Fehlende Logs in GKE beheben

Probleme mit der Logging-Pipeline in Google Kubernetes Engine (GKE) können verhindern, dass Ihre Clusterlogs in Cloud Logging angezeigt werden. Dies kann Ihre Bemühungen zur Überwachung und Fehlerbehebung behindern.

In diesem Dokument erfahren Sie, wie Sie Konfigurationen und Berechtigungen überprüfen, Ressourcen- und Leistungsprobleme beheben, Filter und das Verhalten von Anwendungen untersuchen und Plattform- oder Dienstprobleme beheben, die sich auf Ihre Protokolle auswirken.

Diese Informationen sind wichtig für Plattformadministratoren und ‑operatoren, die die Clusterbeobachtbarkeit verwalten, und für alle, die Cloud Logging zur Fehlerbehebung bei GKE-Vorgängen verwenden. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Weitere Informationen zur Verwendung von Logs zur Fehlerbehebung bei Arbeitslasten und Clustern finden Sie unter Verlaufsanalyse mit Cloud Logging durchführen.

Lösung nach Symptom suchen

Wenn Sie ein bestimmtes Symptom im Zusammenhang mit Ihren fehlenden Logs festgestellt haben, finden Sie in der folgenden Tabelle Tipps zur Fehlerbehebung:

Kategorie Symptom oder Beobachtung Mögliche Ursache Schritte zur Fehlerbehebung
Configuration Es sind keine Logs von einem Cluster im Projekt sichtbar. Die Cloud Logging API ist für das Projekt deaktiviert. Status der Cloud Logging API prüfen
Logs fehlen in einem bestimmten Cluster oder nur bestimmte Logtypen fehlen. Die Protokollierung auf Clusterebene ist für die erforderlichen Logtypen deaktiviert. Cluster-Logging-Konfiguration prüfen
Logs fehlen für Knoten in einem bestimmten Knotenpool. Den Knoten des Knotenpools fehlt der erforderliche Zugriffsbereich. Zugriffsbereiche für Knotenpools prüfen
In den Logs des Logging-Agents werden Berechtigungsfehler (401 oder 403) angezeigt. Dem Dienstkonto des Knotens fehlt die erforderliche Berechtigung. Berechtigungen des Knotendienstkontos prüfen
Ressourcen und Leistung Protokolle fehlen zeitweise oder es werden RESOURCE_EXHAUSTED-Fehler angezeigt. Das Projekt überschreitet das Schreibkontingent für die Cloud Logging API. Kontingentnutzung der Cloud Logging API untersuchen
Einige Logs von einem bestimmten Knoten fehlen, oft bei hohem Traffic oder hoher Last. Der Knoten überschreitet die Durchsatzlimits des Logging-Agents oder es fehlen Ressourcen (CPU oder Arbeitsspeicher) zum Verarbeiten von Logs. Knotendurchsatz und Ressourcennutzung untersuchen
Filtern und Anwendungsverhalten Bestimmte Logs, die einem bestimmten Muster entsprechen, fehlen immer wieder. Ein Logausschlussfilter in Cloud Logging verwirft die Logs unbeabsichtigt. Logausschluss-Filter untersuchen
Logs aus einem Container werden erheblich verzögert oder erst nach dem Beenden des Containers angezeigt. Die Ausgabe der Anwendung wird vollständig gepuffert, oft aufgrund von Piping stdout. Pufferung und Verzögerungen bei Containerlogs untersuchen
Erwartete Logs werden nicht in den Suchergebnissen angezeigt. Die Abfragefilter im Log-Explorer sind möglicherweise zu restriktiv. Log-Explorer-Abfragen untersuchen
Von einem bestimmten Anwendungs-Pod sind keine Logs sichtbar, aber andere Cluster-Logs sind vorhanden. Die Anwendung im Container schreibt nicht in stdout oder stderr. Anwendungsspezifisches Logging-Verhalten untersuchen
Plattform und Dienst Protokolle, die älter als ein bestimmtes Datum sind, werden nicht angezeigt. Die Logs haben den Aufbewahrungszeitraum überschritten und wurden von Cloud Logging gelöscht. Aufbewahrungsdauer für Logs prüfen
Es kommt zu einem weitverbreiteten Log-Verlust oder Verzögerungen in Projekten oder Clustern. Problem mit dem Cloud Logging-Dienst oder Verzögerung bei der Aufnahme. Probleme und Verzögerungen beim Cloud Logging-Dienst untersuchen
Logging-Probleme fallen mit Einschränkungen der Clusterversion zusammen. Nicht unterstützte GKE-Version. Clusterversion prüfen

Automatisierte Diagnosetools verwenden

In den folgenden Abschnitten werden Tools beschrieben, mit denen Ihr Cluster automatisch auf häufige Fehlkonfigurationen geprüft und komplexe Probleme untersucht werden können.

GKE-Logging-Probleme mit gcpdiag beheben

Wenn Sie unvollständige Logs in Ihrem GKE-Cluster fehlen oder diese abrufen, verwenden Sie das gcpdiag-Tool zur Fehlerbehebung.

gcpdiag ist ein Open-Source-Tool. Es ist kein offiziell unterstütztes Google Cloud -Produkt. Mit dem Tool gcpdiag können Sie Probleme mit Google Cloud-Projekten identifizieren und beheben. Weitere Informationen finden Sie im gcpdiag-Projekt auf GitHub.

Wenn Logs aus dem GKE-Cluster fehlen oder unvollständig sind, untersuchen Sie mögliche Ursachen, indem Sie sich auf die folgenden zentralen Konfigurationseinstellungen konzentrieren:

  • Logging auf Projektebene:Sorgt dafür, dass im Google Cloud-Projekt, in dem sich der GKE-Cluster befindet, die Cloud Logging API aktiviert ist.
  • Logging auf Clusterebene:Überprüft, ob das Logging explizit in der Konfiguration des GKE-Clusters aktiviert ist.
  • Knotenpoolberechtigungen:Bestätigt, dass für die Knoten in den Knotenpools des Clusters der Bereich Cloud Logging Write aktiviert ist, sodass sie Logdaten senden können.
  • Dienstkontoberechtigungen:Prüft, ob das von den Knotenpools verwendete Dienstkonto die erforderlichen IAM-Berechtigungen für die Interaktion mit Cloud Logging hat. Insbesondere ist die Rolle roles/logging.logWriter normalerweise erforderlich.
  • Schreibkontingente für die Cloud Logging API:Prüft, ob die Schreibkontingente für die Cloud Logging API im angegebenen Zeitraum nicht überschritten wurden.

Google Cloud Console

  1. Führen Sie den folgenden Befehl aus und kopieren Sie ihn. 
    2. gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION
  2. Öffnen Sie die Google Cloud Console und aktivieren Sie Cloud Shell.
    3. Cloud Console öffnen
  3. Fügen Sie den kopierten Befehl ein.
  4. Führen Sie den Befehl gcpdiag aus, um das Docker-Image gcpdiag herunterzuladen und dann Diagnoseprüfungen durchzuführen. Folgen Sie gegebenenfalls der Anleitung für die Ausgabe, um fehlgeschlagene Prüfungen zu beheben.

Docker

Sie können gcpdiag mit einem Wrapper ausführen, der gcpdiag in einem Docker-Container startet. Docker oder Podman muss installiert sein.

  1. Kopieren Sie den folgenden Befehl und führen Sie ihn auf Ihrer lokalen Workstation aus.
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Führen Sie den Befehl gcpdiag aus. 
    ./gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION

Verfügbare Parameter für dieses Runbook ansehen

Ersetzen Sie Folgendes:

  • PROJECT_ID: die ID des Projekts, das die Ressource enthält.
  • CLUSTER_NAME: der Name des GKE-Clusters.
  • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.

Nützliche Flags:

Eine Liste und Beschreibung aller gcpdiag-Tool-Flags finden Sie in der gcpdiag-Nutzungsanleitung.

Gemini Cloud Assist-Prüfungen verwenden

Sie können Gemini Cloud Assist-Prüfungen verwenden, um zusätzliche Informationen zu Ihren Logs zu erhalten und Probleme zu beheben. Weitere Informationen zu den verschiedenen Möglichkeiten, eine Untersuchung mit dem Log-Explorer zu starten, finden Sie in der Gemini-Dokumentation unter Probleme mit Gemini Cloud Assist-Untersuchungen beheben.

Logging-Konfiguration und Berechtigungen prüfen

Falsche Einstellungen sind ein häufiger Grund für fehlende GKE-Logs. Verwenden Sie die folgenden Abschnitte, um Ihre Cloud Logging-Konfiguration zu überprüfen.

Status der Cloud Logging API prüfen

Damit Logs aus einem beliebigen Cluster in Ihrem Projekt erfasst werden können, muss die Cloud Logging API aktiv sein.

Symptome:

In Cloud Logging sind keine Logs von GKE-Ressourcen in Ihrem Projekt sichtbar.

Ursache:

Die Cloud Logging API ist für das Projekt Google Cloud deaktiviert. Daher kann der Logging-Agent auf den Knoten keine Logs senden.

Lösung:

Wählen Sie eine der folgenden Optionen aus, um zu prüfen, ob die Cloud Logging API aktiviert ist, und sie gegebenenfalls zu aktivieren:

Console

  1. Rufen Sie in der Google Cloud Console die Seite Aktivierte APIs und Dienste auf.

    Zu „Aktivierte APIs und Dienste“

  2. Geben Sie im Feld Filter Cloud Logging API ein und drücken Sie die Eingabetaste.

  3. Wenn die API aktiviert ist, wird sie in der Liste angezeigt. Wenn die API nicht aufgeführt ist, aktivieren Sie sie:

    1. Klicken Sie auf  APIs und Dienste aktivieren.
    2. Geben Sie im Feld Suchen Cloud Logging API ein und drücken Sie die Eingabetaste.
    3. Klicken Sie auf das Ergebnis Cloud Logging API.
    4. Klicken Sie auf Aktivieren.

gcloud

  1. Prüfen Sie, ob die API aktiviert ist:

    gcloud services list --enabled --filter="NAME=logging.googleapis.com"

    Die Ausgabe sollte so aussehen:

    NAME: logging.googleapis.com
TITLE: Cloud Logging API

  2. Wenn die API nicht in den aktivierten Diensten aufgeführt ist, aktivieren Sie sie:

    gcloud services enable logging.googleapis.com \
    --project=PROJECT_ID

    Ersetzen Sie PROJECT_ID durch Ihre Google CloudProjekt-ID.

Cluster-Logging-Konfiguration prüfen

In GKE können Sie konfigurieren, welche Logtypen (z. B. SYSTEM oder WORKLOAD) aus einem Cluster erfasst werden.

Symptome:

In Cloud Logging werden keine Logs aus einem bestimmten GKE-Cluster angezeigt oder es fehlen nur bestimmte Arten von Logs (z. B. SYSTEM).

Ursache:

Die Protokollierung auf Clusterebene ist für die erforderlichen Logtypen deaktiviert. Wenn Sie einen Autopilot-Cluster verwenden, ist dies nicht die Ursache Ihrer Probleme mit der Protokollierung. Diese Einstellung kann für Standardcluster konfiguriert werden, ist aber in Autopilot-Clustern immer standardmäßig aktiviert und kann nicht deaktiviert werden.

Lösung:

Wählen Sie eine der folgenden Optionen aus, um die Logging-Konfiguration des Clusters zu prüfen und zu aktualisieren:

Console

  1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf.

    Zur Seite "Kubernetes-Cluster"

  2. Klicken Sie auf den Namen des Clusters, den Sie untersuchen möchten.

  3. Klicken Sie auf den Tab Details und rufen Sie den Abschnitt Funktionen auf.

  4. Prüfen Sie in der Zeile Logging, welche Logtypen aktiviert sind, z. B. System oder Arbeitslasten.

  5. Wenn die Protokolltypen, die Sie erfassen möchten, deaktiviert oder falsch sind, klicken Sie auf  Protokollierung bearbeiten.

  6. Wählen Sie in der Liste Komponenten die Kästchen für die Logtypen aus, die Sie erfassen möchten, und klicken Sie auf OK. Weitere Informationen zu den verfügbaren Logtypen finden Sie unter GKE-Logs.

  7. Klicken Sie auf Änderungen speichern.

gcloud

  1. So prüfen Sie die Logging-Konfiguration:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(name,loggingConfig.componentConfig.enableComponents)"

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.
    • PROJECT_ID: Projekt-ID in Google Cloud .

    Wenn die Protokollierung aktiviert ist, sieht die Ausgabe in etwa so aus:

    example-cluster    SYSTEM_COMPONENTS;WORKLOADS

    Wenn die Ausgabe NONE ist, ist das Logging deaktiviert.

  2. Wenn die gewünschten Logtypen deaktiviert oder falsch sind, aktualisieren Sie die Logging-Konfiguration:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --logging=LOGGING_TYPE

    Ersetzen Sie LOGGING_TYPE durch SYSTEM, WORKLOAD oder beides. Damit Logs erfasst werden können, muss SYSTEM aktiviert sein. WORKLOAD-Logs können nicht separat erfasst werden. Weitere Informationen zu verfügbaren Logtypen finden Sie unter GKE-Logs.

Zugriffsbereiche für Knotenpools prüfen

Knoten in einem GKE-Cluster verwenden OAuth-Zugriffsbereiche, um die Berechtigung zur Interaktion mit Google Cloud APIs, einschließlich Cloud Logging, zu erhalten.

Symptome:

Auf Knoten in einem bestimmten Knotenpool fehlen Logs.

Ursache:

Die Knoten im Knotenpool haben nicht den erforderlichen OAuth-Zugriffsbereich. Einer der folgenden Bereiche ist erforderlich, damit Knoten Logs in Cloud Logging schreiben können:

  • https://www.googleapis.com/auth/logging.write: Erteilt die Berechtigung zum Schreiben von Logs. Dies ist der erforderliche Mindestbereich.
  • https://www.googleapis.com/auth/logging.admin: Gewährt vollständigen Zugriff auf die Cloud Logging API, einschließlich der Berechtigungen von logging.write.
  • https://www.googleapis.com/auth/cloud-platform: Gewährt uneingeschränkten Zugriff auf alle aktivierten Google Cloud APIs, einschließlich der Berechtigungen auslogging.write.

Lösung:

Wählen Sie eine der folgenden Optionen aus, um die Berechtigungen zu überprüfen und die erforderlichen Rollen zuzuweisen, falls sie fehlen:

Console

  1. Prüfen Sie die Zugriffsbereiche des Knotenpools:

    1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf.

      Zur Seite "Kubernetes-Cluster"

    2. Klicken Sie auf den Namen des Clusters, den Sie untersuchen möchten, um die Detailseite des Clusters zu öffnen.

    3. Klicken Sie auf den Tab Knoten.

    4. Klicken Sie im Bereich Knotenpools auf den Namen des Knotenpools, den Sie untersuchen möchten.

    5. Rufen Sie den Abschnitt Sicherheit auf.

    6. Prüfen Sie die im Feld Zugriffsbereiche aufgeführten Bereiche. Prüfen Sie, ob mindestens einer der erforderlichen Bereiche vorhanden ist:

      • Stackdriver Logging API – Nur Schreiben
      • Stackdriver Logging API – Voll
      • Cloud Platform – Aktiviert

      Wenn die erforderlichen Bereiche fehlen, erstellen Sie den Knotenpool neu. Sie können Zugriffsbereiche für einen vorhandenen Knotenpool nicht ändern.

  2. Erstellen Sie bei Bedarf einen neuen Knotenpool mit dem erforderlichen Bereich:

    1. Kehren Sie zur Seite mit den Clusterdetails für den Cluster zurück, den Sie ändern möchten.
    2. Klicken Sie auf den Tab Knoten.
    3. Klicken Sie auf  Nutzerverwalteten Knotenpool erstellen.
    4. Füllen Sie den Abschnitt Knotenpooldetails aus.
    5. Klicken Sie in der linken Navigationsleiste auf Sicherheit.
    6. Wählen Sie im Abschnitt Zugriffsbereiche die Rollen aus, die Sie hinzufügen möchten:
      • Wenn Sie bestimmte Bereiche hinzufügen möchten, wählen Sie Zugriff für jede API festlegen aus.
      • Wenn Sie uneingeschränkten Zugriff zulassen möchten, wählen Sie Uneingeschränkten Zugriff auf alle Cloud-APIs zulassen aus.
    7. Konfigurieren Sie bei Bedarf weitere Abschnitte.
    8. Klicken Sie auf Erstellen.

  3. Migrieren Sie Ihre Arbeitslasten zum neuen Knotenpool. Nachdem Sie Arbeitslasten zum neuen Knotenpool migriert haben, werden Ihre Anwendungen auf Knoten ausgeführt, die die erforderlichen Bereiche zum Senden von Logs an Cloud Logging haben.

  4. Löschen Sie den alten Knotenpool:

    1. Kehren Sie zur Seite mit den Clusterdetails zurück und wählen Sie den Tab Knoten aus.
    2. Suchen Sie im Abschnitt Knotenpools nach dem alten Knotenpool.
    3. Klicken Sie neben dem Knotenpool auf  Löschen .
    4. Wenn Sie dazu aufgefordert werden, bestätigen Sie das Löschen, indem Sie den Namen des Knotenpools eingeben und auf Löschen klicken.

