Practice 1: Meer dan alleen refresh status monitoren
De ingebouwde meldingen van Power BI laten u weten wanneer een refresh mislukt. Ze laten u niet weten wanneer een refresh slaagt maar onjuiste data laadt. Begin met het toevoegen van drie checks aan uw monitoring stack.
Rij-aantallen vergelijken: Vergelijk na elke refresh het aantal geladen rijen met de vorige refresh. Geef een alert bij dalingen groter dan een drempelpercentage. Welke drempel passend is hangt af van uw dataset — 10% is een redelijk uitgangspunt voor grote fact tables. Lookup tables vereisen een strakker bereik.
Watermark check: Controleer voor elke dataset die incrementele data laadt de maximale waarde van het meest recente datumveld. Als een refresh is voltooid maar de maximale datum niet is opgeschoven, zijn de nieuwe data verouderd — ook al is de refresh technisch geslaagd.
Refresh duration trend: Houd bij hoe lang elke refresh duurt over tijd. Een refresh die vroeger 8 minuten kostte en nu 45 minuten nadert een timeout. Pak de trend aan voordat het een failure wordt.
De implementatie hoeft niet complex te zijn. Een script dat na elke refresh de Power BI REST API raadpleegt, het resultaat vergelijkt met de vorige run en een vlag schrijft naar een monitoring table is een werkend startpunt. Van daaruit kunt u verder bouwen.
Practice 2: Schema wijzigingen bijhouden
Schema wijzigingen zijn een van de snelste manieren om een Power BI report te breken, en ze zijn bijna altijd upstream ontstaan — in een SQL Server database, een dbt model, een Azure Synapse view of een SharePoint lijst. Tegen de tijd dat de wijziging Power BI bereikt, kan het model bij de laatste refresh al onjuiste data hebben geladen.
Stel schema wijzigingsdetectie in door:
- Een baseline vast te leggen van de kolommen en datatypes die elke data source query retourneert in de laatste bekende correcte staat
- Na elke refresh de werkelijke kolommen te vergelijken met de baseline
- Direct een alert te genereren als een kolom verdwijnt, hernoemd wordt of van type verandert
- Ook een alert te genereren als er een nieuwe kolom verschijnt die nog niet in het model is opgenomen — een gemiste kans in plaats van een failure, maar wel de moeite waard om te weten
Voor teams die dbt Cloud of dbt Core gebruiken is het manifest bestand een waardevol upstream signaal. Het manifest documenteert elke kolom in elk model, inclusief beschrijvingen en datatypes. Wanneer het manifest wijzigt — doordat een dbt model is aangepast — kunt u voor en na vergelijken om te begrijpen wat er upstream is veranderd, vóór de Power BI refresh wordt uitgevoerd.
Schema drift detecteren vóór een refresh is beter dan erna. Een lineage-aware monitoring systeem kan een alert geven: "het dbt model dat deze dataset voedt heeft zijn schema gewijzigd — controleer dit vóór de geplande refresh om 06:00."
Practice 3: Volume baselines per dataset instellen
Volume baselines beantwoorden een fundamentele vraag: bevat deze dataset ongeveer de juiste hoeveelheid data? Dit goed doen vereist nadenken over wat 'juist' betekent voor elke specifieke dataset — niet één regel toepassen op uw hele Power BI omgeving.
Voor een dagelijkse transactie fact table kan het juiste volume zijn: 'binnen 20% van het gemiddelde rij-aantal voor deze dag van de week.' Weekenden hebben andere volumes dan weekdagen. Vakantieperiodes verschillen van normale weken. Een goede baseline houdt rekening met deze patronen door een dag-van-de-week-bewust voortschrijdend gemiddelde te gebruiken in plaats van een eenvoudig 7-daags gemiddelde.
Voor een slowly-changing dimension table is het juiste volume: 'mag nooit met meer dan een handvol rijen afnemen, en moet gestaag groeien over tijd.' Een plotselinge daling in een dimension table is bijna altijd een data kwaliteitsprobleem.
Voor een snapshot table die bij elke refresh volledig opnieuw wordt geladen is het juiste volume: 'moet binnen een smal bereik van de vorige refresh liggen.' Als een volledig herladen snapshot plotseling 30% van de rijen verliest, zijn de brondata aanzienlijk gewijzigd of is een query filter per ongeluk verkeerd geconfigureerd.
Begin eenvoudig: houd rij-aantallen per dataset per refresh bij, bereken een voortschrijdend 7-daags gemiddelde en geef een alert bij afwijkingen groter dan 15%. Pas de drempelwaarden in de loop van de tijd aan naarmate u de natuurlijke variatie van elke dataset leert kennen. Vroege false positives zijn waardevol — elk geval leert u iets over hoe uw data zich daadwerkelijk gedraagt.
Practice 4: End-to-end latentie monitoren
Power BI gebruikers geven om één ding: zijn de data actueel wanneer ze het report openen? Het antwoord hangt af van de hele keten — wanneer het bronsysteem is bijgewerkt, hoe lang de pipeline erover deed, hoe lang Power BI nodig had voor de refresh. Elk onderdeel afzonderlijk monitoren vertelt u niet of de end-to-end SLA is gehaald.
End-to-end latency monitoring vereist het bijhouden van:
- Wanneer de brondata voor het laatst is bijgewerkt (de data watermark in het bronsysteem)
- Wanneer de pipeline is voltooid (ADF run voltooiingstijd)
- Wanneer de Power BI refresh is voltooid
- Het totale verschil van bronupdate tot data beschikbaar in report
Voor de meeste teams hoeft dit geen real-time systeem te zijn. Een dagelijkse check die bevestigt 'deze dataset is vernieuwd binnen 2 uur nadat brondata beschikbaar was' is een aanzienlijke verbetering ten opzichte van aannemen dat alles goed gaat.
De ketens met het hoogste latency risico zijn die met meerdere hops: bron → ADF → Azure SQL → Synapse Analytics → Power BI dataset → report. Elke hop voegt verwerkingstijd en een potentieel vertragingspunt toe. Wanneer de end-to-end 4 uur duurt en uw refresh window om 06:00 staat voor een report om 08:00, is er geen buffer. Elke vertraging in de keten laat de SLA zakken.
Latency monitoring onthult ook optimalisatiemogelijkheden. Als uw end-to-end 3 uur duurt maar 80% daarvan Power BI verwerkingstijd is, heeft het toevoegen van resources aan de Power BI capacity meer impact dan het optimaliseren van de ADF pipeline.
Practice 5: Een incident response playbook bouwen
Practices 1–4 verminderen de frequentie en ernst van data incidents. Practice 5 is voor wanneer ze toch optreden: zorg dat er een gedocumenteerd proces klaarstaat vóór het telefoontje van maandagochtend 06:45, niet tijdens het gesprek zelf.
Een minimaal playbook omvat vijf punten: de drempel voor escalatie versus stilzwijgend onderzoek, een triage checklist voor de eerste diagnostische stappen, welke reports getroffen zijn en wie dat moet weten, herstelopties met realistische tijdschattingen en communicatiesjablonen voor verschillende stakeholder groepen. Voor het volledige stap-voor-stap framework — van detectie tot postmortem — zie Incident response voor data pipeline failures inrichten.