System-Protokolle: Was macht der Uhle eigentlich?

Wenn ich jemandem erzähle, dass ich bei meiner Arbeit praktisch ganztägig System-Protokolle vor den Augen habe, ernte ich meist ziemlich viele fragende Blicke. Jetzt könnte ich sagen: Was denn, ihr habt doch gefragt. Aber das ist dann ja am Ende nicht fair. Denn woher soll jemand ohne tiefere Kenntnis von IT und auch ohne Kenntnis von dem, was Support bedeutet, wissen, was ich damit mache und wofür ich das mache und so. Deshalb muss ich da mal ein paar Takte dazu aufschreiben. Keine Angst, ich bewerfe euch da jetzt nicht so sehr mit Details.

Schick mir mal einen SDP-Report

Einen was? Wie ihr wisst, arbeite ich seit vielen Jahren im Support. Ich habe mich aus gesundheitlichen Gründen neu erfinden müssen. Davon habe ich ja schon mal erzählt. Und so wurde ich mit 32 Jahren Informatiker. Was habe ich mich schwer getan und mich durch die Umschulung geschleppt! Bis mir einer der Dozenten etwas von Protokollen und Systemmeldungen und all dem erzählt hatte. Und bis ich dann verstand, dass alles von allem abhängt. Jetzt will ich es nicht mehr anders.

Ich bin in meinem Job seit fast 13 Jahren dafür zuständig, dass Exchange Server und Windows Cluster wieder das tun, wofür sie gebaut wurden. Jetzt ist es so, dass es ja einen Grund geben muss, warum das nicht der Fall ist. Und den erzählen einem die System-Protokolle. Nehmen wir mal an, dass ein Cluster seine Verbindung zu den Ressourcen verliert. Und das vielleicht auch noch sporadisch. Kunden haben da meistens keine Zeit für die Analyse, also beauftragen sie uns.

Ich fordere mir dann meistens einen SDP-Report an. Der ist Teil des TroubleShootingScript Toolsets von Microsoft. Das enthält ein Script namens „Get-psSDP.ps1“. Mit verschiedenen Schaltern sammelt das Script all die Informationen ein, die der Support zur Analyse halt braucht, also auch die System-Protokolle. Am Ende können durchaus mehrere hundert MB und auch mal über 1 GB an Daten zusammenkommen. Das kann kein Mensch mehr überblicken. Aber ich weiß, wonach ich suchen muss.

Nein, das ist keine Hexerei, und ich bin auch nicht gut darin, mich als Mr. Allwissend hinzustellen. Das war harte Arbeit, verbunden mit vielen Kopfschmerzen, viel Lesen und Bewerten und all das. Und es hat eben mit unheimlich viel praktischer Erfahrung zu tun. Jedenfalls habe ich so gelernt, wie ich am besten feststelle, warum ein Cluster gerade das tut, was er tut, aber nicht das, was er soll. Das kann schon dauern. Aber oft bekommt man heraus, wo das Problem liegt.

System-Protokolle, so weit das Auge reicht

Solche Tools, die wir nutzen, sammeln ja allerlei Zeug zusammen. System-Protokolle ist dabei nicht nur das, was der Admin als Eventlog kennt. Es gehören auch Registry-Einstellungen dazu, Discovery-Informationen, Systeminformationen, riesige Batzen wie das Clusterlog, Firewall-Einstellungen et cetera peh peh. Wenn ich also einen Cluster analysiere, habe ich jede Menge zu tun. Dabei sage ich immer, dass ich bei einem Cluster die System-Protokolle von allen Knoten des Clusters brauche.

Warum? Naja, weil es herzlich wenig bringt, dass ich nur den auswerte, der „spinnt“. Ich habe es oft erlebt, dass ein Knoten durchdreht, weil auf einem anderen die Hölle los ist. Ich sag ja: Alles hängt von allem ab. Ich hatte mal einen Dateiserver-Cluster am Wickel, der deshalb verrückt gespielt hatte, weil ein virtueller Adapter an einem dahinter liegenden Gateway kaputt war. Das hast du dann ausschließlich an einer unregelmäßig wiederkehrenden Meldung im Clusterlog mitbekommen.

