How to aggregate metrics by device in Real-Time Analytics: step by step

João Barros 09 de November de 2026 4 min read

Device-level aggregation in Real-Time Analytics allows summarizing signals (CPU, temperature, errors) by device in sliding windows, reducing noise and enabling real-time decision making. This tutorial shows how to configure a simple pipeline, aggregate by device_id and emit aggregated metrics regularly — useful for dashboards and alerts.

Prerequisites

An account with access to a real-time event ingestion service (e.g., Event Hub, Kafka, or Azure IoT Hub).
A cluster or processing service that supports streaming queries (e.g., Azure Stream Analytics, Kusto/ADX, or Apache Flink).
Telemetry data with a device identifier (device_id), timestamp and a metric value (metric_value).
Basic knowledge of KQL or streaming SQL; KQL/ADX example included.

Step 1: Model the events and schema

Having a consistent schema is important. Each event should include device_id, timestamp (UTC) and a numeric metric_value. Having an event_type or sensor_type also helps grouping.

{
  "device_id": "device-123",
  "timestamp": "2026-11-09T12:34:56Z",
  "metric_name": "temperature",
  "metric_value": 23.7
}

Step 2: Ingestion and normalization

Ingest events into a topic/stream. Normalizing timestamps to UTC and validating types prevents surprises when aggregating by windows. In Azure Event Hub or IoT Hub, configure a consumer that writes to your streaming engine's store (e.g., Event Hub -> ADX ingestion).

Step 3: Define the sliding window and output granularity

Choose a sliding window that balances latency and stability. E.g.: a 1-minute window with a 10-second hop — this produces an updated metric every 10s using data from the last 60s.

Step 4: Write the aggregation query in KQL (ADX example)

Example using KQL in Azure Data Explorer (ADX) to aggregate by device_id and metric_name with average, count and 95th percentile over sliding windows. Adjust the ingestion table name.

Telemetry
| where timestamp between (ago(10m) .. now())
| where isnotempty(device_id) and isnotempty(metric_value)
| summarize
    avg_value = avg(metric_value),
    count_events = count(),
    p95 = percentile(metric_value, 95)
  by device_id, metric_name, window = slidingwindow(1m, 10s)
| project window_start = window.start, window_end = window.end, device_id, metric_name, avg_value, count_events, p95

Step 5: Emit aggregated metrics to downstream

Write the result to a sink that feeds dashboards or alerts (e.g., Power BI, Azure Monitor Metrics, or a Kafka topic). In ADX you can use

// Exemplo conceptual: exportar para Event Hub ou função que grava em Timescale/Influx
.create-or-alter function ExportAggregates() {
  Telemetry
  | where timestamp between (ago(10m) .. now())
  | summarize avg_value=avg(metric_value), count_events=count() by device_id, metric_name, window=slidingwindow(1m,10s)
  | project window_start=window.start, window_end=window.end, device_id, metric_name, avg_value, count_events
}

Step 6: Handle outliers and missing data

Filter invalid readings before aggregation (null values, negative values when impossible). For devices with few events, combine aggregations with a minimum count threshold to avoid noisy metrics.

... | where metric_value >= 0
| summarize avg_value=avg(metric_value), count_events=count() by device_id, metric_name, window=slidingwindow(1m,10s)
| where count_events >= 3

Verify the result

Confirm that aggregated metrics appear in the sink with coherent timestamps and expected frequency (e.g., every 10s). Check some device_id values manually: compare the average computed by the query with the average of the raw events in the interval. Monitor end-to-end latency and events-per-window rate to ensure the sliding window has sufficient data.

Conclusion

Aggregating metrics by device in Real-Time Analytics enables visualizing local trends and reducing noise, supporting more reliable alerts and dashboards. Next steps: experiment with different windows, enrich with device metadata and export to Power BI or Azure Monitor. Tip: start with larger windows and shrink them until you find the balance between latency and stability — which window will you try first?