Eseguire la migrazione all'agente di Monitoraggio di Azure dalle estensioni di diagnostica di Azure (WAD/LAD)

Le estensioni di Diagnostica di Azure (WAD/LAD) sono deprecate e ritirate il 31 marzo 2026. Per indicazioni complete sulla migrazione, vedere qui.
Come opzione di migrazione, è possibile eseguire la migrazione all'agente di Monitoraggio di Azure.As a migration option, you can migrate to Azure Monitor Agent (AMA). Viene configurato con le regole di raccolta dati (DCR) per continuare a raccogliere i log del sistema operativo guest e i dati sulle prestazioni. Consente il routing multi-destinazione, centralizzato, una configurazione più sicura e una gestione su larga scala.

Annotazioni

Le Regole di Raccolta dei Dati forniscono trasformazioni (filtro in fase di inserimento, analisi sintattica) per ridurre i costi e personalizzare gli schemi, un elemento non disponibile in WAD/LAD.

Confronto tra agenti WAD/LAD e AMA

Area WAD/LAD AMA
Stato Eredità; ritiro 31 marzo 2026 Agente attuale e strategico
Modello di configurazione XML/JSON/WAD, schema LAD DCR centralizzate in Azure che offrono anche trasformazioni (filtro in fase di inserimento, analisi) per ridurre i costi e personalizzare gli schemi
Security Chiavi di archiviazione, modelli di autenticazione classici Accesso basato sulle identità gestite di Azure; endpoint TLS (Transport Layer Security) moderni
Rete Per estensione in uscita Endpoint/etichette di servizio standardizzati per AMA ed endpoint di raccolta dati (DCEs)

Passaggi per la migrazione

Usare l'approccio in più fasi seguente per eseguire la migrazione da WAD/LAD ad AMA con DCR.

Fase 1: Individuare e valutare

  1. Computer di inventario che eseguono WAD/LAD

    1. Per la visualizzazione per macchina virtuale nel portale di Azure, passare alla scheda Estensioni e applicazioni .
    2. Per ogni macchina virtuale è possibile usare l'interfaccia della riga di comando di Azure:
    az vm extension list  --resource-group <RESOURCE_GROUP>  --vm-name <VM_NAME> --output table
    1. Per la visualizzazione della flotta, usare la query di Azure Resource Graph nell'articolo panoramica di WAD/LAD per trovare le estensioni in base all'editore == Microsoft.Azure.Diagnostics.

  2. Estrarre la configurazione di diagnostica corrente: raccogliere WAD public config XML (Windows) e LAD JSON (Linux) per elencare contatori, eventi, strutture syslog/gravità, percorsi di file, pianificazioni di trasferimento e destinazioni.

    az vm extension show --resource-group <RESOURCE_GROUP> --vm-name <VM_NAME> --name <EXTENSION_NAME>  --query "settings" --output json

  3. Classificare in ordine di priorità gli elementi da mantenere o eliminare: usare questo momento per ridurre il rumore e i tipi di dati inutilizzati, se presenti. Usando le trasformazioni DCR, è anche possibile filtrare in base ai segnali essenziali.

Fase 2: Progettare DCR

  1. Creare DCR che replichino la finalità WAD/LAD:
    1. Origini dati di macchine virtuali standard , ad esempio eventi di Windows (ad esempio, System, Application, Security), Syslog Linux, contatori delle prestazioni.
    2. Log di testo personalizzati (stessi caratteri jolly del percorso del file, assicurarsi che esistano tabelle personalizzate; spesso richiede un DCE) inviati al livello ausiliario a basso costo in analisi dei log.
    3. Routing di destinazione ADX.

Annotazioni

Mantenere Windows e Linux in DCR separate per evitare la duplicazione accidentale dei contatori (stessa metrica da entrambi gli stili di denominazione).

Fase 3: Implementare AMA e assegnare regole di raccolta dati su larga scala

  1. Preparare i prerequisiti per l'installazione di Ama e l'associazione DCR, inclusa la verifica delle impostazioni di rete e del sistema operativo supportate.
  2. Assicurarsi che l'area di lavoro Log Analytics sia configurata con il livello ausiliario in base alle esigenze.
  3. (Scelta consigliata) Usare iniziative predefinite di Criteri di Azure per installare AMA su Windows e Linux e associare DCR. Utilizzando i criteri, puoi eseguire automaticamente l'onboarding di nuove macchine e correggere quelle esistenti, allineandoti con le migliori pratiche di migrazione.

Fase 4: Convalidare

  1. Integrità dell'agente: verificare che lo stato dell'estensione AzureMonitorWindowsAgent e AzureMonitorLinuxAgent sia Provisioning riuscito nelle macchine virtuali.
  2. Flusso di dati:
    1. Log: eseguire query nell'area di lavoro di analisi dei log (ad esempio, evento, syslog, tabella personalizzata) in base all'origine dati DCR.
    2. Contatori delle prestazioni in Parametri: passare alla vista Parametri VM nello spazio dei nomi guest della macchina virtuale per visualizzare i contatori tramite il routing AMA-Parametri.

Fase 5: Rimuovere WAD/LAD

  1. Coordinare una finestra di cutover per ogni ambiente (Sviluppo → Test → Produzione).
  2. Arrestare o rimuovere l'estensione Microsoft.Azure.Diagnostics da ogni macchina virtuale una volta confermata la parità dei dati AMA. Questo passaggio è consigliato in modo esplicito per evitare il doppio inserimento e costi aggiuntivi.

Suggerimenti comuni per la risoluzione dei problemi

  • Agente installato ma nessun servizio visibile su Windows: AMA viene eseguito con un modello di estensione e un processo. Verificare l'agente tramite l'area Estensioni della macchina virtuale e l'associazione DCR anziché cercare un servizio "Agente di Monitoraggio di Azure".
  • Nessun dato dai log personalizzati: verificare che la tabella personalizzata esista, che il DCE sia configurato (se necessario), che i modelli di file siano corretti e che il delimitatore di record e il formato dell'ora corrispondano ai file.
  • Firewall o proxy bloccato: convalidare la porta in uscita 443 per il controllo, il DCR, l'ODS e l'DCE come endpoint di acquisizione. È necessario disabilitare l'ispezione HTTPS.
  • Last updated on