Ops-Agent – Fehlerbehebung

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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:

    1. Speichern Sie die benutzerdefinierten Konfigurationsdateien für den Cloud Monitoring-Agent und den Cloud Logging-Agent.

    2. 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:

    1. Deaktivieren Sie den in Konflikt stehenden Abschnitt der Ops-Agent-Konfigurationsdatei. Weitere Informationen finden Sie in der Anleitung Ops-Agent konfigurieren.

    2. Deaktivieren Sie den in Konflikt stehenden Cloud Logging-Agent oder Cloud Monitoring-Agent.

      1. Speichern Sie alle benutzerdefinierten Konfigurationsdateien für den Cloud Logging-Agent.
      2. 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.

  1. Wählen Sie in der Google Cloud Console Monitoring aus oder klicken Sie auf die folgende Schaltfläche:

    Zu Monitoring

  2. Wählen Sie im Navigationsbereich Metrics Explorer aus.

  3. Wählen Sie den Tab MQL aus.

  4. 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.

  1. Installieren Sie das Dienstprogramm logrotate mit dem folgenden Befehl:

    Unter Debian und Ubuntu

    sudo apt install logrotate
    

    Mit CentOS, RHEL und Fedora

    sudo yum install logrotate
    
  2. Erstellen Sie unter /etc/logrotate.d/google-cloud-ops-agent.conf eine logrotate-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
    }
    EOF
    
  3. Richten Sie crontab oder systemd timer ein, um das Dienstprogramm logrotate regelmäß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:

  1. Verringern Sie vorübergehend die Dateigröße, bei der die Rotation ausgelöst wird. Setzen Sie dazu den Wert maxsize in der Datei /etc/logrotate.d/google-cloud-ops-agent.conf auf 1k.

  2. 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 restart
    
  3. Warten Sie, bis crontab oder systemd timer wirksam wurde, um das Dienstprogramm logrotate auszulösen, oder lösen Sie das Dienstprogramm logrotate manuell aus. Führen Sie dazu diesen Befehl aus:

    sudo logrotate /etc/logrotate.d/google-cloud-ops-agent.conf
    
  4. Prüfen Sie, ob im Verzeichnis /var/log/google-cloud-ops-agent/subagents/ rotierte Logdateien angezeigt werden.

  5. 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/buffers
    

    Windows

    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 -f
    

    Windows

    $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 buffers gespeichert, aber als Dateien. Die lokalen Zwischenspeicher werden als Unterverzeichnisse im Verzeichnis buffers gespeichert.

    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 -delete
    

    Windows

    $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:186
    
  • Fehler, 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 und
disk/percent_used
Mit dem vollständigen Pfad im Label device aufgenommen, z. B. /dev/sda15

Nicht 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.
Die Spalte GA bezieht sich auf Ops-Agent-Versionen ab 2.0.0. Die Spalte Vorschau bezieht sich auf Ops-Agent-Versionen vor 2.0.0.

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