Monitoring tijdens cloud migratie: wat teams missen

Cloud migratieprojecten kennen zelden een duidelijke overgangsdatum. De realiteit voor de meeste organisaties die overstappen van on-premises SQL Server en SSIS naar Azure SQL en ADF is een periode — vaak maanden, soms jaren — waarin beide omgevingen gelijktijdig draaien. Sommige datasets zijn gemigreerd; andere nog niet. Sommige bedrijfsonderdelen gebruiken Power BI; andere nog steeds SSRS.

In deze tussenfase is data monitoring het moeilijkst en het belangrijkst. U monitort niet één omgeving, maar twee omgevingen met verschillende failure modes, verschillende tooling en verschillende expertise binnen uw team. Een SSIS package dat vroeger netjes faalde, kan nu falen omdat de Azure gateway die het gebruikt voor connectiviteit verkeerd is geconfigureerd. Een ADF pipeline die er in Azure Monitor gezond uitziet, schrijft mogelijk naar de verkeerde database omdat een connection string onjuist is ingesteld.

De meeste monitoring tools zijn ontworpen voor één van beide werelden. Azure Monitor dekt ADF en Azure SQL. SQL Server Agent logs dekken on-premises SSIS. Power BI Service dekt refresh status. Geen van deze tools geeft u het omgeving-overstijgende beeld — het beeld dat de volledige staat van uw data stack, on-premises en cloud, in één overzicht toont.

De on-premises data gateway is de brug tussen uw legacy on-premises systemen en de Azure cloud. Tijdens de migratie is het ook uw grootste single point of failure.

De gateway draait als een Windows service op een dedicated server (of idealiter een cluster). Die verwerkt elke data refresh die een on-premises SQL Server, Oracle database, SSAS cube of bestandssysteem betreft. Wanneer de gateway uitvalt, stopt elke dataset die ervan afhankelijk is met refreshen. Er is geen fallback.

Gateway monitoring moet meerdere zaken omvatten die de ingebouwde monitoring van Power BI Service mist:

Gateway service health: Draait de Windows service? Gateway services kunnen crashen, en Power BI cloud kan tot 10 minuten nodig hebben om te detecteren dat een gateway offline gaat (op basis van het heartbeat polling interval van de gateway). Tegen de tijd dat de portal "offline" toont, zijn de geplande refreshes die in dat tijdsvenster draaiden al stilletjes mislukt.

Cluster capaciteit: Hoeveel gelijktijdige refreshes verwerkt de gateway? Als u tijdens de migratie 20 nieuwe datasets hebt toegevoegd en de gateway 40 gelijktijdige refreshes verwerkt, verslechtert de performance en beginnen refreshes te queuen — langzaam lijkend voordat ze gaan falen.

Gateway versie: Microsoft werkt de gateway software regelmatig bij. Een verouderde versie veroorzaakt authenticatiefouten en verbindingsfouten die lastig te diagnosticeren zijn. De geïnstalleerde versie vergelijken met de laatste release is een eenvoudige maar waardevolle check.

Connectiviteit per data source: Test regelmatig de connectiviteit van de gateway naar elke geregistreerde data source. Een firewall regelwijziging of verlopen SQL Server credential kan de connectiviteit stilletjes verbreken voordat enige refresh wordt geprobeerd.

Credential management is een van de meest voorkomende bronnen van migratie-gerelateerde incidents. U heeft credentials op meerdere plaatsen: SSIS package connection managers, SQL Server Agent taakstappen, Power BI data source credentials, ADF linked services en Key Vault secrets. Wanneer een wachtwoord wijzigt of een service account wordt geroteerd, veroorzaakt het missen van één locatie een failure.

Tijdens de migratie is het credential oppervlak het grootst. Sommige pipelines gebruiken on-premises service accounts. Nieuwe ADF pipelines gebruiken managed identities of Azure AD service principals. Power BI datasets kunnen een mix hebben van embedded credentials, gateway-gemapte credentials en OAuth tokens.

Specifieke risico's om op te letten tijdens migratie:

Verlopen gateway credentials: Power BI datasets die gateway verbindingen gebruiken, hebben credentials nodig die zijn opgeslagen in de verbindingsconfiguratie van de gateway. Dit staat los van het database wachtwoord zelf. Als het database wachtwoord wijzigt maar de gateway credential niet wordt bijgewerkt, mislukt elke refresh via die verbinding — vaak met een generieke "Credentials are invalid" fout die niet specificeert welk credential.

Cross-omgeving connection string drift: Een ADF pipeline gemigreerd vanuit SSIS kan een connection string erven die naar de on-premises database wijst, terwijl de ADF linked service is geconfigureerd naar Azure SQL te wijzen. De ene omgeving wordt bijgewerkt; de andere niet. De pipeline draait maar schrijft naar de verkeerde bestemming.

Service account lockout: Accounts gebruikt door SSIS of ADF om toegang te krijgen tot SQL Server kunnen worden geblokkeerd door wachtwoordbeleid of ongebruikelijke aanmeldingspatronen vanuit nieuwe IP-bereiken. Authentication failures monitoren op de gateway laag detecteert dit vroeg — voordat meerdere refreshes mislukken.

Voor de migratie werd uw data laadplanning waarschijnlijk op één plek beheerd: SQL Server Agent jobs. De planning was eenvoudig te controleren — één systeem, één lijst met jobs.

Tijdens de migratie verspreiden planningen zich over meerdere systemen: SQL Server Agent (legacy jobs die nog draaien), ADF triggers (nieuwe pipelines), Power BI scheduled refresh (dataset refresh windows) en mogelijk Azure Logic Apps of Event Grid voor event-driven flows.

Het risico zijn conflicten en volgorde schendingen. Twee jobs die gelijktijdig naar dezelfde tabel schrijven. Een Power BI refresh die triggert voordat de ADF pipeline klaar is met het laden van de staging tabel — omdat iemand de pipeline planning heeft gewijzigd maar vergat de Power BI refresh planning bij te werken. Een SSIS package dat om middernacht nog laadt vanuit dezelfde brondatabase terwijl de nieuwe ADF pipeline tegelijkertijd een volledige herlaad uitvoert.

Planning monitoring tijdens migratie betekent een enkelvoudig overzicht bijhouden van alle geplande jobs over alle tools, conflicten op gedeelde resources controleren en valideren dat refresh planningen downstream liggen van de pipelines die ze voeden. Zelfs een eenvoudige spreadsheet met alle geplande jobs, hun tijden en hun afhankelijkheden is nuttiger dan aannemen dat de planning van elke tool onafhankelijk is.

Migratie monitoring moet voortgang bijhouden, niet alleen failures. Definieer in elke fase expliciet wat gezond betekent.

Pre-migratie baseline: On-premises pipelines draaien op schema, Power BI refreshes voltooid binnen SLA. Rij-aantallen, duur en foutpercentages vastgelegd als baseline. U heeft deze data nodig om pariteit te verifiëren tijdens en na de migratie.

Parallel draaien: Zowel on-premises als cloud pipelines actief. Data uit beide omgevingen vergeleken om pariteit te valideren — komen de rij-aantallen overeen? Zijn de waarden consistent? Dit is de meest complexe monitoring fase omdat u twee systemen tegelijkertijd valideert.

Post-migratie, pre-decommissie: Cloud pipelines draaien betrouwbaar. On-premises jobs uitgeschakeld (niet alleen deprecated — daadwerkelijk uitgeschakeld, zodat een herstart ze niet herActiveert). Gateway verkeer neemt af naarmate datasets migreren naar cloud-native directe verbindingen.

Steady state: Gateway alleen gebruikt voor daadwerkelijk on-premises bronnen (databases die nooit naar cloud gaan). Duidelijke documentatie van welke datasets nog gateway toegang vereisen en waarom. Monitoring keert terug naar een enkelvoudig omgevingsoverzicht.

Het monitoring systeem moet deze progressie weerspiegelen. Tijdens parallel draaien zijn alerteringsdrempels en notificatieregels anders dan in steady state. Tijdelijke failures tijdens migratie cutover zijn verwacht; nieuwe failure modes die er daarvoor niet waren, niet.