Logging-Agent – Fehlerbehebung

Auf dieser Seite finden Sie Anleitungen zur Behebung häufiger Probleme bei der Installation des Logging-Agents und bei der Interaktion mit diesem.

Checkliste

Wenn Sie Probleme bei der Installation oder Verwendung des Logging-Agents haben, sollten Sie Folgendes prüfen:

• Wenn Sie unter Linux bei Installationsbefehlen Fehlermeldungen erhalten, prüfen Sie, ob den Installationsbefehlen sudo vorangestellt wurde.

• Prüfen Sie, ob der Agent auf Ihrer VM-Instanz ausgeführt wird:

  • Verwenden Sie für eine Windows-VM den folgenden PowerShell-Befehl:

    Get-Service -Name StackdriverLogging
    

    Suchen Sie nach einem Dienst namens Stackdriver Monitoring. Wenn der Agent nicht ausgeführt wird, müssen Sie ihn möglicherweise neu starten.

  • Verwenden Sie für eine Linux-VM den folgenden Befehl:

    sudo service google-fluentd status
    

    Wenn der Agent nicht ausgeführt wird, müssen Sie ihn möglicherweise neu starten. Führen Sie dazu den folgenden Befehl aus:

    sudo service google-fluentd restart
    

    Wenn der Neustart fehlschlägt und in der Logausgabe die Meldung "Über Metadaten deaktiviert" angezeigt wird, führen Sie möglicherweise ein Image über Google Cloud Marketplace aus. In Google Cloud Marketplace ist der Logging-Agent standardmäßig deaktiviert. Der Metadatenschlüssel der Instanz google-logging-enable steuert den Aktivierungsstatus des Logging-Agents, wobei der Wert 0 den Agent deaktiviert. Entfernen Sie entweder den Schlüssel google-logging-enable oder legen Sie als Wert 1 fest, um den Agent wieder zu aktivieren. Weitere Informationen finden Sie unter Instanz mit deaktiviertem Logging-Agent erstellen.

    Wenn der Agent nicht über Metadaten deaktiviert ist, installieren Sie ihn neu. Weitere Informationen finden Sie im folgenden Abschnitt Logging-Agent neu installieren.

• Prüfen Sie, ob der Agent Fehlermeldungen in Logs geschrieben hat.

  • Unter Windows, ab Version v1-9, speichert der Logging-Agent seine Logs im Verzeichnis C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log.

    Es gibt keine Möglichkeit, die Logs für frühere Versionen des Agents abzurufen.

  • Unter Linux ist der Logging-Agent ein fluentd-Paket und protokolliert Nachrichten in /var/log/google-fluentd/google-fluentd.log:

    • Wenn Sie den HTTP-Fehler 429 erhalten, haben Sie möglicherweise Ihr Logging API-Kontingent überschritten. Sie können Ihr verfügbares Kontingent ansehen, wenn Sie in der Google Cloud Console APIs & Dienste > Dashboard auswählen. Wählen Sie die Logging API aus.

    • Wenn beim API-Zugriff oder der Autorisierung Probleme auftreten, wechseln Sie zu Compute Engine Anmeldedaten überprüfen.

• Wenn der Agent scheinbar normal ausgeführt wird, Sie aber keine Daten erhalten, prüfen Sie, ob der Agent Daten an das richtige Projekt sendet. Weitere Informationen finden Sie im folgenden Abschnitt Compute Engine Anmeldedaten überprüfen.

• Wenn der Agent nicht autorisiert wird, prüfen Sie, ob die Anmeldedaten für Ihren privaten Schlüssel fehlen oder ungültig sind.

Agent-Installation überprüfen

Um zu überprüfen, ob die Installation erfolgreich war, suchen Sie im Log-Explorer den Test-Logeintrag des Agents.

1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

   Zum Log-Explorer

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Wählen Sie oben auf der Seite das Projekt mit der VM-Instanz aus:

   • Wählen Sie unter Compute Engine-VM-Instanzen das Google Cloud-Projekt aus, das die VM-Instanz enthält.
   • Wählen Sie für Amazon EC2-VM-Instanzen das Google Cloud-Projekt aus, an das Sie Protokolle senden.

3. Wählen Sie in den Windows-Tabs die Ressource für Ihre VM-Instanz aus:

   • Wählen Sie für Compute Engine die GCE-VM-Instanz aus.
   • Wählen Sie für Amazon EC2 die AWS EC2-Instanz aus.
   • Wählen Sie für Linux syslog, für Windows fluent.info oder allgemein Alle Logs aus.

Wenn Sie den Logeintrag "Successfully sent gRPC to Logging API" (gRPC erfolgreich an Logging API gesendet) sehen, ist die Agent-Installation abgeschlossen. Diese Nachricht wird bei der Installation des Agents und bei jedem Neustart des Agents einmal generiert.

Weitere Informationen zum Log-Explorer finden Sie unter Log-Explorer verwenden.

Agent testen

Wenn Sie vermuten, dass der Agent nicht funktioniert, senden Sie eine Testnachricht an Logging:

Testnachricht suchen

Suchen Sie die gesendete Testnachricht im Log-Explorer:

1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

   Zum Log-Explorer

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Wählen Sie oben auf der Seite das Projekt mit der VM-Instanz aus:

   • Wählen Sie unter Compute Engine-VM-Instanzen das Google Cloud-Projekt aus, das die VM-Instanz enthält.
   • Wählen Sie für Amazon EC2-VM-Instanzen das Google Cloud-Projekt aus, an das Sie Protokolle senden.

3. Wählen Sie in den Windows-Tabs die Ressource für Ihre VM-Instanz aus:

   • Wählen Sie für Compute Engine die GCE-VM-Instanz aus.
   • Wählen Sie für Amazon EC2 die AWS EC2-Instanz aus.
   • Wählen Sie für Linux syslog, für Windows fluent.info oder allgemein Alle Logs aus.

4. Sie sollten einen Logeintrag mit Ihrer Testnachricht sehen. Wenn dies der Fall ist, arbeitet der Logging-Agent ordnungsgemäß.

Anmeldedaten für Compute Engine prüfen

Damit eine Compute Engine-VM-Instanz den Agent ohne Anmeldedaten mit privatem Schlüssel ausführen kann, muss die Instanz geeignete Zugriffsbereiche und die von der Instanz verwendete Dienstkontoidentität geeignete IAM-Berechtigungen haben.

Wenn Sie eine VM-Instanz erstellen, reichen die Standardeinstellungen für Bereich und Dienstkonto aus, um die Agents auszuführen. Sehr alte Instanzen oder Instanzen, für die Sie die Standardeinstellungen geändert haben, haben möglicherweise nicht die geeigneten Anmeldedaten.

Fehler beim Laden der Standardanmeldedaten

Wenn in der Logging-Logdatei Could not load the default credentials-Fehler auftreten, bedeutet dies möglicherweise, dass der Agent keine Verbindung zum Compute Engine-Metadatenserver herstellen kann.

Das Fehlerprotokoll sieht in etwa so aus:

