Indicazioni sulla risoluzione dei problemi per l'agente Monitoraggio di Azure in macchine virtuali Linux e set di scalabilità

Panoramica dell'agente di Monitoraggio di Azure

Prima di leggere altre informazioni, è necessario avere familiarità con Monitoraggio di Azure agent e Data Collection Rules.

Terminologia

Nome Acronimo Descrizione
agente Monitoraggio di Azure AMA Nuovo agente di Monitoraggio di Azure
Regole di raccolta dati DCR Regole per configurare la raccolta di dati da parte dell'agente, ad esempio cosa raccogliere, dove inviare e altro ancora
Servizio di configurazione Monitoraggio di Azure AMCS Servizio a livello di area ospitato in Azure, che controlla la raccolta dei dati per questo agente e altre parti di Monitoraggio di Azure. L'agente chiama questo servizio per recuperare i DCR.
Endpoint dei log -- Endpoint per l'invio di dati alle aree di lavoro Log Analytics
Endpoint delle metriche -- Endpoint per l'invio di dati ai database delle metriche di Monitoraggio di Azure.
Servizio metadati dell'istanza e ibrido IMDS e HIMDS Servizi ospitati in Azure che forniscono informazioni sulle macchine virtuali attualmente in esecuzione, i set di scalabilità (tramite IMDS) e i server abilitati per Arc (tramite HIMDS) rispettivamente
area di lavoro di Log Analytics DIRITTO Destinazione in Monitoraggio di Azure a cui è possibile inviare i log raccolti dall'agente
Metriche personalizzate -- Destinazione in Monitoraggio di Azure a cui è possibile inviare le metriche guest raccolte dall'agente

Procedura di base per la risoluzione dei problemi

Usare la procedura seguente per risolvere i problemi relativi alla versione più recente dell'agente Monitoraggio di Azure in esecuzione nella macchina virtuale Linux:

  1. Rivedi attentamente i prerequisiti qui.

  2. Verificare che l'estensione sia stata installata e che ne sia stato eseguito il provisioning, il che installa i file binari dell'agente nel computer:

    1. Aprire il portale di Azure > selezionare la macchina virtuale > Aprire Impostazioni : Estensioni + applicazioni dal riquadro a sinistra > 'AzureMonitorLinuxAgent' dovrebbe essere visualizzato con Stato: 'Provisioning riuscito'

    2. Se l'estensione non è elencata, verificare se il computer può raggiungere Azure e trovare l'estensione da installare usando il comando seguente:

      az vm extension image list-versions --location <machine-region> --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor
      
    3. Attendere 10-15 minuti, poiché l'estensione potrebbe essere in stato di transizione. Se non viene ancora visualizzato come descritto in precedenza, disinstallare e installare nuovamente l'estensione .

    4. Controlla se vedi errori nei log di estensione presenti in /var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/ sulla tua macchina

  3. Verificare che l'agente sia in esecuzione:

    1. Verificare se l'agente sta inviando i log degli heartbeat all'area di lavoro di analisi dei log utilizzando la seguente query. Ignorare se Se "Custom Metrics" (Parametri personalizzati) è l'unica destinazione nella regola di raccolta dati (DCR):

      Heartbeat | where Category == "Azure Monitor Agent" and Computer == "<computer-name>" | take 10
      
    2. Controllare se il servizio agente sia in esecuzione

      systemctl status azuremonitoragent
      
    3. Controllare se sono presenti errori nei log dell'agente di base situati in /var/opt/microsoft/azuremonitoragent/log/mdsd.* nel computer

  4. Verificare che la DCR esista e sia associata alla macchina virtuale:

    1. Se si utilizza l'area di lavoro di Log Analytics come destinazione, verificare che il DCR esista nella stessa area fisica dell'area di lavoro di Log Analytics.
    2. Aprire Azure portale > selezionare la regola di raccolta dati > Apri Configuration : Resources dal riquadro a sinistra > La macchina virtuale dovrebbe essere elencata qui.
    3. Se non è elencato, selezionare Aggiungi e selezionare la macchina virtuale dalla selezione risorse. Ripetere l'operazione in tutti i DCR.
  5. Verificare che l'agente sia stato in grado di scaricare le DCR associate dal servizio AMCS:

    1. Controllare se venga visualizzata la DCR più recente scaricata in questo percorso /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/
  6. Se la directory o i file sono mancanti:

    1. L'agente Monitoraggio di Azure non è riuscito a scaricare la regola di raccolta dati (DCR) dal servizio di configurazione Monitoraggio di Azure (AMCS).
    2. Ciò indica in genere uno dei seguenti elementi:
    3. La macchina virtuale non è associata ad alcun DCR.
    4. La macchina virtuale non può raggiungere AMCS a causa di restrizioni di rete o DNS.
    5. Il servizio Monitoraggio di Azure Agent non è in esecuzione o non è riuscito durante l'avvio.
  7. Eseguire queste azioni:

    1. Verificare che il DCR sia associato alla macchina virtuale:

      • Azure portale → Regole di raccolta dati → Seleziona il tuo DCR → Risorse
      • Verificare che la macchina virtuale venga visualizzata nell'elenco.
    2. Controllare la connettività in uscita dalla macchina virtuale:

      curl -v https://global.handler.control.monitor.azure.com
      
    3. Una connessione TLS riuscita conferma che la macchina virtuale può raggiungere AMCS.

    4. Riavviare l'agente:

      sudo systemctl restart azuremonitoragent
      sudo systemctl status azuremonitoragent
      
    5. Controllare i log degli errori dell'agente:

      sudo tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.err
      
  8. L'aspetto di un file di configurazione valido è simile al seguente:

    1. Ogni file in /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/ rappresenta una regola di raccolta dati analizzata scaricata da Azure.

    2. Esempio:

      ls /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/
      
    3. Risultato:

      dcr_1a2b3c4d.json
      dcr_5e6f7g8h.json
      
    4. Esaminare un file:

      cat /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/dcr_1a2b3c4d.json
      
    5. I contenuti tipici includono:

      {
      "dataSources": {
      "syslog": [
      {
      "facilityNames": ["daemon"],
      "logLevels": ["Info", "Warning", "Error"]
      }
      ]
      },
      "destinations": {
      "logAnalytics": [
      {
      "workspaceResourceId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>"
      }
      ]
      }
      }
      

