Monitoring van Microsoft Fabric: Wat native tools missen en hoe je die hiaten kunt opvullen

Het is woensdag 06:47. je Fabric capaciteit draait op volle toeren met 84% CU-gebruik. De Lakehouse-pipeline die verkoopgegevens laadt vanuit een Snowflake-bron is om 06:00 voltooid. Het Power BI Direct Lake-rapport erbovenop wordt een paar minuten later vernieuwd. Om 08:30 opent de CFO het rapport op haar telefoon en het jaarcijfer lijkt € 1,4 miljoen te laag.

De pipeline is niet mislukt. De capaciteit is niet beperkt. Workspace Monitoring toont geen fouten. Het rapport is nog steeds onjuist.

Wat er is gebeurd: de upstream Snowflake-tabel heeft een partitie verloren tijdens een reorganisatie op dinsdagavond, de Lakehouse-kopieerstap heeft 320.000 rijen minder opgehaald dan de baseline van de afgelopen 30 dagen, en Direct Lake heeft de kleinere dataset zonder problemen aan Power BI geleverd. Alle native Fabric-interfaces meldden succes.

Dit is de kloof die de term 'Microsoft Fabric-monitoring' probeert te overbruggen, en het is de kloof waar de meeste teams die Fabric-workloads in productie draaien binnen een kwartaal tegenaan lopen. De native tools doen hun werk. Ze vertellen je wat er is uitgevoerd en hoeveel capaciteit het heeft gebruikt. Ze vertellen je niet of de gegevens correct zijn, of Direct Lake verouderde cijfers levert, of dat de fout die zojuist in je Snowflake-taak is opgetreden, Power BI binnen 90 minuten zal bereiken.

Fabric biedt drie verschillende monitoring interfaces. Elk heeft een duidelijke functie. Geen van deze interfaces is ontworpen om met elkaar te communiceren.

De Monitoring Hub — realtime activiteitsregistratie

De Monitoring Hub is de operationele weergave. Open deze en je ziet alle recent uitgevoerde items in de werkruimten waartoe je toegang hebt: pipelines, dataflows, refreshen van semantische modellen, notebooks en Spark-taken. Je kunt filteren op status, item type, capaciteit en tijdsbereik, en op een individuele uitvoering klikken om het logboek te bekijken.

De Hub is handig voor twee dingen: het prioriteren van wat er momenteel draait en het opzoeken waarom een specifiek item gisteren is mislukt. De Hub is niet geschikt voor trendanalyse, waarschuwingen of iets anders waarbij gegevens van verschillende items gecombineerd moeten worden. Microsoft beschrijft de Hub als een plek om 'Fabric-activiteit te bekijken en te volgen', wat een eerlijke beschrijving is — het toont je activiteit, maar interpreteert deze niet.

Werkruimtemonitoring — logboeken en statistieken op werkruimteniveau

Werkruimtemonitoring is de diepere laag. Wanneer je Fabric inschakelt in een werkruimte, schrijft het operationele logboeken en statistieken naar een beheerde Eventhouse, die via KQL kan worden opgevraagd. Je krijgt een uitvoeringsgeschiedenis op item niveau, query prestaties en (afhankelijk van het item type) diagnostische gegevens per rij, met een standaard bewaartermijn van maximaal 30 dagen.

Dit is waar teams die al vertrouwd zijn met Kusto veel waarde uit halen. Je kunt een KQL-query schrijven die verversingsfouten koppelt aan capaciteitsgebeurtenissen, hierop een melding genereren via Activator of een Reflex-item en de melding doorsturen naar Teams. Het nadeel is dat je iemand in het team nodig hebt die daadwerkelijk KQL schrijft, de meldingsdefinities beheert en deze actueel houdt wanneer item typen en logboek schema's veranderen. Voor een kleiner datateam betekent dit weer een extra systeem om te onderhouden.

De Fabric Capacity Metrics-app

