Alerts

An alert is a user-defined response to some event or custom condition. Alerts immediately notify your app’s online users and system administrators when something goes wrong. They also deliver custom messages via email, SMS, instant messengers, and third-party systems.

Each alert comprises triggers, notification and escalation rules, as well as automatic and interactive corrective actions. A single alert may analyze status and receive events from one to many thousand sources. Once an alert is raised, an instance event is created and routed via platform’s event flow. Alert instance’s lifecycle may also assume that it remains active until it’s acknowledged by a human or a custom deactivation condition it met.

Alerts are raised by triggers (alert conditions). A trigger can be an event, a state or a change of state of a system component/hardware device. See the triggers section for details.

When an alert is raised, the system responds to it:

• The alert owner may be immediately notified, if he is connected to the server. He may also be prompted to acknowledge the alert.

• E-mail messages and other notifications may be sent to the alert owner, to a system user (s) or to a custom destination(s).

• The alert may be stored in the event history as a usual event.

• Some corrective actions may be executed, in interactive or non-interactive mode.

• The alert may change its state.

Every user has their own set of alerts.

Two contexts are used to administer alerts: One is the general Alerts context, which serves as a container. The other is the Alert context, which holds the information for one alert.

Alerts are activated by triggers. Every alert may have several triggers associated with it. Each trigger defines a condition in which the alert should be raised. Each trigger may check one or more devices or resources, e.g. all devices in a group. Combined with the ability to set up multiple triggers per alert, this allows very flexible setup. There are two types of triggers, described below:

• Event Triggers

• Variable Triggers

Trigger: an act that sets in motion some course of events.

Each alert may define zero or more triggers of every type. If no triggers are defined, the alert is never raised. If several triggers are defined, they act separately -- each trigger may raise the alert (they don't all have to exist at the same time -- just one is enough to raise the alert).

Event trigger is raised when an event of a certain type conforms to the trigger condition. This condition is flexibly configured by an expression, allowing complex checking. For example, a vehicle monitoring system may generate an alert if the impact event received from a vehicle controller indicates that impact strength exceeds a threshold.

Event triggers have support for event correlation, allowing an alert to be activated by the event of one type and deactivated by the event of another type (correlated event).

Any event trigger may be configured to activate only if more than N matching events were raised within a certain time frame.

State trigger can either be raised in response to a certain state, or to any change in the state of whatever is being monitored. State trigger periodically checks a certain variable's value (also pointed by a custom expression).

State triggers have configurable hysteresis (deadband) time for activating the alert only if the condition lasts longer than a certain time. For example, a state trigger may raise an alert if the temperature rises over 120 degrees for more than 3 minutes. Separate rearming hysteresis is also supported.

Plus, state triggers support value flapping (frequent change) detection that is reported as a separate alert type.

When an alert is raised by one of its triggers, Iotellect Server starts sending notifications and executing corrective actions.

Alert notifications inform operators about alert conditions and provide related information. Notification types include:

• Popup messages to the operator (may also prompt for acknowledgement)

• Custom sounds

• E-mail notifications. Alerts may be acknowledged by replying to notification mails

• SMS notifications

• Any other notification delivery methods, such as sending a Skype message via an external application

In addition, alert's corrective actions may implement any other notification schemes.

Alert state indicates current severity of the alert. It involves several factors, such as availability of pending alert instances, trigger activity, and escalation rules.

See Alert States for details.

Once raised, an alert may remain active while its causing condition is in force or until an event correlated to the activation event is received. The server keeps global active alert list and tracks active instances associated with every resource and device. Active alerts with high priority are usually visualized on system overview dashboards.

Device Offline alert is built into Iotellect Server basic distribution package. It is raised when any Data Terminal is disconnected from the server for longer than 10 minutes.

According to its Variable Triggers, this alert is triggered only for Devices whose Enable Offline Alert setting is active.

Device Offline alert is owned by default administrator.

Failover alert is raised once the Master Node of Iotellect Server failover cluster fails and control is taken by a Failover node. An e-mail message is sent to the default administrator upon this alert.

Some examples of real-world alert configurations are provided in the Alert Examples section.

Was this page helpful?

Tell us more

Send

Thank you!