Category: Information Technology

Nagios is an industry leader in network and resource monitoring and GLPI is a great ITIL based help desk system but neither provide integration to each other out of the box. As an IT Manager who uses both systems I found a need to alert the help desk when Nagios recognized a system failure. Of course, Nagios could always send an email alert to a mailbox and then GLPI could pickup that email and create a new ticket. This can work out of the box and I actually ran this configuration for some time but I found out that my help desk was being inundated with tickets that were not being closed and Nagios tickets were filling up the help desk even after the error was rectified on Nagios. Not a very scalable solution. So I set out to find a better solution and my goal was to be able to automatically close GLPI tickets when systems or services return to normal in Nagios. After some research I decided I would write a custom Nagios host and service event handler that opens and closes tickets on GLPI. You can read more about Nagios custom event handlers here You can also download the event handlers at the end of this article. The below event handlers will create new GLPI tickets for Nagios events and close them once the issue has been resolved.  These scripts are written in PHP and do require direct access to the GLPI MySQL database. This solution also requires the web services plugin on the GLPI server.

Pulling it all together

Modify the event handler files to include a GLPI username, password and GPLI server IP, GLPI MySQL Username and Password.  If you are on GPLI version .80+ then enter a GLPI watcher user ID or GLPI group ID.  Then move the files to your /usr/share/nagios/event_handlers/ folder. Next modify your Nagios commands.cfg (/etc/nagios3/commands.cfg) to include the following commands:

# 'manage-host-tickets' command definition
define command{
command_name manage-host-tickets
command_line php /usr/share/nagios3/plugins/eventhandlers/manage-host-tickets.php event="$HOSTSTATE$" state="$HOSTSTATETYPE$" eventhost="$HOSTNAME$" hostattempts="$HOSTATTEMPT$" maxhostattempts="$MAXHOSTATTEMPTS$" hostproblemid="$HOSTPROBLEMID$" lasthostproblemid="$LASTHOSTPROBLEMID$"
}

# 'manage-service-tickets' command definition
define command{
command_name manage-service-tickets
command_line php /usr/share/nagios3/plugins/eventhandlers/manage-service-tickets.php event="$SERVICESTATE$" state="$SERVICESTATETYPE$" hoststate="$HOSTSTATE$" eventhost="$HOSTNAME$" service="$SERVICEDISPLAYNAME$" serviceattempts="$SERVICEATTEMPT$" maxserviceattempts="$MAXSERVICEATTEMPTS$" servicestate="$SERVICESTATE$" lastservicestate="$LASTSERVICESTATE$" servicecheckcommand="$SERVICECHECKCOMMAND$" serviceoutput="$SERVICEOUTPUT$" longserviceoutput="$LONGSERVICEOUTPUT$"
}

Next, modify your generic-host_nagios2.cfg (/etc/nagios3/conf.d)

define host{
        name                            generic-host    ; The name of this host template
        notifications_enabled           1       	; Host notifications are enabled
        event_handler_enabled           1       	; Host event handler is enabled
        flap_detection_enabled          1       	; Flap detection is enabled
        failure_prediction_enabled      1       	; Failure prediction is enabled
        process_perf_data               1       	; Process performance data
        retain_status_information       1       	; Retain status information across program restarts
        retain_nonstatus_information    1       	; Retain non-status information across program restarts
		check_command                   check-host-alive
		event_handler		            manage-host-tickets
		max_check_attempts      1
		notification_interval   0
		notification_period     24x7
		notification_options    d,u,r
		contact_groups          admins
        register                        0       	; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
        }

And then modify the generic-service-nagios2.cfg (/etc/nagios3/conf.d)

define service{
        name                            generic-service ; The 'name' of this service template
        active_checks_enabled           1       ; Active service checks are enabled
        passive_checks_enabled          1       ; Passive service checks are enabled/accepted
        parallelize_check               1       ; Active service checks should be parallelized (disabling this can lead to major performance problems)
        obsess_over_service             1       ; We should obsess over this service (if necessary)
        check_freshness                 0       ; Default is to NOT check service 'freshness'
        notifications_enabled           1       ; Service notifications are enabled
        event_handler_enabled           1       ; Service event handler is enabled
        flap_detection_enabled          1       ; Flap detection is enabled
        failure_prediction_enabled      1       ; Failure prediction is enabled
        process_perf_data               1       ; Process performance data
        retain_status_information       1       ; Retain status information across program restarts
        retain_nonstatus_information    1       ; Retain non-status information across program restarts
		notification_interval           0		; Only send notifications on status change by default.
		event_handler		            manage-service-tickets
		is_volatile                     0
		check_period                    24x7
		normal_check_interval           5
		retry_check_interval            1
		max_check_attempts              4
		notification_period             24x7
		notification_options            w,u,c,r
		contact_groups                  admins
        register                        0       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
        }

You will now receive helpdesk tickets in GLPI when alerts are created in Nagios and those tickets will be removed when the service or host has been restored.  GLPI can now handle the appropriate  notifications.

Download

[wp_ad_camp_2] [wpdm_file id=1] Happy Monitoring!