¶ Alerting management
¶ Alerting group
The alerting mechanism is based on the notion of group.
When creating/updating a group, it is possible to declare it as an alerting one.
A gateway can only belong to one alerting group at a time.
¶ Alerting configuration
Configuring the alerts is done at group level, i.e. the configuration applies to all the gateways in the alerting group.
To configure the alerts, you need to go to the ''Group overview'' page and select ''ALERTING'' from the header menu.
For each alert type, it is possible to:
- Activate/deactivate the alert
- Use default configuration (recommended), or custom it
¶ Description of alert types
¶ Disconnection
The Disconnection alert is:
- Triggered when the gateway has stopped receiving telemetry messages for more than 3h
- Automatically closed when the gateway has successfully reconnected and is receiving telemetry messages again
¶ Backhaul consumption
The Backhaul consumption alert is:
- Triggered when the backhaul consumption forecasted for the current month exceeds the predefined limit (configurable from 50 to 5000 Mbytes, 400 Mb by default)
- Automatically closed when the backhaul consumption forecasted for the month comes back within the limit
The global consumption is estimated until the reset day (configurable from 1 to 28), independently for each type of backhaul used (Ethernet, WiFi or Cellular).
¶ LoRaWAN Uplink traffic
¶ LoRaWAN uplink disruption
The LoRaWAN uplink disruption alert is:
- Triggered when the gateway has not receive any valid LoRaWAN messages for a certain period of time
- Automatically closed when valid LoRaWAN messages have been received again during the last monitoring window
The monitoring window is configurable from 3 hours to 7 days (24h by default).
¶ LoRaWAN uplink trend change
The LoRaWAN uplink trend change alert is:
- Triggered when a significant downward trend is detected on the number of valid LoRaWAN messages received, based on the last 30 days behavior
- Automatically closed when the trend on the number of valid LoRaWAN messages received is stabilized
Configuring the sensitivity mode (normal or low) allows to adjust the detection threshold.
¶ LoRaWAN CRC error rate trend change
The LoRaWAN CRC error rate trend change alert is:
- Triggered when a significant upward trend is detected on CRC error rate for one or more frequencies, based on the last 30 days behavior
- Automatically closed when the trend on CRC error rate on all detected frequencies is stabilized
Configuring the sensitivity mode (normal or low) allows to adjust the detection threshold.
The frequencies involved in trigerring this alert are listed in the reason field of the alert details.
¶ Monitoring of alerts
¶ Alerting dashboard
An Alerting dashboard is accessible by selecting ''Alerts'' from the left menu, it allows to:
- List the alerts of an alerting group, with filtering options
- Acknowledge an alert
After clicking on an eye link in the ''Alerts'' table, you will be redirected to the ''Alert details'' page. \
This page lists all the events (including the associated reason) related to the alert, from its triggering until closing.
Example for Disconnection alert:
Example for Backhaul consumption alert:
Example for LoRaWAN CRC error rate trend change alert:
¶ Group overview
The global information about alerts of an alerting group are displayed in its overview:
- Number of alerts currently active
- Graph with evolution of the number of alerts opened daily, over the last 30 days
¶ Gateway overview
The list of alerts currently active on a specific gateway are displayed in its overview.
¶ Notification by Webhook
You have the possibility to be notified of alerts on your gateways by configuring a Webhook as an alert destination to receive associated events.
The notification applies to all the gateways in the alerting group.
All the events (opening, updating, closing) related to each alert trigerred are published.
¶ Webhook configuration settings
The following parameters are configurable:
- Enable/disable the notification
- URL where you want to receive the alert events (mandatory)
- Security: None (default), mTLS, Basic Authentication
You also have the possibility to add several Custom Headers in the list, with the following parameters for each one:
- Key (mandatory)
- Value (mandatory)
When a Custom Header has already been configured, it is possible to update it or remove it from the list.
The following parameters are associated to the mTLS security option:
- Certificate (mandatory)
- Key (mandatory)
- CA certiticate
The following parameters are associated to the Basic Authentication security option:
- Username & Password (mandatory)
¶ Format of alert event
Each alert event is sent as an HTTP POST command with a JSON-encoded payload.
//Examples for opening, updating and closing a LoRaWAN uplink disruption alert://
