Risoluzione dei problemi dei log

Utilizzare le informazioni di risoluzione dei problemi per identificare e risolvere i problemi comuni che possono verificarsi durante l'utilizzo di Logging.

Risoluzione dei problemi relativi a General Unified Monitoring Agent

Requisiti hardware

A seconda dei requisiti di log e della configurazione (numero di log, tipo di buffering e così via), i requisiti hardware e le prestazioni dell'agente di monitoraggio unificato possono variare notevolmente. Quando non è presente alcuna pressione operativa (meno di 1.000 eventi di log al minuto), l'agente non deve consumare più di 200 MB di RAM e il 20% di un core CPU. I limiti non modificabili del servizio Unified Monitoring Agent sono 5 GB di RAM e il 40% di una memoria centrale. Si consigliano anche 1 GB di RAM.

Abilitazione del monitoraggio

Il monitoraggio può aiutare con la risoluzione dei problemi. Per ulteriori informazioni su come abilitare il monitoraggio (metriche e log) nelle istanze di computazione Oracle Cloud Infrastructure, vedere Abilitazione del monitoraggio per le istanze di computazione.

Agente di monitoraggio unificato Linux

Unità systemd

L'agente di monitoraggio unificato si basa su unità systemd ed è composto dai seguenti componenti:

  1. unified-monitoring-agent.service: il servizio principale Unified Monitoring Agent.
  2. unified-monitoring-agent_config_downloader.service: il servizio di aggiornamento automatico della configurazione.
  3. unified-monitoring-agent_config_downloader.timer: unità timer che attiva il servizio di download automatico in base a intervalli specificati, randomizzati.
  4. unified-monitoring-agent_restarter.path: unità di percorso, che attiva il ricaricamento della configurazione da parte dell'agente di monitoraggio unificato, se viene rilevata una modifica (a causa del download di una nuova configurazione da parte del servizio di aggiornamento automatico).
Nota

La maggior parte dei comandi systemctl o journalctl deve essere eseguita con privilegi di utente privilegiato, ad esempio root o tramite sudo.

Per verificare il corretto funzionamento di queste unità systemd, è possibile utilizzare il comando systemctl come indicato di seguito.

systemctl status <unit_name>
                        

dove <unit_name> deve essere sostituito da uno dei seguenti valori:

  1. unified-monitoring-agent.service
  2. unified-monitoring-agent_config_downloader.service
  3. unified-monitoring-agent_config_downloader.timer
  4. unified-monitoring-agent_restarter.path

In genere questi comandi systemctl mostrano un output simile al seguente:

systemctl status unified-monitoring-agent.service
   unified-monitoring-agent.service - unified-monitoring-agent: Fluentd based data collector for Oracle Cloud Infrastructure
   Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2020-09-29 13:54:03 UTC; 1min 37s ago
     Docs: https://docs.cloud.oracle.com/
  Process: 2337 ExecReload=/bin/kill -USR2 ${MAINPID} (code=exited, status=0/SUCCESS)
  Process: 2321 ExecStart=/opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unified-monitoring-agent/unified-monitoring-agent.pid --log-rotate-size 1048576 --log-rotate-age 10 $EXTRA_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 2327 (fluentd)
   Memory: 66.3M (limit: 5.0G)
   CGroup: /system.slice/unified-monitoring-agent.service
           ├─2327 /opt/unified-monitoring-agent/embedded/bin/ruby /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unif...
           └─2330 /opt/unified-monitoring-agent/embedded/bin/ruby -Eascii-8bit:ascii-8bit /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.lo...
systemctl status unified-monitoring-agent_config_downloader.service
  unified-monitoring-agent_config_downloader.service - unified-monitoring-agent Fluentd configuration downloader.
  Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent_config_downloader.service; enabled; vendor preset: disabled)
  Active: inactive (dead) since Tue 2020-09-29 13:54:38 UTC; 1min 30s ago
 Process: 2333 ExecStart=/opt/unified-monitoring-agent/embedded/bin/ruby /opt/unified-monitoring-agent/embedded/bin/fluent_config_updater.rb -c /etc/unified-monitoring-agent/conf.d/ -b 10 (code=exited, status=0/SUCCESS)
