Posted iniiot

IoT Device Monitoring: Observability Architecture, Metrics & Fleet Management (2026)

No Comments
IoT Device Monitoring: Observability Architecture, Metrics & Fleet Management (2026)

IoT Device Monitoring: Observability Architecture, Metrics & Fleet Management (2026)

Last Updated: April 19, 2026

Managing thousands of remote devices requires visibility into device health, connectivity state, and performance in real time. This is IoT device monitoring—the cornerstone of fleet observability that prevents silent failures, detects anomalies before they cascade, and keeps production running. We’ll walk through observability architecture, metrics hierarchies, data pipelines, alerting patterns, and production scaling considerations for systems managing 100K+ devices.

TL;DR

IoT device monitoring combines telemetry collection (MQTT, HTTP), time-series storage (Prometheus, InfluxDB), and anomaly detection to observe fleet health. Core metrics span device-level (CPU, heartbeat), gateway-level (ingest throughput), and fleet-level (uptime, cost-per-device) layers. Alert routing ties detection to on-call workflows. Scaling to 100K+ devices requires broker architecture, compression, and intelligent retention policies.

Table of Contents

  1. What Is IoT Device Monitoring?
  2. Core Architecture: Data Pipeline
  3. Metrics Hierarchy: Device → Gateway → Fleet
  4. Observability Tooling Stack
  5. Anomaly Detection Techniques
  6. Alert Routing & On-Call Integration
  7. Scaling to 100K+ Devices
  8. Frequently Asked Questions
  9. Real-World Implications & Future Outlook
  10. References & Further Reading
  11. Related Posts

What Is IoT Device Monitoring?

IoT device monitoring is the continuous observation of remote device health, connectivity, and operational performance across a fleet. It answers: Is my device online? Is it sending data? Are sensors drifting? Is the gateway overloaded? Is power consumption normal? Monitoring differs from logging—it’s focused on metrics (numeric time-series) rather than events, enabling detection of gradual degradation and automated response before failure.

Key concepts:

  • Device Health: CPU usage, memory, disk I/O, temperature, power state.
  • Connectivity State: MQTT subscriptions active, HTTP uptime, packet loss, last heartbeat timestamp.
  • Anomaly Detection: Statistical deviation from baseline (e.g., sensor readings 3-sigma above normal).
  • OTA Status: Firmware version, update in-flight, rollback state.
  • Observability: The ability to understand system behavior from external outputs (metrics, logs, traces).

Core Architecture: Data Pipeline

IoT monitoring follows a standardized data flow: devices produce telemetry → ingestion layer queues it → time-series database stores it → dashboards query it → alerts route anomalies to humans.

Architecture setup and rationale:

The diagram below shows the end-to-end pipeline. Devices push metrics to an MQTT broker (or HTTP endpoint) for decoupling; edge gateways may pre-aggregate. An ingester (Telegraf, Kafka, or custom agent) reads from the broker and writes to a time-series database (TSDB) optimized for high-cardinality time-series. Dashboards (Grafana, Datadog) query the TSDB for visualization. An alert engine continuously evaluates rules and routes incidents to on-call systems.

IoT monitoring data pipeline: device to MQTT to ingester to TSDB to dashboard and alerting

Walkthrough of each component:

  1. Devices & Agents: Each device runs an agent (MQTT client, HTTP publisher, or embedded OMH-Sparkplug B agent). Agents collect local metrics and push telemetry either directly or through an edge gateway. Sparkplug B (MQTT variant) includes birth/death messages for liveness detection—when a device goes offline, the broker publishes a death message, triggering immediate alerts.

  2. Message Queue (MQTT): MQTT topic hierarchy mirrors device structure: factory/line1/machine42/temperature, factory/line1/machine42/energy_kw. QoS 1 (at-least-once) ensures no loss; QoS 2 adds overhead. High-concurrency brokers (Mosquitto cluster, AWS IoT Core, HiveMQ) handle 100K+ concurrent connections. Broker deduplication windows prevent duplicate metrics from network retries.

  3. Ingestion Layer: Telegraf (InfluxData), Kafka Connect, or a custom consumer reads from MQTT and transforms into metric format. Ingestion should include device metadata lookup (tags: factory, line, asset_class) to enrich metrics. Batching writes (100 metrics per request) reduces API calls.

  4. Time-Series Database: InfluxDB, Prometheus, or Thanos stores compressed time-series. InfluxDB Line Protocol packs timestamp, measurement name, tags, and field values efficiently. Retention policies auto-delete data older than 90 days (tunable per use-case). Cardinality limits prevent runaway growth from high-dimensionality device IDs.

  5. Querying & Dashboards: Grafana auto-discovers Prometheus/InfluxDB and builds panels with Flux or PromQL queries. Dashboards typically show device status grid (green=healthy, red=error), time-series for key metrics, and top anomalies.

  6. Alert Engine & Router: Prometheus AlertManager or custom rule engine evaluates conditions (e.g., device_cpu > 85% for 5 minutes), creates incidents, and routes via PagerDuty, Slack, or email.

