Fehlerbehebung bei der Datenaufnahme des Ops-Agents

Dieses Dokument enthält Informationen zum Diagnostizieren und Beheben von Problemen zur Datenaufnahme für Logs und Messwerte im ausgeführten Ops-Agent. Wenn der Ops-Agent nicht ausgeführt wird, finden Sie weitere Informationen unter Fehlerbehebung bei Installation und Start.

Hinweis

Bevor Sie versuchen, ein Problem zu beheben, überprüfen Sie den Status der Systemdiagnosen des Agents.

In der Google Cloud Console wird angezeigt, dass die Installation des Ops-Agents bei „Ausstehend“ hängengeblieben ist

Auch nach der erfolgreichen Installation des Ops-Agents wird in der Google Cloud Console möglicherweise weiterhin der Status „Ausstehend“ angezeigt. Verwenden Sie gcpdiag, um die Installation des Ops-Agents zu bestätigen und zu prüfen, ob der Agent Logs und Messwerte von Ihrer VM-Instanz überträgt.

Häufige Gründe für Installationsfehler

Die Installation des Ops-Agents kann aus folgenden Gründen fehlschlagen:

An die VM ist kein Dienstkonto angehängt. Hängen Sie ein Dienstkonto an die VM an und installieren Sie den Ops-Agent neu.
Auf der VM ist bereits einer der Legacy-Agents installiert, was die Installation des Ops-Agents verhindert. Deinstallieren Sie die alten Agents und installieren Sie den Ops-Agent neu.

Häufige Gründe für Fehler bei der Telemetrieübertragung

Ein installierter und laufender Ops-Agent kann aus den folgenden Gründen keine Protokolle, Messwerte oder beides von einer VM senden:

Dem mit der VM verknüpften Dienstkonto fehlt die Rolle roles/logging.logWriter oder roles/monitoring.metricWriter.
Der Zugriffsbereich für Logging oder Monitoring ist nicht aktiviert. Informationen zum Prüfen und Aktualisieren von Zugriffsbereichen finden Sie unter Zugriffsbereiche überprüfen.
Die Logging API oder die Monitoring API ist nicht aktiviert.

Verwenden Sie Systemdiagnosen für den Kundenservicemitarbeiter, um die Ursache und die entsprechende Lösung zu ermitteln.

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.

Rufen Sie in der Google Cloud Console die Seite Metrics Explorer auf.
Zum Metrics Explorer

Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.
Wählen Sie bei der Ein/Aus-Schaltfläche Builder-Code die Option Code aus und legen Sie dann MQL als Sprache fest.

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?

Wenn der Agent ausgeführt wird, aber keine Protokolle sendet, prüfen Sie den Status der Laufzeit-Systemdiagnosen des Agents.

Pipelinefehler

Wenn Sie den Laufzeitfehler LogPipelineErr (die Logging-Pipeline des Ops-Agents ist fehlgeschlagen) sehen, ist beim Schreiben von Protokollen ein Problem mit dem untergeordneten Logging-Agent aufgetreten. Prüfen Sie Folgendes:

Prüfen Sie, ob auf die Speicherdateien des Logging-Subagents zugegriffen werden kann. Sie finden diese Dateien an den folgenden Speicherorten:
- Linux: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/
- Windows: C:\Program Files\Google\Cloud Operations\Ops Agent\run\buffers\
Prüfen Sie, ob das Laufwerk der VM nicht voll ist.
Prüfen Sie, ob die Logging-Konfiguration korrekt ist.

Für diese Schritte müssen Sie eine SSH-Verbindung zur VM herstellen.

Wenn Sie die Logging-Konfiguration ändern oder auf die Pufferdateien zugegriffen werden kann und das Laufwerk der VM nicht voll ist, starten Sie den Ops-Agenten neu:

Linux

Führen Sie den folgenden Befehl auf der Instanz aus, um den Agent neu zu starten:
```
sudo systemctl restart google-cloud-ops-agent
```
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob der Agent neu gestartet wurde. Prüfen Sie dann, ob die Komponenten „Metrics-Agent“ und „Logging-Agent“ gestartet wurden:
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

