Logstash-Konfiguration im Team

Das folgende Setup hat sich als Entwurf bei einem Kundenprojekt ergeben. Es ist noch nicht in die Realität umgesetzt, aber ich fand es interessant genug, um es hier teilen zu wollen.

Aufgabe

Hier kurz die Ausganslage, für die das Konzept erstellt wurde.

  • Mehrere Teams wollen Logs über den Elastic Stack verarbeiten
  • Die Logs sind teilweise Debuglogs aus Eigenentwicklungen. (Erfahrene Logmanagement-Admins lesen hier “sich häufig ändernde und nicht immer klar strukturierte Logformate”)
  • Die Logmanagement-Admins haben nicht die Kapazität, Logstash-Regeln für alle verwalteten Applikationen zu schreiben und vor allem nicht ständig anzupassen
  • Das zentrale Logmanagement ist sehr wichtig und soll durch unerfahrene Anwender nicht gefährdet werden

Lösungsansatz

Im Gespräch hat sich dann ein Setup ergeben, das ungefähr so aussehen soll:

  • Es wird eine Entwicklungsmaschine geschaffen, auf der die einzelnen Teammitglieder ssh-Logins bekommen. Auf dieser Maschine ist Logstash installiert, wird aber nicht ausgeführt
  • Jedes Team bekommt ein Repository in der zentralen Versionsverwaltung (z.B. GitLab ) und kann das auf der Entwicklungsmaschine auschecken. In diesem Repository befindet sich die gesamte Logstash-Konfiguration einer Pipeline und ggf. Testdaten (siehe weiter unten)
  • Die Mitglieder des Teams entwickeln ihre Pipeline und nutzen den lokalen Logstash zum Testen auf syntaktische Richtigkeit.
  • Optional können zusätzliche Pipelines zur Verfügung gestellt werden, die Beispieldaten einlesen und wieder in Dateien rausschreiben. Diese beiden Dateien können mit eingecheckt werden, man muss nur darauf achten, sie nicht so zu benennen, dass Logstash sie als Konfiguration ansieht. Es empfiehlt sich, die Beispieldaten aus allen möglichen Logzeilen der Applikation zusammenzusetzen. Bei Änderungen sollten auch alte Zeilen belassen werden, um Logs aller möglichen Versionen einlesen zu können. Sollen die Daten mit Elasticsearch und Kibana veranschaulicht werden, kann in den Beispieldaten ein Platzhalter für den Zeitstempel verwendet werden, der vor dem Einlesen durch die aktuelle Zeit ersetzt wird. Die Pipelines werden einmal eingerichtet und bleiben dann statisch, sie werden nicht von den Teams bearbeitet und befinden sich nicht in zugänglichen Repositories
  • Beim Commit der Konfiguration in Git wird ein pre-commit-hook ausgeführt, der nochmal mit Logstash testet, ob die Konfiguration fehlerfrei ist. (Vertrauen ist gut, etc.)
  • Ist der Commit gut verlaufen, wird nach dem Push ein CI Tool wie Jenkins benutzt, um die aktuellen Stände sämtlicher Pipelines auf einer Testmaschine auszurollen. Dort wird Logstash dann kurz gestartet, mit fest konfigurierten Pipelines, die Daten einlesen und ausgeben. Statt wie auf einem Produktionssystem Ports zu öffnen und an Elasticsearch oder Icinga zu schreiben, werden die Logdaten aus den eingecheckten Dateien mit Beispieldaten gelesen und in Dateien geschrieben. Dabei ist es wichtig, dass alle Daten von allen Teams in die selbe Instanz gelesen werden. Nur so kann verhindert werden, dass sich die Teams  gegenseitig “dreinpfuschen”
  • Die ausgegebene Dateien werden auf ihre Richtigkeit geprüft. Das klingt aufwändiger als es ist. Es reicht eigentlich, eine funktionierende Konfiguration mit den oben genannten in- und outputs laufen zu lassen und das Ergebnis als Vorlage zu verwenden. Diese Vorlage wird dann mit dem tatsächlichen Ergebnis verglichen. Arbeiten die Teams schon im ersten Schritt mit den optionalen In- und Outputdateien, kann dieser Punkt stark vereinfacht werden, da man davon ausgehen kann, dass jeder seine eigenen Outputdateien schon berichtigt hat und sie nur mehr geprüft werden müssen
  • Abweichungen von der Vorlage werden überprüft und danach entweder die Logstash-Konfiguration erneut angepasst oder die Vorlage angepasst, sodass weitere Tests erfolgreich sind
  • War der Test erfolgreich, kann die Konfiguration getagged und auf den Produktionsservern ausgerollt werden

