Gegevensobservatie voor de Microsoft-stack: Power BI, ADF, Databricks, dbt en Fabric

Voor dbt+Snowflake-teams is data-observability een opgelost probleem. Monte Carlo, Bigeye en Elementary dekken de actualiteit, het volume, het schema en de herkomst van de data binnen het datawarehouse. De grens van het probleem ligt grofweg bij het datawarehouse zelf.

Teams die met de Microsoft-stack werken, hebben die luxe niet. De meeste data-observability-platformen die zijn gebouwd voor datawarehouse-first stacks laten de ADF-, Databricks- en Power BI lagen onbedekt – en dat zijn nu juist de lagen waar incidenten met de Microsoft-stack ontstaan.

Een typische pipeline brengt ruwe data via een ADF-copy activity naar ADLS, transformeert deze in een Databricks-notebook of dbt-project dat draait op Databricks SQL, materialiseert een sterschema en levert deze via een Power BI semantisch model – steeds vaker binnen Microsoft Fabric. Elk van deze overdrachten heeft zijn eigen foutmodus, zijn eigen log oppervlak en zijn eigen native alerting die niet communiceert met de volgende overdracht.

Het resultaat: wanneer een update op vrijdagochtend verouderde cijfers in het directiedashboard laat zien, moet de dienstdoende BI-ontwikkelaar op vijf plekken kijken en weet hij niet waar het probleem zich het eerst voordeed.

Zie ook: Beste data-observabilityplatforms in 2026

1. Brongegevens. Stroomopwaartse systemen — Dynamics 365, SAP, Salesforce, on-premise SQL — wijzigen hun schema zonder voorafgaande kennisgeving, verminderen het volume na een implementatie of komen te laat aan omdat een SFTP-partner een deadline heeft gemist. Het symptoom: een downstream COPY INTO slaagt, maar schrijft slechts 12 rijen in plaats van 1,2 miljoen, of een MERGE mislukt met de foutmelding Kan kolom 'CustomerStatus' niet oplossen. Er is geen ingebouwde tooling. Je moet rijtellingen en schemacontroles in ADF Lookup-activiteiten implementeren of downstream vertrouwen op dbt-bronversheidstests — wat betekent dat je het probleem pas detecteert nadat het zich al heeft verspreid.

2. ADF-pipelines. Activiteitsfouten (ErrorCode=2200, ErrorCode=2100), fouten in de gegevensstroom van mappings, time-outs van zelfgehoste IR-gateways (ErrorCode=9013) en uitputting van het integratie-runtime quotum. Symptoom: pipeline status 'Mislukt' in het tabblad Monitoring, vaak met een vierlaagse geneste foutketen. Gebruikte tools: ADF Monitoring, diagnostische logboeken van Azure Monitor naar Log Analytics, actiegroepen voor e-mail-/webhookwaarschuwingen. Nuttig, maar elke pipeline geeft een waarschuwing afzonderlijk — je ontvangt één e-mail per mislukte activiteit, niet één incident per logische pipeline.

3. Databricks-taken. OOM in een worker (Driver/Executor lost), SparkOutOfMemoryError, trage taken die de SLA overschrijden, fouten bij automatisch schalen, opstartfouten van het cluster door INVALID_PARAMETER_VALUE op instantiepools. Symptoom: een taak die gisteren 14 minuten duurde, duurt vandaag 47 minuten of mislukt bij de derde poging. Gebruikte tools: e-mailwaarschuwingen op taakniveau, systeemtabellen (system.lakeflow.jobs), webhookbestemmingen naar Slack of PagerDuty. Gedetailleerde informatie, maar geen inzicht in of de uitvoer van de taak correct is.

4. dbt-transformaties. Fouten bij het bouwen van modellen, testfouten (unique, not_null, aangepaste singular-tests), fouten met betrekking tot de actualiteit van de upstream-bron en snapshot-drift. Symptoom: dbt run sluit af met een niet-nul-uitgang, of een dbt test meldt 14.302 foutieve rijen in not_null_orders_customer_id. Native tools: dbt Cloud heeft alerts en de Discovery API; dbt Core-gebruikers hebben run_results.json en alles wat ze daaraan koppelen. De blinde vlek: dbt weet niets over de vraag of de Power BI dataset die de datawarehouse gebruikt daadwerkelijk is vernieuwd.

