Skip to main content

KALLO Alerting

How to set up alerting on the Ranlytics Dashboard, received via email or webhook.

Updated over 2 weeks ago

Configuring Alerts

Alerts are either configured per site or per device, created and edited on the RanMonitor Sites page or RanMonitor Workbench page of each KALLO respectively.

Site-by-site alerts.

Device-by-device alerts.

Types of Alerting

There are currently 3 types of alerts available to users: Device Events, Cell Metrics, and Throughput Metrics. While Device Events alerts are device-wide, Cell Metrics and Throughput Metrics alerts are configured per operator, technology, and band.

Device Events

The 'Device Event' metric type is currently limited to alarming on battery state change per KALLO only. This will trigger an alert whenever a KALLO gains or loses external power from its PoE input.

Cell Metrics

The 'Cell Metric' metric type encompasses Rate of Change, Threshold, and State Change alerts for RSCP, Ec/No, PSC, RSRQ, RSRP, SINR, PCI, and Signal.

Throughput Metrics

The 'Throughput Metric' metric type is currently limited to threshold alerts on download/upload throughput rate, data downloaded/uploaded per test, latency, and Jitter (download).

Alert Types

Rate of Change

Cell Metrics only. Allows you to set alerts based on a change in a metric reading by an absolute value. For instance, the alert below will alert upon a change in RSRP by Β±20dBm averaged across 5 consecutive metrics. This alert type will always alert upon an absolute change in either direction.

Threshold

Throughput Metrics and Cell Metrics only. Allows you to set alerts upon metrics falling above or below a specified value. For instance, the alert below will alert upon RSRP falling below -105dBm averaged across 5 consecutive metrics.

State Change

Device Metrics and Cell Metrics only. Allows you to set alerts upon the change of a specified status. For instance, the alert below will alert on any changes in PCI that persist across 3 consecutive metrics.

Batch Size / Consecutive Metric Count

Users are able to customise alert sensitivity through the "Batch Size" and "Consecutive Metric Count" fields. Both fields determine the number of consecutive metrics that are taken into account for the defined alert condition to fire. Rate of Change and Threshold alerts, utilising the "Batch Size" field, alert upon the average metric value across the defined number of metrics. In contrast, State Change alerts, utilising the "Consecutive Metric Count" field, alert upon a change of state that persists among the defined number of metrics.

Metric Counts and Time

As the KALLO conducts each configured network test in series, the number of configured tests corresponds to the frequency that each test occurs. For instance, a KALLO configured to 5 network tests will repeat each test roughly once every 50 seconds, whereas a KALLO configured to 30 network tests will repeat each test roughly every 5 minutes. Alongside this, to ensure accurate metric capture, the KALLO repeats failed tests up to 2 additional times before reporting "no signal". Please see below some rough guidelines surrounding time taken per configured task:

Task Type

Time Taken

Successful Cellular Passive Test

5 - 10s

Failed Cellular P25 Passive Test

30 - 40s

Throughput Test

10 - 15s

Lastly, please note that the KALLO batch-reports metrics once every 15 minutes.

Receiving Alerts

Alerts can be configured to be sent to any number of registered users' emails upon creation and are available through a webhook. Email alerts are batched and sent 15 minutes after the initial trigger, notifying users about all alerts triggered during that 15-minute window in one email.

Email Alert Notifications

Email alert notifications can be sent out to any number of emails actively registered to the Ranlytics Dashboard. These emails differ slightly between device-by-device alerts and site-by-site alerts, but both contain location / site details and the number of alerts generated.

Webhook Alert Structure

Webhook alerts are delivered via POST and ignore the batching logic described above. Each payload is sent immediately upon an alert trigger and follows the structure below:

{
"id": "",
"type": "",
"created_at": "",
"data": {
"failed_at": "",
"name": "",
"value": ,
"site_id": ,
"site_name": "",
"subsite_id": ,
"subsite_name": "",
"location_id": ,
"location_name": "",
"device_id": ,
"device_serial_number": "",
}
}

Field Name

Field Type

Explanation

id

String

Unique identifier for the webhook event.

type

String

Type of webhook event.

created_at

Timestampz

Time the webhook event was created (UTC) upon being processed by the RanDPS.

data

Data entry

Contains all below fields.

failed_at

Timestampz

Time the alert was triggered on the KALLO (UTC).

name

String

Name of the alert triggered.

value

String / Number / Boolean

Value of the event. Will be a different type depending on the alert type.

site_id

Number

Unique identifier of the site the KALLO is installed in.

site_name

String

Name of the site the KALLO is installed in.

subsite_id

Number

Unique identifier of the subsite the KALLO is installed in.

subsite_name

String

Name of the subsite the KALLO is installed in.

location_id

Number

Unique identifier of the location the KALLO is installed in.

location_name

String

Name of the location the KALLO is installed in.

device_id

Number

KALLO unique device identifier

device_serial_number

String

KALLO serial number, formatted as "KA-E20-#####"

Did this answer your question?