De Capacity Metrics-app is een Power BI app die telemetriegegevens van je Fabric capaciteit leest en het CU-verbruik, throttling-gebeurtenissen en uitsplitsingen op item niveau in de loop van de tijd weergeeft. Dit is de enige plek waar je kunt zien hoe een specifieke Spark-taak of een refresh van een semantisch model heeft bijgedragen aan een throttling-gebeurtenis afgelopen dinsdag om 14:00 uur. We zullen de beperkingen ervan in een aparte sectie bespreken.

De meeste standaard monitoringvragen in Fabric komen uiteindelijk neer op capaciteitsvragen. Als je niet weet hoe CU-smoothing en -bursting werken, zullen capaciteitswaarschuwingen ofwel constant afgaan, ofwel helemaal niet.

SKU's, CU-bursting en -throttling uitgelegd

De capaciteit van Fabric wordt bepaald in capaciteitseenheden (CU). De SKU die je koopt – F2, F4, F8, tot en met F2048 – stelt een CU-budget per seconde in. Items verbruiken CU wanneer ze worden uitgevoerd. Een zware Spark-notebook kan in 30 seconden meerdere minuten van je capaciteitsbudget verbruiken; een Direct Lake-query is nauwelijks merkbaar.

Fabrikant stopt je niet zodra je je budget per seconde overschrijdt. Het gebruikt twee mechanismen om pieken op te vangen:

• Bursting zorgt ervoor dat een enkele bewerking meer dan het budget per seconde kan gebruiken, zodat een Spark-taak van 90 seconden kan worden voltooid, zelfs als deze tijdelijk 4 keer je normale CU gebruikt.

• Smoothing spreidt de kosten van achtergrondbewerkingen (verversingen, geplande pipelines) over een periode van 24 uur, zodat een zware nachtelijke belasting de interactieve gebruikers niet om 09:00 uur afremt.

