WebSitePulse - How to Configure Alert Dependencies

Monitoring locations

Service updates

Support > How To > Configure Alert Dependencies

Configure Alert Dependencies

The main purpose of setting dependencies is to avoid unnecessary alerts for targets when they depend from each other.

For example: if you monitor a router and a web server that is connected to the Internet through this router, and the router fails, it's obvious that the web server will be inaccessible from outside the router, which is equal to a failure. In this case, you can create a rule that when the web server is on error, no alert will be sent if at the same time your router is on error too. If this rule is in place, each time the system detects an error with your web server, it will check the status of your router, and if the router is on error, no alert will be sent for the web server. You will be notified for the error of the router and obviously all systems behind this router will be unreachable.

It is very easy to create dependency rules if you can clearly define your goal. To help you understand how the system works here is a detailed description.

How the dependency rules work:

To illustrate how the dependency rules work we will take a look at one simple example. Let's suppose that our rule explanation looks like this:

"If all ports on HOST A show status Failure and message type is 'Target Failure' then don't send failure alerts on HOST B - SSH".

So lets see how the WebSitePulse monitoring agent will interpret this rule. First of all this dependency rule will be checked when the monitoring agent checks your target "HOST B - SSH" and detects a failure on it. After it detects a failure, it will then check the statuses of the ports of "HOST A" (note that here the agent will get their last statuses from the logs table, and will not check them in this moment). If all ports of this HOST A are down (e.g. Failure), than it will check what message must be send for the HOST B - SSH. If the message that should be send is a "failure", then no alert will be send, because our rule reads "… and message type is 'Target Failure' then don't send failure alerts on HOST B - SSH". Otherwise if the message must notify you about something else, like recovery or failure repeated, than message will be sent, because our rule doesn't include these cases.

Now let's take a quick look at the dependency rules elements:

Dependency label
The label is a short friendly name for this dependency rule, which will be used to identify it. It will be used for reference in the dependency section, dependency alerts and control panel.

Alert type
This is the type of the alert that should be sent when this rule is checked. See example above.

If
The IF condition can contain the following values: "All Targets", "All Targets of a specific type" and "One specific target".

on host
This field can contain only values: "All hosts" or a specific host of your targets.

show status
This field can contain either "OK" or "Failure" values. Please note that all statuses different from "OK" are considered as Failure (example: "Connection Time Out", "No route to host", etc.).

then
This one contains the action part of the rule. It can be: "Don't send failure alerts", "Send dependency alert" and "Continue as usual".

Let's look what different actions mean:
"Don't send failure alerts" - will not send alerts to the notification contact that is configured to receive alerts for the target.

"Send dependency alert" - will send dependency alert to the notification contact that is configured to receive alerts for the target saying that this rule is induced. The text of this message cannot be customized like the text of the other messages (for failures, recovers, etc.).

"Continue as usual" - will send messages as usual to the notification contact that is configured to receive alerts for the target. This option is widely used when you configure more than one rule, and has no effect if you have only one rule defined.

Most common scenarios

Scenario 1: I don't want to receive separate alerts for every single target on HOST A if the whole server is down.
Solution: This goal can be done with two rules. They are:

1. If at least one target on host HOST A shows status Failure then don't send alerts.
2. If all targets on host HOST A show status Failure then Send dependency alert.

The first disables the alerts if a target on this host is already down. The second activates a dependency alert when all targets on the selected host are down. You will receive one alert when the first target fails and another one when all targets are down. Both rules should be added for all targets on the selected host.

Scenario 2: I want to receive only one recovery message when multiple targets on my HOST A are recovering after a failure.
Solution: You have to define two rules with message type "Target Recovered" for all targets on the selected host. These rules will read:

1. "If at least one target on host HOST A show status Failure and message type is Target Recovered then don't send alerts."
2. "If all targets on host HOST A show status OK and message type is Target Recovered then Send dependency alert on HOST A."

The same example can be done as well for message type "Target Failure".

Scenario 3: I have one ROUTER (monitored with PING), and one WEBSERVER, monitored at HTTP. The WEBSERVER is behind the ROUTER, so if the ROUTER fails, I want to alert only ROUTER system administrator (but not WEBSERVER webmaster - it's clearly that the WEBSERVER is inaccessible and the problem is with the ROUTER).
Solution: First you have to make sure that you have at least 2 different notification contacts - CONTACT A that is alerted for the ROUTER, and CONTACT B that is alerted for the WEBSERVER. Then you have to define the dependency rule:

"If ROUTER - PING on host ROUTER show status Failure then Don't send failure alerts on WEBSERVER."

Note the bold one in the rule above. This means that this rule must be defined for WEBSERVER, not for the ROUTER.