Changes to service notifications not invoked

[hhlodge]

Because of the amount of customization and changes I do to notifications, until there's an easy way to centrally manage user's notification settings, I've decided I'd rather use the standard notify-service-by-email command. Is there any reason to reconsider that decision?

[rdedon]

It sounds like you are in a very dynamic environment so for now this would be a "low-impact" solution.

[hhlodge]

Have these xi_service_notification_handler variables been documented anywhere yet? I'd like to know if there is an equivalent variable for Core's $NOTIFICATIONRECIPIENTS$ macro. And it would be great if Core had a corresponding %responseurl% macro for use in notify-service-by-email command.

[scottwilkerson]

You can modify the xi_service_notification_handler command to have the

Configure -> CCM -> Commands -> Modify
If you append the following to the command you will be able to use the macro %notificationrecipients% in your messages.

Code: Select all

--notificationrecipients="$NOTIFICATIONRECIPIENTS$"

Unfortunately the %responseurl% macro is only available in the xi_service_notification_handler & xi_host_notification_handler

[hhlodge]

Works great, thanks. Are all these XI variables documented yet?

[scottwilkerson]

All of the standard Nagios variable can be added in the same method described, there is a list here
http://nagios.sourceforge.net/docs/3_0/macrolist.html

as for the macro's only implemented in the XI handler, I believe it is just
Respond: %responseurl%
Nagios URL: %xiserverurl%

[hhlodge]

I am aware of the standard macros but if you look back in this post where I posted my findings, many of the XI variables are not a match for their Core counterparts.

[scottwilkerson]

The macro's that are available will depend on your command specifications, you can add or remove them, the default is something like this

Code: Select all

/usr/bin/php /usr/local/nagiosxi/scripts/handle_nagioscore_notification.php --notification-type=service 
--contact="$CONTACTNAME$" 
--contactemail="$CONTACTEMAIL$" 
--type=$NOTIFICATIONTYPE$ 
--escalated="$NOTIFICATIONISESCALATED$" 
--author="$NOTIFICATIONAUTHOR$" 
--comments="$NOTIFICATIONCOMMENT$" 
--host="$HOSTNAME$" 
--hostaddress="$HOSTADDRESS$" --hostalias="$HOSTALIAS$" 
--hostdisplayname="$HOSTDISPLAYNAME$" 
--service="$SERVICEDESC$" 
--hoststate=$HOSTSTATE$ 
--hoststateid=$HOSTSTATEID$ --servicestate=$SERVICESTATE$ 
--servicestateid=$SERVICESTATEID$ 
--lastservicestate=$LASTSERVICESTATE$ 
--lastservicestateid=$LASTSERVICESTATEID$ --servicestatetype=$SERVICESTATETYPE$ 
--currentattempt=$SERVICEATTEMPT$ 
--maxattempts=$MAXSERVICEATTEMPTS$ 
--serviceeventid=$SERVICEEVENTID$ --serviceproblemid=$SERVICEPROBLEMID$ 
--serviceoutput="$SERVICEOUTPUT$" 
--longserviceoutput="$LONGSERVICEOUTPUT$" 
--datetime="$LONGDATETIME$"

each item that starts with -- will become a macro of the name that follows it.

For example, if you see --datetime="$LONGDATETIME$"
you will have a notification macro available as %datetime% that will = $LONGDATETIME$

[hhlodge]

FYI - I upgraded to 3.2 yesterday and the change I made to the xi_notification commands were not carried over. Perhaps related to these errors from the upgrade?

Applying NDOUtils patch level 103
ALTER TABLE `nagios_logentries` DROP INDEX `logentry_time_2` ;
SQL: SQL Error [ndoutils] :</b> Can't DROP 'logentry_time_2'; check that column/key exists ALTER TABLE `nagios_logentries` DROP INDEX `logentry_data_2` ;
SQL: SQL Error [ndoutils] :</b> Can't DROP 'logentry_data_2'; check that column/key exists ALTER TABLE `nagios_logentries` DROP INDEX `instance_id_2` ;
SQL: SQL Error [ndoutils] :</b> Can't DROP 'instance_id_2'; check that column/key exists ALTER TABLE `nagios_statehistory` DROP INDEX `state_time_2` ;
SQL: SQL Error [ndoutils] :</b> Can't DROP 'state_time_2'; check that column/key exists ALTER TABLE `nagios_statehistory` DROP INDEX `object_id_2` ;
SQL: SQL Error [ndoutils] :</b> Can't DROP 'object_id_2'; check that column/key exists ALTER TABLE `nagios_notifications` DROP INDEX `start_time_2` ;
SQL: SQL Error [ndoutils] :</b> Can't DROP 'start_time_2'; check that column/key exists ALTER TABLE `nagios_notifications` DROP INDEX `object_id_2` ;
SQL: SQL Error [ndoutils] :</b> Can't DROP 'object_id_2'; check that column/key exists ALTER TABLE `nagios_notifications` DROP INDEX `instance_id_2` ;
ALTER TABLE `nagios_contactnotifications` DROP INDEX `notification_id_2` ;
SQL: SQL Error [ndoutils] :</b> Can't DROP 'notification_id_2'; check that column/key exists ALTER TABLE `nagios_contactnotifications` DROP INDEX `contact_object_id_2` ;
SQL: SQL Error [ndoutils] :</b> Can't DROP 'contact_object_id_2'; check that column/key exists ALTER TABLE `nagios_contactnotificationmethods` DROP INDEX `contactnotification_id_2` ;
SQL: SQL Error [ndoutils] :</b> Can't DROP 'contactnotification_id_2'; check that column/key exists ALTER TABLE `nagios_objects` DROP INDEX `objecttype_id_2` ;
SQL: SQL Error [ndoutils] :</b> Can't DROP 'objecttype_id_2'; check that column/key exists ALTER TABLE `nagios_objects` DROP INDEX `name1_2` ;
ALTER TABLE `nagios_objects` DROP INDEX `name2_2` ;
ALTER TABLE `nagios_objects` DROP INDEX `is_active_2` ;
ALTER TABLE `nagios_timedeventqueue` DROP INDEX `queued_time_2` ;
ALTER TABLE `nagios_timedevents` DROP INDEX `queued_time_2` ;
NDOUtils patched to level 103 successfully.

[scottwilkerson]

These actually aren't "errors" as this portion of the script runs through to find and delete duplicate indexes in the database.

with some updates the xi_notification commands will be over written as features are added. It is best to create new command when making customizations and use those, this way they will never be overwritten.