De meldingen van Fabric gaan over wat er is gebeurd, niet over wat er niet is gebeurd.
Een terugkerende vraag op de Fabric-communityforums legt een hiaat bloot dat de meeste teams pas ontdekken nadat ze in productie zijn gegaan: hoe word je gewaarschuwd als een bestand dat tussen 16:00 en 20:00 uur had moeten aankomen, nooit verschijnt? De waarschuwingsmechanismen van Fabric – geplande meldingen van mislukte pipelines, Data Activator-regels voor jobgebeurtenissen, KQL-query's op werkruimteniveau – reageren allemaal op gebeurtenissen die wél hebben plaatsgevonden. Een pipeline mislukt en je ontvangt een e-mail. Een pipeline slaagt na 90 minuten in plaats van 30, en een operations agent signaleert de anomalie. Maar als Event Grid nooit wordt geactiveerd omdat het upstream-systeem nooit een bestand in ADLS heeft geplaatst, merkt niets in de native stack van Fabric de afwezigheid op.
Dit is de fundamentele architectuurfout. SLA-monitoring draait om de niet-gebeurtenis: het bestand dat niet is aangekomen, de pipeline die niet is geactiveerd, de refresh die niet is gestart. De Eventhouse-monitoring van Fabric schrijft naar de tabel ItemJobEventLogs, waarin JobStatus-waarden zoals Failed, Completed en In progress worden vastgelegd. Er is geen rij voor een taak die verwacht werd maar nooit is gestart.
De eenvoudigste foutmelding – het configureren van e-mailwaarschuwingen onder Home > Planning > Foutmeldingen voor een pipeline – wordt alleen geactiveerd bij expliciete fouten van geplande uitvoeringen. Als je pipeline via Eventstream wordt geactiveerd door een gebeurtenis en de gebeurtenis nooit aankomt, wordt de pipeline nooit uitgevoerd en wordt er geen fout geregistreerd. Je komt pas de volgende ochtend achter het probleem wanneer een stakeholder een Power BI rapport opent en de cijfers van gisteren ziet.
Drie waarschuwingslagen en de naden daartussen.
Fabric biedt waarschuwingen op drie niveaus, elk met eigen mechanismen en blinde vlekken.
Waarschuwingen op activiteitsniveau gebruiken Outlook- of Teams-activiteiten die zijn gekoppeld na specifieke pipeline-activiteiten. Ze worden direct tijdens de uitvoering geactiveerd, waardoor ze betrouwbaar zijn voor het signaleren van de voltooiing van een kritieke fase. De beperking is het bereik: je moet ze handmatig aan elke pipeline koppelen en ze kunnen geen pipeline detecteren die nooit is gestart.
Data Activator-regels op item niveau reageren op gebeurtenissen van Fabric-werkruimte-items: taak geslaagd, taak mislukt, item aangemaakt, item verwijderd. Je maakt een Activator-item aan, selecteert Gegevens ophalen > Taakgebeurtenissen, kiest een pipeline en definieert een regel met een actie (e-mail, Teams-bericht of het starten van een ander Fabric-item). Dit werkt goed voor individuele pipelines, maar het bereik is per item. De Fabric-documentatie bevestigt dat gebeurtenissen in Data Activator op item niveau zijn gescopeerd, wat betekent dat elke pipeline afzonderlijk moet worden geselecteerd. Er is geen wildcard of werkruimtebrede abonnementsmogelijkheid via deze weg.
Monitoring op werkruimteniveau dicht het gat in het bereik. Wanneer je werkruimtebewaking inschakelt, schrijft Fabric run logen naar een Eventhouse KQL-database. Je schrijft een KQL-query voor ItemJobEventLogs, koppelt deze aan een Activator-regel en ontvangt waarschuwingen voor elke pipeline in de werkruimte vanuit één enkele regel. De referentiequery filtert waar JobType == 'Pipeline' en JobStatus == 'Failed' binnen een rollend tijdsvenster (SecondsAgo <= 540). Dit is krachtig, maar het polling-interval is belangrijk: als Activator minder vaak pollt dan je KQL-venster, mist je waarschuwingen of ontvangt je dubbele waarschuwingen. De documentatie van Microsoft zelf waarschuwt dat als Activator is gepauzeerd of uitgeschakeld, verwachte waarschuwingen worden gemist.
De overgang tussen deze lagen is waar SLA-bewaking zich bevindt — en die wordt door geen van deze lagen standaard gedekt.
Het bouwen van de klok voor ontbrekende bestanden met Event Grid en KQL.
Om een bestand te detecteren dat had moeten aankomen maar dat niet is gebeurd, moet je een timer buiten het job event-systeem van Fabric bouwen. De architectuur waar de Fabric-community het over eens is, maakt gebruik van drie componenten: Event Grid voor het detecteren van de aankomst van bestanden, een Eventhouse-tabel voor het loggen van aankomsten en een KQL-query die controleert op hiaten.
Begin met het routeren van ADLS-blob-gebeurtenissen via Event Grid naar een Fabric Eventstream. Configureer de Eventstream om elke gebeurtenis naar een aangepaste KQL-tabel te schrijven – noem deze FileArrivalLog – met kolommen voor FileName, ContainerPath, ArrivalTimestamp en EventId. Dit geeft je een overzicht van wat er daadwerkelijk is aangekomen.
Maak vervolgens een referentietabel aan – ExpectedFileSchedule – die je SLA-contracten definieert: welke bestanden worden verwacht, in welke containerpaden en binnen welke tijdsvensters. Een rij kan specificeren dat sales_daily_extract.parquet verwacht wordt in /landing/sales/ tussen 16:00 en 20:00 UTC elke werkdag.
De detectiequery koppelt deze twee tabellen:
``` let SLAWindow = ago(4h);
ExpectedFileSchedule | where ExpectedBy <= now() and ExpectedAfter >= SLAWindow | join kind=leftanti ( FileArrivalLog
| where ArrivalTimestamp between (SLAWindow .. now()) ) on FileName, ContainerPath | project FileName, ContainerPath, ExpectedBy, AlertTime=now() ```
Dit retourneert bestanden die binnen het SLA-venster verwacht werden, maar waarvoor geen overeenkomend aankomstrecord bestaat. Koppel deze query aan een Activator-regel die elke 10 minuten een polling uitvoert, en je hebt detectie van ontbrekende bestanden. Het cruciale detail is de leftanti-join — deze genereert alleen rijen voor gevallen waarin er geen overeenkomst is, wat precies de niet-gebeurtenis is die je wilt detecteren.
Om dubbele waarschuwingen te voorkomen (de oorspronkelijke poster vroeg specifiek om één waarschuwing per SLA-schending, niet om herhaalde meldingen), voegt je een SLABreachLog-tabel toe. Nadat elke waarschuwing is geactiveerd, schrijft je de schending naar deze tabel en voegt je een leftanti-filter toe aan je detectiequery.
Stille trigger fouten vereisen een tweede waakhond.
Ontbrekende bestanden zijn één mogelijke oorzaak van een fout. Een subtielere oorzaak is dat het bestand op tijd aankomt, Event Grid een trigger activeert, maar de trigger van Eventstream naar pipeline stilzwijgend mislukt. Dit kan gebeuren wanneer Eventstream tijdelijke vertragingen ondervindt bij het verwerken van gegevens, wanneer de trigger conditie van de pipeline niet overeenkomt met het gebeurtenisschema, of wanneer capaciteitsbeperkingen de uitvoering van taken onderbreken.
Om dit te detecteren, moet je twee gebeurtenisstromen correleren: de aankomst van bestanden in je FileArrivalLog en de uitvoering van pipelines in ItemJobEventLogs. Het querypatroon is vergelijkbaar — een tijdgebonden leftanti-join — maar nu join je op een gedeelde sleutel tussen de bestandsgebeurtenis en de pipeline run. Als je pipelines consistent zijn benoemd (bijv. ingest_sales_daily), kunt je joinen op een afgeleide sleutel van FileName naar ItemName.
`` FileArrivalLog | where ArrivalTimestamp between (ago(30m) .. ago(5m)) | extend ExpectedPipeline = strcat('ingest_', extract('(.+)_extract', 1, FileName)) | join kind=leftanti ( ItemJobEventLogs
| where JobType == 'Pipeline'
| where Timestamp >= ago(30m)
| project ItemName, Timestamp ) on $left.ExpectedPipeline == $right.ItemName | project FileName, ArrivalTimestamp, ExpectedPipeline, AlertTime=now() ```
De buffer ago(5m) geeft de pipeline de tijd om te starten voordat deze als ontbrekend wordt gemarkeerd. Stem dit af op basis van de waargenomen trigger latentie. In workspaces met een hoge gelijktijdigheid plaatst Fabric taken in de wachtrij en kan de tijd tussen de aankomst van een gebeurtenis en de start van de pipeline oplopen tot enkele minuten. De kolommen JobStartTime en Timestamp in de monitoring Eventhouse laten deze afwijking in de loop van de tijd zien.
De operations agent (momenteel in preview) kan dit gedeeltelijk oplossen met playbooks in natuurlijke taal, maar deze bewaakt alleen ItemJobEventLogs. De agent heeft geen toegang tot je aangepaste FileArrivalLog-tabel en kan daarom de correlatiefout tussen bestandsontvangst en pipeline-trigger niet detecteren. De bovenstaande watchdog-query vult die leemte op.
De polling intervallen creëren een onzekerheidsvenster voor waarschuwingen.
Elke KQL-gebaseerde Activator-regel introduceert latentie. De keten is als volgt: gebeurtenis vindt plaats → Eventhouse verwerkt de logregel → Activator voert de KQL-query uit → voorwaarde wordt als waar beoordeeld → actie wordt uitgevoerd (e-mail, Teams, pipeline). Elke schakel voegt seconden tot minuten toe.
De latentie bij het verwerken van ItemJobEventLogs door Eventhouse is doorgaans minder dan 60 seconden, maar kan oplopen bij capaciteitsproblemen. Het polling-interval van Activator is configureerbaar, maar is standaard ingesteld op 1 minuut voor KQL Queryset-triggers. Het tijdsvenster van de KQL-query moet breder zijn dan het polling-interval om te voorkomen dat gebeurtenissen tussen de polls worden gemist — de documentatie van Microsoft waarschuwt hier expliciet voor. Als je query filtert op SecondsAgo <= 540 (9 minuten) en Activator elke 60 seconden pollt, is er voldoende overlap. Maar als je het venster verkleint tot 120 seconden om duplicaten te verminderen, betekent één trage polling dat een waarschuwing wordt gemist.
Voor SLA-monitoring is deze onzekerheidsmarge minder kritisch, omdat SLA-schendingen in uren worden gemeten, niet in seconden. Een detectievertraging van 5 minuten voor een bestand dat om 20:00 uur klaar had moeten zijn, is acceptabel. Het probleem ontstaat pas bij een trigger fout: als je controleert of een pipeline binnen 5 minuten na ontvangst van het bestand is gestart, en je waarschuwingsketen zelf 3 minuten duurt, krimpt je effectieve detectiebuffer tot 2 minuten.
De praktische aanbeveling: stel het polling interval van je Activator in op 1 minuut, het KQL-queryvenster op 10 minuten en de detectiebuffer voor trigger fouten op 15 minuten. Dit geeft je een drievoudige overlap – voldoende om vertragingen bij de verwerking, haperingen in de Activator en wachtrijen voor taken als gevolg van capaciteitsproblemen op te vangen. Registreer de detectietijdstempels in je tabel met schendingen, zodat je de werkelijke waarschuwingslatentie in de loop van de tijd kunt meten en de vensters kunt verkleinen naarmate je meer vertrouwen krijgt in het gedrag van het systeem.
MetricSign dicht de kloof tussen niet-gebeurtenissen en aangepaste KQL-query's.
De hierboven beschreven architectuur werkt. Het vereist echter wel dat je twee aangepaste KQL-tabellen, een referentieschema, drie detectiequery's, een deduplicatielogboek en afgestemde Activator-polling intervallen onderhoudt – en dit alles wordt niet gemonitord, tenzij je nog een extra laag toevoegt.
MetricSign pakt dit anders aan. In plaats van te reageren op uitvoeringsgebeurtenissen, houdt het de verwachte voltooiingstijden van de pipeline en de refreshvensters van de dataset bij en geeft het een refresh_delayed-signaal af wanneer de verwachte gebeurtenis niet plaatsvindt. De detectie is gebaseerd op de klok, niet op gebeurtenissen, wat betekent dat het stille trigger fouten, ontbrekende bestandsaankomsten en gepauzeerde capaciteiten via één enkel mechanisme detecteert. Wanneer een Fabric-pipeline die normaal gesproken om 18:30 uur voltooid is, om 19:00 uur nog geen voltooiingsgebeurtenis heeft gegenereerd, toont MetricSign de vertraging met context over de onderliggende oorzaak – is de pipeline niet gestart, of is het upstream-bestand nooit aangekomen? – zonder dat je zelf de correlatie query's hoeft te bouwen en te onderhouden.
Dit is vooral belangrijk voor teams die tientallen pipelines beheren in meerdere werkruimtes, waar het per item instellen van Data Activator-regels onbeheersbaar wordt en waar de aangepaste KQL-aanpak voortdurende afstemming vereist naarmate het aantal pipelines en de SLA-contracten veranderen. De monitoring infrastructuur mag zelf geen bron van operationeel risico worden.