Main PID: 2333 (code=exited, status=0/SUCCESS) 
systemctl status unified-monitoring-agent_config_downloader.timer
  unified-monitoring-agent_config_downloader.timer - Run unified-monitoring-agent configuration automatic updater.
   Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent_config_downloader.timer; enabled; vendor preset: disabled)
   Active: active (waiting) since Tue 2020-09-29 13:54:03 UTC; 3min 57s ago 
systemctl status unified-monitoring-agent_restarter.path
  unified-monitoring-agent_restarter.path - "Monitor the /etc/unified-monitoring-agent/conf.d/ directory for changes"
   Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent_restarter.path; enabled; vendor preset: disabled)
   Active: active (waiting) since Tue 2020-09-29 13:54:03 UTC; 4min 9s ago 

Le parti più importanti dell'output del comando systemctl sono i campi Loaded e Active. Il campo Loaded contiene il valore loaded per tutte le unità di sistema. Il campo Active contiene i seguenti valori:

  • active (running) per l'unità Unified-monitoring-agent.service.
  • active (waiting) o active (running) per le unità Unified-monitoring-agent_restarter.path e Unified-monitoring-agent_config_downloader.timer.
  • active (running) o inactive (dead) per l'unità agent_config_downloader.service di monitoraggio unificato. Per quest'ultimo valore, il campo Main PID include il valore code=exited, status=0/SUCCESS).

Controlla processi in esecuzione

Un altro modo per verificare ulteriormente il corretto funzionamento dell'agente di monitoraggio unificato è controllare i processi in esecuzione del sistema. Quando funziona correttamente, l'agente di monitoraggio unificato esegue due processi: un processo supervisore e un processo lavoratore. È possibile verificarne l'esistenza eseguendo il seguente comando in un terminale (output di esempio incluso):

ps aux | grep unified-monitoring-agen[t]
root      2327  0.0  2.3 307704 40864 ?        Sl   13:54   0:00 /opt/unified-monitoring-agent/embedded/bin/ruby /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unified-monitoring-agent/unified-monitoring-agent.pid --log-rotate-size 1048576 --log-rotate-age 10
root      2330  0.2  2.1 297456 38192 ?        S    13:54   0:03 /opt/unified-monitoring-agent/embedded/bin/ruby -Eascii-8bit:ascii-8bit /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unified-monitoring-agent/unified-monitoring-agent.pid --log-rotate-size 1048576 --log-rotate-age 10 --under-supervisor

Come mostrato nell'esempio precedente, sono in esecuzione due processi con gli stessi argomenti, ad eccezione del –under-supervisor aggiuntivo aggiunto al secondo. Denota il processo del lavoratore, rendendo così il processo senza questo parametro il supervisore.

Posizione log agente di monitoraggio unificato

Nota

La maggior parte dei comandi systemctl o journalctl deve essere eseguita con privilegi di utente privilegiato, ad esempio root o tramite sudo.

I log di Unified Monitoring Agent sono disponibili all'indirizzo /var/log/unified-monitoring-agent/unified-monitoring-agent.log. Questo file include i log dell'agente di monitoraggio unificato.

Oltre ai log dell'agente, che non contengono eventi correlati al sistema (ad esempio, avvio del servizio, arresto del servizio e così via), è possibile visualizzare i log anche dal servizio di log del sistema journald, systemd. Per visualizzare i log di sistema specifici di un'unità, è possibile utilizzare il comando journalctl come indicato di seguito.

journalctl -u <unit_name>
                        

dove <unit_name> deve essere sostituito da uno dei seguenti valori:

  1. unified-monitoring-agent.service
  2. unified-monitoring-agent_config_downloader.service
  3. unified-monitoring-agent_config_downloader.timer
  4. unified-monitoring-agent_restarter.path
Quando si esegue una query sui log journald tramite journalctl, è inoltre possibile definire intervalli di tempo specifici:
journalctl --since "2020-12-30 00:00:01" --until "2020-12-31 23:59:59"
Il formato della data utilizzato è YYYY-MM-DD HH:MM:SS.
È inoltre possibile aggiungere i log dei giornali aggiungendo il parametro -f :
journalctl -f

Agente di monitoraggio unificato non installato

Per le istanze appena create, l'installazione automatica dell'agente può richiedere fino a 25 minuti. Se non è installato dopo questo periodo di tempo, controllare quanto segue:

  1. La connettività di rete dell'istanza.
  2. Indica se il monitoraggio è abilitato nella console.

