Bernd Zuther | Software Architect

Wie man im meinen Beitrag „OutOfMemoryError: Java Heapdump Analyse – Was tun? Wenn die Produktion spinnt!“ sehen kann, hat Softwareentwicklung manchmal auch etwas mit Datenanalyse zu tun. Bei der Heapdump Analyse arbeitet man mit einer großen Menge  Objekten und leidet aus Dominatorbäumen Metriken ab, um potentielle Memory Leaks aufzuspüren. Die Heapdump Analyse ist aber nur ein Beispiel dafür, dass ein Software Ingenieur auch in der Lage sein muss Datenanalysen durchzuführen.

Die Logdateianalyse ist ein weiteres Beispiel für eine Datenanalyse, um die ein Software Ingenieur früher oder später nicht herum kommen wird. Spätestens wenn sein Softwareprodukt in Produktion  geht, muss die Logdateianalyse zum Handwerkszeug eines Software Ingenieur gehören, um Fehler schneller zu erkennen und schneller auf Fehlverhalten der Software reagieren zu können.

„Was man nicht messen kann, kann man nicht lenken.“
Peter F. Drucker

Gerade in verteilen Software-Architekturen stellt die Logdateianalyse keine geliebte Aufgabe dar. Denn diese Aufgabe hat häufig damit zu tun, dass man sich auf vielen unterschiedlichen Servern einloggen muss, um händisch die Logdateien zu durchsuchen.

In diesem Beitrag geht es, um die Logdateianalyse. Ich möchte den ELK Stack (Elasticsearch, Logstash, Kibana) als Alternative zu dem kommerziellen Werkzeug Splunk vorstellen, dass einem das händische durchsuchen von Logdateien auf verschiedenen Server abnimmt. Der ELK Stack besteht aus mehren Komponenten, die Logdaten sammeln, indexieren und mit einer grafischen Oberfläche für eine schnelle und gezielte Analyse verfügbar machen.

Betrachten wir aber zunächst, wie Logdateianalyse abläuft, wenn man kein dediziertes Werkzeug dafür benutzt und finden heraus, welche Anforderungen sich aus der händischen Logdateianalyse an ein Logdateianalyse-Werkzeug ergeben.

Logdateianalyse

Bei der Logdateianalyse werden Logdateien eines Computersystems während eines gewissen Zeitraumes nach bestimmten Kriterien durchsucht. Bei vielen Softwaresystemen werden die unterschiedlichsten Ereignisse mitprotokolliert. Beispielsweise finden sich heutzutage bei nahezu allen Webserver, bei vielen Datenbanken und Firewalls Logdateien. Je nach Art, Inhalt und Umfang der Aufzeichnung in den Logdateien können durchaus  verschiedene Schlüsse gezogen werden. Die Logdateianalyse kann z.B.  als Grundlage für Benutzerfreundlichkeitsanalysen dienen oder  Aussagen über den Erfolg einer Marketingaktion liefern.

Eine Logdatei enthält meisten ein automatisch geführtes Protokoll aller oder bestimmter Aktionen von Prozessen, die in einem Computersystem ablaufen. Deshalb wir eine Logdatei häufig auch als Protokolldatei bezeichnet. Das folgende Listing zeigt die Zugriffsprotokolldatei eines Tomcat Anwendungsserver, dass alle Anfragen auf dem Webserver protokolliert:

0:0:0:0:0:0:0:1 - - [18/May/2014:15:42:38 +0200] "GET /pizza/assets/img/Pizza/spaghetti-with-clams.jpg HTTP/1.1" 200 23875
0:0:0:0:0:0:0:1 - - [18/May/2014:15:42:38 +0200] "GET /pizza/assets/img/Pizza/tuna.jpg HTTP/1.1" 200 79792
0:0:0:0:0:0:0:1 - - [18/May/2014:15:42:39 +0200] "GET /pizza/productdetail/capricciosa?2-1.ILinkListener-otherUsersAlsoViewedProducts-products-3-product-productDetailLink HTTP/1.1" 302 -
|      Data       |          Timestamp             |                                                              Data                                     Data                            |

Bei den einzelnen Einträgen in dem Zugriffsprotokoll handelt es sich um  unstrukturierte Daten. Ein Mensch erkennt zwar höchstwahrscheinlich auf den ersten Blick auf welche Webseiten zugegriffen wurden ist, aber was bedeuten die letzten beiden Zahlen in den Zugriffsprotokoll? Die Erste, der beiden letzten Zahlen, könnte den Statuscode des HTTP-Response darstellen, der vom Server ausgeliefert wird. Bei der letzten Zahl könnte es sich um die übertragenen Bytes handeln. Diese Information wird allerdings für den Mensch nicht auf den ersten Blick ersichtlich, sondern muss in die Spezifikation der Logdatei nachlesen werden, um mit Sicherheit sagen zu können, dass es sich bei der letzten Zahl um die übertragenen Bytes handelt. Ein Computer kann diese Verbindung nicht automatisch herstellen. Ein solches Log-Format verhindert, dass man die Request mit Statuscode 200 einfach zählen kann. Man muss zuerst die Zeilen mit dem Statuscode 200 extrahieren und kann dann die Zeilen zählen.

Allgemein gilt, dass unstrukturierte Daten digitalisierte Informationen sind, die in einer nicht formalisierten Struktur vorliegen. Durch die nicht formalisierte Struktur können Computerprogrammen nicht über eine einzelne Schnittstelle aggregiert auf diese Daten zugegriffen.

Was man in den Zugriffsprotokoll aber auch sehen kann, ist das ein Log-Eintrag immer aus einem Zeitstempel (Timestamp) und Daten (Data) besteht. Gelingt es  die unstrukturierte Daten in eine zumindest semistrukturierte Form bringen, die Struktur Informationen enthält (z.B. JSON oder XML), dann kann man  Leistungskennzahlen benennen und errechnen, wie es in Abbildung 1 dargestellt ist, die verschiedene HTTP-Response Stati über die Zeit zeigt.

Jetzt haben wir viel über eine einzelne Log-Datei gesprochen. Häufig bestehen moderne Web-Architekturen aus mehren Anwendungsservern. Auf den Anwendungsservern laufen auch mehrere Web-Anwendungen, die mit einer Vielzahl von Backendsystemen kommunizieren. Um nachvollziehen zu können, was bei Zusammenspiel der unterschiedlichen Softwarekomponenten eines Softwaresystems passiert, werden i.d.R auf den unterschiedlichen Anwendungsservern von den installierten Anwendungen Logdateien geschrieben.

bernd@mbp:/var/log/tomcat7$ ll
total 456
drwxr-x---  2 tomcat7 adm      4096 May 21 13:55 ./
drwxr-xr-x 12 root    root     4096 May 21 14:45 ../
-rw-r--r--  1 tomcat7 tomcat7 26547 May 21 14:45 catalina.2014-05-21.log
-rw-r--r--  1 tomcat7 tomcat 318574 May 21 14:45 catalina.out
-rw-r--r--  1 tomcat7 tomcat7  8825 May 21 14:45 localhost.2014-05-21.log
-rw-r--r--  1 tomcat7 tomcat7 17176 May 21 14:09 localhost_access_log.2014-05-21.txt
-rw-r--r--  1 tomcat7 tomcat7 65554 May 22 06:48 probe.log
bernd@mbp:/var/log/tomcat7$

Einen Blick in das Log-Verzeichnis des Tomcat-Anwendungsserver, zeigt, dass sich mehre Logdateien in dem Verzeichnis befinden. Mindestens mit den beiden Logdateien catalina.log und localhost_access_log.txt kann man immer rechnen. I.d.R gibt es aber noch viel mehr Logdateien in diesem Verzeichnis. Gehen wir der Einfachheit halber erst einmal nur von diesen beiden genannten Logdateien aus, dann hat man bei 10 Anwendungsservern schon 20 Logdateien, die bei der Logdateianalyse berücksichtigt werden müssen und ggf. alle durchsucht werden müssen, um ein Fehlverhalten des Softwaresystems besser verstehen zu können.

Ohne eine zentrale Logdaten-Speicherung bedeutet das häufig für einen Software Ingenieur, dass er sich auf 20 Servern über SSH anmelden musst und die Logdateien von Hand in der Konsole durchsuchen musst. Natürlich bietet die Unix-Shell eine Vielzahl an Programmen für die Datenanalyse, wie man in meinem Beitrag „Data Analysis with the Unix Shell“ sehen kann. Doch ist das händische Durchsuchen von Logdateien nicht sonderlich komfortabel und auch nicht wirklich schnell, da die unterschiedlichen Log-Files nicht indexiert sind und das Auffinden von Regulärer Ausdrücken in gigabyte–großen Logdateien schon eine Weile dauern kann.

Das folgende Listing verdeutlicht die Arbeit, die man machen muss, um Logdateien auf der Kommandozeile zu durchsuchen. Ziel ist es die Requests zu zählen, die erfolgreich bearbeitet wurden sind. In Zeile 4 ist ein Unix-Pipeline aus den beiden Unix-Befehlen grep und wc zu sehen. Mit dem Regex ‚“ 200 [0-9]‘ selektieren wir alle Zeilen in denen wir den Statuscode 200 finden. Diese Zeilen zählt uns dann das Kommando wc. Mit dieser Pipeline erhalten wir das Ergebnis 47 auf dem aktuellen Rechner, wenn wir das Ergebnis für einen gesamten Cluster haben wollen, dann müssen wir dieses Vorgehen auf allen anderen Rechnern im Cluster wiederholen und die einzelnen Ergebnisse entsprechend aggregieren.

bernd@mbp ~/tomcat/logs $ grep '" 200 [0-9]' localhost_access_log.2014-05-18.txt
0:0:0:0:0:0:0:1 - - [18/May/2014:15:42:34 +0200] "GET /pizza/assets/css/bootstrap.css HTTP/1.1" 200 129119
0:0:0:0:0:0:0:1 - - [18/May/2014:15:42:34 +0200] "GET /pizza/wicket/resource/com.comsysto.shop.ui.application.settings.AbstractJavaScriptLibrarySettings/jquery/jquery-1.9.1.min-ver-1400416490000.js HTTP/1.1" 200 92629
bernd@mbp ~/tomcat/logs $ grep '" 200 [0-9]' localhost_access_log.2014-05-18.txt | wc -l
      47

Fassen wir die Anforderungen an ein Logdateianalyse Werkzeug zusammen, die sich aus diesem Beispiel ergeben:

• Unstrukturierte Daten sorgen dafür, dass es schwer fällt Leistungskennzahl zu benennen und zu errechnen. Anhand einer Leistungskennzahl soll der Fortschritt oder der Erfüllungsgrad hinsichtlich wichtiger Zielsetzungen gemessen werden.
  -> Ein Werkzeug zur Logdateianalyse muss es ermöglichen unstrukturierte Daten in eine strukturierte Form zu bringen, um Kennzahlen berechnen zu können.
• Die Verteilung der Logdateien stellt ein Problem dar, wenn man Abfrage über den gesamten Datenbestand durchführen möchte.
  -> Alle Logdateien müssen an einer zentralen Stelle durchsucht werden können.
• Außerdem benötigt man eine Abfragesprache, die bei der Suche nach Informationen hilft. Das Ergebnis einer Abfrage (Query) muss eine Teilmenge des zugrunde liegenden Informationsbestandes liefern.
  -> Es muss eine Abfrage Sprachen geben, mit der man gesamten Datenbestand schnell durchsuchen kann.

Splunk

Um dem Software Ingenieur die Möglichkeit zu geben verschiedene Logdateien an einer zentralen Stelle zu durchsuchen, gibt es eine kommerzielle Lösung namens Splunk. Splunk ist ein Log-, Monitoring- und Reporting-Tool für IT-Systemadministratoren. Es sammelt Logdateien, Leistungskennzahlen und weitere Daten von unterschiedlichen Applikationen, Servern und Netzwerkgeräten und indiziert sie in ein durchsuchbaren Repository. Mit Splunk lassen sich Grafiken, SQL-Reports und Warnmeldungen generieren. Splunk hilft, Störfälle zu erkennen und Log-Daten verschiedenster Systeme und Softwarekomponenten zueinander korreliert zu können. Dazu hat Splunk eine eigene Abfragesprache.

Splunk erfüllt somit unsere drei Anforderungen an Logdateianalyse Werkzeug. Der Preis von Splunk ist abhängig von der zu indexierenden Datenmenge pro Tag und startet bei  $4,500 für 1 GB/Tag für eine Splunk Enterprise Lizenz (Quelle).

Logdateien können aber erstaunliche Menge an Gigabytes produzieren und dann kann diese kommerzielle Lösung schnell sehr teuer werden, vorallen wenn man nur bestimmte Features wirklich nutzt. Häufig gibt es aber in vielen Organisationen nicht mal ein Logdateianalysewerkzeug und hohe Lizenzkosten können die Einstiegshürde zusätzlich vergrößern.  Eine alternative zu der kommerziellen Lösung Splunk ist der ELK Stack, der aus den folgenden Open-Source Komponenten besteht.

• Elasticsearch – für die Suche und Datenanalyse,
• Logstash – zum Zentralisieren, Anreichern und Parsen von Logdaten,
• Kibana – für die Daten Visualisierung.

Elasticsearch

Elasticsearch ist eine hoch-skalierende Volltext-Suche, die auf Apache Lucene aufbaut. Außerdem stellt Elasticsearch eine REST-API  für das Suchen und Analysieren von Daten bereit.

# Index erstellen
bernd@mbp ~ $ curl -XPUT 'http://localhost:9200/twitter/'
{"acknowledged":true}                            # Document indexieren
bernd@mbp ~ $ curl -XPUT 'http://localhost:9200/twitter/tweet/1' -d '{
     "user" : "bernd",
     "post_date" : "2009-11-15T14:12:12",
     "message" : "trying out Elasticsearch"
 }'
{"_index":"twitter","_type":"tweet","_id":"1","_version":1,"created":true}
# nach Document suchen
bernd@mbp ~ $ curl -XGET 'http://localhost:9200/twitter/tweet/1'
{"_index":"twitter","_type":"tweet","_id":"1","_version":1,"found":true, "_source" : {
    "user" : "bernd",
    "post_date" : "2009-11-15T14:12:12",
    "message" : "trying out Elasticsearch"
}}

Elasticsearch erlaubt es mit einem Server anzufangen und später horizontal zu skalieren. Wenn man mehr Kapazität braucht, muss man einfach nur einen neuen Knoten hinzufügen. Elasticsearch reorganisiert dann das Cluster von selbst, um von der neuen Hardware zu profitieren.

Elasticsearch ist im ELK Stack als Backend zum Speichern, Indexieren von Dokumenten an zusehen, dass über eine REST-API leicht für analytische Anfragen zugänglich ist. Da Elasticsearch auf Lucene basiert, verfügt es außerdem über die Lucene Anfragesprache, mit der man indexierte Dokument selektieren kann und analytische Abfragen gestalten kann. Im Folgenden werden ein paar Lucene Abfragen gezeigt, die man zu selektieren von Dokumenten im Index benutzen kann (Dokumentation):

• status:active – Status muss ‚active‘ beinhalten,
• title:(bernd zuther) – Titel muss bernd oder zuther enthalten,
• author:“Bernd Zuther“ – Author muss „Bernd Zuther“ vollständig enthalten,
• status:[200 TO 299] – Status muss zwischen 199 und 300 liegen
• status:200 AND  host:“app-server-node-1″ – Status gleich 200 und Host gleich ‚app-server-node-1‘

10.0.2.2 - - [23/May/2014:07:31:09 +0000] "GET /pizza/checkout?5-IResourceListener-header-home-logo HTTP/1.1" 200 23875

Die REST-API von Elasticsearch nimmt JSON-Dokumente entgegen. Wenn wir uns dann das Zugriffsprotokoll des Tomcat-Anwendungsservers erinnern, das Eingangs als Beispiel diente, dann heißt das, dass die Daten in einer Zeilen erst mal transformiert werden müssen, um sie an Elasticsearch schicken zu können. Zunächst muss eine semistruktuierte Form aus einer Zeile erzeugt werden, wie es im folgenden Listing dargestellt ist.

{
    "remoteHost": "10.0.2.2",
    "remoteLogname": "-",
    "user": "-",
    "request": "GET /pizza/checkout?5-IResourceListener-header-home-logo HTTP/1.1",
    "status": "200",
    "size": "29822",
    "@version": "1",
    "@timestamp": "2014-05-23T07:31:16.375Z",
    "type": "access-log",
    "host": "app-server-node-1",
    "path": "/var/log/tomcat7/localhost_access_log.2014-05-23.txt"
}

Den Transport der einzelnen Logzeilen zu Elasticsearch wird im ELK Stack von Logstash übernommen, das im folgenden beschrieben wird.

Logstash

bin/logstash -e 'input { stdin { } } output { stdout {} }'
hello world
2013-11-21T01:22:14.405+0000 0.0.0.0 hello world

Logstash kann mit einer Unix-Pipeline verglichen werden. Es nimmt Daten entgegen, die über eine Input Schnittstelle hereinkommen. Diese Daten können  dann gefiltert und transformiert werden. Nach der Transformation können die Daten wieder an ein Output geschickt werden. Logstash verfügt über eine große Menge verschiedener Input und Output. Es ist u.a. mögliche bekannte NoSQL-Datenbanken, wie  MongoDB, Redis und Riak als Input und Output zu nutzen. Außerdem kann man auch Elasticsearch oder RabbitMQ nutzen.

Logstash normalisiert Logeinträge und transportiert sie von einem System an eine zentrale Stelle. Es gibt verschiedene Ansätze, um Logstash zu integrieren. Ein möglicher architektonischer Aufbau wird in Abbildung 3 gezeigt. Auf den Rechnern, die die Logdateien produzieren, läuft Logstash als sogenannte Shipper Instanz. Die Shipper sende die Logeinträge an Redis. Redis spielt hierbei nur die Rolle einer Queue in der einzelnen Logeinträge zwischen gespeichert werden können. Die Logeinträge in Redis werden kann von einer Indexer Instanz von Logstash genommen und in Elasticsearch überführt.

Logstash kann als Dienst gesehen werden, der eingehende Daten einfängt und aggregiert.  Außerdem kann Logstash so konfiguriert werden, dass Daten durch eine Serie von Filtern geschickt werden, um transformiert oder normalisiert zu werden, bevor die Daten letztlich in einem Backend wie Elasticsearch gespeichert und indexiert werden. Die komplette Konfiguration von Logstash erfolgt über eine Konfigurationssprache.

Die Logstash Konfigurationssprache ist sehr einfach gehalten und besteht nur aus den drei Teilen: inputs, filters, outputs. In diesen Sektionen können Plugins konfiguriert werden. Die einzelnen Plugin Konfigurationen beinhalten dann die Einstellungen, die Plugins benötigen.

input {
    file {
        type => "access-log"
        path => "/var/log/tomcat7/localhost_access_log.*.txt
        codec => json
        sincedb_path => "/var/logstash/sincedb/access-log"
    }
}
output {
    elasticsearch {
        host => "10.211.55.100"
        port => "9200"
        embedded => false
        codec => json
        protocol => http
    }
}

Es gibt verschiedene Ansätze die Logeinträge in eine strukturierte Form zu bringen. Zum Einen existieren Filter-Plugins wie grok, das man benutzen muss, wenn man das Logformat nicht verändern will. Zum Anderen kann man aber auch das Logformat in den Logdateien direkt in eine strukturierte Form bringen. Es existieren fertige Encoder für Log4J und Logback, die die Logeinträge in ein JSON-Format bringen, dass direkt von Logstash an Elasticsearch geschickt werden kann, wie es im oben-stehenden Listing zu sehen ist. Das folgende Listing zeigt die Groovy-Konfiguration von dem schnellen Logger-Framework Logback, das die Logausgaben in ein JSON-Format umwandelt.

