Alert metrics and what to monitor

Let’s learn which metrics you can alert on with SPEKTRA Edge, and how to use them to keep an eye on remote devices without checking them by hand.

The Manage alerts page shows you how to build an alerting policy, using the Device connected metric as the example. This page focuses on the opposite question: which metric should you pick, and what each one is good for. Use it as a catalog when you create your own alerting conditions.

Why alert on more than “Device connected”

A device can stay connected and still be in trouble: a disk fills up, the CPU is pinned at 100%, a sensor overheats, an application stops responding, or a cellular link degrades to the point of dropping data. Connection status alone won’t tell you any of that.

By alerting on resource and health metrics, you get notified of these conditions before they turn into an outage, so you can act on a device that may be in a remote, hard-to-reach location.

Device metrics

These metrics describe the health of the device itself (resource type devices.edgelq.com/device).

Availability

Metric What it tells you Typical condition
Device connected Whether the device is online (1) or offline (0). Less than 1 for 5 minutes.
Uptime How long the device has been running since its last boot. A sudden drop signals an unexpected reboot.

A low Uptime value (for example, uptime resetting to near zero) is a good way to catch devices that are rebooting unexpectedly, even when they reconnect quickly enough that the connection alert never fires.

Compute

Metric What it tells you Typical condition
CPU utilization Percentage of CPU in use. Greater than 80% for 30 minutes.
CPU load (1m) 1-minute load average. Greater than the device’s core count for a sustained period.

Sustained high CPU is the classic sign of a runaway process or an application consuming more than expected. Use a duration (for example, 30 minutes) so that short, legitimate spikes don’t trigger noise.

Memory

Metric What it tells you Typical condition
Memory utilization Percentage of RAM in use. Greater than 90% for 15 minutes.
Memory used Bytes of RAM in use. Useful when you care about absolute headroom.

High memory utilization warns you before the device starts killing processes under memory pressure.

Storage

Metric What it tells you Typical condition
Disk utilization Percentage of disk space in use, per mount point. Greater than 85%.
Disk used Bytes of disk space in use. Useful for absolute thresholds.

A full disk is one of the most common causes of failed application deployments and stalled log forwarding. Alert early (for example, at 85%) to leave time to clean up. The disk metrics are reported per mount point, so you can tell whether it’s the system area, the data area, or an additional partition that is filling up.

Hardware sensors

Metric What it tells you Typical condition
Hardware temperature Temperature readings in °C, per chip/sensor. Greater than a safe limit for the hardware.
Fan speed Cooling fan RPM readings. A drop toward zero can indicate a failing fan.
Voltage Voltage rail readings. Out-of-range values indicate power problems.
Power Power consumption readings. Unusual draw can indicate a hardware fault.

Thermal alerts are especially valuable for fanless or enclosed devices deployed in environments where ambient temperature isn’t controlled.

Network interfaces

Metric What it tells you Typical condition
Bytes received / sent Throughput per interface. A drop to zero can mean a link is down; a spike can mean unexpected traffic.
Packets received / sent Packet rate per interface. Same as above, at packet granularity.
Incoming / outgoing drops Dropped or errored packets per interface. Greater than 0 over an interval signals a degraded link.

These are grouped per interface, so you can monitor a specific uplink (for example, the wired interface) independently from others.

Cellular signal

For devices with a cellular modem, these metrics help you catch a connection that is slowly degrading before it fails.

Metric What it tells you Typical condition
Modem RSSI Received signal strength. Less than a weak-signal threshold.
Modem RSRP Reference signal received power. Less than a weak-signal threshold.
Modem RSRQ Reference signal received quality. Less than a weak-signal threshold.
Modem SNR Signal-to-noise ratio. Less than a poor-quality threshold.

A device on a weakening cellular link may still report connected, but alerting on signal quality lets you schedule maintenance (for example, repositioning an antenna) before it goes offline.

Health checks

If you configure host-level health checks on a device, their results are also available as metrics.

Metric What it tells you Typical condition
Health check status Result of each configured check (1 healthy, 0 unhealthy). Less than 1.
Health check HTTP response time Response time of HTTP checks. Greater than an acceptable latency.
Health check network RTT Round-trip time of ICMP/network checks. Greater than an acceptable latency.

Health checks let you turn “is this specific service or endpoint reachable from the device” into an alert.

Application metrics

These metrics describe the applications (pods) running on your devices (resource type applications.edgelq.com/pod). Select Pod as the resource type when creating the alerting condition.

Metric What it tells you Typical condition
Pod CPU utilization CPU used by the application. Greater than an expected ceiling.
Pod memory utilization Memory used by the application. Greater than an expected ceiling.
Pod memory used Absolute memory used by the application. Useful for absolute thresholds.
Pod health Whether the application is healthy (1) or not (0). Less than 1.
Pod health check status Result of the application’s health checks. Less than 1.
Pod health check HTTP response time Response time of the application’s HTTP checks. Greater than an acceptable latency.
Pod health check network RTT Round-trip time of the application’s network checks. Greater than an acceptable latency.

These let you alert on the workload itself — for example, an application that is unhealthy or consuming far more CPU than usual — rather than only on the device hosting it.

If you’re not sure where to begin, these conditions cover the most common problems for a fleet of remote devices:

Condition Metric Suggested trigger
Device offline Device connected Less than 1 for 5 minutes
Disk filling up Disk utilization Greater than 85%
Memory pressure Memory utilization Greater than 90% for 15 minutes
CPU saturation CPU utilization Greater than 80% for 30 minutes
Overheating Hardware temperature Greater than the hardware’s safe limit
Application down Pod health Less than 1

Tips for fleet-wide alerts

  • Group by device. In the time series configuration, group by resource.labels.device_id so each device is evaluated independently and a single policy covers your whole fleet. See the time series configuration section on the alerts page for details on aligners and reducers.
  • Use a duration. Requiring a condition to hold for a few minutes filters out transient spikes and keeps notifications meaningful.
  • Attach notification channels. Connect Slack, email, or a webhook so alerts reach you wherever you work. See notification channels.
  • Let the platform tune thresholds for you. If picking exact thresholds is hard, consider AI Alerting, which adds anomaly detection and adaptive thresholds on top of these same metrics.

Next step

Now that you know what to monitor, learn how the platform can investigate and even remediate alerts for you with AI Alerting.