Real-Time Backend
Design: IoT Dashboard
Каждую секунду Tesla получает телеметрию от миллиона автомобилей. AWS IoT Core принимает 100 миллиардов сообщений в день. Как вся эта лавина данных превращается в дашборд, который инженер видит на экране?
- **Tesla Fleet Telemetry**: 1M+ автомобилей отправляют данные каждые 1-10 сек - скорость, заряд батареи, температура двигателя, GPS. InfluxDB хранит петабайты time-series данных для анализа производительности и OTA диагностики.
- **Bosch IoT Suite**: 8B+ подключённых устройств в промышленных сценариях - от станков до умных счётчиков. Алертинг детектирует аномалии в реальном времени, предотвращая поломки оборудования стоимостью миллионы USD.
- **Grafana в NASA**: мониторинг спутниковых систем с Grafana + InfluxDB. 10M+ time series, custom panels для визуализации орбитальных параметров, алерты при отклонении от расчётных траекторий.
- **Smart Grid**: энергосети мониторят 100M+ умных счётчиков. Аномалия потребления в районе -> алерт за < 1 сек -> превентивное отключение до каскадного сбоя.
IoT Architecture: от датчика до дашборда
AWS IoT Core обрабатывает **100B+ сообщений в день** от миллионов устройств. Tesla передаёт телеметрию с **1M+ автомобилей** каждые несколько секунд. Bosch IoT Suite подключает **8B+ устройств** в промышленных сценариях. За всем этим стоит одна и та же многоуровневая архитектура: Edge -> Ingestion -> Stream Processing -> Storage -> Visualization.
Ключевой выбор протокола: **MQTT** (publish/subscribe, 2 байта overhead, QoS 0/1/2) для ресурсоограниченных устройств vs **HTTP** для однократных запросов. На уровне ingestion Kafka выдерживает **1M+ событий/сек** при горизонтальном масштабировании партиций.
| Слой | Технология | Пропускная способность | Latency |
|---|---|---|---|
| Edge protocol | MQTT QoS 0 | 10K msg/sec per broker | < 10 ms |
| Ingestion | Apache Kafka | 1M+ msg/sec | 5-15 ms |
| Stream processing | Apache Flink | 500K events/sec | 50-100 ms |
| Storage | InfluxDB | 1M points/sec writes | < 1 ms read |
| Visualization | Grafana | 10M+ time series | < 500 ms render |
**Fan-out проблема**: 1 устройство -> 1 топик в Kafka - антипаттерн при 10M устройствах (10M партиций). Правильно: шардировать по device_type или region, 100-1000 партиций на топик.
Система получает события от 5 млн датчиков. Каждый датчик публикует в свой отдельный Kafka-топик. В чём главная проблема?
Fleet Management: реестр и состояние миллионов устройств
AWS IoT Device Shadow хранит **last-known state** каждого устройства - JSON-документ с полями `reported` (что устройство сообщает) и `desired` (что должно быть). При восстановлении связи устройство получает delta и синхронизирует состояние. Это решает проблему intermittent connectivity без сложной логики на устройстве.
Для fleet-wide операций (OTA update, конфигурация) применяется **job queue** паттерн. AWS IoT Jobs разбивает rollout на группы: сначала 1% устройств (canary), затем 10%, затем 100%. Если в canary группе failure rate > 5% - rollout останавливается автоматически.
- Device Registry - база метаданных устройств (type, region, firmware, owner)
- Device Shadow / Twin - last-known state + desired state + delta
- Fleet Groups - логические группировки для batch-операций
- Job Queue - OTA updates с canary / staged rollout
- Certificate rotation - автоматическое обновление mTLS сертификатов
**Heartbeat vs Connection**: не доверять только TCP-соединению для определения online-статуса. Устройство может быть подключено, но зависнуть. Heartbeat interval = 30 сек, offline threshold = 3x heartbeat = 90 сек.
OTA firmware update нужно раскатить на 2M устройств. Как минимизировать риск массового отказа?
Alerting: детектирование аномалий в потоке событий
Промышленный IoT требует alert latency < 1 сек для критических событий (температура турбины, давление в трубопроводе). Grafana Alerting поддерживает **10M+ time series** с evaluation interval от 10 сек. PagerDuty интегрируется с 700+ инструментами мониторинга и обрабатывает **200M+ alerts в год**.
Три уровня алертинга по latency требованиям:
- Real-time: Stream Processing Alerts — Apache Flink / Kafka Streams - CEP (Complex Event Processing) rules прямо в потоке. Latency 50-200 ms. Для критических threshold alerts: temp > 150°C, pressure drop > 20% за 5 сек.
- Near-real-time: TSDB Rules — InfluxDB Tasks, Grafana Alerting - запросы к time-series каждые 10-60 сек. Для трендовых аномалий: rolling average, rate of change, seasonal deviation.
- Batch: ML Anomaly Detection — AWS Lookout for Equipment, Azure Anomaly Detector - обнаружение паттернов на исторических данных. Latency минуты/часы, но catch complex multivariate anomalies.
**Alert fatigue**: если система генерирует 1000+ алертов в день, операторы начинают их игнорировать. Решение: alert grouping (один алерт на регион вместо 1000 на каждое устройство), correlation (связывать causally linked alerts), flapping detection (подавлять алерты при частом переключении).
- Deduplication key - группировать алерты по device_group + alert_type, не по device_id
- Inhibition rules - сетевой алерт подавляет все device alerts в том же сегменте
- Silences - плановое обслуживание без шума
- Escalation policy - нет ответа за 5 мин -> следующий on-call
Flink job детектирует аномалии температуры в потоке событий. Нужно поймать паттерн: три последовательных значения выше 140°C в течение 30 секунд от одного устройства. Какой механизм Flink подходит?
Time-Series Visualization: Grafana и 10M метрик
Grafana используется для мониторинга IoT в Tesla (time-series телеметрия), Uber (fleet tracking), NASA (спутниковые данные). Grafana Cloud обрабатывает **10M+ уникальных time series** и поддерживает **50+ data sources** - от InfluxDB и Prometheus до PostgreSQL и Elasticsearch.
Главная проблема IoT-дашборда: **cardinality explosion**. Каждое уникальное сочетание labels (device_id, region, sensor_type) создаёт отдельную time series. 100K устройств x 20 метрик x 5 регионов = 10M series. InfluxDB и Victoria Metrics оптимизированы для high-cardinality, обычный Prometheus начинает деградировать после 1M series.
- Downsampling: raw data 1 сек -> 1 мин агрегация -> 1 час агрегация (retention policy в InfluxDB)
- Query caching: Grafana кеширует запросы, но IoT dashboards часто нужен live refresh каждые 5 сек
- Variable templating: один дашборд для всех регионов через ${region} переменную
- Provisioning as Code: дашборды в Git, деплой через Grafana provisioning API
- RBAC: оператор видит свой регион, admin видит всё
**Live streaming vs polling**: Grafana Streaming (WebSocket) позволяет получать данные push-way без polling. Подходит для < 1000 активных панелей одновременно. При большем числе пользователей - polling каждые 5-10 сек с query caching на уровне data source.
IoT dashboard = просто Grafana поверх базы данных. Выбрал красивые панели - готово.
IoT dashboard - это многослойная система: протокол (MQTT/CoAP) -> ingestion (Kafka) -> stream processing (Flink) -> time-series storage (InfluxDB) -> visualization (Grafana). Каждый слой решает свою задачу масштабируемости.
Без правильного ingestion layer Grafana задыхается при прямых запросах к миллионам устройств. Без stream processing алерты приходят с задержкой в минуты вместо секунд. Без downsampling storage заканчивается за недели.
InfluxDB хранит 100K метрик с raw resolution 1 событие/сек. Через 30 дней объём данных становится неприемлемым. Что применить?
Итоги
- **Многослойная архитектура**: Edge (MQTT) -> Kafka ingestion -> Flink stream processing -> InfluxDB/TimescaleDB -> Grafana. Каждый слой независимо масштабируется горизонтально.
- **Device Shadow паттерн**: хранить last-known state + desired state. При reconnect устройство получает delta и синхронизируется. Staged OTA rollout через canary groups предотвращает массовые сбои.
- **Cardinality explosion**: 100K устройств x 20 метрик = 2M time series. Использовать InfluxDB/Victoria Metrics вместо Prometheus для high-cardinality. Downsampling: raw 1сек -> 1мин -> 1ч с retention policy.
- **Alert engineering**: Stream CEP (Flink) для sub-second critical alerts. TSDB rules (InfluxDB Tasks) для трендов каждые 10-60 сек. Deduplication + inhibition + escalation policy против alert fatigue.
Связанные темы
IoT Dashboard объединяет несколько паттернов распределённых систем:
- Event-Driven Architecture — MQTT pub/sub и Kafka - основа IoT event pipeline
- Stream Processing — Flink CEP для real-time аномалий - применение потоковой обработки в IoT контексте
- Time-Series Databases — InfluxDB и TimescaleDB - специализированные хранилища для sensor data с downsampling
- Consistent Hashing — Шардирование устройств по партициям Kafka и нодам кластера
Вопросы для размышления
- Если бюджет на хранилище ограничен, на каком уровне детализации хранить данные за год? За неделю? За последние 24 часа? Как обосновать этот выбор?
- Устройство отправляет heartbeat каждые 30 сек. Как определить разницу между 'устройство offline' и 'сеть временно недоступна'? Как это влияет на дизайн alerting?
- Grafana дашборд тормозит при открытии - запросы выполняются 10-30 сек. Какие три места проверить в первую очередь?