Gegevensmonitoringsysteem: wat het is, wat het niet is en hoe je er een bouwt die werkt.

Los van de marketing, is een datamonitoringsysteem in essentie dit: de combinatie van tools, telemetrie, waarschuwingsregels en menselijke processen waarmee je team dataproblemen kan detecteren voordat de mensen verderop in het proces dat doen.

Het woord "systeem" is belangrijk. Een enkel dashboard is geen systeem. Een Slack-waarschuwing zonder verantwoordelijke is geen systeem. Een monitoringtool die is aangesloten maar nooit is afgesteld, is geen systeem. Een systeem impliceert onderdelen die op elkaar aansluiten: detectie, routering, respons en leren.

De meeste teams hebben één of twee onderdelen en noemen dat een systeem. Het resultaat: veel ruis, trage detectie en incidenten die de CFO nog steeds bereiken voordat het datateam er iets van merkt.

Volgens een brancheonderzoek van Wakefield Research / Monte Carlo hebben organisaties gemiddeld 70 data-incidenten per 1.000 tabellen per jaar, waarbij 40% van de tijd van data-engineers wordt besteed aan het oplossen van kwaliteitsproblemen. (Monte Carlo, 2024)

Een datamonitoringsysteem dat zijn nut bewijst, omvat vier lagen. Sla er één over en het hele systeem lekt.

Laag 1 — Pipeline-status is wat de meeste teams als eerste bouwen. Airflow, ADF en Databricks Jobs tonen allemaal de uitvoeringsstatus. Stel een Slack-webhook in en je hebt laag 1.

Laag 2 — Data-status is waar de meeste teams vastlopen. dbt-tests dekken bekende regels. Laag 2 vereist meer: detectie van schema-afwijkingen, vertraging in de actualiteit van gegevens en volume-anomalieën. Dit is waar tools voor data-observability zich bevinden.

Laag 3 — Zakelijke impact is de laag die bijna iedereen overslaat. Zonder deze laag lijken alle waarschuwingen op elkaar. De dataset die het dagelijkse omzetdashboard van de CFO aanstuurt, genereert hetzelfde ruisniveau als een backfill-taak waar niemand op vertrouwt. Resultaat: waarschuwingsmoeheid.

Laag 4 — Oplossing is de laag die waarschuwingen omzet in oplossingen. Een waarschuwing zonder eigenaar en zonder draaiboek is slechts decoratie. Houd de mediane detectietijd, de oplostijd en het aantal incidenten dat zakelijke gebruikers bereikt bij.

We hebben hetzelfde patroon gezien bij tientallen datateams. Het lek ontstaat bijna altijd op een van de volgende drie plekken:

Lek 1: Laag 2 bouwen zonder laag 3 Een team neemt een data-observability tool in gebruik en voegt 500 datasets tegelijk toe. Dag 2: het team heeft 500 alerts. Dag 3: ze dempen het kanaal. De tool zelf had het niet mis. Het team had niet gedefinieerd welke datasets bedrijfskritisch zijn, waardoor elke alert even zwaar weegt.

Lek 2: Datatests behandelen als monitoring dbt-tests zijn uitstekend geschikt om bekende problemen op te sporen. Ze zijn geen monitoring. Een test detecteert alleen wat je in een regel hebt opgenomen. Een monitoringsysteem moet de onbekende onbekenden detecteren: de soorten fouten waar je geen regel voor hebt opgesteld.

Lek 3: Stoppen bij detectie Een Slack-alert waar niemand verantwoordelijk voor is, wordt één keer gelezen en vervolgens vergeten. Zonder runbook, ernst niveaus en routeringsregels ontbreekt laag 4 — en is het systeem slechts een notificatiesysteem, geen monitorsysteem.

"Je hebt geen monitoringsysteem; je hebt een notificatiesysteem." — geparafraseerd uit een SRE-workshopdiscussie op SREcon 2023.

Als je helemaal opnieuw begint of een bestaand systeem opnieuw opbouwt, is dit de volgorde die het snelst resultaten oplevert. Stappen overslaan is de meest voorkomende fout.