Why not HTTP for every device?

MQTT scales better because it multiplexes many publishers over one connection (TCP) and supports QoS guarantees. HTTP requires a new connection per publish, causing connection churn. For constrained devices (e.g., battery-powered sensors), MQTT’s low overhead (2-byte fixed header vs HTTP’s headers) is critical.

Metrics Hierarchy: Device → Gateway → Fleet

Effective monitoring doesn’t collect every possible metric—it organizes them by aggregation level to reduce noise and cost.

Metrics hierarchy diagram showing rollup from device to fleet:

Metrics hierarchy flowing from device-level CPU and memory to gateway aggregate throughput to fleet uptime and cost KPIs

Device-level metrics (collected on device or gateway):
– device_cpu_usage_percent — CPU utilization (max over 60s window).
– device_memory_free_mb — Available RAM.
– device_packet_loss_percent — % of MQTT publishes not acknowledged (QoS 1+).
– device_last_heartbeat_seconds — Time since last successful metric publish (liveness).
– device_temperature_celsius — Sensor reading (example; domain-specific).

Gateway-level metrics (aggregated at edge):
– gateway_connected_devices — Count of devices online (from Sparkplug birth/death).
– gateway_ingest_throughput_msgs_per_sec — Metrics/second flowing into gateway.
– gateway_queue_depth_msgs — Buffered messages awaiting transmission (backpressure indicator).
– gateway_backend_latency_ms — Round-trip latency to TSDB.

Fleet-level KPIs (derived from device metrics):
– fleet_overall_uptime_percent — % of devices online in last 24 hours.
– fleet_anomalies_detected — Count of devices with 3-sigma deviations.
– fleet_device_churn_rate — Devices added/removed per day.
– fleet_cost_per_device — Storage + compute divided by device count.

Organizing metrics this way allows teams to set different alerting thresholds: a single device offline is not an alert, but 5% of the fleet offline is critical. Aggregating at the gateway reduces TSDB cardinality (one gateway_throughput metric vs. one per device).

Observability Tooling Stack

Production IoT monitoring uses either fully managed services or self-hosted stacks. Each has trade-offs: managed services scale easily but lock you into a vendor; self-hosted offers flexibility but requires DevOps expertise and maintenance.

Fully Managed Services:
– AWS IoT Core — MQTT broker + Rules Engine for transformation + CloudWatch integration. Built-in OTA support. ~$1–2 per device-month for small fleets; scales to millions. Rules Engine applies SQL-like queries to route messages before ingestion (reduces egress costs). Device Defender monitors device behavior for anomalies (e.g., unusual connection patterns).
– Datadog IoT Monitoring — MQTT ingestion, live anomaly detection (statistical + ML), and on-call integration. Cloud-only, premium pricing (~$500–5K/month depending on fleet size and metric cardinality). Unified dashboards share device data with APM/infrastructure monitoring.
– Azure IoT Hub — MQTT/AMQP broker, Device Twins for state sync, Azure Monitor for alerting. Native integration with Azure Stream Analytics for real-time processing (e.g., aggregate metrics on streaming pipeline before storage).

Self-Hosted Open Source Stack:
– MQTT: Mosquitto (single-node ~10K devices) or HiveMQ (clustered, scales to 1M+ devices). HiveMQ Bridge extensions enable geographic distribution (Europe/US brokers forward to central). Both support auth plugins (LDAP, OAuth2).
– Ingestion: Telegraf → InfluxDB (line-protocol native), or Kafka → InfluxDB (high-throughput pipeline). Telegraf includes 300+ input plugins (SNMP, Modbus, OPC-UA), simplifying protocol conversion.
– TSDB: InfluxDB OSS (line-protocol native, excellent for time-series, cost-effective) or Prometheus (pull-based, less ideal for push-heavy IoT but excellent for scraping gateway aggregates). Thanos adds long-term object storage (S3) to Prometheus.
– Streaming Analytics: Apache Kuiper (edge ML/rules on IoT gateway; processes 10K+ events/sec per edge node) or eKuiper (cloud version with state store).
– Dashboards: Grafana (supports 200+ data sources) + Prometheus AlertManager for alert routing + Alertmanager webhook to PagerDuty.
– Cost at 10K devices: ~$3–8K/month cloud infrastructure (3 Kubernetes nodes, InfluxDB Cloud tier 1, Grafana Cloud) + 1 FTE engineering for maintenance.

