Tools

Logserver – Kibana 4.2-Elasticsearch 2.0-Logstash 2.0 – Update von früheren Versionen – was sind die neuen Features und Begriffserklärungen

Endlich vollbracht. Das Update auf eine neuere Version von unserem Logserver ist durchgeführt. Im Projekt hatten wir bisher schon einen Logserver mit Kibana 3, Logstash 1.x und Elasticsearch 1.x laufen.

Vielleicht sei kurz für diejenigen, die diese Produkte nicht kennen noch geklärt, wozu diese eingesetzt werden.

Ein Logserver wird immer sinnvoller, je mehr Logs anfallen. Damit ist es möglich, die Einträge von Logdateien zu visualisieren und mit Filtern sichtbar zu machen, inklusive „chirurgischer“ Auftrennung der einzelnen Logeinträge in deren Einzelbestandteile und Abspeichern in Einzelfelder. Dies ermöglicht es im Nachgang, darüber Auswertungen zu fahren und auch forensische Analysen durchzuführen, oder Angriffe besser identifizieren zu können und eventuell sogar auch Zukunftsmaßnahmen abzuleiten.

Nun, wie gehören diese einzelnen Produkte zusammen?

Kibana1

Die einzelnen Logfiles werden pro Rechner mit einem sogenannten Shipper zusammengesammelt, anschließend wenden sich alle diese Shipper, welche durchaus auch unterschiedlicher Natur sein können (z.B. Syslog, Logstash selbst, FileBeat, Log-Courier, PacketBeat, WinlogBeat, Log4J, Redis) an einen zentralen Endpoint, auf dem schließlich Logstash liegt.

Logstash ist wiederum letztendlich dafür verantwortlich, wie eine Art Durchlauferhitzer die verschiedenen Logshipper zusammenzuziehen, diese im Anschluss mittels einer Konfigurationslogik in Felder aufzudröseln und anschließend diese Felder danach pro Logeintrag als Datensatz standardisiert weiterzureichen: entweder zu weiterer Bearbeitung oder aber an eine Datenbank, über die man später Auswertungen laufen lassen kann, in unserem Fall läuft dies in die Datenbank Elasticsearch.

Die Datenbank Elasticsearch hat als Hauptaugenmerk nicht direkt die Datenhaltung, sondern ist von der Art her eher ein Suchserver auf Basis vom Apache Lucene-Index, der auch sehr gut skalieren kann und somit prädestiniert ist für eine Suche und Analyse von hohen Datenmengen, welche ja natürlicherweise bei Logdateien anfallen können. Die Datenhaltung erfolgt als NoSQL-Datenbank im JSON-Format. Elasticsearch selbst teilt dann noch jeden Index in sogenannte Shards, die ihrerseits wiederum auf mehrere Clusternodes repliziert werden können, um die Ausfallsicherheit zu gewährleisten.

Kibana andererseits ist ein Produkt, welches in raffinierter Weise eine GUI bietet, um auf die Daten in Elasticsearch zuzugreifen, in Grafiken aufzubereiten und so Auswertungen darauf anzubieten.

Dies sollte wohl nun als Kurzüberblick genügen und es sollte besser möglich sein, der hier enthaltenen Materie zu folgen.

An alle denjenigen, die ihr Logserver auf die aktuelle Produktpalette aktualisieren möchten, oder aber auch den Neueinsatz eines solchen planen sollten, richtet sich dieser Artikel besonders.

Allen anderen wünsche ich eine hoffentlich trotzdem kurzweilige Lektüre.

 

An besonderen Neuigkeiten gibt es folgendes zu erwähnen.

