0

Currently I have a fairly large syslog-ng cluster setup that is my main log aggregation point. I have the need to be able to acknowledge certain logs and mark them as review for auditing purposes. Such as all failed sudo attempts. I can easily send the logs I am interested in to a specific folder, program, or email, but was wondering what you all use for the auditing aspect of it. Currently I send them to a MySQL DB and have it where it shows the logs and I can click acknowledge and add comments if I like. While this method works, I wanted something a little more professional looking. I've thought about tying them into an open source ticketing system and closing them out after review but wanted others opinions.

Thanks,

Eric

Eric
  • 1,383
  • 3
  • 17
  • 34

1 Answers1

1

One option would be to feed your logs through logstash. Use a matching rule to match desired messages, and then use the logstash email output to create tickets for each message.

EEAA
  • 109,363
  • 18
  • 175
  • 245
  • I did a quick POC of logstash and did like the searching/filtering capabilities of it. My main question on that is I'd still need another piece of software or script where I can track my actual approvals and the fact that I reviewed the logs, or does logstash have some sort of built in ticketing that I am not aware of? – Eric Aug 21 '13 at 15:22
  • If you only want "unread" logs, you can use the AMQP output and create a little consumer which will remove messages after ACK. You can also try the ElasticSearch output and play with it to search/filter/update documents. – Kdecherf Aug 21 '13 at 15:52
  • No, you'd need something like [RT](http://www.bestpractical.com/rt/) to track tickets. RT (and most other ticketing systems) can be configured to consume email from IMAP/POP3 mailboxes and create tickets based on those messages. – EEAA Aug 21 '13 at 16:00
  • If the solution is only used for automated tickets, use of emails to open tickets is counter-productive I think. – Kdecherf Aug 21 '13 at 16:16
  • 1
    @Kdecherf - why counter-productive? Itis likely the fastest way to a solution, as nearly every org has some sort of email system already running, and doesn't require staff to write a custom AMQP consumer and maintain redis/RabbitMQ/etc. – EEAA Aug 21 '13 at 16:42
  • @EEAA IMHO the communication between two apps is not the behavior of emails. But I agree with you, it can be the fastest solution. – Kdecherf Aug 21 '13 at 17:50
  • Legit objection EEAA, if Eric wants to integrate this thing into an existing "enterprise infrastructure" AMQP and the like are a considerable solution but creating tickets seems to be one of the simplest. @Kdecherf: SMTP seems to implement a messaging middleware to me. When you use AMQP you have no frontend which RT or OTRS could be. How would you use your "little consumer"? – mdo Aug 21 '13 at 17:54
  • 1
    @mdo - you seem to have missed the OP's desire to be able to add comments to specific messages. Again, this is something that would have to be written custom if one didn't want to install a ticket tracker. Additionally, he's doing this for regulatory reasons, and the regulatory bodies want to be able to see a full history of messages, comments, actions, and resolutions. Again, requiring custom logic. This is a **perfect** task for a ticket tracking software. – EEAA Aug 21 '13 at 19:16
  • @EEAA - You are correct. Due to the regulatory reasons, being able to track and add comments is essential. I am currently working on installing RT to see how that works for me. Thanks for your advice. – Eric Aug 21 '13 at 19:22
  • @Eric - no problem. Have fun with the gazillion perl modules that RT requires. :) – EEAA Aug 21 '13 at 19:27
  • @EEAA: Yes, I completely agreed with your proposal of a ticket system. My objection to Kdecherf's middleware solution was that he had no frontend. – mdo Aug 21 '13 at 19:35
  • @mdo - ahh, ok. That makes sense - I read your comment wrong the first time around. Thanks for clarifying. – EEAA Aug 21 '13 at 19:37
  • @mdo yeah there is probably no solution out of the box which do the same thing than RT or OTRS using AMQP. We are used to doing a lot of stuff ourselves here to fit our needs, it's another way of think :) – Kdecherf Aug 21 '13 at 20:26