De meeste IoT-pijplijnen zien er prima uit op een demo-dataset. Echte telemetrie laat ze breken op manieren die in een lab moeilijk te reproduceren zijn — klokafwijking, volgorde-issues, een tijdelijke uitval van één gateway, de firmware-update die om 02:00 lokale tijd uitrolt.
Wat we als eerste meten
Drie regels telemetrie die zichzelf terugverdienen zodra het mis gaat:
- Een heartbeat per device, los van de zakelijke payload
- Een monotone volgnummer-reeks, zodat gaps detecteerbaar zijn zonder ernaar te raden
- Een ontvangst-tijdstempel los van de device-tijdstempel
De derde is het belangrijkst. Op de dag dat de klok van een sensor negentig minuten afdrijft, wil je weten of de vertraging op de lijn zit of in het device.
“We dachten dat het het netwerk was. Het was altijd de firmware.”
Pijplijnen die “niet breken”, zijn meestal pijplijnen die zichtbaar falen en automatisch herstellen. De broze pijplijnen zijn de pijplijnen die stilletjes twee procent van de berichten laten vallen en het een afrondingsfout noemen.
Drie patronen die de praktijk overleven
Tenzij er een specifieke reden is om het niet te doen, doen wij het zo:
- Idempotente writes op (device_id, sequence) — de oplossing voor bijna elke paniek over dubbele events.
- Een dead-letter store met de oorspronkelijke payload intact — de enige manier om te leren van een falen dat je niet kunt reproduceren.
- Trage alerts voor snelle alerts — pagen op een trend van vijf minuten is rustiger dan pagen op elke piek.
Niets daarvan is nieuw. Het is allemaal het soort dingen dat je je herinnert te willen toevoegen na de derde dinsdag — maar het kost nauwelijks iets om het op dag één al in te bouwen.