È inoltre possibile controllare il file di log /var/log/oracle-cloud-agent/plugins/unifiedmonitoring/unifiedmonitoring.log per informazioni sull'installazione dell'agente di monitoraggio unificato da parte dell'agente Oracle Cloud.

L'agente di monitoraggio unificato non è in esecuzione

Se lo stato non è caricato o attivo, né i processi supervisore e lavoratore sono in esecuzione, riavviare l'agente di monitoraggio unificato e controllare i log per eventuali problemi.

systemctl restart unified-monitoring-agent

Configurazione non scaricata automaticamente

Assicurarsi di aver seguito la procedura descritta in Installazione dell'agente e Verifica installazione agente. Consultare il diario del servizio di aggiornamento automatico della configurazione eseguendo:

journalctl -u unified-monitoring-agent_config_downloader.service

Configurazione non ricaricata automaticamente

Assicurarsi di aver seguito la procedura descritta in Installazione dell'agente e Verifica installazione agente. Consulta la rivista di tutte le unità:

  1. L'unità timer deve essere eseguita almeno una volta.
  2. Il servizio di download della configurazione automatica deve essere stato eseguito dopo l'attivazione dell'unità di tempo pertinente. È possibile verificare dai relativi log che la configurazione sia stata scaricata ed estratta nella directory di configurazione dell'agente di monitoraggio unificato. Per verificarlo, è possibile anche elencare i file in quella directory: ls -lhatR /etc/unified-monitoring-agent.
  3. Verificare che l'unità di percorso sia attiva verificandone lo stato: systemctl status unified-monitoring-agent_restarter.path.
  4. Verificare che l'agente di monitoraggio unificato abbia ricevuto un segnale di ricaricamento esaminandone il giornale: journalctl -u unified-monitoring-agent_config_downloader.service. Nell'output di questo comando viene visualizzato "Reloading unified-monitoring-agent".

Test del pattern di analisi e forzare l'agente a scaricare immediatamente la configurazione

Eseguire il comando riportato di seguito:

systemctl restart unified-monitoring-agent_config_downloader
Nota

L'aggiornamento automatico della configurazione sul lato agente può richiedere fino a 30 minuti.

Creare un log personalizzato per visualizzare il contenuto di un alert log di un sistema di database mediante OCI

L'agente di monitoraggio unificato non supporta il sistema di database.

Raccolta dati

Se si desidera aprire un ticket in modo che un tecnico possa risolvere il problema relativo all'agente di monitoraggio unificato, includere l'output dei seguenti comandi. Per alcuni di essi potrebbero essere richiesti privilegi di utente privilegiato.

yum info unified-monitoring-agent
rpm -ql unified-monitoring-agent |  xargs sha512sum
systemctl status --full unified-monitoring-agent.service
systemctl status --full unified-monitoring-agent_config_downloader.service
systemctl status --full unified-monitoring-agent_config_downloader.timer
systemctl status --full unified-monitoring-agent_restarter.path
journalctl -a --no-pager -u unified-monitoring-agent.service
journalctl -a --no-pager -u unified-monitoring-agent_config_downloader.service
journalctl -a --no-pager -u unified-monitoring-agent_config_downloader.timer
journalctl -a --no-pager -u unified-monitoring-agent_restarter.path

Per Ubuntu utilizzare un comando simile al seguente:

apt show unified-monitoring-agent
dpkg -L unified-monitoring-agent | xargs sha512sum

Includere anche un archivio dei file sotto /var/log/unified-monitoring-agent/ e /var/log/oracle-cloud-agent/. È possibile creare un archivio tar compresso di queste directory con il comando:

tar cvzf agent_logs_$(date +%s).tar.gz /var/log/unified-monitoring-agent/ /var/log/oracle-cloud-agent/

Se Unified Monitoring Agent è in esecuzione ma ha un funzionamento irregolare, è anche possibile includere informazioni sul profilo di backtrace e memoria, eseguendo il comando seguente e includendo i file /tmp/sigdump-<integer>.log nel report (dove <integer> è un numero intero con 1-6 cifre, anche se in rari casi potrebbe avere più di questo).

ps aux | grep unified-monitoring-agen[t] | grep ruby | awk '{print $2}' | xargs kill -SIGCONT

Questo comando consente di trovare i PID di processo dell'agente di monitoraggio unificato e di inviare loro il segnale SIGCONT, che genera un dump in /tmp/sigdump-<integer>.log.