Real-world setup (100K device fleet):

Enterprise deployments often use hybrid: MQTT broker cluster (HiveMQ on Kubernetes, 5 nodes for redundancy, $15K/month), Kafka pipeline (3 brokers + 3 Zookeeper nodes, $8K/month) for high-cardinality metric buffering, InfluxDB Cloud (2 TB/month, $20K/month), Grafana Cloud ($5K/month), and PagerDuty for escalation ($800/month). This isolates concerns and allows independent scaling: MQTT cluster handles connection churn; Kafka absorbs metric bursts; InfluxDB compresses storage; Grafana caches queries. Total: ~$50K/month infrastructure + 2 FTE ops engineers.

Anomaly Detection Techniques

Simple threshold alerts (“alert if CPU > 80%”) fail in production because normal baselines vary by device type, time of day, and workload. A manufacturing line running overnight shift has different power consumption than day shift; a seasonal spike in summer temperature is normal, not anomalous. Production systems use statistical or ML-based detection to adapt to context.

Threshold-Based (Baseline + Bounds):
– Compute rolling 7-day median for each metric (e.g., median_cpu_7d = 45%).
– Define alert bounds as median ± 2σ (95% confidence interval). For CPU example: bounds = [25%, 65%].
– Trigger if metric exceeds bounds for 5+ consecutive minutes (reduce false positives from transient spikes).
– Example: temperature > (median_7d + 2*stddev_7d) for 5 minutes → alert "thermal runaway".
– Implementation: InfluxDB task (Flux) re-calculates bounds hourly; Prometheus recording rule updates baseline daily.
– Pro: Simple, interpretable, no labeled training data required. Works offline (no cloud call needed).
– Con: Doesn’t detect gradual drift (e.g., capacitor aging over weeks). Struggles with devices that have legitimately variable baselines (e.g., fleet vehicles with variable load).

Statistical (Isolation Forest, Z-Score):
– Isolation Forest unsupervised learning detects multivariate anomalies (e.g., “high CPU AND high memory AND high network latency together”—which is abnormal even if each metric individually is OK).
– Z-score: (value - mean) / stddev > 3 → anomaly (99.7% confidence).
– Apache Kuiper and custom Python scripts (scikit-learn, PyOD library) run on-device or gateway. Kuiper processes 10K+ events/sec per edge node with minimal latency.
– Pro: Catches complex patterns; works online (streaming, no 7-day history needed). Lightweight (runs on edge).
– Con: Requires retraining periodically (monthly if baseline shifts); false positives if data distribution shifts seasonally; assumes normally distributed metrics.

ML-Based (LSTM, Prophet):
– Facebook’s Prophet forecasts expected metric value (account for trend, seasonality, holidays); alert if actual deviates by >20% from forecast.
– LSTM autoencoders detect sequence anomalies (e.g., “device behaved differently for 10 consecutive minutes”—timestamp+value patterns).
– Datadog and Splunk embed these; enterprise customers use custom TensorFlow/PyTorch models trained on historical data.
– Use case example: Pump power consumption sequence [5kW, 5.1kW, 5.2kW, …] is normal; [5kW, 8kW, 9kW, 11kW] is abnormal (bearing friction increasing). LSTM catches the pattern; threshold detection would not.
– Pro: Captures temporal patterns; handles seasonality (e.g., manufacturing ramps on Monday mornings). Learns complex failure precursors.
– Con: High compute cost (GPU required for training); 30+ days of historical data needed to warm-start; model drift requires monthly retraining; hard to interpret (“why did the model flag this device?”).

Hybrid Approach (Production-Grade):

