Power BI Monitoring: Wat u moet bijhouden naast refreshes

De meeste Power BI monitoring setups zien er hetzelfde uit: een failure alert instellen, een e-mail ontvangen wanneer een refresh mislukt, en klaar. Voor kleine teams met eenvoudige modellen werkt dit. De refresh slaagt of niet, en u weet het binnen een uur.

Maar naarmate uw data stack groeit — meer datasets, meer rapporten, meer afhankelijkheden van upstream pipelines — wordt refresh status een steeds onvolledigere maatstaf. Een refresh kan succesvol verlopen terwijl data van twee dagen geleden wordt geladen. Een dataset kan elke refresh check doorstaan terwijl er stilletjes een volledige dimension table ontbreekt omdat een kolom upstream is hernoemd.

De kloof tussen "refresh geslaagd" en "data is correct en actueel" is waar de meeste datakwaliteitsincidenten zich voordoen. Anders dan een hard failure kondigen deze stille problemen zich niet aan. Ze komen aan het licht wanneer een stakeholder iets vreemds in een rapport opmerkt, of erger, wanneer er al een zakelijke beslissing is genomen op basis van onjuiste cijfers.

Een schema-wijziging is een van de meest ingrijpende dingen die een Power BI dataset kunnen overkomen, en ze komen zelden met een waarschuwing. Wanneer een data engineer een kolom in een SQL Server tabel hernoemt, een view verwijdert, of een datatype wijzigt, kan het downstream Power BI model nog steeds succesvol refreshen — maar er is iets kapot.

Het meest voorkomende scenario: een kolom waarvan een Power Query stap afhankelijk is, wordt hernoemd in de bron. Afhankelijk van de structuur van de query kan de kolom stilletjes null-waarden teruggeven of kan de stap een cryptische fout geven: Expression.Error: The column 'CustomerID' of the table wasn't found.

De lastiger te detecteren variant: een nieuwe kolom verschijnt upstream die in het model zou moeten zitten, maar er niet in staat. Uw dataset refresht prima, maar het model mist data die analisten verwachten. Zonder schema-wijziging detectie weet u het pas wanneer iemand vraagt "waar is het kortingsveld gebleven?"

Schema-wijzigingen detecteren vereist het vergelijken van de kolommen die elke query teruggeeft met een baseline vastgelegd bij de laatste bekende correcte toestand. Een goed monitoring systeem alerteert zodra een kolom verschijnt, verdwijnt of van type verandert — voordat iemand een rapport draait op een verouderde structuur.

Volume monitoring beantwoordt een simpele vraag: heeft deze dataset ongeveer het juiste aantal rijen? Als uw sales fact table normaal 50.000 rijen bevat na een dagelijkse refresh en vandaag 12.000, is er iets misgegaan upstream — maar uw refresh is zonder fouten voltooid.

Dit gebeurt vaker dan u denkt. Veelvoorkomende oorzaken:

• Een ADF pipeline die een leeg bestand heeft gekopieerd omdat het bronsysteem niet op tijd heeft geëxporteerd
• Een gefilterde query die per ongeluk de meeste rijen uitsloot omdat een datumparameter niet was bijgewerkt
• Een soft delete in de brondatabase die een partitie heeft gewist
• Een staging tabel die was leeggehaald maar niet opnieuw geladen voordat de Power BI refresh draaide

Volume monitoring werkt door een baseline vast te stellen — typisch een rolling average van rij-aantallen over de afgelopen N refreshes — en te alerteren wanneer het huidige aantal significant afwijkt. Een daling van 15% kan normale weekendschommeling zijn; een daling van 70% bijna nooit.

De uitdaging is kalibreren per dataset. Een kleine lookup table met 200 rijen zou niet moeten alerteren bij een wijziging van 10 rijen. Een fact table met 50 miljoen rijen vraagt om een nauwere bandbreedte. Goede volume monitoring past drempelwaarden aan op de geschiedenis van elke dataset in plaats van één algemene regel toe te passen.