Wanneer het gesmoothde verbruik lang genoeg boven de 100% van de SKU blijft, treedt throttling in werking. Microsoft beschrijft drie throttling fasen: interactieve vertraging (bewerkingen die tot 20 seconden in de wachtrij staan), interactieve afwijzing (nieuwe query's worden geweigerd) en achtergrond afwijzing (geplande verversingen worden geweigerd). De volgorde is belangrijk omdat gebruikers interactieve vertraging als eerste ervaren: het dashboard wordt trager voordat verversingen mislukken.

Fabric versus Synapse: wat is er veranderd voor monitoring?

Als je migreert van Synapse, is het denkkader anders. Synapse Dedicated SQL Pools werden gefactureerd per DWU en per query, en Azure Monitor met diagnostische instellingen verzorgde het grootste deel van de observatielaag. Fabric combineert opslag en rekenkracht in één capaciteit, waardoor er geen aparte DWU-instellingen zijn en er geen overzicht van de kosten per query in de Azure-portal beschikbaar is.

Het gevolg hiervan voor monitoring is dat de patronen die je kende van Synapse – Log Analytics instellen, een KQL-waarschuwing schrijven voor langlopende query's, oproepdiensten oproepen – alleen naar Fabric overdraagbaar zijn als je Werkruimtebewaking inschakelt en de waarschuwingen daar opnieuw configureert. Azure Monitor heeft geen inzicht in de inhoud van een Fabric capaciteit. Voor migratieteams is dit de grootste uitdaging waar ze rekening mee moeten houden.

De Capacity Metrics-app is de meest geciteerde native tool voor Fabric-monitoring. Het is ook de bron van meer gefrustreerde Reddit-threads dan welk ander onderdeel van het platform dan ook. Beide beweringen kloppen.

De Fabric Capacity Metrics-app: installatie, beperkingen en oplossingen

De installatie is eenvoudig. Installeer de app via AppSource, koppel deze aan een capaciteits-ID en verleen de benodigde machtigingen. Na ongeveer 30 minuten heb je een Power BI rapport met drie pagina's: een overzicht van meerdere statistieken, een detailweergave van een tijdstip die laat zien wat er draaide tijdens een throttling-gebeurtenis, en een uitsplitsing van de berekeningen per item.

Wat de app goed doet: het is de enige ingebouwde interface die een specifieke item uitvoering koppelt aan een specifieke throttling-fase. Als je capaciteit om 14:07 uur interactieve afwijzing bereikte, laat de tijdsweergave zien welke Spark-notebook en welke dataset verversing op dat moment CU gebruikten.

Wat de app niet doet:

• Geen waarschuwingen. De app is een rapport, geen waarschuwingssysteem. Je kunt een tegel vastpinnen en deze twee keer per dag bekijken, maar er is geen ingebouwde route van 'capaciteit op 95% gedurende 10 minuten' naar een Teams-bericht.

• Geen trendtracking langer dan 14 dagen. De detailweergave beperkt zich tot 14 dagen aan historische gegevens; het overzicht met meerdere statistieken gaat verder, maar met minder detail. Capaciteitsplanning op lange termijn vereist het exporteren van de gegevens of het doorsturen van de onderliggende logboeken naar Log Analytics.

• Geen cross-item lineage. De app laat zien dat een Spark-notebook 4 minuten heeft gedraaid en 320 CU-seconden heeft verbruikt. Het laat niet zien welke downstream semantische modellen of Direct Lake-rapporten afhankelijk zijn van de output van die notebook.

• Ongeveer 30 minuten vertraging. Telemetriegegevens hebben tijd nodig om in de onderliggende dataset van de app terecht te komen. Voor incident respons betekent 30 minuten het verschil tussen het detecteren van een probleem en het lezen ervan in Slack.

Blinde vlekken — wat de native tools je niet vertellen

Drie hiaten komen steeds terug in de drie bovenstaande tools:

1. Data correctheid. Geen enkele native tool signaleert lege datasets, schema-afwijkingen of volume-anomalieën. Een Lakehouse-kopie die 0 rijen laadt, wordt als een succesvolle run beschouwd.

1. Cross-stack-herkomst. Als je data begint in Snowflake of Azure Data Factory en eindigt in een Direct Lake-rapport, ziet geen enkele Fabric-tool het eerste deel van het traject.

1. Proactieve routering. Native tools wachten tot je ernaar kijkt. Er is geen ingebouwd concept van 'waarschuw de dienstdoende data-engineer wanneer deze specifieke dataset om 06:30 uur nog niet is vernieuwd'.

Een effectieve Fabric-monitoringstrategie gaat ervan uit dat de native tools input zijn, niet de oplossing. De taak is om ze te combineren met drie dingen die ze op zichzelf niet bieden: waarschuwingen, cross-stack lineage en actualiteitscontroles.

Het combineren van native metrics met externe observability

Een patroon dat werkt voor de meeste data-teams in het middensegment die Fabric gebruiken:

1. Gebruik de Monitoring Hub voor live triage tijdens incidenten. Houd deze open in een tabblad; probeer er geen dashboard van te maken.

1. Schakel Workspace Monitoring in voor elke productiewerkruimte en stuur de logboeken door naar een Log Analytics-werkruimte als je een bewaartermijn van meer dan 30 dagen nodig hebt. Microsoft beschrijft het pad voor de diagnostische instellingen; het is één configuratiewijziging per werkruimte.

1. Gebruik de Capacity Metrics-app voor wekelijkse capaciteitsbeoordelingen en analyse na incidenten. Vertrouw er niet op voor realtime waarschuwingen.

1. Voeg een externe observatietool (of een zelfontwikkelde KQL-waarschuwingsconfiguratie als je een Kusto-specialist hebt) toe met twee specifieke taken: het detecteren van afwijkingen die de native tools niet kunnen zien en het doorsturen van waarschuwingen naar het kanaal dat je team daadwerkelijk leest.

Waarschuwingen bij capaciteitsoverschrijdingen voordat gebruikers het merken

Het tijdsvenster tussen 'capaciteit bereikt 95% gedurende 10 minuten' en 'gebruikers klagen dat Power BI traag is' is waar waarschuwingen hun nut bewijzen. Een werkbare drempelregel ziet er als volgt uit:

• Waarschuwing bij 85% afgevlakte capaciteit gedurende 10 minuten (geeft je tijd om onderzoek te doen).

• Pagina weergeven bij 95% afgevlakte capaciteit gedurende 5 minuten (interactieve vertraging dreigt).

• Neem altijd de top 3 items op basis van capaciteitsverbruik op in de waarschuwingspayload, zodat de gebruiker de app Capaciteitsstatistieken niet helemaal opnieuw hoeft te openen.

Dit is geen functie die standaard in de tools is opgenomen. Het is een regel die je zelf opstelt, ofwel in de KQL-waarschuwingslaag van Workspace Monitoring, ofwel in een externe tool die dezelfde telemetriegegevens uitleest.

MetricSign bevindt zich boven Fabric en de rest van je stack, leest de telemetrie van elke laag en koppelt technische gebeurtenissen aan de impact op de bedrijfsvoering. Specifiek voor Fabric monitort het drie zaken die de native tools niet tegelijkertijd weergeven.

Capaciteitsgebeurtenissen met context voor de downstream-processen. Wanneer een capaciteit de interactieve afwijzingsdrempel bereikt, koppelt MetricSign aan welke Direct Lake-rapporten door die capaciteit worden verwerkt en welke managers die rapporten hebben vastgezet. De melding luidt: 'F32-capaciteit op 96% gedurende 7 minuten — 4 rapporten getroffen, waaronder het wekelijkse dashboard van de CFO. Belangrijkste belasting: notebook nb-sales-aggregation, 480 CU-seconden in de laatste 5 minuten.'

Volume- en actualiteitsafwijkingen bij Lakehouse-loads. MetricSign volgt een voortschrijdende baseline van 30 dagen voor het aantal rijen en laadtijdstempels op Lakehouse- en Warehouse-tabellen. Wanneer de Snowflake-reorganisatie op dinsdagavond 320.000 rijen uit een feed verwijdert, signaleert MetricSign de afwijking vóór de Direct Lake-verversing van 06:00 uur. De melding vermeldt de brontabel, de afwijking en de downstream-rapporten.

Cross-stack lineage van bron tot rapport. Als de fout begint in Azure Data Factory, Snowflake of Databricks, traceert MetricSign deze via dbt-modellen en Lakehouse-kopieën naar het semantische model en het Direct Lake-rapport. Eén melding vermeldt de hoofdoorzaak en de getroffen rapporten, in plaats van drie afzonderlijke meldingen van drie tools die elkaar niet kennen.

Meldingen worden doorgestuurd naar Teams, Slack, Telegram of PagerDuty. De installatie maakt binnen ongeveer 15 minuten verbinding met een Fabric-tenant via een service principal — geen agents, geen herschrijvingen van pipelines. Zie end-to-end data lineage from ADF to Power BI voor een voorbeeld van hoe de lineage-laag in de praktijk werkt.

Twee eerlijke beperkingen.

Het KQL-endpoint van Workspace Monitoring is de meest uitgebreide native optie die Fabric biedt. Als je een Kusto-specialist in je team hebt, een beveiligingsmodel dat loggegevens binnen Fabric bewaart en het geduld om alerting op basis van KQL te bouwen, kun je het grootste deel van de weg afleggen zonder een externe tool. MetricSign is handig als je die persoon niet hebt, als de data lineage buiten Fabric moet worden verwerkt (bijvoorbeeld naar Snowflake, ADF of Databricks), of als alert routing naar Slack/Teams/Telegram moet plaatsvinden vóór het volgende refreshvenster.

MetricSign heeft ook geen inzicht in de code van Spark-notebooks. Als een notebook stilletjes onjuiste waarden schrijft vanwege een bug in de transformatielogica, detecteert geen enkele monitoringtool – native of extern – dit zonder expliciete datakwaliteitstests in de pipeline. Detectie van volume- en actualiteitsafwijkingen detecteert een ander soort problemen.

Fabric Monitoring is niet één product dat één functie mist. Het bestaat uit drie native interfaces die elk een deel van de data bestrijken en ervan uitgaan dat je ze met KQL en handmatige triage aan elkaar koppelt. Voor sommige teams is die koppeling de juiste oplossing. Voor de meeste datateams die mixed-stack pipelines naar Fabric draaien, is het ontbrekende stukje de connector tussen technische gebeurtenissen binnen Fabric en de zakelijke impact twee lagen verderop.