3.1 Was ist Troubleshooting
Die Fehlersuche ist eine Form der Problemlösung, die oft zur Reparatur von fehlerhaften Produkten oder Prozessen an einer Maschine oder einem System angewandt wird. Es ist eine logische, systematische Suche nach der Ursache eines Problems, um es zu lösen und das Produkt oder den Prozess wieder funktionsfähig zu machen. – Wikipedia
Inhalt
Was ist Troubleshooting
Troubleshooting ist nichts anderes als bei einem Problem (Fehlermeldung) die Ursache zu finden.
Für diese Problemsuche reichen meistens Linux Bordmitttel aus. In diesem Lab werden einige dieser Bordmittel vorgestellt.
Wann braucht man es
Wie erwähnt ist Troubleshooting das finden der Ursache eines Problems. Das bedeutet, sobald man eine Fehlermeldung von dem System bekommt, ist Troubleshooting angesagt.
Ist es Zauberei
Kurz gesagt: Nein
Ein kleines Beispiel:
| |
Das System meldet das es das Erstellen des Ordners in /var verweigert.
Schauen wir uns kurz die Berechtigung an:
| |
Es scheint, dass der /var Ordner dem User root und der Gruppe root gehört. Alle anderen haben keine Schreibrechte auf dem /var Ordner.
(Wie man Berechtigungen liest, wird im Kapitel Dateien und Ordner Berechtigungen
erklärt)
Somit wurde das Problem gefunden, weshalb der Ordner nicht erstellt werden konnte. Das ist Troubleshooting.
Natürlich gibt es Probleme, die sehr komplex sind und es ist nicht immer einfach das Problem auf Anhieb zu finden. (Siehe auch Troubleshooting Konzepte)
Aber auch in solchen Fällen kann bereits ein einfaches Troubleshooting zum nächsten Puzzlestein führen.
Troubleshooting Konzepte
Top-Down Troubleshooting
Beispiel anhand Netzwerk Troubelshooting OSI-Modell :
Das Top-Down (Netzwerk) Troubleshooting verwendet das OSI-Modell als Leitprinzip. Eine der wichtigsten Eigenschaften des OSI-Modells besteht darin, dass jede Schicht für ihren Betrieb von den darunter liegenden Schichten abhängt. Das bedeutet, wenn eine Schicht als funktionsfähig erachtet wird, kann mit Sicherheit davon ausgegangen werden, dass alle darunter liegenden Schichten ebenfalls voll funktionsfähig sind.
Nehmen wir an, wir untersuchen ein Problem eines Benutzers, der eine bestimmte Website nicht aufrufen kann, und stellen fest, dass wir eine TCP-Verbindung auf Port 80 von diesem Host zum Server herstellen und eine Antwort vom Server erhalten können. In dieser Situation ist die Schlussfolgerung vernünftig, dass die Transportschicht und alle darunter liegenden Schichten zwischen dem Client und dem Server voll funktionsfähig sein müssen und dass es sich dabei höchstwahrscheinlich um ein Client- oder Serverproblem (höchstwahrscheinlich auf dem Application, Presentation, oder Session layer) und nicht um ein Netzwerkproblem handelt.
Wir müssen uns bewusst sein, dass in diesem Beispiel die Schlussfolgerung vernünftig ist, dass die Schichten 1 bis 4 voll funktionsfähig sein müssen, aber dies ist kein endgültiger Beweis dafür. Beispielsweise könnten nicht fragmentierte Pakete korrekt geroutet werden, während fragmentierte Pakete fallen gelassen werden. Die TCP-Verbindung zu Port 80 könnte ein solches Problem nicht aufdecken.
Im wesentlichen besteht das Ziel des Top-Down Ansatzes darin, die höchste OSI-Schicht zu finden, die noch funktioniert. Alle Geräte und Prozesse, die auf dieser Schicht oder den darunter liegenden Schichten arbeiten, werden dann aus dem Umfang der Fehlerbehebung eliminiert. Es dürfte klar sein, dass dieser Ansatz am effektivsten ist, wenn das Problem auf einer der höheren OSI-Schichten liegt.
Es ist auch einer der einfachsten Ansätze zur Fehlerbehebung, da von Benutzern gemeldete Probleme in der Regel als Probleme der Anwendungsschicht definiert werden, so dass es ganz natürlich ist, den Fehlerbehebungsprozess auf dieser Schicht zu beginnen. Ein Nachteil bei diesem Ansatz ist, dass Sie Zugriff auf die Software des Application Layer des Kunden haben müssen, um den Fehlerbehebungsprozess einzuleiten, und wenn die Software nur auf einer kleinen Anzahl von Rechnern installiert ist, sind Ihre Möglichkeiten zur Fehlerbehebung möglicherweise begrenzt.
Bottom-Up Troubleshooting
Beispiel anhand Netzwerk Troubelshooting OSI-Modell :
Das Bottom-Up (Netzwerk) Troubleshooting verwendet ebenfalls das OSI-Modell als Leitprinzip mit dem Physical Layer als Ausgangspunkt. Bei diesem Ansatz arbeiten wir uns Schicht für Schicht nach oben zum Application Layer vor und überprüfen, ob die relevanten Netzwerkelemente korrekt funktionieren. Wir versuchen, immer mehr potentielle Problemursachen zu beseitigen, so dass wir den Umfang der potentiellen Probleme eingrenzen können.
Nehmen wir an, wir untersuchen das Problem eines Benutzers, der eine bestimmten Website nicht aufrufen kann. Während wir das Problem überprüfen, stellen wir fest, dass der Computer des Benutzers nicht einmal in der Lage ist, eine IP-Adresse durch den DHCP-Prozess zu erhalten. In dieser Situation ist es vernünftig, untere Schichten des OSI-Modells zu vermuten und ein Bottom-Up Troubleshooting zu wählen.
Ein Vorteil des Bottom-Up Troubleshooting besteht darin, dass die gesamte anfängliche Fehlerbehebung im Netzwerk stattfindet, so dass der Zugriff auf Clients, Server oder Anwendungen erst in einer sehr späten Phase des Fehlerbehebungsprozesses erforderlich ist.
Das Bottom-Up Troubleshooting ist unter diesen Umständen sehr effektiv. Ein Nachteil dieser Methode ist, dass sie in grossen Netzwerken ein zeitaufwendiger Prozess sein kann, da viel Mühe mit dem Sammeln und Analysieren von Daten verbunden ist und man immer von der untersten Schicht ausgeht. Der beste Bottom-up-Ansatz besteht darin, zunächst den Umfang des Problems mit einer anderen Strategie zu reduzieren und dann für klar abgegrenzte Teile der Netzwerktopologie zum Bottom-Up Troubleshooting überzugehen.