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 Monitoring 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:

Linux-Instanz

Das folgende Verfahren funktioniert sowohl auf Compute Engine- als auch Amazon EC2-VM-Instanzen, die unter Linux ausgeführt werden:

  1. Überprüfen Sie mit den folgenden Befehlen für Ihre VM-Instanz, ob der Stackdriver Logging-Agent ausgeführt wird:

    ps ax | grep fluentd

    Die Ausgabe sollte in etwa so aussehen:

     2284 ?        Sl     0:00 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]
 2287 ?        Sl    42:44 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]

  2. Senden Sie mit dem folgenden Befehl für die VM-Instanz eine Test-Lognachricht:

    logger "Some test message"

Windows-Instanz

Der Stackdriver Logging-Agent hat zwei Windows-Dienstnamen:

  • StackdriverLogging für Versionen ab v1-5
  • fluentdwinsvc für frühere Versionen

Sie sollten einen Agent-Dienst ausführen. Führen Sie die folgenden Befehle über PowerShell für die VM-Instanz aus:

  1. Fragen Sie den Status beider Dienste ab. Wenn Sie wissen, welcher Dienst ausgeführt werden soll, reicht es, wenn Sie nur dessen Dienstnamen verwenden:

    Get-Service StackdriverLogging,fluentdwinsvc

  2. Wenn ein Dienst nicht ausgeführt wird, erhalten Sie eine Fehlermeldung. Wird er ausgeführt, sehen Sie in etwa folgende Ausgabe:

    Status    Name                DisplayName
------    ----                -----------
Running  StackdriverLogging   Cloud Logging

  3. Wenn Sie beide Dienste abfragen, sollten Sie eine Fehlermeldung und einen Status Running sehen:

    • Wenn Sie den Status Running nicht sehen, wird der Logging-Agent nicht ausgeführt.
    • Wenn Sie sehen, dass StackdriverLogging ausgeführt wird, haben Sie eine aktuelle Agent-Version. Wie Sie die spezielle Version ermitteln, erfahren Sie unter Version abrufen.
    • Wenn fluentdwinsvc ausgeführt wird, sollten Sie den Agent auf die neueste Version upgraden.

  4. Erfordert Administratorrechte: Wenn eine Agent-Version ausgeführt wird, senden Sie mit den folgenden PowerShell-Befehlen eine Test-Lognachricht:

    New-EventLog   -LogName Application -Source "Test Source"
Write-EventLog -LogName Application -Source "Test Source" -EntryType Information -EventID 1 -Message "Testing 123 Testing."

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 Monitoring 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:

Zugriffsbereich Agent-Berechtigungen
https://www.googleapis.com/auth/logging.write Für den Logging-Agent ausreichend
https://www.googleapis.com/auth/monitoring.write Für den Monitoring-Agent ausreichend

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 und Verwaltung 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:

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.

Fehler Ursache Lösung
Das Agent-Installationsprogramm kann nicht unter Windows ausgeführt werden. Möglicherweise haben Sie das Installationsprogramm in ein Systemverzeichnis heruntergeladen. Verschieben Sie das Installationsprogramm in ein Verzeichnis außerhalb des Systemverzeichnisses, z. B. C:\Users\[USERID]\.
Die API wurde nicht für das Projekt aktiviert. Sie haben die Cloud Logging API in Ihrem Projekt nicht aktiviert. Rufen Sie die API Console auf und ändern Sie den Status der Cloud Logging API in EIN.
Die Anfrage weist ungültige Anmeldedaten auf
oder
das Zugriffstoken kann nicht abgerufen werden (möglicherweise sind keine Bereiche konfiguriert).		 Ihre VM-Instanz hat keine geeigneten Anmeldedaten. Wenn Sie Amazon EC2 verwenden, müssen Sie vor der Installation des Agents Anmeldedaten auf Ihren VM-Instanzen installieren. Informationen zum Installieren von Anmeldedaten finden Sie unter Logging-Agent autorisieren.
Autorisierung fehlgeschlagen Ihre Anmeldedaten mit privatem Schlüssel für den Stackdriver Logging-Agent sind nicht richtig konfiguriert. Weitere Informationen erhalten Sie unter Anmeldedaten mit privatem Schlüssel prüfen.
Das Dienstkonto hat keine Berechtigung. Die Berechtigungen des in Ihrem Projekt für die Autorisierung verwendeten Dienstkontos sind unzureichend. Dabei kann es sich um das in Compute Engine oder App Engine verwendete Standarddienstkonto oder ein benutzerdefiniertes Dienstkonto handeln, das Sie für die Autorisierung mit einem privaten Schlüssel verwenden. Das Konto muss die Rolle Bearbeiter haben. Ändern Sie die Berechtigung des Dienstkontos auf der Seite IAM für Ihr Projekt. Bei Bedarf können Sie den Zugriffsbereich für eine vorhandene VM ändern. Dazu ändern Sie die Dienstkonto- und Zugriffsbereiche für eine Instanz.
Die Projekt-ID kann nicht abgerufen werden. Der Cloud Logging-Agent konnte die Projekt-ID nicht aus der Datei mit den Anmeldedaten mit privatem Schlüssel eines Dienstkontos abrufen. Um eine Projekt-ID für den Agent hinzuzufügen oder zu überschreiben, bearbeiten Sie die Konfigurationsdatei des Agents, /etc/google-fluentd/google-fluentd.conf, in Ihrer VM-Instanz. Fügen Sie im Abschnitt <match **> die folgende Zeile ein:
project_id [YOUR_PROJECT_ID]
Wie Sie stattdessen die Anmeldedaten korrigieren oder ersetzen können, erfahren Sie unter Logging-Agent autorisieren.
Der Windows-Logging-Agent nimmt keine Ereignislogs mehr von einigen Kanälen auf. Der Logging-Agent kann bei der Aufnahme von Ereignislogs aus bestimmten Kanälen unbemerkt fehlschlagen, obwohl er noch ausgeführt wird und die Agent- und Ereignislogs von anderen Kanälen aufnimmt. Der Grund hierfür ist, dass das windows_eventlog-Plug-in einige Probleme hat, wie in dieser Darstellung erwähnt. Dieses Problem lässt sich mit windows_eventlog2 beheben. Hinweis: Das Datenformat des windows_eventlog2-Plug-ins ist nicht mit dem windows_eventlog-Plug-in abwärtskompatibel. Falls BigQuery- oder Google Cloud Storage-Exportpipelines vorhanden sind, die für diese Logs eingerichtet sind, müssen sie entsprechend angepasst werden. Weitere Informationen finden Sie unter Vergleich der Logeinträge von windows_eventlog und windows_eventlog2. Zur Verwendung von windows_eventlog2 müssen Sie zuerst den Logging-Agent beenden und dann die Konfigurationsdatei durch eine Datei ersetzen, die dieser Beispielkonfigurationsdatei ähnelt. Starten Sie schließlich den Logging-Agent.
Der Logging-Agent stoppt die Aufnahme von Logs bei Vorhandensein von Logrotate Wenn Logrotate mit der Einstellung copytruncateeingerichtet wurde, ist es möglich, dass der Logging-Agent den Überblick darüber verliert, an welcher Stelle er sich gerade bei den Eingabedateien befindet. Verwenden Sie am besten die Einstellung nocopytruncate, um sicherzustellen, dass Logrotate die Dateien verschiebt und nicht kürzt. Wenn Sie die Einstellung copytruncate beibehalten möchten, können Sie das Problem umgehen. Dazu starten Sie den Agent von Zeit zu Zeit neu. Alternativ können Sie den Agent mit der Einstellung postrotate neu starten.
error_class=Errno::EADDRINUSE error="Die E-Mail-Adresse wird bereits verwendet - bind(2) for 0.0.0.0:24231" Auf der VM werden mehrere Logging-Agent-Instanzen ausgeführt. Verwenden von ps -aux | grep "/usr/sbin/google-fluentd" zum Anzeigen laufender Agent-Prozesse (sollten nur zwei sein: ein Supervisor und ein Worker) und sudo netstat -nltp | grep :24231 zum Anzeigen von Prozessen, die den Port durchlaufen. Gegebenenfalls beenden von älteren Instanzen.
Logging-Agent startet aufgrund von Fehlern bei lib/fluent/config/types.rb nicht Die Logging-Agent-Konfiguration verwendet einen Abschnitt zum Regex-Parser mit fehlerhaftem Regex, was zu einem ungültigen Subexp-Aufruf und Fehlern wie Starting google-fluentd 1.8.6: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/fluentd-1.11.2/lib/fluent/config/types.rb:92: warning: invalid subexp call führt. Suchen Sie nach dem fehlerhaften Regex in der Konfigurationsdatei des Agents und beheben Sie den Fehler. Tipp: Suchen Sie nach regex oder parse.

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.