Schedule drift is subtiel. Uw dataset is geconfigureerd om om 06:00 te refreshen. Maandag is hij klaar om 06:14. Dinsdag om 06:22. Vrijdag draait de refresh tot 07:15, en uw ochtendrapport is al vijf dagen te laat — maar niemand heeft hiervoor een alert ingesteld omdat de refreshes technisch gezien nog steeds slagen.

Drift heeft meerdere oorzaken: de upstream data source groeit en queries duren langer, gateway resources worden gedeeld met meer gelijktijdige jobs, of een langzaam groeiend model nadert geheugenlimieten tijdens verwerking. Geen van deze oorzaken triggert een failure. Ze maken alles alleen trager.

Vanuit business impact perspectief kan schedule drift net zo schadelijk zijn als een uitval. Als een Power BI rapport dat een standup om 09:00 ondersteunt om 08:50 nog aan het refreshen is, begint de meeting zonder actuele data. Als een financieel afsluitingsrapport dat om middernacht moet draaien consequent om 04:00 klaar is, wordt het reviewvenster voor marktopening kleiner.

Drift detecteren vereist het bijhouden van werkelijke voltooiingstijden over meerdere refreshes en alerteren wanneer de gemiddelde of worst-case duur een drempel overschrijdt — niet alleen individuele trage refreshes monitoren, maar de trend volgen.

De meest verraderlijke failure mode: de refresh slaagt, het rij-aantal klopt, het schema is niet gewijzigd — maar de data is van twee dagen geleden. Dit gebeurt wanneer het bronsysteem stilletjes faalt en gecachede of stale data aan de querylaag levert.

Een concreet voorbeeld: een on-premises SQL Server heeft een nachtelijke ETL-job die een staging tabel vult. De ETL is gisteravond mislukt, waardoor de staging tabel nog steeds de data van gisteren bevat. Power BI refresht die tabel, laadt de rijen succesvol en rapporteert "refresh complete". Alles ziet er goed uit downstream totdat iemand opmerkt dat de maximale transactiedatum in een rapport vastloopt.

Stale data detectie vereist het monitoren van een watermark kolom — typisch een modified_at, created_at of transaction_date veld — en alerteren wanneer de maximale waarde niet is opgeschoven na de laatste refresh. Dit is specifiek per dataset omdat verschillende tabellen verschillende datumpatronen gebruiken.

Voor Power BI specifiek betekent dit het inspecteren van de werkelijke datawaarden in het geladen model, niet alleen of de refresh is voltooid. De meeste monitoring tools stoppen bij de API-laag en kijken nooit naar de data zelf.

Refresh status, schema-wijzigingen, volume anomalies, schedule drift en stale data zijn geen vijf aparte monitoring problemen — het zijn vijf signalen die samen een compleet beeld geven van dataset health. Een dataset die alle vijf checks doorstaat, is daadwerkelijk gezond. Een dataset die alleen de eerste doorstaat, levert mogelijk onjuiste data aan honderden gebruikers.

De praktische uitdaging is dat elk signaal andere data vereist: API-aanroepen voor refresh status, metadata vergelijking op query-niveau voor schema-wijzigingen, rij-aantallen vergelijken voor volume, tijdstempel analyse voor schedule drift, en watermark inspectie voor staleness. Dit samenvoegen in één monitoring overzicht vereist het integreren van meerdere databronnen.

Voor de meeste teams zijn volume monitoring en stale data detectie de meest waardevolle signalen om als eerste toe te voegen — deze vangen de silent failures met de grootste business impact. Schema-wijziging detectie is kritiek voor teams met frequente upstream wijzigingen. Schedule drift monitoring telt het zwaarst wanneer rapporten harde SLA windows hebben: bestuursrapporten, financiële afsluitingen, dagelijkse operationele dashboards.

Het doel is niet meer complexiteit toevoegen. Het doel is de kloof dichten tussen "de refresh is geslaagd" en "de data is correct."