Condividi tramite

Risolvere i problemi relativi all'agente Log Analytics per Linux

  • Articolo

Questo articolo fornisce informazioni sulla risoluzione degli errori che potrebbero verificarsi con l'agente di Log Analytics per Linux in Monitoraggio di Azure.

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione Linux prossima allo stato EOL (End of Life, fine del ciclo di vita). Valutare le proprie esigenze e pianificare di conseguenza. Per ulteriori informazioni, consultare la Guida alla fine del ciclo di vita di CentOS.

Strumento di risoluzione dei problemi di Log Analytics

Lo strumento di risoluzione dei problemi dell'agente di Log Analytics per Linux è uno script progettato per individuare e diagnosticare i problemi relativi all'agente di Log Analytics. Viene incluso automaticamente con l'agente al momento dell'installazione. L'esecuzione dello strumento deve essere il primo passaggio per la diagnosi di un problema.

Usare lo strumento di risoluzione dei problemi

Per eseguire lo strumento di risoluzione dei problemi, incollare il comando seguente in una finestra del terminale in un computer con l'agente di Log Analytics:

sudo /opt/microsoft/omsagent/bin/troubleshooter

Installazione manuale

Lo strumento di risoluzione dei problemi viene incluso automaticamente quando viene installato l'agente di Log Analytics. Se l'installazione non riesce in alcun modo, è anche possibile installare lo strumento manualmente:

  1. Assicurarsi che il debugger del progetto GNU (GDB) sia installato nel computer perché lo strumento di risoluzione dei problemi si basa su di esso.
  2. Copiare il bundle dello strumento di risoluzione dei problemi nel computer: wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
  3. Decomprimere il bundle: tar -xzvf omsagent_tst.tar.gz
  4. Eseguire l'installazione manuale: sudo ./install_tst

Scenari possibili

Lo strumento di risoluzione dei problemi controlla gli scenari seguenti:

  • L'agente non è integro; l'heartbeat non funziona correttamente.
  • L'agente non viene avviato o non riesce a connettersi a Log Analytics.
  • L'agente Syslog non funziona.
  • L'agente ha un utilizzo elevato della CPU o della memoria.
  • L'agente presenta problemi di installazione.
  • I log personalizzati dell'agente non funzionano.
  • Non è possibile raccogliere i log dell'agente.

Per altre informazioni, vedere la documentazione dello strumento di risoluzione dei problemi in GitHub.

Nota

Eseguire lo strumento Agente di raccolta log quando si verifica un problema. La presenza dei log inizialmente aiuterà il team di supporto a risolvere il problema più velocemente.

Ripulire e reinstallare l'agente Linux

Una reinstallazione pulita dell'agente risolve la maggior parte dei problemi. Questa attività potrebbe essere il primo suggerimento del team di supporto per ottenere l'agente in uno stato non corretto. L'esecuzione dello strumento di risoluzione dei problemi e dello strumento di raccolta log e il tentativo di una reinstallazione pulita consentono di risolvere i problemi più rapidamente.

  1. Scaricare lo script di eliminazione:

    $ wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/purge_omsagent.sh

  2. Eseguire lo script di eliminazione (con autorizzazioni sudo):

    $ sudo sh purge_omsagent.sh

Percorsi di log importanti e lo strumento di raccolta log

file Percorso
File di log dell'agente di Log Analytics per Linux /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log
File di log di configurazione dell'agente di Log Analytics /var/opt/microsoft/omsconfig/omsconfig.log

È consigliabile usare lo strumento Agente di raccolta log per recuperare log importanti per la risoluzione dei problemi o prima di inviare un problema di GitHub. Per altre informazioni sullo strumento e su come eseguirlo, vedere Agente di raccolta log dell'agente Linux di OMS.

File di configurazione importanti