Organizations running 100K+ device fleets use layered detection:

  1. Fast path (tier 1): Threshold rules for critical hardware failures. Latency: <1s. Examples: device_offline for 2 min, temperature > 95°C, battery_voltage < 2.5V. Runs on gateway or cloud.

  2. Smart path (tier 2): Statistical baseline + bounds for gradual degradation detected within 24h. Latency: 5–10 minutes. Example: energy consumption creeping up over days (bearing wear, efficiency loss). Runs in cloud (sufficient data); alerts go to predictive maintenance team (lower priority than tier 1).

  3. Learning loop: Ops engineers mark false positives in Grafana; system tracks false positive rate per alert type. Alerts with >10% false positive rate are tuned (bounds widened or disabled seasonally). ML models retrain weekly on feedback.

  4. Feedback metrics: Track detection performance: precision (% of alerted anomalies that were real failures), recall (% of actual failures detected). Aim for >90% precision (avoid alert fatigue) and >70% recall (catch most issues).

Alert Routing & On-Call Integration

Detecting an anomaly is useless if it doesn’t reach the right person at the right time. Alert routing bridges the gap between detection and human action, with clear escalation policies, severity mapping, and runbook links embedded in notifications.

Alert routing workflow diagram:

Sequence: device sends metric, engine evaluates rule, router creates incident, routes to on-call team, notifies Slack, user reads runbook

Walkthrough:

  1. Alert Engine Evaluates: Prometheus AlertManager, Datadog, or custom engine continuously evaluates rules at configurable intervals (typically 30 seconds). Examples: device_offline for 2 minutes, cpu_temp > 95°C for 5 min, energy_consumption trending up for 7 days.

  2. Incident Created & Severity Mapped: Alert transitioned from PENDING → FIRING and mapped to severity tier (SEV0/SEV1 = customer-impacting, requires immediate response; SEV2 = service degraded; SEV3 = predictive/hygiene, can wait hours). Severity is often derived from device importance (e.g., production line controller is SEV1; environmental sensor is SEV3).

  3. Escalation Policy: Router queries on-call calendar (PagerDuty, Opsgenie, VictorOps) for currently scheduled primary and backups. Incident assigned to primary with alert immediately sent. If primary doesn’t acknowledge within SLA (typically 5–15 min depending on severity), router auto-escalates to backup. Example SLA: SEV1 ack in 5 min, SEV2 in 15 min, SEV3 in 4 hours.

  4. Multi-Channel Notification: Severity determines notification mode. SEV1: phone call + SMS + Slack + email. SEV2: Slack + email. SEV3: email + Slack digest. Notification includes: metric name, current value, threshold, device ID, fleet location, runbook link, and recent metric history (3-hour sparkline).

  5. Runbook Execution: Linked document (Notion, Confluence, or wiki) with diagnosis steps. Example for “device_offline” alert:
    – Check device last IP (device registry API)
    – Ping device via ICMP
    – SSH into edge gateway, check device logs
    – If stale metrics, restart device agent
    – If network issue, check gateway connectivity
    – Escalate to network team if persistent

  6. Feedback Loop & MTTR Tracking: Engineer resolves incident, marks resolved in PagerDuty. Platform records MTTR (mean time to recovery), time-to-acknowledge, and which runbook was used. Analytics dashboard shows: which alert types are most noisy (high false positive rate), which have longest MTTR (need better runbooks), which matter most (detect high-impact failures early).

Example PagerDuty integration (Alertmanager webhook):

alert_routing:
  rule: "fleet_devices_offline > 5%"
  service_id: "P123ABC"  # PagerDuty service
  severity_map:
    critical: "device_offline > 20%"     # cascading failure
    high: "device_offline 5-20%"         # significant fleet impact
    medium: "single_device_offline"       # isolated issue
    low: "predictive_alert"               # maintenance hint
  escalation_policy: "iiot-team-on-call"  # primary, then manager after 10 min
  notification_template: |
    Alert: {{ .Alert.Labels.alertname }}
    Device: {{ .Alert.Labels.device_id }}
    Value: {{ .Alert.Annotations.value }}
    Runbook: https://wiki.example.com/runbooks/{{ .Alert.Labels.alertname }}

Runbook discipline (critical): For every alert type, a runbook must exist and be kept up-to-date. Without runbooks, operators troubleshoot ad-hoc, losing context and wasting 30–60 minutes per incident. With runbooks: ~5 minute resolution. Best practice: every time an operator resolves an incident differently than the runbook, update the runbook. Quarterly: review alert types that never fire (disable them) and those that fire but are always false positives (tune thresholds or remove).

Scaling to 100K+ Devices

Scaling monitoring past 10K devices introduces bottlenecks at every layer. A single-node MQTT broker maxes out around 10K–50K concurrent clients depending on message rate; a single time-series database node struggles with >100M data points/hour. Here’s how production systems handle it without melting down.

