How does the scheduling for sensor requests work in IPCheck Server Monitor?

This article explains how the scheduler of IPCheck handles the scheduling of sensor requests.

Standard behaviour

After a (re)start of the IPCheck service all sensors are scanned once. To avoid huge network loads by many parallel requests (that might influence the measurement results) the initial scans of all sensors are stretched out over a few minutes. From there on IPCheck tries to monitor each sensor with its sensor interval.

Error behaviour

• One scan succeeds with OK
  • The sensor state changes to OK
  • The next scan is performed after about one sensor interval
• One scan fails with WARNING
  • IPCheck sets the state to WARNING
  • The next scan is performed after about one sensor interval expires or after the WARNING latency expires (whichever comes first)
• One scan fails with ERROR
  • IPCheck sets the state to WARNING
  • IPCheck immediately sends out another request
  • If this second scan is OK
    • The sensor state changes to OK
    • The next scan is performed after about one sensor interval
  • If this second scan fails with ERROR also
    • The sensor state changes to ERROR
    • The next scan is performed after about one sensor interval expires or after the DOWN latency expires (whichever comes first)
  • If this second scan fails with WARNING
    • The sensor state changes to WARNING
    • The next scan is performed after about one sensor interval expires or after the WARNING latency expires (whichever comes first)

Whenever the list above mentions a "sensor state changes to XXX" a notification may be sent if configured and if dependencies, latencies, and schedules allow it.