Se questi file sono vuoti, mancanti o in formato non valido, l'agente non raccoglie o carica i dati.

Problemi di raccolta di Syslog

Per altre informazioni su come risolvere i problemi di syslog con Monitoraggio di Azure Agent, vedere here.

  • Il file qualità del servizio (QoS) /var/opt/microsoft/azuremonitoragent/log/mdsd.qos fornisce aggregazioni in formato CSV di 15 minuti degli eventi elaborati e contiene le informazioni sulla quantità di eventi Syslog elaborati nell'intervallo di tempo specificato. Questo file è utile per tenere traccia di cali di inserimenti di eventi Syslog.

    L'esempio seguente mostra che nei 15 minuti precedenti 2022-02-28T19:55:23.5432920Z, l'agente ha ricevuto 77 eventi syslog con informazioni sul daemon della struttura e sul livello e ha inviato 77 di tali eventi all'attività di caricamento. Inoltre, l'attività di caricamento dell'agente ha ricevuto 77 messaggi daemon.info e li ha caricati correttamente tutti e 77.

    #Time: 2022-02-28T19:55:23.5432920Z
    #Fields: Operation,Object,TotalCount,SuccessCount,Retries,AverageDuration,AverageSize,AverageDelay,TotalSize,TotalRowsRead,TotalRowsSent
    ...
    MaRunTaskLocal,daemon.debug,15,15,0,60000,0,0,0,0,0
    MaRunTaskLocal,daemon.info,15,15,0,60000,46.2,0,693,77,77
    MaRunTaskLocal,daemon.notice,15,15,0,60000,0,0,0,0,0
    MaRunTaskLocal,daemon.warning,15,15,0,60000,0,0,0,0,0
    MaRunTaskLocal,daemon.error,15,15,0,60000,0,0,0,0,0
    MaRunTaskLocal,daemon.critical,15,15,0,60000,0,0,0,0,0
    MaRunTaskLocal,daemon.alert,15,15,0,60000,0,0,0,0,0
    MaRunTaskLocal,daemon.emergency,15,15,0,60000,0,0,0,0,0
    ...
    MaODSRequest,https://e73fd5e3-ea2b-4637-8da0-5c8144b670c8_LogManagement,15,15,0,455067,476.467,0,7147,77,77
    