Stellen Sie mithilfe von RDP oder einem ähnlichen Tool eine Verbindung zu Ihrer Instanz her und melden Sie sich bei Windows an.
Öffnen Sie ein PowerShell-Terminal mit Administratorberechtigungen. Klicken Sie dazu mit der rechten Maustaste auf das PowerShell-Symbol und wählen Sie Als Administrator ausführen aus.
Führen Sie den folgenden PowerShell-Befehl aus, um den Agent neu zu starten:
```
Restart-Service google-cloud-ops-agent -Force
```
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob der Agent neu gestartet wurde. Prüfen Sie dann, ob die Komponenten „Metrics-Agent“ und „Logging-Agent“ gestartet wurden:
```
Get-Service google-cloud-ops-agent*
```

Fehler beim Log-Parsing

Wenn Sie den Laufzeitfehler LogParseErr (das Parsen der Logs durch den Ops-Agent ist fehlgeschlagen) sehen, ist das wahrscheinlichste Problem die Konfiguration eines Logging-Prozessors. So beheben Sie das Problem:

Prüfen Sie, ob die Konfiguration aller parse_json-Prozessoren korrekt ist.
Prüfen Sie, ob die Konfiguration aller parse_regex-Prozessoren korrekt ist.
Wenn Sie keine parse_json- oder parse_regex-Prozessoren haben, prüfen Sie die Konfiguration aller anderen Logging-Prozessoren.

Für diese Schritte müssen Sie eine SSH-Verbindung zur VM herstellen.

Wenn Sie die Logging-Konfiguration ändern, starten Sie den Ops-Agent neu:

Linux

Führen Sie den folgenden Befehl auf der Instanz aus, um den Agent neu zu starten:
```
sudo systemctl restart google-cloud-ops-agent
```
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob der Agent neu gestartet wurde. Prüfen Sie dann, ob die Komponenten „Metrics-Agent“ und „Logging-Agent“ gestartet wurden:
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

Stellen Sie mithilfe von RDP oder einem ähnlichen Tool eine Verbindung zu Ihrer Instanz her und melden Sie sich bei Windows an.
Öffnen Sie ein PowerShell-Terminal mit Administratorberechtigungen. Klicken Sie dazu mit der rechten Maustaste auf das PowerShell-Symbol und wählen Sie Als Administrator ausführen aus.
Führen Sie den folgenden PowerShell-Befehl aus, um den Agent neu zu starten:
```
Restart-Service google-cloud-ops-agent -Force
```
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob der Agent neu gestartet wurde. Prüfen Sie dann, ob die Komponenten „Metrics-Agent“ und „Logging-Agent“ gestartet wurden:
```
Get-Service google-cloud-ops-agent*
```

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. Wenn keine Logs vorhanden sind, wird der Agent-Dienst nicht ordnungsgemäß ausgeführt. 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.

Probleme mit der Netzwerkverbindung

Wenn der Agent ausgeführt wird, aber weder Logs noch Messwerte gesendet werden, liegt möglicherweise ein Netzwerkproblem vor. Welche Arten von Problemen mit der Netzwerkverbindung auftreten können, hängt von der Topologie Ihrer Anwendung ab. Eine Übersicht über Compute Engine-Netzwerke finden Sie unter Netzwerkübersicht für VMs.

Häufige Ursachen für Verbindungsprobleme sind:

Firewallregeln, die eingehenden Traffic beeinträchtigen. Informationen zu Firewallregeln finden Sie unter VPC-Firewallregeln verwenden.
Probleme in der Konfiguration eines HTTP-Proxys.
DNS-Konfiguration.

Der Ops-Agent führt Systemdiagnosen aus, mit denen Fehler bei der Netzwerkverbindung erkannt werden. In der Dokumentation zu Systemdiagnosen finden Sie Vorschläge für Maßnahmen bei Verbindungsfehlern.