gcloud

  1. Prüfen Sie die Zugriffsbereiche des Knotenpools:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePools[].name,nodePools[].config.oauthScopes)"

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.
    • PROJECT_ID: Projekt-ID in Google Cloud .

    Prüfen Sie die Ausgabe für jeden Knotenpool. Achten Sie darauf, dass mindestens einer der erforderlichen Bereiche (https://www.googleapis.com/auth/logging.write, https://www.googleapis.com/auth/cloud-platform oder https://www.googleapis.com/auth/logging.admin) aufgeführt ist. Wenn die erforderlichen Bereiche fehlen, erstellen Sie den Knotenpool neu. Sie können die Zugriffsbereiche eines vorhandenen Knotenpools nicht ändern.

  2. Erstellen Sie bei Bedarf einen neuen Knotenpool mit dem erforderlichen Bereich:

    gcloud container node-pools create NEW_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --scopes=https://www.googleapis.com/auth/logging.write,OTHER_SCOPES

    Ersetzen Sie Folgendes:

    • NEW_NODE_POOL_NAME ist der Name für den neuen Knotenpool.
    • OTHER_SCOPES: Eine durch Kommas getrennte Liste aller anderen Bereiche, die für Ihre Knoten erforderlich sind. Wenn Sie keine anderen Bereiche benötigen, lassen Sie diesen Platzhalter und das vorangehende Komma weg.

  3. Migrieren Sie Ihre Arbeitslasten zum neuen Knotenpool. Nachdem Sie Arbeitslasten zum neuen Knotenpool migriert haben, werden Ihre Anwendungen auf Knoten ausgeführt, die die erforderlichen Bereiche zum Senden von Logs an Cloud Logging haben.

  4. Löschen Sie den alten Knotenpool:

    gcloud container node-pools delete OLD_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID

Berechtigungen des Knotendienstkontos prüfen

Knoten verwenden ein Dienstkonto zur Authentifizierung bei Google Cloud -Diensten. Dieses Konto benötigt bestimmte IAM-Berechtigungen zum Schreiben von Logs.

Symptome:

  • Auf Knoten fehlen Logs.
  • Wenn Sie die Logs des Logging-Agents (z. B. Fluent Bit) untersuchen, werden möglicherweise Berechtigungsfehler wie die Codes 401 oder 403 angezeigt, wenn Sie versuchen, in Cloud Logging zu schreiben.
  • Möglicherweise wird in der Google Cloud -Konsole eine Grant Critical Permissions to Node Service Account-Benachrichtigung für den Cluster angezeigt.

Ursache:

Dem Dienstkonto, das von den Knoten des Knotenpools verwendet wird, fehlen die erforderlichen IAM-Berechtigungen zum Schreiben von Logs in Cloud Logging. Für Knoten ist ein Dienstkonto mit der Rolle logging.logWriter erforderlich, die die Berechtigung logging.logEntries.create enthält.

Außerdem muss für GKE-Versionen 1.33 oder höher dem GKE-Standarddienst-Agent für Knoten (service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com) mindestens die Rolle „Kubernetes Default Node Service Agent“ (roles/container.defaultNodeServiceAgent) zugewiesen sein. Mit dieser Rolle kann GKE Knotenressourcen und ‑vorgänge verwalten, einschließlich Logging-Komponenten.

Lösung:

So überprüfen Sie die Berechtigungen und weisen die erforderlichen Rollen zu, falls sie fehlen:

  • Berechtigung des Dienstkontos des Knotens prüfen
  • Prüfen Sie, ob der GKE-Dienst-Agent die erforderliche Rolle hat.

Berechtigung des Knotendienstkontos prüfen

Das Knotendienstkonto ist das Konto, das Ihr Knoten zur Authentifizierung und zum Senden von Logs verwendet. So können Sie dieses Dienstkonto identifizieren und prüfen, ob es die erforderliche Berechtigung roles/logging.logWriter hat:

  1. Wählen Sie eine der folgenden Optionen aus, um das vom Knotenpool verwendete Dienstkonto zu ermitteln:

    Console

    1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf.

      Zur Seite "Kubernetes-Cluster"

    2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie untersuchen möchten.

    3. Führen Sie je nach Clustermodus einen der folgenden Schritte aus:

      • Führen Sie für Standardcluster die folgenden Schritte aus:

        1. Klicken Sie auf den Tab Knoten.
        2. Klicken Sie in der Tabelle Knotenpools auf einen Knotenpoolnamen. Die Seite mit den Knotenpooldetails wird geöffnet.
        3. Suchen Sie im Abschnitt Sicherheit nach dem Feld Dienstkonto.

      • Führen Sie für Autopilot-Cluster die folgenden Schritte aus:

        1. Wechseln Sie zum Tab Details.
        2. Suchen Sie im Abschnitt Sicherheit nach dem Feld Dienstkonto.

      Wenn der Wert im Feld Dienstkonto default ist, verwenden Ihre Knoten das Compute Engine-Standarddienstkonto. Wenn der Wert in diesem Feld nicht default ist, verwenden Ihre Knoten ein benutzerdefiniertes Dienstkonto. Eine Anleitung zum Zuweisen der erforderlichen Rolle zu einem benutzerdefinierten Dienstkonto finden Sie unter IAM-Dienstkonten mit geringsten Berechtigungen verwenden.

    gcloud

    Führen Sie je nach Clustertyp den folgenden Befehl aus:

    Standardcluster 

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(config.serviceAccount)"

    Ersetzen Sie Folgendes:

    • NODE_POOL_NAME: Der Name des Knotenpools.
    • CLUSTER_NAME: Der Name Ihres Standardclusters.
    • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.
    • PROJECT_ID: Ihre Google CloudProjekt-ID.

    Wenn die Ausgabe default ist, verwendet der Knotenpool das Compute Engine-Standarddienstkonto. Wenn der Wert nicht default ist, verwenden Ihre Knoten ein benutzerdefiniertes Dienstkonto. Eine Anleitung zum Zuweisen der erforderlichen Rolle zu einem benutzerdefinierten Dienstkonto finden Sie unter IAM-Dienstkonten mit geringsten Berechtigungen verwenden.

    Autopilot-Cluster 

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePoolDefaults.nodeConfigDefaults.serviceAccount)"

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Autopilot-Clusters.
    • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.
    • PROJECT_ID: Ihre Google Cloud Projekt-ID.

    Wenn die Ausgabe default ist, verwendet der Knotenpool das Compute Engine-Standarddienstkonto. Wenn der Wert nicht default ist, verwenden Ihre Knoten ein benutzerdefiniertes Dienstkonto. Eine Anleitung zum Zuweisen der erforderlichen Rolle zu einem benutzerdefinierten Dienstkonto finden Sie unter IAM-Dienstkonten mit geringsten Berechtigungen verwenden.

    Ausführlichere Skripts zum Ermitteln fehlender Berechtigungen finden Sie unter Alle Knotendienstkonten mit fehlenden Berechtigungen ermitteln.

  2. GKE sucht automatisch nach fehlenden Berechtigungen und gibt Empfehlungen. Wenn Sie Empfehlungen verwenden möchten, um nach fehlenden Berechtigungen zu suchen, wählen Sie eine der folgenden Optionen aus:

    Console

    1. Suchen Sie auf der Seite Kubernetes-Cluster nach der Spalte Benachrichtigungen.
    2. Sehen Sie sich in der Spalte Benachrichtigungen die Empfehlung Kritische Berechtigungen erteilen an. Diese Empfehlung bedeutet, dass die NODE_SA_MISSING_PERMISSIONS-Prüfung fehlgeschlagen ist.
    3. Klicken Sie auf die Empfehlung, falls sie angezeigt wird. Es öffnet sich ein Detailbereich, in dem die fehlenden Berechtigungen erläutert und die Schritte zur Behebung des Problems beschrieben werden.

    gcloud

    1. Empfehlungen für fehlende Dienstkontoberechtigungen auflisten:

      gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

    2. Analysieren Sie die Befehlsausgabe:

      • Wenn der Befehl eine leere Liste zurückgibt, hat der Recommender keine aktiven NODE_SA_MISSING_PERMISSIONS-Empfehlungen gefunden. Die geprüften Dienstkonten scheinen die erforderlichen Berechtigungen zu haben.

      • Wenn der Befehl einen oder mehrere YAML-Blöcke zurückgibt, hat der Empfehlungsdienst ein Berechtigungsproblem erkannt. Prüfen Sie die Ausgabe auf die folgenden Schlüsselfelder:

        • description: Hier finden Sie eine Zusammenfassung des Problems, z. B. dass Ihrem Knotendienstkonto die Rolle roles/logging.logWriter fehlt oder dass dem GKE-Dienst-Agent die Rolle roles/container.defaultNodeServiceAgent fehlt.
        • resource: Gibt den betroffenen Cluster an.
        • content.operations: Enthält die empfohlene Auflösung. In diesem Abschnitt finden Sie den genauen gcloud projects add-iam-policy-binding-Befehl, der zum Zuweisen der fehlenden Rolle erforderlich ist.

    Es kann bis zu 24 Stunden dauern, bis sich die letzten Änderungen im Empfehlungstool niederschlagen.

  3. Wenn Sie die Berechtigungen sofort prüfen und die Rolle zuweisen möchten, wählen Sie eine der folgenden Optionen aus:

    Console

    1. Rufen Sie in der Google Cloud Console die Seite IAM auf.

      IAM aufrufen

    2. Suchen Sie das vom Knotenpool verwendete Dienstkonto.

    3. Prüfen Sie in der Spalte Rolle, ob das Dienstkonto die Rolle Logautor (roles/logging.logWriter) hat.

    4. Wenn die Berechtigung fehlt, fügen Sie sie hinzu:

      1. Klicken Sie auf  Hauptkonto bearbeiten.
      2. Klicken Sie auf Weitere Rolle hinzufügen.
      3. Geben Sie im Suchfeld Logs Writer ein.
      4. Klicken Sie das Kästchen Log-Autor an und dann auf Übernehmen.
      5. Klicken Sie auf Speichern.

    gcloud

    1. Aktuelle Rollen für das Knotendienstkonto prüfen:

      gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:SERVICE_ACCOUNT_EMAIL"

    2. Wenn sie fehlt, weisen Sie die Rolle logging.logWriter zu:

      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/logging.logWriter"

Berechtigungen des GKE-Dienst-Agents prüfen

