Verlaufsanalyse mit Cloud Logging durchführen

Wenn ein Pod in Google Kubernetes Engine (GKE) fehlschlägt oder ein Dienst nicht wie erwartet funktioniert, ist es wichtig, die Abfolge der Ereignisse zu verstehen, die zum Problem geführt haben. Die Untersuchung des aktuellen Zustands reicht nicht immer aus, um die Ursache zu ermitteln. Daher sind Verlaufsdaten aus Protokollen von unschätzbarem Wert.

Auf dieser Seite erfahren Sie, wie Sie mit Cloud Logging vergangene Fehler untersuchen können, z. B. warum ein Pod nicht gestartet wurde oder wer eine kritische Bereitstellung gelöscht hat. Dazu fragen Sie GKE-Logs ab und analysieren sie.

Diese Informationen sind wichtig für Plattformadministratoren und ‑betreiber, die die Ursachen von clusterweiten Problemen analysieren, Änderungen prüfen und Trends beim Systemverhalten nachvollziehen müssen. Sie ist auch für Anwendungsentwickler unerlässlich, um anwendungsspezifische Fehler zu beheben, Anfragepfade nachzuvollziehen und zu verstehen, wie sich ihr Code im Laufe der Zeit in der GKE-Umgebung verhält. 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.

Wichtige Logtypen für die Fehlerbehebung

Zur Fehlerbehebung werden in Cloud Logging automatisch mehrere wichtige Logtypen aus Ihren GKE-Clustern, containerisierten Apps und anderenGoogle Cloud -Diensten erfasst und zusammengefasst:

  • Knoten- und Laufzeitlogs (kubelet, containerd): die Logs der zugrunde liegenden Knotendienste. Da kubelet den Lebenszyklus aller Pods auf dem Knoten verwaltet, sind die zugehörigen Logs für die Fehlerbehebung bei Problemen wie Containerstarts, OOM-Ereignissen (Out of Memory, fehlender Speicher), Prüfungsfehlern und Fehlern beim Einbinden von Volumes unerlässlich. Diese Logs sind auch entscheidend für die Diagnose von Problemen auf Knotenebene, z. B. bei einem Knoten mit dem Status NotReady.

    Da containerd den Lebenszyklus Ihrer Container verwaltet, einschließlich des Abrufens von Images, sind seine Logs entscheidend für die Fehlerbehebung von Problemen, die auftreten, bevor das Kubelet den Container starten kann. Die containerd-Logs helfen Ihnen, Probleme auf Knotenebene in GKE zu diagnostizieren, da sie die spezifischen Aktivitäten und potenziellen Fehler der Containerlaufzeit dokumentieren.

  • App-Logs (stdout, stderr): Die Standardausgabe- und Fehlerstreams aus Ihren containerisierten Prozessen. Diese Logs sind für die Fehlerbehebung von app-spezifischen Problemen wie Abstürzen, Fehlern oder unerwartetem Verhalten unerlässlich.

  • Audit-Logs: Diese Logs beantworten die Frage „Wer hat was, wo und wann getan?“ für Ihren Cluster. Sie verfolgen administrative Aktionen und API-Aufrufe, die an den Kubernetes API-Server gesendet werden. Das ist nützlich, um Probleme zu diagnostizieren, die durch Konfigurationsänderungen oder unbefugten Zugriff verursacht werden.

Häufige Fehlerbehebungsszenarien

Nachdem Sie ein Problem identifiziert haben, können Sie diese Logs abfragen, um herauszufinden, was passiert ist. Protokolle können Ihnen bei folgenden Problemen helfen:

  • Wenn ein Knoten den Status NotReady hat, sehen Sie sich die Knotenlogs an. Die Logs kubelet und containerd geben oft Aufschluss über die zugrunde liegende Ursache, z. B. Netzwerkprobleme oder Ressourcenbeschränkungen.
  • Wenn ein neuer Knoten nicht bereitgestellt werden kann und dem Cluster nicht beitreten kann, sehen Sie sich die Logs des seriellen Ports des Knotens an. In diesen Logs werden Aktivitäten beim frühen Start und beim Start von kubelet erfasst, bevor die Logging-Agents des Knotens vollständig aktiv sind.
  • Wenn ein Pod in der Vergangenheit nicht gestartet wurde, sehen Sie in den App-Logs für diesen Pod nach, ob Abstürze aufgetreten sind. Wenn die Logs leer sind oder der Pod nicht geplant werden kann, suchen Sie in den Audit-Logs nach relevanten Ereignissen oder in den Knoten-Logs auf dem Zielknoten nach Hinweisen auf Ressourcenengpässe oder Fehler beim Abrufen von Images.
  • Wenn eine kritische Bereitstellung gelöscht wurde und niemand weiß, warum, können Sie die Audit-Logs für Administratoraktivitäten abfragen. Anhand dieser Logs können Sie ermitteln, welcher Nutzer oder welches Dienstkonto den API-Aufruf zum Löschen ausgegeben hat. So haben Sie einen klaren Ausgangspunkt für Ihre Untersuchung.

Auf Logs zugreifen

Mit dem Log-Explorer können Sie GKE-Logs in der Google Cloud -Konsole abfragen, ansehen und analysieren. Der Log-Explorer bietet leistungsstarke Filteroptionen, mit denen Sie das Problem eingrenzen können.

So greifen Sie auf den Log-Explorer zu und verwenden ihn:

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

    Zum Log-Explorer

  2. Geben Sie im Bereich „Abfrage“ eine Abfrage ein. Verwenden Sie die Logging-Abfragesprache, um gezielte Abfragen zu schreiben. Hier sind einige gängige Filter für den Anfang:

    Filtertyp Beschreibung Beispielwert
    resource.type Der Typ der Kubernetes-Ressource. k8s_cluster, k8s_node, k8s_pod, k8s_container
    log_id Der Logstream der Ressource. stdout, stderr
    resource.labels.RESOURCE_TYPE.name Nach Ressourcen mit einem bestimmten Namen filtern
     Ersetzen Sie RESOURCE_TYPE durch den Namen der Ressource, die Sie abfragen möchten. Beispiel: namespace oder pod.    		 example-namespace-name, example-pod-name
    severity Der Schweregrad des Logs. DEFAULT: INFO, WARNING, ERROR, CRITICAL
    jsonPayload.message=~ Eine Suche nach regulären Ausdrücken im Text der Logmeldung. scale.down.error.failed.to.delete.node.min.size.reached

    Wenn Sie beispielsweise Probleme mit einem bestimmten Pod beheben möchten, können Sie seine Fehlerlogs isolieren. Wenn Sie nur Logs mit dem Schweregrad ERROR für diesen Pod sehen möchten, verwenden Sie die folgende Abfrage:

    resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
resource.labels.namespace_name="NAMESPACE_NAME"
severity=ERROR

    Ersetzen Sie Folgendes:

    • POD_NAME: der Name des Pods, bei dem Probleme auftreten.
    • NAMESPACE_NAME: der Namespace, in dem sich der Pod befindet. Wenn Sie nicht sicher sind, welcher Namespace verwendet wird, sehen Sie sich die Spalte Namespace in der Ausgabe des Befehls kubectl get pods an.

    Weitere Beispiele finden Sie in der Google Cloud Observability-Dokumentation unter Kubernetes-bezogene Abfragen.

  3. Klicken Sie auf Abfrage ausführen.

  4. Wenn Sie die vollständige Logmeldung mit JSON-Nutzlast, Metadaten und Zeitstempel sehen möchten, klicken Sie auf den Logeintrag.

Weitere Informationen zu GKE-Logs finden Sie unter GKE-Logs.

Nächste Schritte