Categoria Percorso del file
Syslog /etc/syslog-ng/syslog-ng.conf o /etc/rsyslog.conf o /etc/rsyslog.d/95-omsagent.conf
Output e agente generale di Performance, Nagios, Zabbix e Log Analytics /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
Configurazioni aggiuntive /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/*.conf

Nota

La modifica dei file di configurazione per i contatori delle prestazioni e Syslog viene sovrascritta se la raccolta è configurata dalla configurazione dell'agente nella portale di Azure per l'area di lavoro. Per disabilitare la configurazione per tutti gli agenti, disabilitare la raccolta dalla gestione degli agenti legacy. Per un singolo agente, eseguire lo script seguente:

sudo /opt/microsoft/omsconfig/Scripts/OMS_MetaConfigHelper.py --disable && sudo rm /etc/opt/omi/conf/omsconfig/configuration/Current.mof* /etc/opt/omi/conf/omsconfig/configuration/Pending.mof*

Codici di errore di installazione

Codice errore Significato
NOT_DEFINED Poiché le dipendenze necessarie non sono installate, il plug-in di controllo auoms non verrà installato. L'installazione di auoms non è riuscita. Installare il pacchetto controllato.
2 È stata specificata un'opzione non valida per l'aggregazione della shell. Eseguire sudo sh ./omsagent-*.universal*.sh --help per l'utilizzo.
3 Non è stata specificata alcuna opzione per l'aggregazione della shell. Eseguire sudo sh ./omsagent-*.universal*.sh --help per l'utilizzo.
4 Tipo di pacchetto non valido o impostazioni proxy non valide. I pacchetti omsagent-rpm.sh possono essere installati solo nei sistemi basati su RPM. I pacchetti omsagent-deb.sh possono essere installati solo nei sistemi basati su Debian. È consigliabile usare il programma di installazione universale dalla versione più recente. Consultare questa sezione anche per verificare le impostazioni del proxy.
5 Il bundle della shell deve essere eseguito come radice o si è verificato un errore 403 restituito durante l'onboarding. Eseguire il comando usando sudo.
6 Architettura del pacchetto non valida o errore 200 restituito durante l'onboarding. I pacchetti omsagent-*x64.sh possono essere installati solo nei sistemi a 64 bit. I pacchetti omsagent-*x86.sh possono essere installati solo nei sistemi a 32 bit. Scaricare il pacchetto corretto per l'architettura dalla versione più recente.
17 L'installazione del pacchetto OMS non è riuscita. Esaminare l'output del comando per trovare la causa radice dell'errore.
18 L'installazione del pacchetto OMSConfig non è riuscita. Esaminare l'output del comando per trovare la causa radice dell'errore.
19 L'installazione del pacchetto OMI non è riuscita. Esaminare l'output del comando per trovare la causa radice dell'errore.
20 L'installazione del pacchetto SCX non è riuscita. Esaminare l'output del comando per trovare la causa radice dell'errore.
21 L'installazione dei kit del provider non è riuscita. Esaminare l'output del comando per trovare la causa radice dell'errore.
22 L'installazione del pacchetto di aggregazione non è riuscita. Esaminare l'output del comando per trovare la causa radice dell'errore.
23 Il pacchetto SCX o OMI è già installato. Usare --upgrade invece di --install per installare l'aggregazione della shell.
30 Si è verificato un errore interno dell'aggregazione. Segnalare un problema di GitHub con i dettagli dell'output.
55 La versione di openssl non supportata o non può connettersi a Monitoraggio di Azure o dpkg è bloccata o manca il programma curl.
61 La libreria ctypes Python non è installata. Installare la libreria o il pacchetto ctypes Python (python-ctypes).
62 Programma tar mancante. Installare tar.
63 Programma sed mancante. Installare sed.
64 Programma curl mancante. Installare curl.
65 Programma Gpg mancante. Installare gpg.

Codici di errore di onboarding

Codice errore Significato
2 È stata specificata un'opzione non valida per lo script omsadmin. Eseguire sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h per l'utilizzo.
3 È stata specificata una configurazione non valida per lo script omsadmin. Eseguire sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h per l'utilizzo.
4 È stato specificato un proxy non valido per lo script omsadmin. Verificare il proxy e vedere la documentazione per l'uso di un proxy HTTP.
5 Errore HTTP 403 ricevuto da Monitoraggio di Azure. Vedere l'output completo dello script omsadmin per informazioni dettagliate.
6 Errore HTTP non 200 ricevuto da Monitoraggio di Azure. Vedere l'output completo dello script omsadmin per informazioni dettagliate.
7 Non è possibile connettersi a Monitoraggio di Azure. Vedere l'output completo dello script omsadmin per informazioni dettagliate.
8 Si è verificato un errore durante l'onboarding all'area di lavoro Log Analytics. Vedere l'output completo dello script omsadmin per informazioni dettagliate.
30 Si è verificato un errore interno di script. Segnalare un problema di GitHub con i dettagli dell'output.
31 Si è verificato un errore durante la generazione dell'ID agente. Segnalare un problema di GitHub con i dettagli dell'output.
32 Si è verificato un errore durante la generazione dei certificati. Vedere l'output completo dello script omsadmin per informazioni dettagliate.
33 Errore durante la generazione della metaconfigurazione per omsconfig. Segnalare un problema di GitHub con i dettagli dell'output.
34 Lo script di generazione della metaconfigurazione non è presente. Ripetere il tentativo di onboarding con sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key>.

Abilitazione della registrazione di debug

Debug del plug-in di output oms

FluentD consente livelli di registrazione specifici del plug-in che consentono di specificare livelli di log diversi per input e output. Per specificare un livello di log diverso per l'output di OMS, modificare la configurazione generale dell'agente in /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

Nel plug-in di output oms, prima della fine del file di configurazione, modificare la log_level proprietà da info a debug:

<match oms.** docker.**>
  type out_oms
  log_level debug
  num_threads 5
  buffer_chunk_limit 5m
  buffer_type file
  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
  buffer_queue_limit 10
  flush_interval 20s
  retry_limit 10
  retry_wait 30s
</match>

La registrazione di debug consente di visualizzare i caricamenti in batch in Monitoraggio di Azure separati da tipo, numero di elementi di dati e tempo impiegato per l'invio.

Ecco un esempio di log abilitato per il debug:

Success sending oms.nagios x 1 in 0.14s
Success sending oms.omi x 4 in 0.52s
Success sending oms.syslog.authpriv.info x 1 in 0.91s

Output dettagliato

Invece di usare il plug-in di output OMS, è possibile inviare gli elementi di dati direttamente a stdout, che è visibile nel file di log dell'agente di Log Analytics per Linux.

Nel file di configurazione dell'agente generale di Log Analytics in /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.confimpostare come commento il plug-in di output oms aggiungendo un elemento # davanti a ogni riga:

#<match oms.** docker.**>
#  type out_oms
#  log_level info
#  num_threads 5
#  buffer_chunk_limit 5m
#  buffer_type file
#  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
#  buffer_queue_limit 10
#  flush_interval 20s
#  retry_limit 10
#  retry_wait 30s
#</match>

Sotto il plug-in di output rimuovere il commento dalla sezione seguente rimuovendo l'oggetto # davanti a ogni riga:

<match **>
  type stdout
</match>

Problema: Non è possibile connettersi tramite proxy a Monitoraggio di Azure

Possibili cause

  • Il proxy specificato durante l'onboarding non è corretto.
  • Gli endpoint di servizio di Monitoraggio di Azure e Automazione di Azure non sono inclusi nell'elenco approvato nel data center.

Risoluzione

  1. Eseguire nuovamente l'onboarding in Monitoraggio di Azure con l'agente di Log Analytics per Linux usando il comando seguente con l'opzione -v abilitata. Consente l'output dettagliato dell'agente che si connette tramite il proxy a Monitoraggio di Azure: /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

  2. Esaminare la sezione Aggiornare le impostazioni proxy per verificare di aver configurato correttamente l'agente per comunicare tramite un server proxy.

  3. Verificare che gli endpoint descritti nell'elenco dei requisiti del firewall di rete di Monitoraggio di Azure vengano aggiunti correttamente a un elenco di elementi consentiti. Se si usa Automazione di Azure, i passaggi di configurazione di rete necessari sono collegati anche in precedenza.

Problema: Viene visualizzato un errore 403 durante il tentativo di onboarding

Possibili cause

  • La data e l'ora non sono corrette nel server Linux.
  • L'ID dell'area di lavoro e la chiave dell'area di lavoro non sono corretti.

Risoluzione

  1. Controllare l'ora nel server Linux con il comando date. Se l'ora è +/- 15 minuti dall'ora corrente, l'onboarding ha esito negativo. Per risolvere questa situazione, aggiornare la data e/o il fuso orario del server Linux.
  2. Verificare di aver installato la versione più recente dell'agente di Log Analytics per Linux. Ora la versione più recente invia una notifica all'utente se la differenza di tempo causa l'errore di onboarding.
  3. Eseguire di nuovo l'onboarding usando l'ID e la chiave dell'area di lavoro corretti nelle istruzioni di installazione riportate in precedenza in questo articolo.

Problema: Viene visualizzato un errore 404 o 500 nel file di log subito dopo l'onboarding

Si tratta di un problema noto che si verifica al primo caricamento di dati Linux in un'area di lavoro Log Analytics. Questo problema non influisce sui dati inviati o sull'esperienza del servizio.

Problema: Viene visualizzato omiagent con CPU al 100%

Possibili cause

Una regressione nel pacchetto nss-pem v1.0.3-5.el7 ha causato un grave problema di prestazioni. Questo problema è stato riscontrato molto nelle distribuzioni Redhat/CentOS 7.x. Per altre informazioni su questo problema, vedere regressione delle prestazioni 1667121 in libcurl.

I bug correlati alle prestazioni non si verificano sempre e sono difficili da riprodurre. Se si verifica un problema di questo tipo con omiagent, usare lo script omiHighCPUDiagnostics.sh, che raccoglierà l'analisi dello stack dell'omiagent quando supera una determinata soglia.

  1. Scaricare lo script:
    wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh

  2. Eseguire la diagnostica per 24 ore con soglia cpu del 30%:
    bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

  3. Callstack verrà sottoposto a dump nel file omiagent_trace. Se si notano molte chiamate di funzione curl e NSS, seguire questa procedura di risoluzione.

Risoluzione

  1. Aggiornare il pacchetto nss-pem alla versione 1.0.3-5.el7_6.1:
    sudo yum upgrade nss-pem

  2. Se nss-pem non è disponibile per l'aggiornamento, che si verifica principalmente in CentOS, effettuare il downgrade di curl a 7.29.0-46. Se si esegue "yum update" per errore, curl verrà aggiornato alla versione 7.29.0-51 e il problema si verificherà di nuovo:
    sudo yum downgrade curl libcurl

  3. Riavviare OMI:
    sudo scxadmin -restart

Problema: I messaggi di Syslog inoltrati non vengono visualizzati

Possibili cause

  • La configurazione applicata al server Linux non consente la raccolta di strutture o livelli di log inviati.
  • Syslog non viene inoltrato correttamente al server Linux.
  • Il numero di messaggi inoltrati al secondo è troppo elevato per la configurazione di base dell'agente di Log Analytics per Linux da gestire.

Risoluzione

  • Verificare che la configurazione nell'area di lavoro Log Analytics per Syslog disponga di tutte le strutture e dei livelli di log corretti. Esaminare configurare la raccolta Syslog nel portale di Azure.
  • Verificare che i daemon di messaggistica Syslog nativi (rsyslog, syslog-ng) possano ricevere i messaggi inoltrati.
  • Controllare le impostazioni del firewall nel server Syslog per assicurarsi che i messaggi non vengano bloccati.
  • Simulare un messaggio Syslog in Log Analytics usando un logger comando:
    logger -p local0.err "This is my test message"

Problema: Viene restituito un messaggio di errore per segnalare che l'indirizzo è già in uso nel file di log omsagent

Viene visualizzato [error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use - bind(2) for "127.0.0.1" port 25224> in omsagent.log.

Possibili cause

Questo errore indica che l'estensione di diagnostica Linux (LAD) è installata side-by-side con l'estensione vm Linux di Log Analytics. Usa la stessa porta per la raccolta di dati Syslog di omsagent.

Risoluzione

  1. Come radice, eseguire i comandi seguenti. Si noti che 25224 è un esempio ed è possibile che nell'ambiente venga visualizzato un numero di porta diverso usato da LAD.

    /opt/microsoft/omsagent/bin/configure_syslog.sh configure LAD 25229

sed -i -e 's/25224/25229/' /etc/opt/microsoft/omsagent/LAD/conf/omsagent.d/syslog.conf

    È quindi necessario modificare il file di configurazione rsyslogd o syslog_ng corretto e cambiare la configurazione relativa a LAD in modo da scrivere sulla porta 25229.

  2. Se la macchina virtuale è in esecuzione rsyslogd, il file da modificare è /etc/rsyslog.d/95-omsagent.conf (se esistente, altrimenti /etc/rsyslog). Se la macchina virtuale è in esecuzione syslog_ng, il file da modificare è /etc/syslog-ng/syslog-ng.conf.

  3. Riavviare omsagent con sudo /opt/microsoft/omsagent/bin/service_control restart.

  4. Riavviare il servizio Syslog.

Problema: non è possibile disinstallare omsagent usando l'opzione ripulitura

Possibili cause

  • L'estensione di diagnostica Linux è installata.
  • L'estensione di diagnostica Linux è stata installata e disinstallata, ma viene comunque visualizzato un errore relativo all'uso di omsagent da mdsd e non può essere rimosso.

Risoluzione

  1. Disinstallare l'estensione di diagnostica Linux.
  2. Rimuovere i file di estensione di diagnostica Linux dal computer se sono presenti nel percorso seguente: /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ e /var/opt/microsoft/omsagent/LAD/.

Problema: non è possibile visualizzare dati Nagios

Possibili cause

  • L'utente omsagent non dispone delle autorizzazioni per la lettura dal file di log Nagios.
  • L'origine e il filtro Nagios non sono stati commentati dal file omsagent.conf.

Risoluzione

  1. Aggiungere l'utente omsagent per leggere dal file Nagios seguendo queste istruzioni.

  2. Nel file di configurazione generale dell'agente di Log Analytics per Linux in /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf, verificare che per entrambe le impostazioni dell'origine e del filtro di Nagios sia stato rimosso il commento.

    <source>
  type tail
  path /var/log/nagios/nagios.log
  format none
  tag oms.nagios
</source>

<filter oms.nagios>
  type filter_nagios_log
</filter>

Problema: non vengono visualizzati dati Linux

Possibili cause

  • L'onboarding in Monitoraggio di Azure non è riuscito.
  • Connessione ion a Monitoraggio di Azure è bloccato.
  • La macchina virtuale è stata riavviata.
  • Il pacchetto OMI è stato aggiornato manualmente a una versione più recente rispetto a quella installata dall'agente di Log Analytics per linux.
  • OMI è bloccato, bloccando l'agente OMS.
  • Classe log risorse DSC non trovata nel omsconfig.log file di log.
  • Viene eseguito il backup dell'agente di Log Analytics per i dati.
  • Log DSC La configurazione corrente non esiste. Eseguire il comando Start-DscConfiguration con il parametro -Path per specificare un file di configurazione e creare prima una configurazione corrente. nel omsconfig.log file di log, ma non esiste alcun messaggio di log sulle PerformRequiredConfigurationChecks operazioni.

Risoluzione

  1. Installare tutte le dipendenze, ad esempio il pacchetto controllato.

  2. Controllare se l'onboarding in Monitoraggio di Azure è riuscito controllando se il file seguente esiste: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. In caso contrario, eseguire di nuovo il tabellone usando le istruzioni della riga di comando omsadmin.sh.

  3. Se si usa un proxy, controllare i passaggi precedenti per la risoluzione dei problemi del proxy.

  4. In alcuni sistemi di distribuzione di Azure, il daemon del server OMI omid non viene avviato dopo il riavvio della macchina virtuale. In questo caso, non verranno visualizzati i dati correlati alla soluzione Audit, ChangeTracking o UpdateManagement. La soluzione alternativa consiste nell'avviare manualmente il server OMI eseguendo sudo /opt/omi/bin/service_control restart.

  5. Dopo che il pacchetto OMI viene aggiornato manualmente a una versione più recente, è necessario riavviarlo manualmente affinché l'agente di Log Analytics continui a funzionare. Questo passaggio è necessario per alcune distribuzioni in cui il server OMI non viene avviato automaticamente dopo l'aggiornamento. Eseguire sudo /opt/omi/bin/service_control restart per riavviare l'OMI.

    In alcune situazioni, l'OMI può diventare bloccato. L'agente OMS potrebbe entrare in uno stato bloccato in attesa dell'OMI, che blocca tutta la raccolta di dati. Il processo dell'agente OMS verrà eseguito, ma non ci sarà alcuna attività, che viene evidenziata da nessuna nuova riga di log (ad esempio heartbeat inviati) presente in omsagent.log. Riavviare l'OMI con sudo /opt/omi/bin/service_control restart per ripristinare l'agente.

  6. Se viene visualizzato un errore di classe di risorse DSC non trovato in omsconfig.log, eseguire sudo /opt/omi/bin/service_control restart.

  7. In alcuni casi, quando l'agente di Log Analytics per Linux non riesce a comunicare con Monitoraggio di Azure, viene eseguito il backup dei dati nell'agente fino alle dimensioni del buffer completo di 50 MB. L'agente deve essere riavviato tramite il comando seguente: /opt/microsoft/omsagent/bin/service_control restart.

    Nota

    Questo problema è stato risolto nella versione 1.1.0-28 o successiva dell'agente.

    • Se il omsconfig.log file di log non indica che PerformRequiredConfigurationChecks le operazioni vengono eseguite periodicamente nel sistema, potrebbe verificarsi un problema con il processo/servizio cron. Verificare che il processo cron esista in /etc/cron.d/OMSConsistencyInvoker. Se necessario, eseguire i comandi seguenti per creare il processo cron:

      mkdir -p /etc/cron.d/
echo "*/15 * * * * omsagent /opt/omi/bin/OMSConsistencyInvoker >/dev/null 2>&1" | sudo tee /etc/cron.d/OMSConsistencyInvoker

    • Verificare inoltre che il servizio cron sia in esecuzione. È possibile usare service cron status con Debian, Ubuntu e SU edizione Standard o service crond status con RHEL, CentOS e Oracle Linux per controllare lo stato di questo servizio. Se il servizio non esiste, è possibile installare i file binari e avviare il servizio usando le istruzioni seguenti:

      Ubuntu/Debian

      # To Install the service binaries
