Im folgenden gebe ich einen kurze Übersicht über ein paar Handgriffe, die sich beim Debuggen des Elastic Stack bewährt haben. Vor allem beim Beantworten der Frage “Wo verdammt sind meine Events?”
In Kibana
Zuerst wird man wohl bemerken, dass Events fehlen, wenn man sie in Kibana nicht finden kann. Bevor man sich aber in die Tiefen der Konfiguration begibt, sollte man also erstmal die Möglichkeiten des Webinterface völlig ausschöpfen.
- Ist ein Filter gesetzt, der die Nachrichten ausblendet?
- Wurde ein falscher Zeitbereich gewählt?
- Kann es sein, dass der sendende Host eine falsche Zeiteinstellung hat und die Events deshalb an einer falschen Position des Zeitstrahls angezeigt werden?
- Wurde das falsche Index-Pattern gewählt?
Einfach zurück setzen kann man die meisten dieser Einstellungen durch einen Klick auf die “New” Schaltfläche im Kibana-Discover.
Führt all das nicht zum Erfolg, folgen tiefer greifende Schritte.
Message Broker
Sehr leicht nachvollziehen kann man, ob Nachrichten im Message broker festhängen, falls man denn einen benutzt. Füllen sich Redis, Kafka oder ähnliches, dann ist auf jeden Fall im Ablauf etwas falsch oder der Stack zu klein gesized. Bei mehreren Pipelines kann hier auch gut nachvollzogen werden, an welcher Stelle es klemmt. Dabei helfen aussagekräftige Namen beim Ablegen im Broker z.B. für Keys in Redis.
Den Füllstand des Brokers sollte man übrigens auch deshalb ständig im Blick haben. Das check_redis.pl Plugin für Icinga bietet sich dafür an.
Logstash
Bevor an der Konfiguration Änderungen vorgenommen werden, sollte unbedingt das Log von Logstash und Elasticsearch geprüft werden. Ein häufiges Problem ist ein “type mismatch” in einem Feld, das verhindert, dass ein Event in Elasticsearch geschrieben wird. Beim Verwenden von dynamic mapping (dem default) wird jedem Feld der Typ verpasst, den das erste Event aufweist, das in diesen Index geschrieben wird. Steht also in client.port eine Nummer, wird Elasticsearch hier den Typ int zuweisen. Kommt später ein Event, wo client.port Text enthält (warum auch immer), dann wird dieses Event mit einer Meldung im Logstash Log verworfen.
Führt auch das nicht zum Erfolg, gibt es einige Tricks, die man anwenden kann, um die Funktionsweise genauer zu durchleuchten.
- Einzelne Pipelines können in der
pipelines.ymlvorübergehend deaktiviert werden. Das bietet sich vor allem für “output” oder “forwarder” pipelines an, die an Elasticsearch schreiben - Jedem Filter eine id zu vergeben ist immer eine gute Idee. Damit kann man auch sehr gut im Kibana Monitoring sehen, welcher Filter wie viele Events verarbeitet
- Praktisch ist auch, sich Konfigdateien zurecht zu legen, die nur für’s Debugging gebraucht werden. Bei Bedarf kann man diese in die Verzeichnisse der Pipelines kopieren und danach wieder löschen. Ich verwende dabei gern einen
mutateFilter, der einfach nur ein Tag setzt, um zu sehen, ob überhaupt bestimmte Events durch eine Pipeline kommen. Außerdem eine weitere Datei mit einem file Output, der mir alle Events in der Pipeline in eine Testdatei schreibt. Optional kombiniert mit dem dot Codec kann man so sehen, wie viel durch fließt, wenn die genauen Events gar nicht relevant sind. Diese Files kann man dann einfach in die einzelnen Pipelines legen und wieder raus nehmen. Verwendet man sie mehrfach, muss man aber darauf achten, Doubletten zu vermeiden, also verschiedene Namen für Tags, verschiedene Files als Ziel etc. - Der obige Tip funktioniert natürlich auch mit mutate Filtern, die man kurzerhand mitten in die eigene Konfig schreibt – z.B. in ein if – um dort Tags und Felder mitzugeben, nach denen man dann sucht
- Falls Logstash eine Pipeline nicht starten kann, liegt das häufig an Tippfehlern in der Konfiguration. Um diese zu finden kann man den Pfad der Konfig einer Pipeline aus der pipelines.yml kopieren und durch cat anzeigen lassen. Dieser Copy&Paste Ansatz verhindert, dass man z.B. nur eine einzige Datei in der
pipelines.ymlangegeben hat, aber erwartet, dass das ganze Verzeichnis angezogen wird. Wichtig dabei zu wissen ist, dass Logstash durchaus auch eine einzelne Pipeline offline nehmen kann und der Rest weiter läuft
Wer noch mehr zum Thema Troubleshooting bei Elastic Stack wissen will und das auch mal praktisch ausprobieren möchte, hat dazu in unseren Elastic Stack Schulungen zum Thema Logmanagement Gelegenheit.
0 Comments