Van SSIS naar ADF naar Fabric: het overzicht behouden

Als je organisatie meer dan vijf jaar geleden is begonnen met het bouwen van pipelines, is de kans groot dat je drie generaties ETL-tools tegelijkertijd gebruikt: SSIS-pakketten uit het SQL Server-tijdperk, ADF-pipelines van de eerste Azure-migratie en Fabric Data Pipelines van het huidige moderniseringsinitiatief.

Het overzicht behouden over al deze drie is dezelfde uitdaging waarvoor data-observability-platforms zijn ontworpen: het normaliseren van een gefragmenteerd monitoringlandschap tot één samenhangend beeld.

Elke generatie werkt. Elke generatie heeft zijn eigen gebruiksscenario's. En elke generatie heeft een volledig aparte monitoringinterface. SSIS-taken verschijnen in de SQL Server Agent-geschiedenis of in SSISDB-uitvoeringsrapporten. ADF-pipelines zijn zichtbaar in Azure Monitor en het monitoringvenster van ADF Studio. Fabric Pipelines verschijnen in de Fabric-werkruimtemonitorhub. Geen van deze interfaces biedt inzicht in de andere.

Het praktische gevolg is dat wanneer er iets misgaat, de dienstdoende engineer drie consoles moet controleren om vast te stellen wat wel en niet werkte, en wat van wat afhankelijk is. Bij een pipeline fout die een generatiegrens overschrijdt — een SSIS-extract dat een ADF-transformatie voedt, die op zijn beurt een Fabric-semantisch model voedt — vereist het onderzoek het schakelen tussen drie monitoringtools zonder gedeelde context.

Dit is geen probleem van onvolwassen tools. Het is een architectonisch gevolg van incrementele migratie. De oplossing is niet om alle pipelines op één platform te consolideren voordat je ze kunt monitoren. De oplossing is om de monitoringlaag te abstraheren.

Zie ook: Best data observability platforms in 2026

De meeste organisaties onderschatten hoe vaak SSIS nog steeds in productie draait. De pakketten werken, ze draaien al jaren zonder problemen, en het migreren ervan naar ADF kost moeite die niet op het sprintbord terechtkomt als er werk met een hogere prioriteit om aandacht vraagt. Het resultaat: bedrijfskritische SSIS-pakketten die draaien op SQL Server Agent zonder integratie met een cloudmonitoringsysteem.

De foutmodus is opzettelijk onzichtbaar. Wanneer een SSIS-pakket om 02:30 uur faalt, registreert SQL Server Agent dit in msdb.dbo.sysjobhistory. Azure Monitor ziet het niet. De refreshmonitoring van Power BI ziet het ook niet. De ADF-pipeline die de SSIS-output zou moeten ophalen, draait volgens schema, vindt geen nieuwe gegevens, kopieert niets (succesvol) en markeert zichzelf als voltooid. Power BI vernieuwt de downstream-dataset en levert de gegevens van gisteren zonder foutmelding.

Het oplossen van dit probleem vereist geen migratie van de SSIS-pakketten. Het vereist één toevoeging: een stap aan het einde van elk pakket die de uitvoeringsstatus, het aantal rijen en de tijdstempel naar een SQL Server tabel schrijft die toegankelijk is vanuit Azure. Een eenvoudige INSERT in een gedeelde logtabel na elk succesvol pakket zorgt voor inzicht in alle omgevingen, iets wat geen enkele native tool biedt. De cloudmonitoringlaag leest deze tabel samen met ADF-run logs en de Fabric-pipeline status.

In een omgeving met drie generaties ADF doet ADF gelijktijdig twee dingen: het vervangt SSIS voor workloads die on-premise verbonden zijn (waarvoor de data gateway nodig is) en het levert data aan Fabric en Power BI voor toekomstgerichte taken. Deze twee categorieën pipelines hebben verschillende faalpatronen, verschillende SLA's en verschillende onderhoudsbehoeften, maar ze worden beheerd vanuit dezelfde console.

