Condividi tramite

Risolvere i problemi relativi agli heartbeat mancanti negli agenti Linux

Questo articolo illustra come risolvere i problemi relativi agli heartbeat mancanti nell'agente di Microsoft Azure Log Analytics in un computer basato su Linux.

Note

Esistono molti motivi per cui gli heartbeat potrebbero sembrare mancanti dagli agenti Linux. Tuttavia, questo articolo illustra solo un campionamento degli scenari che causano il problema.

Prerequisiti

  • Una distribuzione e una versione linux supportate che non sono con protezione avanzata. Se non si conosce la distribuzione o la versione, eseguire il cat /etc/system-release comando in una shell per visualizzare queste informazioni.

  • Architettura della CPU x86 o x64.

  • Un agente di Log Analytics che non è multi-homed in più di un'area di lavoro. Per verificare lo stato multihoming dell'agente, eseguire lo script omsadmin.sh :

    sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -l

  • Firewall o proxy configurato per le risorse dell'agente seguenti:

    • *.ods.opinsights.azure.com
    • *.oms.opinsights.azure.com
    • *.blob.core.windows.net
    • *.azure-automation.net

    Assicurarsi che queste risorse usino la porta 443 nella direzione in uscita e che consentano il bypass dell'ispezione HTTPS. Per altre informazioni, vedere Requisiti di rete.

  • Agente di raccolta log dell'agente Linux di Operations Management Suite in esecuzione nel computer Linux. Operations Management Suite (OMS) è un altro nome per l'agente di Log Analytics per Linux.

    Se lo strumento Agente di raccolta log non funziona per il sistema operativo, raccogliere manualmente i log e i file di configurazione indicati in Percorsi di log importanti e strumento di raccolta log.

Sintomi

Quando si visualizza un'area di lavoro Log Analytics nella portale di Azure, gli heartbeat non vengono segnalati dall'agente di Log Analytics in una macchina virtuale Linux.

Causa 1: L'agente è configurato per segnalare a un'altra area di lavoro

Cosa accade se l'agente Linux richiama un ID area di lavoro (un GUID) diverso dall'ID dell'area di lavoro Log Analytics? In questo caso, l'agente è configurato per inviare heartbeat e dati a un'altra area di lavoro.

Per ottenere l'ID dell'area di lavoro usato dall'agente Linux, eseguire lo stesso script omsadmin.sh usato per verificare lo stato multihoming dell'agente:

sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -l

Per ottenere l'ID dell'area di lavoro in Azure, seguire questa procedura:

  1. Nella portale di Azure individuare e selezionare Aree di lavoro Log Analytics.

  2. Nell'elenco delle aree di lavoro Log Analytics selezionare l'area di lavoro a cui inviare i dati dell'agente.

  3. Nella pagina Panoramica dell'area di lavoro selezionata individuare il valore GUID elencato in ID area di lavoro. Questo valore è diverso dall'ID dell'area di lavoro visualizzato nell'output dello script di omsadmin.sh ? In caso affermativo, è stata individuata la causa del problema.

Soluzione: riconfigurare l'agente in modo che punti all'area di lavoro corretta

Modificare la configurazione dell'agente per usare l'ID dell'area di lavoro visualizzato nel portale di Azure. È necessario esaminare il motivo per cui l'agente è configurato per segnalare a un'area di lavoro diversa. Potrebbe esserci un motivo valido per l'invio di dati a un'area di lavoro diversa da quella dell'agente.

Causa 2: Il processo dell'agente non è stato avviato

Il processo dell'agente (omsagent) non è stato avviato correttamente, quindi non sono disponibili dati heartbeat.

Eseguire il comando seguente che usa gli ps strumenti e grep per elencare i processi attualmente in esecuzione:

ps -ef | grep -i oms | grep -v grep

Dopo aver trovato il ps comando, esaminare l'output del comando per il comando seguente omsagent (come una singola riga) chiamato all'interno di Ruby:

/opt/microsoft/omsagent/ruby/bin/ruby /opt/microsoft/omsagent/bin/omsagent \
  -d /var/opt/microsoft/omsagent/<workspace-id>/run/omsagent.pid \
  -o /var/opt/microsoft/omsagent/<workspace-id>/log/omsagent.log \
  -c /etc/opt/microsoft/omsagent/<workspace-id>/conf/omsagent.conf \
  --no-supervisor

Note

Il <segnaposto workspace-id> è un GUID.

Se non è possibile trovare questa chiamata al comando, significa che il processo dell'agente non è stato avviato.

Soluzione: avviare manualmente il processo dell'agente

In una shell Linux eseguire il comando seguente per avviare manualmente l'agente:

/opt/microsoft/omsagent/bin/service_control start

Dopo aver eseguito questo comando, verificare se l'output in omslinux.out contiene ora il testo previsto cercato in precedenza.

Causa 3: I problemi influiscono sull'installazione SSL della macchina virtuale

Potrebbe verificarsi un problema che influisce sulla connessione SECURE Sockets Layer (SSL) nella macchina virtuale. Per verificare la presenza di problemi SSL, seguire questa procedura:

  1. Eseguire il comando wget seguente per scaricare lo script di test Ruby nella macchina virtuale locale:

    wget https://raw.githubusercontent.com/ruby/openssl/master/test/openssl/test_ssl.rb

  2. Spostare lo script nella directory /tmp .

  3. Assicurarsi che l'utente omsagent possa accedere ai certificati CA radice.

  4. Eseguire lo script di test usando il comando seguente:

    sudo --user=omsagent /opt/microsoft/omsagent/ruby/bin/ruby /tmp/test_ssl.rb

Lo script di test determina se un problema influisce sulla connessione SSL della macchina virtuale.

Soluzione: correggere i certificati della CA e la connessione SSL

Assicurarsi che i certificati della CA radice SSL siano validi e che sia possibile che la macchina virtuale disponga di connessioni SSL.

Causa 4: l'agente genera heartbeat, ma non può trasmetterli all'area di lavoro

Il file omsagent.log mostra che l'agente genera heartbeat, ma non trasmette correttamente gli heartbeat all'area di lavoro Log Analytics. Per assicurarsi che gli heartbeat siano registrati in tale file, eseguire il comando seguente tail per visualizzare la fine del file di log:

tail omsagent.log

Nel file vengono visualizzate diverse voci di log che contengono la stringa seguente?

[info]: Invio di heartbeat OMS riuscito

Ad esempio, viene visualizzata una voce simile al testo seguente?

2022-03-19 05:18:52 +0000 [info]: Invio di heartbeat OMS riuscito al 2022-03-19T05:18:52.812Z

Una voce di questo tipo indica che l'agente genera heartbeat e invia correttamente questi heartbeat all'area di lavoro.

In alternativa, anziché una voce di questo tipo, vengono visualizzati messaggi informativi simili a "È stata rilevata un'eccezione riprovabile. Riprovare a inviare i dati in un secondo momento con messaggi di avviso come "failed to flush the buffer" o "suppressed same stacktrace"? Se l'output contiene tali messaggi, l'agente non invia i relativi heartbeat all'area di lavoro. Ad esempio, è possibile che venga visualizzata una voce simile al testo seguente:

Log degli errori di trasmissione

2019-04-02 19:27:43 -0500 [info]: Invio di heartbeat OMS riuscito a 2019-04-03T00:27:43.729Z

2019-04-02 19:28:43 -0500 [info]: Invio di heartbeat OMS riuscito a 2019-04-03T00:28:43.729Z

2019-04-02 19:29:31 -0500 [info]: Rilevata eccezione riprovabile. Riprova a inviare i dati in un secondo momento.

2019-04-02 19:29:31 -0500 [warn]: temporaneamente non è stato possibile scaricare il buffer. next_retry=2019-04-02 19:38:01 -0500 error_class="RuntimeError" error="Net::HTTP. Post genera un'eccezione: Net::OpenTimeout, 'execution expired'" plugin_id="object:2ab334e31fcc"

2019-04-02 19:29:31 -0500 [warn]: suppressed same stacktrace

2019-04-02 19:29:43 -0500 [info]: Invio di heartbeat OMS riuscito a 2019-04-03T00:29:43.730Z

2019-04-02 19:30:43 -0500 [info]: Invio di heartbeat OMS riuscito a 2019-04-03T00:30:43.731Z

2019-04-02 19:31:43 -0500 [info]: Invio di heartbeat OMS riuscito a 2019-04-03T00:31:43.731Z

2019-04-02 19:32:04 -0500 [info]: Rilevata eccezione riprovabile. Riprova a inviare i dati in un secondo momento.

2019-04-02 19:32:04 -0500 [warn]: temporaneamente non è stato possibile scaricare il buffer. next_retry=2019-04-02 19:36:34 -0500 error_class="RuntimeError" error="Net::HTTP. Post genera un'eccezione: Net::OpenTimeout, 'execution expired'" plugin_id="object:2ab3347a61e4"

2019-04-02 19:32:04 -0500 [warn]: suppressed same stacktrace

2019-04-02 19:32:43 -0500 [info]: Invio di heartbeat OMS riuscito a 2019-04-03T00:32:43.732Z

2019-04-02 19:33:43 -0500 [info]: Invio di heartbeat OMS riuscito a 2019-04-03T00:33:43.733Z

2019-04-02 19:34:43 -0500 [info]: Invio di heartbeat OMS riuscito a 2019-04-03T00:34:43.734Z

2019-04-02 19:35:43 -0500 [info]: Invio di heartbeat OMS riuscito a 2019-04-03T00:35:43.735Z

2019-04-02 19:36:43 -0500 [info]: Invio di heartbeat OMS riuscito al 2019-04-03T00:36:43.736Z

2019-04-02 19:37:04 -0500 [info]: Rilevata eccezione riprovabile. Riprova a inviare i dati in un secondo momento.

2019-04-02 19:37:04 -0500 [warn]: failed to flush the buffer. error_class="RuntimeError" error="Net::HTTP. Post genera un'eccezione: Net::OpenTimeout, 'execution expired'" plugin_id="object:2ab3347a61e4"

Se gli heartbeat non vengono trasmessi all'area di lavoro, eseguire lo strumento di risoluzione dei problemi Linux dell'agente di Log Analytics usando il comando seguente:

sudo /opt/microsoft/omsagent/bin/troubleshooter

Lo strumento di risoluzione dei problemi elenca un menu di scelte. Selezionare l'opzione 2 (Agent doesn't start, can't connect to Log Analytic Services). Lo strumento tenterà quindi di determinare la causa dell'errore.

Soluzione: ottenere assistenza dall'infrastruttura o dal team di rete per accedere agli endpoint necessari

Se lo strumento di risoluzione dei problemi restituisce eventuali errori che coinvolgono la connettività degli endpoint, vedere Requisiti di rete per l'agente di Log Analytics. L'URL necessario per poter inviare i dati heartbeat è <workspace-id.ods.opinsights.azure.com.> Se si verificano errori durante l'uso dell'URL, consultare l'infrastruttura o il team di rete per ripristinare l'accesso.

Causa 5: I problemi influiscono sull'inserimento in Log Analytics

Nell'area di lavoro Log Analytics la query Kusto seguente che cerca heartbeat Linux non restituisce risultati:

Heartbeat
| where OSType == "Linux"
| summarize arg_max(TimeGenerated, *) by Computer

Poiché nessun altro agente può inviare heartbeat, questa condizione indica problemi generali che influiscono sull'inserimento in Log Analytics.

Soluzione 1: Verificare la presenza di notifiche di interruzione

Verificare se l'agente presenta ritardi di latenza di inserimento. Se si rilevano ritardi di inserimento evidenti, controllare l'integrità del servizio di Azure per determinare se sono presenti notifiche di interruzione.

Soluzione 2: Attendere che il problema di inserimento venga cancellato nel servizio o nell'area di Azure

Il problema potrebbe essere causato da problemi di inserimento nel servizio di Azure o nell'area di Azure. Controllare lo stato dei servizi e delle aree di Azure. Se si verifica un problema, attendere che il servizio o l'area interessata torni all'integrità. Controllare quindi se gli heartbeat vengono segnalati all'area di lavoro.

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.