Condividi tramite

Risolvere i problemi relativi all'agente Log Analytics per Linux

Questo articolo fornisce aiuto nella risoluzione dei problemi che potresti incontrare con l'agente di Log Analytics per Linux in Azure Monitor.

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione di Linux che ha raggiunto lo stato di fine del servizio (EOL). Si prega di valutare il proprio utilizzo 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.

Utilizzare lo strumento per la risoluzione dei problemi:

Per eseguire lo strumento di risoluzione dei problemi, incollare il comando seguente in una finestra del terminale in un computer dove è presente 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, è possibile installare lo strumento anche manualmente:

  1. Assicurarsi che nel computer sia installato lo GNU Project Debugger (GDB), in quanto lo strumento di risoluzione dei problemi è basato su tale funzionalità.
  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. Procedere all’apertura della scatola: tar -xzvf omsagent_tst.tar.gz
  4. Eseguire l’installazione manuale: sudo ./install_tst

Scenari coperti

Lo strumento di risoluzione dei problemi verifica gli scenari seguenti:

  • L'agente non è in salute; il battito cardiaco non funziona correttamente.
  • L'agente non viene avviato o non è in grado di connettersi a Log Analytics.
  • Il Syslog dell'agente non funziona.
  • Utilizzo elevato della CPU o della memoria da parte dell'agente
  • 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 per la risoluzione dei problemi su GitHub.

Nota

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

Rimuovere e reinstallare l'agente Linux

Una reinstallazione pulita dell'agente risolve la maggior parte dei problemi. Questo potrebbe essere il primo suggerimento fornito dal team di supporto per riportare l'agente in uno stato non corrotto. L'esecuzione dello strumento di risoluzione dei problemi e dello strumento di raccolta dei log e il tentativo di una reinstallazione consentono di risolvere i problemi più rapidamente.

  1. Scaricare lo script di rimozione:

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

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

    $ sudo sh purge_omsagent.sh

Percorsi di log importanti e Agente di raccolta log

Documento 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 l'Agente di raccolta log per recuperare i log importanti per la risoluzione dei problemi o prima di segnalare un problema in GitHub. Per altre informazioni sullo strumento e su come eseguirlo, vedere Raccoglitore di log per agenti Linux 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 extra /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 viene configurata dall’agente di configurazione nel portale di Azure per l'area di lavoro. Per disabilitare la configurazione di tutti gli agenti, disabilitare la raccolta da 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
NON_DEFINITO Poiché non sono installate le dipendenze necessarie, il plug-in auditd per auoms non viene installato. Installazione di auoms non riuscita. Installare il pacchetto auditd.
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 della versione più recente. Consultare questa sezione anche per verificare le impostazioni del proxy.
5 Il pacchetto shell deve essere eseguito come root oppure verrà restituito l'errore 403 durante l'onboarding. Eseguire il comando usando sudo.
6 Architettura del pacchetto non valida oppure si è verificato un errore 200 durante la procedura di integrazione. 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 integrato non è riuscita. Esaminare l'output del comando per trovare la causa radice dell'errore.
23 Il pacchetto SCX o OMI è già installato. Utilizzare --upgrade invece di --install per installare il pacchetto della shell.
30 Si è verificato un errore interno dell'aggregazione. Segnalare il problema in GitHub con i dettagli dell'output.
55 La versione di openssl non è supportata o non è possibile connettersi Monitoraggio di Azure o dpkg è bloccato o il programma curl non è installato.
61 La libreria Python ctypes è mancante. 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. Controllare il proxy e consultare la documentazione sull'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 ad Azure Monitor. 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 il problema in GitHub con i dettagli dell'output.
31 Si è verificato un errore durante la generazione dell'ID agente. Segnalare il problema in 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 il problema in GitHub con i dettagli dell'output.
34 Lo script di generazione della metaconfigurazione non è presente. Ripeti il processo 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 dell'output di OMS

FluentD consente livelli di registrazione specifici per il plug-in che consentono di specificare livelli di log diversi per l'input e l'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 dell'output di OMS, prima della fine del file di configurazione, modificare la proprietà log_level 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 a Azure Monitor separati per 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

Anziché usare il plug-in dell'output di OMS, è possibile inviare elementi di dati di output 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.conf, impostare come commento il plug-in dell'output di OMS aggiungendo il carattere # all'inizio di 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>

Al di sotto del plug-in dell'output, rimuovere il carattere di commento # all'inizio di ogni riga nella sezione seguente:

<match **>
  type stdout
</match>

Problema: Impossibile connettersi tramite proxy ad Azure Monitor

Possibili cause

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