sudo apt-get install -y cron
# To start the service
sudo service cron start

      SUSE

      # To Install the service binaries
sudo zypper in cron -y
# To start the service
sudo systemctl enable cron
sudo systemctl start cron

      RHEL/CentOS

      # To Install the service binaries
sudo yum install -y crond
# To start the service
sudo service crond start

      Oracle Linux

      # To Install the service binaries
sudo yum install -y cronie
# To start the service
sudo service crond start

Problema: quando si configura la raccolta dal portale per i contatori delle prestazioni Syslog o Linux, le impostazioni non vengono applicate

Possibili cause

  • L'agente di Log Analytics per Linux non ha selezionato la configurazione più recente.
  • Le impostazioni modificate nel portale non sono state applicate.

Risoluzione

Contesto:omsconfig è l'agente di configurazione dell'agente di Log Analytics per Linux che verifica la presenza di una nuova configurazione sul lato portale ogni cinque minuti. Questa configurazione viene quindi applicata al file di configurazione dell'agente di Log Analytics per Linux che si trova in /etc/OPT/Microsoft/omsagent/conf/omsagent.conf.

In alcuni casi, l'agente di configurazione di Log Analytics per Linux potrebbe non essere in grado di comunicare con il servizio di configurazione del portale. Questo scenario comporta la mancata applicazione della configurazione più recente.

  1. Verificare che l'agente omsconfig sia installato eseguendo dpkg --list omsconfig o rpm -qi omsconfig. Se non è installato, reinstallare la versione più recente dell'agente di Log Analytics per Linux.

  2. Verificare che l'agente omsconfig possa comunicare con Monitoraggio di Azure eseguendo il comando seguente: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Questo comando restituisce la configurazione ricevuta dall'agente dal servizio, incluse le impostazioni syslog, i contatori delle prestazioni di Linux e i log personalizzati. Se questo comando non riesce, eseguire il comando seguente: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Questo comando forza l'agente omsconfig a comunicare con Monitoraggio di Azure e recuperare la configurazione più recente.

