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.
gfall 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.
