Module supervision
Capabilities
Capability |
Support |
Comment |
|---|---|---|
Monitoring the connection between modules and osp-configuration-dispatcher (heartbeat) |
|
The monitoring is done by polling and supervise only the state with the dispatcher see details. Warning most of the modules are supporting this feature see capabilities for the list. |
Get the started timestamp |
|
Warning most of the modules are supporting this feature see capabilities for the list. |
Get the module version |
|
This feature allowing to check if remote-module are running with out-of-date version. See capabilities for support and details for configuration |
Monitoring module state
The configuration dispatcher provides the current state of modules as Values. Those Values are automatically provided for every module and can be subscribed on. To do so, use the module id (i.e. modules.modbus.modbus-1 for example).
Those Values are of type TEXT and can have following content :
RUNNING : The module is running, this is the normal state for a module.
CONFIG_OUTDATED : A configuration mismatch was detected between the module and the
osp-configuration-dispatcher. When a module is in this state, theosp-configuration-dispatcherwill ask the module to restart and fetch its latest configuration. This typically happens after changing the module configuration.UNREACHABLE : The module did not send its heartbeat in time, so it is considered to be down. This will typically happen when a module restarts (after a CONFIG_OUTDATED for example), and in case of network or module failure. A module not sending heartbeats anymore will be detected as UNREACHABLE after at least 5 seconds and at most 10 seconds.
Note
If a module is down less than 5 seconds, it may not be reported as UNREACHABLE.
REMOVED : The module no longer exist. This typically happens when the module was removed (by a configurationchange) but subscriptions to its Value were done when it still existed.
Note
On configuration dispatcher startups, all modules are first seen as UNREACHABLE until they send their first heartbeat. This can happen when adding a new module, since the configuration dispatcher needs to be restarted in this case.
Monitoring version state
The version state can be exposed as a monitoring value. It provides visibility into the version currently running on each remote module. This information can be used to raise an alarm if a remote module is not aligned with the version deployed on the core system.
By supervising version consistency across modules, administrators can quickly detect mismatches, ensuring that the overall deployment remains stable and homogeneous.
Monitoring start timestamp state
The start timestamp of each module is exposed as a monitoring value at every restart. This timestamp represents the exact moment, in milliseconds since the epoch, when the module was initialized.
It is particularly useful for tracking module uptime, diagnosing unexpected restarts, and correlating events across distributed systems. By monitoring these values, it becomes easier to analyze system behavior over time and maintain operational reliability.