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.