Refresh-succes is een voorwaarde, geen gezondheidssignaal
Power BI monitoring stopt meestal bij refresh-success of -failure. Een data observability tool — of je hem nu zelf bouwt of koopt — bewaakt meerdere signalen tegelijk, omdat de storingen die gebruikers raken zelden als gefaalde refresh verschijnen.
De meeste Power BI monitoring-opstellingen zijn gebouwd rondom één event: de refresh mislukt of niet. Een failure-alert instellen, een e-mail ontvangen wanneer er iets stukgaat en noem dat monitoring. Voor een kleine omgeving met twee of drie eenvoudige import-mode datasets houdt dit stand. Schaal voorbij een dozijn datasets die worden gevoed door meerdere upstream pipelines en de gaten worden kostbaar.
Een geslaagde refresh betekent één ding: Power BI heeft data geladen vanuit de geconfigureerde databron zonder een API-fout. Het zegt niets over de juistheid, volledigheid of actualiteit van de data. De upstream pipeline kan draaien en nul rijen kopiëren. Een schema-wijziging in een bron kan stilzwijgend een kolom verwijderen waarvan je measures afhankelijk zijn. De dataset kan data laden die al twaalf uur oud was toen de refresh werd uitgevoerd. Al deze gevallen leveren een groene status op in Power BI Service.
Er zijn vier signalen die je vertellen of je data daadwerkelijk gezond is. Refresh-status is slechts het beginpunt.
Schema-wijzigingen breken rapporten zonder een fout te geven
Wanneer een data engineer een kolom hernoemt in een SQL Server tabel of een view verwijdert in Azure Synapse, hangt het gedrag van Power BI af van de vraag of het ontbrekende veld wordt gebruikt in een berekende kolom of measure. Als dat zo is, mislukt de dataset-refresh met een expressie-fout. Als het veld niet direct wordt gebruikt, de kolom verdwijnt gewoon uit de ruwe tabel, herlaadt de dataset zonder fout, de kolom is stilzwijgend afwezig en elke rapportvisualisatie die erop is gebouwd toont lege waarden of nul.
Het detectiepatroon is eenvoudig: vergelijk na elke refresh de kolomset in de geladen dataset met een bekende correcte baseline. Elke kolom die aanwezig was in de baseline maar ontbreekt in de huidige load is een schema-wijziging. Deze check duurt seconden via de Power BI REST API en vangt de failure-klasse op die expressie-fouten niet onderscheppen.
Schema-wijzigingen afkomstig uit dbt-modellen zijn een veelvoorkomende bron van dit probleem. Een dbt-ontwikkelaar hernoemt een veld in een staging-model. De downstream Power BI dataset refresht succesvol. Drie rapporten die naar dat veld verwijzen tonen nullen. De eerste die het opmerkt is een salesmanager die maandagochtend een forecast opent.
Volume anomalies onderscheppen het getal dat geen nul mag zijn
Volume-monitoring beantwoordt één vraag: heeft deze dataset ongeveer het juiste aantal rijen? De vraag is eenvoudig. Het antwoord voorkomt een hele categorie van stille failures.
Je sales fact-table laadt normaal gesproken 48.000–52.000 rijen na de dagelijkse refresh. Als hij vandaag 12.000 rijen laadt, is er iets mis upstream, een filter werd toegevoegd aan de pipeline, een partitie werd niet geladen, een brontabel werd leeggemaakt. De Power BI refresh is succesvol voltooid. Er is niets te zien in het API-logboek. Het enige signaal is het aantal rijen.
Volume-baselines vereisen kalibratie: dag-van-de-week-variatie telt mee (maandagloads zijn doorgaans groter), en seizoenspatronen beïnvloeden sommige datasets. Een naïeve drempel die afgaat telkens wanneer het row count met 20% daalt ten opzichte van de vorige dag genereert elke maandagochtend false positives. De juiste baseline vergelijkt de huidige load met de mediaan voor dezelfde dag van de week over de afgelopen vier tot zes weken. Dat elimineert normale variatie terwijl echte dalingen worden onderschept.
De drempel hoeft niet exact te zijn om nuttig te zijn. Een daling naar 25% van het verwachte row count duidt bijna altijd op een echt probleem, ongeacht de nauwkeurigheid van de baseline.
Schedule drift is onzichtbaar totdat de SLA al is overschreden
Je dataset is geconfigureerd voor een refresh om 06:00. De refresh voltooit maandag om 06:14. Woensdag eindigt hij om 06:47. Vrijdag loopt de refresh door tot 07:15 en het rapport dat je finance-team om 07:00 opent heeft drie dagen lang verouderde data getoond. Er is geen alert afgegaan. Elke refresh is geslaagd.
Schedule drift treedt op wanneer de refresh duur geleidelijk groeit, modelcomplexiteit neemt toe, datavolumes groeien, upstream queries vertragen naarmate tabellen groter worden. De failure is onzichtbaar omdat het incrementeel gebeurt. Geen enkele dag overschrijdt een duidelijke drempel. De drift accumuleert totdat hij de zakelijke SLA overschrijdt.
Om afwijkingen te detecteren, is het nodig de verversingsduur in de loop van de tijd te volgen en waarschuwingen te geven op basis van de trend, niet alleen op basis van individuele waarden. Een enkele verversing die 75 minuten duurt, is geen anomalie als eerdere verversingen gemiddeld 70 minuten duurden. Een verversing die 75 minuten duurt terwijl het zeswekengemiddelde 15 minuten was, is dat wel. Het signaal is de afwijking van de historische basislijn, niet de afwijking van een willekeurig maximum.
Stale data: wanneer de bron faalt en de refresh het niet merkt
De moeilijkst te detecteren failure-mode: de refresh slaagt, het row count klopt, het schema is ongewijzigd, maar de data is van twee dagen geleden. Dit gebeurt wanneer het bronsysteem stopt met bijwerken terwijl de pipeline blijft draaien. De pipeline kopieert dezelfde data die hij gisteren ook kopieerde. De refresh laadt die zonder fout. De timestamp-kolom die het probleem zou onthullen is verborgen in de ruwe tabel waar niemand naar heeft gekeken.
Stale data detecteren vereist een watermark-check: lees de maximale waarde van de datum- of timestamp-kolom die de meest recente data zou moeten weerspiegelen en vergelijk die met de huidige tijd. Als je dagelijkse sales dataset refresht om 06:00 en de maximale transactiedatum is gisteren om twaalf uur 's middags, is de data al achttien uur oud voordat je gebruikers het rapport openen.
De watermark-check voegt één query toe aan je monitoring-stack en onderschept de failure-klasse die alle andere signalen missen. Gecombineerd met refresh-status, schema-wijzigingsdetectie en volume-monitoring sluit het de vier meest voorkomende paden naar stille datafailure.
Vier signalen geven je een compleet beeld. Refresh-status alleen geeft je een kwart ervan.
Refresh-status, schema-wijzigingsdetectie, volume-monitoring en watermark-checks adresseren elk verschillende failure-modes en ze kunnen allemaal onafhankelijk van elkaar afgaan. Een refresh kan slagen (status groen) terwijl hij een verlaagd row count laadt (volume-anomalie). Een schema-wijziging kan onopgemerkt blijven terwijl de watermark er gezond uitziet. Stale data kan samengaan met een perfect row count.
De vier checks zijn elk lichtgewicht om afzonderlijk te implementeren. Gecombineerd geven ze een compleet beeld van de gezondheid van een dataset — niet alleen of de loader zonder fout heeft gedraaid. Voor de meeste Power BI-omgevingen is het implementeren van deze vier checks via de REST API en een geconfigureerde databron één dag engineeringwerk. Het alternatief is problemen ontdekken via je gebruikers.