MQTT Broker Clustering:
– Single Mosquitto instance: ~10K concurrent clients max (even on high-end hardware, CPU becomes the bottleneck processing QoS handshakes).
– HiveMQ or Mosquitto cluster (3–5 nodes load-balanced): 100K+ concurrent clients easily. Each node shares subscription state (Hazelcast or etcd). Devices reconnect to any node; messages route between nodes transparently.
– Bridge brokers: Deploy regional brokers in Europe, Asia, US. Each region handles local device connections; bridges forward to central broker for archival. Reduces latency (devices connect to nearby broker) and isolates regional outages.
– Connection limits: Set per-node limits (e.g., 20K/node in 5-node cluster = 100K total) to detect runaway device populations early.
– Cost: ~$2–5K/month self-hosted cluster (Kubernetes nodes + storage) or ~$1–3K/month with managed HiveMQ Cloud.

Metrics Cardinality Explosion (The Silent Killer):
– 100K devices × 10 metrics/device = 1M time-series.
– If each device has a unique ID label (device_id=abc123def456), and you add location, firmware_version, device_type, manufacturer tags, cardinality compounds: 1M × 5 dimensions = 5M+ time-series.
– Time-series databases enforce cardinality limits to prevent OOM crashes. Prometheus defaults to 1K series per metric; InfluxDB allows millions but becomes slow.
– Real-world failure: A fleet added a asset_class tag (100 values) + production_line tag (200 values) = 20K variants per metric × 50 metrics = 1M+ series. Query latency jumped from 200ms to 8 seconds. Storage doubled.
– Mitigation: Pre-aggregate at gateway (publish only sum/count/percentile, not per-device detail). Use controlled tag dimensions: device_id, location (factory/line, not building/floor/room), device_type (3–5 categories, not detailed model numbers). Keep tags ≤5 dimensions per metric.
– Cardinality budgeting: Allocate cardinality like compute: “1M series budget per TSDB node; at 100 tags per device × 10K devices = 1M series; we have 10 TSDB nodes, so max 10M series fleet-wide; enforce tag limits.”

Data Retention & Cost:
– Volume calculation: 100K devices × 10 metrics × 1 sample/minute × 30 days = 4.32 billion data points.
– Compressed size: Modern time-series databases compress ~80–90%. At 1 byte/point uncompressed, 4.3B points = 4.3 TB. Compressed = 430–860 GB.
– Retention policy: 30 days full 1-minute resolution (for alerting), 90 days 10-minute rollup (for trends), 1-year hourly (for capacity planning). Typical storage: 500 GB–1 TB for 100K devices.
– Storage cost: Cloud (InfluxDB Cloud tier 2): ~$1.5K/month. Self-hosted (S3 storage + Thanos sidecars): ~$200–400/month.
– Example retention rule: Automatically downsampled from 1-min to 10-min after 30 days, reducing storage 10x. After 90 days, downsample to 1-hour.

Latency & Query Performance (Dashboard Responsiveness):
– Latency growth pattern: Single TSDB node queries 1M series in ~200ms. At 10M series, same query takes 5+ seconds. At 50M series, 20+ seconds (unacceptable for dashboards).
– Bottlenecks:
– Metric name index lookup (millions of label combinations to scan)
– Disk I/O (reading from compressed blocks)
– Network (transferring large result sets to Grafana)
– Optimization strategies:
– Materialized views: Pre-compute common aggregations (fleet-level mean CPU, top 10 high-energy devices) every 5 minutes. Queries hit pre-computed data in <100ms instead of scanning raw data.
– Query caching (Redis): Cache query results for 5–10 minutes. Repeating “show me device fleet uptime for last 24h” hits cache, not TSDB.
– Downsampling for long ranges: Queries for 1-year range use 1-hour-resolution data (8,760 points) instead of 1-min (525,600 points), reducing data transfer 60x.
– Horizontal read scaling: Deploy InfluxDB replication (standby nodes) or Thanos (federated queries across multiple TSDB instances). Grafana distributes queries across nodes.
– SLA targets: 95th percentile latency <2s for dashboards (tolerable), <100ms for alert engine (must be fast).
– Real-world setup: Queries against 100K device fleet should take 500–1500ms if well-indexed. If >5s, partition data by location or device type.

Example InfluxDB 2.0 Retention & Downsampling Policy for 100K Fleet:

// Raw metrics: keep 30 days, full 1-minute resolution
option task = {name: "raw-30d-retention", every: 24h}
from(bucket: "iot-raw")
  |> range(start: -31d)
  |> filter(fn: (r) => r._time < now() - 30d)
  |> to(bucket: "iot-deleted")  // move to cheaper archive