Problema: non vengono visualizzati dati di log personalizzati

Possibili cause

  • L'onboarding in Monitoraggio di Azure non è riuscito.
  • L'impostazione Applica la configurazione seguente ai server Linux non è stata selezionata.
  • omsconfig non ha prelevato la configurazione del log personalizzata più recente dal servizio.
  • L'agente omsagent di Log Analytics per Linux non è in grado di accedere al log personalizzato a causa delle autorizzazioni o non è stato trovato. Potrebbero essere visualizzati gli errori seguenti:
    • [DATETIME] [warn]: file not found. Continuing without tailing it.
    • [DATETIME] [error]: file not accessible by omsagent.
  • Problema noto con race condition risolto nell'agente di Log Analytics per Linux versione 1.1.0-217.

Risoluzione

  1. Verificare che l'onboarding in Monitoraggio di Azure sia riuscito controllando se il file seguente esiste: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Se non è presente, eseguire una di queste operazioni:

    1. Eseguire di nuovo l'onboarding usando le istruzioni della riga di comando omsadmin.sh.
    2. In Impostazioni avanzate nel portale di Azure verificare che l'impostazione Apply the following configuration to my Linux Servers (Applica la configurazione seguente ai server Linux) sia abilitata.

  2. Verificare che l'agente omsconfig possa comunicare con Monitoraggio di Azure eseguendo il comando seguente: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Questo comando restituisce la configurazione ricevuta dall'agente dal servizio, incluse le impostazioni syslog, i contatori delle prestazioni di Linux e i log personalizzati. Se questo comando non riesce, eseguire il comando seguente: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Questo comando forza l'agente omsconfig a comunicare con Monitoraggio di Azure e recuperare la configurazione più recente.

