Actions

For years Nagstamon allowed certain context actions to be taken to failed hosts and services. These actions include acknowledging and connecting via some remote connection methods like SSH and RDP. With version 0.9.9 these actions are extended to be completely customizable. The already known builtin actions still can be taken but also the user has the freedom to define some actions which fit the needs of the actual environment. Nagstamon comes with some examples like accessing host/service/configuration in Op5 Ninja showing graph in Opsview.

There are builtin actions:

  • Monitor - open host/service page of monitor's web interface in browser
  • Recheck - checks the sate of the host/service again
  • Acknowledge - allows acknowledging host/service problem like in web interface
  • Downtime - maybe a little late but just in case allows to set a host/service into maintenance
  • Submit check result - allows submitting any check result like in web interface

Nagstamon comes with some preconfigured custom actions which simply connect to a host via the protocol stated in their names:

  • RDP
  • SSH
  • Telnet
  • VNC

There are also a lot of example but disabled actions included. These actions may be of those types:

  • Browser - call browser with certain given URL
  • Command - call external command with certain related arguments
  • URL - call any URL in background with arguments, for example a CGI action

The command and URL calls can be constructed of some placeholder variables:

  • $HOST$ - host as in monitor
  • $SERVICE$ - service as in monitor
  • $MONITOR$ - monitor address (https://monitor/....)
  • $MONITOR-CGI$ - monitor CGI address
  • $ADDRESS$ - address of host as set in Nagstamon settings (Hostname/DNS/IP)
  • $USERNAME$ - username on monitor
  • $PASSWORD$ - username's password on monitor
  • $COMMENT-ACK$ - default acknowledge comment
  • $COMMENT-DOWN$ - default downtime comment
  • $COMMENT-SUBMIT$ - default submit check result comment

The following examples might illustrate the possibilities provided by custom actions.

1. Example: Ping command

For diagnosis purposes it might be a good thing to permanently ping a host. To have a console executing such a ping it might take only one click.

First open action settings:

actions_command_1.png

There are some example actions one could use to have a look at but here a new action will be created with "New action...":

actions_command_2.png

Here we go:

actions_command_3.png

As described above there are 3 types of actions. In this case it will be a command so this type will be choosen. An unique name has to be given, for example PING. Some description might help to remember what the actions is good for. The heart of the whole action is the string which will be given as external call. It is OS dependent and would be in this case:

  • Windows: start ping -t $ADDRESS$
  • Linux: gnome-terminal -e "ping $ADDRESS$"
  • MacOS X: /usr/X11/bin/xterm -e -ping $ADDRESS$

If an action only applies to services or hosts its target could be set. Regular expressions are optionally possible to filter out hosts and services to keep the actions menu as usable as possible. The behaviour of the popup window could be set too - if it stays opened it might cover a new terminal window.

actions_command_4.png

Now the new PING action appears in context menu:

actions_command_5.png

After clicking PING a Terminal window appears which runs the ping command with the host address inside:

actions_command_6.png

2. Example: Performance data in Browser

Icinga on OMD comes with PNP4Nagios integrated and it is an easy task to access the performance data of an host or service in your browser with one click in the context menu. First we need to find out the PNP4Nagios-URL of a service:

actions_browser_1.png

Here we see the URL of the performance data of host foobar: http://monitor/test1/pnp4nagios/index.php/graph?host=foobar&srv=_HOST_ . So we need to use this URL when creating an appropriate action and replace "foobar" by variable $HOST$, which looks this way: "$MONITOR$/pnp4nagios/index.php/graph?host=$HOST$&srv=_HOST_". With type "Browser" and target "Host" this is a complete action:

actions_browser_2.png

In case the same should be applied to a service we need to change the action string slightly to $MONITOR$/pnp4nagios/index.php/graph?host=$HOST$&srv=$SERVICE$ :

actions_browser_3.png

The next time a host or service has trouble one could easily access its performance data with one click:

actions_browser_4.png

3. Example: CGI URL call

There are already builtin CGI URL calls like acknowledging a host or service. This can be extended for example wtih a remote call to remove an existing acknowledgement. The type of such an action is "URL" and if we take Icinga again the URL is "$MONITOR-CGI$/cmd.cgi?cmd_typ=52&cmd_mod=2&host=$HOST$&service=$SERVICE$&btnSubmit=Commit" for a service. This should apply only to a service because the URL for hosts is different:

actions_url_1.png

Now a service acknowledgement can be removed with one click:

actions_url_2.png

4. Example: Regular expressions

Regular expressions allow to filter out inappropriate actions. If for example the update state of a server is monitored and the service "Up-to-date-iness" is warning, the context action for it is running an update on that server. This actions make no sense on any other service. So we configure the action "Update-Linux" as "Command" which calls "start C:\Windows\plink.exe root@$HOST$ update.sh" (update.sh is a local script on the server which does the update) only on services which have the name "Up-to-date-iness":

actions_regexp_1.png

Plink.exe is available on Putty homepage and is used to execute commands remotely via SSH.
If the service "Up-to-date-iness" is warning...

actions_regexp_2.png

..after a click on "Update-Linux" a terminal opens, asks for password (which might be omitted with SSH keys)...

actions_regexp_3.png

...and the update starts:

actions_regexp_4.png