Disinstalla e reinstalla

È possibile rimuovere l'agente di monitoraggio unificato senza rimuovere la configurazione dell'agente eseguendo il comando seguente:

yum -y remove unified-monitoring-agent

Per Ubuntu:

apt -y remove unified-monitoring-agent

La configurazione dell'agente rimane nella directory /etc/unified-monitoring-agent/. Se non si desidera mantenere la configurazione per una futura (ri)installazione del package Unified Monitoring Agent, è necessario rimuoverla manualmente:

# use the following command to print the contents of the agent's configuration directory
find /etc/unified-monitoring-agent/
# use the following command to remove the directory and all of its contents (this step cannot be undone)
rm -rf /etc/unified-monitoring-agent/

L'agente viene reinstallato automaticamente dall'agente Oracle Cloud al massimo 25 minuti. Affinché ciò si verifichi, è necessario abilitare il monitoraggio per l'istanza nella console. Per ulteriori informazioni, vedere Agente Oracle Cloud.

Agente di monitoraggio unificato Windows

Per controllare lo stato del servizio

  1. L'agente viene eseguito come parte di un servizio Windows, per visualizzarne lo stato, aprire il menu di avvio e digitare Services.msc e aprirlo. Per visualizzare lo stato, vai al servizio Oracle Cloud Unified Monitoring Service.
  2. Fare clic con il pulsante destro del mouse sul servizio e scegliere Proprietà per ulteriori informazioni. Start/stop/restart sono disponibili qui.
  3. Nel tipo di menu Start cmd, fare clic con il pulsante destro del mouse su Prompt dei comandi e selezionare Esegui come amministratore. Eseguire i seguenti comandi:
  • Per visualizzare lo stato del servizio Agente di monitoraggio unificato:
    sc query unified-monitoring-agent
  • Riavviare il servizio Unified Monitoring Agent:
    sc stop unified-monitoring-agent
    sc start unified-monitoring-agent
Nota

I comandi precedenti non funzionano in PowerShell, pertanto è necessario utilizzare il prompt dei comandi di Windows.

Per trovare gli errori del servizio Windows

  1. Nel menu Avvia digitare Visualizzatore eventi e selezionarlo.
  2. Aprire Log di Windows, quindi Sistema. Ogni volta che un servizio inizia o si interrompe, non riesce a farlo o si blocca improvvisamente, viene registrato qui.
    Nota

    Nella maggior parte dei computer Windows è previsto un limite al numero di eventi che possono essere presenti nel visualizzatore eventi. Di conseguenza, se si è verificato un evento molto tempo fa, i log potrebbero non essere disponibili.

Per visualizzare i log Fluentd

  1. Apri explorer.exe (icona del file nella barra delle applicazioni)
  2. Passare a C:\oracle_unified_agent.
  3. Se c'è un solo file, significa che non c'è un file di configurazione valido sul computer.
  4. Se sono presenti due file, esiste un log del supervisore che avrà tutti i log di impostazione/avvio e un log del lavoratore con tutti i log di analisi/output. Unified-monitoring-agent.conf è il nome del file di configurazione se è stato scaricato correttamente.
  5. Eseguire Fluentd manualmente. Provare i passi precedenti per identificare il problema, ma se necessario, è possibile eseguire il debug di un problema eseguendo manualmente Fluentd.
    Nota

    L'esecuzione di Fluentd viene eseguita manualmente nel servizio Windows, che impedisce l'esecuzione normale del servizio e comporta un comportamento diverso rispetto a quello di Linux.
  6. Utilizzare il seguente comando per eseguire Fluentd manualmente. Questa operazione può essere eseguita in PowerShell o nel prompt dei comandi, ma deve essere eseguita come amministratore:
    C:\oracle_unified_agent\unified-monitoring-agent\embedded\bin\fluentd -c C:\oracle_unified_agent\unified-monitoring-agent.conf -vv

