In some circumstances, the machine may work not as well or expected, and this situation can be traced by the use of anomalies.
We can have different levels of anomalies:
- Major: the product is still working, but something wrong has happened that affects product health and could potentially cause a failure in the short term; a short term action is needed to avoid this risk.
- Minor: the product is still working but something wrong has happened that could potentially affect product health in the long term; there is no risk of short term failure, therefore a programmable action is enough to deal with this case.
An Anomaly is described by:
-
Name: the name of the anomaly (e.g. FAN_SLOWDOWN).
-
Title: the user-friendly name of the event (e.g. Fan running slow).
-
Description: the event description (e.g. The fan seems clogged or damaged).
-
Severity: WARNING for minor anomalies, and CRITICAL for major anomalies.
-
Category: hard coded to ANOMALY.
-
Active/Clear Conditions: the metric/property-based conditions used to activate/deactivate the event instance.
In case of property-based condition, you can use only properties of type DATE. -
Notification: custom notification messages to send when the event is activated or deactivated. By default, notification messages are sent by using the event title and description, but the notification messages can be redefined, if needed.
-
Troubleshooting: a set of remedies the user can follow to fix the problem by himself.
-
Options: a set of variables that can be used to let the user customize the thresholds for event triggering.
Creating an Anomaly
To add a new Anomaly event, you should:
- Enter the Events / Anomalies page.
- Select the Location or Thing Definitions tab, depending on where you want to create the event.
- In case of Thing Definition, select the Thing Definition to edit.
- Press the Add Event button.
- Provide the required information.
- Press the Save button and edit the additional information, if needed.
Editing an Anomaly
An Anomaly event is described by the following sections:
General
The main section describing the alert through these properties:
-
Name: specifies the name of the alert, it is a free value (e.g. TEMP WARNING).
-
Title: the alert shown title within the alert list.
-
Description: the text describing the occurred problem.
-
Severity: WARNING or CRITICAL.
-
Category: fixed to ANOMALY
By selecting the Limit the alert visibility depending on the user type checkbox, it is possible to profile the alert visibility to a specific set of User Types.
By selecting the Limit this event computation on a specific time period checkbox, it is possible to define a Start and End day of the year when the event can be activated.
Within the event Title, and Description it is possible to use placeholders to include information about the thing, the event, and measures.
Dashboard
- Event Template: the template used to display the event details in a dedicated dashboard.
Active Condition
This section allows defining when the event must be activated. An event is activated only when the active condition switches its state from false to true and remains true for at least 30 seconds. In addition, you can specify the Minimum Active Time the condition must remain true before activating the event.
The Manual activation checkbox allows specifying whether the event must be manually activated by using the Manual Alert Reporting widget. Once the event has been manually activated, it can be cleared automatically by using the Clear Condition or manually by using the Clear action within the Active Alert List widget.
Clear Condition
This section allows defining when the event must be cleared.
If unspecified, the negated active condition is used instead.
Alert Activation Notification
This section allows defining the alert notification messages to be notified in case the event has been activated.
Once the status of an event is changed, users are informed in real-time through a notification by using the enabled channels (web, email, mobile push).
Servitly automatically notifies the registered users having visibility on the occurred alert, and optionally it is also possible to notify external contacts (email, SMS).
Within the notification Title, Short Message, and Long Message it is possible to use placeholders to include information about the thing, the event, and measures.
Alert Clearing Notification
This section allows defining the alert notification messages to be notified in case the event has been cleared.
Once the status of an event is changed, users are informed in real-time through a notification by using the enabled channels (web, email, mobile push).
Servitly automatically notifies the registered users having visibility on the cleared alert, and optionally it is also possible to notify external contacts (email, SMS).
Within the notification Title, Short Message, and Long Message it is possible to use placeholders to include information about the thing, the event, and measures.
Notification Delay
You can specify the delay for executing the notification to the users; if the alert is automatically cleared before the notification delay, the notification is skipped.
Technical Description and Remedies
Here you can describe more technically the event that has occurred and which are the causes and impacts. Optionally, you can provide a set of remedies, the user can follow to fix the problem by itself.
Remedies are presented to the user through the Thing Troubleshooting widget.
Options
This section allows defining options to be used within the event definition and whose value can be redefined by the end-user within the page by suing the thing-options widget.
For more details, see the Options article.
Event Refactoring
In case you have wrongly defined an anomaly that should instead be a failure, you can convert the event by clicking the Convert to Failure button present in the page bottom.
Comments
0 comments
Please sign in to leave a comment.