Generate HTML emails for Opsview service and host alerts

All credit goes to https://github.com/Voxer/nagios-html-email as this is a simple fork and modification of a few lines to get the script working with Opsview.

Generate HTML emails for Opsview service and host alerts. This is a forked version of the nagios-html-email nodejs script with amendments for Opsview.

Instead of choosing service vs hosts notification method in commands.cfg, service or host check is determined by the existence of the env variable passed to the notification script, NAGIOS_SERVICEATTEMPT which should be null for host checks.

Opsview is based on Nagios however notifications and configuration is handled differently. Opsview has done away with the .cfg files and all the configuration takes place in the web interface. Any changes that get made to the .cfg files will mostly get overwritten.

The installation into the commands.cfg, or misccommands.cfg for Opsview gets overwritten on a reload. For the nagios installation instructions please see Voxer/nagios-html-email on Github.

The modifications I have made will stop this working with Nagios.

Tested on Opsview Core 3.20131016.0.14175-1precise1 on Ubuntu 12.04 LTS as of 2014-06-10. a Installation

Generate HTML emails for Opsview service and host alerts

Requires nodejs and npm. Install with your package manager. Below is for Ubuntu

$ ~ sudo apt-get update; sudo apt-get install nodejs npm

Install this package on your opsview server

$ ~ sudo npm install -g opsview-html-email

Check that the opsview-html-email script is in the path of the nagios user.

$ ~ which opsview-html-email

In /usr/local/nagios/libexec/notifications create a symlink to the script

$ ~ ln -s /usr/bin/opsview-html-email /usr/local/nagios/libexec/notifications/opsview-html-email

You can now test this from the command line, but first you will need to export some environment variables for the script to use. This is only for testing. See the Testing section below for better testing.

export NAGIOS_HOSTALIAS="test server alias"
export NAGIOS_CONTACTEMAIL="your.email@domain"
export NAGIOS_SERVICEDESC='CPU Utilisation'
export NAGIOS_HOSTADDRESS='prod1-database.domain'
export NAGIOS_LONGDATETIME='2014-06-10 15:39'

Now you can run

$ ~ opsview-html-email your-opsview-host.domain | sendmail -t

You may have to change sendmail for the mail daemon configured on your server. You can also not pipe to sendmail to see the raw HTML output.

Now in your Opsview web interface, add a new Notification method. Name it whatever suits and add the command as opsview-html-email your-opsview-server.domain | sendmail -t

Also add EMAIL as a variable underneath. Otherwise the NAGIOS_CONTACTEMAIL env variable will not get passed into the script, and your emails will get sent to dummy@localhots

You should be able to add your new notification method to existing or new notification profiles and start generating HTML emails from Opsview. I added mine alongside existing notification methods in case it didn't work so I still recieved alerts.

Have a look at the troubleshooting section if your emails come through as just JSON or raise an issue.

I have updated the templates slightly so they will appear different to the screenshots here. Only slightly though.

A critical service

The service recovery, threaded because the subject is the same

Host recovery

I have skipped the advanced usage step for now as I haven't found out if it works with Opsview yet. Will add in later following some testing!

By default, this program will use builtin templates for host and service alerts. You can use your own templates by supplying -t <dir> to point to a directory with your templates.

See templates/ to see the builtin templates.

Templates are rendered using EJS, and have these variables available for you to use.

  • nagios: this object contains all of the Nagios variables found as environmental variables. For example, nagios.CONTACTEMAIL, nagios.HOSTSTATE, etc. Any variable you could access as a macro like $MACRONAME$ will be avaliable as nagios.MACRONAME.
  • args: this array contains all of the command line arguments after the type argument. For instance, if the program is invoked as nagios-html-email -t /etc/templates -s subject service foo bar baz the array will be set to ['foo', 'bar', 'baz'].
  • package: package.json from this module as an object; this can be used to get information like package.version, etc.

A custom template dir, if you supply one, should contain at least a host.html.ejs and service.html.ejs file for host and service alerts respectively.

Most likely, the path with nagios-html-email in it is not in the PATH variable for the Nagios server. Ensure the path given by which nagios-html-email is in the PATH of the Nagios server.

This means that a template failed to render. Instead of failing to send an email, this program will do everything it can to make sure you get an email, even if it isn't pretty.

Since variables are passed as either command line arguments or environmental variables, all variables are of type String. You must expliticly cast any values you know to be numbers, booleans, dates, etc. to their correct data type.

**Not sure if this works with Opsview. Haven't tested or found a need for this in my server. **

You can still use this program, just pass the variables you would like to use as command line arguments, and access them in your template as args[0], args[1], etc. For example:

define command {
    command_name notify-service-by-email
    command_line nagios-html-email -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" -a $CONTACTEMAIL$ service | mailx -t

However, from experience, passing environmental variables won't cause too much of a performance penality. I'd recommend turning it on for a bit to see how it affects your latency before turning off such an amazing feature.