Condividi tramite


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.

Importante

L'agente di Log Analytics è stato ritirato il 31 agosto 2024. Questa deprecazione non si applica all'agente MMA connesso esclusivamente a un'installazione SCOM locale.

Se si usa l'agente MMA od OMS dopo il 31 agosto 2024, è possibile che si verifichi quanto descritto di seguito.

  • Caricamento dei dati: I servizi di inserimento cloud ridurranno gradualmente il supporto per gli agenti MMA, con conseguente perdita di supporto per l'inserimento e potenziali problemi di compatibilità per gli agenti MMA nel tempo. Le funzionalità di caricamento non verranno distribuite in nuove aree
  • 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é eseguire le installazioni offline.
  • Supporto clienti: non sarà possibile ottenere supporto per problemi relativi agli agenti legacy.
  • Supporto del sistema operativo: Il supporto per le nuove distribuzioni linux o Windows, inclusi i Service Pack, non sarà disponibile dopo la deprecazione degli agenti legacy.
  • L'agente di Log Analytics può coesistere con l'agente di Monitoraggio di Azure. Si prevede di visualizzare dati duplicati se entrambi gli agenti raccolgono gli stessi dati.

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 di alto livello

Usare le indicazioni seguenti per pianificare ed eseguire la migrazione:

  • Conoscere i propri agenti e capire di quanti 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 del Assistente 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 ulteriori informazioni, vedere la cartella di lavoro dello strumento di assistenza alla migrazione dell'agente di Monitoraggio Azure.

Comprendi i tuoi agenti

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

Domanda Azioni
Quanti agenti devi migrare? 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)?

Qual è il piano previsto per SCOM in futuro?

Se si prevede di continuare a usare SCOM, iniziare a valutare l'istanza gestita di SCOM. Per altre informazioni, vedere Istanza gestita di SCOM.
Come stai implementando i tuoi agenti oggi? 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, analisi 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 conoscere meglio le proprie aree di lavoro. Per usare il workbook di audit dell'area di lavoro di Azure Monitor, copiarlo dal repository GitHub e importarlo nell'area di lavoro di 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 fonti di 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 ulteriori informazioni, vedere Origini dati dell'agente di Log Analytics in Azure Monitor

  • Convalidare i nuovi dati per assicurarsi che non vi siano lacune. Confrontare i dati inseriti dall'agente legacy con quelli dell’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 predefiniti per distribuire estensioni e associazioni DCR su larga scala. L'uso della politica assicura anche la distribuzione automatica delle estensioni e delle 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.

Servizio 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.

La Gestione degli aggiornamenti verrà deprecata 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.

Monitoraggio delle modifiche e gestione dell'inventario Se si utilizzano Monitoraggio delle modifiche e Gestione dell'inventario, è necessario eseguire la migrazione a Azure Automation.

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 Microsoft Monitoring Agent 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 per l'amministrazione di SCOM che consente di rimuovere le configurazioni dell'area di lavoro su larga scala mantenendo la configurazione del Gruppo di gestione SCOM. Per maggiori informazioni su SCOM Admin Management Pack, 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.

Passaggi successivi