Zentrale Applikations-Logs mit dem Elastic Stack
Sobald man mehrere Server, Applikationen oder Container im Einsatz hat, besteht früher oder später der Bedarf an einer zentralen Logging-Lösung. Dabei bietet sich der Elastic Stack als flexible und gleichzeitig leistungsfähige Lösung an. Doch wie speichert man seine Applikations-Logs am einfachsten? Dafür wollen wir uns drei verschiedene Ansätze jeweils mit einer möglichen Implementierung sowie ihren jeweiligen Vor- und Nachteilen ansehen.
Als Beispielimplementierung dient eine Java Applikation, aber die selben Konzepte gelten gleichermaßen für jede andere Programmiersprache.
Parsing
Gehen wir davon aus, dass unsere Applikation bereits Logdateien schreibt. Diese sammeln wir mit Filebeat ein und senden sie an Logstash, das die einzelnen Elemente eines Eintrags parsen kann.
Vorteil der Methode ist, dass wir keinerlei Veränderungen an der Applikation vornehmen müssen und die Lösung unabhängig von der Programmiersprache und dem Loggingwerkzeug ist.
Allerdings müssen wir die Regular Expression zum Parsen selbst schreiben, was speziell bei mehrzeiligen Logeinträgen kompliziert sein kann. Außerdem wirkt es etwas umständlich die in der Applikation strukturiert vorliegenden Elemente eines Logeintrags unstrukturiert auf die Festplatte zu schreiben, um sie anschließend von dieser wieder auszulesen und sie danach zurück in ein strukturiertes Format zu bringen.
Forwarder
Anstatt Logdateien zu schreiben, können wir aus der Applikation auch direkt die Logeinträge weiterleiten. Je nach Log-Appender können die Einträge entweder per HTTP-Request (idealerweise als Bulk) direkt in Elasticsearch geschrieben werden oder an Logstash für die weitere Verarbeitung gesendet werden.
Der große Vorteil dabei ist, dass die zusätzlichen Schreiboperationen am Applikationsserver entfallen und dass man keine Regular Expressions zum Parsen der Logdatei schreiben muss. Denn ehrlich — wer schreibt schon gerne Regular Expressions?
Ein Nachteil ist allerdings, dass man bei einem Netzwerkausfall oder bei Nicht-Verfügbarkeit des Logsystems mehr oder weniger im Blindflug operieren muss. Die Notlösung auf lokale Logdateien zuzugreifen ist nur möglich, wenn man zusätzlich zum Forwarder weiterhin lokale Logdateien schreibt.
Schlecht implementierte Forwarder haben außerdem das Problem, dass sie mit jedem nicht zugestellten Logeintrag mehr Ressourcen blockieren, womit im schlimmsten Fall ein Ausfall des Logsystems die Applikation selbst beeinträchtigen kann. Dieses Szenario sollte auf jeden Fall getestet werden.
JSON
Bei diesem Ansatz schreiben wir eine lokale Logdatei, allerdings in einem strukturierten Format, sodass wir nicht parsen müssen. Dabei wählen wir JSON, da man die Daten dann direkt an Elasticsearch senden kann. Die Logdaten werden in eine Datei geschrieben (ein Logeintrag pro Zeile), die von Filebeat ausgelesen wird und direkt in Elasticsearch geschrieben werden kann.
Vorteil ist, dass man die Daten nach wie vor lokal vorrätig hält und bei Bedarf auf sie zugreifen kann und gleichzeitig das Parsen per Regular Expression entfällt.
Der Nachteil gegenüber regulären Logdateien ist, dass das strukturierte Format etwas größer ist, da die Metainformation von jedem Feld enthalten sein muss.
Fazit
Welches ist der beste Ansatz? Mir gefällt das Loggen als JSON am besten, aber jeder muss die richtige Abwägung für sein Projekt treffen. Wichtig ist primär, dass man die Vor- und Nachteile kennt.
Und damit noch frohe Weihnachten und erfolgreiches Loggen 