Alternate methods to notify Nagios

[Demetri Mouratis]

On Fri, 15 Jul 2005, Adam Engel wrote:

>
>
> Demetri Mouratis wrote:
>
>> On Fri, 15 Jul 2005, Adam Engel wrote:
>> 
>>> Hey guys!
>>> 
>>> I have been using Nagios for over 2 years now and really enjoy it.  I have 
>>> a question regarding ways to inform Nagios of problems.  Does anyone know 
>>> of a plugin that will allow Nagios to accept email from a peice of 
>>> software informing it that a problem is going on.  This would be nice so 
>>> that the software we have written can send an email to nagios stating 
>>> there is a problem and then nagios sends out its normal notifications.  I 
>>> have already told the developers of NSCA, but they would like if there was 
>>> a way Nagios could be informed via email because they wouldn't have to 
>>> write anything.
>>> 
>>> Thanks,
>>> 
>>> Adam
>> 
>> 
>> Adam,
>> 
>> I doing exactly what you describe to connect my Nagios Distributed boxes to 
>> Nagios Central.  NSCA wasn't an option in my environmnent to I needed to 
>> come up with an alternative that used a well-known port.  I chose postfix 
>> as the MTA for both the sending and receiving sides and added a GPG 
>> encryption layer to encrypt the data.  Then I hooked up a 
>> global_service_event_handler called submit_check_result_smtp that looks 
>> like this:
>> 
>> time=`perl -e 'print time';`
>> 
>> /bin/echo "[$time] PROCESS_SERVICE_CHECK_RESULT;$1;$2;$return_code;$4" | 
>> /usr/bin/gpg -ea -r nagios --batch --no-tty --always-trust | mail -s 
>> "Nagios Status Message" nagios at nagioscentral.mydomain.com
>> 
>> On the central box, I have a small perl script that takes mail on stdin, 
>> gpg decrypts it and writes the output to the named pipe using the 
>> Mail::GnuPG, MIME::Parser, and MIME::Entity perl modules.
>> 
>> It has been running in production for 6 months now without any major 
>> issues.
>> 
>> Some of the other advandantes of using an MTA include the ability to retry 
>> deferred messages (a mixed bag) and extended logging functionality.
>> 
>> Hope that helps. 
>
> Yes it does. I have been informed of more, they want these to be sent from 
> Java. We have Java jobs that run all day doing various tasks, and if a job 
> detects that it is about to die or something bad is happening then it will 
> email to Nagios. And then nagios will catch the message and process it.

What you describe is very similar to how our Nagios infrastructure was 
configured when I arrived.  All I can say is be very careful letting the 
developers drive too much.  For example, they may send a CRITICAL state 
when java throws an exception but who is responsible for sending the OK 
state after the problem has abated?  Also of concern is the exact name of 
the service check.  You'll have to know the service names so that you can 
configure services.cfg.  If the developer uses a different service name 
you'll end up with a mismatch.  This can quickly get maddening.

The alternate we settled on here was for the java developers to expose a 
call that would be responsible for maintaining the state of the various 
java components running our our application.  Nagios in turn ssh's into 
the machine and invokes a plugin that can get the current state of the 
java components.  This is a pull where the method you described above is a 
push.  In my experience, managing the pull configuration is much easier. 
---------------------------------------------------------------------
Demetri Mouratis
dmourati at linfactory.com


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null