Contesto: invece di essere eseguito come utente con privilegi, root, l'agente di Log Analytics per Linux viene eseguito come utente omsagent. Nella maggior parte dei casi, è necessario concedere all'utente l'autorizzazione esplicita per la lettura di determinati file. Per concedere l'autorizzazione all'utente omsagent, eseguire i comandi seguenti:

  1. Aggiungere l'utente omsagent al gruppo specifico: sudo usermod -a -G <GROUPNAME> <USERNAME>.
  2. Concedere l'accesso in lettura universale al file richiesto: sudo chmod -R ugo+rx <FILE DIRECTORY>.

Si è verificato un problema noto con una race condition con l'agente di Log Analytics per Linux versione precedente alla versione 1.1.0-217. Dopo aver eseguito l'aggiornamento all'agente più recente, eseguire il comando seguente per ottenere la versione più recente del plug-in di output: sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

Problema: si sta provando a eseguire di nuovo l'onboarding in una nuova area di lavoro

Quando si prova a eseguire nuovamente l'onboarding a una nuova area di lavoro, è necessario prima pulire la configurazione dell'agente di Log Analytics. Per pulire la configurazione precedente dall'agente, eseguire il bundle della shell con --purge:

sudo sh ./omsagent-*.universal.x64.sh --purge