Week 1 — Inventariseer en categoriseer je datasets Maak een lijst van alle datasets, tabellen en dashboards die in productie zijn. Geef ze een categorie: 1 (CFO ziet het), 2 (operationeel team gebruikt het), 3 (al het overige). Dit is laag 3, die wordt uitgevoerd voordat laag 1 of 2 überhaupt bestaat. Zonder deze laag herhaal je het lek dat hierboven is beschreven.

Week 2-3 — Pipelinestatus (laag 1) Stel basiswaarschuwingen in voor de status van de pipelines op laag 1 en 2. De dashboards van de standaardtools plus een Slack-kanaal zijn in dit stadium voldoende. Probeer nog niet te slim te zijn.

Week 4-6 — Datakwaliteit alleen op tier 1 (laag 2) Introduceer datakwaliteitscontroles (dbt-tests, Great Expectations) en monitoring van de actualiteit/het volume van datasets op tier 1. Weersta de verleiding om alles te importeren. De 20 datasets die de zichtbare cijfers in het bestuur genereren, dekken 80% van het bedrijfsrisico.

Week 7-8 — Routering en runbooks (laag 4) Voeg voor elke bestaande alert een eigenaar, ernst niveau en een runbook van één alinea toe. Alerts zonder deze drie elementen worden gedegradeerd of verwijderd.

Vanaf week 9 — Uitbreiding Voeg nu datasets van tier 2 toe aan laag 2. Stem de drempelwaarden af op basis van daadwerkelijke incidenten. Houd maandelijks drie cijfers bij: de mediane detectietijd, de oplostijd en het aantal incidenten dat een zakelijke gebruiker bereikte voordat je team erbij betrokken raakte.

De keuze van de tool hangt af van de structuur van je stack. Hier is een startpakket per stacktype.

Wat je beter kunt weglaten: alles wat belooft alle vier de lagen zonder configuratie af te handelen. Laag 3 (impact op het bedrijfsleven) kan niet uit de data worden afgeleid; daarvoor is menselijke input nodig om te bepalen welke datasets voor wie relevant zijn.

Drie cijfers, die maandelijks worden bijgehouden, laten zien of je datamonitoringsysteem zijn nut bewijst.

Mediane tijd tot detectie (MTTD) Van "er is iets kapot" tot "eerste waarschuwing geactiveerd". Houd dit bij per ernstgraad. Een gezonde MTTD voor datasets van niveau 1 is minder dan 10 minuten. Alles boven de 1 uur betekent dat je monitoring reactief is, niet proactief.

Mediane tijd tot oplossen (MTTR) Van "eerste waarschuwing geactiveerd" tot "incident afgesloten". Dit hangt voornamelijk af van de kwaliteit van laag 4 (runbooks, verantwoordelijkheid). Een gezonde MTTR voor laag 1 is minder dan 2 uur.

Aantal incidenten dat de business bereikt Het allerbelangrijkste cijfer. Hoeveel incidenten per maand worden opgemerkt door een business user voordat je team ze opmerkt? Als dit aantal niet richting nul gaat, lekt het systeem ergens.

Een IDC InfoBrief schat dat data engineers tot 30% van hun tijd besteden aan incident triage. (IDC, 2023) Het doel van een datamonitoringsysteem is niet om meer incidenten te vinden. Het is om dat aantal omlaag te brengen.

Als je stack zich binnen het Microsoft-data-ecosysteem bevindt (Power BI, ADF, Databricks, dbt, Fabric, Snowflake), is MetricSign het data-monitoringsysteem dat de tweede en derde laag (laag 2 + 3) vormt.

Het bewaakt de actualiteit, het volume, het schema en de distributie van datasets over de gehele stack. Het modelleert de herkomst van gegevens tussen tools, zodat een storing in ADF als een waarschuwing wordt weergegeven op het Power BI dashboard dat ervan afhankelijk is. Bovendien kunt je datasets indelen in lagen, zodat incidenten van laag 1 worden doorgegeven aan de on-call-afdeling, terwijl incidenten van laag 3 in een overzicht worden opgenomen.

Laag 1 blijft binnen je bestaande tools (Azure Monitor, native dashboards). Laag 4 maakt verbinding met je bestaande on-call-proces (Slack, PagerDuty, Teams). MetricSign dekt de lagen die de meeste teams als laatste en het minst implementeren.