Ab der Ops-Agent-Version 2.28.0 begrenzt der Ops-Agent den Speicherplatzmenge, den er zum Speichern von Pufferblöcken verwenden kann. Der Ops-Agent erstellt Pufferblöcke, wenn Logging-Daten nicht an die Cloud Logging API gesendet werden können. Ohne Limit können diese Chunks den gesamten verfügbaren Speicherplatz belegen und andere Dienste auf der VM unterbrechen. Wenn ein Netzwerkausfall dazu führt, dass Pufferblöcke auf das Laufwerk geschrieben werden, verwendet der Ops-Agent einen plattformspezifischen Menge an Speicherplatz, um die Blöcke zu speichern. Eine Nachricht wie das folgende Beispiel wird auch in /var/log/google-cloud-ops-agent/subagents/logging-module.log auf Linux-VMs oder in C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log auf Windows-VMs angezeigt, wenn die VM keine Pufferblöcke an die Cloud Logging API senden kann:

[2023/04/15 08:21:17] [warn] [engine] failed to flush chunk

Ich möchte nur Messwerte oder Logs, aber nicht beides erfassen

Standardmäßig erfasst der Ops-Agent sowohl Messwerte als auch Logs. Wenn Sie die Erfassung von Messwerten oder Logs deaktivieren möchten, überschreiben Sie mit der Ops-Agent-Datei config.yaml den Standarddienst logging oder metrics, damit die Standardpipeline keine Empfänger hat. Hier finden Sie weitere Informationen:

Das Beenden der Datenaufnahme durch Deaktivieren der Ops-Agent-Sub-Agent-Dienste „Logging-Agent“ oder „Monitoring-Agent“ führt zu einer ungültigen Konfiguration und wird nicht unterstützt.

Messwerte werden erfasst, aber es scheint etwas falsch zu sein

Agent protokolliert Loggingnachrichten „Export fehlgeschlagen. Neuer Versuch.“

Wenn der erste Datenpunkt eines kumulativen Messwerts verworfen wird, werden Logeinträge mit dem Fehler „Export schlägt fehl“ angezeigt. 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"}

Der Agent loggt „TimeSeries konnte nicht geschrieben werden: Punkte müssen in der richtigen Reihenfolge geschrieben werden“-Nachrichten.

Wenn Sie vom alten Monitoring-Agent auf den Ops-Agent umgestellt haben und beim Schreiben kumulativer Messwerte die folgende Fehlermeldung angezeigt wird, starten Sie die VM neu. Der Ops-Agent und der Monitoring-Agent berechnen die Startzeiten für kumulative Messwerte unterschiedlich, was dazu führen kann, dass Punkte nicht in der richtigen Reihenfolge angezeigt werden. Durch einen Neustart der VM wird die Startzeit zurückgesetzt und dieses Problem behoben.

  Jun 2 14:00:06 * otelopscol[4035]: 2023-06-02T14:00:06.304Z#011error#011exporterhelper/queued_retry.go:367#011Exporting failed.
  Try enabling retry_on_failure config option to retry on retryable errors#011{"error": "failed to export time series to GCM: rpc error: code = InvalidArgument desc =
  One or more TimeSeries could not be written: Points must be written in order. One or more of the points specified had an older start time than the most recent point.:
  gce_instance{instance_id:,zone:} timeSeries[0-199]: agent.googleapis.com/memory/bytes_used{state:slab}

Der Agent protokolliert "Token muss ein kurzlebiges Token (60 Minuten) und in einem angemessenen Zeitraum sein"

Wenn beim Schreiben von Messwerten durch den Agent die folgende Fehlermeldung angezeigt wird, bedeutet dies, dass die Systemuhr nicht richtig synchronisiert wurde:

  Invalid JWT: Token must be a short-lived token (60 minutes) and in a
  reasonable timeframe. Check your iat and exp values in the JWT claim.

Informationen zum Synchronisieren von Systemuhren finden Sie unter NTP auf einer VM konfigurieren.

Agent vermerkt im Log „Messwert-Empfänger des Typs 'nvml' wird nicht unterstützt“

