Viele Open Source Projekte kommen so in Fahrt, dass man mit dem Verfolgen der Entwicklung kaum noch hinterherkommt. Auch wenn das zusätzliche Arbeit verursacht, so ist das dennoch ein Grund zur Freude. Dem entsprechend gibt es heute eine Aktualisierung des logstash Quickstart Tutorials, das ich vor einiger Zeit gepostet habe.
Vieles hat sich beim Wechsel von Version 1.3 auf 1.4 geändert, dennoch sollten Migrationen (grossteils) reibungslos vonstatten gehen. Dieses Tutorial soll möglichst schlank und aufs Wesentliche beschränkt bleiben, weshalb ich hier nicht gross auf die Unterschiede eingehen möchte. Dennoch ist es etwas aufwändiger als die vorherige Version, dafür hat man danach eine Teststellung, die nicht nur zum Rumspielen taugt, sondern gleich der Grundstock einer Testumgebung werden kann. Genug der Vorrede, jetzt geht’s ans Eingemachte.
Inzwischen ist es auf jeden Fall empfehlenswert, logstash aus den zur Verfügung gestellten Paketen zu installieren, die praktischerweise auch noch in Repositories organisiert sind. Als Voraussetzung muss Java installiert sein. OpenJDK funktioniert für einfache Beispiele, auch wenn das Projekt inzwischen Sun, äh, Oracle Java empfiehlt.
Für die Installation werden die Repositories konfiguriert. Die nötigen Repofiles und eine Anleitung, wie man sie inkludiert, findet man hier für logstash und hier für elasticsearch.
yum install logstash elasticsearch
(Der aufmerksame Leser erkennt jetzt, dass dieses Tutorial für CentOS/RHEL/Fedora ausgelegt ist, es funktioniert aber ganz ähnlich mit Debian, SLES und diversen anderen Linuxdistributionen oder auch anderen Betriebssystemen) Etwas unüblich ist, dass sich logstash nach der Installation nicht sofort starten lässt, sondern erst eine Konfigurationsdatei angelegt werden muss. Ein Beispiel könnte folgendermassen aussehen:
input {
file {
path => "/var/log/messages"
}
}
output {
elasticsearch {
cluster => "elasticsearch"
protocol => "http"
}
}
Die legt man nach /etc/logstash/conf.d/logstash.conf . Es ginge noch etwas einfacher mit einer embedded Variante von elasticsearch, aber so kann man den Testhost auch gleich für etwas grössere Tests verwenden und die zusätzliche Installation ist nicht wirklich aufwändig, wie man gesehen hat.
Da im Beispiel der logstash Prozess auf ein File zugreifen will, das eigentlich nur für root lesbar ist, sollte der Prozess nicht als User logstash, sondern als User root gestartet werden. Dazu in /etc/sysconfig/logstash (auf Debian /etc/default/logstash) folgenden Eintrag vornehmen: LS_USER=root. Für Tests schadet es übrigens auch nicht, erstmal SELinux auf permissive zu setzen.
Jetzt noch
service elasticsearch start service logstash start service logstash-web start
und mit dem Browser http://localhost:9292/index.html#/dashboard/file/logstash.json (oder statt localhost den Namen / die IP der Maschine mit logstash, falls man nicht lokal testet) aufrufen. Fertig. Ja, ehrlich, das wars. Logstash sammelt lokale Logfiles ein, speichert sie in Elasticsearch und dort kann man sie mit Kibana durchsuchen.
Wer jetzt ein wenig weiter experimentieren möchte, kann noch ein paar Filter mit einbauen, die die Lognachrichten weiter aufbereiten. Da auf jedem System andere Dienste in die Logs schreiben und oft auch andere Logformate eingesetzt werden, kann es sein, dass das folgende Beispiel nicht überall funktioniert.
input {
file {
path => "/var/log/messages"
}
}
filter {
grok {
match => [ "message", "%{SYSLOGLINE}" ]
}
}
output {
elasticsearch {
cluster => "elasticsearch"
protocol => "http"
}
}
Dieses Beispiel setzt den grok Filter ein, um Syslognachrichten mit einem mitgelieferten Muster in ihre Einzelteile zu zerlegen. Sieht man im Kibana (das vorhin aufgerufene Webinterface) nach, erscheinen am linken Rand plötzlich neue Felder, nach denen man Filtern kann. So wird beispielsweise das program Feld erkannt, das Teil des Syslog headers ist.
Ein Beispiel, das auf allen Linux Systemen funktionieren sollte, ist das folgende.
input {
file {
path => "/var/log/messages"
type => "syslog"
}
exec {
type => "system-load-average"
command => "cat /proc/loadavg | awk '{print $1,$2,$3}'"
interval => 30
tags => "sysstat"
}
}
filter {
if [type] == "syslog" {
grok {
match => [ "message", "%{SYSLOGLINE}" ]
}
}
if [type] == "system-load-average" {
grok {
match => [ "message" , "%{NUMBER:load_avg_1m} %{NUMBER:load_avg_5m} %{NUMBER:load_avg_15m}" ]
named_captures_only => true
add_tag => "groked"
}
}
}
output {
elasticsearch {
cluster => "elasticsearch"
protocol => "http"
}
}
Hier wird in regelmässigen Abständen ein Shellcommand ausgeführt, das aus /proc die aktuelle Load ausliest und als Logevent verschickt. Die wird durch den grok Filter in Felder zerlegt, wo sie dann z.B. zum Zeichnen von Graphen in Kibana oder Graphite verwendet werden kann. Man könnte auch beim Überschreiten einer bestimmten Load ein passives Checkergebnis an Icinga schicken, um darüber zu alarmieren. Klar macht das letzte Beispiel in der Praxis wenig Sinn, wenn es die hervorragenden Monitoringplugins gibt, aber es zeigt, wie vielseitig logstash sein kann. Man könnte Icinga dabei sogar umgehen und beim Überschreiten einer Grenze der load gleich per Mail, IRC, oder Jabber einen Alarm an den zuständigen Admin schicken.
Ich kann nur jedem empfehlen, zumindest den Anfang des Quickstarts durchzuspielen. Das Experimentieren mit logstash und dem Rest vom ELK Stack macht einfach Spass. Wenn es dann daran geht, die Erkenntnisse so zu vertiefen, dass sie in einer Produktivumgebung eingesetzt werden sollen, geht’s hier zu Schulung und Consulting. Die beiden machen übrigens auch Spass.
Für Experimentierfreudige gibt’s als Dreingabe noch ein paar Stichworte zum Erweitern des Kibana Dashboards:
- Rechts unten auf „Add row“, damit eine neue Zeile in hinzufügen.
- In der neuen Zeile auf „Add panel to empty row“
- Panel type: „terms“
- Alle Felder so lassen, wie sie sind, nur die folgenden ändern:
title: „Programme“,field: „program“,style: „pie“
