Drie generaties, gelijktijdig actief
Als uw organisatie meer dan vijf jaar geleden is begonnen met het bouwen van data pipelines, is de kans groot dat u drie generaties ETL-tooling tegelijk draait: SSIS packages uit het SQL Server-tijdperk, ADF pipelines gebouwd tijdens de Azure-migratie en, in toenemende mate, Fabric Data Pipelines naarmate Microsoft het platform verder ontwikkelt.
Elke generatie heeft andere monitoring mogelijkheden. SSIS logt naar SQL Server Agent geschiedenis — leesbaar maar geïsoleerd van cloud tooling. ADF heeft Azure Monitor integratie, activity run metrics en native alerting via de Azure portal. Fabric Pipelines hebben een eigen monitoring interface, los van ADF, ook al delen ze een deel van de onderliggende infrastructuur.
Geen van deze tools geeft u een generatie-overstijgend overzicht. De vraag "is mijn data stack nu gezond?" vereist het controleren van drie aparte monitoring consoles, handmatig correleren van tijdstempels en weten welke versie van elke pipeline de gezaghebbende is. Voor teams die tooling stapsgewijs hebben uitgebreid, is dit de realiteit — en het creëert echte lacunes in het overzicht.
SSIS: wat draait er nog en waarom
Veel organisaties onderschatten hoeveel SSIS nog steeds in productie draait. De packages werken, ze draaien al jaren zonder problemen, en de migratie naar ADF vereist inspanning die nooit bovenaan de prioriteitenlijst komt. Het resultaat: productie pipelines die niemand actief monitort op een cloud-geïntegreerde manier.
Het probleem is niet dat SSIS slecht is — het is dat SSIS monitoring niet integreert met uw cloud monitoring stack. Wanneer een SSIS package mislukt, gaat de fout naar de SQL Server Agent taakgeschiedenis. Uw ADF monitoring console weet er niets van. Uw Power BI incident alerts weten er niets van.
Voor packages die Power BI datasets voeden — rechtstreeks via een on-premises SQL Server of via een gateway verbinding — is een stille SSIS-fout een Power BI-probleem dat niet verschijnt in de actualisatiegeschiedenis van Power BI Service. De refresh kan slagen door stale data te laden uit de tabel die SSIS had moeten bijwerken.
Een monitoring brug die werkt zonder volledige migratie: push de SSIS-taakstatus na elke run naar een centrale monitoring tabel. Een eenvoudig SSIS package met een afsluitende taak die succes/mislukking, rij-aantallen en duur naar een monitoring database schrijft, opvraagbaar door uw cloud monitoring tool. Dit overbrugt de kloof zonder de package logica aan te passen of migratie te vereisen.
ADF: de tussenpositie
ADF is volwassen, goed gedocumenteerd en heeft goede native monitoring. De uitdaging tijdens een drie-generatie transitie is dat ADF tegelijkertijd twee dingen doet: SSIS vervangen voor workloads met on-premises connectiviteit, en geleidelijk worden vervangen door Fabric Pipelines voor cloud-native orchestratie.
Dat betekent dat sommige ADF pipelines actief worden ontwikkeld en verbeterd, terwijl andere in onderhoudsmodus staan in afwachting van migratie naar Fabric. De monitoring aanpak voor deze twee groepen moet verschillen.
Voor actief ontwikkelde ADF pipelines: uitgebreide monitoring met run-level alerting, validatie van rij-aantallen, performance baselines en foutnotificaties. Deze pipelines veranderen; monitoring wijzigingen moeten daarmee gelijke tred houden.
Voor ADF pipelines in onderhoudsmodus: basis health monitoring — heeft de pipeline gedraaid, is die gelukt, hoe lang duurde het? Geen behoefte aan geavanceerde observability voor pipelines die u in Q3 buiten gebruik stelt.
Het risico in de praktijk is dat alle ADF pipelines hetzelfde worden behandeld. Gedetailleerde monitoring opzetten voor een tijdelijke migratiepipeline die over twee maanden wordt uitgefaseerd, is verspilde moeite. Onderhoudsmodus monitoring toepassen op een kritieke productiepipeline omdat "het nog nooit problemen heeft gegeven" is een betrouwbaarheidsrisico. Classificeer pipelines op basis van kritikaliteit en migratiestatus voordat u de monitoring diepte bepaalt.
Fabric Pipelines: monitoring op een bewegend platform
Fabric Data Pipelines vormen de next-generation orchestratielaag van Microsoft. Begin 2026 zijn ze goed ingeburgerd voor lakehouse workloads, maar missen nog functionaliteit ten opzichte van ADF — met name voor connectiviteit met on-premises bronnen (waarvoor nog steeds gateway clusters nodig zijn) en voor complexe conditionele retry logica.
Vanuit monitoring perspectief voegen Fabric Pipelines een laag complexiteit toe: ze draaien in Fabric workspaces met een eigen capaciteitsbeheer, los van ADF en Power BI Premium. Een Fabric pipeline die traag draait, kan tegen workspace capaciteitslimieten aanlopen, niet tegen fouten in de pipeline logica.
De native monitoring van Fabric biedt run history en basis metrics via de Fabric workspace monitoring hub, maar integreert niet met ADF monitoring of met Power BI dataset refresh monitoring. Voor organisaties die Fabric Pipelines gebruiken om Delta tabellen te laden die Power BI datasets voeden via Direct Lake, is de fout-keten direct: Fabric pipeline → Delta tabel → Power BI model (Direct Lake). Een Fabric pipeline fout raakt het model onmiddellijk.
Dit verschilt van import mode Power BI datasets, waar een mislukte pipeline betekent dat de volgende geplande refresh stale data laadt. Met Direct Lake is er geen staging buffer — wat in de Delta tabel staat, is vrijwel direct zichtbaar in het rapport. Een half geladen Delta tabel door een Fabric pipeline fout verschijnt onmiddellijk in elk rapport dat die tabel gebruikt.
Eén overzicht voor drie generaties
Het doel is niet om elke pipeline in één tool te dwingen — SSIS, ADF en Fabric hebben elk legitiem verschillende use cases en zullen nog jarenlang naast elkaar bestaan. Het doel is één monitoring overzicht dat over alle drie de tooling generaties laat zien: wat er heeft gedraaid, wat gelukt is, wat mislukt is en wat er downstream staat.
Dit vereist een abstractie die tool-specifieke details normaliseert. Een pipeline run is een pipeline run, ongeacht welke tool hem heeft uitgevoerd. Die heeft een naam, een starttijd, een duur, een status, een rij-aantallen en een lijst met outputs. Met deze abstractie wordt de monitoring logica generiek: alerteer wanneer een pipeline run mislukt, alerteer wanneer rij-aantallen onder de drempel komen, alerteer wanneer de duur de baseline overschrijdt.
Deze abstractie onderhouden vereist een collector per tool: lezen uit SQL Server Agent geschiedenis voor SSIS, abonneren op Azure Event Grid voor ADF, de Fabric monitoring API bevragen voor Fabric Pipelines. Het is infrastructuurwerk — maar de operationele opbrengst is significant. Eén incident feed voor uw volledige data stack betekent één on-call proces, één set escalatiepaden en één plek om te kijken wanneer er iets misgaat.
Voor teams midden in een migratie beantwoordt dit uniforme overzicht ook een strategische vraag: welke pipelines draaien nog op SSIS en moeten worden gemigreerd, en hoe kritiek zijn ze? Inzicht in job health, frequentie en downstream impact maakt prioritering eenvoudiger.