Wenn weiterhin Logs fehlen und Sie Version 1.33 oder höher verwenden, prüfen Sie, ob der von Google verwaltete Agent, mit dem GKE Ihre Knotenkomponenten verwaltet, die erforderliche Berechtigung hat:

  1. So ermitteln Sie die E-Mail-Adresse des Dienst-Agents:

    gcloud projects describe PROJECT_ID --format="value(projectNumber)"

    Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID. Notieren Sie sich die Ausgabe.

    Die E-Mail-Adresse des GKE-Dienst-Agents lautet: service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

  2. Wenn Sie Empfehlungen verwenden möchten, um nach fehlenden Berechtigungen zu suchen, wählen Sie eine der folgenden Optionen aus:

    Console

    1. Suchen Sie auf der Seite Kubernetes-Cluster nach der Spalte Benachrichtigungen.
    2. Sehen Sie sich die Spalte für die Empfehlung Wichtige Berechtigungen erteilen an.
    3. Klicken Sie auf die Empfehlung, falls sie angezeigt wird. Es öffnet sich ein Detailbereich, in dem die fehlenden Berechtigungen erläutert und die Schritte zur Behebung des Problems beschrieben werden.

    gcloud

    1. Empfehlungen für fehlende Dienstkontoberechtigungen auflisten:

      gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

    2. Analysieren Sie die Befehlsausgabe. Sehen Sie sich die Ausgabe an, um eine Beschreibung zu finden, die angibt, dass dem GKE-Dienst-Agent (gcp-sa-gkenode) die Rolle roles/container.defaultNodeServiceAgent fehlt.

  3. Wenn Sie die Berechtigungen sofort prüfen und die Rolle zuweisen möchten, wählen Sie eine der folgenden Optionen aus:

    Console

    1. Rufen Sie in der Google Cloud Console die Seite IAM auf.

      IAM aufrufen

    2. Geben Sie im Feld Filter die E-Mail-Adresse des GKE-Dienst-Agents ein und drücken Sie die Eingabetaste.

    3. Prüfen Sie in der gefilterten Liste, ob der Dienst-Agent mindestens die Rolle „Kubernetes Default Node Service Agent“ (roles/container.defaultNodeServiceAgent) hat.

    4. Wenn die Rolle fehlt, weisen Sie sie zu:

      1. Klicken Sie neben dem Dienst-Agent auf  Hauptkonto bearbeiten.
      2. Klicken Sie auf Rollen hinzufügen.
      3. Geben Sie im Suchfeld Kubernetes Default Node Service Agent ein und wählen Sie die Rolle aus.
      4. Klicken Sie auf Speichern.

    gcloud

    1. Prüfen Sie, ob die Rolle roles/container.defaultNodeServiceAgent an den Dienst-Agent gebunden ist:

      gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com"

      Suchen Sie in der Ausgabe nach roles/container.defaultNodeServiceAgent.

    2. Wenn die Rolle fehlt, weisen Sie die Rolle „Kubernetes Default Node Service Agent“ zu:

      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAgent"

Ressourcen- und Leistungsprobleme beheben

Wenn Logs zeitweise fehlen oder von Knoten mit hohem Traffic verworfen werden, ist die Ursache möglicherweise keine Fehlkonfiguration, sondern ein Leistungsproblem. In den folgenden Abschnitten erfahren Sie, wie Sie prüfen können, ob Ihr Projekt API-Kontingente überschreitet oder ob ein hohes Logvolumen die Agents auf bestimmten Knoten überfordert.

Kontingentnutzung der Cloud Logging API untersuchen

Zum Schutz des Dienstes erzwingt Cloud Logging ein Schreibkontingent für alle Projekte, das das Gesamtvolumen der Logs begrenzt, die Cloud Logging pro Minute aufnehmen kann.

Symptome:

  • Protokolle fehlen zeitweise oder vollständig.
  • In den Logs des Knotens oder des Logging-Agents werden RESOURCE_EXHAUSTED-Fehler im Zusammenhang mit logging.googleapis.com angezeigt.

Ursache:

Das Projekt überschreitet das Kontingent für Cloud Logging API-Schreibanfragen. Dieses Problem verhindert, dass der Logging-Agent Logs sendet.

Lösung:

So prüfen Sie die Kontingentnutzung und fordern eine Erhöhung an:

  1. Rufen Sie in der Google Cloud Console die Seite Kontingente auf.

    Zu „Kontingente“

  2. Geben Sie im Feld Filter Cloud Logging API ein und drücken Sie die Eingabetaste.

  3. Suchen Sie in der gefilterten Liste nach dem Kontingent für Log-Schreibvorgänge (Bytes pro Minute und Region) für die Region, in der sich Ihr Cluster befindet.

  4. Sehen Sie sich die Werte in der Spalte Aktuelle Nutzung in Prozent an. Wenn die Nutzung das Limit erreicht oder fast erreicht hat, haben Sie das Kontingent wahrscheinlich überschritten.

  5. Wenn Sie eine Erhöhung anfordern möchten, klicken Sie auf Kontingent bearbeiten und folgen Sie der Anleitung. Weitere Informationen finden Sie unter Kontingente aufrufen und verwalten.

Um die Nutzung zu reduzieren, können Sie Logs ausschließen oder die Ausführlichkeit von Logs in Anwendungen reduzieren. Sie können auch Benachrichtigungsrichtlinien einrichten, um benachrichtigt zu werden, bevor das Limit erreicht wird.

Knotendurchsatz und Ressourcennutzung untersuchen

Der GKE-Logging-Agent auf jedem Knoten hat ein eigenes Durchsatzlimit, das überschritten werden kann.

Symptome:

Logs von bestimmten Knoten fehlen zeitweise oder werden verzögert, insbesondere bei hoher Clusteraktivität oder starker Nutzung von Knotenressourcen.

Ursache:

Der GKE-Logging-Agent hat ein Standarddurchsatzlimit (ca. 100 KBps pro Knoten). Wenn Anwendungen auf einem Knoten Logs schneller als dieses Limit generieren, kann es sein, dass der Agent Logs verwirft, auch wenn das API-Gesamtkontingent des Projekts nicht überschritten wird. Sie können den Logging-Durchsatz von Knoten mit dem Messwert kubernetes.io/node/logs/input_bytes im Metrics Explorer überwachen.

Logs fehlen möglicherweise auch, wenn der Knoten stark durch CPU oder Arbeitsspeicher ausgelastet ist und nicht genügend Ressourcen für die Verarbeitung von Logs durch den Agenten vorhanden sind.

Lösung:

Wählen Sie eine der folgenden Optionen aus, um den Durchsatz zu reduzieren:

Standardcluster

Probieren Sie die folgenden Lösungen aus:

  • Logging mit hohem Durchsatz aktivieren: Diese Funktion erhöht die Kapazität pro Knoten. Weitere Informationen finden Sie unter Durchsatz des Cloud Logging-Agent anpassen.

  • Logvolumen reduzieren: Analysieren Sie die Muster der Anwendungsprotokollierung. Reduzieren Sie unnötige oder übermäßig ausführliche Protokollierung.

  • Benutzerdefinierten Logging-Agent bereitstellen: Sie können Ihr eigenes benutzerdefiniertes Fluent Bit-DaemonSet bereitstellen und verwalten, sind dann aber für dessen Konfiguration und Wartung verantwortlich.

  • Knotenressourcennutzung prüfen: Auch wenn das Protokollvolumen innerhalb der Grenzwerte liegt, sollten Sie prüfen, ob die Knoten stark durch CPU oder Arbeitsspeicher belastet werden. Unzureichende Knotenressourcen können die Fähigkeit des Logging-Agents beeinträchtigen, Logs zu verarbeiten und zu senden. Sie können Messwerte wie kubernetes.io/node/cpu/core_usage_time und kubernetes.io/node/memory/used_bytes im Metrics Explorer prüfen.

Autopilot-Cluster

Probieren Sie die folgenden Lösungen aus:

  • Logvolumen reduzieren: Analysieren Sie die Logging-Muster Ihrer Anwendung. Reduzieren Sie unnötige oder übermäßig ausführliche Protokollierung. Achten Sie darauf, dass Logs nach Möglichkeit strukturiert sind, da diese Art von Logs eine effiziente Verarbeitung ermöglicht. Schließen Sie Logs aus, die nicht unbedingt erforderlich sind.

  • Anwendungsleistung optimieren: Da Knotenressourcen in Autopilot-Clustern verwaltet werden, sollten Sie darauf achten, dass Ihre Anwendungen nicht übermäßig viel CPU oder Arbeitsspeicher verbrauchen, da dies sich indirekt auf die Leistung von Knotenkomponenten wie dem Logging-Agent auswirken könnte. Sie verwalten Knoten zwar nicht direkt, die Effizienz der Anwendung wirkt sich jedoch auf den allgemeinen Knotenstatus aus.