// Hourly rollup: keep 1 year for trending
option task = {name: "hourly-rollup", every: 1h}
from(bucket: "iot-raw")
  |> range(start: -2h)
  |> aggregateWindow(every: 1h, fn: mean, createEmpty: false)
  |> to(bucket: "iot-hourly")

// Daily rollup: 3-year archive (capacity planning)
option task = {name: "daily-rollup", every: 24h}
from(bucket: "iot-hourly")
  |> range(start: -2d)
  |> aggregateWindow(every: 24h, fn: mean, createEmpty: false)
  |> to(bucket: "iot-daily-archive")

This setup keeps raw data small (30 days of 100K devices = ~500 GB), provides trend data (hourly for 1 year), and long-term archive (daily for capacity planning).

Frequently Asked Questions

Q: Do I need real-time metrics or can I batch every 5 minutes?

A: Depends on use-case. For early anomaly detection (e.g., runaway temperature), real-time (1-minute window) is critical. For cost optimization, 5–10 minute batches suffice. Hybrid: real-time to edge gateway for local alerting, 10-minute batch to cloud for archival.

Q: How do I detect a device that is sending metrics but is actually hung?

A: Heartbeat metric + explicit liveness check. Device publishes device_heartbeat_timestamp_seconds every minute. If heartbeat stalls, alert. Additionally, from cloud, periodically ping device via MQTT RPC or HTTP health check. If no response, mark offline even if old metrics still arrive.

Q: What’s the cheapest way to monitor 1000 devices?

A: AWS IoT Core + CloudWatch (~$1–2/device-month) + free CloudWatch dashboard. Or: self-hosted Mosquitto (t2.micro EC2 ~$10/month) + InfluxDB OSS on Kubernetes (~$5/month) + Grafana (~$5/month) = ~$20/month total, but requires DevOps effort. Hybrid: AWS IoT Core for MQTT, push to self-hosted InfluxDB.

Q: How do I handle device firmware updates without losing observability?

A: Pre-announce update window in on-call. Device publishes device_update_status=in-flight before reboot. Suppress offline alerts during 5-minute update window. Post-update, device publishes new firmware version and resumes telemetry. Dashboard shows firmware versions per fleet for rollout validation.

Q: Can I use Prometheus instead of InfluxDB for IoT?

A: Prometheus is pull-based (server scrapes /metrics endpoint); IoT is push-based. You’d need Pushgateway (single point of failure) or use Prometheus remote write (ingests pushed metrics). InfluxDB’s MQTT support and line-protocol ingestion are better fits. However, Prometheus + Thanos (long-term storage) + remote write works at scale.

Real-World Implications & Future Outlook

IoT device monitoring is shifting from reactive (devices fail, then alert) to predictive (metrics diverge from baseline, prevent failure). Vendors are embedding anomaly detection directly into devices (NVIDIA Jetson edge AI, AWS Lookout for Equipment ML). By 2027, most industrial IoT platforms will ship with built-in anomaly detection; organizations maintaining custom stacks will face competitive pressure to upgrade.

The rise of Unified Namespace (MQTT broker as single source of truth, published by all devices) standardizes monitoring architecture. This enables plug-and-play observability tools—any Grafana deployment can query any UNS broker.

Cost pressures favor edge-first designs: pre-aggregate at device/gateway, push only summaries to cloud, avoid cloud ingestion costs. Bandwidth and storage become competitive advantages.

References & Further Reading

  1. MQTT v5.0 Specification — OASIS Standard, defines QoS, retained messages, will message (device offline). https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html
  2. MQTT Sparkplug B Specification — Traction/Infiswift, defines birth/death liveness for industrial IoT. https://sparkplug.eclipse.org/
  3. Prometheus Remote Write Format — Cloud-native monitoring standard for push-based ingestion. https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write
  4. InfluxDB Line Protocol — High-performance time-series ingestion format. https://docs.influxdata.com/influxdb/v2/write-data/line-protocol/
  5. Grafana Best Practices — Dashboard design, alerting rules, multi-tenancy for fleet monitoring. https://grafana.com/docs/grafana/latest/fundamentals/
  6. ISO/IEC 27001 Annex A.14 — Monitoring and alerting controls for critical systems.
  7. Datadog IoT Monitoring Blog — Real-world fleet monitoring case studies. https://www.datadoghq.com/blog/
Tags:

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *