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 ein Problem beheben, überprüfen Sie den Status der Systemdiagnosen des Agents.

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 im Navigationsbereich der Google Cloud Console Monitoring und anschließend Metrics Explorer aus:
Zum Metrics Explorer
Wählen Sie in der Ein-/Aus-Schaltfläche Builder Code die Option Code aus und legen Sie die Sprache auf MQL 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 Logs sendet, prüfen Sie den Status der Systemdiagnosen des Agents.

Pipelinefehler

Wenn Sie den Laufzeitfehler LogPipelineErr (die Logging-Pipeline des Ops-Agents ist fehlgeschlagen) sehen, ist beim Logging-Subagent ein Problem beim Schreiben von Logs aufgetreten. Prüfen Sie folgende Bedingungen:

Prüfen Sie, ob auf die Speicherdateien des Logging-Subagenten zugegriffen werden kann. Diese Dateien befinden sich 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 wenn auf die Zwischenspeicherdateien zugegriffen werden kann und das Laufwerk der VM nicht voll ist, 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*
```

Log-Parsing-Fehler

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 eines beliebigen parse_json-Prozessors korrekt ist.
Prüfen Sie, ob die Konfiguration eines beliebigen parse_regex-Prozessors 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, die Netzwerkverbindungsfehler erkennen. Informationen zu den vorgeschlagenen Aktionen bei Verbindungsfehlern finden Sie in der Dokumentation zu Systemdiagnosen.

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 keine Logging-Daten an die Cloud Logging API gesendet werden können. Ohne Limit verbrauchen diese Blöcke möglicherweise den gesamten verfügbaren Speicherplatz, sodass andere Dienste auf der VM unterbrochen werden. 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 Legacy-Monitoring-Agent ein Upgrade auf den Ops-Agent durchgeführt haben und beim Schreiben kumulativer Messwerte die folgende Fehlermeldung sehen, ist die Lösung ein Neustart der VM. Der Ops- und der Monitoring-Agent berechnen die Startzeiten für kumulative Messwerte unterschiedlich, was dazu führen kann, dass Punkte in der falschen 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.

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 aktuellen Ops-Agent-Releases bekannt sind.

Der Namespace der Prometheus-Messwerte enthält neben der Instanz-ID ab Ops-Agent-Version 2.46.0 auch den Instanznamen.

Ab Version 2.46.0 enthält der Ops-Agent den VM-Namen als Teil des namespace-Labels, wenn Messwerte im Prometheus-Aufnahmeformat aufgenommen werden. In früheren Versionen verwendeten Prometheus-Messwerte nur die Instanz-ID der VM als Teil des Labels namespace.Ab Version 2.46.0 ist namespace jedoch auf INSTANCE_ID/INSTANCE_NAME

Wenn Sie Diagramme, Dashboards oder Benachrichtigungsrichtlinien haben, die das Label namespace verwenden, müssen Sie möglicherweise Ihre Abfragen nach dem Upgrade Ihres Ops-Agents auf Version 2.46.0 oder höher aktualisieren. Wenn Ihre PromQL-Abfrage beispielsweise so aussieht: 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. “

Prometheus-Messwerte ohne Typ ändern den Messwerttyp ab 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 Messgerätanzeigen behandelt. Ab Version 2.39.0 werden Messwerte ohne Typ jedoch sowohl als Messgerät als auch als Zähler behandelt. Nutzer können jetzt kumulative Vorgänge für diese Messwerte verwenden.

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. Statt die nicht typisierten 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 Speichernutzung auf Windows-VMs (Versionen 2.27.0 bis 2.29.0)

Unter Windows in den Ops-Agent-Versionen 2.27.0 bis 2.29.0 hat ein Programmfehler, der dazu geführt hat, dass der Agent Sockets führte, zu einer erhöhten Speichernutzung und einer hohen Anzahl von Handles geführt, die vom fluent-bit.exe-Prozess gehalten wurden.

Aktualisieren Sie den Ops-Agent auf Version 2.30.0 oder höher und starten Sie den Agent neu, um dieses Problem zu beheben.

Zeitzonen für Ereignisprotokolle sind unter Windows falsch (Versionen 2.15.0 bis 2.26.0)

Die Zeitstempel, die mit Windows-Ereignislogs in Cloud Logging verknüpft sind, 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 einen der folgenden Problemumgehungen verwenden.

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 Log-Prozessor verwenden, der einen Zeitstempel parst, wird der Zeitzonenwert unter Windows nicht korrekt 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.