Graylog2

Logmanagement einfach gemacht

Vortrag auf den Chemnitzer Linux Tagen 2014
Klaus Kruse / mail@klaus-kruse.de

Warum Logs?

Logs sind toll:

Daemons protokollieren Verhalten
Helfen bei Fehlersuchen
Zeigen Performance(probleme)

Viele Daemons produzieren viele Logs

Viele Server produzieren zu viele Logs

Probleme

Was ist mit mehreren Servern?
Was ist mit Zeitverläufen?
Was ist mit Zusammenhängen?

Fazit: Sammelstelle für Logmanagement und Auswertungen benötigt

Lösungen

Octopussy

Logstash

Graylog2

Octopussy

Aktuelle Version 1.0.11 (Release: 16.02.2014)

Homepage von Octopussy

Erfahrung

Pro

Pakete für Debian
Vollständige Installationsanweisung

Contra

Abhängig von RSyslog (Logs werden über FIFO angenommen)
Hatte Probleme mit dem Parsen von Konfigurationsdateien
Aussage des Entwicklers: "yes, I need to provide better error messages and stop when something goes wrong..."

Logstash

Aktuelle Version 1.3.3

Homepage

Bewertung

Konfiguration über Textdatei(en)

Teil des Elasticsearch-Projektes

Umfangreiche Plugin-Sammlung

Eigenes Buch (The Logstash Book)

Graylog2

Entstehung

Entstanden 2010 als persönliches Projekt zweier Mitarbeiter von Xing

Mittlerweile überführt in die TORCH GmbH in Hamburg

Hauptentwickler Lennart Koopmann und Kay Röpke

Architektur

Minimales Setup besteht aus einem Graylog2-Server, Webinterface, MongoDB und Elasticsearch

Kommunikation zwischen Server-Daemon und Webinterface-Daemon über REST-Schnittstelle

Ausführlich & Erweiterbar: architecture high level overview

Diagramm

Testsetup

Alle Dienste auf einer Maschine

Webinterface als unprivilegierter User, Server als Root

Scale Out: Elasticsearch-Knoten auf separaten Maschinen (später mehr...)

Voraussetzungen

Java Version 7 - Entweder Oracle JDK oder OpenJDK

Letzte Stable der MongoDB von www.mongodb.org

Exakt die von Graylog2 angegebene Version der ElasticSearch-Engine von www.elasticsearch.org

Server und Frontend

Aktuelle Version von graylog2.org/download

Solide Anleitung: Installing graylog2 server on *NIX systems

Leider keine paketierte Version oder Initskripte - Handarbeit ist angesagt...

Erster Start

						
cd /opt/graylog2-server-0.20.0-rc.2
java -jar graylog2-server.jar --debug
[...]
2014-02-13 23:14:29,770 INFO : org.graylog2.Main - Graylog2 up and running.

						
cd /opt/graylog2-web-interface
./bin/graylog2-web-interface
Play server process ID is 23226

Ideen Initskripte

Selbst ist der/die AdministratorIn:

Für graylog2-server reicht ein Wrapper um graylog2ctl

graylog2-webinterface etwas umfangreicher mit start-stop-daemon (Debian)

Erster Schritt

User: admin, Passwort in /etc/graylog2.conf

Suchmaske

Umfangreiche Möglichkeiten und natürlich Regex

Streams

Zeigen Nachrichten nach festgelegten Filterregeln an

Dashboards

Ermöglicht "Views", d.h. Graphen aus Logmeldungen

Sources

Übersicht über die konfigurierten Quellen

System

Übersicht über Cluster und Konfiguration von Quellen

Inputs

Neben Graylog2-Eigenentwicklung GELF (natürlich) auch Syslog-Streams

Graylog2 nimmt neben einigen Eigenentwicklungen auch Syslog-Streams an

Hello World

Graylog2 lauscht auf Syslog-Nachrichten von localhost

Einrichtung eines Syslog-Listeners auf localhost

Konfiguration von Syslog-ng

/etc/syslog-ng/conf.d/hello.conf

							
filter f_helloworld{level(info); facility(local0);};
destination d_helloworld{udp("127.0.0.1" port(514);};
log{ source(s_src); filter(f_helloworld); destination(d_helloworld);};
							
							
/etc/init.d/syslog-ng restart

reload hat ein paar mal keine Auswirkungen gehabt...

Prüfen

logger --priority local0.info "Hello World"

Fragen bis hierhin?

Syslog

Was meinen wir mit "Syslog"?

BSD Syslog nach RFC3164

<PRIORITY> TIMESTAMP HOSTNAME APPLICATION: MESSAGE

Feb 18 18:02:36 django syslog-ng[23148]: Configuration reload request received, reloading configuration;

IETF Syslog nach RFC5424

<PRIORITY>VERSION ISOTIMESTAMP HOSTNAME APPLICATION PID MESSAGEID STRUCTURED-DATA MSG

<45>1 2014-02-19T16:00:27+01:00 django syslog-ng 23148 - [meta sequenceId="2"] Configuration reload request received, reloading configuration;

Syslog-Formate

IETF Syslog ist besser weil klarer definiert

Leider kann Graylog2 nur BSD Syslog

Syslog-ng kann beides und noch viel mehr

Syslog-ng

Weiterentwicklung des alten Syslog-Daemons und mittlerweile Standard in vielen Distributionen

Flexible aber zuerst nicht vollständig eingängige Konfiguration (siehe hello.conf)

Kann alles lesen und ggf. formatiert wieder ausgeben

Aufbau

Diagramm über den Weg von Logs über Syslog-ng in Graylog2

KISS: Anwendungen loggen und nur Syslog-ng kümmert sich um die Sammlung und Verteilung

Beispiel: Apache Logs

Einfach: logger statt Logfile

						
CustomLog "|/usr/bin/logger --priority local7.info --tag Apache" combined

destination d_graylog{ udp("graylog" port(514) ); };
filter f_apache{ facility(local7); "$PROGRAM" == "Apache"; };
log{ source(s_src); filter(f_apache); destination(d_graylog); };

Ergebnis

War doch easy!

That was (too) easy

Keine Trennung der Nachrichtenteile

Umständliche Suche oder Sortierung

Wir brauchen ein Logformat das sich einfach extrahieren lässt

Apache Combined Graylog Format™

Einfacher wird es mit Logs im Key=Value Stil

						
LogFormat "REMOTE=%h IDENT=%l USER=%u \
REQUEST_TIME=%t REQUEST_METHOD=%m REQUEST=%U%q \
STATUS=%>s BYTES=%O REFERER=\"%{Referer}i\" \
USER_AGENT=\"%{User-Agent}i\" HOST=\"%{Host}i\"" graylog-combined