Jetzt fummelt mal hunderte Megabyte an Clusterlog durch. Wenn man da nicht mit einer gewissen Erfahrung ein wenig Struktur reinbringt, ist das einfach nicht zu machen. Wer soll denn viele Millionen Zeilen Text lesen? Da weißt du doch dann gar nicht mehr, was 10 Zeilen vorher stand. Es ist zwar ein Segen, dass es Tools wie dieses SDP gibt. Aber die Menge System-Protokolle macht es nicht unbedingt einfacher. Das musst du dann also sortiert bekommen.

Alter, wie machst du das denn?

Ich erzähle immer den Kunden, nachdem ich gesehen habe, wie viel sie mir über den Zaun geworfen haben, dass ich jetzt erstmal eine Weile brauchen werde. Darüber hinaus brauche ich Ruhe. Was glaubt ihr, was mein Home Office hier an Verbesserung gebracht hat! Naja, und dann brauche ich Zeiträume, wann das Fehlerbild aufgetreten ist. Und dann fange ich an und stresse meinen Computer, weil ich X System-Protokolle gleichzeitig offen habe.

Es sind ja manchmal spärlich verstreute Informationen, die am Ende den Ausschlag geben. Die stehen manchmal auch nur in IDs, die dann in den eingesammelten Registry-Auszügen zu finden sind. Ich suche also die Stecknadel im Heuhaufen. Das ist irgendwie mein Ding. Wenn ich mal Außenstehenden die Dinge zeige, die ich so analysiere, wird denen regelmäßig schlecht. Das mache ich dann mit Daten aus unserer Testumgebung, die ich irgendwann gezogen habe, nicht mit Kundendaten.

Jedenfalls lernst du irgendwann, wie du was zu bewerten hast. Dazu hast du tagelang Foren gewälzt, die Testumgebung gequält, ins Blaue geschossen. Support muss einem liegen. Du darfst nämlich nicht einfach so irgendwas ungeprüft raushauen, weil du das irgendwo mal gelesen hast. Am Ende musst du den Kunden dabei helfen, dass bei denen die Kontroll-Lampen von „Rot“ wieder auf „Grün“ gehen. Oder halt, dass die Cluster nicht mehr komplett verrückt spielen.

Und das bekommt man halt ohne System-Protokolle nicht hin. Darüber hinaus gibt es dann eben trotzdem noch Situationen, in denen man machtlos ist und einfach diese berühmte Stecknadel im Heuhaufen nicht findet. Vielleicht, weil andere Faktoren noch eine Rolle spielen. Aber wenigstens hast du es versucht. Das muss man dann dem Kunden erklären.

Aber es gibt doch ChatGPT

Wenn ich das immer höre: Beschreib doch der KI dein Problem, die hat dafür bestimmt eine Lösung. Natürlich! Hat sie bestimmt. Das geht dann so nach dem Motto: „Wir haben alles, was Sie brauchen. Was wir nicht haben, brauchen Sie auch nicht“. Nein, das hat nichts mit Support zu tun, lasst euch da nichts einreden. Was soll denn ChatGPT sagen, wenn ich dem Tool Auszüge der System-Protokolle ins Eingabefenster knalle? Vielleicht empfiehlt es ja Sachen, die die Situation noch verschlimmern?

Nein, es ist schon so, dass einem diese Dinge nicht weiterhelfen, wenn es um echte Support-Anfragen geht. Wir haben es getestet. Und so werde ich auch in Zukunft noch System-Protokolle von Clustern und Exchange Servern und all dem Firlefanz auswerten. Wer soll es denn sonst machen? Ach, und bei Cloud-Dingen ist es ja nicht anders. Warum gibt es wohl Tracing und all das Zeug? Man muss es halt auswerten und bewerten können. Und speziell letzteres wird ChatGPT nicht können. Oder sehe ich das falsch?

One Reply to “System-Protokolle: Was macht der Uhle eigentlich?”

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert