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.

Diving into Elastic Stack 5.0.0-beta1 and Elastic Beats

logo2_elastic_150x75I’m always trying to look into new devops tools and how they fit best with Icinga 2 as a monitoring solution. Often demanded is an integration with Elastic Stack and Elastic Beats with Icinga 2. Gathering metrics and events, correlated to additional input sources analysing a greater outage and much more.

Last week the first 5.0.0 beta1 release hit my channels and I thought I’d give it a try. The installation is pretty straight forward using packages. Note: This is my first time installing Elastic Stack, still have little knowledge from colleague hero stories and the OSDC talk by Monica Sarbu and earlier conferences.

(more…)

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉

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.

Ein Buch über Icinga 2

Erscheint am 27. Juni 2016

 
41suqaLOyCL._SX336_BO1,204,203,200_April 2015, nach Monaten des Schwankens machten sich dann zwei verbliebene Möchtegernautoren doch auf ein Buch zum Thema Icinga 2 zu verfassen. Wir wollten ein sehr praxisnahes Werk mit vielen Beispielen wie und mit welchen Plugins etwas zu überwachen ist. Herausgekommen sind 344 Seiten von denen sich 100 mit Plugins und deren Verwendung in Icinga 2 befassen. Vorweg erfolgt eine generelle Einführung, die Vorstellung des neuen Webinterfaces Icingaweb 2 als auch eine ausführliche Erläuterung wie man lokale Werte wie Load bzw. CPU bei Windows oder Disk Usage mit NRPE/NSClient++, SSH und selbstverständlich mit dem neuen Icinga Agenten ermittelt.

Dem Kapitel über Plugins ist noch die Vorstellung einer fiktiven Firma vorangestellt. Diese betreibt ein zweigeteiltes Netzwerk mit einem internen Netz und eine durch Perimeter abgetrennte DMZ. Anhand dieses Beispiels wird eine verteilte Überwachung implementiert. Im internen Netz ist ein Icinga-Server (Master) für die Überwachung der dortig angesiedelten Server und Dienste zuständig. Für die DMZ wird ein weiterer Icinga-Server (Satellit) verwendet, der die ermittelten Ergebnisse an den Master meldet.

Diese Icinga-2-Infrastruktur wird dann im Folgenden benutzt, um eine Vielzahl von Diensten zu überwachen:

  • Host Erreichbarkeit
  • Zeitserver und lokale Zeit
  • Webservices incl. Apache und Ngnix
  • Domain Name Services
  • DHCP
  • Kerberos
  • Mailempfang und -versand
  • Proxy-Server
  • Generische Portüberwachung am Beispiel von Jabber
  • Javabasierte Application-Server
  • SAP
  • Kibana
  • Microsoft-Infrastrukturdienste: CIFS, Terminalservice, Domaincontroller, Exchange
  • Datenbanken: MySQL, PostgreSQL, MS SQL, Oracle
  • LDAP
  • Redis
  • Elasticsearch
  • VMware vSphere
  • Hardware: IPMI, HP, Oracle Solais, Thomas Krenn, Netzwerk, Festplatten
  • NetApp
  • Qnap

Das letzte Drittel ist Graphing mit PNP4Nagios und Graphite, Logmangement, Reporting und Businessprozessen gewidmet.

Teilbereiche werden von den beiden Autoren in einem Workshop vor der diesjährigen Open Source Monitoring Conference mit den Teilnehmern zusammen praktisch umgesetzt.

Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

OSDC 2016 – Klappe, die erste

Montag, 25.04. 2016
Haben wir alles dabei? Haben wir auch wirklich nichts vergessen und an alles gedacht? Jaaaaa, wir haben alles! Und los geht’s zur OSDC 2016. Unser Events-Team und unsere Trainer reisten bereits am Montag ins Mercure Hotel MOA nach Berlin und bereiteten alles für die Workshops am Folgetag vor. Als dann alles aufgebaut war, haben wir uns – wie gewohnt – mit Essen belohnt. Nachdem unter anderem diverse 42 cm Pizzen verdrückt wurden, fielen alle zufrieden in Ihre Betten, voller Erwartungen an den nächsten Tag.

Dienstag, 26.04.2016
Der erste Tag der Konferenz startete mit unseren drei Intensiv-Workshops. Die Teilnehmer konnten zwischen Docker, Elastic Stack und Graphing wählen. Um 10 Uhr morgens ging es für alle los. Leckeres Essen in den Pausen brachte den Trainern und Teilnehmern die Kraft für die Intensiv-Workshops, ehe die restlichen NETWAYS Mitarbeiter im Hotel ankamen, um das Events-Team beim Aufbau für die Konferenz tatkräftig zu unterstützen.

Nach getaner Arbeit durften Teilnehmer, Trainer, Referenten und Mitarbeiter ein tolles gemeinsames Abendessen im Konferenzhotel genießen. Für die NETWAYS Crew ging es anschließend, in geordneten Zweierreihen versteht sich, Richtung Mitarbeiterhotel – natürlich nicht, ohne noch einen Stopp beim allseits beliebten “Tele-Inder”* einzulegen. Und da auf (starken) Durst bekanntlich der (Heiß-)Hunger folgt, lag es nahe, noch ein paar Schritte weiter zu gehen, um beim “Dönerturm” nach dem Rechten zu sehen…  😉



 

Redaktionelle Anmerkung

*Tele-Inder, der: Seines Zeichens rassiger Berliner Spätkauf, der den entwurzelten NETWAYSlern bei Widrigkeiten jedweder Art, aber auch in allen anderen Gemütslagen, gerne als heimelige Zuflucht in der fernen preußischen Hauptstadt dient.

Teleinder

Julia Hackbarth

Autor: Julia Hackbarth

Julia ist seit 2015 bei NETWAYS. Sie hat im September ihre Ausbildung zur Kauffrau für Büromanagement gestartet. Etwas zu organisieren macht ihr großen Spaß und sie freut sich auf vielseitige Herausforderungen. In ihrer Freizeit spielt Handball eine große Rolle: Julia steht selbst aktiv auf dem Feld, übernimmt aber auch gerne den Part als Schiedsrichterin.

To secure one of the last few remaining OSDC tickets you will have to be FAST & FURIOUS!

osdc_aktuelles_Konfbanner_registerThe Open Source Data Center Conference highlights current challenges and opportunities of open source software in data centers and huge IT environments, while covering the entire scope of OS data center solutions.

This year’s conference program is focused on the thematic topics INFRASTRUCTURE AS CODE, CONTAINERS AND DATABASES and TOOLS & INFRASTRUCTURE. Besides that, you can – as always – look forward to the the conferences’ second key feature: the great and exclusive opportunity for exchange of ideas and latest knowledge as well as in-depth discussions with other experienced professionals and well known experts in the field of OS data center solutions. To get a first impression, check out our evening event location as well as the relaxed and casual atmosphere provided by the conference venue.

The high class speaker line-up 2016 includes OS-experts as Jörg Schad, software engineer at Mesosphere, supporting the Apache Mesos Project; Monica Sarbu, creator of the Packetbeat open source project and team lead of the Beats inside Elastic; Jonathan Boulle, working at CoreOS; Dawn Foster, consultant at The Scale Factory; Kris Buytaert, one of the instigators of the devops movement, currently working for Inuits; Ján Lieskovský, software engineer at Red Hat and many more.

Secure your ticket now and profit from the comprehensive experience of international OS specialists, proven best practices and the get latest know-how for your daily practice!

If you are lucky you might even catch one of the strictly limited workshop seats, that are still available. Workshop topics are: ADVANCED GRAPHING – with Graphite, DOCKER – Virtual Containers and ELASTIC STACK – Enterprise Logfile Management.

 

Pamela Drescher

Autor: Pamela Drescher

Pamela hat im Dezember 2015 das Marketing bei NETWAYS übernommen. Sie ist daher speziell für die Corporate Identity unserer Veranstaltungen sowie von NETWAYS insgesamt verantwortlich. Die enge Zusammenarbeit mit Events ergibt sich aus dem Umstand heraus, dass sie vor ein paar Jahren mit Markus zusammen die Eventsabteilung geleitet hat und diese äußerst vorzügliche Zusammenarbeit nun auch die Bereiche Events und Marketing noch enger verknüpft. Privat ist sie Anführerin einer vier Mitglieder starken Katzenhorde, was ihr den absolut schmeichelhaften Vergleich mit einer gewissen "Crazy Cat Lady" eingebracht hat...