Starting google-fluentd 1.8.4: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/googleauth-0.9.0/lib/googleauth/application_default.rb:74:in `get_application_default': Could not load the default credentials. Browse to (RuntimeError) https://developers.google.com/accounts/docs/application-default-credentials for more information.

Eine mögliche Ursache hierfür ist die Einrichtung eines benutzerdefinierten Proxy für die VM. Informationen zum Beheben dieses Problems finden Sie in der Anleitung zur Proxyeinrichtung, um den Compute Engine-Metadatenserver (metadata.google.internal oder 169.254.169.254) vom Proxy auszuschließen. Wenn der Fehler weiterhin auftritt, entfernen Sie das Compute Engine-Standarddienstkonto von der VM und fügen Sie es wieder hinzu.

Zugriffsbereiche überprüfen

Führen Sie die folgenden Schritte aus, um die Zugriffsbereiche zu überprüfen:

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf:

   Zu Seite VM-Instanzen

   Wenn Sie diese Seite über die Suchleiste finden, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Compute Engine lautet.

2. Klicken Sie auf den Namen Ihrer VM-Instanz. Daraufhin wird die Detailseite für Ihre Instanz eingeblendet.

3. Klicken Sie im Abschnitt Zugriffsbereiche für Cloud API auf Details, um die Liste der APIs aufzurufen. Suchen Sie nach den folgenden Einträgen:

   1. Wenn Sie die Meldung "Diese Instanz hat uneingeschränkten API-Zugriff auf alle Google Cloud-Dienste" sehen, reichen Ihre Zugriffsbereiche aus.
   2. Wenn neben Stackdriver Logging API, ein älterer Name für die Cloud Logging API, Nur Schreibzugriff oder Vollzugriff als Berechtigung angezeigt wird, sind die Zugriffsbereiche Ihrer Instanz für den Cloud Logging-Agent geeignet.
   3. Wenn neben Stackdriver Monitoring API, ein älterer Name für die Cloud Monitoring API, Nur Schreibzugriff oder Vollzugriff als Berechtigung angezeigt wird, sind die Zugriffsbereiche Ihrer Instanz für den Cloud Monitoring-Agent geeignet.

Problem beheben

Wenn in Ihrer Compute Engine-Instanz keine geeigneten Zugriffsbereiche vorhanden sind, fügen Sie der Instanz die erforderlichen Zugriffsbereiche hinzu.

Die folgende Tabelle zeigt die für die Logging- und Monitoring-Agents relevanten Bereiche:

Standardmäßige Dienstkontoberechtigung prüfen

Auch wenn die Zugriffsbereiche Ihrer Compute Engine-VM-Instanz ausreichend sind, bietet das Standarddienstkonto Ihrer Instanz möglicherweise nicht die richtigen IAM-Berechtigungen für den Agent.

Um die Berechtigung des Standarddienstkontos zu überprüfen, suchen Sie zuerst nach dem Standarddienstkonto:

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf:

   Zu Seite VM-Instanzen

   Wenn Sie diese Seite über die Suchleiste finden, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Compute Engine lautet.

2. Klicken Sie auf den Namen Ihrer VM-Instanz. Daraufhin wird die Detailseite für Ihre Instanz eingeblendet.

3. Suchen Sie auf der Seite nach der Überschrift Dienstkonto. Das Standarddienstkonto für die Instanz ist aufgeführt. Es könnte so aussehen:

   [ID]-compute@developer.gserviceaccount.com
   

4. Öffnen Sie in der Google Cloud Console die Seite IAM:

   Rufen Sie IAM auf.

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift IAM & Admin ist.

5. Wählen Sie Ansehen nach: Hauptkonten aus. Sie sollten eine Liste mit Personen, Gruppen und Dienstkonten sehen. In der Spalte Rolle finden Sie die Rollen, die jedes Hauptkonto in Ihrem Projekt hat.

6. In der Zeile für das Standarddienstkonto Ihrer Instanz sollten eine oder mehrere Rollen angezeigt werden:

   • Wenn Bearbeiter angezeigt wird, ist diese Rolle für alle Agents geeignet. Je nach Konfiguration Ihrer Organisationsrichtlinie wird dem Standarddienstkonto möglicherweise automatisch die Rolle Bearbeiter zugewiesen.
   • Wenn Sie Logautor sehen, reicht diese Rolle für den Logging-Agent aus. Informationen zu weiteren Logging-Rollen mit Schreibberechtigung finden Sie unter Zugriffssteuerung für Cloud Logging.
   • Wenn Sie Monitoring-Messwertautor sehen, reicht diese Rolle für den Monitoring-Agent aus. Weitere Monitoring-Rollen mit Schreibberechtigung finden Sie unter Zugriffssteuerung für Cloud Monitoring.

Problem beheben

Wenn Ihr Standarddienstkonto nicht über ausreichende Rollen verfügt, versuchen Sie, die Rollen für Ihr Dienstkonto auf der Seite IAM & Verwaltung > IAM zu bearbeiten. Fügen Sie die entsprechenden Logging- oder Monitoring-Rollen hinzu, um die Agents zu autorisieren: Logging > Log-Autor oder Monitoring > Monitoring-Messwert-Autor.

Anmeldedaten mit privatem Schlüssel prüfen

Auf Compute Engine-VM-Instanzen können Sie den Agent so konfigurieren, dass er ein nicht standardmäßiges Dienstkonto verwendet, das über die erforderliche Berechtigung verfügt. Bei AWS EC2-VM-Instanzen müssen Sie den Agent für die Verwendung eines solchen Dienstkontos konfigurieren.

Um den Agent auf diese Weise zu konfigurieren, müssen Sie für das angegebene Dienstkonto Anmeldedaten für den privaten Schlüssel erstellen und diese Anmeldedaten dem Agent zuweisen.

1. Der Agent sucht nach einer Umgebungsvariablen GOOGLE_APPLICATION_CREDENTIALS mit dem Namen einer Datei, die die Anmeldedaten für den privaten Schlüssel enthält.

2. Wenn die Umgebungsvariable nicht vorhanden ist, sucht der Agent nach Anmeldedaten an einem Standardspeicherort:

   Linux

   /etc/google/auth/application_default_credentials.json
   

   Windows

   C:\ProgramData\Google\Auth\application_default_credentials.json
   

3. Wenn der Standardspeicherort die Anmeldedaten nicht enthält, verwendet der Agent die Standardanmeldedaten für Anwendungen vom Metadatenserver.

Die folgenden Informationen helfen Ihnen, Probleme mit den Anmeldedaten für private Schlüssel zu erkennen:

1. Ist der private Schlüssel vorhanden?
2. Ist der private Schlüssel für das Dienstkonto noch gültig?
3. Verfügt das Dienstkonto über die Rollen, die für den Agent benötigt werden?

Zur Bestätigung, dass auf Ihrer VM-Instanz gültige Anmeldedaten mit privatem Schlüssel vorhanden sind, prüfen Sie zuerst, ob sich die Datei mit den Anmeldedaten am erwarteten Speicherort befindet. Bestätigen Sie anschließend, dass die Informationen in der Datei mit den Anmeldedaten gültig sind.

Sind die Anmeldedaten vorhanden?

Führen Sie zur Prüfung, ob auf Ihrer Instanz Anmeldedaten mit privatem Schlüssel für das Dienstkonto vorhanden sind, die folgenden Linux-Befehle darauf aus:

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

Wenn mit einem der Befehle eine Datei mit folgendem Inhalt aufgerufen wird, verfügt Ihre Instanz unter Umständen über gültige Anmeldedaten mit privatem Schlüssel. Wenn beide Befehle eine Datei zurückgeben, wird die Datei mit der Bezeichnung GOOGLE_APPLICATION_CREDENTIALS verwendet.

{
  "type": "service_account",
  "project_id": "[YOUR-PROJECT-ID]",
  "private_key_id": "[YOUR-PRIVATE-KEY-ID]",
  "private_key": "[YOUR-PRIVATE-KEY]",
  "client_email": "[YOUR-PROJECT-NUMBER]-[YOUR-KEY]@developer.gserviceaccount.com",
  "client_id": "[YOUR-CLIENT-ID]",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "{x509-cert-url}",
  "client_x509_cert_url": "{client-x509-cert-url}"
}

Abweichungen zwischen den Anmeldedatenkonfigurationen können dazu führen, dass der Agent Anmeldedaten verwendet, die von Ihrem Dienst abweichen. Wenn Sie beispielsweise einen benutzerdefinierten Anmeldedatenstandort in GOOGLE_APPLICATION_CREDENTIALS in der Anmelde-Shell festlegen, aber diese Variable nicht in der Dienstkonfiguration des Agents festlegen, sucht der Dienst stattdessen am Standardspeicherort.

Wenn Sie Ihre Umgebungsvariable für Anmeldedaten prüfen oder ändern möchten, greifen Sie in /etc/default/google-fluentd auf GOOGLE_APPLICATION_CREDENTIALS zu oder legen Sie es fest.

Wenn keine Datei mit Anmeldedaten vorhanden ist, fahren Sie unter Anmeldedaten hinzufügen fort.

Sind die Anmeldedaten gültig?

In der Datei mit den Anmeldedaten bezieht sich project_id auf Ihr Google Cloud-Projekt, client_email auf das Dienstkonto des Projekts und private_key_id auf den privaten Schlüssel im Dienstkonto. Passen Sie diese Informationen an die Angaben in der Google Cloud Console unter IAM & Verwaltung > Dienstkonten an.

Die Datei mit den Anmeldedaten ist nicht gültig, wenn eine der folgenden Bedingungen zutrifft:

• Sie prüfen eine Compute Engine-Instanz, aber das Google Cloud-Projekt in der Datei mit den Anmeldedaten ist nicht das Projekt, in dem Ihre Instanz enthalten ist.
• Sie prüfen eine Amazon EC2-Instanz, aber das Google Cloud-Projekt in der Datei mit den Anmeldedaten ist nicht das Google Cloud-Projekt, an das Sie Protokolle senden.
• Das aufgeführte Dienstkonto existiert nicht. Es wurde möglicherweise gelöscht.
• Im aufgeführten Dienstkonto sind nicht die richtigen Rollen aktiviert: Log-Autor für den Cloud Logging-Agent und Monitoring-Messwert-Autor für den Cloud Monitoring-Agent.
• Der private Schlüssel existiert nicht. Er wurde möglicherweise widerrufen.

Bisher gültige Anmeldedaten können Sie in der Google Cloud Console unter IAM & Verwaltung > Dienstkonten widerrufen. Wenn keine Anmeldedaten vorhanden sind, ersetzen Sie wie unter Anmeldedaten hinzufügen beschrieben die bestehenden Anmeldedaten oder fügen Sie neue hinzu.

Wenn das Dienstkonto korrekt ist, aber der private Schlüssel widerrufen wurde, können Sie einen neuen privaten Schlüssel erstellen und ihn in Ihre Instanz kopieren. Siehe Dienstkontoschlüssel erstellen.

Andernfalls müssen Sie wie im Abschnitt Anmeldedaten hinzufügen beschrieben ein neues Dienstkonto erstellen.

Abfragen mit Logausschlüssen prüfen

Prüfen Sie Ihre aktuellen Ausschlussabfragen, um sicherzustellen, dass die gesuchten Logs nicht versehentlich ausgeschlossen werden.

Firewall verifizieren

Führen Sie den folgenden Linux-Befehl für die Instanz aus, um festzustellen, ob die Instanz Zugriff auf logging.googleapis.com hat:

curl -sSL 'https://logging.googleapis.com/$discovery/rest?version=v2' | head

Der Befehl kann einige Zeit in Anspruch nehmen, wenn die Firewall den ausgehenden Traffic blockiert. Beispielausgabe, die auf ein Firewallproblem hinweist:

curl: (7) Failed to connect to 2607:f8b0:4001:c03::5f: Network is unreachable

Weitere Informationen zum Einrichten von Regeln für ausgehenden Traffic finden Sie unter Firewallregeln.

Agent neu installieren

Die Installation der aktuellen Agent-Version kann zahlreiche Probleme lösen:

• Wenn Sie sicher sind, dass das Problem nicht mit den Anmeldedaten zusammenhängt, können Sie direkt mit dem Schritt Installation unter Linux und Windows weitermachen.

• Wie Sie den Agent vollständig installieren und welche Anmeldedaten Sie benötigen, erfahren Sie unter Logging-Agent installieren.

Weitere häufig auftretende Probleme

In der folgenden Tabelle sind einige häufig auftretende Probleme aufgeführt, die beim Umgang mit dem Cloud Logging-Agent auftreten können. Hier erfahren Sie, wie sich diese beheben lassen.

Unter Linux werden Fehlermeldungen des Logging-Agents in /var/log/google-fluentd/google-fluentd.log aufgezeichnet. Unter Windows werden Fehlermeldungen des Logging-Agents in C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log aufgezeichnet (ab Version v1-9). Die Fehlerklasse Google::APIClient::ClientError gibt an, dass ein Problem hinsichtlich der Berechtigungen oder des API-Zugriffs vorliegt.

Etwaige Fehlermeldungen werden angezeigt, sobald der Agent erfolgreich ausgeführt wird. Ein Fehler wird beispielsweise ausgegeben, wenn ein Nutzer die erforderlichen Berechtigungen für Ihr Projekt oder Ihre VM-Instanz aufgehoben hat.

Beschränkung des Logdurchsatzes

Der maximale Logdurchsatz, den der Logging-Agent verarbeiten kann, ist CPU-gebunden. Die CPU-Auslastung steigt tendenziell, wenn der Logdurchsatz zunimmt. Der Agent kann in der Standardkonfiguration jedoch nur einen CPU-Kern verwenden. Wenn der Logdurchsatz steigt, kann der Agent ein CPU-Nutzungslimit erreichen. Wenn diese Spitzen nur temporär sind, puffert der Logging-Agent die Logs und holt sie später ab, um sie zu verarbeiten. Wenn der Logdurchsatz konstant hoch bleibt, können die Logs den Puffer überlaufen lassen und schließlich verloren gehen.

Wenn jeder Logeintrag aus 1.000 Byte Rohtext besteht und keine zusätzliche Formatierung enthält, stößt der Log-Aagent in der Regel bei etwa 5.500 Logeinträgen pro Sekunde an die Grenze von einem CPU-Kern. Wenn für die Logeinträge eine erweiterte Verarbeitung erforderlich ist, z. B. JSON- oder Regex-Parsing, können die maximalen Logeinträge pro Sekunde niedriger sein.

Wenn Sie einen höheren Logdurchsatz benötigen, können Sie den Ops-Agent verwenden. Unter Linux kann der Ops-Agent bei Logeinträgen, die aus 1.000 Byte Rohtext bestehen und keine zusätzliche Verarbeitung erfordern, etwa 160.000 Logeinträge pro Sekunde verarbeiten.

Maximale Loggröße überschritten

Wenn ein oder mehrere Logeinträge die maximale Größe überschreiten, werden in den fluentd-Logs möglicherweise Einträge wie die folgenden angezeigt:

Dropping 1 log message(s) error_class="Google::Apis::ClientError" error="Invalid request"

oder

Dropping 1 log message(s) error="3:Log entry with size 1000515 bytes exceeds maximum size of 112640 bytes" error_code="3"

Um diesen Fehler zu beheben, sollten Sie Ihre Logeinträge so kürzen, dass sie die maximale Größe nicht überschreiten. Mit dem folgenden Beispielcode werden beispielsweise Logs mit dem Tag mytag mit den Daten im Feld message gekürzt:

# Cloud Logging only supports log entries that are up to 256 KiB in size.
# Trim the entries to just under that size to avoid dropping them.
<filter [MY_TAG]>
  @type record_transformer
  enable_ruby true
  <record>
    message ${record['message'].length > 256000 ? "[Trimmed]#{record['message'][0..256000]}..." : record['message']}
  </record>
</filter>

Logs sind dupliziert

LogEntry.insertID wird der Verarbeitungspipeline innerhalb des Agents hinzugefügt. Wenn insertID sich zwischen den doppelten Logs unterscheidet, bedeutet dies, dass die Logs aus den Logdateien mehrfach hervorgehen. Dies kann auftreten, wenn die Logrotation vorhanden ist oder wenn die Positionsdatei fehlt oder beschädigt ist. Achten Sie darauf, die Positionsdateien für eine in_tail-Eingabe nicht im Ordner /var/log oder in anderen Ordnern mit aktivierter Log-Rotation zu konfigurieren, um dieses Problem zu vermeiden.

Die Logging-Pipeline verwendet außerdem das Feld LogEntry.timestamp, um Logs zu deduplizieren. Prüfen Sie, ob der tatsächliche Zeitstempel des Logeintrags richtig geparst wird. Wenn Fluentd nicht so eingerichtet ist, dass der ursprüngliche Zeitstempel aus dem Logeintrag geparst wird, verwendet Fluentd den Zeitpunkt, an dem der Logeintrag verarbeitet wird. Wenn die Eingabe also mehrmals gelesen wird, obwohl der Zeitstempel in der Logzeile identisch ist, werden sie möglicherweise von Fluentd als unterschiedliche Logeinträge mit unterschiedlichen Zeitstempeln behandelt.

Wiederholte Audit-Log-Fehler: Data points cannot be written more than 24h in the past

Es gibt ein bekanntes Problem, das die Versionen 1.8.5 bis (einschließlich) 1.9.3 betrifft. Dabei werden Logs wie die folgenden wiederholt in Audit-Logs zum Datenzugriff angezeigt, wenn der Agent länger als 24 Stunden ausgeführt wird:

Field timeSeries[0].points[0].interval.end_time had an invalid value of "2021-10-20T20:16:34.010866-07:00": Data points cannot be written more than 24h in the past.

Die Lösung besteht darin, den Agent auf 1.9.4 oder höher zu aktualisieren.

Unicode-Zeichen in Logs werden durch Leerzeichen oder '�' ersetzt

Standardmäßig erwartet die Eingabe in_tail, dass die Eingabedateien ASCII-codiert sind. Daher werden alle Nicht-ASCII-Zeichen durch ein Leerzeichen ersetzt. Um UTF-8-codierte Dateien tatsächlich aufzunehmen, müssen Sie zwei Optionen in der in_tail-Konfiguration angeben:

<source>
  @type tail
  …

  encoding UTF-8
  from_encoding UTF-8
</source>

Beide Optionen sind erforderlich. Wenn nur die Option encoding angegeben ist, werden Nicht-ASCII-Zeichen in den aufgenommenen Logs durch "�" ersetzt.

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.

Der Logging-Agent erscheint nicht in der Liste der zu deinstallierenden Windows-Programme

Führen Sie uninstall.exe in dem Verzeichnis aus, in dem Sie den Agent installiert haben, um den Logging-Agent zu deinstallieren, wenn er nicht in der Liste Programm deinstallieren der Windows-Systemsteuerung aufgeführt ist.