Probleme mit Filtern und Anwendungen beheben

Wenn Ihre Anwendung Logs erfolgreich generiert, diese aber trotzdem nicht in Cloud Logging angezeigt werden, liegt das Problem häufig an der Filterung oder am Logging-Verhalten der Anwendung. In den folgenden Abschnitten werden Probleme wie Filter zum Ausschließen von Logs, Pufferung auf Containerebene, restriktive Suchanfragen und Anwendungen, die nicht in stdout oder stderr schreiben, behandelt.

Logausschluss-Filter untersuchen

Im Log-Explorer werden nur Logs angezeigt, die allen Filtern in Ihrer Abfrage und dem ausgewählten Zeitraum entsprechen.

Symptome:

Bestimmte Logs, die bestimmten Kriterien entsprechen, fehlen in Cloud Logging, aber andere Logs aus denselben Quellen sind vorhanden.

Ursache:

Log-Ausschlussfilter werden in Ihren Cloud Logging-Senken definiert (häufig in der Senke _Default). Bei diesen Regeln werden Logs, die bestimmten Kriterien entsprechen, automatisch verworfen, auch wenn sie vom Knoten erfolgreich gesendet wurden.

Lösung:

Wählen Sie eine der folgenden Optionen aus, um Ausschlussfilter zu überprüfen und zu ändern:

Console

  1. Rufen Sie in der Google Cloud Console die Seite Logs Router auf.

    Zu Logs Router

  2. Problematischen Filter identifizieren:

    1. Klicken Sie für jede Senke (außer der _Required-Senke, für die keine Ausschlussfilter festgelegt werden können) auf  Weitere Aktionen und wählen Sie Senkendetails ansehen aus.
    2. Sehen Sie sich die Anfragen im Abschnitt Ausschlussfilter an. Vergleichen Sie die Filterlogik mit den Attributen der fehlenden Logs (z. B. Ressourcentyp, Labels oder Keywords).
    3. Kopieren Sie die Abfrage für den Ausschlussfilter.

    4. Rufen Sie die Seite Log-Explorer auf.

      Zum Log-Explorer

    5. Fügen Sie die Ausschlussfilterabfrage in den Abfragebereich ein und klicken Sie auf Abfrage ausführen.

    6. Überprüfen Sie die Ergebnisse. Die angezeigten Logs sind diejenigen, die durch den Filter ausgeschlossen würden. Wenn Ihre fehlenden Logs in diesen Ergebnissen angezeigt werden, ist dieser Filter wahrscheinlich die Ursache.

  3. Filter deaktivieren oder bearbeiten:

    1. Kehren Sie zur Seite Log-Router zurück.
    2. Klicken Sie für die Senke mit dem verdächtigen Filter auf  Weitere Aktionen und wählen Sie Senke bearbeiten aus.
    3. Suchen Sie den Abschnitt Auswählen zum Filtern aus der Senke und den Ausschlussfilter.
    4. Sie können entweder auf Deaktivieren klicken, um den Filter zu deaktivieren, oder die zugehörige Abfrage ändern, um sie genauer zu fassen.
    5. Klicken Sie auf Senke aktualisieren. Änderungen gelten für neue Logs.

gcloud

  1. Alle Senken im Projekt auflisten:

    gcloud logging sinks list --project=PROJECT_ID

  2. So rufen Sie die Ausschlussfilter der einzelnen Senken auf:

    gcloud logging sinks describe SINK_NAME --project=PROJECT_ID

    Sehen Sie sich in der Ausgabe den Abschnitt exclusions an. Vergleichen Sie die Filterlogik mit den Attributen der fehlenden Logs (z. B. Ressourcentyp, Labels oder Keywords).

  3. So ändern Sie Ausschlüsse:

    1. Exportieren Sie die Konfiguration des Senken in eine lokale Datei (z. B. sink-config.yaml):

      gcloud logging sinks describe SINK_NAME \
    --format=yaml > sink-config.yaml

    2. Öffnen Sie die Datei sink-config.yaml in einem Texteditor.

    3. Suchen Sie den Bereich exclusions: und entfernen oder ändern Sie den problematischen Filter.

    4. Aktualisieren Sie die geänderte Senke:

      gcloud logging sinks update SINK_NAME sink-config.yaml \
    --project=PROJECT_ID

      Weitere Informationen zu diesem Befehl finden Sie in der Dokumentation zu gcloud logging sinks update.

Pufferung und Verzögerungen bei Containerlogs untersuchen

Anwendungen und Betriebssysteme verwenden häufig Pufferung, um Daten in Blöcken statt zeilenweise zu schreiben, was die Leistung verbessern kann.

Symptome:

  • Logs aus bestimmten Containern werden in Cloud Logging erst angezeigt, nachdem der Container beendet wurde, oder es gibt eine erhebliche Verzögerung bei der Anzeige der Logs.
  • Manchmal sind Logs unvollständig.

Ursache:

Dieses Problem wird häufig durch das Puffern von Logs verursacht. Obwohl die Standardausgabe (stdout) in der Regel zeilenweise gepuffert wird, wenn sie mit einem Terminal verbunden ist, ändert sich dieses Verhalten, wenn die Ausgabe weitergeleitet wird. Wenn die Logs oder Startskripts einer Anwendung in einem Container stdout an andere Befehle (z. B. my-app | grep ...) weiterleiten, kann die Ausgabe vollständig gepuffert werden. Daher werden Protokolle zurückgehalten, bis der Puffer voll ist oder die Pipe geschlossen wird. Dieses Verhalten kann zu Verzögerungen oder Datenverlust führen, wenn der Container unerwartet beendet wird. Auch die anwendungsinterne Pufferung kann zu Verzögerungen führen.

Lösung:

Versuchen Sie Folgendes, um das Problem zu beheben:

  • stdout nicht weiterleiten: Ändern Sie nach Möglichkeit die Containereinstiegspunkte oder Anwendungsbefehle so, dass Logs direkt in stdout oder stderr geschrieben werden, ohne dass sie im Container über andere Befehle wie grep oder sed weitergeleitet werden.
  • Zeilenpufferung sicherstellen:
    • Wenn das Weiterleiten von Daten über Pipes unvermeidlich ist, verwenden Sie Tools, die Line-Buffering unterstützen. Verwenden Sie beispielsweise grep --line-buffered.
    • Bei benutzerdefinierten Anwendungen sollten Logs häufig geleert werden, idealerweise nach jeder Zeile, wenn in stdout geschrieben wird. Viele Logging-Bibliotheken haben Einstellungen zum Steuern des Pufferns.

  • Pufferungsverhalten testen: Stellen Sie das folgende Pod-Manifest bereit und beobachten Sie die Auswirkungen in den Logs mit dem Befehl kubectl logs -f buffered-pod. Sie können experimentieren, indem Sie die verschiedenen command-Arrays im buffered-container-Manifest aus- und einkommentieren:

    # buffered.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: run-script
data:
run.sh: |
    #!/bin/bash
    echo "Starting..."
    for i in $(seq 3600); do
    echo "Log ${i}"
    sleep 1
    done
    echo "Exiting."
---
apiVersion: v1
kind: Pod
metadata:
name: buffered-pod
spec:
containers:
    - name: buffered-container
    image: ubuntu  # Or any other image with bash

    # Case 1: Direct execution - line buffered by default to TTY
    # Logs appear immediately.
    command: ['/bin/bash', '-c', '/mnt/run.sh']

    # Case 2: Piped to grep - fully buffered by default
    # Logs might be delayed or appear in chunks.
    # command: ['/bin/bash', '-c', '/mnt/run.sh | grep Log']

    # Case 3: Piped to grep with --line-buffered
    # Logs appear immediately.
    # command: ['/bin/bash', '-c', '/mnt/run.sh | grep --line-buffered Log']

    volumeMounts:
        - name: scripts
        mountPath: /mnt
volumes:
    - name: scripts
    configMap:
        name: run-script
        defaultMode: 0777
restartPolicy: Never

Log-Explorer-Abfragen untersuchen

Wenn Sie sicher sind, dass Ihre Logs erfasst werden, aber Sie sie nicht finden können, liegt das möglicherweise an Ihrer Suchanfrage oder dem Zeitraum.

Symptome:

Erwartete Logs werden nicht in den Suchergebnissen angezeigt, obwohl Sie wissen, dass die Anwendung sie generiert.

Ursache:

Ihre Abfrage im Log-Explorer enthält möglicherweise Filter (z. B. für Namespaces, Labels, Ressourcentypen oder Text), die die gesuchten Logs versehentlich ausschließen.

Lösung:

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

    Zum Log-Explorer

  2. Klicken Sie auf Zeitraum auswählen. Auch wenn Sie glauben, zu wissen, wann die Logs erstellt wurden, sollten Sie einen deutlich größeren Zeitraum ausprobieren, um Timing-Probleme auszuschließen.

  3. Abfrage vereinfachen:

    1. Alle Filter löschen.

    2. Filtern Sie nur nach Ihrem Cluster:

      resource.type="k8s_container"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"

      Ersetzen Sie Folgendes:

      • CLUSTER_NAME: Der Name Ihres Clusters.
      • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.

    3. Klicken Sie auf Abfrage ausführen.

  4. Wenn die allgemeine Abfrage funktioniert, fügen Sie Ihre ursprünglichen Filter nach und nach wieder ein:

    • Ressourcentyp: Achten Sie darauf, dass Sie den richtigen Ressourcentyp verwenden. Filtern Sie beispielsweise nach k8s_container, obwohl Sie nach k8s_node filtern sollten?
    • Labels: Prüfen Sie die Schreibweise von resource.labels wie namespace_name, container_name oder benutzerdefinierten Labels.
    • Schweregrad: Achten Sie darauf, dass der Schweregrad (z. B. severity=ERROR) nicht zu restriktiv ist.
    • Text-Payload: Prüfen Sie die Suchbegriffe auf Rechtschreibfehler und zu restriktive Strings. Verwenden Sie beispielsweise : für „enthält“ anstelle von = für eine genaue Übereinstimmung (jsonPayload.message:"error" anstelle von jsonPayload.message="error").

  5. Prüfen Sie, ob bei Ihren Filtern die Groß-/Kleinschreibung berücksichtigt wird (Text ist in der Regel nicht case-sensitive, Labels aber möglicherweise schon). Achten Sie darauf, dass Werte keine verborgenen Zeichen oder zusätzlichen Leerzeichen enthalten, und prüfen Sie, ob Begriffe mit Sonderzeichen in Anführungszeichen gesetzt werden müssen.

  6. Sehen Sie sich die Zeitachse an. Plötzliche Rückgänge beim Hinzufügen eines Filters können Ihnen helfen, den problematischen Teil der Abfrage zu identifizieren.

Weitere Informationen zu effektiven Logabfragen finden Sie in der Cloud Logging-Dokumentation unter Logeinträge schnell finden.

Wenn Sie die Logs auch nach der Optimierung Ihrer Anfrage nicht finden können, liegt das Problem möglicherweise nicht an der Anfrage, sondern an einem Problem, das in anderen Abschnitten dieses Dokuments beschrieben wird.

Anwendungsspezifisches Logging-Verhalten untersuchen

Der GKE-Logging-Agent erfasst nur Logs, die in die Streams stdout und stderr geschrieben werden.

Symptome:

In Cloud Logging sind keine Logs für einen bestimmten Pod oder Container sichtbar, obwohl andere Logs aus dem Cluster vorhanden sind.

Ursache:

Die Anwendung schreibt nicht in stdout oder stderr. Möglicherweise ist die Konfiguration so eingerichtet, dass Logs in eine Datei im Container geschrieben werden, wo der Logging-Agent sie nicht erfassen kann.

Möglicherweise werden in der Ausgabe der Anwendung auch JSON- und Nicht-JSON-Text gemischt. Der Parser des Logging-Agents erwartet ein einheitliches Format (JSON oder Text) von einem einzelnen Stream. Wenn eine für die JSON-Protokollierung konfigurierte Anwendung eine Nur-Text-Zeile ausgibt, kann dies den Parser unterbrechen und dazu führen, dass Protokolle verworfen oder falsch aufgenommen werden.

Lösung:

  1. Ermitteln Sie den Pod-Namen und den Namespace der Anwendung, deren Logs fehlen:

    kubectl get pods -n NAMESPACE_NAME

  2. Containerlogs prüfen:

    • Wenn der Pod einen einzelnen Container hat, führen Sie den folgenden Befehl aus:

      kubectl logs POD_NAME \
    -n NAMESPACE_NAME

      Ersetzen Sie Folgendes:

      • POD_NAME: der Name Ihres Pods.
      • NAMESPACE_NAME: der Namespace Ihres Pods.

    • Wenn der Pod mehrere Container hat, geben Sie den Containernamen an:

      kubectl logs POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME

      Ersetzen Sie CONTAINER_NAME durch den Namen des Containers im Pod.

    • Führen Sie den folgenden Befehl aus, um Logs in Echtzeit zu verfolgen:

      kubectl logs -f POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME

      Ersetzen Sie Folgendes:

      • POD_NAME: der Name Ihres Pods.
      • CONTAINER_NAME: Der Name des Containers im Pod.
      • NAMESPACE_NAME: der Namespace Ihres Pods.

  3. Ausgabe analysieren:

    • Wenn der Befehl kubectl logs keine Ausgabe hat oder die Befehlsausgabe nicht die erwarteten Logs enthält, liegt das Problem an der Anwendung selbst. Der Befehl kubectl logs liest direkt aus den Streams stdout und stderr, die von der Container-Laufzeit erfasst werden. Wenn hier keine Logs vorhanden sind, kann der Logging-Agent von GKE sie nicht sehen.

      Ändern Sie den Code oder die Konfiguration Ihrer Anwendung, damit nicht mehr in eine Datei geschrieben wird, sondern alle Meldungen direkt in stdout (für reguläre Logs) und stderr (für Fehlerlogs) protokolliert werden.

    • Wenn Sie eine Mischung aus JSON-Strings und Nur-Text-Zeilen sehen, deutet diese Ausgabe auf ein Problem mit dem gemischten Format hin. Konfigurieren Sie Ihre Anwendung so, dass nur gültige einzeilige JSON-Objekte in stdout und stderr geschrieben werden.

    • Wenn der Befehl kubectl logs die erwarteten Logs anzeigt, liegt das Problem wahrscheinlich weiter unten in der Logging-Pipeline (z. B. Agent, Berechtigungen oder Cloud Logging-Dienst).

Probleme mit Plattformen und Diensten beheben

In den folgenden Abschnitten erfahren Sie, wie Sie Probleme untersuchen, die nicht direkt mit Ihrer Konfiguration zusammenhängen, z. B. Richtlinien zur Logaufbewahrung, Cloud Logging-Integrität oder nicht unterstützte GKE-Versionen.

Aufbewahrungsdauer für Logs untersuchen

Logs werden in Buckets gespeichert. Jeder Bucket hat einen Aufbewahrungszeitraum, der festlegt, wie lange die Logs aufbewahrt werden, bevor sie automatisch gelöscht werden.

Symptome:

Logs, die älter als ein bestimmtes Datum sind, fehlen.

Ursache:

Die gesuchten Logs sind älter als die Aufbewahrungsdauer für den Log-Bucket, an den sie weitergeleitet wurden.

Lösung:

Wählen Sie eine der folgenden Optionen aus, um die Aufbewahrungsdauer zu ermitteln und zu aktualisieren:

Console

  1. Ermitteln Sie den Bucket, an den Ihre GKE-Logs weitergeleitet werden:

    1. Rufen Sie in der Google Cloud Console die Seite Logs Router auf.

      Zu Logs Router

    2. Sehen Sie sich die Spalte Ziel an. Dort wird angezeigt, wohin die Logs weitergeleitet werden.

      Das Ziel sieht ungefähr so aus:

      logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

      Achten Sie auf die PROJECT_ID, LOCATION und BUCKET_ID.

      Logs werden häufig an den Bucket _Default weitergeleitet, können aber auch an andere Buckets weitergeleitet werden, wenn Sie benutzerdefinierte Senken konfiguriert haben.

  2. Aufbewahrungszeitraum für Log-Bucket prüfen:

    1. Rufen Sie in der Google Cloud Console die Seite Logspeicher auf.

      Zum Logspeicher

    2. Suchen Sie in der Senkenquelle nach den Buckets, die BUCKET_ID, LOCATION und PROJECT_ID entsprechen.

    3. Sehen Sie sich für jeden relevanten Bucket die Spalte Aufbewahrungsdauer an.

    4. Wenn die Logs, die Sie aufrufen möchten, älter als der Aufbewahrungszeitraum sind, wurden sie von Cloud Logging gelöscht. Wenn Sie eine längere Aufbewahrungsdauer benötigen, gehen Sie so vor:

      1. Klicken Sie für den Bucket, dessen Aufbewahrungszeitraum Sie verlängern möchten, auf  Weitere Aktionen.
      2. Wählen Sie Bucket bearbeiten aus und aktualisieren Sie den Aufbewahrungszeitraum. Mögliche Auswirkungen auf die Kosten

gcloud

  1. Ermitteln Sie den Bucket, an den Ihre GKE-Logs weitergeleitet werden:

    gcloud logging sinks list --project=PROJECT_ID

    Sehen Sie sich die Ausgabe an. Das Feld destination für jede Senke gibt an, wohin die Logs weitergeleitet werden. Das Zielformat für einen Log-Bucket lautet:

    logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

    Achten Sie auf die PROJECT_ID, LOCATION und BUCKET_ID.

    Logs werden oft an den Bucket _Default weitergeleitet.

  2. Aufbewahrungszeitraum für Log-Bucket prüfen:

    gcloud logging buckets describe BUCKET_ID \
    --location=LOCATION \
    --project=PROJECT_ID

    Suchen Sie in der Ausgabe nach dem Feld retentionDays. Wenn die benötigten Logs älter als der für retentionDays angegebene Wert sind, wurden sie von Cloud Logging gelöscht.

  3. Wenn Sie einen längeren Aufbewahrungszeitraum benötigen, aktualisieren Sie ihn:

    gcloud logging buckets update BUCKET_ID \
    --location=LOCATION \
    --retention-days=RETENTION_DAYS \
    --project=PROJECT_ID

    Ersetzen Sie Folgendes:

    • BUCKET_ID: die ID des Log-Buckets.
    • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Bucket.
    • RETENTION_DAYS: die Anzahl der Tage, für die Logs aufbewahrt werden sollen. Beachten Sie die potenziellen Auswirkungen auf die Kosten, wenn Sie die Aufbewahrungsdauer verlängern.
    • PROJECT_ID: Projekt-ID in Google Cloud .

Probleme mit dem Cloud Logging-Dienst und Verzögerungen bei der Aufnahme untersuchen

Manchmal kann es zu Problemen mit der Logging-Pipeline selbst kommen, entweder aufgrund einer dienstweiten Störung oder einer vorübergehenden, groß angelegten Verzögerung bei der Aufnahme.

Symptome:

  • Weitverbreiteter oder zeitweiser Logverlust in mehreren Projekten oder Clustern.
  • Die Logs werden im Log-Explorer mit erheblicher Verzögerung angezeigt.

Ursache:

  • Cloud Logging-Dienststörung: Eine seltene, dienstweite Störung kann die Aufnahme von Logs verhindern, was zu erheblichen Verzögerungen oder zum vollständigen Verlust von Logs führt.
  • Hohes Logvolumen: Auch ohne offizielle Störung kann ein hohes Logvolumen aus Ihrem Projekt oder Ihrer Region den Aufnahmedienst vorübergehend überlasten, sodass Logs verzögert angezeigt werden.

Lösung:

  • Den Status der Google Cloud -Dienste können Sie im Google CloudService Health-Dashboard prüfen. Suchen Sie nach offenen Vorfällen im Zusammenhang mit Cloud Logging oder GKE.

  • Berücksichtigen Sie potenzielle Verzögerungen bei der Aufnahme. Wenn Logs nicht sofort sichtbar sind und keine aktiven Vorfälle vorliegen, kann es einige Zeit dauern, bis sie aufgenommen werden, insbesondere wenn das Logvolumen hoch ist. Versuchen Sie es in einigen Minuten noch einmal.

Clusterversion untersuchen

GKE veröffentlicht regelmäßig neue Versionen, die Fehlerkorrekturen und Leistungsverbesserungen für Komponenten, einschließlich des Logging-Agents, enthalten.

Symptome:

Logging-Probleme fallen mit Einschränkungen der Clusterversion zusammen.

Ursache:

Auf dem Cluster wird möglicherweise eine ältere oder nicht unterstützte GKE-Version ausgeführt, die bekannte Probleme mit dem Logging-Agent hat oder in der bestimmte Logging-Funktionen fehlen.

Lösung:

So beheben Sie das Problem:

  1. So prüfen Sie die Version Ihres Clusters:

    gcloud container clusters describe CLUSTER_NAME \
    --location LOCATION \
    --format="value(currentMasterVersion)"

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.

  2. Vergleichen Sie diese Version mit dem GKE-Release-Zeitplan, um festzustellen, ob es sich um eine unterstützte Version handelt.

  3. Wenn der Cluster eine nicht unterstützte Version verwendet, führen Sie ein Upgrade des Clusters durch.

Nächste Schritte

  • Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Hilfe, z. B. zu den folgenden Themen: