Fabric Capaciteit Statistieken Uitgelegd: Waar moet je op letten voordat je wordt afgeremd?

Het is woensdag 09:15. Een productmanager opent een Power BI rapport dat is gebaseerd op een semantisch model uit Direct Lake. Het rapport laadt 20 seconden voordat de resultaten verschijnen. Ze vernieuwt het rapport. Dezelfde vertraging. Ze stuurt een bericht naar het datateam: "Power BI is vandaag traag."

De data engineer opent de Fabric Capacity Metrics-app. De gebruiksgrafiek toont een piek die begon om 06:12 — een Spark-notebook die gelijktijdig met drie geplande refreshen van het semantische model werd uitgevoerd. Samen verbruikten ze meer capaciteitseenheden (CU's) dan de Fabric 4-capaciteit in een tijdsbestek van 10 minuten aankon. Fabric heeft de eerste vertragingsfase toegepast: 20 seconden vertraging op alle interactieve bewerkingen.

Niemand heeft een melding ontvangen. De Capacity Metrics-app verstuurt geen notificaties. De piek was al vier uur oud toen iemand het controleerde. Dit is de kloof tussen het beschikbaar hebben van capaciteitsstatistieken en het daadwerkelijk monitoren ervan.

De capaciteit van Microsoft Fabric is een pool van rekencapaciteit die aan je tenant zijn toegewezen en wordt gemeten in capaciteitseenheden (CU's). Elke Fabric-workload – Spark-notebooks, data pipelines, refreshen van semantische modellen, datawarehouse-query's, dataflows – maakt gebruik van deze gedeelde pool. Je koopt een specifieke SKU (F2, F4, F8, F16, enzovoort) en die SKU bepaalt hoeveel CU's per seconde je capaciteit levert.

Een F2 geeft je 2 CU's per seconde. Een F64 geeft je 64. De CU's worden gedeeld over alle workspaces die aan die capaciteit zijn toegewezen. Er is geen isolatie per workload, tenzij je workloads aan afzonderlijke capaciteiten toewijst.

Dit gedeelde model betekent dat een Spark-taak die vastloopt, CU's kan verbruiken die nodig zijn voor de refreshen van je semantische model. Een datawarehouse-query die tijdens piekuren draait, concurreert met je dataflow. De capaciteit maakt geen onderscheid tussen "belangrijk" en "experimenteel" — het wijst CU's toe op basis van wie het eerst komt, en past een beperking toe wanneer het totaal de capaciteit van de SKU overschrijdt.

Elke bewerking in Fabric verbruikt CU-seconden. Een refresh van een semantisch model die 1 CU gedurende 30 seconden gebruikt, verbruikt 30 CU-seconden. Een Spark-notebook dat 10 minuten draait en 4 CU's gebruikt, verbruikt 2400 CU-seconden.

Fabrikant brengt niet al dat verbruik direct in rekening. Het gebruikt smoothing om de kosten over toekomstige tijdstippen te spreiden. Een tijdstip in Fabric duurt 30 seconden – er zijn 2880 tijdstippen in 24 uur.

De smoothing periode is afhankelijk van het type bewerking:

• Interactieve bewerkingen (rapport query's, refreshen op aanvraag, API-aanroepen): gespreid over 5 tot 64 minuten, afhankelijk van het aantal verbruikte CU's.

• Achtergrondbewerkingen (geplande refreshen, Spark-taken, dataflows): gespreid over 24 uur.

Dit is waar capaciteitsplanning minder intuïtief wordt. Een enkele achtergrondtaak die 1 CU-uur (3600 CU-seconden) verbruikt, draagt slechts ongeveer 2,1% bij aan de capaciteit van een F2-processor op een individueel tijdstip. Diezelfde taak op een F64-processor draagt slechts 0,065% per tijdstip bij. Hoe groter je SKU, hoe kleiner de impact van elke bewerking.

Maar smoothing is geen kwijtschelding. Die CU's moeten nog steeds worden afbetaald. Ze accumuleren als "carryforward" en moeten worden afbetaald met toekomstige ongebruikte capaciteit. Als je zware bewerkingen zonder pauzes blijft uitvoeren, groeit de carryforward totdat throttling in werking treedt.

Het praktische gevolg: een Spark-burst van 10 seconden veroorzaakt geen onmiddellijke throttling, maar reserveert wel toekomstige capaciteit. Stapel voldoende bursts achter elkaar en je vult het overschrijdingsvenster van 10 minuten zonder dat één enkele bewerking buitensporig lijkt.

De app Capaciteitsstatistieken is een Power BI app van Microsoft voor capaciteitsbeheerders. De app maakt verbinding met je Fabric-tenant en toont het rekengebruik, de opslag, throttling-gebeurtenissen en uitsplitsingen per bewerking.

Belangrijkste pagina's:

Statuspagina — een overzicht op hoog niveau van alle capaciteiten die je beheert. Toont welke capaciteiten het meeste rekenkracht verbruiken of te maken hebben met throttling.

Rekenpagina — 14 dagen aan gebruiksgegevens. Lintdiagrammen splitsen het CU-verbruik uit per workloadtype (Spark, Warehouse, Semantisch model, Dataflows, AI-functies). De grafiek met de gebruikstrend laat zien wanneer je capaciteit de 100% overschreed. De throttling-grafiek toont welke throttling-fase actief was en hoe lang.

Tijdspuntpagina — zoom in op elk venster van 30 seconden om precies te zien welke bewerkingen hoeveel CU's hebben verbruikt. Hier kunt je specifieke pieken diagnosticeren.

Opslagpagina — 30 dagen aan opslagverbruik per workspace.

Wat de app niet doet:

• Geen waarschuwingen. De eigen documentatie van Microsoft bevestigt: "De Microsoft Fabric Capacity Metrics-app ondersteunt geen waarschuwingen of meldingen." Je moet de app openen en zelf kijken. Als je niet kijkt, weet je het niet.

• Retentie van rekentijd: 14 dagen. Alles ouder dan 14 dagen is verdwenen. Je kunt geen maandelijkse trends analyseren of deze week vergelijken met dezelfde week van vorige maand.

• Geen context voor meerdere tools. De app toont het CU-verbruik per bewerking, maar correleert dit niet met ADF-pipeline runen, dbt-taken of de prestaties van Power BI rapporten. Een piek om 06:12 is slechts een getal; je moet handmatig achterhalen welke pipeline deze heeft veroorzaakt.

• Datavertraging van 10-15 minuten. Gebruiksgegevens worden ongeveer 15 minuten na de activiteit zichtbaar. Een throttling-gebeurtenis om 06:12 wordt op zijn best rond 06:27 weergegeven.

Voor een capaciteitsbeheerder die de app dagelijks controleert, zijn deze beperkingen beheersbaar. Voor een team dat moet reageren op beperkingen voordat gebruikers het merken, zijn ze echter ontoereikend.

Fabric-throttling is een progressief proces. Het weigert bewerkingen niet direct wanneer het gebruik 100% bereikt. In plaats daarvan biedt het een beschermingsperiode van 10 minuten: je capaciteit kan tot 10 minuten aan toekomstige rekeneenheden (CU's) verbruiken zonder dat er sprake is van throttling.

Zodra die periode is verstreken, begint de throttling in fasen:

Fase 1 — Interactieve vertraging (10 min < overschrijding ≤ 60 min) Alle nieuwe interactieve bewerkingen (rapport query's, on-demand refreshen, API-aanvragen) krijgen een vertraging van 20 seconden voordat ze worden uitgevoerd. Achtergrondbewerkingen worden niet beïnvloed. Gebruikers ervaren dit als "Power BI is vandaag traag" zonder een duidelijke foutmelding.

Fase 2 — Interactieve weigering (60 min < overschrijding ≤ 24 uur) Nieuwe interactieve bewerkingen worden direct geweigerd. Gebruikers zien foutcode CapacityLimitExceeded en het bericht "De rekencapaciteit van Fabric van je organisatie heeft de limieten overschreden. Probeer het later opnieuw." Achtergrondprocessen kunnen nog steeds starten.

Fase 3 — Afwijzing achtergrondprocessen (overschrijding > 24 uur) Alle nieuwe verzoeken — zowel interactieve als achtergrondprocessen — worden afgewezen. Geplande refreshen mislukken. Spark-taken starten niet. De capaciteit wordt in feite bevroren totdat de opgebouwde overschrijding is weggewerkt door inactiviteit.

Bewerkingen die al in uitvoering zijn, worden nooit afgeremd. Een Spark-notebook dat vóór de afremming is gestart, wordt voltooid. Dit voorkomt gegevensverlies, maar betekent ook dat langlopende taken CU's blijven verbruiken, waardoor de afremmingsperiode mogelijk wordt verlengd.

De belangrijkste indicatoren om in de gaten te houden: het verbruik van je capaciteit in CU's ten opzichte van de tijdsvensters van 10 minuten, 60 minuten en 24 uur. De Capacity Metrics-app toont dit als percentages op de grafiek voor het beperken van de capaciteit. Wanneer de lijn van 10 minuten de 100% nadert, is fase 1 aanstaande.

Drie patronen zijn verantwoordelijk voor de meeste ongeplande throttling-gebeurtenissen op middelgrote Fabric capaciteiten (F4 tot en met F64):

Gelijktijdige geplande refreshen in hetzelfde tijdsvenster. Veel teams plannen refreshen van semantische modellen om 06:00 uur, omdat dan de brongegevens binnenkomen. Vier semantische modellen die tegelijkertijd worden vernieuwd op een F4 kunnen de buffer van 10 minuten gemakkelijk overschrijden. De oplossing: spreid de refreshen met 5-10 minuten, of verplaats grote modellen naar de achtergrondplanning.

Spark-notebooks zonder CU-budgetten. Een data scientist die tijdens kantooruren een verkennend notebook uitvoert, kan in korte bursts honderden CU-seconden verbruiken. Omdat interactieve Spark-bewerkingen slechts over 5-64 minuten worden gespreid, heeft dit snel impact op de capaciteit. De oplossing: wijs experimentele workloads toe aan een aparte capaciteit met lage prioriteit, of plan zware notebooks als achtergrondtaken.

Datawarehouse-query's tijdens piekuren voor rapporten. Als je datawarehouse onderhoudsquery's uitvoert (tabeloptimalisatie, herberekening van statistieken) tijdens dezelfde uren dat gebruikers rapporten opvragen, concurreren beide om dezelfde CU-pool. Warehouse-bewerkingen worden geclassificeerd als achtergrondbewerkingen en verdeeld over 24 uur, wat helpt, maar een voldoende grote query draagt nog steeds aanzienlijk bij aan het venster van 10 minuten.

Het patroon bij alle drie de gevallen: meerdere soorten workloads concurreren om een gedeelde pool zonder coördinatie. De Capacity Metrics-app kan je dit achteraf laten zien. Proactieve monitoring betekent dat je weet dat dit nu gebeurt.

Als je verder niets controleert, houd dan deze vier signalen in de gaten:

1. Piekgebruik van de CU (venster van 10 minuten) Dit is de metriek die bepaalt of fase 1-throttling wordt geactiveerd. Op de compute-pagina van de Capacity Metrics-app toont de gebruiksgrafiek de overschrijding van de capaciteit over een periode van 10 minuten als percentage. Wanneer dit consistent boven de 80% ligt, hebt je beperkte speelruimte voor onverwachte pieken.

2. Throttle-gebeurtenissen per dag De tabel Systeemgebeurtenissen op de compute-pagina registreert wanneer throttling-fasen zijn geactiveerd. Eén throttle-gebeurtenis per week op een F4 kan acceptabel zijn. Dagelijkse throttle-gebeurtenissen geven aan dat je capaciteit ondergedimensioneerd is voor je workloadpatroon, of dat de planning moet worden aangepast.

3. Minuten tot burndown Wanneer je doorklikt naar de throttling-grafiek, toont Fabric een geschatte "minuten tot burndown" - hoe lang het zou duren voordat de capaciteit terugkeert naar een niet-gethrottlede status als er geen nieuwe bewerkingen worden uitgevoerd. Als dit aantal langer is dan 60 minuten, bouwt je sneller ongebruikte CU's op dan je ze afbetaalt.

4. Grootste CU-verbruikers per item De matrix per item en bewerking op de rekenpagina toont het cumulatieve CU-verbruik over 14 dagen. Identificeer welke items consistent de boventoon voeren. Een enkel semantisch model dat 40% van je capaciteit aan CU's verbruikt, komt in aanmerking voor optimalisatie of capaciteitssplitsing.

De uitdaging: je moet de Capacity Metrics-app raadplegen om dit te zien. Er is geen pushmelding wanneer je 10-minutengebruik de 80% overschrijdt. Er is geen e-mail wanneer er een throttling-gebeurtenis plaatsvindt. Je moet zelf een pollingmechanisme bouwen, of accepteren dat throttling door gebruikers wordt ontdekt voordat het datateam het merkt.

MetricSign maakt verbinding met je Fabric capaciteit via dezelfde beheerders-API's die de Capacity Metrics-app gebruikt. Het verschil: MetricSign controleert continu en stuurt waarschuwingen door voordat het overschrijdingsvenster vol is.

Een concreet voorbeeld: je F8-capaciteit bereikt 75% van het CU-budget van 10 minuten om 06:14 uur, omdat twee geplande refreshen en een Spark-notebook binnen 90 seconden na elkaar zijn gestart. MetricSign detecteert de versnelling, berekent de verwachte overschrijding op basis van het huidige verbruik en stuurt om 06:15 uur een Telegram-waarschuwing naar het data engineering-kanaal – voordat het 10-minutenvenster vol is en voordat er interactieve vertragingen optreden.

De waarschuwing bevat: welke bewerkingen momenteel de meeste CU's verbruiken, welke downstream-rapporten worden beïnvloed als er sprake is van throttling, en een link naar het specifieke tijdstip in de Capacity Metrics-app voor nader onderzoek.

Dit is geen vervanging voor de Capacity Metrics-app. De app blijft de beste tool voor historische analyses en capaciteitsplanning. MetricSign voegt toe wat de app mist: realtime waarschuwingen met context over verschillende stacks heen. Wanneer een Spark-notebook throttling veroorzaakt waardoor een Power BI rapport niet wordt vernieuwd, koppelt MetricSign beide gebeurtenissen in één incident – in plaats van ze als afzonderlijke items in aparte tools weer te geven.

Een belangrijke beperking: MetricSign monitort capaciteitsstatistieken met dezelfde datavertraging van 10-15 minuten als de Capacity Metrics-app. Het kan niet sneller waarschuwingen geven dan Microsoft de gegevens beschikbaar stelt. Voor bijna realtime inzicht is het polling-interval van de Admin API de bottleneck, niet MetricSign.

MetricSign is gratis te gebruiken, maakt binnen 10 minuten verbinding met je Fabric capaciteit en begint met monitoren zonder dat je je bestaande workloads of planningen hoeft aan te passen.