Passaggi per la risoluzione dei problemi

  1. Esaminare prima i passaggi generici per la risoluzione di problemi di Linux AMA. Se l'agente emette heartbeat, procedere con il passaggio 2.

  2. La configurazione analizzata viene archiviata in /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/. Verificare che la raccolta Syslog sia definita e che le destinazioni di log siano uguali a quelle costruite in DCR UI / DCR JSON.

    1. In caso affermativo, procedere con il passaggio 3. In caso contrario, il problema ha a che fare con il flusso di lavoro di configurazione.
    2. Esaminare i file mdsd.err,mdsd.warn, mdsd.info in /var/opt/microsoft/azuremonitoragent/log per individuare possibili errori di configurazione.
  3. Convalidare il layout del flusso di lavoro della raccolta Syslog per assicurarsi che tutte le parti necessarie siano presenti e accessibili:

    1. Per gli utenti rsyslog, assicurarsi che il file /etc/rsyslog.d/10-azuremonitoragent.conf sia presente, non sia vuoto e sia accessibile dal daemon rsyslog (utente syslog).
      1. Controllare la configurazione di rsyslog in /etc/rsyslog.conf e /etc/rsyslog.d/* per verificare se sono presenti input associati a un set di regole non predefinito, perché i messaggi di questi input non vengono inoltrati a Monitoraggio di Azure Agent. Ad esempio, i messaggi di un input configurato con un set di regole non predefinito, ad input(type="imtcp" port="514" ruleset="myruleset") esempio, non vengono inoltrati.
    2. Per gli utenti syslog-ng, assicurarsi che il file /etc/syslog-ng/conf.d/azuremonitoragent.conf sia presente, non sia vuoto e sia accessibile dal daemon syslog-ng (utente syslog).
    3. Verificare che il file /run/azuremonitoragent/default_syslog.socket esista e sia accessibile rispettivamente da rsyslog o syslog-ng.
    4. Verificare che la coda del daemon Syslog non sia sovraccarica, causando il fallimento del caricamento, consultando le indicazioni fornite qui: I dati Rsyslog non vengono caricati a causa di un problema di spazio su disco esaurito nell'agente Linux AMA
  4. Per eseguire ulteriormente il debug dell'inserimento di eventi syslog, è possibile aggiungere il flag -T 0x2002 di traccia alla fine di MDSD_OPTIONS nel file /etc/default/azuremonitoragente riavviare l'agente:

    export MDSD_OPTIONS="-A -c /etc/opt/microsoft/azuremonitoragent/mdsd.xml -d -r $MDSD_ROLE_PREFIX -S $MDSD_SPOOL_DIRECTORY/eh -L $MDSD_SPOOL_DIRECTORY/events -e $MDSD_LOG_DIR/mdsd.err -w $MDSD_LOG_DIR/mdsd.warn -o $MDSD_LOG_DIR/mdsd.info -T 0x2002"
    
  5. Dopo aver riprodotto il problema con il flag di traccia attivato, troverai ulteriori informazioni di debug in /var/opt/microsoft/azuremonitoragent/log/mdsd.info. Esaminare il file per individuare la possibile causa del problema di raccolta syslog, ad esempio errori di analisi / elaborazione / configurazione / caricamento.

    Avviso

    Assicurarsi di rimuovere l'impostazione del flag di traccia -T 0x2002 dopo la sessione di debug, poiché genera molte istruzioni di traccia che potrebbero riempire il disco più rapidamente o rendere difficile l'analisi visiva del file di resoconto.

Risoluzione dei problemi nel server abilitato per Arc

Se dopo aver controllato i passaggi di risoluzione dei problemi di base non vengono visualizzati i log di Monitoraggio di Azure Agent o si trovano 'Impossibile ottenere il token MSI dall'endpoint IMDS' errori nel file di log /var/opt/microsoft/azuremonitoragent/log/mdsd.err, è probabile che syslog utente non sia membro del gruppo himds. Se l’utente non è membro di questo gruppo, aggiungere utente syslog al gruppo di utenti himds. Se necessario, creare l'utente syslog e il gruppo syslog e assicurarsi che l'utente faccia parte di tale gruppo. Per ulteriori informazioni, consultare i requisiti di autenticazione dei server abilitati per Azure Arc qui.

Per un elenco completo degli account utente Linux creati dall'agente Monitoraggio di Azure e Azure Arc, vedere Account utenteLinux creati durante l'installazione.

Problemi relativi agli aggiornamenti automatici nei set di scalabilità di macchine virtuali

Quando si abilita l'aggiornamento automatico delle estensioni per AzureMonitorLinuxAgent in un set di scalabilità di macchine virtuali, il flag aggiorna innanzitutto il modello del set di scalabilità. Se i criteri di aggiornamento del set di scalabilità sono impostati su Manuale, questa modifica non viene propagata alle istanze esistenti fino a quando non si applica l'aggiornamento del modello.

È possibile applicare il modello più recente nel portale di Azure o a livello di codice.

  1. Passare al portale Azure.
  2. Aprire il set di scalabilità di macchine virtuali.
  3. Vai a Istanze.
  4. Selezionare le istanze da aggiornare.
  5. Nella barra dei menu in alto selezionare Aggiorna>Applica modello più recente.

In questo modo il modello del set di scaling corrente (incluso il flag aggiornato enableAutomaticUpgrade) viene applicato alle istanze selezionate.

Suggerimento

È possibile modificare i criteri di aggiornamento in Rolling in modo che le modifiche future del modello vengano propagate automaticamente. Esegui il seguente comando CLI e sostituisci <resource-group> e <vmss> con i nomi del tuo gruppo di risorse e del tuo set di scalabilità delle macchine virtuali.

az vmss update -g <resource-group> -n <vmss> --set upgradePolicy.mode=Rolling

Se le macchine virtuali specifiche non vengono ancora aggiornate, controllare la Protezione dell'istanza (protezione dalle azioni del set di scalabilità) e disattivarla se impostata.

Passaggi successivi