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.

Fehlerbehebung

Kurzanleitung zur Fehlersuche

Hier ist eine Kurzanleitung zur Fehlersuche beim Start von SUSE Observability:

  1. Überprüfen Sie, ob die Installation erfolgreich abgeschlossen wurde und die Version aufgeführt ist:

    helm list --namespace suse-observability

  2. Überprüfen Sie, ob alle Pods im SUSE Observability-Namespace laufen:

    kubectl get pods

    Bei einer Erstimplementierung kann es vorkommen, dass Container in mehreren Pods mehrfach neu gestartet werden, da sie darauf warten, dass andere Pods starten und sich im ready Zustand befinden. Dies kann durch Verzögerungen bei der Planung und beim Herunterladen von Docker-Images verursacht werden.

    Pods, die sich im pending Zustand befinden, sind normalerweise ein Hinweis auf ein Problem:

    • Der Pod ist aufgrund von Ressourcenmangel im Cluster nicht einplanbar. Wenn ein Cluster-Auto-Scaler aktiv ist, kann er dies oft automatisch lösen, andernfalls ist manuelles Eingreifen erforderlich, um weitere Knoten zum Cluster hinzuzufügen.

    • Der Pod ist nicht einplanbar, es gibt Knoten, auf denen er passen würde, aber diese Knoten weisen taints auf, die der Pod nicht toleriert. Um dies zu lösen, können weitere Knoten hinzugefügt werden, die keine Taints haben, aber SUSE Observability kann auch konfiguriert werden, um bestimmte Taints zu tolerieren und auf den betroffenen Knoten zu laufen.

    • Der Pod wartet darauf, dass die Persistent Volumes (PVs) gemountet werden. Ein Grund kann sein, dass das SUSE Observability Helm-Chart keine storageClassName angibt, sondern darauf vertraut, dass der Cluster eine Standard-Speicherklasse hat. Wenn es keine Standard-Speicherklasse für den Cluster gibt, ist es erforderlich, eine Speicherklasse anzugeben über die Helm-Werte von SUSE Observability.

      Für Pods mit dem Zustand ImagePullBackOff überprüfen Sie auch die genaue Fehlermeldung, häufige Ursachen sind:

    • Ein falscher Benutzername/Passwort wurde verwendet, um die Images abzurufen.

    • Die Verbindung zur Docker-Registry ist fehlgeschlagen, dies kann auf Authentifizierungsprobleme oder Verbindungsprobleme (Firewalls, Air-Gapped-Installationen) zurückzuführen sein.

    • Ein Tippfehler in der überschriebenen URL der Docker-Image-Registry.

    Um eine detailliertere Ursache für die Zustände Pending, ImagePullBackOff oder CrashLoopBackOff herauszufinden, verwenden Sie diesen Befehl:

    +

    kubectl describe pod <pod-name>

    + Die Ausgabe enthält am Ende einen event Abschnitt, der normalerweise das Problem enthält. Es gibt auch einen State Abschnitt für jeden Container, der weitere Details zur Beendigung des Containers enthält.

  3. Wenn Sie ein Premiumkunde sind, wenden Sie sich an den SUSE Observability-Support unter https://scc.suse.com/, um Hilfe bei der Einrichtung von SUSE Observability in Ihrem lokalen Cluster zu erhalten. Verwenden Sie Support-Paket (Protokolle), um Informationen über Ihre Instanz für das Support-Team zu sammeln.

  4. Wenn das Problem leistungsbezogen ist, führen Sie Support-Paket (Leistung) aus, um aktiv die Leistung zu untersuchen.

  5. Falls die oben genannten Schritte das Problem nicht gelöst haben, steht ein erweiterter Fehlerbehebungsleitfaden zur Verfügung.