The monitoring algorithm is based on a procedure occurring within the monitoring itself called cycling.

When monitoring is enabled from multiple monitoring agents (locations), by default, all locations attempt to successfully complete the monitoring task.  If successful, the device will wait until the frequency selected has passed, and one individual location will begin cycling the task. Once that location has completed the task successfully, the device will again wait for the specified frequency until the next location triggers the task. This cycling from one location to the next, at the specified frequency, will continue until a monitoring location detects an error.  When an error is detected (or the first time a device is run or updated) all monitoring locations will be triggered to perform the tasks unless you have disabled simultaneous checking (only available in the ServerView Platform and WebView Platform).

Before we move forward, let’s define the differences between monitoring session and monitoring cycle.

  • Monitoring session is an operation when we initiate monitoring at a single location.
  • Monitoring cycle includes all monitoring sessions at all selected locations.

Cycling has two modes:

  • simultaneous checking is enabled
  • simultaneous checking is disabled.

The selection of the cycling mode depends on the specifics of the monitoring device. The option for selecting the cycling mode, the Allow Simultaneous Checks option, is only available in ServerView Platform and WebView Platform in a device interface (Device > Edit page >Monitoring tab > Advanced Configuration).

Selecting No for the Allow Simultaneous Checks option prevents the monitoring agents from performing simultaneous checks from multiple agents at the same time on the exact device. The reason to avoid simultaneous checks is some applications cannot be accessed by two, or more, users (or monitoring agents) simultaneously.

How it works

When the simultaneous check is enabled (by default for all platforms)

Once a device has been set up Dotcom-Monitor initiates monitoring sessions from all configured (activated during device configuration) monitoring agents. A counter, equal to the monitoring frequency duration, starts after each most recently received monitoring response. As a result, a new session of monitoring starts exactly as specified by the monitoring frequency.

There can be two possible paths for the monitoring algorithm depending on the monitoring results of the initial monitoring session. The first path occurs when all monitoring agents report the same state (i.e. each monitoring session returns a “success” state, or an “error” state). In this path, Dotcom-Monitor moves forward in “Single-mode” when a single monitoring session occurs from the next monitoring agent.

The second path of the monitoring algorithm occurs if there is at least one response from a monitoring agent that is a state that differs from the states of the other monitoring agents. For example, in a situation where there are five active monitoring agents, four of them report a “success” state, one fails and reports back an “error” state. Dotcom-Monitor moves forward in a “Mixed-mode” and initiates monitoring sessions from all available monitoring agents simultaneously.

The following is fair for both “Single” and “Mixed” mode monitoring

Sometimes, monitoring agents become unavailable (“disabled” state) due to a wide range of possible reasons, or they can be still during the processing of the previous monitoring session (“in process” state). Agents in “disabled” and “in process” states are ignored during monitoring.

Each monitoring session sends back its state (so-called keep-alive messages) during the process of monitoring. The status of each monitoring session is tracked by the Dotcom-Monitor system. Dotcom-Monitor “marks” an agent in cases when more than five minutes (current value for “session in process timeout”) have passed since the last keep-alive message. If there is a marked agent at the moment when a new session should be initiated, then both agents will initiate a monitoring session.

When the simultaneous check is disabled (available in the ServerView Platform and WebView Platform)

Once a device has been set up Dotcom-Monitor initiates monitoring sessions from the first configured (activated during device configuration) monitoring agent. During the initial monitoring cycle (the first cycle after the device has been created or unpostponed), new sessions are created immediately after receiving the completion of previous ones. In order to provide continuous monitoring, despite possible monitoring agent issues, when it may go offline, counter, equal to 5 minutes, starts on each new session. This counter specifies a time point when the next session should be initiated (in case the previous session hangs up at some stage).

If there is still any unfinished monitoring session at the moment when the time is up, session initiation delays on the same principle (current time + 5 min). After initial monitoring cycle is completed (each selected monitoring agent returned the response, or its downstate was confirmed) Dotcom-Monitor waits for a time that equals to the monitoring frequency duration and then analyzes the group of responses.

As in the “simultaneous check is enabled” mode, there can be two possible paths for the monitoring algorithm depending on the monitoring results of the initial monitoring session. The first path occurs when all monitoring agents report the same state. In this path, Dotcom-Monitor continues to initiate new monitoring sessions one by one at regular intervals which are equal monitoring frequency. In the second case, it switches to the session by session monitoring, excluding monitoring frequency value, like during the initial monitoring cycle.