Eseguire la migrazione all'agente di Monitoraggio di Azure dall'agente di Log Analytics

Agente di Monitoraggio di Azure (AMA) sostituisce l'agente di Log Analytics, noto anche come agente di Monitoraggio Microsoft (MMA) e OMS, per computer Windows e Linux, in ambienti Azure e non Azure, locali e altri cloud. L'agente introduce un metodo semplificato e flessibile per configurare la raccolta dati usando le regole di raccolta dati. Questo articolo fornisce indicazioni su come implementare una migrazione corretta dall'agente di Log Analytics all'agente di Monitoraggio di Azure.

La migrazione è un'attività complessa. Iniziare a pianificare la migrazione all'agente di Monitoraggio di Azure usando le informazioni contenute in questo articolo come guida.

Vantaggi

L'agente di Monitoraggio di Azure offre vantaggi immediati, come illustrato di seguito:

• Risparmio sui costi mediante regole di raccolta dei dati:
  • Rispetto all'approccio "tutti o niente" degli agenti legacy, abilita la raccolta di dati mirata e granulare per un computer o per subset di computer.
  • Consente di filtrare le regole e le trasformazioni dei dati per ridurre il volume di dati complessivo in caricamento, riducendo così in modo significativo i costi di inserimento e archiviazione.
• Sicurezza e prestazioni
  • Protezione avanzata tramite identità gestita e token di Microsoft Entra (per i client).
  • Velocità effettiva dell’evento superiore del 25% rispetto agli agenti di Log Analytics (MMA/OMS) legacy.
• Gestione più semplice, inclusa la risoluzione dei problemi efficiente:
  • Supporta i caricamenti di dati in più destinazioni (più aree di lavoro Log Analytics, ad esempio multihoming in Windows e Linux), anche tra aree e raccolte di dati tra tenant (tramite Azure LightHouse).
  • Configurazione centralizzata dell'agente "nel cloud" per la scalabilità di livello aziendale durante tutto il ciclo di vita della raccolta dei dati, dall'onboarding alla distribuzione, agli aggiornamenti e alle modifiche nel tempo.
  • Tutte le modifiche apportate alla configurazione vengono implementate automaticamente in tutti gli agenti, senza richiedere la distribuzione lato client.
  • Maggiore trasparenza e controllo di più funzionalità e servizi, ad esempio Microsoft Sentinel, Defender per il cloud e Informazioni dettagliate macchina virtuale.
• Un singolo agente che gestisce tutte le esigenze di raccolta dei dati tra server e dispositivi client supportati. L'obiettivo è un singolo agente, anche se l'agente di Monitoraggio di Azure sta attualmente convergendo con gli agenti di Log Analytics.

Operazioni preliminari

• Esaminare i prerequisiti per l'installazione dell'agente di Monitoraggio di Azure. Per monitorare i server non Azure e locali è necessario installare l'agente di Azure Arc. L'agente Arc rende i server locali visibili ad Azure come risorsa di destinazione. Non vengono addebitati costi aggiuntivi per l'installazione dell'agente di Azure Arc.

• Verificare che l'agente di Monitoraggio di Azure possa soddisfare tutte le esigenze. L'agente di Monitoraggio di Azure è di disponibilità generale (GA) per la raccolta dati e viene usato per la raccolta di dati da varie funzionalità di Monitoraggio di Azure e da altri servizi di Azure.

• Verificare di avere le autorizzazioni necessarie per installare l'agente di Monitoraggio di Azure. È necessario disporre delle autorizzazioni necessarie per installare l'agente nei computer da monitorare. Per altre informazioni, vedere Autorizzazioni necessarie per installare l'agente di Monitoraggio di Azure.

Linee guida generali

Usare le indicazioni seguenti per pianificare ed eseguire la migrazione:

