Home > Nagios > HOW TO USE EVENT_HANDLERS IN NAGIOS

HOW TO USE EVENT_HANDLERS IN NAGIOS

January 19th, 2009 Leave a comment Go to comments

This case I wanted to AUTO RESTART A SERVICE USING NAGIOS.
The event_handlers can automaticly handle a alarm, aiming to solving the problem for the administrator.

Restart_svc is a batch file inside nrpe_nt folder witch should also be defined inside nrpe.cfg as a command called restart_svc
The nrpe.cfg:
command[restart_svc]=c:NRPE_NTpluginsrestart_svc.bat $ARG1$

This is the batch file in nrpe_nt/plugins:
net stop %1

net start %1

@echo Restarted Service %1

exit %ERRORLEVEL%
note: %1 is refered to the service name, argument passed.

Now define the service check using whatever method you like, I used SNMP and inside it define the event_handler:
event_handler restart_service!pdm_daemon_manager
event_handler_enabled 1

Ok now its set to Call script using NRPE_NT -> try restart services
Restart_service should also be defined as a command:
./check_nrpe -u -H -p 5666 -t 30 -c restart_svc -a

This is it, it worked fine for me. Altough I wanted to have the server reboot if the service is not restarted correctly.

More about event_handlers:
Event handlers are optional system commands (scripts or executables) that are run whenever a host or service state change occurs.

An obvious use for event handlers is the ability for Nagios to proactively fix problems before anyone is notified. Some other uses for event handlers include:

* Restarting a failed service
* Entering a trouble ticket into a helpdesk system
* Logging event information to a database
* Cycling power on a host*
* etc.

* Cycling power on a host that is experiencing problems with an auomated script should not be implemented lightly. Consider the consequences of this carefully before implementing automatic reboots. 🙂

When Are Event Handlers Executed?

Event handlers are executed when a service or host:

* Is in a SOFT problem state
* Initially goes into a HARD problem state
* Initially recovers from a SOFT or HARD problem state

SOFT and HARD states are described in detail here .

Event Handler Types

There are different types of optional event handlers that you can define to handle host and state changes:

* Global host event handler
* Global service event handler
* Host-specific event handlers
* Service-specific event handlers

Global host and service event handlers are run for every host or service state change that occurs, immediately prior to any host- or service-specific event handler that may be run. You can specify global event handler commands by using the global_host_event_handler and global_service_event_handler options in your main configuration file.

Individual hosts and services can have their own event handler command that should be run to handle state changes. You can specify an event handler that should be run by using the event_handler directive in your host and service definitions. These host- and service-specific event handlers are executed immediately after the (optional) global host or service event handler is executed.

Enabling Event Handlers

Event handlers can be enabled or disabled on a program-wide basis by using the enable_event_handlers in your main configuration file.

Host- and service-specific event handlers can be enabled or disabled by using the event_handler_enabled directive in your host and service definitions. Host- and service-specific event handlers will not be executed if the global enable_event_handlers option is disabled.

Event Handler Execution Order

As already mentioned, global host and service event handlers are executed immediately before host- or service-specific event handlers.

Event handlers are executed for HARD problem and recovery states immediately after notifications are sent out.

  1. No comments yet.
  1. No trackbacks yet.

VAMOVE *

*