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

Articolo
07/04/2024

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.

Importante

L'agente di Log Analytics verrà ritirato il 31 agosto 2024. Quando si usa l'agente MMA o OMS dopo questa data, ci si può aspettare quanto segue.

Caricamento dei dati: i servizi di inserimento cloud ridurranno gradualmente il supporto per gli agenti MMA, con conseguente riduzione del supporto e potenziali problemi di compatibilità per agenti MMA nel corso del tempo. L'inserimento per MMA rimarrà invariato fino al febbraio 1 2025.
Installazione: la possibilità di installare gli agenti legacy verrà rimossa dal portale di Azure e i criteri di installazione per gli agenti legacy verranno rimossi. È comunque possibile installare l'estensione agenti MMA, nonché le installazioni offline.
Supporto tecnico: non sarà possibile ottenere supporto per problemi dell'agente legacy.
Supporto del sistema operativo: il supporto per le nuove distribuzioni di Linux o Windows, inclusi service pack, non verranno aggiunti dopo la deprecazione degli agenti legacy.

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

Per comprendere meglio gli agenti, esaminare le domande seguenti:

Domanda	Azioni
Di quanti agenti è necessario eseguire la migrazione?	Comprendere il numero di agenti di cui è necessario eseguire la migrazione.
Sono presenti agenti distribuiti all'esterno di Azure? Questi agenti sono distribuiti nel proprio data center o in un altro ambiente cloud?	Per i server esterni ad Azure, è prima necessario distribuire l'agente di Azure ARC Connected Machine. Per altre informazioni, vedere Panoramica dell'agente di Azure Connected Machine.
Si sta usando System Center Operations Manager (SCOM)? Quali piani futuri ha l'utente per il SCOM?	Se si prevede di continuare a usare SCOM, iniziare a valutare l'istanza gestita di SCOM. Per altre informazioni, vedere Istanza gestita di SCOM.
In che modo l'utente distribuisce gli agenti al momento?	Se si usano metodi automatizzati per distribuire l'agente legacy, riflettere su quando arrestare le distribuzioni automatizzate per i nuovi server e iniziare a concentrarsi sulla distribuzione del nuovo agente. L'arresto della distribuzione automatica per nuovi server consente di assicurarsi di non continuare ad aggiungere carico al lavoro di migrazione e di concentrarsi sull'inventario esistente degli agenti di cui eseguire la migrazione.

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.

Service	Impatto
Gestione degli aggiornamenti	Se si usa Gestione aggiornamenti in Automazione di Azure, è necessario eseguire la migrazione ad Azure Update Manager. Azure Update Manager ha un proprio agente ed è separato dall'agente di Monitoraggio di Azure. Gestione aggiornamenti verrà deprecato alla fine di agosto 2024. È consigliabile eseguire la migrazione a Gestore aggiornamenti di Azure. Per altre informazioni, vedere Passare da Gestione aggiornamenti di Automazione di Azure a Gestore aggiornamenti di Azure. La cartella di lavoro dell'helper per la migrazione AMA mostra quali computer usano la soluzione Gestione aggiornamenti e come eseguirne la migrazione. Per altre informazioni, vedere Guida alla migrazione dell'agente di Monitoraggio di Azure - Gestione aggiornamenti.
Rilevamento modifiche e inventario	Se si usano Rilevamento modifiche e inventario, è necessario eseguire la migrazione ad Automazione di Azure. Rilevamento modifiche e inventario fanno anch'essi parte di Automazione di Azure. Sebbene l'agente di Monitoraggio di Azure disponga di una soluzione di rilevamento modifiche e inventario, è necessario creare una regola di raccolta dati. Per altre informazioni, vedere Gestire il rilevamento modifiche e l'inventario con l'agente di monitoraggio di Azure.
Defender per il Cloud	Se si usa Defender per il cloud per il proprio servizio o Defender per server e si dispone di P2 abilitato o si prevede di abilitare P2 per i server, modificare la distribuzione dell'agente in Defender per il Cloud dalla distribuzione dell'agente legacy alla scansione senza agente. Se si usa Defender per il cloud per raccogliere eventi di sicurezza, creare una regola di raccolta dati personalizzata per raccogliere tali eventi.
Microsoft Sentinel	Se si usa Microsoft Sentinel, le soluzioni che usano l'agente legacy sono state convertite in soluzioni basate su Agente di Monitoraggio di Azure e possono essere aggiornate.

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.

Gap di parità noti che possono influire sulla migrazione

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.
Sentinel: i log di Windows Firewall non sono ancora disponibili a livello generale.
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: alcune funzionalità per la nuova soluzione senza agente sono in fase di sviluppo. La migrazione potrebbe subire un impatto negativo se si usano 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.
Informazioni dettagliate sui contenitori: la versione di Windows è disponibile in anteprima pubblica.

Condividi tramite