<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: #000000'>You can build a new contact group that is gets alert only from this commands . Or you can split the templates and build a new one that uses this alerting for the new service . You need to think of the process of the alerts and define what alerts to send . I know many people think that adding new (insert nagios item ) is trouble , but i found that if some thing "breaks" my conventions or is an exemption , it is best to "build" the templates for it and make it modular - as it is most likely will happen again , and that way you'll have the definition ready . Assaf <hr id="zwchr"><div style="color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;">From: "Andrew Thompson" <andrew@fulgent.co.uk> To: nagios-users@lists.sourceforge.net Sent: Wednesday, 30 November, 2011 11:37:10 AM Subject: [Nagios-users] Can you add custom commands to the 2 standard "notify-host-by-xxx" and "notify-service-by-xxx" commands? <style></style> <div class="WordSection1"> Hi all. Is it possible to add your own custom commands to add to the 2 standard notify commands? At the moment I have # 'notify-host-by-email' command definition define command{ command_name notify-host-by-email command_line /usr/bin/printf "%b" "***** Nagios says its broken *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\n$HOSTOUTPUT$\n\nHost: $HOSTNAME$\nAddress: $HOSTADDRESS$\nState: $HOSTSTATE$\n\nDate/Time: $LONGDATETIME$" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$ } # 'notify-service-by-email' command definition define command{ command_name notify-service-by-email command_line /usr/bin/printf "%b" "***** Nagios says its broken *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nInfo :$SERVICEOUTPUT$\n\n Service: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$ is $SERVICESTATE$ **" $CONTACTEMAIL$ } This is fine for the hosts that I manage by PING. Now I have started to manage my websites for both availability and also to navigate through the site using 2 separate scripts. Id like separate notifications for the website checks as id like to add more text into the subject line. For eg if 1 of my sites has an issues and 1 of the pages it navigates for is not available or returns something different to what it should id like: # 'notify-website-service-by-email' command definition define command{ command_name notify-website-service-by-email command_line /usr/bin/printf "%b" "***** Nagios says its broken *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nInfo :$SERVICEOUTPUT$\n\n Service: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: Website content cannot be found at $HOSTALIAS$ and is in a $SERVICESTATE$ state**" $CONTACTEMAIL$ } But if I create this and add it to my Critical website template which tells it to to email the admin email contact group which has me and another admin in it then its going to send both the original “notify-service-by-email” and the new “notify-website-service-by-email Any way I can get around this. Apologies if it’s a really simple answer by the way…. Thankyou </div> ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Nagios-users mailing list Nagios-users@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</div> </div></body></html>