Hinweis: Die localhost:2020/api/v1/metrics bei 3:18 in diesem Video erwähnte Endpunkt ist im Ops-Agent nicht mehr verfügbar. Weitere Optionen finden Sie unter Agent wird ausgeführt, Daten werden jedoch nicht aufgenommen.
Dieses Dokument erleichtert Ihnen die Diagnose von Fehlern, die bei der Installation oder beim Ausführen des Ops-Agents auftreten können.
Agent-Diagnosetool für VMs
Das Agent-Diagnosetool erfasst wichtige lokale Debugging-Informationen von Ihren VMs für alle folgenden Agents: Ops-Agent, Legacy-Logging-Agent und Legacy-Monitoring-Agent. Die Debugging-Informationen umfassen Informationen wie Projektinformationen, VM-Informationen, Agent-Konfiguration, Agent-Logs, Agent-Dienststatus und Informationen, die normalerweise manuell erfasst werden müssen. Das Tool prüft auch die lokale VM-Umgebung, um sicherzustellen, dass sie bestimmte Anforderungen erfüllt, damit die Agents ordnungsgemäß funktionieren, z. B. Netzwerkverbindung und erforderliche Berechtigungen.
Wenn Sie einen Kundenfall für einen Agent auf einer VM einreichen, führen Sie das Agent-Diagnosetool aus und hängen Sie die erfassten Informationen an den Fall an. Bevor Sie die Informationen an den Supportfall anhängen, entfernen Sie alle vertraulichen Informationen wie Passwörter. Durch die Bereitstellung dieser Informationen reduziert sich der Zeitaufwand für die Fehlerbehebung in Ihrem Supportfall.
Das Agent-Diagnosetool muss innerhalb der VM ausgeführt werden. Daher müssen Sie in der Regel zuerst eine SSH-Verbindung zur VM herstellen. Mit dem folgenden Befehl wird das Agent-Diagnosetool abgerufen und ausgeführt:
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"
Folgen Sie der Ausgabe der Skriptausführung, um die Dateien zu finden, die die erfassten Informationen enthalten. In der Regel finden Sie diese im Verzeichnis /var/tmp/google-agents unter Linux und im Verzeichnis $env:LOCALAPPDATA/Temp unter Windows, es sei denn, Sie haben das Ausgabeverzeichnis beim Ausführen des Skripts angepasst.
Ausführliche Informationen finden Sie im Skript diagnose-agents.sh unter Linux oder im Skript diagnose-agents.ps1 unter Windows.
Agent kann nicht installiert werden
Beim Ausführen des Installationsskripts können die folgenden Fehler auftreten.
Das Betriebssystem wird nicht unterstützt. Die Fehlermeldung sieht in etwa so aus:
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
Auf der VM ist der Cloud Logging-Agent oder der Cloud Monitoring-Agent bereits installiert. Dieser steht in Konflikt mit dem neuen Agent. Die Fehlermeldung sieht in etwa so aus:
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
Der Ops-Agent verwendet neue Konfigurationsdateien, die nicht mit den alten Agents kompatibel sind. Weitere Informationen finden Sie in der Anleitung Ops-Agent konfigurieren.
So beheben Sie diesen Fehler:
Speichern Sie die benutzerdefinierten Konfigurationsdateien für den Cloud Monitoring-Agent und den Cloud Logging-Agent.
Deinstallieren Sie anschließend den alten Cloud Monitoring-Agent und den alten Cloud Logging-Agent.
Nachdem Sie den Agent deinstalliert haben, kann es bis zu eine Stunde dauern, bis diese Änderung in der Google Cloud Console gemeldet wird.
Agent ist installiert, wird aber nicht ausgeführt
Agent-Dienste werden nicht ausgeführt
Wenn der Agent-Dienst wie erwartet ausgeführt wird, sehen Sie möglicherweise den folgenden Status:
Für 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"}
Für 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
Wird der Agent-Dienst nicht ausgeführt, wird möglicherweise der folgende Status angezeigt:
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
Führen Sie zum Starten des Dienstes den folgenden Befehl aus, um diesen Fehler zu beheben:
Linux
sudo service google-cloud-ops-agent start
Windows
Start-Service google-cloud-ops-agent
Wenn der Dienst nicht gestartet werden kann, ist die Konfiguration möglicherweise ungültig.
Konflikt mit derzeit installierten Agents
Auf der VM ist der Cloud Logging-Agent oder der Cloud Monitoring-Agent bereits installiert und es tritt ein Konflikt zwischen dieser Konfiguration und der Konfiguration des neuen Agents auf. Die Fehlermeldung sieht in etwa so aus:
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.
Sie haben zwei Möglichkeiten, diesen Fehler zu beheben:
Deaktivieren Sie den in Konflikt stehenden Abschnitt der Ops-Agent-Konfigurationsdatei. Weitere Informationen finden Sie in der Anleitung Ops-Agent konfigurieren.
Deaktivieren Sie den in Konflikt stehenden Cloud Logging-Agent oder Cloud Monitoring-Agent.
- Speichern Sie alle benutzerdefinierten Konfigurationsdateien für den Cloud Logging-Agent.
- Deinstallieren Sie anschließend den alten Cloud Monitoring-Agent und den alten Cloud Logging-Agent.
Nachdem Sie den Agent deinstalliert haben, kann es bis zu eine Stunde dauern, bis diese Änderung in der Google Cloud Console gemeldet wird.
Ungültige Konfiguration
Ist die Konfiguration ungültig, wird beim Neustart des Agent-Dienstes möglicherweise der folgende Fehler angezeigt:
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.
Mit journalctl erhalten Sie die genaue Fehlermeldung:
sudo journalctl -xe | grep "google_cloud_ops_agent_engine"
Es kann eine Meldung ähnlich der folgenden angezeigt werden:
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 ':'
Korrigieren die ungültige Konfiguration und starten Sie den Agent neu, um diesen Fehler zu beheben. Weitere Informationen finden Sie in der Anleitung Ops-Agent konfigurieren.
Agent wird ausgeführt, Daten werden jedoch nicht aufgenommen
Verwenden Sie Metrics Explorer, um den Messwert uptime des Agents abzufragen, und prüfen Sie, ob die Agent-Komponente google-cloud-ops-agent-metrics oder google-cloud-ops-agent-logging in den Messwert schreibt.
Wählen Sie in der Google Cloud Console Monitoring aus oder klicken Sie auf die folgende Schaltfläche:
Wählen Sie im Navigationsbereich
Metrics Explorer aus.Wählen Sie den Tab MQL aus.
Geben Sie die folgende Abfrage ein und klicken Sie auf Ausführen:
fetch gce_instance | metric 'agent.googleapis.com/agent/uptime' | align rate(1m) | every 1m
Sendet der Agent Logs an Cloud Logging?
Lokale Messwerte prüfen
Für diese Schritte müssen Sie eine SSH-Verbindung zur VM herstellen.
- Wird das Logging-Modul ausgeführt? Prüfen Sie mit den folgenden Befehlen:
Linux
sudo systemctl status google-cloud-ops-agent"*"
Windows
Öffnen Sie Windows PowerShell als Administrator und führen Sie folgenden Befehl aus:
Get-Service google-cloud-ops-agent
Sie können auch den Dienststatus in der Services-App und die laufenden Prozesse in der Task Manager-App prüfen.
Logging-Modullog prüfen
Für diesen Schritt müssen Sie eine SSH-Verbindung zur VM herstellen.
Die Logging-Modullogs finden Sie unter /var/log/google-cloud-ops-agent/subagents/*.log für Linux und C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log für Windows. Falls keine Logs vorhanden sind, deutet dies darauf hin, dass der Agent-Dienst nicht ordnungsgemäß ausgeführt wird. Wechseln Sie zuerst zum Abschnitt Agent ist installiert, wird aber nicht ausgeführt, um diesen Zustand zu korrigieren.
Wenn Sie in die Logging API schreiben, wird möglicherweise der Berechtigungsfehler 403 angezeigt. Beispiel:
[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" } ] } ] } }Aktivieren Sie die Logging API und legen Sie die Rolle Logautor fest, um diesen Fehler zu beheben.
Möglicherweise wird ein Kontingentproblem für die Logging API angezeigt. Beispiel:
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"
Erhöhen Sie das Kontingent oder reduzieren Sie den Logdurchsatz, um diesen Fehler zu beheben.
Im Log des Moduls werden möglicherweise die folgenden Fehler angezeigt:
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}oder
can't fetch token from the metadata server
Diese Fehler können darauf hinweisen, dass Sie den Agent ohne Dienstkonto oder mit angegebenen Anmeldedaten bereitgestellt haben. Informationen zum Beheben dieses Problems finden Sie unter Ops-Agent autorisieren.
Sendet der Agent Messwerte an Cloud Monitoring?
Log des Messwertmoduls prüfen
Für diesen Schritt müssen Sie eine SSH-Verbindung zur VM herstellen.
Die Logs des Messwertmoduls finden Sie in syslog. Falls keine Logs vorhanden sind, deutet dies darauf hin, dass der Agent-Dienst nicht ordnungsgemäß ausgeführt wird. Wechseln Sie zuerst zum Abschnitt Agent ist installiert, wird aber nicht ausgeführt, um diesen Zustand zu korrigieren.
Beim Schreiben in die Monitoring API werden möglicherweise
PermissionDenied-Fehler angezeigt. Dieser Fehler tritt auf, wenn die Berechtigung für den Ops-Agent nicht richtig konfiguriert wurde. Beispiel: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"}Aktivieren Sie die Monitoring API und legen Sie die Rolle Monitoring-Messwert-Autor fest, um diesen Fehler zu beheben.
Beim Schreiben in die Monitoring API werden möglicherweise
ResourceExhausted-Fehler angezeigt. Dieser Fehler tritt auf, wenn das Projekt das Limit für Monitoring API-Kontingente erreicht. Beispiel: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"}Erhöhen Sie das Kontingent oder reduzieren Sie den Messwertdurchsatz, um diesen Fehler zu beheben.
Im Log des Moduls werden möglicherweise die folgenden Fehler angezeigt:
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}oder
can't fetch token from the metadata server
Diese Fehler können darauf hinweisen, dass Sie den Agent ohne Dienstkonto oder mit angegebenen Anmeldedaten bereitgestellt haben. Informationen zum Beheben dieses Problems finden Sie unter Ops-Agent autorisieren.
Self-logs des Agents prüfen
Wenn der Agent keine Logs in Cloud Logging aufnimmt, müssen Sie möglicherweise die Logs lokal auf der VM zur Fehlerbehebung prüfen.
Linux
Führen Sie den folgenden Befehl aus, um in Journald geschriebene self-Logs zu prüfen:
journalctl -u google-cloud-ops-agent*
Führen Sie den folgenden Befehl aus, um die Self-logs zu prüfen, die vom Logging-Modul auf das Laufwerk geschrieben werden:
vim /var/log/google-cloud-ops-agent/subagents/logging-module.log
Windows
Führen Sie den folgenden Befehl aus, um in Windows Event Logs geschriebene self-Logs zu prüfen:
Get-WinEvent -FilterHashtable @{ Logname='Application'; ProviderName='google-cloud-ops-agent*' } | Format-Table -AutoSize -Wrap
Führen Sie den folgenden Befehl aus, um die Self-logs zu prüfen, die vom Logging-Modul auf das Laufwerk geschrieben werden:
notepad "C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log"
Führen Sie den folgenden Befehl aus, um die Logs des Windows Service Control Manager für Ops-Agent-Dienste zu prüfen:
Get-WinEvent -FilterHashtable @{ Logname='System'; ProviderName='Service Control Manager' } | Where-Object -Property Message -Match 'Google Cloud Ops Agent' | Format-Table -AutoSize -Wrap
Rotation von Self-Logdateien auf Linux-VMs einrichten
Installieren und konfigurieren Sie das Dienstprogramm logrotate, um die Größe des Logging-Sub-Agent-Logs unter /var/log/google-cloud-ops-agent/subagents/logging-module.log zu begrenzen.
Installieren Sie das Dienstprogramm
logrotatemit dem folgenden Befehl:Unter Debian und Ubuntu
sudo apt install logrotateMit CentOS, RHEL und Fedora
sudo yum install logrotateErstellen Sie unter
/etc/logrotate.d/google-cloud-ops-agent.confeinelogrotate-Konfigurationsdatei.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 } EOFRichten Sie
crontabodersystemd timerein, um das Dienstprogrammlogrotateregelmäßig auszulösen.
Nachdem die Logrotation wirksam wurde, werden im Verzeichnis /var/log/google-cloud-ops-agent/subagents/ rotierte Dateien angezeigt. Die Ergebnisse sehen in etwa so aus:
/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
So testen Sie die Logrotation:
Verringern Sie vorübergehend die Dateigröße, bei der die Rotation ausgelöst wird. Setzen Sie dazu den Wert
maxsizein der Datei/etc/logrotate.d/google-cloud-ops-agent.confauf1k.Lösen Sie die Selbstlogdatei des Agents auf einen Wert größer als 1 KB aus, indem Sie den Agent mehrmals neu starten:
sudo service google-cloud-ops-agent restartWarten Sie, bis
crontabodersystemd timerwirksam wurde, um das Dienstprogrammlogrotateauszulösen, oder lösen Sie das Dienstprogrammlogrotatemanuell aus. Führen Sie dazu diesen Befehl aus:sudo logrotate /etc/logrotate.d/google-cloud-ops-agent.confPrüfen Sie, ob im Verzeichnis
/var/log/google-cloud-ops-agent/subagents/rotierte Logdateien angezeigt werden.Setzen Sie die Logrotation-Konfiguration zurück, indem Sie den ursprünglichen
maxsize-Wert wiederherstellen.
Agent-Zustand vollständig zurücksetzen
Wenn der Agent in einen Zustand wechselt, aus dem er nicht wiederhergestellt werden kann, führen Sie die folgenden Schritte aus, um den Agent in einen neuen Zustand zurückzusetzen.
Linux
Beenden Sie den Agent-Dienst:
sudo service google-cloud-ops-agent stop
Entfernen Sie das Agent-Paket:
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
Entfernen Sie die Selflogs des Agents auf dem Laufwerk:
sudo rm -rf /var/log/google-cloud-ops-agent
Entfernen Sie die lokalen Zwischenspeicher des Agents auf dem Laufwerk:
sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers/*/
Installieren Sie den Agent neu und starten Sie ihn neu:
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
Beenden Sie den Agent-Dienst:
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*";
Entfernen Sie das Agent-Paket:
(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"
Entfernen Sie die Selflogs des Agents auf dem Laufwerk:
rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\log";
Entfernen Sie die lokalen Zwischenspeicher des Agents auf dem Laufwerk:
Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -Directory -ErrorAction SilentlyContinue | %{rm -r -Path $_.FullName}
Installieren Sie den Agent neu und starten Sie ihn neu:
(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"
Zurücksetzen, aber Zwischenspeicherdateien speichern
Wenn die VM keine beschädigten Zwischenspeicherblöcke hat (d. h. in der self-log-datei des Ops-Agents sind keine format
check failed-Nachrichten vorhanden), können Sie die vorherigen Befehle überspringen, die die lokalen Zwischenspeicher beim Zurücksetzen des Agent-Status entfernen.
Wenn die VM beschädigte Pufferblöcke hat, müssen Sie diese entfernen. In den folgenden Optionen werden verschiedene Möglichkeiten zum Verarbeiten der Zwischenspeicher beschrieben. Die anderen Schritte, die unter Agent-Zustand vollständig zurücksetzen beschrieben werden, gelten weiterhin.
Option 1: Löschen Sie das gesamte Verzeichnis
buffers. Dies ist die einfachste Option, kann aber aufgrund des Verlusts der Positionsdateien zu einem Verlust der unbeschädigten zwischengespeicherten Logs oder zu Logduplizierung führen.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";Option 2: Löschen Sie die Pufferunterverzeichnisse aus dem Verzeichnis
buffers, aber behalten Sie die Positionsdateien bei. Dieser Ansatz wird unter Agent-Zustand vollständig zurücksetzen beschrieben.Option 3: Wenn Sie nicht alle Zwischenspeicherdateien löschen möchten, können Sie die Namen der beschädigten Zwischenspeicherdateien aus den Selflogs des Agents extrahieren und nur beschädigten Zwischenspeicherdateien löschen.
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\' + $_)} };Option 4: Wenn es viele beschädigte Zwischenspeicher gibt und Sie alle Logdateien erneut verarbeiten möchten, können Sie die Befehle aus Option 3 verwenden und auch die Positionsdateien löschen (die den Fortschritt des Ops-Agent pro Logdatei speichern). Das Löschen der Positionsdateien kann zu einer Logduplizierung für alle Logs führen, die bereits erfolgreich aufgenommen wurden. Mit dieser Option werden nur aktuelle Log-Dateien noch einmal verarbeitet. Dateien, die bereits rotiert wurden, oder Logs aus anderen Quellen wie einem TCP-Port werden nicht noch einmal verarbeitet. Die Positionsdateien werden im Verzeichnis
buffersgespeichert, aber als Dateien. Die lokalen Zwischenspeicher werden als Unterverzeichnisse im Verzeichnisbuffersgespeichert.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()}
Bekannte Probleme
Der folgende Abschnitt enthält bekannte häufige Probleme. Für die bereits behobenen oder entschärften Probleme befolgen Sie die entsprechenden Anweisungen, um das Problem zu beheben.
Nicht schädliche Logs
Fehler beim Scraping von Messwerten aus Pseudoprozessen oder eingeschränkten Prozessen
Die folgenden Logs sind nicht schädlich und können ignoriert werden. Aktualisieren Sie den Ops-Agent auf Version 2.10.0 oder höher, um sie zu entfernen.
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:186Fehler, wenn der erste Datenpunkt kumulativer Messwerte ignoriert wird:
Die folgenden Logs sind nicht schädlich und können ignoriert werden.
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"}
Einige Messwerte fehlen oder sind inkonsistent
Es gibt eine kleine Anzahl von Messwerten, die die Ops-Agent-Version 2.0.0 und höher anders verarbeitet als die "Vorschau"-Versionen des Ops-Agents (Versionen älter als 2.0.0) oder des Monitoring-Agents.
In der folgenden Tabelle werden die Unterschiede zwischen den Daten beschrieben, die vom Ops-Agent und dem Monitoring-Agent aufgenommen werden.Messwerttyp, agent.googleapis.com weglassen |
Ops-Agent (GA)† | Ops-Agent (Vorschau)† | Monitoring-Agent |
|---|---|---|---|
disk/bytes_used unddisk/percent_used |
Mit dem vollständigen Pfad im Label device aufgenommen, z. B. /dev/sda15Nicht für virtuelle Geräte wie tmpfs und udev aufgenommen. |
Aufgenommen ohne /dev im Pfad im
device-Label; Beispiel: sda15.Für virtuelle Geräte wie tmpfs und udev aufgenommen. |
Aufgenommen ohne /dev im Pfad im
device-Label; Beispiel: sda15.Für virtuelle Geräte wie tmpfs und udev aufgenommen. |
Entfernter Agent von der Google Cloud Console als installiert gemeldet
Nachdem Sie den Agent deinstalliert haben, kann es bis zu eine Stunde dauern, bis diese Änderung in der Google Cloud Console gemeldet wird.
Agent-Self-Logs verbrauchen zu viel CPU, Arbeitsspeicher und Speicherplatz
Alte Versionen des Ops Agent verbrauchen möglicherweise viel CPU, Arbeitsspeicher und Laufwerksplatz mit /var/log/google-cloud-ops-agent/subagents/logging-module.log-Dateien auf Linux-VMs oder C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log-Dateien auf Windows-VMs aufgrund von beschädigten Pufferblöcken. In diesem Fall sehen Sie in der Datei logging-module.log eine große Anzahl von Nachrichten wie die folgenden.
[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
So beheben Sie das Problem:Ops-Agent upgraden auf Version 2.17 oder höher undAgent-Status vollständig zurücksetzen.
Beschädigte Leistungszähler unter Windows
Wenn der Sub-Agent für Messwerte nicht gestartet wird, wird möglicherweise einer der folgenden Fehler in Cloud Logging angezeigt:
Failed to retrieve perf counter object "LogicalDisk"
Failed to retrieve perf counter object "Memory"
Failed to retrieve perf counter object "System"
Diese Fehler können auftreten, wenn die Leistungszähler Ihres Systems beschädigt sind. Sie können die Fehler beheben, indem Sie die Leistungszähler neu erstellen. Führen Sie in PowerShell als Administrator folgenden Befehl aus:
cd C:\Windows\system32
lodctr /R
Der vorherige Befehl kann gelegentlich fehlschlagen. Laden Sie in diesem Fall PowerShell neu und versuchen Sie es noch einmal, bis der Befehl erfolgreich ist.
Nachdem der Befehl erfolgreich ausgeführt wurde, starten Sie den Ops-Agent neu:
Restart-Service -Name google-cloud-ops-agent -Force
Zeitstempel von Ereignislogs sind unter Windows falsch
Die mit Windows-Ereignislogs in Cloud Logging verknüpften Zeitstempel sind möglicherweise je nach den Zeitzoneneinstellungen Ihres Systems falsch. Wenn Sie dies feststellen, können Sie eine der folgenden Problemumgehungen ausprobieren.
UTC-Zeitzone verwenden
Führen Sie in PowerShell die folgenden Befehle als Administrator aus:
Set-TimeZone -Id "UTC"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force
Zeitzoneneinstellung nur für den Logging-Sub-Agent-Dienst überschreiben
Führen Sie in PowerShell die folgenden Befehle als Administrator aus:
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