Tools

Logserver – Kibana 4.2-Elasticsearch 2.0-Logstash 2.0 – Update von früheren Versionen – Installation und auftretende Schwierigkeiten beseitigen

Im letzten Blogbeitrag wurde zuerst einmal geklärt, wie die einzelnen Produkte in Relation stehen. Heute soll nun geklärt werden, wie das eigentliche Update erfolgt von

  • Elasticsearch 1.x zu 2.0,
  • Logstash 1.x auf 2.0,
  • Kibana 4.0.x/4.1.x auf 4.2.0 erfolgt.

Elasticsearch

Beginnen wir zunächst mit der Datenbasis. Beim Wechsel auf die Elasticsearch 2.0 von Version 0.90/1.x Elasticsearch, gibt es aus meiner Sicht zunächst folgende Frage zu stellen:

In der neuen Version 2.0 wurde einiges geändert. Sind also meine aktuell in Elasticsearch gespeicherten Daten und die bisher implementierten Logiken in Logstash überhaupt kompatibel mit dem neuen Update? Kann ich so etwas wie einen Check vor dem Update durchführen? Diese Frage kann das Migration-Plugin beantworten, welches extra für diesen Zweck geschaffen wurde und man aus dem Elasticsearch-Verzeichnis heraus installieren kann:

(falls man einen Proxy benötigt, kann man diesen noch mit -DproxyPort=<proxyPort> -DproxyHost=<proxyHost> ergänzen)

Das Migration Plugin müsste nach Installation dort mit  bin/plugin --list  aufgelistet werden. Der Aufruf erfolgt über und natürlich unbedingt VOR dem Update:

http://<host>:<port>/_plugin/migration/

So sollte es aussehen, wenn alles ok ist und zum Update bereit ist.

Kibana2Eine unter Anderem wichtige zu erwähnende Sache wäre, wenn jemand Felder mit enthaltenen Sonderzeichen per Logstash shippt. Dies funktioniert nicht mehr under ES2.0:

In fields not allowed – these characters are illegal:

\
/
*
?

<
>
|
<space>
,
.
<null>

In solch einem Fall kann man schon einmal seine Logstash Regeln anpassen.

Bei mir war das z.B. beim Übertragen der metrics der Fall, welche bisher beispielsweise die Namen (mit nicht mehr enthaltenen Punkten) trugen:

Nach neuer Nomenklatur müssen diese nun als Array in der Logstash Config angesprochen werden

Weiterhin habe ich noch das altbekannte kopf-Plugin installiert, um die Verfügbarkeit von elasticsearch in einer schöneren GUI zur Verfügung zu haben.

Erreichbar unter http://:/_plugin/kopf

Kibana3

 

 

Kibana3_2

 

Oben der Nodeszustand  und unten der Clusterzustand.
Anschließend kann man schon einmal seiner neuen Elasticsearch Installation das data Verzeichnis vom alten Elasticsearch vorlegen und ES starten. Im Hintergrund wird der Index dann schon aktualisiert.

Im Zuge des Updates habe ich noch in der elasticsearch.yml die settings

gepflegt, weil ich sonst mit der Logstash Config Probleme beim Finden der Shards hatte. Sicher ließe es sich auch anders lösen, aber es gibt bekanntlich viele Wege nach Rom.
Ebenfalls neu ist, dass es nicht mehr möglich ist, elasticsearch per curl mit /_cluster/nodes/_local/_shutdown oder der jeweiligen node herunterzufahren.

Näheres dazu kann man in der Doku nachlesen:

The _shutdown API has been removed.

https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-nodes-shutdown.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-service.html

Dies wird nun klassisch per Script realisiert und mit einer echten Daemon-PID-file Lösung ersetzt.

Es gibt noch ein Gimmik für elasticsearch: ES2.0 unterstützt nämlich nun einen neuen Kompressionsalgorithmus DEFLATE neben dem bisherigem LZ4. DEFLATE ist effizienter, wenn es um Speicher auf der Disk geht.

Erreicht wird das, indem man in config/elasticsearch.yml  den Wert  "index.codec": "best_compression"  ergänzt.

 

Laut der Metriken hat der Wechsel zur neuen Version etwas gebracht.

Diese Verbesserung ist vor allem darauf zurückzuführen, dass Logstash nun standardmäßig mit 12 parallelen workern Richtung elasticsearch shippt statt mit einem worker.

Eine weitere Steigerung erfolgte mit Wechsel des Kompessionsalgorithmus von LZ4 auf DEFLATE.

 

Logstash