Wenn Sie GPU-Messwerte für NVIDIA Management Library (NVML) (agent.googleapis.com/gpu) mit dem nvml-Empfänger erfassen, verwenden Sie eine Version des Ops-Agents mit Vorschauunterstützung für die NVML-Messwerte Unterstützung für diese Messwerte ist ab Version 2.38.0 des Ops-Agents allgemein verfügbar (General Availability). In der GA-Version wurde die vom nvml-Empfänger durchgeführte Messwerterfassung mit dem hostmetrics-Empfänger zusammengeführt und der nvml-Empfänger wurde entfernt.

Sie sehen nach der Installation der Ops-Agent-Version 2.38.0 oder höher die Fehlermeldung „Messwert-Empfänger des Typs 'nvml' wird nicht unterstützt“, wenn Sie den nvml-Vorschauempfänger verwendet und das Standarderfassungsintervall in der benutzerdefinierten Konfigurationsdatei überschrieben haben. Der Fehler tritt auf, weil der nvml-Empfänger nicht mehr vorhanden ist, aber in Ihrer benutzerdefinierten Konfigurationsdatei darauf verwiesen wird.

Um dieses Problem zu beheben, aktualisieren Sie Ihre benutzerdefinierte Konfigurationsdatei, um stattdessen das Erfassungsintervall für den hostmetrics-Empfänger zu überschreiben.

GPU-Messwerte fehlen

Wenn der Ops-Agent einige Messwerte erfasst, aber einige oder alle Messwerte der NVIDIA Management Library (NVML)-GPU (agent.googleapis.com/gpu) fehlen, liegt möglicherweise ein Konfigurationsproblem vor oder es werden keine Prozesse ausgeführt, die die GPU verwenden.

Wenn keine GPU-Messwerte erfasst werden, prüfen Sie den GPU-Treiber. Damit der Ops-Agent GPU-Messwerte erfassen kann, muss der GPU-Treiber auf der VM installiert und konfiguriert sein. So prüfen Sie den Treiber:

Wenn Sie prüfen möchten, ob der Treiber installiert und richtig ausgeführt wird, folgen Sie der Anleitung unter Installation des GPU-Treibers prüfen.

Wenn der Treiber nicht installiert ist, gehen Sie so vor:

Installieren Sie den GPU-Treiber.
Starten Sie den Ops-Agent neu.

Sie müssen den Ops-Agent neu starten, nachdem Sie den GPU-Treiber installiert oder aktualisiert haben.

Prüfen Sie in den Ops-Agent-Protokollen, ob die Kommunikation erfolgreich gestartet wurde. Die Protokollmeldungen sehen in etwa so aus:

Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.771Z        info        nvmlreceiver/client.go:128        Successfully initialized Nvidia Management Library
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:151        Nvidia Management library version is 12.555.42.06
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:157        NVIDIA driver version is 555.42.06
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.781Z        info        nvmlreceiver/client.go:192        Discovered Nvidia device 0 of model NVIDIA L4 with UUID GPU-fc5a05a7-8859-ec33-c940-3cf0930c0e61.

Wenn der GPU-Treiber installiert ist und die Ops-Agent-Protokolle anzeigen, dass der Ops-Agent mit dem Treiber kommuniziert, Sie aber keine GPU-Messwerte sehen, liegt möglicherweise ein Problem mit dem verwendeten Diagramm vor. Informationen zur Fehlerbehebung bei Diagrammen finden Sie unter Diagramm enthält keine Daten.

