An observability blueprint for industrial IoT: lightweight edge collection, PLC and gateway log ingestion, multi-plant aggregation with isolation, resumable uploads over flaky networks, and equipment-anomaly alerting.
Industrial IoT observability differs from internet observability in a few ways: the equipment is heterogeneous — PLCs, gateways, CNCs, and sensors each speak their own protocol and produce non-standard log formats; the network is poor, with plant intranets that are bandwidth-limited and jittery, so you can't push data as freely as in a datacenter; and plants are scattered, meaning data from multiple sites and lines must converge into one platform while staying isolated and permission-scoped. The design has to bend around those three constraints.
In industrial settings the baseline is to collect and preprocess at the edge, then upload to the center. OBSERVE provides a lightweight Agent tuned for ARM industrial PCs and gateways, holding memory in the low hundreds of MB so it runs on modest edge hardware.
The edge Agent has three jobs: first, speak device protocols (Modbus, OPC UA, MQTT) and translate device data into standard logs and metrics; second, preprocess locally — aggregate, filter, and redact high-frequency raw data so only the valuable part goes upstream, saving bandwidth; third, buffer locally, spooling data to disk during outages and backfilling after recovery.
Device logs come in every shape, so ingest them in layers:
The key is preserving device-native fields like "alarm code" as enums so you can later aggregate failure distribution by code. Don't translate alarm codes into human text at the collector — keep the raw code and map it on the platform side (e.g. E23 → spindle over-temperature), so alert messages carry human-readable meaning while the raw code stays queryable.
Data from multiple plants under one group lands in one platform, but plants — and even workshops within a plant — must be isolated. OBSERVE reuses its tenant+project model: one plant or base maps to one tenant, and workshops/lines map to projects within it. Data is routed at write time by site and line labels, and the auth layer enforces that Plant A can't see Plant B's data.
On the network side, each plant runs an edge aggregation node that uploads to group HQ over a private link or encrypted tunnel, keeping data off the public internet. Permissions give group HQ a global view while each plant sees only its own, and on-call alerts are dispatched per plant.
Plant networks jitter constantly, so the design must tolerate disconnects. OBSERVE's edge Agent has built-in resume: during an outage data spools to local disk (rolling by size and age), and after recovery it continues uploading from the checkpoint — no loss, no duplication. The central side deduplicates idempotently so backfills don't re-insert records.
Decide a few parameters up front: the local buffer cap (say 24 hours or 20GB), a bandwidth ceiling for backfills (so catch-up doesn't crush normal business traffic), and a heartbeat timeout alert (page if an edge Agent goes silent for N minutes). One easily missed detail: keep edge devices on NTP. If clocks drift across plants, the merged data's ordering falls apart and both alerting and search go wrong with it.
Equipment alerting differs from software alerting: it leans on thresholds and state transitions. Typical patterns:
Alerts must reach a specific person: dispatch by plant and line, and include device ID, alarm code, and line in the notification so the on-call engineer knows which machine to walk to without opening another system.
Industrial projects run long and touch many parties, so go step by step: pilot on one line or workshop, getting edge collection, device ingest, and alerting working, then run 2-4 weeks to prove stability; replicate horizontally to other lines; finally wire up the group dashboard and unified ops. Accept each step with a collect → search → alert → review loop rather than opening everywhere at once.