Migrera till Azure Monitor-agenten från Log Analytics-agenten
Azure Monitor Agent (AMA) ersätter Log Analytics-agenten, även kallad Microsoft Monitor Agent (MMA) och OMS, för Windows- och Linux-datorer, i Azure- och icke-Azure-miljöer, lokalt och andra moln. Agenten introducerar en förenklad, flexibel metod för att konfigurera datainsamling med hjälp av datainsamlingsregler (DCR). Den här artikeln innehåller vägledning om hur du implementerar en lyckad migrering från Log Analytics-agenten till Azure Monitor Agent.
Migrering är en komplex uppgift. Börja planera migreringen till Azure Monitor Agent med hjälp av informationen i den här artikeln som en guide.
Viktigt!
Log Analytics-agenten drogs tillbaka den 31 augusti 2024. Den här utfasningen gäller inte för MMA-agenten som är exklusivt ansluten till en lokal SCOM-installation.
Du kan förvänta dig följande när du använder MMA- eller OMS-agenten efter den 31 augusti 2024.
- Datauppladdning: Molninmatningstjänster minskar gradvis stödet för MMA-agenter, vilket kan leda till minskat stöd och potentiella kompatibilitetsproblem för MMA-agenter över tid. Inmatningen för MMA kommer att vara oförändrad fram till den 1 februari 2025.
- Installation: Möjligheten att installera äldre agenter tas bort från Azure-portalen och installationsprinciper för äldre agenter tas bort. Du kan fortfarande installera MMA-agenttillägget samt utföra offlineinstallationer.
- Kundsupport: Du kommer inte att kunna få support för äldre agentproblem.
- Os-stöd: Stöd för nya Linux- eller Windows-distributioner, inklusive servicepaket, läggs inte till efter utfasningen av de äldre agenterna.
- Log Analytics-agenten kan samexistera med Azure Monitor Agent. Förvänta dig att se duplicerade data om båda agenterna samlar in samma data.
Förmåner
Med Hjälp av Azure Monitor-agenten får du omedelbara fördelar enligt nedan:
- Kostnadsbesparingar med hjälp av regler för datainsamling:
- Aktiverar riktad och detaljerad datainsamling för en dator eller delmängder av datorer, jämfört med metoden "allt eller ingenting" för äldre agenter.
- Tillåter filtreringsregler och datatransformeringar för att minska den totala datavolymen som laddas upp, vilket minskar kostnaderna för inmatning och lagring avsevärt.
- Säkerhet och prestanda
- Förbättrad säkerhet via hanterad identitet och Microsoft Entra-token (för klienter).
- Högre händelsedataflöde som är 25 % bättre än de äldre Log Analytics-agenterna (MMA/OMS).
- Enklare hantering , inklusive effektiv felsökning:
- Stöder dataöverföringar till flera mål (flera Log Analytics-arbetsytor, t.ex. multihoming i Windows och Linux) inklusive datainsamling mellan regioner och flera klientorganisationer (med Hjälp av Azure LightHouse).
- Centraliserad agentkonfiguration "i molnet" för företagsskala under hela datainsamlingens livscykel, från registrering till distribution till uppdateringar och ändringar över tid.
- Alla ändringar i konfigurationen distribueras automatiskt till alla agenter, utan att en distribution på klientsidan krävs.
- Större transparens och kontroll över fler funktioner och tjänster, till exempel Microsoft Sentinel, Defender för molnet och VM Insights.
- En enda agent som hanterar alla datainsamlingsbehov på servrar och klientenheter som stöds . En enda agent är målet, även om Azure Monitor Agent för närvarande konvergerar med Log Analytics-agenterna.
Innan du börjar
Granska förutsättningarna för att installera Azure Monitor Agent. Om du vill övervaka icke-Azure- och lokala servrar måste du installera Azure Arc-agenten. Arc-agenten gör dina lokala servrar synliga för Azure som en resurs som den kan rikta in sig på. Du debiteras ingen extra kostnad för att installera Azure Arc-agenten.
Kontrollera att Azure Monitor-agenten kan uppfylla alla dina behov. Azure Monitor Agent är allmän tillgänglighet (GA) för datainsamling och används för datainsamling av olika Azure Monitor-funktioner och andra Azure-tjänster.
Kontrollera att du har de behörigheter som krävs för att installera Azure Monitor-agenten. Du måste ha de behörigheter som krävs för att installera agenten på de datorer som du vill övervaka. Mer information finns i Behörigheter som krävs för att installera Azure Monitor-agenten.
Vägledning på hög nivå
Använd följande vägledning för att planera och köra migreringen:
- Förstå dina agenter och hur många du måste migrera.
- Förstå hur du använder dina arbetsytor.
- Förstå vilka lösningar, insikter och datasamlingar som är konfigurerade.
- Konfigurera dina datasamlingar och verifiera samlingarna.
- Förstå ytterligare beroenden och tjänster.
- Ta bort de äldre agenterna.
Azure Monitor Agent Migration Helper-arbetsboken är en arbetsboksbaserad Azure Monitor-lösning som kan hjälpa dig med vart och ett av stegen ovan. Den här guiden refererar till arbetsboken och andra verktyg i varje steg i migreringsprocessen. Mer information finns i Azure Monitor Agent Migration Helper-arbetsbok.
Förstå dina agenter
Använd DCR-generatorn för att konvertera din äldre agentkonfiguration till datainsamlingsregler automatiskt.1 För att förstå dina agenter kan du läsa följande frågor:
Fråga | Åtgärder |
---|---|
Hur många agenter måste du migrera? | Förstå antalet agenter som du måste migrera. |
Har du några agenter som distribueras utanför Azure? Distribueras dessa agenter i ditt eget datacenter eller i en annan molnmiljö? |
För servrar utanför Azure måste du först distribuera Azure ARC Connected Machine Agent. Mer information finns i Översikt över Azure Connected Machine-agenten. |
Använder du System Center Operations Manager (SCOM) ? Vilken plan har du tänkt dig för SCOM framöver? |
Om du planerar att fortsätta använda SCOM börjar du utvärdera SCOM Managed Instance. Mer information finns i SCOM-hanterad instans. |
Hur distribuerar du dina agenter idag? | Om du använder automatiserade metoder för att distribuera den äldre agenten bör du överväga när du ska stoppa de automatiserade distributionerna för nya servrar och börja fokusera på att distribuera den nya agenten. Genom att stoppa den automatiserade distributionen för nya servrar ser du till att du inte fortsätter att lägga till migreringsarbetet och kan fokusera på den befintliga inventeringen av agenter som ska migreras. |
Hjälparbetsboken för Azure Monitor-agentmigrering kan hjälpa dig att förstå hur många agenter du måste migrera. Mer information finns i Azure Monitor Agent migration helper workbook- Agents.|
Förstå dina arbetsytor, lösningar, insikter och datasamlingar
Innan migreringen ska du förstå hur dina Log Analytics-arbetsytor används. Kontrollera om alla används och vilka agenter som skickar sin telemetri till vilka arbetsytor. Många arbetsytor skapas över tid och det kan bli oklart vilka arbetsytor som faktiskt används, vilka arbetsytor som används för att samla in telemetri och från vilka servrar. Migrering är ett bra tillfälle att rensa och konsolidera dina arbetsytor.
Observera vilka lösningar som är konfigurerade när du tittar på dina arbetsytor. Den här informationen är viktig för att förstå vilka data du samlar in och hur du använder dem.
Hjälparbetsboken för Azure Monitor-agentmigrering kan hjälpa dig att förstå vilka arbetsytor du har och vilka lösningar som implementeras på varje arbetsyta och när du senast använde lösningen. Varje lösning har en migreringsrekommendations. Mer information finns i Azure Monitor Agent Migration Helper-arbetsbok – Arbetsytor
Du kan också använda Arbetsytegranskningsarbetsboken för Azure Monitor för att hjälpa dig att förstå dina arbetsytor. Om du vill använda Arbetsytegranskningsarbetsboken för Azure Monitor kopierar du arbetsboken från GitHub-lagringsplatsen och importerar den till Din Log Analytics-arbetsyta.
Den här arbetsboken samlar in alla dina Log Analytics-arbetsytor och visar följande för varje arbetsyta:
- Alla datakällor som skickar data till arbetsytan.
- De agenter som skickar pulsslag till arbetsytan.
- De resurser som skickar data till arbetsytan.
- Alla Application Insights-resurser som skickar data till arbetsytan.
Mer information finns i Arbetsytegranskningsarbetsbok för Azure Monitor.
Konfigurera dina datasamlingar och verifiera samlingarna
Tänk på följande när du konfigurerar dina datasamlingar:
Identifiera en pilotgrupp med servrar som du kan använda för den här processen. Använd pilotservrarna för att verifiera data innan du distribuerar i stor skala.
Använd DCR Config Generator för att transformera de datasamlingar som är konfigurerade på arbetsytan och distribuera dem som regler för datainsamling tillbaka till din miljö. Mer information om DCR Config Generator finns i DCR Config Generator.
Migrera VM Insights eller Azure Monitor for Virtual Machines till Azure Monitor-agenten. Verifiera de migrerade datasamlingarna för pilotgruppen med servrar jämfört med vad som samlades in före migreringen. För att undvika dubbel inmatning kan du inaktivera datainsamling från äldre agenter under testfasen utan att avinstallera agenterna ännu genom att ta bort arbetsytekonfigurationerna för äldre agenter. Mer information finns i Log Analytics-agentdatakällor i Azure Monitor
Verifiera de nya data för att säkerställa att det inte finns några luckor. Jämför data som matas in av äldre agentdata med Azure Monitor Agent. Använd KQL för att jämföra motsvarande data från varje agent baserat på agenttyp.
Planera distribution i stor skala med hjälp av Azure Policy. Använd inbyggda principer för att distribuera tillägg och DCR-associationer i stor skala. Med hjälp av principen säkerställs även automatisk distribution av tillägg och DCR-associationer för nya datorer. Mer information om hur du distribuerar i stor skala finns i Hantera Azure Monitor Agent – Använda Azure-principer.
Förstå ytterligare beroenden och tjänster
Innan migreringen är det viktigt att förstå hur dina andra tjänster påverkas.
Tjänst | Påverkan |
---|---|
Uppdateringshantering | Om du använder Uppdateringshantering under Azure Automation måste du migrera till Azure Update Manager. Azure Update Manager har en egen agent och är frikopplad från Azure Monitor-agenten. Uppdateringshanteringen kommer att vara inaktuell i slutet av augusti 2024. Vi rekommenderar att du migrerar till Azure Update Manager. Mer information finns i Flytta från Automation Update Management till Azure Update Manager. Arbetsboken för AMA-migreringshjälp visar vilka av dina datorer som använder uppdateringshanteringslösningen i dag och hur du migrerar dem. Mer information finns i Azure Monitor Agent Migration Helper-arbetsbok – Uppdateringshantering. |
Ändringsspårning och inventering | Om du använder Ändringsspårning och inventering måste du migrera till Azure Automation. Ändringsspårning och Inventory ingår också i Azure Automation. Azure Monitor-agenten har en lösning för ändringsspårning och inventering, men du måste skapa en datainsamlingsregel. Mer information finns i Hantera ändringsspårning och inventering med Azure Monitoring Agent. |
Defender för molnet | Om du använder Defender för molnet för tjänsten eller Defender för servrar och du har P2 aktiverat eller planerar att aktivera P2 för dina servrar ändrar du agentdistributionen i Defender för molnet från den äldre agentdistributionen till agentlös genomsökning. Om du använder Defender för molnet för att samla in säkerhetshändelser skapar du en anpassad datainsamlingsregel för att samla in dessa händelser. |
Microsoft Sentinel | Om du använder Microsoft Sentinel har lösningarna som använde den äldre agenten konverterats till Azure Monitor Agent-baserade lösningar och kan uppdateras. |
Ta bort de äldre agenterna
Som en del av migreringsplaneringen planerar du att ta bort den äldre agenten när migreringen är klar för att undvika duplicering av datainsamling.
Om du inte behöver behålla MMA på någon av dina datorer använder du MMA Discovery and Removal-verktyget för att ta bort agenten i stor skala. Mer information om verktyget för identifiering och borttagning av MMA finns i MMA-verktyget Identifiering och borttagning.
Om du däremot använder System Center Operations Manager (SCOM) behåller du MMA-agenten distribuerad till datorerna som du fortsätter att hantera med System Center Operations Manager.
Det finns ett SCOM-administratörshanteringspaket som kan hjälpa dig att ta bort arbetsytekonfigurationerna i stor skala samtidigt som du behåller SCOM-hanteringsgruppens konfiguration. Mer information om SCOM Admin Management Pack finns i SCOM Admin Management Pack.
Kända migreringsproblem
- IIS-loggar: När IIS-loggsamlingen är aktiverad kanske AMA inte fyller i
sSiteName
kolumnen iW3CIISLog
tabellen. Det här fältet samlas in som standard när IIS-loggsamlingen är aktiverad för den äldre agenten. Om du behöver samla in fältetsSiteName
med hjälp av AMA aktiverar duService Name (s-sitename)
fältet i W3C-loggning av IIS. Anvisningar för hur du aktiverar det här fältet finns i Välj W3C-fält att logga. - SQL-utvärderingslösning: Detta är nu en del av SQL Best Practice-utvärdering. Distributionsprinciperna kräver en Log Analytics-arbetsyta per prenumeration, vilket inte är den bästa praxis som rekommenderas av AMA-teamet.
- Microsoft Defender för molnet: övergår till en agentlös lösning. Vissa funktioner kommer inte att vara klara vid utfasningsdatumet. Kunder bör stanna kvar på MMA för datorer som använder FIM (File Integrity Monitoring), rekommendationer för identifiering av slutpunktsskydd, OS Misconfigurations (Azure Security Benchmark)-rekommendationer (ASB) och anpassningsbara programkontroller.
- Uppdateringshanteringen flyttas till en lösning utan agent men kommer inte att vara klar vid MMA-avskrivningsdatumet. Kunder som använder Uppdateringshantering bör behålla MMA tills den nya tjänsten Automated Update Manager är klar.