An efficient monitoring setup

Default monitoring settings can be quite usable for most use cases; however, as the monitoring setup grows, certain configuration tweaks might be required to make monitoring more efficient. Alerts should actually attract attention of network administrator; otherwise, they are as good as gone.

Alerts sent by monitoring tools should reach their destination. Although it can look obvious, there are several common pitfalls we should warn you about.

Below we assume all the configuration used in IPHost monitoring setup is using the defaults from its initial installation.

Make subject lines unique and mnemonic

The template of typical “Send mail” simple action (the one used to send email notifications) looks like this:

[IPHost] ‘$MonitorName on $HostName’ – ‘$EventShortDescription’ $Duration

It provides enough information, but can result in rather long and obscure subject lines. In case you have several IPHost installations, you could have hard time determining what exactly event is notification related to. You can change the default subject line like this:

[Monitoring Network / $AgentName / $HostName] $MonitorName is now $NewState

where “Monitoring Network” is any unique string related to the network you are monitoring. The subject would show the hierarchy the monitor belongs to. If subject line differs from other typical monitoring events, it will be easier to pay attention to.

Note that one can assign a different notification for every monitoring event (see details in Alerting and Actions). By assigning a discernible subject line, important monitoring events can be easier to notice.

Use as few alerts as possible

One can set a different alert for every monitoring event (4 for entering/leaving Down state, same for Warning state, and, when applicable, an Event alert). In most situations there’s no need to use all the possible states and assign an alert sending mail to every one. While entering extended Warning/Down state may be quite an important monitoring event, typically entering Down/leaving Down may be enough for the majority of cases.

If all the monitoring events must be registered, it is advised to send them to, for example, time series database, to allow simpler visualization, but only send human-readable notifications to most important events.

That will reduce amount on superfluous notifications (which will, in turn, reduce possibility to miss an important alert in time).

Monitor the monitoring setup

If monitoring setup is ever going down, it should be noticed as soon as possible. The simplest solution is to set up a second IPHost installation within the same network, which will only monitor the availability of primary IPHost installation (for example, by monitoring its service’ port availability).

It is also advised to set up regular reporting and instruct it to send email summaries within time interval most convenient for notifications (for example, if you typically revise the general assets’ health starting from 10:00am, set reporting time to a time slightly after). If no typical notification is received, it will be noticed quicker.

Further options

The above pieces of advice can help to make alerts recognizable, easy to understand and scarce enough to provide timely alerts when necessary. They will also assist quicker detecting IPHost installation going down.

Do you have any other ideas on how to make monitoring setup more efficient? Feel free to either comment below or contact us directly.