• Comprendere i propri agenti e di quanti elementi sia necessario eseguire la migrazione.
• Comprendere come si stiano usando le proprie aree di lavoro.
• Comprendere quali soluzioni, informazioni dettagliate e raccolte di dati sono configurate.
• Configurare le raccolte dati e convalidarle.
• Informazioni su dipendenze e servizi aggiuntivi.
• Rimuovere gli agenti legacy.

La cartella di lavoro dell'helper per la migrazione dell'agente di Monitoraggio di Azure è una soluzione di Monitoraggio di Azure basata su cartella di lavoro che può essere utile in ognuno dei passaggi descritti in precedenza. Questa guida fa riferimento alla cartella di lavoro e ad altri strumenti in ogni fase del processo di migrazione. Per altre informazioni, vedere Cartella di lavoro dell'helper di migrazione dell'agente di Monitoraggio di Azure.

Informazioni sugli agenti

Usare il generatore DCR per convertire automaticamente la configurazione dell'agente legacy in regole di raccolta dati.¹ Per comprendere gli agenti, rivedere le domande seguenti:

La cartella di lavoro dell'helper per la migrazione dell'agente di Monitoraggio di Azure consente di comprendere il numero di agenti di cui eseguire la migrazione. Per altre informazioni, vedere Cartella di lavoro dell'helper di migrazione dell'agente di Monitoraggio di Azure- Agenti.|

Informazioni su aree di lavoro, soluzioni, informazioni dettagliate e raccolte di dati

Prima di eseguire la migrazione, comprendere come vengono usate le aree di lavoro Log Analytics. Controllare se sono tutte in uso e quali agenti inviano i dati di telemetria a quali aree di lavoro. Molte aree di lavoro vengono create nel corso del tempo e può diventare poco chiaro quali aree di lavoro siano effettivamente in uso, quali vengano usate per raccogliere dati di telemetria e da quali server. La migrazione è un'ottima opportunità per ripulire e consolidare le aree di lavoro.

Quando si esaminano le aree di lavoro, tenere presente quali soluzioni sono configurate. Queste informazioni sono importanti per comprendere i dati raccolti e il modo in cui vengono usati.

La cartella di lavoro dell'helper per la migrazione dell'agente di Monitoraggio di Azure consente di comprendere quali aree di lavoro siano disponibili, le soluzioni implementate in ogni area di lavoro e quando sia stata usata per l'ultima volta la soluzione. Ogni soluzione ha una raccomandazione sulla migrazione. Per altre informazioni, vedere Cartella di lavoro dell'helper di migrazione dell'agente di Monitoraggio di Azure - Aree di lavoro

Anche la cartella di lavoro di controllo dell'area di lavoro di Monitoraggio di Azure può essere d'aiuto per comprendere le aree di lavoro. Per usare la cartella di lavoro di controllo dell'area di lavoro di Monitoraggio di Azure, copiarla dal repository GitHub e importarla nell'area di lavoro Log Analytics.

Questa cartella di lavoro raccoglie tutte le aree di lavoro Log Analytics e mostra le informazioni seguenti per ogni area di lavoro:

• Tutte le origini dati che inviano dati all'area di lavoro.
• Agenti che inviano heartbeat all'area di lavoro.
• Risorse che inviano dati all'area di lavoro.
• Eventuali risorse di Application Insights che inviano dati all'area di lavoro.

Per altre informazioni, vedere Cartella di lavoro di controllo dell'area di lavoro di Monitoraggio di Azure.

Configurare le raccolte dati e convalidarle

Quando si configurano le raccolte di dati, seguire questa procedura:

• Identificare un gruppo pilota di server da usare per questo processo. Usare i server pilota per convalidare i dati prima di eseguire la distribuzione su larga scala.

• Usare il generatore di configurazione DCR per trasformare le raccolte di dati configurate nell'area di lavoro e distribuirle come regole di raccolta dati nell'ambiente in uso. Per altre informazioni sul generatore di configurazione DCR, vedere Generatore di configurazione DCR.

