6 – 10 October offered guides on Heira, Logstash and the new generation of floats in HTML, plus a few OSDC announcements along the way.
Eva started the week counting 50 days to the OSMC by sharing Alan Robertson’s talk: “Monitoring and Discovery with Limit”.
She went on to announce early bird specials for the OSDC in Berlin coming up in April, and tout the Call for Papers.
Achim then gave a short guide to Hiera, a key value backend for Puppet while Thomas W presented his updated quick start tutorial on Logstash.
Lastly, Marius celebrated “Flexible Box Layout Module” as the neo-“floating” containers in HTML.
NETWAYS Blog
Eine aktuelle Fassung des logstash Quickstarts
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“
Thomas Widhalm
Manager Operations
Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...
logstash – Der 15 Minuten Quickstart Guide
Da ich mich die letzte Zeit intensiv auf logstash Schulungen und – Consulting vorbereitet habe, liegt es nur nahe, dass ich auch zu diesem Thema blogge. Bei so zentralen Systemen ist es natürlich wichtig, sich intensiv damit auseinander zu setzen und viel Zeit zu investieren, um erstmal die Hintergründe und Zusammenhänge zu verstehen, damit man eine Installation planen kann, bevor man das erste Mal Code in die Hand nimmt. Prinzipiell ist das so richtig, aber es muss auch mal ok sein, einfach mal mit einem neuen, interessanten System rumzuspielen, bevor man sich intensiver damit beschäftigt, um erstmal ein gewisses Gefühl für die Arbeitsweise zu bekommen und weil es einfach Spass macht.
Und genau dafür soll dieser Quickstart Guide sein. Zuvor aber dennoch ein paar Worte dazu, was logstash denn nun eigentlich ist und wozu man es verwenden kann und soll. Wer das schon weiss, darf auch weiter nach unten scrollen. Aber keine Sorge, weitere Infos über die Abläufe in einer logstash Installation kommen noch in dieser Blogserie. Genauso ein paar Beispiele, wie Logs von logstash aufbereitet werden können. Wer also keine Lust hat, sich mal kurz logstash zu installieren, muss nur ein wenig warten.
Jeder Computer und auch sonst fast jedes Gerät, mit dem man in der IT zu tun bekommt, schreibt Logfiles, wo besondere Ereignisse festgehalten werden. Das hilft nicht nur, aber insbesondere, beim Erkennen und Nachvollziehen von aufgetretenen Fehlern. Als Administrator steht man nun vor dem Problem, dass diese Logfiles auf den Systemen bleiben und man sich erstmal dorthin verbinden muss, um sie zu lesen. So bleiben oft kleinere Fehler, die grössere Ausfälle im Vorfeld ankündigen und helfen würden, diese zu verhindern, unerkannt. Für diesen Fall bieten wir gerne Unterstützung mit Monitoring wie Icinga an. Wer aber nicht erst warten möchte, bis es kracht, sondern schon proaktiv handeln möchte, muss irgendwie an die Logfiles rankommen, ohne den halben Tag damit zu verbringen, sie von den Systemen abzuholen. Natürlich gibt es noch viele weitere Gründe, Logs zu sammeln, zu lesen und auszuwerten, aber das würde den Rahmen eines Einleitungsartikels sprengen. Es gibt bereits seit langer Zeit Lösungen wie logwatch oder syslog Server, die zumindest helfen, die Informationen aus Logfiles zu sammeln. Wozu dann logstash? Ein paar der Vorteile gegenüber herkömmlicher Lösungen sind:
- logstash kann auf vielen verschiedenen Systemen ausgeführt werden und ist als Java (bzw. JRuby) Anwendung nicht auf ein paar Betriebssysteme beschränkt
- logstash kann alle möglichen und unmöglichen Formate lesen. Syslog und Windows Eventlog sind naheliegend, aber auch über das Drupal dblog oder IRC können Nachrichten in logstash kommen. Gibt es keine Schnittstelle für einen Dienst, können auch beliebige Textfiles auf Systemen als Logfile angesehen und ausgewertet oder die Rückgabe beliebiger Programme gelesen werden.
- logstash ist von vornherein darauf ausgelegt, hervorragend zu skalieren. Alle Komponenten können mehr oder weniger auf beliebig viele Server ausgebracht und miteinander verbunden werden. Teilweise als sehr einfach zu verwaltende loadbalancing und high availability cluster, teilweise einfach als redundante Instanzen, die nichts voneinander wissen und einfach jeweils nur einen Teil der zu verarbeitenden Daten erhalten. Und das, wie von Tools, die wir unterstützen, nicht anders zu erwarten, alles ohne Lizenzkosten. Wer dann noch freie Linux Distributionen einsetzt, wird eigentlich nur durch Anschaffungs- und Betriebskosten der Hardware in der Grösse der logstash Installation beschränkt.
- logstash leitet Logs nicht einfach stumpf weiter, sondern zerlegt sie in Felder, die dann in der Auswertung genutzt werden können. Damit fällt die Regexbastelei zum Küren des grössten Spamempfängers anhand der Sendmail Logs weg, denn eine Information wie die Empfängeradresse kann schon beim Verarbeiten der Logs als eigenes Feld ausgewiesen werden, nach dem dann gefiltert oder mit dem dann Berechnungen angestellt werden können.
Jetzt aber wie versprochen die Kurzanleitung:
logstash wird als .jar File zum Download angeboten, das auch gleich ein paar andere der benötigten Tools in embedded Versionen enthält. Den Download findet man prominent unter http://logstash.net/ . Ausserdem muss Java installiert sein. logstash ist ziemlich unempfindlich, welche Java Version eingesetzt wird. In Tests hat OpenJDK-7 hervorragend funktioniert.
Als nächstes wird eine einfache Konfigurationsdatei namens logstash-quickstart.conf angelegt:
input {
stdin {
type => "stdinput"
}
file {
path => "/var/log/messages"
type => "syslog"
}
}
output {
stdout {
codec => rubydebug
}
elasticsearch {
embedded => true
}
}
Dieses Beispiel muss mit einem User gestartet werden, der Leserechte auf /var/log/messages hat. Wer das nicht für einen Test möchte, kann den file Part einfach weglassen. Dieses Konfigfile lässt logstash Events aus /var/log/messages sowie von stdin annehmen und gibt sie auf stdout aus, speichert sie aber auch gleichzeitig in die im .jar File mitgebrachte Elasticsearch Instanz.
Gestartet wird logstash mit
java -jar logstash-1.3.3-flatjar.jar agent -f logstash-quickstart.conf -- web
Dann passiert erstmal nicht viel. Nach ein paar Sekunden erhält man eine Warnung, dass verwendete Plugins noch nicht als stabil gekennzeichnet sind, die man für einen Test einfach mal ignorieren kann. Dann wartet logstash auf neue Logmeldungen. Falls nicht zufällig eine neue Nachricht in /var/log/messages geschrieben wird, kann man auch einfach eine Testnachricht abschicken, die dann logstash durchläuft und aufgeschlüsselt wieder ausgegeben wird. Ohne weitere Konfiguration wird aber natürlich nicht viel aufgeschlüsselt, sondern die gesamte Nachricht im message Feld wieder ausgegeben. Ein paar zusätzliche Felder fügt logstash automatisch hinzu und der type wurde ebenfalls über die Konfiguration gesetzt.
[root@fenris ~]# java -jar logstash-1.3.3-flatjar.jar agent -f logstash-quickstart.conf -- web
Using milestone 2 input plugin 'file'. This plugin should be stable, but if you see strange behavior, please let us know! For more information on plugin milestones, see http://logstash.net/docs/1.3.3/plugin-milestones {:level=>:warn}
hello world
{
"message" => "hello world",
"@version" => "1",
"@timestamp" => "2014-01-23T12:06:27.895Z",
"type" => "stdinput",
"host" => "fenris.int.netways.de"
}
„hello world“ ist die eingetippte Testnachricht.
Um logstash zu beenden, kann Ctrl+C gedrückt werden. Aber zuvor lohnt sich ein Blick auf http://localhost:9292/index.html#/dashboard/file/logstash.json . Woah! Das ist Kibana. Das mitgelieferte Webinterface zur Analyse der gespeicherten Events.
Und jetzt kommt der Clou: Die logstash Installation ist voll funktionsfähig und die gesammelten Events bleiben auch gespeichert, wenn man logstash beendet und später wieder neu startet. Ab hier geht es „nur“ mehr darum, die Daten in mehr und brauchbare Felder zu zerlegen, sie von mehr Quellen zu sammeln, sie zwischen Hosts mit logstash Instanzen weiterzuleiten und die beteiligten Systeme zu tunen und zu skalieren. Dazu wird es Sinn machen, die embedded Versionen von Elasticsearch und Kibana als eigenständige Instanzen ausserhalb des .jar Files zu installieren und es um weitere Tools wie Redis zu ergänzen.
Wer jetzt schon überzeugt ist, dass logstash eine feine Sache ist, findet sich sicher etwas bei unseren logstash Starterpaketen oder logstash Schulungen . Wer nicht, hat noch ein paar Folgen dieser Blogserie Zeit, sich überzeugen zu lassen.
Thomas Widhalm
Manager Operations
Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...
