Pipeline monitoring in Microsoft Fabric: native of via Azure Monitor?

Werk je serieus met Microsoft Fabric, dan stuit je vroeg of laat op dezelfde vraag: hoe zet je fatsoenlijke alerts op voor je pipelines en notebooks? Wie gewend is te werken met Azure Data Factory, zal deze functionaliteit direct missen. Daar heb je ingebouwde failure alerts, action groups en notificaties die vanzelf in Microsoft Teams of je ITSM-tool belandden. In Microsoft Fabric is dit (nog) niet het geval. De community is er eerlijk over: standaard error monitoring bestaat eigenlijk niet. Microsoft erkent in de eigen documentatie dat je veel zelf moet inrichten. Er zijn meerdere opties, maar geen van deze voelt volwassen.

Route 1: de native Fabric-route

De meest laagdrempelige optie is een e-mailnotificatie op een scheduled pipeline. Eén ‘vinkje’ in de settings, en je krijgt een mailtje als het misgaat. Alleen mail, alleen op pipeline-niveau, geen routing of context. Prima vangnet, maar geen strategie.

Een stap verder zijn Outlook- of Teams-activiteiten die je rechtstreeks in de pipeline bouwt. Dat geeft volledige controle over inhoud en kanaal, maar bij honderd pipelines onderhoud je ook honderd plekken met notificatielogica. De modernste native optie is Data Activator op job events: centraal, declaratief, en het werkt voor pipelines, dataflows, notebooks en Spark jobs. De UX is alleen nog niet volwassen, routing naar externe tools zoals ServiceNow of PagerDuty vereist een functie of webhook, en stateful alerting, alarmeren pas na drie keer falen, zit er nog niet in.

Heb je een handvol pipelines, één team en is basale "het is kapot"-alerting voldoende, dan is Activator met gewone failure e-mails als vangnet prima.

Route 2: Eventhouse en Log Analytics als basis

Wil je meer controle, dan bouw je een eigen stack. Het uitgangspunt is simpel: Fabric is uitstekend voor data, maar voor observability heeft Azure al een volwassen platform staan. Waarom dat opnieuw uitvinden?

Events landen in een Eventhouse in Fabric: pipeline events via Activator, notebooklogs, custom business events en datakwaliteitsmetrics bij elkaar. Een Python-notebook leest die periodiek uit met KQL en POST naar de Logs Ingestion API van Log Analytics. Daar draaien alert rules op KQL-queries, en een match triggert een action group die routeert naar Teams, e-mail, ServiceNow, PagerDuty of een webhook.

Eventhouse fungeert daarin als buffer. Het ontkoppelt je van Log Analytics als die tijdelijk uitvalt, biedt retentie en herafspeelbaarheid in KQL, en geeft je de ruimte om events te aggregeren, dedupliceren en verrijken voor je ze doorstuurt. Een pipeline kan REST-calls doen via Web Activity, maar zodra je token caching, retries of bulk POST's nodig hebt, wordt Python veel prettiger. En Log Analytics? KQL als querytaal is dezelfde als in Eventhouse, de alert rules zijn fijnmazig, en de action groups routeren naar zo'n beetje elke bestemming die je kunt bedenken. Het belangrijkste argument blijft organisatorisch: dit platform staat er waarschijnlijk al, Cloud Ops kent het, en je alerts zijn geen geïsoleerd Fabric-dingetje meer.

De prijs zit niet in je Azure-factuur

Route 2 is meer werk. Je hebt een Log Analytics-workspace, twee platformen voor authenticatie en RBAC, een notebook dat zelf gemonitord moet worden en KQL-kennis in het team nodig. Voor alerting-volumes zijn de kosten per GB ingestion in Log Analytics meestal verwaarloosbaar, maar je betaalt wel in complexiteit.

De afweging van Cito

Voor Cito woog dat op tegen de winst: één centrale alerting-stack, integratie met de rest van de Azure-observability en de vrijheid om elke gewenste conditie te schrijven.

Microsoft is duidelijk bezig met dit gebied. Activator wordt snel uitgebreid en in elke Fabric-update komen meer event-integraties bij. Over een jaar of twee is route 1 misschien volwassen genoeg om route 2 overbodig te maken. Zolang dat nog niet zo is en je een platform draait waarop mensen op jouw signaal vertrouwen, is route 2 de verstandige keuze.