event_handlers macro contactemail

[Carlos de Sousa]

Thanx again for your answer, I think things are getting clearer now!

Actually, it is not a fire-and-forget kind of thing.

I started with Nagios V1 a long time ago, and are using
the eventhandler to send snmptraps to a TEMIP console.

I have developed our own "NAGIOS-MIB" that is integrated into
TEMIP (remember this was long before V2 was announced)

to Keep the TRAP and TRAP_CLEAR in SYNC, the eventhandler
uses a sequence number for the alarm, and the eventhandler
keeps a STATE database with seq number, so for example, when I get
a UP or OK from Nagios, I lookup the host/service pair in
the local DB and send off a CLEAR/RESET trap with the same SEQ number
as when SERVICE/HOST went CRITICAL/DOWN.

So it's imperative that I always have a matching UP/OK
for each DOWN/CRITICAL, that is basically the only
states I bother to handle.

One of the many MIB variables in the TRAP is a URL, that
contains all kind of info, When the NOC people see the alarm
in TEMIP, we have a modification so that they get a drop-down menu
with the choice to surf to the URL, which will bring up a WEB
browser containing alarm instructions (dynamically generated
by a CGI I have developed that gets the information for the Instruction 
thru the URL in the MIB)

And that is why I would like to send the CONTACT to be able to present
it on the Alarm Inst. WEB page so the NOC knows where to send any 
questions too as we have different TEAM's that manages different
hostgroups

We are also doing HEARTBEAT functionality so that TEMIP gets an alarm
if the NAGIOS processes are not running on the box, but that is another 
story.

Is there a better way of doing this with Nagios V2? I have seen
some references to a NAGIOS MIB for V2, but haven't looked any closer.

Would the notification be sufficient to trig the above mentioned states?

We have around 600 devices around the world that we monitor from 3 
different NAGIOS thats uses my stuff to send all alarms to 1 central TEMIP.

Any suggestions?

Appreciate any input.

Regards
Carlos de Sousa






Marc Powell wrote:
> Comments inline...
> 
> 
>>-----Original Message-----
>>From: nagios-users-admin at lists.sourceforge.net [mailto:nagios-users-
>>admin at lists.sourceforge.net] On Behalf Of Carlos de Sousa
>>Sent: Thursday, March 09, 2006 4:19 PM
>>To: nagios-users at lists.sourceforge.net
>>Subject: Re: [Nagios-users] event_handlers macro contactemail
>>
>>Hi!
>>
>>Thanx for the prompt answer, I realize now that
>>I shouldn't try to fool the system by using obscure
>>ways.
>>
>>BUT .....
>>
>>    If I use the suggested "contact"-path, could u
>>pls explain what is the major difference between
>>a notification and an event?
> 
> 
> An event-handler is run for every non-OK check up to max_check_attempts
> (soft and hard states) and once when the service recovers to an OK
> state. A notification is launched when non-OK checks reach
> max_check_attempts (hard state), when a recovery occurs and whenever you
> have repeat notifications scheduled (if at all). I'm excluding
> escalations but those could be useful as well.
> 
> 
>>If I already have in production  a event-handler
>>script that works fine (except for not using the CONTACTx stuff),
>>would I then disable "event_handler processing" completely
>>and use the contactgroup in a host definition to use a contact
>>that would call the same script as I am using for events?
> 
> 
> If you did this then the event_handler would be redundant. I don't know
> what you're really trying to accomplish but a notification is the only
> way that the CONTACT_* macros are currently available directly from
> within Nagios. 
>  
> 
>>The example I gave before is somewhat shortened, here is what
>>I really use
>>
>>define command {
>>command_name                   send_snmptrap_host
>>command_line                   /usr/bin/perl
>>$USER1$/eventhandlers/send_nagiostrap HOST $HOSTSTATE$ $HOSTSTATETYPE$
>>$HOSTATTEMPT$
> 
> $HOSTNAME$#$HOSTADDRESS$#$HOSTALIAS$#$SERVICEDESC$#$USER2$
> 
>>}
>>
>>Would I still be able to use the above macros through a notification
>>command?
> 
> 
> I presume you'd be adding $CONTACTEMAIL$ and $CONTACTPAGER$ to the above
> but the answer is yes. Again, the chart linked below details where each
> macro is valid. Just look for a Yes in the Service Notifications or Host
> Notifications column, whichever you are going to use --
> 
> http://nagios.sourceforge.net/docs/2_0/macros.html
> 
> 
>>Would the macros above contain the exact same information if I used
>>them in a notification command rather than in a event_handler?
> 
> 
> Yes, with the caveat that they're only run when the check reaches a HARD
> state so $HOSTSTATETYPE$ would always be HARD and $HOSTATTEMPT$ would
> always be max_check_attempts for that host (I believe).
> 
> 
>>So basically, If I understood u right, u say that I could do
>>
> 
> [config example removed]
> 
> Looks workable to me.
> 
> 
>>would I loose any functionality at all by not using eventhandlers
>>in favor of notification commands?
> 
> 
> Some, related to when they are executed as noted above. Whether that's
> important or not is up to you. From what I've gathered, you're looking
> for kind of fire-and-forget functionality which is very similar to a
> notification.
> 
> --
> Marc
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> _______________________________________________
> 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

-- 
Carlos de Sousa

Ericsson AB
Phone: +46 8 56860605
Mail: Carlos.de_Sousa at ericsson.com

Disclaimer

This communication is confidential and intended solely for the 
addressee(s). Any unauthorized review, use, disclosure or distribution 
is prohibited. If you believe this message has been sent to you in 
error, please notify the sender by replying to this transmission and 
delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data 
corruption,interruption, unauthorized amendment, tampering and viruses, 
and we only send and receive e-mails on the basis that we are not liable 
for any such corruption, interception, amendment, tampering or viruses 
or any consequences thereof.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Carlos.de_Sousa.vcf
Type: text/x-vcard
Size: 161 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/users/attachments/20060310/9c45a6de/attachment.vcf>