Details über einzelne Logstash Filter rausfinden

Dass Logstash sehr performant ist, wissen hoffentlich alle, die ihn schon mal ausprobiert haben. Dennoch gibt es einige Kniffe, die man anwenden kann, um die Konfiguration so zu schreiben, dass Events noch schneller verarbeitet werden. Bisher war dabei nur das Problem, herauszufinden, ob das Tuning gefruchtet oder alles nur verschlimmert hat. Seit Version 5 hat Logstash nun eine eigene API bekommen, die es ermöglicht, etliche Informationen über den Logstash Dienst einzuholen. Diese ist per Default auf Port 9600 des Logstash Hosts erreichbar. (Eventuell, je nach Version, muss sie in /etc/logstash/logstash.yml aktiviert werden.)

# curl localhost:9600/_node/stats?pretty
...
  "process" : {
    "open_file_descriptors" : 79,
    "peak_open_file_descriptors" : 80,
    "max_file_descriptors" : 16384,
    "mem" : {
      "total_virtual_in_bytes" : 3390824448
    },
    "cpu" : {
      "total_in_millis" : 176030000000,
      "percent" : 3,
      "load_average" : {
        "1m" : 0.0,
        "5m" : 0.02,
        "15m" : 0.11
      }
    }
...

Neuer Versionen von Logstash 5 liefern sogar Details über einzelne Filter. Das Problem beim Anzeigen der Performancedetails ist nur, dass Logstash jedem Filter eine zufällige ID verpasst und ein Zuordnen nicht möglich ist. Wer jedoch die Logstash Issues auf Github verfolgt, erkennt, dass es sehr wohl eine Möglichkeit gibt, diese ID zu setzen – sie wurde nur noch nicht dokumentiert.

Folgende Konfiguration verpasst also dem angegebenen Filter eine ID, die nicht in Elasticsearch gespeichert und damit auch nicht in Kibana ersichtlich ist. Sehr wohl sichtbar ist sie jedoch über die Logstash API.

filter {
  if [program] == "kibana" {
    json {
      id => "kibana-json"
      source => "message"
      target => "kibana"
    }
  }
}

Die API liefert dann entsprechenden Output.

     {
        "id" : "kibana-json",
        "events" : {
          "duration_in_millis" : 908,
          "in" : 394,
          "out" : 394
        },
        "name" : "json"
      }

Wer keinen exec Input verwenden möchte, damit Logstash regelmässig seine eigene API abfragt, kann auch check_logstash verwenden, das es bereits als Checkcommand in die ITL von Icinga 2 geschafft hat. Über Feedback sowohl zum Plugin als auch zur Integration würde ich mich freuen. Und auch an dieser Stelle nochmal Danke an die, die bereits etwas beigetragen haben. Allen voran Jordan Sissel.

Vagrant Boxen, die die gezeigte Konfiguration bereits enthalten, gibt’s auch auf Github. Die sind zwar noch nicht so weit gediehen, wie ich das gern möchte, aber als Grundlage für eigene Experimente können sie durchaus dienen. Auch hier freue ich mich über Feedback.

Wer überhaupt gern mehr zu Logstash und dem Elastic Stack erfahren möchte, sollte sich für eine unserer Schulungen zu dem Thema anmelden. Wer jedoch noch nicht von Vagrant gehört hat, wird in einer anderen, unserer Schulungen fündig.

Thomas Widhalm

Autor: Thomas Widhalm

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 Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool. Seit 2017 stellt er sich neuen Herausforderungen als Lead Support Engineer und versucht sein Wissen aus den vorgenannten Tätigkeiten im Produktsupport umzusetzen.

Schnellere Neustarts für Elasticsearch

This entry is part of 11 in the series logstash

Dass Elasticsearch das “Elastic” in seinem Namen richtig ernst meint, hat jeder, der mal mit mehr als einem Knoten experimentiert hat, feststellen können. Anders als viele andere geclusterte Dienste können Knoten fast nach Belieben zu einem bestehenden Cluster hinzugefügt und wieder entfernt werden.

Wie ernst es Elastic mit der Elastizität ist, sieht man unter anderem an den folgenden Eigenschaften. (Wer sich intensiver mit Elasticsearch auseinandergesetzt hat, wird wissen, dass es sich hier um Defaulteinstellungen handelt und man in komplexeren Setups doch das eine oder andere einstellt und nicht dem Automatismus überlässt. Also bitte keine Kommentare wie “In meinem Cluster steht aber, dass gateway.expected_nodes den Wert 23 hat.”)

  • Elasticsearch Cluster haben üblicherweise nirgends vermerkt, wie viele Knoten der Cluster beinhaltet. Lastverteilung, Wahl des Masters, etc. rechnet immer mit der aktuell vorhandenen Anzahl an Knoten.
  • Es gibt keinen Weg, einen Knoten aus einem Cluster “sauber” zu entfernen oder ihn hinzuzufügen. Entfernen bedeutet Beenden des Dienstes und Hinzufügen bedeutet Starten des Dienstes mit gleicher Konfiguration wie der Rest.
  • Backups bzw. Snapshots werden von allen beteiligten Knoten auf einen Share geschrieben und von dort gelesen. Egal, wie viele Knoten zum jeweiligen Zeitpunkt aktiv sind. Ein zwei Knoten Cluster kann ohne weiteres einen Snapshot restoren, der von einem 12 Knoten Cluster gemacht wurde, solange die Ressourcen dazu ausreichen. Konfiguration braucht man dafür nicht.
  • Kommunikation mit dem Cluster geschieht üblicherweise über die REST-API eines einzelnen Knotens, der die Anfrage im Cluster weiter verteilt. Egal, ob es sich dabei um ein Query oder eine dynamische Konfigurationsänderung handelt.

Der Nachteil dieser Elastizität ist, dass der Cluster nicht wissen kann, ob ein Knoten entfernt wurde oder nur mal kurz neu gestartet wird. Das hat zur Folge dass üblicherweise sofort nach Wegummiringerlgfall eines Knotens der restliche Cluster beginnt, Shards und ihre Repliken (Daten in Elasticsearch werden in Indices aufgeteilt, die wiederum in Shards unterteilt werden, die ihrerseits in Repliken kopiert werden – so erreicht Elasticsearch mit beliebigen Daten Lastverteilung und Redundanz) umzuverteilen, um den “Verlust” des Knotens auszugleichen. Dazu werden die Daten, die auf diesem Knoten waren, sofort auf andere Knoten kopiert – das ist möglich weil Elasticsearch per default jeden Datensatz mindest zweimal vorhält. Nachdem die Redundanz wieder hergestellt ist, werden die Shards und Repliken nochmal verschoben, jedoch langsamer, um die Last im Cluster gleichmässig zu verteilen.

Was aber nun, wenn der Knoten sofort wieder dem Cluster beitritt, weil er nur, z.B. wegen eines Kernel Updates, rebooted wurde? Die Daten, die sich noch auf dem Knoten befinden, werden validiert, ob sie noch brauchbar sind oder in der Zwischenzeit verändert wurden und eventuell verschobene Daten werden vielleicht wieder zurückverschoben. Wird Elasticsearch als Teil des Elastic Stack mit Logstash und Kibana verwendet (und das wollen wir doch alle), dann werden üblicherweise nur in den Index des aktuellen Tages Daten geschrieben und die anderen bleiben unverändert. Da Elasticsearch das jedoch nicht weiss, wird der gesamte Datenbestand überprüft. Abhängig von verschiedenen Faktoren kann dieses Überprüfen wenige Minuten bis etliche Stunden dauern. Während dieses Prüfens sind üblicherweise die Daten nicht so verteilt, wie es sein soll und der Cluster bleibt im Status “Yellow”, was einige Arbeiten daran verhindert und auch bedeutet, dass kein weiterer Knoten ausfallen sollte, um Datensicherheit zu gewährleisten. Das macht den Neustart eines gesamten Clusters Knoten für Knoten im laufenden Betrieb zum Geduldsspiel.

Zum Glück gibt es einen einfachen, wenn auch nicht weithin bekannten, Weg, Elasticsearch vom Rebalancing des Clusters abzuhalten und auch die Daten bereits im Vorfeld als unveränderlich zu markieren.


curl -XPUT http://elasticsearch001:9200/_cluster/settings 
{
    "persistent": {
        "cluster.routing.allocation.enable": "none"
    }
}
curl -XPOST http://elasticsearch001:9200/_flush/synced

Mehr dazu gibt in der Elasticsearch Doku. Der erste Befehl schaltet das Umverteilen von Shards komplett ab und der zweite führt einen sogenannten “Synced Flush” aus. Dabei werden ein paar Ressourcen freigegeben und Elasticsearch erstellt etwas ähnliches wie eine Checksum für jeden Index, der sich in den letzten 5 Minuten nicht verändert hat. Diese beiden Befehle haben zur Folge, dass auch bei Wegfall (in unserem Beispiel Neustart) eines Knotens weder die Redundanz im Cluster wieder hergestellt noch die Last gleichmässig verteilt wird. Das ist in diesem Fall gut, da der Knoten ja gleich wieder da sein wird. Wenn denn der neu gestartete Knoten wieder da ist, prüft Elasticsearch nur kurz, ob die Prüfsummen noch stimmen, wovon auszugehen ist, und bringt die Shards und Repliken auf diesem Knoten sofort wieder online. Das beschleunigt einen Neustart enorm.

Wenn alle geplanten Neustarts abgeschlossen sind, muss unbedingt der folgende Befehl abgesetzt werden, um die Umverteilung wieder zu aktivieren, da Elasticsearch sonst nicht auf den echten Ausfall eines Knotens reagieren kann.


curl -XPUT http://elasticsearch022:9200/_cluster/settings
{
    "persistent": {
        "cluster.routing.allocation.enable": "all"
    }
}
Thomas Widhalm

Autor: Thomas Widhalm

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 Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool. Seit 2017 stellt er sich neuen Herausforderungen als Lead Support Engineer und versucht sein Wissen aus den vorgenannten Tätigkeiten im Produktsupport umzusetzen.

yum Plugins

Auch wenn viele ihn regelmäßig verwenden, so haben sich doch nur wenige mit seinen Möglichkeiten auseinander gesetzt: yum, der Paketmanager von RHEL, CentOS, Fedora (bis vor kurzem) und einigen anderen Distributionen aus dem RedHat Dunstkreis.

Zwar wird er in absehbarer Zeit durch dnf ersetzt werden, aber bis dahin zahlt es sich durchaus aus, nochmal ein wenig Energie in yum zu investieren.Yum

Eine meiner liebsten Funktionalitäten ist die Verwendung von Delta RPMs. Dabei werden Updates nicht mehr als ganzes Paket heruntergeladen, sondern nur der Unterschied zwischen der installierten und geplanten Version. Lokal am System wird aus dem installierten Paket und dem Delta RPM dann das neue RPM zusammengebaut und installiert. Je nachdem, welches Paket aktualisiert wird, kann sowas schon einiges an zu übertragenden Daten sparen. Ja, heutzutage sind Netzwerkleitungen oft dick genug, dass es ziemlich wurscht ist, ob man LibreOffice nochmal komplett herunterlädt, oder nur die paar kleinen Änderungen, aber in einigen Situationen fällt es sogar heute noch ins Gewicht. Nicht jeder hat eine überall eine Leitung, die dick genug ist. Z.B. in Schulungssituationen oder auf Konferenzen, kann es schon mal eng werden mit der Bandbreite. Ausserdem entlastet es natürlich die Server, die die Updates zur Verfügung stellen. Hauptsächlich finde ich es aber einfach eine gute Idee und ich hab’ Spass, wenn sich jemand bei einer Lösung was gedacht hat und ich sie einsetzen kann.

Musste man früher noch ein eigenes yum Plugin installieren, reicht seit CentOS 7 die Installation des deltarpm Pakets, um diese Funktionlität zu aktivieren, wenn die verwendeten Repos das anbieten.

Zwei Plugins befassen sich mit dem Entfernen von Paketen, die als Abhängigkeit installiert wurden, aber nun nicht mehr benötigt werden: yum-plugin-remove-with-leaves und yum-plugin-show-leaves. Damit lässt sich beispielsweise durch yum autoremove jedes Paket anzeigen und deinstallieren, das einmal als Abhängigkeit installiert wurde, dessen Grund, weshalb es installiert wurde, inzwischen schon wieder entfernt wurde. Ja ich weiß, Debian kann das auch so.

Mit yum-plugin-protectbase und yum-plugin-versionlock lassen sich einfach ungewollte Updates von bestimmten Paketen, insbesondere über Repository Grenzen hinweg verhindern.

Die Erweiterung yum-plugin-local erstellt aus heruntergeladenen und installierten Paketen ein lokales Repository. Gerade im Zusammenhang mit Containern oder virtuellen Maschinen kann ich es mir praktisch vorstellen, etwas zu bauen, mit dem sich einmal heruntergeladene Pakete leichter weiter verteilen lassen.

Ein besonders praktisches Plugin finde ich search-disabled-repos . Das gibt es unter CentOS 7 nicht als eigenes Paket, sondern nur als Teil des Subscription Managers, der eigentlich für die Verwaltung von RedHat Subscriptions auf RedHat Systemen gedacht ist, aber auch auf CentOS im Paket subscription-manager verfügbar ist. Damit laufen Installationen zukünftig folgendermassen ab: Versucht man ein Paket zu installieren, dessen Abhängigkeiten nicht aufgelöst werden können, bietet yum an, auch alle aktuell deaktivierten Repositories vorübergehend zu aktivieren und dort nach den fehlenden Abhängigkeiten zu suchen. Werden sie dort gefunden, bietet yum an, die nötigen Repos einmalig für die Installation zu aktivieren oder dauerhaft. Die Default Konfiguration verhindert dabei, dass ein -y beim yum Aufruf automatisch alle nötigen Repos aktiviert.

Ein recht hilfreiches Plugin für eine defensive Versionsstrategie ist yum-plugin-security. Dafür müssen aber alle verwendeten Repositories mitspielen. Ist es installiert, können mit yum update --security nur Security-relevante Updates installiert werden und alle anderen werden außen vor gelassen. Aber nicht alle Repos stellen diese Information zur Verfügung.

Was alle Plugins gemeinsam haben ist, dass ihre Konfigurationsdateien unter /etc/yum/pluginconf.d/ liegen. Da bei einigen nur enabled=1 drin steht, ist es wahrscheinlich einfacher, das Plugin einfach wieder zu deinstallieren, als es extra zu deaktivieren. Ansonsten lohnt sich oft durchaus ein Blick in die Dateien dort, um weitere Möglichkeiten zu entdecken.

Das waren nur ein paar der verfügbaren Plugins und auch nur als Anregung gedacht, sich mal näher damit auseinander zu setzen. Die meisten Plugins sind relativ eingägig in der Verwendung und fügen sich nahtlos in die übrigen yum Kommandos (z.B. auch in help) ein.

Thomas Widhalm

Autor: Thomas Widhalm

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 Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool. Seit 2017 stellt er sich neuen Herausforderungen als Lead Support Engineer und versucht sein Wissen aus den vorgenannten Tätigkeiten im Produktsupport umzusetzen.

Logstash 1.5 (bald) released

Während Version 1.5 von Logstash kurz vor dem Release steht, nehme ich mir kurz Zeit, schonmal einen Vorgeschmack darauf zu geben. Eine umfassende Liste der Änderungen findet man wie gewohnt im Changelog.

Besonders freue ich mich dabei auf folgende Neuerungen und Verbesserungen:

  • Plugin Manager: Man wird jetzt aus einer grösseren Menge an Plugins wählen und diese auch über Logstash nachinstallieren können. Ich hab’ zwar noch kein konkretes Plugin, das mir abgehen würde, aber das eröffnet doch ganz neue Möglichkeiten.
  • Konfigurationsdateien können jetzt nicht nur aus dem lokalen Dateisystem, sondern auch über http angezogen werden. Vielleicht eine etwas abenteuerliche Methode, aber sicher ein Weg, Konfig auf mehrere Hosts zu verteilen. Andererseits setzt hoffentlich eh jeder Puppet ein, oder?
  • Filter, die neue Events generieren (split, multiline, etc) reichen diese jetzt korrekt an folgende Filter weiter.
  • Man kann jetzt ein Standardverzeichnis für eigene Patterns angeben. Damit spart man sich unter Umständen einiges an Tipparbeit.
  • Syslog Inputs, die mit Nachrichten in einem falschen Format gefüttert werden, schreiben jetzt eigene Tags, damit man sie leichter debuggen kann.logstash_01
  • Der Elasticsearch Output unterstützt jetzt https mit Anmeldung!
  • Mehrere Hosts im Elasticsearch Output für mehr Hochverfügbarkeit.
  • Heartbeat Information von Logstash, damit man ihn leichter monitoren kann.

Ausserdem wurden einige Teile anscheinend enorm in ihrer Performance verbessert, was sowieso nie schlecht ist und Kibana 3 verschwindet mit Logstash 1.5 auch aus dem Logstash Paket.

 

Thomas Widhalm

Autor: Thomas Widhalm

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 Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool. Seit 2017 stellt er sich neuen Herausforderungen als Lead Support Engineer und versucht sein Wissen aus den vorgenannten Tätigkeiten im Produktsupport umzusetzen.

Elasticsearch Tribe Node

This entry is part 10 of 11 in the series logstash

Elasticsearch hat sich einen Namen damit gemacht, in ungeahnte Grössen zu skalieren, aber manchmal ist ein Cluster einfach nicht genug. Für diese Fälle wurde der Elasticsearch Tribe Node eingeführt, eine spezielle Elasticsearch Instanz, die selber keine Daten hält, sondern mehrere Cluster miteinander verbindet und so den Zugriff auf die Daten der einzelnen Cluster erlaubt, als wären alle Daten in einem einzigen grossen Cluster vorhanden.

Allerdings wird der Tribe Node nicht verwendet, um Grössenbeschränkungen von Elasticsearch Clustern zu umgehen, da die Anzahl von Knoten innerhalb eines Clusters nur durch die zur Verfügung stehenden Ressourcen beschränkt ist. Dabei ist der Bedarf eines einzelnen Knoten so wenig, dass hunderte bis tausende Knoten innerhalb eines Clusters möglich sind.

Übliche Anwendungen des Tribe Node sind:

  • Organisatorische Einschränkungen: Verschiedene Teams sollen Zugriff auf ihren jeweils eigenen Cluster aber nicht auf die Cluster anderer Teams haben. Dennoch soll eine übergeordnete Instanz Zugriff auf alle Daten über eine gemeinsame Schnittstelle haben.
  • Rechtliche Einschränkungen: Wenn Daten in einer bestimmten geographischen Position (z.B. ein bestimmtes Land) gespeichert werden müssen, die Daten jedoch zentral abgefragt werden sollen. (Achtung, ich bin kein Jurist. Ob dieses Konstrukt wirklich solche Einschränkungen erfüllt, ist in den einzelnen Fällen extra zu ermitteln!)
  • Einschränken von Traffic: Besonders bei der Verwendung von Elasticsearch als Teil des ELK Stacks (also mit Logstash) werden oft sehr grosse Datenmengen in die Cluster geschrieben. Wird ein einzelner Cluster verwendet, um alle Daten aus Remote Offices oder verschiedenen Firewallzonen zu sammeln müssen entweder Daten vorgefiltert werden, wodurch auf Events verzichtet werden muss oder die grossen Datenmengen über Firewalls oder WAN Leitungen geschickt werden. Mit dem Tribe Node können die Daten lokal in eigenen Clustern gesammelt und zentral abgefragt werden, wobei nur die Anfrage und die aufbereitete Antwort übertragen werden müssen.

Die Konfiguration des Tribe Node ist denkbar einfach. Man gibt die Namen des Clusters in den folgenden Optionen in der /etc/elasticsearch/elasticsearch.yml an und startet den Dienst. Dabei sollte der Tribe node selbst jedoch keine Daten enthalten.

tribe:
  es1:
    cluster.name: cluster1
    discovery:
      zen:
        ping:
          multicast:
            enabled: false
          unicast:
            hosts:
              - 192.168.23.228:9300
  es2:
    cluster.name: cluster2
    discovery:
      zen:
        ping:
          multicast:
            enabled: false
          unicast:
            hosts:
              - 192.168.69.229:9300

Da sich die Cluster oft in verschiedenen Subnetzen befinden, wurde hier auch gleich multicast discovery deaktiviert und die Verbindungen zu Knoten aus den einzelnen Clustern per unicast htribe-nodeergestellt.

Wichtig ist, dass man am Tribe Node zwar lesen und schreiben, jedoch keine Indices anlegen kann. Will man also Kibana auf so einem Tribe Node nutzen, muss man den von Kibana zu nutzenden Index für eigene Daten (Dashboards, etc.) in einem der im Tribe Node zusammengefassten Cluster selbst anlegen bzw. Kibana erst mit einem der Cluster verbinden und den Index anlegen lassen, bevor man es auf den Tribe Node umleitet.

 

Mehr Info zum Tribe Node gibt’s in der Elasticsearch Dokumentation.

Thomas Widhalm

Autor: Thomas Widhalm

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 Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool. Seit 2017 stellt er sich neuen Herausforderungen als Lead Support Engineer und versucht sein Wissen aus den vorgenannten Tätigkeiten im Produktsupport umzusetzen.