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.
When you create an alerting condition (Alerts → Alerting policies → [your policy] → Create condition), the Alert metric field lists the metrics available for the selected resource type (Device or Pod). The metrics below are the ones you will find there.
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.
A recommended starting set
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_idso 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 steps
Now that you know what to monitor, learn how the platform can investigate and even remediate alerts for you with AI Alerting.