5. De semantische laag van Power BI. Fouten bij het refresh van datasets, schemaverschillen tussen het model en de bronweergave (De kolom 'X' bestaat niet), gateway-uitval (PBIEgwService stopt zonder statuswijziging), capaciteitsbeperking op Premium/Fabric F-SKU's en — de stille moordenaar — refresh_delayed: een refresh die weliswaar slaagt, maar 6 uur te laat is omdat de upstream-pipeline te laat is voltooid. Standaardtools: refreshgeschiedenis van Power BI Service, activity log, de REST API voor beheerders, Fabric Capacity Metrics-app. Geen van deze tools geeft standaard een vertraging ten opzichte van de verwachte SLA weer.

Generieke tools voor data-observability zijn ontwikkeld voor een datawarehouse-georiënteerde wereld. Ze maken verbinding met Snowflake, BigQuery, Redshift en in toenemende mate Databricks, en ze detecteren uitstekend afwijkingen in de actualiteit van gegevens, volumeverminderingen en schemawijzigingen in die tabellen.

Wat ze niet zien in de Microsoft-stack:

De status van de ADF-pipeline. Monte Carlo heeft geen integratie met de ADF REST API, geen inzicht in fouten op activiteitsniveau en geen zicht op de status van zelfgehoste IR's. Een pipeline die 8 uur lang niet heeft gedraaid omdat de gateway is uitgevallen, is onzichtbaar.

De refresh status van Power BI. Noch Monte Carlo, noch Bigeye voert query's uit op de Power BI Admin API. Een mislukte Refresh-PowerBIDataset wordt niet geregistreerd. Een dataset die wordt geïmporteerd uit een Databricks-tabel die de tool wel monitort, zal groen worden weergegeven op het datawarehouse-niveau, terwijl het dashboard de cijfers van gisteren toont.

Fabric-pipeline-runs. Fabric Data Pipelines en notebook-runs vormen een aparte laag van ADF, met een eigen monitoring-API. De dekking is in feite nul in generieke tools vanaf medio 2026.

Het praktische gevolg: een dbt-model dat niet voldoet aan de 'unieke' test, waardoor een Power BI mart niet meer werkt, genereert één waarschuwing van dbt Cloud, één van de e-mailmeldingen van Power BI over een mislukte refresh, en geen enkele van je observatietool — omdat de tabel op het datawarehouse-niveau nog steeds bestaat en rijen bevat.

Hier is een echt faalpatroon. Om 02:14 UTC wordt de kolom OpportunityStageId verwijderd uit een Dynamics 365-export na een maandelijkse release van Microsoft. Om 03:00 uur lukt de ADF-copy activity naar Bronze omdat het schema dynamisch wordt ingelezen. Om 03:45 uur voert de Databricks Silver-taak MERGE uit en mislukt met de foutmelding AnalysisException: cannot resolve OpportunityStageId. De dbt-uitvoering die gepland staat voor 04:30 uur mislukt omdat het bronmodel verouderd is. De Power BI dataset die gepland staat voor 06:00 uur kan niet worden vernieuwd omdat de DirectQuery-weergave verwijst naar een kolom die niet meer bestaat.

Wat de dienstdoende engineer om 06:05 ziet:

• Een e-mail met een Databricks-taakfout van 03:46
• Een dbt Cloud-foutmelding van 04:32
• Een e-mail met een Power BI verversingsfout van 06:01
• Een Slack-bericht van de CFO om 06:07 met de vraag waarom het pipeline-dashboard leeg is