Pipelines in onderhoudsmodus, in afwachting van een uiteindelijke migratie naar Fabric, vormen een aparte monitoringcategorie. Ze draaien wel, maar er wordt niet actief aan gewerkt. Schemawijzigingen in hun upstream-bronnen blijven langer onopgemerkt. Afhankelijkheden die jaren geleden zijn ingebouwd, zijn mogelijk niet gedocumenteerd. Een fout in een ADF-pipeline in onderhoudsmodus kan moeilijker te diagnosticeren zijn dan een fout in een actief ontwikkelde pipeline, omdat de engineer die het heeft gebouwd mogelijk niet meer in het team zit.

De praktische oplossing is om pipelines expliciet te taggen op status: actief ontwikkeld, stabiele productie, onderhoudsmodus in afwachting van migratie. Pipelines in onderhoudsmodus vereisen juist een agressievere volumebewaking en gedetailleerdere logging, niet minder. Want als ze uitvallen, heeft de dienstdoende engineer die context nodig om een pipeline te diagnosticeren die hij of zij niet zelf heeft gebouwd.

Fabric Data Pipelines vormen de huidige generatie orchestratielaag van Microsoft. Vanaf 2026 zijn ze goed ingeburgerd voor lakehouse-workloads. De foutmodi zijn qua structuur bekend, maar er zijn specifieke details die van belang zijn voor monitoring.

Het belangrijkste verschil is het semantische model van Direct Lake. In tegenstelling tot Power BI datasets in importmodus, die gegevens tijdens een geplande refresh in een cache in het geheugen laden, lezen Direct Lake-modellen rechtstreeks uit OneLake tijdens het uitvoeren van een query. Er is geen aparte refreshstap die een buffer vult. Wanneer een Fabric-pipeline de onderliggende lakehouse-gegevens niet kan bijwerken, zien gebruikers direct onjuiste gegevens wanneer ze het rapport openen – zonder dat er een melding van een refreshsfout is.

Dit verandert het monitoring model. Bij datasets in importmodus biedt een pipeline fout een tijdelijke oplossing: de dataset bevat nog steeds de laatst succesvol geladen gegevens totdat een nieuwe refresh poging wordt gedaan. Bij Direct Lake-modellen bestaat die buffer niet. Het monitoren van de Fabric-pipeline die naar de lakehouse schrijft, wordt net zo urgent als het monitoren van het semantische model zelf – omdat de pipeline fout in feite de refreshsfout is, samengevoegd tot één gebeurtenis.

De native monitoringhub van Fabric biedt per pipeline de status, duur en foutdetails. Het probleem is hetzelfde als bij SSIS en ADF: geen overzicht van meerdere generaties zonder abstractie.

Je hoeft niet elke pipeline op één platform te consolideren voordat monitoring zinvol is. Je hebt een monitoringweergave nodig die werkt ongeacht de generatie van elke pipeline en die stabiel blijft wanneer pipelines tussen generaties migreren.

Een genormaliseerd pipeline runsrecord legt vier velden vast, ongeacht de tool: naam (een consistente identificatie voor de logische pipeline, niet de toolspecifieke taaknaam), status (geslaagd, mislukt, waarschuwing), aantal rijen (aantal rijen dat naar de bestemming is geschreven) en bestemming (de tabel of het bestand dat de pipeline heeft geproduceerd). Omdat deze velden consistent worden vastgelegd voor SSIS, ADF en Fabric, geeft één enkele query op deze tabel je de status van je hele stack – ongeacht welke tool elke taak heeft uitgevoerd.

Het bouwen ervan vereist slechts bescheiden instrumentatie per tool: een log-INSERT aan het einde van elk SSIS-pakket, een aangepaste activiteit in elke ADF-pipeline die uitvoeringsmetadata schrijft, een Fabric-notebook of pipeline-activiteit voor Fabric-taken. Het monitoringoppervlak blijft vervolgens behouden tijdens de migratie: wanneer een pipeline van ADF naar Fabric wordt verplaatst, blijft het genormaliseerde logboek met dezelfde velden worden geschreven. Er verandert niets in de monitoringconfiguratie.