Verlaufsanalyse mit Cloud Logging durchführen

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

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

Diese Informationen sind wichtig für Plattformadministratoren und -operatoren, die die Ursachen von clusterweiten Problemen analysieren, Änderungen prüfen und Trends im Systemverhalten verstehen müssen. Sie sind auch für Anwendungsentwickler unerlässlich, um anwendungsspezifische Fehler zu beheben, Anforderungspfade zu verfolgen 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 Unterstützung bei der Fehlerbehebung erfasst und aggregiert Cloud Logging automatisch mehrere wichtige Logtypen aus Ihren GKE-Clustern, containerisierten Apps und anderen Google Cloud Diensten:

  • Knoten- und Laufzeitlogs (kubelet, containerd): die Logs der zugrunde liegenden Knotendienste. Da kubelet den Lebenszyklus aller Pods auf dem Knoten verwaltet, sind seine Logs unerlässlich, um Probleme wie Containerstarts, Ereignisse mit unzureichendem Arbeitsspeicher (Out of Memory, OOM), Fehler bei Prüfungen und Fehler bei der Einbindung von Volumes zu beheben. Diese Logs sind auch entscheidend für die Diagnose von Problemen auf Knotenebene, z. B. wenn ein Knoten den Status NotReady hat.

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

  • App-Logs (stdout, stderr): die Standardausgabe- und Standardfehlerstreams aus Ihren containerisierten Prozessen. Diese Logs sind unerlässlich, um anwendungsspezifische Probleme wie Abstürze, Fehler oder unerwartetes Verhalten zu beheben.

  • 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 an den Kubernetes API-Server, was bei der Diagnose von Problemen hilfreich ist, die durch Konfigurationsänderungen oder unbefugten Zugriff verursacht wurden.

Häufige Fehlerbehebungsszenarien

Nachdem Sie ein Problem identifiziert haben, können Sie diese Logs abfragen, um herauszufinden, was passiert ist. Die Überprüfung von Logs kann Ihnen bei folgenden Problemen helfen:

  • Wenn ein Knoten den Status NotReady hat, prüfen Sie die Knotenlogs. Die kubelet- und containerd-Logs geben oft Aufschluss über die Ursache, z. B. Netzwerkprobleme oder Ressourcenbeschränkungen.
  • Wenn ein neuer Knoten nicht bereitgestellt und dem Cluster nicht hinzugefügt werden kann, prüfen Sie die Logs des seriellen Ports des Knotens. seriellen Ports. In diesen Logs werden frühe Boot- und Kubelet-Startaktivitäten erfasst, bevor die Logging-Agents des Knotens vollständig aktiv sind.
  • Wenn ein Pod in der Vergangenheit nicht gestartet wurde, prüfen Sie die App-Logs für diesen Pod auf Abstürze. Wenn die Logs leer sind oder der Pod nicht geplant werden kann, prüfen Sie die Audit-Logs auf relevante Ereignisse oder die Knotenlogs auf dem Zielknoten auf Hinweise auf Ressourcenengpässe oder Fehler beim Abrufen von Images.
  • Wenn ein wichtiges Deployment gelöscht wurde und niemand weiß warum, fragen Sie die Audit-Logs zur Administratoraktivität ab. Anhand dieser Logs können Sie ermitteln, welcher Nutzer oder welches Dienstkonto den API-Aufruf zum Löschen ausgeführt 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 Console 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, die Ihnen den Einstieg erleichtern:

    Filtertyp Beschreibung Beispielwert
    resource.type Der Typ der Kubernetes-Ressource. k8s_cluster, k8s_node, k8s_pod, k8s_container
    log_id Der Logstream aus 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 nach Text in dem Logeintrag. scale.down.error.failed.to.delete.node.min.size.reached

    Wenn Sie beispielsweise ein Problem mit einem bestimmten Pod beheben möchten, können Sie die 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 den Namespace nicht kennen, sehen Sie in der Spalte Namespace in der Ausgabe des Befehls kubectl get pods nach.

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

  3. Klicken Sie auf Abfrage ausführen.

  4. Wenn Sie die vollständige Lognachricht einschließlich der JSON-Nutzlast, der Metadaten und des Zeitstempels sehen möchten, klicken Sie auf den Logeintrag.

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

Nächste Schritte