Seite wählen

Events im Elastic Stack verfolgen

von | Nov 26, 2020 | Elastic Stack

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.yml vorü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 mutate Filter, 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.yml angegeben 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.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...
Mehr Beiträge zum Thema Elastic Stack

Namen sind Schall und Rauch? Lieber nicht.

Das Problem Bei vielen Projekten zu Logmanagement stellt sich recht schnell die Frage nach der Benamsung der Felder, in die Events zerlegt werden sollen. Da man sie weitestgehend frei wählen kann, startet so schnell ein gewisser Wildwuchs und das unabhängig davon, ob...

Logstash automatisiert ausrollen? Freilich!

Der Lennart sagt mir ja immer, ich soll nicht über ungelegte Eier sprechen, aber momentan fasziniert mit das Thema einfach zu viel, als dass ich nicht drüber was schreiben könnte. Dass ich gern mit dem Elastic Stack arbeite, sollten auch weniger aufmerksamere Leser...

Veranstaltungen

Di 19

Icinga 2 Advanced Training (englisch class) | Online

Januar 19 @ 09:00 - Januar 21 @ 17:00
Feb 02

Elastic Stack Training | Online

Februar 2 @ 09:00 - Februar 4 @ 17:00
Feb 10

GitLab Fundamentals Training | Online

Februar 10 @ 09:00 - Februar 11 @ 17:00
Feb 23

Terraform mit OpenStack Training | Online

Februar 23 @ 09:00 - Februar 24 @ 17:00
Feb 23

Fundamentals for Puppet | Online

Februar 23 @ 09:00 - Februar 25 @ 17:00