Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Schreiben Sie einen Leitfaden zur Behebung, der Benutzern bei der Fehlersuche hilft.

Übersicht

SUSE® Observability bietet Monitore sofort einsatzbereit, die eine Überwachung häufiger Probleme in einem Kubernetes-Cluster ermöglichen. Diese Monitore enthalten ebenfalls sofort einsatzbereite Leitfäden zur Behebung von Problemen, die dazu dienen, Benutzer bei der genauen Fehlersuche zu unterstützen. Sie werden unter Verwendung bewährter Praktiken und des Wissens der Community erstellt. Befolgen Sie die Anweisungen auf dieser Seite, um zu lernen, wie Sie selbst einen effektiven Leitfaden zur Behebung von Problemen schreiben.

Richtlinien

  • Geben Sie Schritt-für-Schritt-Anleitungen, um einen Benutzer bei der Lösung des vom Monitor erkannten Problems zu unterstützen;

  • Stellen Sie sicher, dass die Anweisungen nach den wahrscheinlichsten Ursachen geordnet sind.

  • Falls möglich, fügen Sie Links zu relevanten Daten und/oder Ressourcen hinzu, um die Untersuchung zu beschleunigen.

  • Halten Sie es kurz und prägnant:

    • Vermeiden Sie übermäßige Erklärungen - fügen Sie Links zu unterstützenden Dokumentationen hinzu, falls dies der Fall ist;

    • Vermeiden Sie die Verwendung eines Inhaltsverzeichnisses und ähnlicher Inhaltsblöcke;

    • Vermeiden Sie eine Zusammenfassung desselben Inhalts;

  • Versuchen Sie, den Leitfaden strukturiert zu formatieren. Verwenden Sie:

    • Aufzählungspunkte

    • Nummerierung

    • kurze Sätze

    • Absätze

    • Inline-formatierte Beispiele

  • Wenn es offene Enden gibt (es könnten verschiedene Ursachen vorliegen, die noch unbekannt sind), geben Sie Hinweise zur Eskalation des Problems. Z. B. stellen Sie dem Benutzer einen Support-Link/ eine Nummer zur Verfügung, usw.

Beispiel für einen Leitfaden zur Behebung.

When a Kubernetes container has errors, it can enter into a state called CrashLoopBackOff, where Kubernetes attempts to restart the container to resolve the issue. The container will continue to restart until the problem is resolved.Take the following steps to diagnose the problem:

### Pod Events

Check the pod events to identify any explicit errors or warnings.
1. Go to the "Events" section in the middle of the [Pod highlight page](/#/components/\{{ componentUrnForUrl \}})
2. Check if there is are events like "BackOff", "FailedScheduling", "FailedAttachVolume" or "OOMKilled" in the Alert Category by clicking on 'Alerts'.
3. You can see the details of the event (click on the event) to give more information about the issue.
4. If the 'Show related event' option is enabled all events of resources related to this resource like a deployment will also show up and can give you a clue if any change on them is causing this issue. You can see this by checking if there is a correlation between the time of a deployment and a change of behaviour seen by the metrics and events of this pod.
For easy correlation you can use 'shift'-'click' to add markers to the different graph, log and event widgets.

### Container Logs
Check the container logs for any explicit errors or warnings
Inspect the [Logs](/#/components/\{{ componentUrnForUrl \}}#logs) of all the containers in this pod.
Search for hints in the logs by:
1.  Looking for changes in logging pattern, by looking at the number of logs per time unit (The histogram bars).
    In many cases the change in pattern will indicate what is going on.
    You can click-drag on the histogram bars to narrow the logs displayed to that time-frame.
2.  Searching for "Error" or "Fatal" in the search bar.
3.  Looking at the logs around the time that the monitor triggered

### Recent Changes
Look at the pod age in the "About" section on the [Pod highlight page](/#/components/\{{ componentUrnForUrl \}}) to identify any recent deployments that might have caused the issue
1. The "Age" is shown in the "About" section on the left side of the screen
2. If the "Age" and the time that the monitor was triggered are in close proximity then take a look at the most recent deployment by clicking on [Show last change](/#/components/\{{ componentUrnForUrl \}}#lastChange).

Links einfügen

Die Syntax, die wir verwenden, ist unterschiedlich für "Deep Links" und "In-Page Links". Die "Deep Links" leiten den Benutzer von der aktuellen Seite weiter, während die "In-Page Links" den Benutzer auf derselben Seite halten.

Deep Links

Um auf eine Perspektive (z. B. "Highlights", "Topologie", "Ereignisse", "Metriken") der aktuellen Ressource zu verlinken, verwenden Sie die folgende Syntax:

[highlight page](/#/components/\{{ componentUrnForUrl \}})
[topology](/#/components/{{ componentUrnForUrl }}/topology)
[events](/#/components/{{ componentUrnForUrl }}/events)
[metrics](/#/components/{{ componentUrnForUrl }}/metrics)

In-Page Links

Um auf zusätzliche Daten (z. B. "Protokolle anzeigen", "letzte Änderung anzeigen", "Status anzeigen", "Konfiguration anzeigen") der aktuellen Ressource zu verlinken, verwenden Sie die folgende Syntax:

[logs](/#/components/\{{ componentUrnForUrl \}}#logs)
[last change](/#/components/\{{ componentUrnForUrl \}}#lastChange)
[status](/#/components/\{{ componentUrnForUrl \}}#status)
[configuration](/#/components/\{{ componentUrnForUrl \}}#configuration)