Share via

Migrera från System Center Operations Manager (SCOM) till Azure Monitor

  • Artikel

Den här artikeln innehåller vägledning för kunder som för närvarande använder System Center Operations Manager (SCOM) och planerar en övergång till molnbaserad övervakning med Azure Monitor när de migrerar affärsprogram och andra resurser till Azure.

Det finns ingen standardprocess för migrering från SCOM och du kan förlita dig på SCOM-hanteringspaket under en längre tid i stället för att utföra en snabb migrering. I den här artikeln beskrivs de olika tillgängliga alternativen och beslutskriterierna som du kan använda för att fastställa den bästa strategin för din specifika miljö.

Övervakning av hybridmoln

De flesta kunder använder en övervakningsstrategi för hybridmoln som gör att du kan göra en gradvis övergång till molnet. Med den här metoden kan du underhålla dina befintliga affärsprocesser när du blir mer bekant med den nya plattformen. Flytta bara från SCOM-funktioner eftersom du kan ersätta den med Azure Monitor. Flera övervakningsverktyg ökar komplexiteten, men gör att du kan dra nytta av Azure Monitors möjlighet att övervaka nästa generations molnarbetsbelastningar samtidigt som du behåller SCOM:s möjlighet att övervaka serverprogramvara och arbetsbelastningar.

Din miljö innan du flyttar komponenter till Azure baseras på virtuella och fysiska datorer som finns lokalt eller med en hanterad tjänstleverantör. Den förlitar sig på SCOM för att övervaka affärsprogram, serverprogramvara och andra infrastrukturkomponenter i din miljö, till exempel fysiska servrar och nätverk. Du använder standardhanteringspaket för serverprogramvara som IIS, SQL Server och olika leverantörsprogram, och du justerar dessa hanteringspaket efter dina specifika krav. Du skapar anpassade hanteringspaket för dina affärsprogram och komponenter som inte kan övervakas med befintliga hanteringspaket, och du konfigurerar även SCOM för att stödja dina affärsprocesser.

När du flyttar tjänster till molnet börjar Azure Monitor samla in plattformsmått och aktivitetsloggen för var och en av dina resurser. Du skapar diagnostikinställningar för att samla in resursloggar så att du interaktivt kan analysera all tillgänglig telemetri med hjälp av loggfrågor och insikter.

Under den här övergångsperioden har du två oberoende övervakningsverktyg. Du använder insikter och arbetsböcker för att analysera din molntelemetri i Azure-portalen medan du fortfarande använder driftkonsolen för att analysera dina data som samlats in av SCOM. Eftersom varje system har en egen avisering måste du skapa åtgärdsgrupper i Azure Monitor som motsvarar dina meddelandegrupper i SCOM.

I följande tabell beskrivs de olika funktioner och strategier som är tillgängliga för en hybridövervakningsmiljö med hjälp av SCOM och Azure Monitor.

Metod beskrivning
Agenter med dubbla hem SCOM använder Microsoft Management Agent (MMA) som är samma som Log Analytics-agenten som används av Azure Monitor. Du kan konfigurera den här agenten så att den har en enda dator som ansluter till både SCOM och Azure Monitor samtidigt. Den här konfigurationen kräver att dina virtuella Azure-datorer har en anslutning till dina lokala hanteringsservrar.

Log Analytics-agenten har ersatts med Azure Monitor-agenten, vilket ger betydande fördelar, inklusive enklare hantering och bättre kontroll över datainsamling. De två agenterna kan samexistera på samma dator så att du kan ansluta till både Azure Monitor och SCOM. Den här konfigurationen är ett bättre alternativ än att dubbla den äldre agenten på grund av de betydande fördelarna med Azure Monitor-agenten.
Anslut hanteringsgrupp Anslut din SCOM-hanteringsgrupp till Azure Monitor för att vidarebefordra data som samlats in från dina SCOM-agenter till Azure Monitor. Detta liknar användningen av agenter med dubbla hem, men kräver inte att varje agent konfigureras för att ansluta till Azure Monitor. Den här strategin kräver den äldre agenten, så du kan inte ange övervakning med datainsamlingsregler. Du kan inte heller använda VM-insikter om du inte ansluter varje virtuell dator direkt till Azure Monitor.
SCOM Managed Instance (förhandsversion) SCOM-hanterad instans (förhandsversion) är en fullständig implementering av SCOM i Azure så att du kan fortsätta köra samma hanteringspaket som du kör i din lokala SCOM-miljö. Det finns ingen aktuell integrering mellan data och aviseringar från SCOM och Azure Monitor, och du fortsätter att använda samma driftkonsol för att analysera din hälsa och dina aviseringar.

SCOM MI liknar att underhålla din befintliga SCOM-miljö och agenter med dubbla värdar, även om du kan konsolidera övervakningskonfigurationen i Azure och dra tillbaka dina lokala komponenter som databas- och hanteringsservrar. Agenter från virtuella Azure-datorer kan ansluta till den SCOM-hanterade instansen i Azure i stället för att ansluta till hanteringsservrar i ditt eget datacenter.
Azure-hanteringspaket Med Azure-hanteringspaketet kan Operations Manager identifiera Azure-resurser och övervaka deras hälsa baserat på en viss uppsättning övervakningsscenarier. Det här hanteringspaketet kräver att du utför extra konfiguration för varje resurs i Azure. Det kan dock vara bra att ge en viss synlighet för dina Azure-resurser i driftkonsolen tills du utvecklar dina affärsprocesser för att fokusera på Azure Monitor.

Övervaka affärsprogram

Du behöver vanligtvis anpassade hanteringspaket för att övervaka dina affärsprogram med SCOM med hjälp av agenter som är installerade på varje virtuell dator. Application Insights i Azure Monitor övervakar webbaserade program oavsett om de finns i Azure, andra moln eller lokalt. Den kan användas för alla dina program oavsett om de har migrerats till Azure eller inte.

Om din övervakning av ett affärsprogram är begränsad till funktioner som tillhandahålls av .NET-appprestandamallen i SCOM kan du förmodligen migrera till Application Insights utan att förlora funktioner. Application Insights innehåller faktiskt ett stort antal andra funktioner, inklusive följande:

  • Identifiera och övervaka programkomponenter automatiskt.
  • Samla in detaljerade programanvändnings- och prestandadata, till exempel svarstid, felfrekvenser och begärandefrekvenser.
  • Samla in webbläsardata som sidvisningar och belastningsprestanda.
  • Identifiera undantag och öka detaljnivån för stackspårning och relaterade begäranden.
  • Utför avancerad analys med funktioner som distribuerad spårning och smart identifiering.
  • Använd metrics Explorer för att interaktivt analysera prestandadata.
  • Använd loggfrågor för att interaktivt analysera insamlad telemetri tillsammans med data som samlats in för Azure-tjänster och VM-insikter.

Det finns dock vissa scenarier där du kan behöva fortsätta använda SCOM utöver Application Insights tills du kan uppnå nödvändiga funktioner. Exempel där du kan behöva fortsätta med SCOM är följande:

  • Tillgänglighetstester som gör att du kan övervaka och varna om tillgänglighet och svarstider för dina program kräver inkommande begäranden från IP-adresserna för webbtestagenter. Om din princip inte tillåter sådan åtkomst kan du behöva fortsätta använda övervakare för webbprogramtillgänglighet i SCOM.
  • I SCOM kan du ange valfritt avsökningsintervall för tillgänglighetstester, där många kunder kontrollerar var 60–120:e sekund. Application Insights har ett minsta avsökningsintervall på fem minuter, vilket kan vara för långt för vissa kunder.
  • En betydande mängd övervakning i SCOM utförs genom att samla in händelser som genereras av program och genom att köra skript på den lokala agenten. Det här är inte standardalternativ i Application Insights, så du kan kräva anpassat arbete för att uppnå dina affärskrav. Detta kan omfatta anpassade aviseringsregler som använder händelsedata som lagras på en Log Analytics-arbetsyta och skript som startas på en virtuell datorgäst med hybrid runbook worker.
  • Beroende på vilket språk programmet är skrivet i kan du vara begränsad i den instrumentation som du kan använda med Application Insights.

Följ den grundläggande strategin i de andra avsnitten i den här guiden och fortsätt att använda SCOM för dina affärsprogram, men dra nytta av ytterligare funktioner som tillhandahålls av Application Insights. Eftersom du kan ersätta viktiga funktioner med Azure Monitor kan du börja dra tillbaka dina anpassade hanteringspaket.

Övervakning av virtuella datorer

Övervakning av programvaran på dina virtuella datorer i en hybridmiljö använder ofta en kombination av Azure Monitor och SCOM, beroende på kraven för de arbetsbelastningar som körs på dina virtuella datorer. Så snart en virtuell dator har skapats i Azure börjar plattformsmått och aktivitetsloggar för den virtuella datorns värd automatiskt att samlas in. Aktivera rekommenderade aviseringar för att meddela dig om vanliga fel för den virtuella datorns värd, till exempel server ned och hög CPU-användning.

Aktivera VM-insikter för att installera Azure Monitor-agenten och börja samla in vanliga prestandadata från klientoperativsystemet. Detta kan överlappa vissa data som du redan samlar in i SCOM, men det gör att du kan börja visa trender över tid och övervaka dina virtuella Azure-datorer med andra molnresurser. Du kan också välja att aktivera kartfunktionen som ger dig insikt i de processer som körs på dina virtuella datorer och deras beroenden för andra tjänster.