import net.logstash.logback.encoder.LogstashEncoder
import ch.qos.logback.core.ConsoleAppender

import static ch.qos.logback.classic.Level.*

appender("stdout", ConsoleAppender) {
    encoder(LogstashEncoder) {}
}
root(ERROR, ["stdout"])

Natürlich kann man sowohl die Logformate des Apache Webserver als auch des Tomcat Anwendungsservers konfigurieren, dass JSON als Logformat benutzt wird. Das kann Sinn machen, um die Einträge besser filtern zu können. Das folgende Listing zeigt, was dazu in der server.xml des Tomcat Anwendungsserver konfiguiert werden muss:

className="org.apache.catalina.valves.AccessLogValve" directory="logs"
                       prefix="localhost_access_log." suffix=".txt"
                       pattern="{ "remoteHost":"%h", "remoteLogname":"%l", "user":"%u", "time":"%t", "request":"%r", "status":"%s", "size":"%b", "referer":"%{Referer}i", "userAgent":"%{User-agent}i" }"/>

Logstash Forwarder / Lumberjack

Logstash hat einen signifikanten Memory Footprint (mindestens 512MB bis zu einem GigaByte). Deshalb gibt es auch leichtgewichtigere Lösungen zum Versenden von Daten zu einen zentralen Logstash Empfänger.

Der Logstash Forwarder ist ein leichtgewichtigere Daemon für das Versenden von Logdaten an eine zentrale Stelle. Der Logstash Forwarder hat mit 64KB einen wesentlich geringeren Memory Footprint und kann anstatt der bekannten Logstash Shipper Instanzen benutzt werden.

Damit wissen wir nun, wie man mit Logstash Logeinträge sammeln kann. Im Folgenden wird nun erklärt, wie man diese Logeinträge visualisieren kann.

Kibana

Kibana ist seit Version 1.2 das offizielle Webinterface von Logstash. Mit Kibana erfolgt die Visualisierung und Analyse der in Elasticsearch gespeicherten Daten. Kibana besteht aus einem Javascript-Frontend,  dass direkt mit dem REST-Interface von Elasticsearch kommuniziert. Kibana ist in der Lage von einem vom Web erreichbaren Verzeichnis (Apache Webserver) ohne weitere Installation benutzt werden zu können.

Kibana bietet die Möglichkeit Dashboards zu erstellen und Interface-Elemente auf die eigenen Suchen abzustimmen. Ein solches Dashboard kann in einem File, Gist oder in Elasticsearch abgelegt werden, um ein Dashboard mit anderen Kollegen zu teilen. Ein Dashboard besteht immer aus einer beliebigen Anzahl an Zeilen (Rows). Zeilen sind wiederum in Kacheln (Panels) unterteilt.

Übergeordnet sind die Kacheln für die Zeiteinschränkung (Timepicker) und die Suchanfragen (Query) zu betrachten, da sich deren Auswahl auf das gesamte Dashboard auswirkt und die in der ausgewählten Zeitperiode dargestellten Werte direkt beeinflusst. Die Zeiteinschränkungskachel bietet eine Vorauswahl von voreingestellten Zeitfenstern und aktualisiert das Dashboard auf Wunsch in regelmäßigen Abständen.

Kacheln beschreiben in welcher Form die Daten aus Elasticsearch präsentiert werden. Es sind Listen, Charts und auch Map-Darstellungen möglich. Unter Verwendung der jeweiligen Attribute kann die Darstellung dann noch weiter verfeinert werden. Um sich mit dem Userinterface besser vertraut zu machen, kann ich das Video „Kibana: Data Visualization Made Simple and Beautiful“ empfehlen, dass man sich unbedingt angucken sollte, um die Oberfläche besser zu verstehen.

ELK Stack – Architektur

Abbildung 5 zeigt ein Verteilungsdiagramm, dass die Architektur eines einfachen ELK Cluster zeigt. Diese ELK Cluster besteht aus den folgenden drei Knoten:

• Einen Elasticsearch Knoten, auf dem auch Kibana innerhalb eines Apache Webservers installiert ist,
• Außerdem gibt es zwei Anwendungsserver auf denen sich jeweils ein Tomcat und eine Logstash Shipper-Instanz befindet. Die Shipper-Instanzen beliefern direkt den Elasticsearch Knoten, in dem sie die JSON-Logeinträge im den Logdateien direkt weiterleiten.

Ein solches Cluster aufzubauen sieht auf den ersten Blick nach jeder Menge Infrastruktur Arbeit aus. Das kann abschrecken, wenn man einfach mal mit Kibana und Logstash herumspielen möchte. Ich hoffe diese Angst kann ich dem Leser nehmen, denn wir können den Cluster mit drei Befehlen bauen.

Vagrant setzt an dieser Stelle an. Vagrant hat das Ziel das Erstellen und Provisionieren von virtuellen Maschinen vereinfachen und beschleunigen. Bei Vagrant handelt es sich, um ein Werkzeug, dass es ermöglicht verschiedene virtuelle Maschinen auf einem einzigen physischen Rechner zu managen. Vagrant  unterstützt von Haus aus VirtualBox. (Mehr zum Thema Vagrant finde man in dem Artikel „Automatisierte virtuelle Testumgebungen mit Vagrant und Puppet“.) Vagrant wird automatisch den in Abbildung 5 abgebildeten ELK Stack initialisieren. Dazu muss man nur die folgenden Befehle in der Kommandozeile ausführen, nachdem man Vagrant und Virtualbox installiert hat.

bernd@mbp ~$ git clone https://github.com/zutherb/AppStash.git appstash
bernd@mbp ~$ git checkout elk-example
bernd@mbp ~$ cd appstash/vagrant
bernd@mbp ~$ vagrant up

Nach dem Start des Clusters mit dem Befehl vagrant up dauert es beim ersten Start einen Moment bis das Cluster komplett eingerichtet ist. Auf die im Verteilungsdiagramm dargestellten Komponenten des ELK Stacks kann man über die folgenden Port Forwardings zu greifen.

• Kibana – http://localhost:8000/
• Elasticsearch – http://localhost:9200/
• Applikation 1 – http://localhost:8080/pizza/
• Applikation 2 – http://localhost:8081/pizza/

Sollten die oben genannten Port auf dem Rechner schon belegt sein ändert Vagrant diese automatisch. Dann muss im Konsolenoutput nach den entsprechenden Ports suchen.

Realtime Logdateianalyse

Im external Verzeichnis des Git-Repository, dass man zuvor ausgecheckt hat, befindet sich die Datei logstash-traffic-simulation.jmx. Diese Datei kann man mit JMeter öffnen und enthält einen einfachen Lasttest. Wenn man den Lasttest ausführt, erzeugt man auf den beiden Anwendungsservern Traffic. Die beiden Anwendungsservern schreiben nun Logeinträge in die Zugriffsprotokolldateien.

Ebenfalls im external Verzeichnis des Git-Repository befindet sich die Datei „Logstash Dashboard“. Dieses Dashboard kann man über die Addresse  http://localhost:8000/ in Kibana laden. Als Resultat erhält man ein Realtime Dashboard, dass die HTTP-Response Statuscodes auf den beiden Anwendugnsservern visualisiert.

[youtube http://www.youtube.com/watch?v=HHomI4y7yGs&rel=0&hd=1]

Zusammenfassung

Eingangs haben wir die folgenden funktionalen Anforderungen an ein Logdateianalyse Werkzeug definiert:

• Ein Werkzeug zur Logdateianalyse muss es ermöglichen unstrukturierte Daten in eine strukturierte Form zu bringen, um Kennzahlen berechnen zu können.
• Alle Logdateien müssen an einer zentralen Stelle durchsucht werden können.
• Es muss eine Abfrage Sprachen geben, mit der man die Daten schnell durchsuchen kann.

ELK Stack erfüllt all diese Anforderungen. Kibana dient dabei zur Visualisierung der Daten und greift über die REST-API der Elasticsearch-DB auf die Datenbank selbst zu, die mithilfe von Logstash befüllt wird. Eine zentralisierte Logdateianalyse ist mit dem ELK Stack definitiv möglich.