Weitere wichtige Punkte

Hier noch ein paar Punkte, die beim Umsetzen helfen sollen.

  • Logstash kann mit der Option -t auf der Shell gestartet werden. Dann prüft er nur die Konfiguration und beendet sich gleich wieder. Das kann auch in der logstash.yml hinterlegt werden
  • Um letztendlich zu verhindern, dass zwei Teams das selbe Feld mit unterschiedlichem Typ schreiben muss extra Aufwand betrieben werden. Entweder muss sich jeder an eine bestimmte Nomenklatur halten, oder jedes Team bekommt ein eigenes Feld und darf nur Unterfelder davon anlegen oder jedes Team schreibt in einen eigenen Index
  • Wenn jedes Team eine eigene Pipeline mit eigenem Input und Output bekommt, kann die Gefahr einer gegenseitigen Beeinflussung minimiert werden. Das ist aber nicht immer möglich oder sinnvoll. Oft schreibt ein Beat Logs von verschiedenen Applikationen oder es gibt nur einen gemeinsamen UDP/TCP input für syslog.
  • Jedes Team kann sich nach wie vor die eigene Konfig zerstören, aber mit dem oben geschilderten Setup kann man ziemlich umfassend sicherstellen, dass auch wirklich jeder nur seine eigene Konfig zerlegt und nicht alle anderen in den Tod reisst.
  • Die von den Teams verwalteten Pipelines haben jeweils nur einen Input aus einem Messagebroker (z.B. Redis) und einen Output ebenfalls in einen Messagebroker. Das kann der selbe sein, wobei dann darauf zu achten ist, dass der verwendete key ein anderer ist. So kann auf den verschiedenen Maschinen jeweils eine völlig andere Pipeline in den Broker schreiben oder raus lesen. Auf den Entwicklungsmaschinen wären es Pipelines, die mit Dateien interagieren, auf der Produktion dagegen z.B. ein beats input und ein elasticsearch output. Diese ändern sich ja nicht und können weitgehend statisch bleiben.
  • Das ganze ist momentan ein Konzept. Es kann natürlich sein, dass in der Umsetzung noch das eine oder andere Problem auftaucht, das bisher nicht bedacht wurde. Über Feedback würde ich mich auf jeden Fall freuen.
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...

Elastic{ON} 2018 Reisebericht und Rückblick

Wie alle guten Weine brauch auch manchmal ein Erlebnis eine Weile um zu einer guten Erfahrung zu reifen. So war es für mich mit der Elastic{ON} 2018 und passend zum Feiertag hole ich für euch nun unsere Review aus dem Keller, öffne die Flasche und wir schauen gemeinsam zurück auf das Event.
Thomas Widhalm und ich waren  für NETWAYS bei der Elasti{CON}2018 für euch vor Ort und haben uns die neuesten Entwicklungen und Best Practice Geschichten für euch angehört.

 

Keynote und Party

Die Keynote geführt von Gründer Shay Banon ging schon spannend los, nach dem wir von unzähligen Mitarbeitern in einem Intro begrüßt wurden, folgten für alle Produkte des Elastic Stacks kurze Feature Vorstellungen fürs nächste Release. Highlight dieser Keynote war der Vortrag von Ryan Kazanciyan der technische Consultant für die Serie Mr. Robot. Eine weitere große Ankündigung war mit Abstand die “Doubling down on open” Strategie, welche eine Veröffentlichung der Quellen des X-Pack  mit sich bringt. Dies bedeutet aber nicht das diese Quellen unter eine Open Source Lizenz gestellt werden. Hierzu gab es noch einen Nachruf von Philipp Krenn im Elastic Blog, denn dieses Thema sorgte für viel Diskussionsstoff und hinterließ zuerst einige Unklarheiten.
Bei der Anschließenden Keynote-Party ging es spielerisch mit Frischlufteinlage zu. Denn der Feueralarm ertönte als die Party im vollen Gange war und wir mussten das Gebäude kurzfristig verlassen. Für alle die uns kennen, soll gesagt sein, Thomas und ich hatten damit nichts zu tun.

 

1 Konferenztag

Am ersten Konferzenz-Tag haben Thomas und ich uns auf die unterschiedlichen Sessions verteilt. Thomas Schwerpunkt lag am ersten Tag hier auf den Talks zu den einzelnen Tools des Stacks und deren neuen Features, während ich mich auf Best Practice und BoF (Birth of Feather) Sessions konzentriert.
Die hier spannendste BoF Session war die zur GDPR welche zum 25.Mai 2018 in kraft tritt. Hier wurde in einer großen Runde darüber diskutiert wie man im Bezug auf Logmanagement und das Auswerten von Logingdaten zu reagieren hat. Klar ist das es einige Möglichkeiten gibt mit denen die sensiblen Daten wie eine IP mit dem Fingerprint Filter gehasht werden können. Aber auch die Auflagen zur Absicherung des Zugangs zu den Daten und deren Aufbewahrungszeiten gilt es zu berücksichtigen. Zu dieser Session findet sich im Elastic Blog eine sehr gute Zusammenfassung.
Thomas konnte für uns einen sehr guten Überblick über die Neuerungen im Stack am ersten Tag gewinnen. Da diese nicht gerade wenig sind, haben wir hier für euch kurz zu jedem Tool drei Punkte:

Elasticsearch

  • Cross-Cluster Search ersetzt vollständig die Tribe Node Funktion, die Tribe Node Funktion wurde entfernt. Mit einem Node als Cross-Cluster-Node ist das verbinden mehrere Cluster und der Darstellung der Cluster-Daten in einem zentralen Kibana möglich. Wichtig dabei ist, dass laut Plan drei Major Versions in einem Verbund unterstützt werden. Diese Funktion kann unter anderem sehr nützlich bei Migrationen und Upgrade-Szenarien sein.
  • “Cross-Cluster-Sync”, wodurch Daten zwischen Clustern synchronisiert werden können. Damit können Daten in verschiedenen Standorten synchron gehalten werden ohne einen Cluster über mehrere Rechenzentren zu spannen (was nicht supported wird)
  • Die Angabe von minimum master nodes um Split Brain zu verhinden wird automatisch werden. Wie und wie die eingestellt werden kann wurde noch nicht genau gezeigt.

Kibana

  • Mit X-Pack gibt’s mehr Authentifizierungsbackends (inkl. SAML)
  • Query Autocompletion kommt
  • KQL wird die neue Querysprache, als Ersatz für die Lucene Query Syntax. Die beiden ähneln sich aber stark.
  • Neue Visualisierung: Waffle Map und Canvas sollen kommen

Beats

  • Es kommt eine Prometheus Integration
  • Auditbeat bekommt neue Features. Wird damit eine Kombination aus Auslesen von auditd plus Aide.
  • Beats senden jetzt eine Art Heartbeat, in dem auch ein paar Eckdaten des Hosts, auf dem sie installiert sind enthalten sind. So hat man ein rudimentäres Monitoring in Kibana und sieht auch gleich, ob alle Beats aktiv sind.

Logstash

  • Mit X-Pack soll ein Konfigmanagement für mehrere Logstash Instanzen inkl. Konfiguration von Pipelines kommen.
  • Logstash erhält einen Secret Key Store, mit dem Passwörter für Verbindungen sicher gespeichert werden können
  • Visual Pipeline Builder, mit dem in Kibana abgebildet wird, wie die Pipeline konfiguriert sind.

Party

Wer uns von NETWAYS kennt weis, dass wir immer gerne Feiern. Am Abend des ersten Tages waren wir zur Party von unseren Freunden von Graylog geladen. Ebenfalls eine Software für das Logmanagement welche unter anderem auch Elastic Software nutzt, wie zum Beispiel Elasticsearch zum speichern der Dokumente.

 

2 Konferenztag

