Nagios-filter / Nagios integration
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi OTRS-Team, based on the recent discussion with bb I want to explain my ideas and codings for an Nagios-Integration in OTRS. A few months ago I needed a PostMaster-Filter to put nagios messages in a predefined queue. However, this filter does a little more than putting the message in a queue. The filter features are: - - check mail to see if it's a nagios mail - - check if it's a host or service request - - put mail in defined queue as a ticket - - set configurable freetext fields with host/ip/service... - - whenever there are already tickets for a certain nagios message/incident, following nagios messages for this incident are appended to this ticket as new articles - - if the arriving message is a recovery alert the corresponding ticket is closed - - configuration for nagios filter is developed as sysconfig-xml To Dos/ideas A pop-up (or whatever) should be used to inform agents of current nagios incidents without searching for those tickets or accessing the nagios web interface. This little display contains a report something like that: Host IP Service comment ... ... .... ......... It refreshes every x minutes so IT-service agents have up to date information and may help customers with a first qualified response. If you are interested in completing or developing the idea or as a first step to create a package out of it, I'm looking forward for your response. If you are interested in the code just contact me. regards, Rico - -- Dipl.-Math. Rico Barth, Geschäftsführer/Projektleiter c.a.p.e. IT GmbH Annaberger Straße 240 , 09125 Chemnitz phone/fax: +49 371 5347-621 / -625 mobile: +49 176 66680786 mailto: rico.barth@cape-it.de , PGP-Key: 0x874C8377 internet: www.cape-it.de Geschäftsführung Rico Barth, Thomas Maier AG Chemnitz, HRB 23192 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGAooBmy4UBYdMg3cRAkOaAJ9C4sna8kZEMLbbF2M5+Y4esvTFKACeL5Tx DJhnmxQ2cYKe6qratTccrNY= =YV0O -----END PGP SIGNATURE-----
On Thu, 2007-03-22 at 14:51 +0100, Rico Barth wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi OTRS-Team,
based on the recent discussion with bb I want to explain my ideas and codings for an Nagios-Integration in OTRS.
A few months ago I needed a PostMaster-Filter to put nagios messages in a predefined queue. However, this filter does a little more than putting the message in a queue. The filter features are:
- - check mail to see if it's a nagios mail - - check if it's a host or service request - - put mail in defined queue as a ticket - - set configurable freetext fields with host/ip/service... - - whenever there are already tickets for a certain nagios message/incident, following nagios messages for this incident are appended to this ticket as new articles - - if the arriving message is a recovery alert the corresponding ticket is closed - - configuration for nagios filter is developed as sysconfig-xml
This pretty much sums up what I am working at right now. :) I didn't distinguish between host and service requests however. If no service can be identified, service is set to 'Host' (or whatever you configure it to be) and from that point on 'Host' is treated as any other service.
To Dos/ideas
A pop-up (or whatever) should be used to inform agents of current nagios incidents without searching for those tickets or accessing the nagios web interface. This little display contains a report something like that:
Host IP Service comment ... ... .... .........
It refreshes every x minutes so IT-service agents have up to date information and may help customers with a first qualified response.
If you are interested in completing or developing the idea or as a first step to create a package out of it, I'm looking forward for your response. If you are interested in the code just contact me.
I like the idea of what I would call a real-time-ticket-watcher. I see this as an independent functionality however. Why restrict it to special tickets? Wouldn't it be cooler to select a search template and have all ticket matched by that search to be monitored? BB -- ((otrs)) :: OTRS GmbH :: Norsk-Data-Strasse 1 :: D - 61352 Bad Homburg Fon: +49 (0) 6172 681988 0 :: Fax: +49 (0) 9421 56818 18 http://www.otrs.com/ :: Communication with success! Geschäftsführer: André Mindermann, Martin Edenhofer Handelsregister: HRB 9452 Bad Homburg Steuernummer: 003/240/97521
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi bb! On Thu, 22 Mar 2007, Bodo Bauer wrote:
This pretty much sums up what I am working at right now. :)
I didn't distinguish between host and service requests however. If no service can be identified, service is set to 'Host' (or whatever you configure it to be) and from that point on 'Host' is treated as any other service.
In the past I have had some Nagios implementations where message subject and message bodies are changed for local needs. so this is why I distinguish between Host, Service and any others. I would be flexible with this module to set some specific values, do some specific things and so on. I put the code on our homepage. may have a look on it. (it's not beautified :-> ) http://www.cape-it.de/download/EMailNagios.tgz
I like the idea of what I would call a real-time-ticket-watcher. I see this as an independent functionality however. Why restrict it to special tickets? Wouldn't it be cooler to select a search template and have all ticket matched by that search to be monitored?
What's your opinion about rss? IMHO it's a cool idea to implement an real-time-watcher. What about environments where no additional software is allowed? regards, Rico - -- Dipl.-Math. Rico Barth, Geschäftsführer/Projektleiter c.a.p.e. IT GmbH Annaberger Straße 240 , 09125 Chemnitz phone/fax: +49 371 5347-621 / -625 mobile: +49 176 66680786 mailto: rico.barth@cape-it.de , PGP-Key: 0x874C8377 internet: www.cape-it.de Geschäftsführung Rico Barth, Thomas Maier AG Chemnitz, HRB 23192 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGArK6my4UBYdMg3cRAmRKAKD2D3NbPXhRsvXilXuXySuf4aC26QCdHDJN QG3tAwYR0h/qTyeZzyrCQs4= =vt35 -----END PGP SIGNATURE-----
On Thu, 2007-03-22 at 17:45 +0100, Rico Barth wrote:
Hi bb!
On Thu, 22 Mar 2007, Bodo Bauer wrote:
This pretty much sums up what I am working at right now. :)
I didn't distinguish between host and service requests however. If no service can be identified, service is set to 'Host' (or whatever you configure it to be) and from that point on 'Host' is treated as any other service.
In the past I have had some Nagios implementations where message subject and message bodies are changed for local needs. so this is why I distinguish between Host, Service and any others. I would be flexible with this module to set some specific values, do some specific things and so on. I put the code on our homepage. may have a look on it. (it's not beautified :-> )
I had quick glance at your module, and while we're trying address the same issue, we choose very different ways to do so. You're detecting Nagios mails and create a ticket object in case you fond one. Nothing wrong with that. But I think our solution has more flexibility. We implemented a filter at the beginning of the mail processing pipeline. We also detect Nagios Mails by the From: header and extract service host, etc using configured regular expressions from the body just as you do. What we don't have is handling of encrypted mails... But going on from there we choose a different route. Instead of creating a ticket, only a few relevant X-OTRS headers are set and mail is passed back to the regular mail processing. This allows for all the tinkering you can do with other incoming mails as well. Queue selection, setting more headers, etc. And all this without any change in the Nagios Module. This means that any other features of mail processing are preserved and future additions will just plug in. I rather have a set of small, easy to understand and easy to maintain modules which I can connect with each other than a few specialized ones which do one thing very well, but can't be reused in for tasks very easily. It's the old UNIX tradition I guess... :)
I like the idea of what I would call a real-time-ticket-watcher. I see this as an independent functionality however. Why restrict it to special tickets? Wouldn't it be cooler to select a search template and have all ticket matched by that search to be monitored?
What's your opinion about rss? IMHO it's a cool idea to implement an real-time-watcher. What about environments where no additional software is allowed?
Yeah, having an RSS feed would be very cool. I'm not too concerned about the add-on software issue. Firefox for example comes with Build-In RSS support. I'm not sure about legacy Software like IE but I guess they'll have this as well sooner or later. More important is that if RSS feeds are important for a particular installation, this should be a management decision. So if they decide that they need this service for OTRS, they also should realize that they need to allow/provide a client app or a Web Service to watch these notifications. And what I really like about RSS is that there are plenty of mobile clients around. Meaning you could get ticket notifications on your cell just as easy as on you desktop. :) BB -- ((otrs)) :: OTRS GmbH :: Norsk-Data-Strasse 1 :: D - 61352 Bad Homburg Fon: +49 (0) 6172 681988 0 :: Fax: +49 (0) 9421 56818 18 http://www.otrs.com/ :: Communication with success! Geschäftsführer: André Mindermann, Martin Edenhofer Handelsregister: HRB 9452 Bad Homburg Steuernummer: 003/240/97521
Hi, in a brief internal chat about the idea of RSS feeds for OTRS one interesting issue came up: What about authentication?. Googling the issue I got the impression that the only way to restrit access to RSS feeds is using HTTP Basic Auth. Which in itself is not the problem. I think we cover that in OTRS by setting/checking the referring headers. The question is if all RSS clients can deal with this? Has anybody here experience with restricted RSS feeds? BB
participants (2)
-
Bodo Bauer -
Rico Barth