Fortsätt att använda hanteringspaket för funktioner som inte kan tillhandahållas av andra funktioner i Azure Monitor. Detta inkluderar hanteringspaket för viktig serverprogramvara som IIS, SQL Server eller Exchange. Du kan också ha anpassade hanteringspaket utvecklade för lokal infrastruktur som inte kan nås med Azure Monitor. Fortsätt också att använda SCOM om det är nära integrerat i dina operativa processer tills du kan övergå till att modernisera dina tjänståtgärder där Azure Monitor och andra Azure-tjänster kan utökas eller ersättas.

Kommentar

Om du aktiverar VM Insights med Log Analytics-agenten i stället för Azure Monitor-agenten behöver ingen ytterligare agent installeras på den virtuella datorn. Azure Monitor-agenten rekommenderas dock på grund av dess betydande förbättringar i övervakningen av den virtuella datorn i molnet. Komplexiteten i att underhålla flera agenter förskjuts av möjligheten att definiera övervakning i datainsamlingsregler som gör att du kan konfigurera olika datainsamling för olika uppsättningar av virtuella datorer, ungefär som din strategi för att utforma hanteringspaket.

Migrera hanteringspaketlogik för VM-arbetsbelastningar

Det finns inga migreringsverktyg för att konvertera SCOM-hanteringspaket till Azure Monitor eftersom deras logik skiljer sig från Azure Monitor-datainsamlingen i grunden. Migrering av hanteringspaketlogik fokuserar vanligtvis på att analysera de data som samlas in av SCOM och identifiera de övervakningsscenarier som kan replikeras av Azure Monitor. När du anpassar Azure Monitor för att uppfylla dina krav för olika program och komponenter kan du börja dra tillbaka olika hanteringspaket och äldre agenter i SCOM.

Hanteringspaket i SCOM innehåller regler och övervakare som kombinerar insamling av data och den resulterande aviseringen i ett enda arbetsflöde från slutpunkt till slutpunkt. Data som redan samlats in av SCOM används sällan för aviseringar. Azure Monitor separerar datainsamling och aviseringar i separata processer. Aviseringsregler får åtkomst till data från Azure Monitor-loggar och Azure Monitor-mått som redan har samlats in från agenter. Regler och övervakare fokuserar vanligtvis på specifika data, till exempel en viss händelse eller prestandaräknare. Datainsamlingsregler i Azure Monitor samlar vanligtvis in flera uppsättningar händelser och prestandaräknare i en enda DCR.

Se följande innehåll för vägledning om hur du skapar datainsamling och aviseringar för vanliga övervakningsscenarier:

I stället för att försöka replikera hela funktionen i ett hanteringspaket analyserar du den kritiska övervakning som var och en tillhandahåller. Bestäm om du kan replikera dessa övervakningskrav med hjälp av alternativa metoder. I många fall kan du konfigurera datainsamlings- och aviseringsregler i Azure Monitor som replikerar tillräckligt med funktioner för att du kan dra tillbaka ett visst hanteringspaket. Hanteringspaket kan ofta innehålla hundratals och till och med tusentals regler och övervakare.

En strategi är att fokusera på de övervakare och regler som utlöste aviseringar i din miljö. Se befintliga rapporter som är tillgängliga i Operations Manager, till exempel aviseringar och de vanligaste aviseringarna, som kan hjälpa dig att identifiera aviseringar över tid. Du kan också köra följande fråga i operationsdatabasen för att utvärdera de vanligaste senaste aviseringarna.

select AlertName, COUNT(AlertName) as 'Total Alerts' from
Alert.vAlertResolutionState ars
inner join Alert.vAlertDetail adt on ars.AlertGuid = adt.AlertGuid
inner join Alert.vAlert alt on ars.AlertGuid = alt.AlertGuid
group by AlertName
order by 'Total Alerts' DESC

Utvärdera utdata för att identifiera specifika aviseringar för migrering. Ignorera alla aviseringar som har finjusterats eller som är kända för att vara problematiska. Granska dina hanteringspaket för att identifiera eventuella kritiska aviseringar av intresse som aldrig utlöstes.

Syntetiska transaktioner

Hanteringspaket använder ofta syntetiska transaktioner som ansluter till ett program eller en tjänst som körs på en dator för att simulera en användaranslutning eller faktisk användartrafik. Om programmet är tillgängligt kan du anta att datorn körs korrekt. Application Insights-tillgänglighetstester i Azure Monitor tillhandahåller den här funktionen. Det fungerar bara för program som är tillgängliga från Internet. För interna program måste du öppna en brandvägg för att tillåta åtkomst från specifika Microsoft-URL:er som utför testet. Eller så kan du fortsätta att använda ditt befintliga hanteringspaket.

Nästa steg