Passi per l'aggiornamento automatico della configurazione

  1. Verificare che lo scheduler task sia in esecuzione come previsto.
  2. Dal menu Start, digitare Task Scheduler.
  3. Andare a Scheduler di task (locale), quindi a Libreria scheduler di task. Trovare il task denominato UnifiedAgentConfigUpdater.
  4. Verificare l'ora dell'ultima esecuzione. Se la data non è valida o indica non eseguire, l'ora della prossima esecuzione sarà quella della prima esecuzione. Per il debug, selezionare l'attività e selezionare Esegui se è necessario eseguirla immediatamente.
  5. Risultato ultima esecuzione specifica il risultato del download della configurazione dal piano di controllo. Se si verifica un errore, è necessario eseguirlo manualmente per determinare cosa è successo. Task Scheduler non conserva i log di output.
  6. Eseguire manualmente il programma di aggiornamento della configurazione.
    Nota

    Per un'esperienza ottimale, eseguire il programma di aggiornamento in PowerShell come amministratore.
    C:\oracle_unified_agent\unified-monitoring-agent\embedded\bin\ruby.exe C:\oracle_unified_agent\unified-monitoring-agent\embedded\lib\ruby\gems\2.6.0\gems\fluent-public-config-updater*\lib\fluent_config_updater.rb -c C:\oracle_unified_agent -b 10

Controlla log agente Oracle Cloud

Per Windows Server 2012r2 o 2016, le posizioni dei file di log sono:

  • C:\Users\OCA\AppData\Local\Local\OracleCloudAgent\agent.log
  • C:\Users\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring.log (log di runtime)
  • C:\Users\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring_msi.log (log di installazione)
  • C:\oracle_unified_agent\unified-monitoring-agent-0.log (log del lavoratore agente, che potrebbe non esistere a seconda dello stato)
  • C:\oracle_unified_agent\unified-monitoring-agent-supervisor-0.log (log supervisore agente, che potrebbe non esistere a seconda dello stato)

Posizioni dei file di log di Windows Server 2019/2022:

  • C:\Windows\ServiceProfiles\OCA\AppData\Local\OracleCloudAgent\agent.log
  • C:\Windows\ServiceProfiles\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring.log (log di runtime)
  • C:\Windows\ServiceProfiles\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring_msi.log (log di installazione)
  • C:\oracle_unified_agent\unified-monitoring-agent-0.log (log del lavoratore agente, che potrebbe non esistere a seconda dello stato)
  • C:\oracle_unified_agent\unified-monitoring-agent-supervisor-0.log (log supervisore agente, che potrebbe non esistere a seconda dello stato)

Installazione MSI non riuscita intermittente

Un'installazione MSI non riuscita intermittente può verificarsi per uno dei due motivi:

  1. Un'installazione MSI è stata interrotta (riavvio del sistema, arresto del processo e così via) e alla seconda esecuzione il processo msiexec.exe conserva ancora un handle di file in una cartella creata.
  2. Durante un aggiornamento in cui MSI non riesce ad accedere alla cartella principale dell'agente, poiché Ruby.exe non termina come dovrebbe (un problema Fluentd). Ciò causa il guasto dell'MSI e il cleanup del sistema, rimuovendo gran parte dell'agente (non la posizione o i file buffer).

In entrambi i casi, una seconda installazione o l'esecuzione di Oracle Cloud Agent tramite l'installazione risolve il problema. Se è ancora bloccato in questo stato, effettuare le operazioni riportate di seguito.

  1. Arrestare tutti i processi msiexec e ruby in Task Manager, Dettagli.
  2. Rinominare C:\oracle_unified_agent in C:\oracle_unified_agent_old.
  3. Installare di nuovo l'agente oppure attendere l'installazione dell'agente Oracle Cloud.

Percorsi generici che non funzionano con la configurazione dell'agente

Utilizzare una barra (/) durante la configurazione dei percorsi per la configurazione dell'agente Windows. Una barra rovesciata (\) con un asterisco (*) non funziona su Windows a causa di limitazioni interne. Per evitare questo problema, non utilizzare un percorso come C:\\path\\to\\*\\foo.log. Utilizzare il seguente metodo barra:

path C:/path/to/*/foo.log

Di seguito sono riportati gli esempi di percorsi di lavoro generici supportati per Windows.

  • C:/logs/*
  • C:/logs/t2*.txt
  • C:/logs/a*b.txt
  • C:/logs/abc*
  • C:/logs/*.txt
  • C:/logs/*/abc*
  • C:/logs/*/a.txt
  • C:/logs/*/a*b.txt
  • C:/logs*/*.txt

Il percorso generico C:/logs/*log.txt, tuttavia, non funziona per Windows.