Am zweiten Konferenztag waren wir überwiegend gemeinsam Unterwegs und durften uns über die Überklimatisierung der Räume erfreuen, welche für Eiszeiten sorgte. An diesem Tag nahmen Thomas und ich an einer Videostory teil, welche bis jetzt wohl noch nicht veröffentlich ist.
 

Talks

Der Talk der an diesem Tag für Thomas und mich besonders erwähnenswert war, war der Talk “The seven deadly Sins of Elasticsearch Benchmarking“.  In diesem Talk gaben Elastic Mitarbeiter aus der Entwicklung Einsicht in Ihre Erfahrung aus dem täglichen Elastisearch Support und wie Sie Elasticsearch zu Performance verhelfen. Klare Empfehlung ist immer auf der gleichen Infrastruktur zu testen wie diese in Produktion verwendet wird. Ein wichtiges Werkzeug für das Testen von Elasticsearch-Clustern wurde vorgestellt und auf Github zu finden https://github.com/elastic/rally.

Unsere Entdeckung

Unser Blerim Sheqa alias bobapple ist auf der “Thank you to the Contributors wall” für seine Beats verewigt!YEAHY!

Schön wars…

Es war insgesamt eine sehr gute Konferenz welche uns sehr viele Erfahrungsmehrwerte verschaffte und uns die Möglichkeit bot eine Zertifizierung einzufahren. Thomas und ich bedanken uns auch bei Bernd bedanken, dass wir unsere Firma vertreten durften.
Mein persönliches Highlight war wohl der AMA-Stand. Diese Chance mit den Schöpfern und den Supportern der Software direkt zu sprechen nehme ich gerne war um meine offenen Verständnisfragen zum Elastic Stack zu schließen und nicht eine konkrete Aufgabenstellung zu lösen. Jetzt bleibt nur noch zu sagen das wir von neuem Wissen und mehr Wissen nur so strotzen und wenn Ihr offene Fragen habt dann besucht doch einfach eine unserer Elastic Stack Trainings z.b  Anfang Juni. Oder meldet euch, wenn Ihr konkret Unterstützung braucht und von unserem mit neuen Informationen angereicherten Wissen profitieren wollt, bei den Kollegen vom Sales Team. So zum Abschied noch eine kleine Weisheit : “You Know for Search!”

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das Netways Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner...

Grok Debugger

So kurz vor dem Wochenende möchte ich euch eine Webseite vorstellen die mir schon einige Tage Lebenszeit gespart hat: Der Grok Debugger!
Da ich immer wieder mit erstaunen feststellen muss das nur sehr wenige diese Seite kennen, sei sie hiermit auf unserem Blog verewigt 🙂
Solltet ihr nicht wissen welche tollen Sachen man mit Grok anstellen kann müsst ihr unbedingt mal in unserem Elastic Stack Training vorbei schauen 😉

 

Tobias Redel
Tobias Redel
Head of Professional Services

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.

Netways auf der Elastic{ON}17

Wie letztes Jahr hatten einige von uns die grossartige Gelegenheit, die Elastic{ON} in San Francisco besuchen. Dort stellt Elastic sämtliche kommenden Neuerungen am Elastic Stack vor. Daneben haben auch einige Kunden und Partner die Möglichkeit, ihre Use-cases oder Services zu präsentieren sowie ihr eigenes Setup und dessen Herausforderungen zu zeigen.
Die Neuigkeiten im Stack zeigen vor allem drei Schwerpunkte: Graphische Bedienung, mehr Visualisierungen in Kibana und noch mehr Stabilität. So sind eine graphische Aufbereitung und wohl auch eine teilweise graphische Konfiguration von Logstash Pipelines via Kibana geplant.
In Kibana selbst tut sich sehr viel. Da kommen neue Visualisierungen, insb. für Geolocation und ein “Visualisation Builder”, mit dem man deutlich ausgefallenere Graphen als bisher erstellen kann. In einer one-on-one Test Session konnte ich dieses Feature schon mal bestaunen, bin aber, ehrlich gesagt, etwas an der Komplexität und der ungewohnten Bedienung gescheitert. Entweder hat da noch der Jet-Lag zugeschlagen oder Elastic sollte noch etwas an der Bedienung feilen, die ja sonst doch sehr eingängig ist.
An der Stabilität wird insbesondere bei Elasticsearch gearbeitet. Dabei ist wohl eine Art “Transaction Log” geplant, das endlich schnelle Neustarts von Clusterknoten ohne vorherigen “Flushed Sync” ermöglicht und auch sonst sehr zur Stabilität beitragen soll.
Es wäre nicht Elastic, wenn nicht auch eine Menge Livedemos vorgeführt werden würden, was wir sehr schätzen, da sie doch auch einen wirklich sehr konkreten Nutzen für die Teilnehmer haben. Da heben sich die Elastic Mitarbeiter wirklich von vielen anderen Sprechern auf, insbesondere amerikanischen, Konferenzen positiv ab. Eine besonders beeindruckende Demo war der Auftakt der Konferenz mit einer Tänzerin, deren Bewegungen und Herzschlag live in Kibana visualisiert wurden. Das schien tatsächlich live zu sein, da Kibana durchaus auch mal den ambivalenten Smiley zeigte, der angibt, dass aktuell keine Datensätze gefunden wurden.
Es ist noch etwas zu früh, um alle Änderungen sichten und bewerten zu können, aber es sieht jedenfalls so aus, als hätte Elastic etliches in petto, das uns als Elastic Stack Usern das Leben deutlich einfacher und vor allem bunter machen würde. Wie immer schwebt das Damoklesschwert “kommt dieses Feature in X-Pack oder bleibt es frei” über jeder angekündigten Neuerung, aber das scheint teilweise noch gar nicht entschieden zu sein. Ziemlich sicher wird “Machine Learning” ein Kibana Feature, das aus “Prelert” entstanden ist, nur für Nutzer von X-Pack erhältlich sein. Ob “Canvas”, ein Feature, mit dem Reports und Präsentationen aus Kibana heraus erstellt werden können, frei verfügbar sein wird, wird noch entschieden. Auf jeden Fall würde das vielen Usern sehr weiterhelfen, nach dem, was wir an Nachfragen erhalten.
Viele der Features wurden für “kommende Releases” angekündigt. Einige davon kommen in 5.3, andere erst in 6.0.
Auf jeden Fall war die Konferenz wieder die Reise wert und ich kann es kaum erwarten, mit den neuen Features zu experimentieren und sie umzusetzen.
Ganz abgesehen von der Konferenz ist San Francisco natürlich auch für sich genommen eine wunderbare Stadt und wir alle sind sehr froh, dass die Reise so gefallen ist, dass wir uns auch noch etwas die Stadt ansehen konnten.
Wer noch keinen Kontakt zum Elastic Stack hatte, sollte sich einmal unsere Schulungen zum Thema ansehen. Die kurz und knackig und bieten alles, was man für einen Start in die Welt des Logmanagement braucht.
Dass der Blogpost etwas später als gewohnt erscheint liegt an der Zeitverschiebung und dem einen oder anderen wunderbaren IPA, das es hier zu probieren gab.
Die Talks gibt es sicherlich demnächst im Archiv nachzusehen.

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

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

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.
(mehr …)

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler 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 und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Schnellere Neustarts für Elasticsearch

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

OSDC 2016 – don't forget to register for your favorite workshop!

osdc_aktuelles_Konfbanner_registerBesides the great conference program, the Open Source Data Center Conference offers three hands-on, in-depth workshops, taking place on April 26, from 10 am to 5 pm. All workshops will be held within a small group. Notebooks, instruction material and WIFI access will be provided. See below for detailed information on content and required previous knowledge.
Since workshop participation is limited to 12 attendees max. – be smart, be fast and register for your favourite workshop now!

osdc_workshop_graphing_250x65

  • Introduction to Performance Graphing
  • Overview of Graphite components
  • Installation of Graphite
  • Usage of Graphite Web
  • Multinode Cluster with Graphite
  • Configuration of Dashboards with Grafana
  • Connection of Icinga 2 and Logstash

Target audience:
Experienced admins with background in monitoring tools.

osdc_workshop_docker_250x65

  • introduction to container virtualization
  • overview of Docker and its components
  • creation of containers with Docker files
  • versioning and management of containers
  • explanation of the most important Docker commands
  • use-cases for the deployment of Docker

Target audience:
This workshop is aimed at experienced administrators with in-depth knowledge in the areas of Linux and virtualization.

osdc_workshop_logstash_250x65

  • introduction to Logstash and Elasticsearch
  • usage of Input-and Output-Plugins
  • installation of different Log-Shippers like Syslog and Lumberjack
  • usage of filters for modification of logs and events
  • correct usage of Kibana for data analysis
  • connection of 3rd Pary Tools such as Icinga

Target audience:
This workshop is aimed at intermediate Sysadmin, Engineering Staff and Devops, with none or a little bit existing knowledge about Logstash & Elasticsearch.
Advanced users or experts with Logstash & Elasticsearch gaine little to none knowledge here

 

Pamela Drescher
Pamela Drescher
Head of Marketing

Pamela hat im Dezember 2015 das Marketing bei NETWAYS übernommen. Sie ist 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...

Der erste Entwurf für den Webinarkalender 2016 ist online!

NETWAYS Webinare Auch in diesem Jahr wollen wir wieder mit diversen Webinaren durchstarten und neben Icinga 2 natürlich unsere anderen Kernkompetenzen wie unter anderem Puppet, Foreman und unsere Hosting-Angebote nicht außen vor lassen.
Über das Jahr verteilt haben wir bereits diverse Themen fixiert – mehr werden aber natürlich noch folgen! Aktuell geplant sind die Folgenden Themen und Termine:

Titel Zeitraum Registrierung
Icinga Director: Konfiguration leicht gemacht 03. März 2016 – 10:30 Uhr Anmelden
Docker Hosting 10. März 2016 – 10:30 Uhr Anmelden
Foreman: Provisionierungswege 31. März 2016 – 10:30 Uhr Anmelden
ELK: Grundlagen der zentralen Logdatenverwaltung 15. April 2016 – 10:30 Uhr Anmelden
Foreman: Klassen und Parametrisierung in Puppet 20. Mai 2016 – 10:30 Uhr Anmelden
Foreman: Berechtigungen 28. Juli 2016 – 10:30 Uhr Anmelden
Foreman: Docker Integration 05. Oktober 2016 – 10:30 Uhr Anmelden

Wer sich einen Überblick über die bisherigen Webinare verschaffen möchte, kann dies natürlich gerne in unserem Webinar-Archiv tun.

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Die OSMC wird 10 – OSMC 2015 – Tag 2

OSMC 2015 Logo
Diese Jahr jährt sich die OSMC zum 10. Mal. Damit haben sich einige Standards etabliert wie die Intensiv-Workshops am Vortag, die wie immer gut besucht waren. Das Abendessen für die am Vortag Anreisenden bei dem Freundschaften gepflegt werden und schon eifrig gefachsimpelt wird.
Und natürlich die übliche herzliche Begrüßung durch Bernd zum offiziellen Auftakt! Zum 10jährigen gab es Feuerwerk (Ja, es wurden nicht die Kosten gescheut für ein Tischfeuerwerk), Nostalgie-Bilder und für die drei Stammgäste, die bei jeder der 10 Konferenzen dabei waren, ein entsprechendes Danke schön aus T-Shirt und die Einladung zu Bernds Lieblings-Schaschlik auf dem Nürnberger Christkindlmarkt.
Aber auch einige Neuerungen und Überraschungen wird es geben, dazu dann aber wohl mehr im morgigen Blogpost nach der Abendveranstaltung und vom Hackaton der dieses Jahr zum ersten Mal den vierten Tag bildet.
IMG_6513
Als ersten Vortrag habe ich dann “Grafana and the Future of Metrics Visualization” von Torkel Ödegaard gelauscht. Dieser gab einen guten Überblick und eine Live-Demo zu Grafana, welches auch schon bei uns im Blog vorgestellt wurde und wohl das beste Webinterface/Visualisierungstool zu den verschiedensten Timeseries-Databases und somit metrischen Daten darstellt. Dies liegt nicht nur an der einfachen Bedienbarkeit, sondern auch an Funktionen wie Snapshots als Reportmöglichkeit und zukünftigen Plänen zur Integration weitere Lösungen zum Beispiel für Alarmierung.
IMG_5354
Einen Einstieg in den ELK-Stack (Elasticsearch – Logstash – Kibana) gab unser Platz-Elch Thomas Widhalm mit “NYALT – Not yet another Logstash Talk” und hatte dabei volles Haus trotzt parallelem Vortrag von Michael Medin. Besonders interessant waren die Gründe für den Einsatz gestaffelt in Warum?, Warum nicht nicht? und Warum wenn es jemand partout nicht will?. Außerdem kann Thomas aus vielen verschiedenen Kundenprojekten schöne Praxisbeispiele und -tipps geben. Nachdem ich diese nicht alle hier unterbringen kann, muss ich um Geduld bitten bis in ein paar Tagen der Konferenzinhalt online geht.
IMG_6585
Nachdem aller guten Dinge drei sind ging es mit Florian Forster und “collectd’s threshold Plugin and Icinga” in die dritte Vormittagsrunde. Collectd findet sich schon lange auf der Liste an Tools mit denen ich gerne mehr machen würde, weshalb ich mich schon auf den Vortrag gefreut habe. Nach einem kurzen Einstieg kam Florian dann zu dem Threshold-Plugin, das die Benachrichtigungsschnittstelle darstellt, welche dann von den Write- oder Notification-Plugins zur Alarmierung genutzt werden kann. Aus dem Feedback letztes Jahr entstand auch das Notification-Plugin notify_nagios um passive Events in Nagios/Icinga einzukippen.
IMG_6640
Reichlich gestärkt mit gutem Mittagessen ging es weiter mit Werner Fischer zu “Linux Performance Profiling and Monitoring”. Als Teil des Wissenstransfer-Teams von Thomas Krenn ist er mit verantwortlich für den Inhalt in ihrem sehr guten Wiki. Genauso fundiert stellte er in seinem Vortrag die verschiedenen Linux-Boardmittel vor um die Auslastung eines Systems zu analysieren, Metriken zu sammeln und Probleme nachzuverfolgen. Besonders Flamegraph könnte nützlich sein um zu zeigen womit ein Prozess seine Rechenzeit verbringt.
IMG_6666
Als fünfter Vortrag auf der zehnjährigen Konferenz wird auch OMD 5 und Matthias Gallinger liefert die “Best Practices”. Man mag von OMD und seinen Ansätzen halten was man will, allein die Zahl der Nutzer spricht dafür, dass hier gute Arbeit geleistet wird um die verschiedenen Werkzeuge (Nagios/Icinga/Shinken mit Plugins, Addons und weiteren nützlichen Komponenten) zu bündeln.
Wie gewohnt bildete das Icinga-Team den Abschluss des Tages mit “Current State of Icinga” und somit gehörte Bernd mal wieder die Bühne. Ein kurzer Überblick zum Projektstatus bildete den Einstieg mit Neuigkeiten wie dem Partner-Programm und Shop (Hinweis hier: Die Hoodies und T-Shirt sind verkäuflich, nicht Eric). An technischen Neuerungen zeigte Bernd dann den neuen Graphite-Tree um den Zugriff einfacher zu machen, den Debugger, das Studio um graphisch direkt mit der API zu sprechen und natürlich die API selbst! Auch zum Icinga Web 2 gabs entsprechende Erläuterungen und eine Demo. Wer sich Business Process Addon, Nagvis und Pnp4Nagios in Icinga Web 2 anschauen möchte, nimmt sich am besten selbst die Vagrant-Boxen vor. Morgen gibt es dann auch wunderbare Neuigkeiten für alle Freunde graphischer Konfiguration, wenn Tom seinen Vortrag hält.
Den Kopf voll mit all den Neuigkeiten geht es nun wieder wie letztes Jahr mit der U-Bahn zur Abendveranstaltung ins Terminal 90. Auch diesmal haben wir keinen U-Bahn-Pusher, hoffen aber nicht wieder die U-Bahn lahmzulegen. Wenn auch sonst nichts schiefläuft, liest man sich morgen wieder mit weiteren Informationen aus der Welt des Open Source Monitoring!

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.