Hi.
I personally like using the hostname first, then the service. Something like this for example: adams : RAM is in a CRITICAL state! It makes it easier for me to sort alerts in Outlook that way (I have a rule sending all alerts to a separate folder), so I can see everything going on with a particular server, for example. Or to view how long a certain alert has been going on. I also changed the default output to HTML for easier reading (because I send alerts both to Instant Messenger and also email). Not sure if this will come out nicely (still in HTML format) through the mailing list, but here is a sample: Alert Type PROBLEM Hostname adams <http://nagios.mycompany.com/cgi-bin/status.cgi?host=adams> (Database Server) Address 912.267.822.2 Service RAM <http://nagios.mycompany.com/pnp/index.php?host=adams&srv=RAM> State CRITICAL Time Thu May 6 11:17:27 EDT 2010 Info RAM CRITICAL - 3% (7 of 196 MB) free Inventory View Host <http://myinventory.mycompany.com/inventory/view?hostname=adams> RT Tickets <http://myrtserver.mycompany.com/Search/Results.html?ClearRestrictions=1 &Query=Status%20!%3D%20%22resolved%22%20AND%20Content%20LIKE%20%22adams% 22> It is hyperlinked to Nagios (host view, then service view), as well as to this host in the inventory system and to the ticketing system (see all touble tickets related to this host). That's just what works for us. - Brent From: Kumar, Ashish [mailto:xml.de...@gmail.com] Sent: Friday, May 07, 2010 1:41 AM To: nagios-users ML Subject: [Nagios-users] Meaningful subject lines in e-mail alert Greetings, We are sending e-mail alerts on host/service state change. I was just wondering what do you guys use as subject lines; just looking around for ideas. Thank you in advance.
------------------------------------------------------------------------------
_______________________________________________ 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