Vier meldingen, één hoofdoorzaak, geen verband. De engineer besteedt 40 minuten aan het vaststellen dat het om hetzelfde incident gaat voordat hij kan beginnen met de oplossing. Er is wel informatie over de herkomst van de gegevens beschikbaar — Purview heeft een deel ervan, dbt de rest — maar geen enkel systeem koppelt de runtime-gebeurtenissen aan de herkomstgrafiek en presenteert één incident.

Dit is het onopgeloste probleem. Het is geen probleem met de datakwaliteit. Het is geen probleem met de observeerbaarheid van het datawarehouse. Het is een probleem met de correlatie van gebeurtenissen tussen systemen, met een bijbehorende afhankelijkheidsgrafiek.

Begin met native tools op elke laag en voeg daar vervolgens correlatie toe.

Brongegevens. Voeg validate_schema lookup-activiteiten toe in ADF die inkomende kolomlijsten vergelijken met een verwacht manifest en een foutmelding geven. Voor grote volumes kunt je na elke laadbeurt een query uitvoeren om het aantal rijen in een controletabel te tellen en een waarschuwing geven als de |delta| meer dan 25% per week bedraagt. De dbt-bronversheid met loaded_at_field dekt het geval van late aankomst af als je warn_after en error_after daadwerkelijk configureert.

ADF. Stuur diagnostische logboeken door naar Log Analytics. Schrijf een KQL-waarschuwing voor ADFActivityRun | where Status == 'Failed', gegroepeerd op pipelinenaam, om N activiteitsfouten samen te voegen tot één pipeline incident. Koppel actiegroepen aan een webhook, niet alleen aan e-mail.

Databricks. Gebruik webhook-meldingen op taakniveau, geen e-mail. Controleer system.lakeflow.job_run_timeline op runs die hun mediane duur met een factor 2 overschrijden — dit detecteert gevallen van langzame degradatie voordat er sprake is van een SLA-schending. Stel max_retries=2 in met exponentiële backoff bij tijdelijke clusterfouten.

dbt. Koppel run_results.json en manifest.json na elke run aan je incidenten systeem. Behandel testfouten met de status modified anders dan nieuwe testfouten — de laatste zijn meestal ruis. Voor dbt Core bevinden de artefacten zich in target/; voor dbt Cloud gebruikt je de Discovery API.

Power BI. Controleer de Admin REST API /admin/datasets/{id}/refreshes elke 5 minuten. Waarschuwing bij status != Completed en bij endTime - scheduledStartTime > expected_duration — de tweede voorwaarde detecteert refresh_delayed, het geval waarin de refresh technisch gezien slaagt, maar vertraging oploopt omdat iets stroomopwaarts dit blokkeert. Capaciteitsbeperking wordt weergegeven in de Fabric Capacity Metrics-app onder CU Usage en Throttling.

Na dit alles blijven er echter hiaten bestaan. De grootste: de native toolset legt geen verband tussen een mislukte dbt-test en de Power BI dataset die afhankelijk is van het mislukte model. Je zult die koppeling zelf moeten schrijven of een tool moeten gebruiken die dit doet.

MetricSign is speciaal ontwikkeld voor dit correlatieprobleem binnen de Microsoft-stack. Het maakt verbinding met ADF, Databricks, dbt (Core en Cloud), Fabric Data Pipelines en de Power BI Admin API, en correleert vervolgens gebeurtenissen in al deze omgevingen tot één incident met een tijdlijn en een herkomstgrafiek.

Het eerdergenoemde scenario – een schemawijziging in Dynamics die leidde tot een mislukte Power BI verversing – wordt weergegeven als één incident met de vier mislukte uitvoeringen geordend op tijdstempel, het herkomstpad van bron naar dataset gemarkeerd en de oorspronkelijke gebeurtenis (de schemawijziging) gemarkeerd als hoofdoorzaak. Het signaal refresh_delayed is uitstekend: een Power BI verversing die weliswaar is gelukt, maar 4 uur later plaatsvond dan verwacht, wordt behandeld als een incident, niet als een groen vinkje. Dat is iets wat generieke observatietools, die zijn ontworpen voor datawarehouse-stacks, niet doen.