Loganalyse mit dem ELK-Stack (1)

Captains Log, Stardate 190601.

von Andreas Stolzenberger

Auf der Enterprise diktiert Captain Kirk sein Log einfach in den Computer. In heutigen IT-Infrastrukturen behält jeder Dienst und Rechner seine Loginformationen lieber für sich. Die Sternzeit ist reif für ein zentrales Logbuch mit Hilfe von Elasticsearch, Logstash und Kibana. Wir zeigen im ersten Teil dieser Workshopserie die Funktionen des ELK-Stacks und beschreiben, wie Sie einen ELK-Host aufsetzen und für die zentrale Log-Analyse konfigurieren.

Aus IT-Administrator 06/2019

Eine stillstehende IT kostet Firmen bares Geld, dabei können die Gründe für einen Ausfall vielfältig sein. Im Juni dreht sich der Schwerpunkt im ... (mehr)

Im täglichen IT-Betrieb kommt es immer wieder zu Ausfällen. Um die Ursache eines Problems zu finden, greifen Administratoren auf die Logs von Hard- und Software zurück. Je nachdem, wie ausführlich ein Dienst oder Treiber seine Tätigkeit protokolliert, kann ein Verwalter in den Logs die gesuchten "famous last words" des Prozesses vor dem Absturz vorfinden und daraus auf die Fehlerursache schließen.

Doch je mehr die IT-Installationen in die Cloudära voranschreiten, desto komplexer gestaltet sich die Loganalyse. Eine monolithische Anwendung, die Datenhaltung, Applikations- und Präsentationslogik und Benutzerinteraktionen unter einem Dach vereint, pflegt ein einzel- nes, zentrales Logbuch. Das vereinfacht in der Regel dem Administrator die Fehlersuche – allerdings rechtfertigt dieser eine kleine Vorteil kaum mehr die Investition in Monolithen.

Agile Infrastrukturen bestehen aus vielen miteinander kommunizierenden Microservices. Der Präsentations-Layer wie etwa ein Webfrontend läuft unter Umständen an einem anderen Ort als die Datenhaltung oder die eigentliche Business-Logik der Anwendung. Und zwischen den Modulen arbeiten wiederum andere Tools und Dienste, die die Kommunikation und Service-Konfiguration gewährleisten.

Die Suche nach einem Fehler zieht sich in so einer Umgebung durch eine ganze Reihe von Logs. Läuft ein Service zu langsam oder stockend, geht es ihm selbst möglichweise gar nicht schlecht. Vielleicht hat ja die Datenbank, mit der er kommuniziert, Probleme? Vielleicht geht es dieser aber auch prinzipiell gut, aber die Storage-LUN, auf der sie die Table-Spaces sichert, kämpft mit einem Problem des Raid-Controllers. Ausfälle einer Hardwarekomponente treten somit erst bei der Anwendung an einer ganz anderen Stelle in der IT-Infrastruktur zu Tage. Der alleinige Blick in die Applikations-Logs wird den wahren Fehler nicht zeigen.