|Alerts are processed by the device agent. Alert definitions are provided to the agent on startup and cannot currently be modified once the agent is running. Alerts, Data Process and parameter functions will be further aligned in R3 as part of D041 Data Processing Management Service deliverable|
The focus of this capability is to allow operators to monitor the data on a device stream and receive events when abnormal conditions occur. Operators define an alert using one of the provided alert classes and setting the required parameters on that class such as the range of valid values for a specific variable in a sample. This alert definition is added to the device agent configuration and the alerts become active when the device begins to stream data.
When an alert is triggered, and alert event is published by the agent that includes information about the cause of the alert as well as the alert level (error or warning). One alert event is published when the alert is active (not a separate event for each subsequent trigger) and an alert event with a subtype of ALL_CLEAR is published when the alert is no longer active.
Alerts can be configured to effect the aggregate status of a device. When aggregate status is calculated for a device, alerts that have been configured to be included in the calculation of one of the four aggregate status categories are reviewed and the aggregate status is set to the highest alert level of that set (ok, warning or error).
It is possible to add additional alert classes as additional user requirements are defined.
The AgentInstance resource contains an alerts parameter that is a list of dictionaries, each dictionary contains the name/value pairs that define one alert. Alert definitions are validated on agent launch and then processed when each granule arrived. The agent will call the eval_alert method on each alert class which will process the granule and determine if the alert has been triggered. If the state of the alert instance changes, then an alert event is published. After all the alerts for this agent have been updated then the aggregate status of this device is updated if there has been a state change in any alert.
An interval alert monitors a single parameter on the stream and validates that each value for that parameter falls within a defined range. The range can be open ended and limit checks can be either inclusive or exclusive. When the value for the parameter is not in the valid range, an alert is set to active and an event is published to notify the user.
In the definition above an warning alert is defined for the 'port_current' parameter on the engineering stream. The alert defines that the port_current should be greater than 5.5. If the following sequence of values were passed thru this alert:This sequence will produce 5 alerts:
- All clear on 30,
- Warning on 5.5
- All clear on 15.1
- Warning on 3.3
- All clear on 15.0
The warning alert events that are published would include the value that caused the warning to occur and the all clear events would include the value that is again inside the valid range.
The definition above is again a warning alert defined for the 'port_current' parameter on the engineering stream. This time the alert defines that the port_current should be between the values of 10 and 20 to be valid. If the following sequence of values were passed thru this alert:
This sequence will produce 5 alerts:
- Warning on the 5.5
- All clear on 10.2,
- Warning on 23.3
- All clear on 17.5
- Warning on 8.8
The late data alert monitors gaps between the publication of granules by the device. If there is a delay between delivery of granules to the agent by the driver greater than the specified interval time then an alert is triggered. The late data alert monitors delivery of granules, not a specific parameter in the granule.
The definition above is a warning alert defined for the on the parsed data stream. The alert will check every three seconds to see if a new granule has arrived since the time of the last granule processed by the agent.
If the vector below was the set of deltas between granules delivered to the agent
This sequence will produce 6 events:
- All clear on the first check data.
- Warning during the first 10s delay.
- All clear during the 1s samples following the first 10s delay.
- Warning during the 2nd 10s delay.
- All clear during the 1s samples following the second 10s delay.
- Warning during the final 10s delay.
The OMS event alert monitors events that arrive in CI from the OMS system. OMS notifies CI of system updates or issues via events that are recieved be the service gateway and republished internally as OMSDeviceStatusEvents. This alert matches fields in the OMSDeviceStatusEvents to know if an addition alert event should be published.