Im Vergleich von Elasticsearch 1.x zu 2.x gibt es folgende Neuerungen:

  • Update auf ein aktuelleres Lucene, welches wesentlich performanter läuft. Hier soll auch in Zukunft näher an der Entwicklung von Lucene geblieben werden
  • In der API sind striktere und damit schlankere Abfragen möglich und man bewegt sich weg vom schwammigen Best-practice-Ansatz hin zu genau festgelegten Regeln, wie man an Elasticsearch herantritt
  • Wenn Optionen falsch oder veraltet sind, sollen dafür schlüssige Logeinträge erzeugt werden
  • Bessere Verwaltung des Java-Heapspace
  • Facets werden durch Aggregations und Streams ersetzt, die hierarchisch angeordnet sind
  • Generelle Tendenz, alles einfacher zu gestalten, auch was Upgrades angeht
  • Schnellere Recovery von einem Fehlerstatus und auch bessere Unterstützung von Clustern

Im Vergleich von Logstash 1.x zu 2.x gibt es folgende Bemerkungen zu machen:

  • Das bisherige empfohlene Vorgehen, Logfiles über den Umweg Redis an Logstash zu shippen und keine Logeinträge zu verlieren, ist nun nicht mehr notwendig. Redis sollte den Verlust von Daten im Falle eines Crashs kompensieren. Es kann direkt von den Shippern an Logstash erfolgen, weil nun extra eine Batch Queue eingeführt wurde, die dieses Merkmal auch beherrscht.
  • Neu definiertes Errormanagement und bessere Resourcenverteilung in der JVM
  • Implementierung eines Clustermechanismus für HA
  • Genauere Darstellung von metrics und wesentliche Erweiterung der Konfigurationsmöglichkeiten
  • Der Logstash-Forwarder wurde entschlackt von Ruby hin zu mehr GoLang-Sprache, da diese oft um den Faktor 5-6 schneller ist, als Ruby on the Rails.

Vergleich Kibana 3.x zu 4.x

  • Der Hauptgrund von einem Wechsel von 3.x auf 4.x liegt in der Änderung von Elasticsearch, dass das auf Facets (ein API-Aufruf Richtung Elasticsearch) basierende Kibana 3.x nicht mehr unter Elasticsearch 2.x funktioniert (Facets existieren nicht mehr unter dieser Version)
  • Version 4.2.0 ist die erste Version von Kibana, die voll kompatibel mit Elasticsearch 2.0 ist und gleichzeitig nicht mehr abwärtskompatibel zu Elasticsearch 1.x ist. Also kurz gesagt: Elasticsearch 2.0 + Kibana 4.2 = 💚
  • Mit 4.2.0 wird wieder ein dunkles Dashboard eingeführt
  • Es ist möglich, für GeoIP WMS-Kartendienste (Web Management Services) einzubinden, also z.B. Topographische Karten oder Wetterkarten etc.
  • Es gibt eine neu eingeführte Statuspage, die über den Gesundheitszustand von Elasticsearch und des Kibana-Index Auskunft gibt
  • Farben werden nun zu Diagrammen und Daten fest zugeordnet, nicht mehr nach dem Zufallsprinzip
  • Die Legende kann in einem Diagramm auch als Filter benutzt werden
  • Benutzung von Olson timezones (auch IANA-timezones genannt) in data_histogram (more exact timed events)
  • Viele der benutzten Bibliotheken wurden aktualisiert, z.B. NodeJS
  • Es gibt nun eine About-Seite mit der exakten Version
  • Balkendiagramme können prozentual oder gestapelt angezeigt werden
  • Es wurden in den Diagrammen Erweiterte Optionen eingeführt, um diverse Anpassungen wie Ausschlüsse etc. abbilden zu können
  • Es können Daten nun auch in Daten-Tabellen dargestellt werden
  • Werte aus einer Visualisierung in CSV exportieren

Die Arbeiten sind auf unserem Logserver für das komplette Update auf Kibana 4.2.0, Elasticsearch 2.0 und Logstash 2.0 vollzogen. Dabei wird auch der darunter liegende Lucene Index von 4.10.4 auf Lucene 5.2.1 hochgezogen.

Im nächsten Artikel wird kurz angesprochen, wer dies auch immer ebenso plant, welche Schwierigkeiten oder deren Culprits identifiziert wurden, um anderen den Weg dorthin mit weniger Schwierigkeiten zu begehen und das Update zu einem erfolgreichen Abschluss zu bringen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.