Wenn Sie einige GPU-Messwerte erfassen, aber die processes-Messwerte processes/max_bytes_used und processes/utilization fehlen, werden keine Prozesse auf GPUs ausgeführt. Die GPU-processes-Messwerte werden nicht erfasst, wenn auf der GPU keine Prozesse ausgeführt werden.

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
`cpu_state`	Die möglichen Werte für Windows sind `idle`, `interrupt,`, , `system` und `user`.	Die möglichen Werte für Windows sind `idle`, `interrupt,`, , `system` und `user`.	Die möglichen Werte für Windows sind `idle` und `used`.
`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.

Windows-spezifische Probleme

Die folgenden Abschnitte gelten nur für den Ops-Agent, der unter Windows ausgeführt wird.

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

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 Selbstlogs 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/*/

Hinweis: Das Verzeichnis /var/lib/google-cloud-ops-agent/fluent-bit/buffers/ enthält die folgenden Dateitypen::

Zwischenspeicherdateien: Diese Dateien sind gepufferte Logeinträge, die vom Ops-Agent verfolgt und verarbeitet, aber noch nicht in Cloud Logging aufgenommen wurden. Wenn beschädigte Blöcke vorhanden sind, sollten sie vom Ops-Agent in Versionen ab oder gleich 2.15.0 übersprungen werden. In einigen Fällen müssen sie jedoch manuell bereinigt werden. Diese Dateien werden in den verschachtelten Ordnern wie diesen gespeichert: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/*
Dateien zur Tailing-Position von Logdateien: Diese Dateien zeichnen auf, wo der Ops-Agent bereits in den Logdateien gebunden ist. Wenn diese Dateien entfernt werden, beginnt der Ops-Agent von den Dateien, die für die Verfolgung konfiguriert sind. Das Löschen dieser Dateien kann zu einer Logduplizierung führen, wenn diese Logs zuvor erfolgreich aufgenommen wurden. Diese Dateien werden direkt im Verzeichnis als Dateien wie /var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog* gespeichert.

Die Syntax .../buffers/*/ im vorherigen Befehl sorgt dafür, dass nur die Zwischenspeicherdateien gelöscht werden. Die Positionsdateien werden nicht gelöscht.

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 Selbstlogs 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. Im Folgenden werden verschiedene Möglichkeiten für den Umgang mit den Zwischenspeichern 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 Zwischenspeicherverzeichnisse 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. Bei dieser Option werden nur aktuelle Logdateien noch einmal verarbeitet. Dateien, die bereits rotiert wurden, oder Logs aus anderen Quellen wie ein 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 in neueren Ops-Agent-Releases

In den folgenden Abschnitten werden Probleme beschrieben, die bei neueren Ops-Agent-Releases bekannt sind.

Absturzschleife bei Ops-Agent-Version 2.47.0, 2.48.0 oder 2.49.0

Die Versionen 2.47.0, 2.48.0 und 2.49.0 enthielten eine fehlerhafte FluentBit-Komponente für das Logging. Diese Komponente schlägt bei bestimmten Protokollzeilen fehl und führt dazu, dass der Ops-Agent in einen Crash-Loop gerät.

Dieses Problem wurde in Version 2.50.0 des Ops-Agenten behoben.

Der Prometheus-Messwert-Namespace enthält ab der Ops-Agent-Version 2.46.0 zusätzlich zum Instanznamen die Instanz-ID.

Ab Version 2.46.0 fügt der Ops-Agent den Namen der VM als Teil des namespace-Labels hinzu, wenn Messwerte im Prometheus-Aufnahmeformat aufgenommen werden. In früheren Versionen wurde in Prometheus-Messwerten nur die Instanz-ID der VM als Teil des namespace-Labels verwendet. Ab Version 2.46.0 ist namespace auf INSTANCE_ID/INSTANCE_NAME festgelegt.

Wenn Sie Diagramme, Dashboards oder Benachrichtigungsrichtlinien mit dem Label namespace verwenden, müssen Sie Ihre Abfragen möglicherweise aktualisieren, nachdem Sie Ihren Ops-Agent auf Version 2.46.0 oder höher aktualisiert haben. Wenn Ihre PromQL-Abfrage beispielsweise so lautet: http_requests_total{namespace="123456789"}, müssen Sie sie in http_requests_total{namespace=~"123456789.*"} ändern, da das Label namespace das Format INSTANCE_ID/INSTANCE_NAME hat.

Der Messwerttyp von nicht typisierten Prometheus-Messwerten ändert sich ab der Ops-Agent-Version 2.39.0

Ab Version 2.39.0 unterstützt der Ops-Agent die Aufnahme von Prometheus-Messwerten mit unbekannten Typen. In früheren Versionen werden diese Messwerte vom Ops-Agent als Messwerte behandelt. Ab Version 2.39.0 werden nicht typisierte Messwerte sowohl als Messwerte als auch als Zähler behandelt. Nutzer können jetzt kumulative Vorgänge auf diese Messwerte anwenden.

Wenn Sie Diagramme, Dashboards oder Benachrichtigungsrichtlinien haben, die MQL zum Abfragen nicht typisierter Prometheus-Messwerte verwenden, müssen Sie Ihre MQL-Abfragen aktualisieren, nachdem Sie Ihren Ops-Agent auf Version 2.39.0 oder höher aktualisiert haben. Anstatt nicht typisierte Messwerte als prometheus.googleapis.com/METRIC_NAME/gauge abzufragen, ändern Sie die Messwerttypen so:

Verwenden Sie prometheus.googleapis.com/METRIC_NAME/unknown für die Messgeräteversion des Messwerts.
Verwenden Sie prometheus.googleapis.com/METRIC_NAME/unknown:counter für die Zählerversion des Messwerts.

Sie müssen keine Änderungen an Diagrammen, Dashboards oder Benachrichtigungsrichtlinien vornehmen, die PromQL zum Abfragen nicht typisierter Prometheus-Messwerte verwenden. Sie können jedoch kumulative Vorgänge auf diese Messwerte anwenden, nachdem Sie Ihren Ops-Agent auf die Version 2.39.0 oder höher aktualisieren.

Hohe Arbeitsspeicherauslastung bei Windows-VMs (Versionen 2.27.0 bis 2.29.0)

Unter Windows in den Ops-Agent-Versionen 2.27.0 bis 2.29.0 führte ein Fehler, der den Agent dazu führte, dass er manchmal Sockets verschleiert hat, was zu einer erhöhten Arbeitsspeichernutzung und einer hohen Anzahl von Handles des Prozesses fluent-bit.exe führte.

So beheben Sie das Problem:Ops-Agent upgraden auf Version 2.30.0 oder höher und starten Sie den Agent neu.

Ereignisprotokoll-Zeitzonen sind unter Windows falsch (Version 2.15.0 bis 2.26.0)

Die mit Windows-Ereignislogs in Cloud Logging verknüpften Zeitstempel sind möglicherweise falsch, wenn Sie die Zeitzone Ihrer VM von UTC ändern. Dieses Problem wurde im Ops-Agent 2.27.0 behoben. Aufgrund des bekannten Problems mit Windows-Speicher mit hohem Arbeitsspeicher empfehlen wir jedoch ein Upgrade auf Ops-Agent 2.30.0 oder höher, wenn Sie dieses Problem haben. Wenn Sie kein Upgrade durchführen können, 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

Geparste Zeitstempel unter Windows haben eine falsche Zeitzone (beliebige Version vor 2.27.0)

Wenn Sie einen Logprozessor verwenden, der einen Zeitstempel parst, wird der Zeitzonenwert unter Windows nicht richtig geparst. Dieses Problem wurde im Ops-Agent 2.27.0 behoben. Aufgrund des bekannten Problems mit Windows-Speicher mit hohem Arbeitsspeicher empfehlen wir jedoch ein Upgrade auf Ops-Agent 2.30.0 oder höher, wenn Sie dieses Problem haben.

Bekannte Probleme in älteren Ops-Agent-Releases

In den folgenden Abschnitten werden Probleme beschrieben, die bei älteren Ops-Agent-Releases bekannt sind.

Nicht schädliche Logs (Version 2.9.1 und niedriger)

Beim Scraping von Messwerten aus Pseudoprozessen oder eingeschränkten Prozessen können Fehler auftreten. 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 diese Nachrichten 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

Agent-Self-Logs belegen zu viel CPU, Arbeitsspeicher und Speicherplatz (Version 2.16.0 und niedriger)

Versionen des Ops-Agents vor 2.17.0 verbrauchen möglicherweise viel CPU, Arbeitsspeicher und Speicherplatz 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.0 oder höher undAgent-Status vollständig zurücksetzen.

Wenn Ihr System immer noch ein großes Volumen an Agent-Self-Logs generiert, sollten Sie die Protokollwechsel verwenden. Weitere Informationen finden Sie unter Protokollwechsel einrichten.