• Eseguire la migrazione di Informazioni dettagliate sulla macchina virtuale o Monitoraggio di Azure per macchine virtuali all'agente di Monitoraggio di Azure. Convalidare le raccolte di dati di cui è stata eseguita la migrazione per il gruppo pilota di server rispetto a quanto raccolto prima della migrazione. Per evitare il doppio inserimento, è possibile disabilitare la raccolta dati dagli agenti legacy durante la fase di test senza ancora disinstallare gli agenti rimuovendo le configurazioni dell'area di lavoro per agenti legacy. Per altre informazioni, vedere Origini dati dell'agente di Log Analytics in Monitoraggio di Azure

• Convalidare i nuovi dati per assicurarsi che non vi siano lacune. Confrontare i dati inseriti dai dati dell'agente legacy con l'agente di Monitoraggio di Azure. Usare KQL per confrontare i dati equivalenti di ogni agente in base al tipo di agente.

• Pianificare la distribuzione su larga scala usando Criteri di Azure. Usare i criteri integrati per distribuire estensioni e associazioni DCR su larga scala. L'uso di criteri garantisce anche la distribuzione automatica di estensioni e associazioni DCR per i nuovi computer. Per altre informazioni sulla distribuzione su larga scala, vedere Gestire l'agente di Monitoraggio di Azure - Criteri d‘uso di Azure.

Informazioni su dipendenze e servizi aggiuntivi

Prima di eseguire la migrazione, è importante comprenderne l'impatto sugli altri servizi.

Rimuovere gli agenti legacy

Come parte della pianificazione della migrazione, pianificare la rimozione dell'agente legacy al termine della migrazione per evitare la duplicazione della raccolta dati.

Se non è necessario conservare l'MMA in uno dei computer, usare lo strumento di individuazione e rimozione MMA per rimuovere l'agente su larga scala. Per altre informazioni sullo strumento di individuazione e rimozione MMA, vedere Strumento di individuazione e rimozione MMA.

Tuttavia, se si usa System Center Operations Manager (SCOM), mantenere l'agente MMA distribuito nei computer che si continuerà a gestire con System Center Operations Manager.

Esiste un Management Pack amministratore SCOM che consente di rimuovere le configurazioni dell'area di lavoro su larga scala mantenendo la configurazione del gruppo di gestione SCOM. Per altre informazioni sul Management Pack amministratore SCOM, vedere SCOM Admin Management Pack.

Problemi di migrazione noti

• Log IIS: quando la raccolta di log IIS è abilitata, AMA potrebbe non popolare la colonna sSiteName della tabella W3CIISLog. Questo campo viene raccolto per impostazione predefinita quando la raccolta di log IIS è abilitata per l'agente legacy. Se è necessario raccogliere il campo sSiteName usando AMA, abilitare il campo Service Name (s-sitename) nella registrazione W3C di IIS. Per i passaggi per abilitare questo campo, vedere Selezionare campi W3C da registrare.
• Soluzione di valutazione SQL: questa è ora parte della valutazione delle procedure consigliate di SQL. I criteri di distribuzione richiedono un'area di lavoro Log Analytics per ogni sottoscrizione, il che non è la procedura consigliata dal team AMA.
• Microsoft Defender per il cloud: passa a una soluzione senza agente. Alcune funzionalità non saranno pronte entro la data di deprecazione. I clienti devono rimanere su MMA per i computer che usano il Monitoraggio dell'integrità dei file (FIM), Raccomandazioni per l'individuazione di Endpoint Protection, configurazioni non corrette del sistema operativo (raccomandazioni di Azure Security Benchmark) e controlli applicazioni adattivi.
• La gestione degli aggiornamenti sta passando a una soluzione senza agenti, ma non sarà pronta per la data di ammortamento di MMA. I clienti che usano Gestione aggiornamenti devono rimanere su MMA fino a quando non sarà pronto il nuovo servizio Gestione aggiornamenti automatizzati.

Passaggi successivi

• Cartella di lavoro dell'helper di migrazione dell'agente di Monitoraggio di Azure
• Generatore di configurazione DCR
• Strumento di individuazione e rimozione MMA