O

sudo sh ./onboard_agent.sh --purge

Dopo aver usato l'opzione, è possibile continuare a eseguire di nuovo il --purge tabellone.

Problema: l'estensione dell'agente di Log Analytics nel portale di Azure è contrassegnata con uno stato di errore: Provisioning non riuscito

Possibili cause

  • L'agente di Log Analytics è stato rimosso dal sistema operativo.
  • Il servizio agente di Log Analytics è inattivo, disabilitato o non configurato.

Risoluzione

  1. Rimuovere l'estensione dal portale di Azure.
  2. Installare l'agente seguendo le istruzioni.
  3. Riavviare l'agente eseguendo il comando seguente:
    sudo /opt/microsoft/omsagent/bin/service_control restart.
  4. Attendere alcuni minuti fino a quando lo stato di provisioning non viene modificato in Provisioning completato.

Problema: L'agente di Log Analytics viene aggiornato su richiesta

Possibili cause

I pacchetti dell'agente di Log Analytics nell'host non sono aggiornati.

Risoluzione

  1. Verificare la versione più recente in questa pagina di GitHub.

  2. Scaricare lo script di installazione (1.4.2-124 è una versione di esempio):

    wget https://github.com/Microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_GA_v1.4.2-124/omsagent-1.4.2-124.universal.x64.sh

  3. Aggiornare i pacchetti eseguendo sudo sh ./omsagent-*.universal.x64.sh --upgrade.

Problema: l'installazione non riesce e indica che Python2 non può supportare i ctype, anche se viene usato Python3

Possibili cause

Per questo problema noto, se la lingua della macchina virtuale non è inglese, un controllo avrà esito negativo quando si verifica quale versione di Python viene usata. Questo problema porta all'agente sempre supponendo che Python2 venga usato e non riesca se non è presente Python2.

Risoluzione

Modificare la lingua ambientale della macchina virtuale in inglese:

export LANG=en_US.UTF-8