What device monitoring on constrained hardware actually needs

Monitoring a server is a solved problem with a hundred tools. Monitoring a terminal on a wall in a school corridor, on a 4G connection that comes and goes, is a different question, and most of the answers borrowed from server monitoring are wrong.

"Online" is not a useful field

A boolean saying a device is online is true for exactly as long as it takes to become a lie. Connectivity on a constrained device is intermittent by design: it sleeps, the network drops, a building's uplink is saturated at the start of the day.

What a dashboard needs instead is last seen, with a timestamp, and a rule about what a gap means for that device class. A terminal that reports every five minutes and has been quiet for six is fine. Quiet for two hours is a visit.

The five signals worth carrying

Every extra field is bandwidth on a metered connection and a column that has to be stored forever, so the list stays short.

• Last activity, as a timestamp, plus what the device believes the time is.
• Queue depth: how many events are waiting to be sent. This is the single best predictor of a device in trouble.
• Memory and storage headroom, as a trend rather than a reading.
• Temperature, because an enclosure on a sunny wall behaves differently in July.
• Connectivity type and signal quality, so a pattern of failures can be attributed.

Queue depth is the one that matters

A device with a growing outbound queue is a device whose events are not arriving. It may be perfectly healthy in every other respect. Alerting on queue depth catches an expired credential, a certificate rotation nobody told the fleet about, and a backend rejecting a payload after a schema change, none of which look like a device fault.

Every event needs an identifier

A terminal that has been offline replays what it queued. Without an identifier generated on the device, a retry becomes a second arrival, and an attendance record that says a student entered twice is worse than one that says nothing.

The identifier costs a few bytes per event and removes an entire class of reconciliation work later.

Report state, do not command it

It is tempting to have the platform hold the truth about a device and push configuration at it. In practice the device is the only thing that knows what it is currently running, so it reports its own configuration version and the platform reconciles. The dashboard then shows what is actually deployed rather than what was intended, and those two are not the same thing.