End-to-end latency monitoring beantwoordt de vraag die gebruikers echt interesseert: zijn de gegevens in dit rapport op dit moment actueel? Dit vereist het volgen van de volledige keten van bron tot rapport en niet alleen het monitoren van individuele componenten.
De keten die de actualiteit van gegevens bepaalt
Een typische bedrijfsdataketen heeft meerdere stappen die elk latency toevoegen:
- Het bronsysteem werkt zijn gegevens bij (bijv. om 23:00 uur wanneer de transacties van de dag worden afgesloten)
- Een ADF pipeline start om middernacht en draait 45 minuten
- Een dbt Cloud-taak transformeert de gegevens en is voltooid om 02:00 uur
- De Power BI-dataset wordt vernieuwd om 05:00 uur en duurt 30 minuten
- Gebruikers openen rapporten vanaf 07:00 uur
De totale end-to-end latency bedraagt 8 uur vanaf het moment dat de brongegevens zijn aangemaakt tot het moment dat ze beschikbaar zijn in het rapport. Elke stap draagt bij aan dit totaal. Het afzonderlijk monitoren van elke stap laat zien of elke stap is voltooid, maar niet of de totale latency voldoet aan de SLA.
Wat te meten
End-to-end latency monitoring registreert drie tijdstempels voor elke dataset:
- Data-watermark: De maximale waarde van een datumveld in de geladen dataset. Dit geeft aan hoe recent de data daadwerkelijk is, ongeacht wanneer de refresh is uitgevoerd.
- Tijdstip van voltooiing van de pipeline: Het moment waarop de upstream pipeline (ADF, dbt, Databricks) klaar was met schrijven naar de brontabel.
- Tijdstip van voltooiing van de refresh: Het moment waarop de Power BI refresh is voltooid.
Het verschil tussen de data-watermark en de huidige tijd is de totale leeftijd van de data. Het verschil tussen de voltooiing van de pipeline en het begin van de refresh is de planningsmarge (buffertijd tussen de voltooiing van de pipeline en het volgende Power BI-vernieuwingsvenster). Als de pipeline langer duurt dan verwacht en deze buffer opgebruikt, kan de refresh het venster missen.
SLA-monitoring in de praktijk
Voor de meeste organisaties is realtime meting niet nodig voor SLA-monitoring. Een dagelijkse controle is voldoende. De controle bevestigt: "bevatte deze dataset data die recenter is dan X uur toen gebruikers vandaag begonnen te werken?"
Voor datasets die realtime operationele dashboards ondersteunen, zijn frequentere controles nodig: "Is de maximale gebeurtenistijdstempel minder dan 2 uur oud?"
Waar end-to-end latency monitoring verschilt van monitoring van individuele stappen
Een team dat ADF en Power BI afzonderlijk monitort, kan beide componenten als gezond beschouwen, alle pipelines succesvol, alle refresh voltooid. Maar als de ADF pipeline 30 minuten langer duurt dan normaal, kan de Power BI refresh starten voordat de pipeline is voltooid waardoor de gegevens van de vorige run worden geladen. Beide componenten lijken gezond. De end-to-end latency-meting onthult het probleem: de gegevens zijn 24 uur oud in plaats van 1 uur oud.