Telemetrie & Streaming

Telemetrie als Blutkreislauf von IoT-Systemen¶

Sensoren ohne zuverlaessige Datenpipeline sind teure Hardware. Sie messen, aber die Daten kommen nie an. Oder sie kommen zu spaet. Oder sie gehen verloren. Oder sie kommen in falscher Reihenfolge und die Anomalieerkennung erzeugt Fehlalarme.

Wir bauen Telemetrieketten, bei denen jede Nachricht ankommt wo sie soll, wann sie soll und in der richtigen Reihenfolge. Vom Sensor ueber MQTT-Broker zu Kafka, ueber Stream Processing zur Zeitreihendatenbank und zum Dashboard. Jeder Schritt ueberwacht, skalierbar, resilient.

MQTT als Transport¶

Warum MQTT¶

MQTT (Message Queuing Telemetry Transport) ist der De-facto-Standard fuer IoT-Kommunikation. 1999 fuer Oelpipelines entwickelt — zuverlaessige Datenuebertragung ueber unzuverlaessige Satellitenverbindungen. Heute auf Milliarden von Geraeten.

Schluesseleigenschaften fuer IoT:

• Leichtgewichtig: 2 Byte minimaler Header. Eine komplette Nachricht mit 100B Payload hat 102B Overhead. Ein HTTP-Request fuer dieselben Daten: 500B+.
• Pub/Sub-Modell: Geraet publiziert auf ein Topic, Backend abonniert. Entkopplung — das Geraet weiss nicht (und muss nicht wissen), wer die Daten liest.
• Persistente Sessions: Broker merkt sich Abonnements und unzugestellte Nachrichten fuer Offline-Geraete. Nach Reconnect liefert er alles nach, was verpasst wurde.
• Last Will and Testament: Beim Verbinden definiert ein Geraet sein „Vermaechtnis” — eine Nachricht, die der Broker sendet, wenn das Geraet unerwartet verschwindet. Sofortige Erkennung von Offline-Geraeten.

Quality of Service¶

Drei Stufen der Zustellungsgarantie:

• QoS 0 (Hoechstens einmal): Fire-and-Forget. Keine Bestaetigung. Fuer Daten, bei denen gelegentlicher Verlust akzeptabel ist (Hochfrequenz-Telemetrie, bei der ein fehlender Abtastwert interpoliert werden kann).
• QoS 1 (Mindestens einmal): Zustellungsbestaetigung. Moegliche Duplikate. Fuer die meiste Telemetrie — das Backend muss idempotent sein.
• QoS 2 (Genau einmal): Vierschritt-Handshake. Keine Verluste, keine Duplikate. Fuer kritische Daten (Transaktionen, Alarme, Befehle). Hoeherer Overhead — nur wo noetig verwendet.

MQTT 5.0 Features¶

• Shared Subscriptions: Load Balancing zwischen mehreren Consumern. Topic $share/group/sensors/+/temperature — Nachrichten Round-Robin zwischen Subscribern verteilt.
• Topic Aliases: Verkuerzung sich wiederholender Topic-Namen. Bandbreitenreduktion um 10-30%.
• Flow Control: Empfaenger kann „langsamer” sagen — Schutz gegen Ueberlastung eines langsamen Consumers.
• Request/Response: Natives Request/Response-Pattern ueber Correlation Data und Response Topic.

MQTT Broker¶

EMQX: Verteilt, Cluster-faehig. Millionen gleichzeitiger Verbindungen. Rule Engine fuer Routing und Transformation. Bridge zu Kafka, HTTP, Datenbanken.

Mosquitto: Leichtgewichtig, Single-Node. Ideal fuer Edge und kleinere Deployments. C-Implementierung, minimale Ressourcen.

Azure IoT Hub / AWS IoT Core: Managed MQTT-Broker mit integriertem Device Management. Vendor Lock-in, aber null Operations.

Kafka fuer Stream Processing¶

MQTT liefert Daten an den Broker. Kafka ist das zentrale Nervensystem — Event Store, Stream Processor, Integration Hub.

Warum Kafka nach MQTT¶

Ein MQTT-Broker ist Transport — er liefert Nachrichten an Subscriber und vergisst sie (typischerweise). Kafka ist ein dauerhaftes Event Log — Nachrichten auf Disk gespeichert, Aufbewahrung von Tagen bis Jahren. Replay jederzeit. Ein neuer Consumer kann historische Daten von Anfang an verarbeiten.

Architekturmuster:

Device → MQTT Broker → Kafka Connect/Bridge → Kafka → Consumers

Stream Processing¶

Kafka Streams oder Apache Flink fuer Echtzeit-Verarbeitung:

• Aggregation: Durchschnittstemperatur der letzten 5 Minuten, maximale Vibration pro Stunde
• Windowing: Tumbling, Hopping, Sliding Windows. Session Windows fuer Aktivitaetserkennung.
• Anomalieerkennung: Z-Score, gleitender Durchschnitt, Isolation Forest. Alert wenn Wert von Baseline abweicht.
• Enrichment: Kontext hinzufuegen — Geraetemetadaten, Standort, Kunde. Stream mit Referenzdaten joinen.
• Filtering: Rauschfilterung, Deduplizierung, Formatvalidierung.

Consumer Groups¶

Parallele Verarbeitung ueber Consumer Groups:

• Alerting Consumer: Echtzeit-Regelauswertung, Push-Benachrichtigung bei Schwellenwert-Ueberschreitung
• Storage Consumer: Schreiben in Zeitreihen-DB fuer historische Abfragen
• Analytics Consumer: Aggregation fuer Dashboards und Reports
• ML Consumer: Feature Store fuer ML-Modelle, Trainingsdaten-Pipeline

Jeder Consumer unabhaengig skalierbar. Neuen Consumer hinzufuegen ohne Auswirkung auf bestehende.

Datenpipeline-Architektur¶

Vom Sensor zum Dashboard¶

Sensor → [Local buffer] → MQTT (QoS 1) → MQTT Broker
  → Kafka Connect → Kafka Topic (raw)
    → Stream Processing (validation, enrichment)
      → Kafka Topic (processed)
        → InfluxDB/TimescaleDB (storage)
        → Grafana (visualization)
        → Alert Engine (rules)
        → ML Pipeline (features)

Jeder Schritt ist unabhaengig skalierbar, ueberwacht und wiederherstellbar.

Dead Letter Queue¶

Nachrichten die die Validierung nicht bestehen (falsches Format, unbekanntes Geraet, ausserhalb des Bereichs) gehen nicht verloren. Sie gehen in eine Dead Letter Queue zur Analyse:

• Automatische Benachrichtigung bei DLQ-Wachstum
• Dashboard mit haeufigsten Fehlergruenden
• Manuelle Pruefung und Wiederverarbeitung
• Root-Cause-Analyse — schlechte Firmware? Bug im Geraetecode?

Kompression und Effizienz¶

• Protocol Buffers: Binaere Serialisierung, 3-10x kleiner als JSON. Schema-Evolution mit Rueckwaerts-/Vorwaertskompatibilitaet. Ideal fuer Hochdurchsatz-Telemetrie.
• MessagePack: JSON-kompatibles Binaerformat. Einfachere Adoption als Protobuf, trotzdem 30-50% kleiner als JSON.
• Geraeteseitiges Batching: Lokaler Puffer, Versand nach N Nachrichten oder T Sekunden. Reduziert Connection Overhead.
• Adaptives Sampling: Normalbetrieb: 1 Abtastwert/Min. Anomalie erkannt: 10 Abtastwerte/s. Dynamische Granularitaet nach Bedarf.

Zeitreihen-Speicher¶

InfluxDB¶

Native Zeitreihendatenbank. Optimiert fuer schreiblastige Workloads:

• Ingest: Hunderttausende Datenpunkte pro Sekunde
• Flux-Abfragesprache fuer Transformationen und Analyse
• Aufbewahrungsrichtlinien: Automatisches Ablaufen alter Daten
• Continuous Queries fuer Voraggregation

TimescaleDB¶

PostgreSQL-Erweiterung fuer Zeitreihen:

• Volles SQL — JOINs mit relationalen Daten (Geraetemetadaten, Kunden)
• Hypertables fuer automatische Partitionierung
• Kompression: 90-95% Speicherersparnis fuer aeltere Daten
• Continuous Aggregates fuer Materialized Views

Auswahl¶

InfluxDB fuer reine Telemetrie-Workloads (einfachere Bedienung, natives Zeitreihen-UX). TimescaleDB wenn Sie SQL, JOINs brauchen oder bereits einen PostgreSQL-Stack haben.

Technologie-Stack¶

Transport: MQTT 5.0, AMQP, CoAP, HTTP/2.

Broker: EMQX, Mosquitto, Azure IoT Hub, AWS IoT Core, HiveMQ.

Streaming: Apache Kafka, Kafka Streams, Apache Flink, Redpanda.

Speicher: InfluxDB, TimescaleDB, QuestDB, Apache Parquet (Archiv).

Serialisierung: Protocol Buffers, MessagePack, Avro, JSON.

Visualisierung: Grafana, Custom Dashboards.

Verwandt mit