Risoluzione

  1. Eseguire di nuovo l'onboarding a Monitoraggio di Azure con l'agente di Log Analytics per Linux usando il comando seguente con l'opzione -v abilitata. In questo modo l'output dettagliato dell'agente può connettersi tramite proxy a Monitoraggio di Azure: /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

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

  3. Controllare che gli endpoint descritti nei requisiti del firewall di rete di Azure Monitor siano aggiunti correttamente a una lista di autorizzazioni. Se si usa Automazione di Azure, i passaggi necessari di configurazione di rete sono anche collegati sopra.

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

Possibili cause

  • Data e ora non sono corrette nel server Linux.
  • L'ID 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 è sfasata di +/- 15 minuti rispetto all'ora corrente, l'onboarding ha esito negativo. Per risolvere il problema, aggiornare la data e/o il fuso orario del server Linux.
  2. Verificare di avere 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 valori corretti per ID e chiave dell'area di lavoro secondo le istruzioni di installazione illustrate 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 durante il primo caricamento dei dati di Linux in un'area di lavoro Log Analytics. Tale problematica non influisce sui dati inviati o sull'esperienza d'uso 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 al superamento di 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 a v1.0.3-5.el7_6.1:
    sudo yum upgrade nss-pem

  2. Se nss-pem non è aggiornabile, cosa che si verifica principalmente in CentOS, effettuare il downgrade di curl alla versione 7.29.0-46. Se si esegue "aggiornamento yum " 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 delle strutture o dei livelli di log inviati.
  • Syslog non viene inoltrato correttamente al server Linux.
  • Il numero di messaggi inoltrati al secondo è troppo elevato e pertanto la configurazione di base dell'agente di Log Analytics per Linux non può gestirli.

Risoluzione

  • Verificare che la configurazione nell'area di lavoro Log Analytics per Syslog disponga di tutte le strutture e dei livelli di log corretti. Rivedere Configurare Syslog nel portale di Azure.
  • Verificare che i daemon di messaggistica syslog nativi (rsyslog, syslog-ng) siano in grado di ricevere i messaggi inoltrati.
  • Controllare le impostazioni del firewall sul server Syslog per verificare che i messaggi non vengano bloccati.
  • Simulare un messaggio di Syslog a Log Analytics usando un comando logger:
    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 per Linux (LAD) è installata in modalità affiancata all'estensione della macchina virtuale Linux di Log Analytics. Usa la stessa porta usata da omsagent per la raccolta dei dati di Syslog.

Risoluzione

  1. Come utente root, eseguire i comandi seguenti. Si noti che 25224 è riportato a titolo di esempio ed è possibile che nell'ambiente in uso 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 esegue rsyslogd, il file da modificare è /etc/rsyslog.d/95-omsagent.conf, se presente, altrimenti /etc/rsyslog. Se la macchina virtuale esegue 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 purge

Possibili cause

  • L'estensione di diagnostica per Linux è installata.
  • L'estensione di diagnostica per Linux è stata installata e disinstallata, ma viene ancora visualizzato un errore per segnalare che omsagent è usato da mdsd e non può essere rimosso.

Risoluzione

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

Problema: non è possibile visualizzare i dati di Nagios

Possibili cause

  • L'utente omsagent non dispone delle autorizzazioni per leggere dai file di log di Nagios.
  • Per l'origine e il filtro di Nagios non è stato rimosso il commento dal file omsagent.conf.

Risoluzione

  1. Consenti all'utente omsagent di leggere dal file di 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: i dati di Linux non vengono visualizzati

Possibili cause

  • Onboarding in Monitoraggio di Azure non riuscito.
  • La connessione ad Azure Monitor è bloccata.
  • La macchina virtuale è stata riavviata.
  • Il pacchetto OMI è stato aggiornato manualmente a una versione più recente rispetto alla versione installata dal pacchetto dell'agente di Log Analytics per Linux.
  • OMI è bloccato, bloccando l'agente OMS.
  • La risorsa DSC registra un errore class not found (classe non trovata) nel file di log omsconfig.log.
  • I dati dell'agente di Log Analytics sono sottoposti a backup.
  • DSC registra l'errore 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 file di log omsconfig.log, ma non esiste alcun messaggio di log riguardo alle operazioni PerformRequiredConfigurationChecks.

Risoluzione

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

  2. Verificare se l'integrazione con Monitoraggio di Azure è stata completata con successo controllando se esiste il seguente file: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Se l'operazione non è riuscita, eseguire nuovamente l'onboarding usando le istruzioni della riga di comando omsadmin.sh.

  3. Se si usa un proxy, seguire 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, i dati correlati alla soluzione Audit, ChangeTracking o UpdateManagement non vengono visualizzati. Per risolvere questo problema è possibile avviare manualmente il server OMI eseguendo sudo /opt/omi/bin/service_control restart.

  5. Dopo che il pacchetto OMI è stato aggiornato manualmente a una versione più recente, è necessario riavviarlo manualmente in modo che l'agente di Log Analytics possa continuare a funzionare. Questo passaggio è obbligatorio 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ò bloccarsi. L'agente OMS potrebbe entrare in uno stato di blocco in attesa dell'OMI, che blocca tutta la raccolta di dati. Il processo dell'agente OMS verrà eseguito, ma non ci sarà alcuna attività, cosa che viene evidenziata dall’assenza di nuove righe di log (ad esempio heartbeat inviati) in omsagent.log. Riavvia l'OMI con sudo /opt/omi/bin/service_control restart per recuperare l'agente.

  6. Se in omsconfig.log viene riportato un errore class not found (classe non trovata) della risorsa DSC, eseguire sudo /opt/omi/bin/service_control restart.

  7. In alcuni casi, quando l'agente di Log Analytics per Linux non può comunicare con Monitoraggio di Azure, i dati dell'agente vengono sottoposti a backup fino a raggiungere la dimensione completa del buffer di 50 MB. L'agente deve essere riavviato tramite il comando seguente: /opt/microsoft/omsagent/bin/service_control restart.

    Nota

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

    • Se il file di log omsconfig.log non indica che le operazioni PerformRequiredConfigurationChecks vengono eseguite periodicamente nel sistema, può essere presente un problema relativo al processo/servizio cron. Verificare che il processo cron sia presente 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 SUSE o service crond status con RHEL, CentOS e Oracle Linux per verificare lo stato di questo servizio. Se il servizio non esiste, è possibile installare i file binari e avviare il servizio tramite le seguenti istruzioni:

      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 una raccolta dal portale per i contatori delle prestazioni di 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 sia in grado di comunicare con Monitoraggio di Azure tramite il comando seguente: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Questo comando restituisce la configurazione che l'agente recupera dal servizio, inclusi i contatori delle prestazioni di Linux, le impostazioni di Syslog 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 impone all'agente omsconfig di comunicare con Monitoraggio di Azure e recuperare la configurazione più recente.

Problema: I dati dei log personalizzati non vengono visualizzati

Possibili cause

  • Onboarding in Monitoraggio di Azure non riuscito.
  • L'impostazione Apply the following configuration to my Linux Servers (Applica la configurazione seguente ai server Linux) non è stata selezionata.
  • omsconfig non ha selezionato la configurazione più recente di log personalizzati dal servizio.
  • L'utente dell'agente di Log Analytics per Linux omsagent non riesce ad accedere al log personalizzato perché non dispone delle autorizzazioni necessarie o perché il file non viene trovato. È possibile visualizzare i seguenti errori:
    • [DATETIME] [warn]: file not found. Continuing without tailing it.
    • [DATETIME] [error]: file not accessible by omsagent.
  • Problema noto di race condition risolto nell'agente di Log Analytics per Linux versione 1.1.0-217.

Risoluzione

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

    1. Eseguire nuovamente 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 sia in grado di comunicare con Monitoraggio di Azure tramite il comando seguente: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Questo comando restituisce la configurazione che l'agente recupera dal servizio, inclusi i contatori delle prestazioni di Linux, le impostazioni di Syslog 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 impone all'agente omsconfig di comunicare con Monitoraggio di Azure e recuperare la configurazione più recente.

Contesto: invece di eseguire l'agente di Log Analytics per Linux come un utente con privilegi, root, l'agente viene eseguito come utente omsagent. Nella maggior parte dei casi, è necessario che all'utente venga concessa l'autorizzazione esplicita per la lettura di alcuni 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 universale in lettura al file richiesto: sudo chmod -R ugo+rx <FILE DIRECTORY>.

Un problema noto di race condition è stato risolto con l'agente di Log Analytics per Linux versione 1.1.0-217. Dopo 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 prova a eseguire nuovamente l'onboarding a una nuova area di lavoro

Quando si tenta di riaggiungere un agente a una nuova area di lavoro, è necessario ripulire la configurazione dell'agente di Log Analytics prima di procedere con il nuovo onboarding. Per pulire la vecchia configurazione dall'agente, eseguire il pacchetto della shell con --purge:

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

Oppure

sudo sh ./onboard_agent.sh --purge

È possibile continuare a effettuare l'onboarding dopo avere usato l'opzione --purge.

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 dell'agente di Log Analytics non è attivo, è disabilitato o non è configurato.

Risoluzione

  1. Rimuovere l'estensione dal portale di Azure.
  2. Installare l'agente seguendo queste 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 del provisioning cambia 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. Controllare la versione più recente nella pagina GitHub presente.

  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 nel caso di utiizzo di Python3

Possibili cause

Per questo problema noto, se la lingua della macchina virtuale non è l’inglese, un controllo avrà esito negativo allorché si verifica quale versione di Python è in uso. Questo problema porta l'agente a supporre sempre che venga usato Python2 e a non avere buon esito in assenza di Python2.

Risoluzione

Modificare la lingua ambientale della macchina virtuale in inglese:

export LANG=en_US.UTF-8
  • Last updated on