Zunächst gibt es auch hier zu bedenken, welche Plugins installiert sind. Diese erhält man mit   bin/plugin list .

Da ich mich für das Elasticsearch Output Protokoll “transport” entschieden habe, ist dieses mit Logstash in ein eigenes Modul gewandert und wird mit  bin/plugin install logstash-output-elasticsearch_java  nachinstalliert.

Mitgeliefert wird standardmäßig das HTTP Protokoll, welches aber durch den TCP-Stack mehr Overhead hat und es im Falle von Logspitzen sinnvoll sein kann, nicht so viel Overhead zu haben. Welche Gründe für welches Protokoll sprechen, kann jeder selbst nach dieser Lektüre entscheiden:

https://www.elastic.co/blog/found-interfacing-elasticsearch-picking-client

Da ich mich als Logshipper für Log Courier von Driskell entschieden habe, installiere ich noch dessen Plugins nach:

Dazu später noch mehr.
Anschließend kann man alle Updates mal auf den aktuellen Stand bringen:

In der Logstash Config sind mittlerweile folgende Settings obsolet und Logstash funktioniert nicht, wenn diese noch in der entsprechenden Rubrik der Config-Datei vorkommen:

input             –> Obsolete config settings (which were already deprecated): debug, format, charset, message_format

filter and output –> Obsolete config settings (which were already deprecated): type, tags, exclude_tags

Nachdem hier die Config angepasst ist, sollte man ein configtest machen:

Ich habe dann schon ein OK bekommen.
Im Falle von Elasticsearch output mit dem Transport Protocol sollte man nun als output elasticsearch in elasticsearch_java ändern, wenn HTTP benutzt wird, elasticsearch lassen.

Es gab dann noch einen logischen Fehler in der Config, weil hosts bei mir nicht mehr benötigt wird; ich habe es durch network_host ersetzt.

Die Nomenklatur ist hier, dass IP/Servername in eckige Klammern geschrieben wird.

Anschließend lief auch logstash und begann zu shippen.

 

Allerdings nutze ich geoip zur Transformation in Logstash, welches auf folgenden Fehler lief:

Das lässt sich in der aktuellen Version lösen, indem man in der Rubrik output der Config Datei angibt:

Das Output Template liegt im Pluginfolder

, in dessen Unterverzeichnis

falls man Anpassungen durchführen muss.

Dort ist dann unter geoip “path”: “full”, nicht enthalten und funktioniert endgültig mit dem Transport in Elasticsearch ohne Fehlermeldung.

Es gäbe nun auch noch die Möglichkeit, das verbesserte Plugin für Windows Eventlogs zu nutzen. Dieses macht es einfacher, Windowslogfiles Richtung Elasticsearch einzubinden, die ja nicht direkt Textdateien sind, sondern in einem speziellen Microsoft Format vorliegen.

Die Installation des Plugins geschieht über:

https://www.elastic.co/guide/en/logstash/current/plugins-inputs-eventlog.html

War in meinem Fall jedoch nicht benötigt.

Logstash Shipper

Als Logstash Shipper habe ich mich schon länger für Log Courier von Driskell entschieden.

Der Vorteil dieses Logshippers ist, dass er schon auf Clientseite Multilinefilter bietet, was den zentralen Logstashfilter entlastet, welcher bisher nicht thread-safe (kann also nicht an mehreren Stellen innerhalb Logstash mehrmals ausgeführt werden, sondern immer nur eine Instanz) war und damit im Logstash zentral – falls dort verwendet.

EIn weiterer Grund ist, dass der Shipper ein Admin-Tool mitliefert, welches für das Monitoring auf Clientseite hilfreich ist.

Hier gab es weiter keine nötigen Anpassungen für das Update.

Kibana

Ein Update von Kibana 3.1.2 auf 4.0 wird hier nicht betrachtet, sondern lediglich von 4.0.x/4.1.x auf 4.2.0.

Die Installation von Kibana funktionierte eigentlich fast auf Anhieb, da die vorherigen Schritte an dieser Stelle dazu geführt haben, dass die Daten konsistent waren.

Wer hier noch tiefer ins Kibana einsteigen möchte oder muss, kann auch starten mit:

Dazu kann man eine spezielle config/kibana.dev.yml pflegen.

Eine genauere Doku dazu gibt es hier:

http://webpack.github.io/docs/configuration.html#devtool

Man kann auch ein Log schreiben zu Kibana

Und gegebenenfalls auch das Kibana mehr sprechen lassen mit

In einem kommenden Beitrag wird Kibana näher besehen, da dies die letztlich die Anwenderschnittstelle ist.

Schreibe einen Kommentar

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