Nota: l'endpoint localhost:2020/api/v1/metrics menzionato alle 3:18 in questo video non è più disponibile nell'agente Ops. Per altre opzioni, vedi Agente in esecuzione ma i dati non vengono importati.
Questo documento consente di diagnosticare i problemi di installazione o di esecuzione dell'agente operativo.
Strumento di diagnostica degli agenti per le VM
Lo strumento di diagnostica degli agenti raccoglie informazioni critiche per il debug locale dalle VM per tutti i seguenti agenti: agente operativo, agente legacy di logging e agente Monitoring legacy. Le informazioni di debug includono elementi di progetto, informazioni sulla VM, configurazione dell'agente, log dell'agente, stato del servizio dell'agente e informazioni che in genere richiedono un lavoro manuale per essere raccolte. Lo strumento controlla anche l'ambiente VM locale per garantire che soddisfi determinati requisiti per il corretto funzionamento degli agenti, ad esempio la connettività di rete e le autorizzazioni richieste.
Quando invii la richiesta di un cliente per un agente su una VM, esegui lo strumento di diagnostica dell'agente e allega le informazioni raccolte alla richiesta. Prima di allegare le informazioni alla richiesta di assistenza, oscura eventuali informazioni sensibili, come le password. Queste informazioni riducono il tempo necessario per risolvere i problemi della tua richiesta di assistenza.
Lo strumento di diagnostica degli agenti deve essere eseguito dall'interno della VM, pertanto devi prima connetterti a SSH nella VM. Il comando seguente recupera lo strumento di diagnostica dell'agente ed lo esegue:
Linux
curl -sSO https://dl.google.com/cloudagents/diagnose-agents.sh
sudo bash diagnose-agents.sh
Windows
(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/diagnose-agents.ps1", "${env:UserProfile}\diagnose-agents.ps1")
Invoke-Expression "${env:UserProfile}\diagnose-agents.ps1"
Segui l'output dell'esecuzione dello script per individuare i file che includono le informazioni raccolte. In genere puoi trovarli nella directory /var/tmp/google-agents su Linux e nella directory $env:LOCALAPPDATA/Temp su Windows, a meno che tu non abbia personalizzato la directory di output durante l'esecuzione dello script.
Per informazioni dettagliate, esamina lo script diagnose-agents.sh su Linux o lo script diagnose-agents.ps1 su Windows.
Impossibile installare l'agente
Potresti riscontrare i seguenti errori durante l'esecuzione dello script di installazione.
Il sistema operativo non è supportato. Il messaggio di errore potrebbe essere simile al seguente:
Linux
https://packages.cloud.google.com/yum/repos/google-cloud-ops-agent-el6-x86_64-all/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. To address this issue please refer to the below wiki article https://wiki.centos.org/yum-errors If above article doesn't help to resolve this issue please use https://bugs.centos.org/. Error: Cannot retrieve repository metadata (repomd.xml) for repository: google-cloud-ops-agent. Please verify its path and try again
Nella VM è già installato l'agente Cloud Logging o l'agente Cloud Monitoring e sono in conflitto con il nuovo agente. Il messaggio di errore potrebbe essere simile al seguente:
Linux
Error: Problem: problem with installed package stackdriver-agent-6.0.5-1.el8.x86_64 - package google-cloud-ops-agent-0.1.0-1.el8.x86_64 conflicts with stackdriver-agent provided by stackdriver-agent-6.0.5-1.el8.x86_64
L'agente operativo utilizza nuovi file di configurazione non compatibili con i vecchi agenti. Per ulteriori informazioni, consulta la guida Configura l'agente operativo.
Per correggere questo errore:
Salva i file di configurazione personalizzati per l'agente Cloud Monitoring e l'agente Cloud Logging.
Disinstalla i vecchi agente Cloud Monitoring e agente Cloud Logging.
Dopo che hai disinstallato l'agente, la console di Google Cloud potrebbe impiegare fino a un'ora per segnalare questa modifica.
L'agente è installato ma non in esecuzione
Servizi agente non in esecuzione
Quando il servizio agente è in esecuzione come previsto, potresti visualizzare il seguente stato:
Per Linux
computer@debian9:~$ sudo systemctl status google-cloud-ops-agent"*"
● google-cloud-ops-agent.service - Google Cloud Ops Agent
Loaded: loaded (/lib/systemd/system/google-cloud-ops-agent.service; enabled; vendor preset: enabled)
Active: active (exited) since Thu 2021-08-05 20:33:44 UTC; 7s ago
Process: 2240 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Process: 2214 ExecStartPre=/opt/google-cloud-ops-agent/libexec/google_cloud_ops_agent_engine -in /etc/google-cloud-ops-agent/config.yaml (code=exited, status=0/SUCCESS)
Main PID: 2240 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
CGroup: /system.slice/google-cloud-ops-agent.service
Aug 05 20:33:44 debian9 systemd[1]: Starting Google Cloud Ops Agent...
Aug 05 20:33:44 debian9 systemd[1]: Started Google Cloud Ops Agent.
● google-cloud-ops-agent-fluent-bit.service - Google Cloud Ops Agent - Logging Agent
Loaded: loaded (/lib/systemd/system/google-cloud-ops-agent-fluent-bit.service; static; vendor preset: enabled)
Drop-In: /lib/systemd/system/google-cloud-ops-agent-fluent-bit.service.d
└─directories.conf
Active: active (running) since Thu 2021-08-05 20:33:44 UTC; 7s ago
Process: 2234 ExecStartPre=/bin/mkdir -p ${RUNTIME_DIRECTORY} ${STATE_DIRECTORY} ${LOGS_DIRECTORY} (code=exited, status=0/SUCCESS)
Process: 2216 ExecStartPre=/opt/google-cloud-ops-agent/libexec/google_cloud_ops_agent_engine -service=fluentbit -in /etc/google-cloud-ops-agent/config.yaml -logs ${LOGS_DIRECTORY} -state ${STATE_DIRECTORY} (code=exited, status=0/SUCCESS)
Main PID: 2247 (fluent-bit)
Tasks: 22 (limit: 4915)
CGroup: /system.slice/google-cloud-ops-agent-fluent-bit.service
└─2247 /opt/google-cloud-ops-agent/subagents/fluent-bit/bin/fluent-bit --config /run/google-cloud-ops-agent-fluent-bit/fluent_bit_main.conf --parser /run/google-cloud-ops-agent-fluent-bit/fluent_bit_parser.conf --log_file /var/log/google-cloud-ops-agent/subagents/logging-module.log --storage_path /var/lib/google-cloud-ops-agent/fluent-bit/buffers
Aug 05 20:33:44 debian9 systemd[1]: Starting Google Cloud Ops Agent - Logging Agent...
Aug 05 20:33:44 debian9 systemd[1]: Started Google Cloud Ops Agent - Logging Agent.
Aug 05 20:33:44 debian9 fluent-bit[2247]: Fluent Bit v1.7.8
Aug 05 20:33:44 debian9 fluent-bit[2247]: * Copyright (C) 2019-2021 The Fluent Bit Authors
Aug 05 20:33:44 debian9 fluent-bit[2247]: * Copyright (C) 2015-2018 Treasure Data
Aug 05 20:33:44 debian9 fluent-bit[2247]: * Fluent Bit is a CNCF sub-project under the umbrella of Fluentd
Aug 05 20:33:44 debian9 fluent-bit[2247]: * https://fluentbit.io
● google-cloud-ops-agent-opentelemetry-collector.service - Google Cloud Ops Agent - Metrics Agent
Loaded: loaded (/lib/systemd/system/google-cloud-ops-agent-opentelemetry-collector.service; static; vendor preset: enabled)
Drop-In: /lib/systemd/system/google-cloud-ops-agent-opentelemetry-collector.service.d
└─directories.conf
Active: active (running) since Thu 2021-08-05 20:33:44 UTC; 7s ago
Process: 2237 ExecStartPre=/bin/mkdir -p ${RUNTIME_DIRECTORY} ${STATE_DIRECTORY} ${LOGS_DIRECTORY} (code=exited, status=0/SUCCESS)
Process: 2215 ExecStartPre=/opt/google-cloud-ops-agent/libexec/google_cloud_ops_agent_engine -service=otel -in /etc/google-cloud-ops-agent/config.yaml -logs ${LOGS_DIRECTORY} (code=exited, status=0/SUCCESS)
Main PID: 2251 (otelopscol)
Tasks: 6 (limit: 4915)
CGroup: /system.slice/google-cloud-ops-agent-opentelemetry-collector.service
└─2251 /opt/google-cloud-ops-agent/subagents/opentelemetry-collector/otelopscol --add-instance-id=false --config=/run/google-cloud-ops-agent-opentelemetry-collector/otel.yaml
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.234Z info builder/pipelines_builder.go:51 Pipeline is starting... {"pipeline_name": "metrics/system", "pipeline_datatype": "metrics"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.234Z info builder/pipelines_builder.go:62 Pipeline is started. {"pipeline_name": "metrics/system", "pipeline_datatype": "metrics"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.234Z info service/service.go:192 Starting receivers...
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.235Z info builder/receivers_builder.go:70 Receiver is starting... {"kind": "receiver", "name": "hostmetrics/hostmetrics"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.235Z info builder/receivers_builder.go:75 Receiver started. {"kind": "receiver", "name": "hostmetrics/hostmetrics"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.236Z info builder/receivers_builder.go:70 Receiver is starting... {"kind": "receiver", "name": "prometheus/agent"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.236Z info discovery/manager.go:195 Starting provider {"kind": "receiver", "name": "prometheus/agent", "level": "debug", "provider": "static/0", "subs": "[otel-collector]"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.236Z info builder/receivers_builder.go:75 Receiver started. {"kind": "receiver", "name": "prometheus/agent"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.236Z info service/collector.go:182 Everything is ready. Begin running and processing data.
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.256Z info discovery/manager.go:213 Discoverer channel closed {"kind": "receiver", "name": "prometheus/agent", "level": "debug", "provider": "static/0"}
Per Windows
Get-Service google-cloud-ops-agent* Status Name DisplayName ------ ---- ----------- Running google-cloud-op... Google Cloud Ops Agent Running google-cloud-op... Google Cloud Ops Agent - Logging Agent Running google-cloud-op... Google Cloud Ops Agent - Metrics Agent
Se il servizio agente non è in esecuzione, potresti visualizzare il seguente stato:
Linux
$ sudo service google-cloud-ops-agent status ● google-cloud-ops-agent.service - Google Cloud Ops Agent Loaded: loaded (/lib/systemd/system/google-cloud-ops-agent.service; enabled; vendor preset: enabled) Active: inactive (dead) since Wed 2021-06-30 21:20:43 UTC; 6s ago
Windows
Get-Service google-cloud-ops-agent Status Name DisplayName ------ ---- ----------- Stopped google-cloud-ops-agent Google Cloud Ops Agent
Per correggere questo errore, esegui il comando seguente per avviare il servizio:
Linux
sudo service google-cloud-ops-agent start
Windows
Start-Service google-cloud-ops-agent
Se il servizio non si avvia, la configurazione potrebbe non essere valida.
Conflitto con gli agenti attualmente installati
Nella VM è già installato l'agente Cloud Logging o l'agente Cloud Monitoring e la sua configurazione è in conflitto con la configurazione del nuovo agente. Il messaggio di errore potrebbe essere simile al seguente:
Windows
We detected an existing Windows service for the StackdriverLogging agent, which is not compatible with the Ops Agent when the Ops Agent configuration has a non-empty logging section. Please either remove the logging section from the Ops Agent configuration, or disable the StackdriverLogging agent, and then retry enabling the Ops Agent.
Per correggere questo errore, puoi procedere in due modi:
Disabilita la sezione in conflitto del file di configurazione dell'agente Ops. Per ulteriori informazioni, consulta la guida Configura l'agente operativo.
Disabilita l'agente Cloud Logging in conflitto o l'agente Cloud Monitoring.
- Salva i file di configurazione personalizzati per l'agente Cloud Logging.
- Disinstalla i vecchi agente Cloud Monitoring e agente Cloud Logging.
Dopo che hai disinstallato l'agente, la console di Google Cloud potrebbe impiegare fino a un'ora per segnalare questa modifica.
Configurazione non valida
Se la configurazione non è valida, potrebbe essere visualizzato il seguente errore durante il tentativo di riavviare il servizio di agenti:
Linux
$ sudo service google-cloud-ops-agent restart \
&& sudo service google-cloud-ops-agent status
● google-cloud-ops-agent-fluent-bit.service - Google Cloud Ops Agent - Logging Agent
Loaded: loaded (/usr/lib/systemd/system/google-cloud-ops-agent-fluent-bit.service; static; vendor preset: disabled)
Drop-In: /usr/lib/systemd/system/google-cloud-ops-agent-fluent-bit.service.d
└─directories.conf
Active: failed (Result: exit-code) since Wed 2021-06-30 22:21:08 UTC; 2s ago
Process: 1141421 ExecStart=/opt/google-cloud-ops-agent/subagents/fluent-bit/bin/fluent-bit --config ${RUNTIME_DIRECTORY}/fluent_bit_main.conf --parser ${RUNTIME_DIRECTORY}/fluent_bit_parser.conf --log_>
Process: 1141847 ExecStartPre=/opt/google-cloud-ops-agent/libexec/google_cloud_ops_agent_engine -service=fluentbit -in /etc/google-cloud-ops-agent/config.yaml -logs ${LOGS_DIRECTORY} -state ${STATE_DIR>
Main PID: 1141421 (code=exited, status=0/SUCCESS)
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Control process exited, code=exited status=1
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Failed with result 'exit-code'.
Jun 30 22:21:08 centos8-2 systemd[1]: Failed to start Google Cloud Ops Agent - Logging Agent.
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Service RestartSec=100ms expired, scheduling restart.
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Scheduled restart job, restart counter is at 5.
Jun 30 22:21:08 centos8-2 systemd[1]: Stopped Google Cloud Ops Agent - Logging Agent.
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Start request repeated too quickly.
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Failed with result 'exit-code'.
Jun 30 22:21:08 centos8-2 systemd[1]: Failed to start Google Cloud Ops Agent - Logging Agent.
Utilizza journalctl per visualizzare esattamente il messaggio di errore:
sudo journalctl -xe | grep "google_cloud_ops_agent_engine"
Potresti vedere un messaggio simile al seguente:
Jun 30 22:00:26 centos8-2 google_cloud_ops_agent_engine[1141491]: 2021/06/30 22:00:26 the agent config file is not valid YAML. detailed error: yaml: line 21: did not find expected key
Windows
failed to generate config files: can't parse configuration: yaml: line 20: could not find expected ':'
Per correggere l'errore, correggi la configurazione non valida e riavvia l'agente. Come riferimento, consulta la guida Configurare l'agente Ops.
L'agente è in esecuzione, ma i dati non vengono importati
Usa Metrics Explorer per eseguire la query sulla metrica uptime dell'agente e verificare che il componente dell'agente, google-cloud-ops-agent-metrics o google-cloud-ops-agent-logging, stia scrivendo alla metrica.
Nella console Google Cloud, seleziona Monitoring o fai clic sul seguente pulsante:
Nel riquadro di navigazione, seleziona
Metrics Explorer.Seleziona la scheda MQL.
Inserisci la query seguente, quindi fai clic su Esegui:
fetch gce_instance | metric 'agent.googleapis.com/agent/uptime' | align rate(1m) | every 1m
L'agente invia i log a Cloud Logging?
Controllare le metriche locali
Questi passaggi richiedono l'uso di SSH nella VM.
- Il modulo di logging è in esecuzione? Utilizza i seguenti comandi per controllare:
Linux
sudo systemctl status google-cloud-ops-agent"*"
Windows
Apri Windows PowerShell come amministratore ed esegui:
Get-Service google-cloud-ops-agent
Puoi anche controllare lo stato del servizio nell'app Servizi e controllare i processi in esecuzione nell'app Gestione attività.
Controlla il log del modulo di logging
Questo passaggio richiede l'uso di SSH nella VM.
Puoi trovare i log del modulo di logging all'indirizzo /var/log/google-cloud-ops-agent/subagents/*.log per Linux e C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log per Windows. Se non sono presenti log, il servizio agente non è in esecuzione in modo corretto. Vai alla sezione L'agente è installato ma non in esecuzione per risolvere questa condizione.
Potresti visualizzare errori di autorizzazione 403 durante la scrittura nell'API Logging. Ad esempio:
[2020/10/13 18:55:09] [ warn] [output:stackdriver:stackdriver.0] error { "error": { "code": 403, "message": "Cloud Logging API has not been used in project 147627806769 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.", "status": "PERMISSION_DENIED", "details": [ { "@type": "type.googleapis.com/google.rpc.Help", "links": [ { "description": "Google developers console API activation", "url": "https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769" } ] } ] } }Per correggere questo errore, abilita l'API Logging e imposta il ruolo Writer log.
Potresti notare un problema di quota per l'API Logging. Ad esempio:
error="8:Insufficient tokens for quota 'logging.googleapis.com/write_requests' and limit 'WriteRequestsPerMinutePerProject' of service 'logging.googleapis.com' for consumer 'project_number:648320274015'." error_code="8"
Per correggere questo errore, aumenta la quota o riduci la velocità effettiva del log.
Nel log del modulo potrebbero essere visualizzati i seguenti errori:
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}o
can't fetch token from the metadata server
Questi errori potrebbero indicare che hai eseguito il deployment dell'agente senza account di servizio o credenziali specificate. Per informazioni sulla risoluzione di questo problema, consulta Autorizzare l'agente operativo.
L'agente invia le metriche a Cloud Monitoring?
Controllare il log del modulo delle metriche
Questo passaggio richiede l'uso di SSH nella VM.
Puoi trovare i log del modulo delle metriche in syslog. Se non sono presenti log, significa che il servizio agente non è in esecuzione correttamente. Vai alla sezione L'agente è installato ma non in esecuzione per risolvere questa condizione.
Potresti notare
PermissionDeniederrori durante la scrittura nell'API Monitoring. Questo errore si verifica se l'autorizzazione dell'agente Ops non è configurata correttamente. Ad esempio:Nov 2 14:51:27 test-ops-agent-error otelopscol[412]: 2021-11-02T14:51:27.343Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "[rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).; rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).]", "interval": "6.934781228s"}Per correggere questo errore, abilita l'API Monitoring e imposta il ruolo Monitoring Writer metrica.
Potresti notare
ResourceExhaustederrori durante la scrittura nell'API Monitoring. Questo errore si verifica se il progetto raggiunge il limite per qualsiasi quota dell'API Monitoring. Ad esempio:Nov 2 18:48:32 test-ops-agent-error otelopscol[441]: 2021-11-02T18:48:32.175Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "rpc error: code = ResourceExhausted desc = Quota exceeded for quota metric 'Total requests' and limit 'Total requests per minute per user' of service 'monitoring.googleapis.com' for consumer 'project_number:8563942476'.\nerror details: name = ErrorInfo reason = RATE_LIMIT_EXCEEDED domain = googleapis.com metadata = map[consumer:projects/8563942476 quota_limit:DefaultRequestsPerMinutePerUser quota_metric:monitoring.googleapis.com/default_requests service:monitoring.googleapis.com]", "interval": "2.641515416s"}Per correggere questo errore, aumenta la quota o riduci la velocità effettiva delle metriche.
Nel log del modulo potrebbero essere visualizzati i seguenti errori:
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}o
can't fetch token from the metadata server
Questi errori potrebbero indicare che hai eseguito il deployment dell'agente senza account di servizio o credenziali specificate. Per informazioni sulla risoluzione di questo problema, consulta Autorizzare l'agente operativo.
Ispeziona log automatici dell'agente
Se l'agente non riesce a importare i log in Cloud Logging, potresti dover ispezionarli a livello locale sulla VM per risolvere il problema.
Linux
Per controllare gli autolog scritti in Journald, esegui il comando seguente:
journalctl -u google-cloud-ops-agent*
Per controllare gli autolog scritti sul disco dal modulo di logging, esegui il comando seguente:
vim /var/log/google-cloud-ops-agent/subagents/logging-module.log
Windows
Per controllare gli autolog scritti in Windows Event Logs, esegui questo comando:
Get-WinEvent -FilterHashtable @{ Logname='Application'; ProviderName='google-cloud-ops-agent*' } | Format-Table -AutoSize -Wrap
Per controllare gli autolog scritti sul disco dal modulo di logging, esegui il comando seguente:
notepad "C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log"
Per esaminare i log dal servizio Windows Service Control Manager per gli agenti operativi, esegui il comando seguente:
Get-WinEvent -FilterHashtable @{ Logname='System'; ProviderName='Service Control Manager' } | Where-Object -Property Message -Match 'Google Cloud Ops Agent' | Format-Table -AutoSize -Wrap
Configura la rotazione dei file di log self-service sulle VM Linux
Per limitare le dimensioni del log dell'agente secondario di logging a
/var/log/google-cloud-ops-agent/subagents/logging-module.log, installa e configura l'utilità logrotate.
Installa l'utilità
logrotateeseguendo questo comando:Su Debian e Ubuntu
sudo apt install logrotateSu CentOS, RHEL e Fedora
sudo yum install logrotateCrea un file di configurazione
logrotateall'indirizzo/etc/logrotate.d/google-cloud-ops-agent.conf.sudo tee /etc/logrotate.d/google-cloud-ops-agent.conf > /dev/null << EOF # logrotate config to rotate Google Cloud Ops Agent self log file. # See https://manpages.debian.org/jessie/logrotate/logrotate.8.en.html for # the full options. /var/log/google-cloud-ops-agent/subagents/logging-module.log { # Log files are rotated every day. daily # Log files are rotated this many times before being removed. This # effectively limits the disk space used by the Ops Agent self log files. rotate 30 # Log files are rotated when they grow bigger than maxsize even before the # additionally specified time interval maxsize 256M # Skip rotation if the log file is missing. missingok # Do not rotate the log if it is empty. notifempty # Old versions of log files are compressed with gzip by default. compress # Postpone compression of the previous log file to the next rotation # cycle. delaycompress } EOFConfigura
crontabosystemd timerper attivare periodicamente l'utilitàlogrotate.
Una volta applicata la rotazione dei log, vedrai i file ruotati nella directory /var/log/google-cloud-ops-agent/subagents/. I risultati hanno un aspetto simile al seguente:
/var/log/google-cloud-ops-agent/subagents$ ls -lh
total 24K
-rw-r--r-- 1 root root 717 Sep 3 19:54 logging-module.log
-rw-r--r-- 1 root root 6.8K Sep 3 19:51 logging-module.log.1
-rw-r--r-- 1 root root 874 Sep 3 19:50 logging-module.log.2.gz
-rw-r--r-- 1 root root 873 Sep 3 19:50 logging-module.log.3.gz
-rw-r--r-- 1 root root 3.2K Sep 3 19:34 logging-module.log.4.gz
Per testare la rotazione dei log:
Riduci temporaneamente le dimensioni del file a cui viene attivata la rotazione impostando il valore
maxsizesu1knel file/etc/logrotate.d/google-cloud-ops-agent.conf.Fai in modo che il file di log self-service dell'agente abbia dimensioni superiori a 1K riavviando l'agente alcune volte:
sudo service google-cloud-ops-agent restartAttendi che l'oggetto
crontabosystemd timerabbia effetto per attivare l'utilitàlogrotateoppure attiva manualmente l'utilitàlogrotateeseguendo questo comando:sudo logrotate /etc/logrotate.d/google-cloud-ops-agent.confVerifica che i file di log ruotati siano elencati nella directory
/var/log/google-cloud-ops-agent/subagents/.Reimposta la configurazione della rotazione dei log ripristinando il valore
maxsizeoriginale.
Reimposta completamente lo stato dell'agente
Se l'agente entra in uno stato non recuperabile, segui questi passaggi per ripristinare l'agente in uno stato nuovo.
Linux
Interrompi il servizio agente:
sudo service google-cloud-ops-agent stop
Rimuovi il pacchetto dell'agente:
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --uninstall --remove-repo
Rimuovi i log self-service dell'agente su disco:
sudo rm -rf /var/log/google-cloud-ops-agent
Rimuovi i buffer locali dell'agente sul disco:
sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers/*/
Reinstalla e riavvia l'agente:
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
sudo service google-cloud-ops-agent restart
Windows
Interrompi il servizio agente:
Stop-Service google-cloud-ops-agent -Force;
Get-Service google-cloud-ops-agent* | %{sc.exe delete $_};
taskkill /f /fi "SERVICES eq google-cloud-ops-agent*";
Rimuovi il pacchetto dell'agente:
(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -Uninstall -RemoveRepo"
Rimuovi i log self-service dell'agente su disco:
rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\log";
Rimuovi i buffer locali dell'agente sul disco:
Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -Directory -ErrorAction SilentlyContinue | %{rm -r -Path $_.FullName}
Reinstalla e riavvia l'agente:
(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -AlsoInstall"
Reimposta ma salva i file del buffer
Se la VM non ha blocchi del buffer danneggiati (ossia, non ci sono messaggi format
check failed nel file di log self-service dell'agente Ops), puoi ignorare i comandi precedenti che eliminano i buffer locali quando reimposta lo stato dell'agente.
Se la VM ha blocchi di buffer danneggiati, devi rimuoverli. Le opzioni seguenti descrivono diversi modi di gestire i buffer. Gli altri passaggi descritti in Reimpostare completamente lo stato dell'agente sono ancora applicabili.
Opzione 1: elimina l'intera directory
buffers. Questa è l'opzione più semplice, ma può comportare la perdita dei log di buffer non danneggiati o la duplicazione dei log a causa della perdita dei file di posizione.Linux
sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffersWindows
rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers";Opzione 2: elimina le sottodirectory del buffer dalla directory
buffers, ma lascia i file di posizione. Questo approccio è descritto in Reimpostare completamente lo stato dell'agente.Opzione 3: se non vuoi eliminare tutti i file di buffer, puoi estrarre i nomi dei file di buffer danneggiati dai log di buffer dell'agente ed eliminare solo i file di buffer danneggiati.
Linux
grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -fWindows
$oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log"; if (Test-Path $oalogspath) { Select-String "format check failed" $oalogspath | %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} | %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)} };Opzione 4: se ci sono molti buffer danneggiati e vuoi rielaborare tutti i file di log, puoi utilizzare i comandi dell'opzione 3 ed eliminare i file di posizione in cui sono archiviati l'avanzamento dell'agente operativo per ogni file di log. L'eliminazione dei file di posizione può comportare la duplicazione di tutti i log già importati. Questa opzione rielabora solo i file di log correnti; non rielabora i file già sottoposti a rotazione o i log di altre origini, come una porta TCP. I file di posizione vengono memorizzati nella directory
buffers, ma sono archiviati come file. I buffer locali sono archiviati come sottodirectory nella directorybuffers,Linux
grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f sudo find /var/lib/google-cloud-ops-agent/fluent-bit/buffers -maxdepth 1 -type f -deleteWindows
$oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log"; if (Test-Path $oalogspath) { Select-String "format check failed" $oalogspath | %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} | %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)} }; Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -File -ErrorAction SilentlyContinue | %{$_.Delete()}
Problemi noti
La seguente sezione contiene i problemi comuni noti. Per quelle che sono già corrette o limitate, segui le istruzioni specifiche per scegliere la correzione.
Log non dannosi
Errori di scraping delle metriche da pseudo-processi o processi limitati
I seguenti log non sono dannosi e possono essere ignorati in sicurezza. Per eliminarli, esegui l'upgrade dell'agente operativo alla versione 2.10.0 o successive.
Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:55.848Z error scraperhelper/scrapercontroller.go:205 Error scraping metrics {"kind" : "receiver", "name": "hostmetrics/hostmetrics", "error": "[error reading process name for pid 2: readlink /proc/2/exe: no such file or directory; error reading process name for pid 3: readlink /proc/3/exe: no such file or directory; error reading process name for pid 4: readlink /proc/4/exe: no such file or directory; error reading process name for pid 5: readlink /proc/5/exe: no such file or directory; error reading process name for pid 6: readlink /proc/6/exe: no such file or directory; error reading process name for pid 7: r eadlink /proc/7/exe: no such file or directory; error reading process name for pid 8: readlink /proc/8/exe: no such file or directory; error reading process name for pid 9: readl ink /proc/9/exe: no such file or directory; error reading process name for pid 10: readlink /proc/10/exe: no such file or directory; error reading process name for pid 11: readli nk /proc/11/exe: no such file or directory; error reading process name for pid 12: readlink /proc/12/exe: no such file or directory; error reading process name for pid 13: readli nk /proc/13/exe: no such file or directory; error reading process name for pid 14: readlink /proc/14/exe: no such file or directory; error reading process name for pid 15: readli nk /proc/15/exe: no such file or directory; error reading process name for pid 16: readlink /proc/16/exe: no such file or directory; error reading process name for pid 17: readli nk /proc/17/exe: no such file or directory; error reading process name for pid 18: readlink /proc/18/exe: no such file or directory; error reading process name for pid 19: readli nk /proc/19/exe: no such file or directory; error reading process name for pid 20: readlink /proc/20/exe: no such file or directory; error reading process name for pid 21: readli nk /proc/21/exe: no such file or directory; error reading process name for pid 22: readlink /proc/22/exe: no such file or directory; error reading process name for pid Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 23: readlink /proc/23/exe: no such file or directory; error reading process name for pid 24: readlink /proc/24/exe: no such file or directory; error reading process name for pid 25: readlink /proc/25/exe: no such file or directory; error reading process name for pid 26: readlink /proc/26/exe: no such file or directory; error reading process name for pid 27: readlink /proc/27/exe: no such file or directory; error reading process name for pid 28: readlink /proc/28/exe: no such file or directory; error reading process name for pid 30: readlink /proc/30/exe: no such file or directory; error reading process name for pid 31: readlink /proc/31/exe: no such file or directory; error reading process name for pid 43: readlink /proc/43/exe: no such file or directory; error reading process name for pid 44: readlink /proc/44/exe: no such file or directory; error reading process name for pid 45: readlink /proc/45/exe: no such file or directory; error reading process name for pid 90: readlink /proc/90/exe: no such file or directory; error reading process name for pid 92: readlink /proc/92/exe: no such file or directory; error reading process name for pid 106: readlink /proc/106/exe: no such fi le or directory; error reading process name for pid 360: readlink /proc/360/exe: no such file or directory; error reading process name for pid 375: readlink /proc/375/exe: no suc h file or directory; error reading process name for pid 384: readlink /proc/384/exe: no such file or directory; error reading process name for pid 386: readlink /proc/386/exe: no such file or directory; error reading process name for pid 387: readlink /proc/387/exe: no such file or directory; error reading process name for pid 422: readlink /proc/422/exe : no such file or directory; error reading process name for pid 491: readlink /proc/491/exe: no such file or directory; error reading process name for pid 500: readlink /proc/500 /exe: no such file or directory; error reading process name for pid 2121: readlink /proc/2121/exe: no such file or directory; error reading Jul 13 17:28:55 debian9-trouble otelopscol[2134]: process name for pid 2127: readlink /proc/2127/exe: no such file or directory]"} Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(*controller).scrapeMetricsAndReport Jul 13 17:28:55 debian9-trouble otelopscol[2134]: /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:205 Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(*controller).startScraping.func1 Jul 13 17:28:55 debian9-trouble otelopscol[2134]: /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:186Errori quando il primo punto dati delle metriche cumulative viene eliminato:
I seguenti log non sono dannosi e possono essere ignorati in sicurezza.
Jul 13 17:28:03 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:03.092Z info exporterhelper/queued_retry.go:316 Exporting failed. Will retry the request a fter interval. {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[1].points[0].interval.start_time had a n invalid value of \"2021-07-13T10:25:18.061-07:00\": The start time must be before the end time (2021-07-13T10:25:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag ent/uptime'.", "interval": "23.491024535s"} Jul 13 17:28:41 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:41.269Z info exporterhelper/queued_retry.go:316 Exporting failed. Will retry the request a fter interval. {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[0].points[0].interval.start_time had a n invalid value of \"2021-07-13T10:26:18.061-07:00\": The start time must be before the end time (2021-07-13T10:26:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag ent/monitoring/point_count'.", "interval": "21.556591578s"}
Alcune metriche risultano mancanti o incoerenti
C'è un piccolo numero di metriche che la versione dell'agente Ops 2.0.0 e versioni successive gestisce in modo diverso rispetto alle versioni "anteprima" dell'agente Ops (versioni precedenti alla 2.0.0) o all'agente Monitoring.
La tabella seguente descrive le differenze nei dati importati dall'agente Ops e dall'agente Monitoring.Tipo di metrica, omettiagent.googleapis.com |
Agente operativo (GA)† | Agente Ops (anteprima)† | Agente Monitoring |
|---|---|---|---|
disk/bytes_used edisk/percent_used |
Importazione con il percorso completo nell'etichetta device, ad esempio /dev/sda15.Non importati per dispositivi virtuali come tmpfs e udev. |
Importazione senza /dev nel percorso nell'etichetta device, ad esempio sda15.Importazione per i dispositivi virtuali come tmpfs e udev. |
Importazione senza /dev nel percorso nell'etichetta device, ad esempio sda15.Importazione per i dispositivi virtuali come tmpfs e udev. |
Agente rimosso segnalato da Google Cloud Console come installato
Dopo che hai disinstallato l'agente, la console di Google Cloud potrebbe impiegare fino a un'ora per segnalare questa modifica.
I log self-service dell'agente consumano troppa CPU, memoria e spazio su disco
Le versioni precedenti dell'agente Ops potrebbero consumare molto CPU, memoria e spazio su disco con file /var/log/google-cloud-ops-agent/subagents/logging-module.log sulle VM Linux o file C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log sulle VM Windows a causa di blocchi di buffer danneggiati. In questi casi, vedrai un numero elevato di messaggi, come quelli indicati di seguito, nel file logging-module.log.
[2022/04/30 05:23:38] [error] [input chunk] error writing data from tail.2 instance [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb [2022/04/30 05:23:38] [error] [storage] [cio file] file is not mmap()ed: tail.2:2004860-1650614856.691268293.flb
Per risolvere il problema, esegui l'upgrade dell'agente Ops alla versione 2.17 o successiva e reimposta completamente lo stato dell'agente.
Contatori delle prestazioni danneggiati su Windows
Se l'avvio secondario delle metriche non riesce, potrebbe essere visualizzato uno dei seguenti errori in Cloud Logging:
Failed to retrieve perf counter object "LogicalDisk"
Failed to retrieve perf counter object "Memory"
Failed to retrieve perf counter object "System"
Questi errori possono verificarsi se i contatori delle prestazioni del sistema vengono danneggiati. Puoi risolvere gli errori ricreando i contatori delle prestazioni. In PowerShell come amministratore, esegui:
cd C:\Windows\system32
lodctr /R
A volte il comando precedente può non riuscire; in questo caso ricarica PowerShell e riprova fino a che l'operazione non riesce.
Una volta che il comando ha esito positivo, riavvia l'agente Ops:
Restart-Service -Name google-cloud-ops-agent -Force
I timestamp del log eventi non sono corretti su Windows
I timestamp associati ai log eventi di Windows in Cloud Logging potrebbero non essere corretti, a seconda delle impostazioni del fuso orario del sistema. Se noti questo problema, puoi provare una delle seguenti soluzioni alternative.
Utilizzare un fuso orario UTC
In PowerShell, esegui i comandi seguenti come amministratore:
Set-TimeZone -Id "UTC"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force
Ignora l'impostazione del fuso orario solo per il servizio di agente secondario di logging
In PowerShell, esegui i comandi seguenti come amministratore:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\google-cloud-ops-agent-fluent-bit" -Name "Environment" -Type "MultiString" -Value "TZ=UTC0"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force