An alert watches one metric across a set of devices and opens an event when a reading crosses a limit you set, or when the data stops arriving. It is usually one alert per monitoring question rather than one per instrument.
Before you begin
Know which devices you are watching, which metric, and what the limit should be.
The limit has to come from your project's monitoring requirements or engineering criteria. BDI Cloud evaluates the condition you configure — it does not know what the appropriate limit for your structure is, and it cannot tell you that a number is too loose.
Basic information
Open Alerts for the project and choose Create alert.
Give it a name and, optionally, a description. Both appear when someone is looking at a triggered event, so write them for a person who did not build the alert. Set a Priority of high, normal or low, and use the Enabled toggle to control whether it evaluates at all.
Note: Priority is a label for the people reading the alert. It does not change how quickly the alert is evaluated or how it is delivered. Use it to help responders triage.
Devices and metric
Add the devices this alert covers, then choose the metric and the unit it is evaluated in.
One alert watches one metric across many devices, not a different metric per device. To watch temperature on six devices, that is one alert with six devices selected. To watch temperature and tilt, that is two alerts.
Check the unit. A threshold compared against the wrong unit produces an alert that either never fires or never stops.
Thresholds
A threshold is a label, a comparison operator, and a value. Add threshold opens a dialog to define one.
An alert can hold several, and any one of them matching triggers it. That is how you cover a high and a low limit in a single alert, or a warning level and an action level.
Thresholds carry a priority order, shown as #1, #2 and so on, which you set by dragging rows. Order them so the most severe reads first — it is what tells a responder which limit was crossed when several could have been.
Label every threshold. "High temperature" is considerably more use to someone at 2am than an unnamed row.
Check it against real data before saving
The threshold dialog includes a Threshold Preview that draws your threshold against the device's actual history, over a period you choose.
Use it. It answers the question that otherwise takes a week to answer: is this limit going to fire constantly, or never? A threshold sitting far above every reading in the past month is probably too loose; one the data crosses daily will train people to ignore it.
How many devices have to breach
By default a single device crossing a threshold triggers the alert. Require all devices changes that, so every selected device must meet a threshold before it fires.
Requiring all of them is much less sensitive and worth using deliberately. It suits a case where one instrument moving is noise but the whole array moving is real. It is the wrong choice if any single instrument crossing its limit matters, which is the more common situation.
Connection status
Connection status triggers the alert when no data has arrived for a chosen duration — ten minutes through to a day, or a custom period. It is disabled by default.
Set it. This is the most commonly skipped setting and it catches the failure nobody notices: an instrument that stopped reporting does not breach anything, so without it the alert stays quiet while the site goes unmonitored.
Choose a duration comfortably longer than the connection's polling interval, so an ordinary gap does not trip it.
An alert can be configured with connection status alone and no thresholds at all. That is a reasonable thing to build for an instrument you want to know about the moment it goes silent, regardless of what it reads.
Who hears about it
Share alert controls who has access to the alert and who receives email about it, with a per-person toggle for notifications.
The Unsubscribe control at the top of the alert affects only you. Use it to stop receiving email about an alert that is not yours to action, without changing anything for anyone else.
After saving
Check the alert against a period you already understand. The threshold preview does most of this, but if you know the metric reached a certain value last week, confirm the threshold you set would have caught it.
An alert built on a Virtual Device deserves extra care, because a valid expression fed the wrong input produces a threshold that is quietly meaningless. Verify the Virtual Device output before you alert on it.
Comments
0 comments
Article is closed for comments.