Namen sind Schall und Rauch? Lieber nicht.

Das Problem

Bei vielen Projekten zu Logmanagement stellt sich recht schnell die Frage nach der Benamsung der Felder, in die Events zerlegt werden sollen. Da man sie weitestgehend frei wählen kann, startet so schnell ein gewisser Wildwuchs und das unabhängig davon, ob der Elastic Stack oder Graylog verwendet wird, um die Nachrichten zu “zergrokken”, wie es mal ein Kunde so schön formuliert hat.

Das Kuddelmuddel rund um die Feldnamen hat einige Nachteile, die früher oder später zuschlagen:

  • Ein Feld innerhalb eines Index darf nur einen Typ haben. Wenn also zufällig zwei Regeln ein Feld namens errorlevel anlegen und eine schreibt debug rein, die andere 4 wird das früher oder später dazu führen, dass Events von Elasticsearch abgelehnt werden
  • Gemeinsame Dashboards gestalten sich schwierig, wenn die IP des sich verbindenden Hosts mal in client , mal in client_ip und mal in anfragenderhost drin steht
  • Andere Tools und mitgelieferte Regeln / Dashboards haben keine Möglichkeit, vorherzusagen wie Felder heissen werden, deren Informationen sie brauchen

Schon immer galt die Empfehlung, sich ein Namensschema zu überlegen und sich strikt dran zu halten. Das klappt leider meist schon nicht, wenn nur eine Person dran arbeitet und wird nahezu unmöglich, wenn mehrere Teams eine gemeinsame Konfiguration pflegen. Das muss gar nicht einer gewissen Nachlässigkeit geschuldet sein, sondern kann alleine schon daraus resultieren, dass die gleichen Dinge manchmal in verschiedenen Teams einfach unterschiedlich genannt werden. Man muss nur an die Diskussion rund um “Satellite” oder “Slave” bei Icinga 2 oder die verschiedenen Logstash Instanzen (“Shipper”, “Indexer”, “Forwarder”, “häh?”) denken, um ein naheliegendes Beispiel zu haben.

ECS to the rescue

Elastic hat nun eine schöne, wenn auch noch nicht umfassende Lösung dafür geschaffen: Das “Elastic Common Schema”, kurz ECS.

Beschrieben in einem eigenen Abschnitt der Dokumentation. Darin sind Regeln festgelegt, wie Felder heissen müssen, die bestimmte Daten beinhalten. So gibt es z.B. nicht mehr logsource oder beat.hostname sondern host.hostname (der Host, auf dem das Event passiert ist, das den Logeintrag ausgelöst hat) und agent.name (Name des Agenten, der die Nachricht verschickt hat – kann der Hostname sein, aber auch ein Custom Name, falls z.b. mehrere Filebeat auf einem Host laufen)

Definiert im ECS sind eine ganze Menge von Überkategorien unter denen dann verschiedene Unterfelder definiert sind, die dann wiederum einen “Level” haben. Der Level gibt an, ob die Felder nach Möglichkeit befüllt werden sollen (“core”) oder eher optional sind (“extended”). Die core-Felder werden auch von diversen Tools des Elastic Stack genutzt, um automatische Auswertungen zu erlauben, was gleich einen riesigen Vorteil des ECS offenbart: Man kann damit viel einfacher fertige Lösungen verschicken, weil man nicht mehr rätseln muss, wie denn die Felder heissen könnten, in denen die wertvollen Informationen stecken.

So wird den meisten langjährigen Usern von Kibana aufgefallen sein, dass es inzwischen eine grosse Menge weiterer Tools in Kibana gibt als die klassischen “Discover”, “Visualize” und “Dashboard”. Die neuen Tools wie SIEM oder Infrastructure verlassen sich darauf, dass die benötigten Informationen in den richtigen Feldern abgelegt sind. Wenn man also ECS umsetzt, dann funktioniert z.B. der SIEM Teil von Kibana mehr oder weniger ohne weiteres zutun.

Im ECS ist auch definiert, welchen Typ welches Feld haben sollte. Sprechen Beats direkt mit Elasticsearch, kümmern sie sich darum, dass das richtig gesetzt wird. Baut man seine eigene Zerlegung in Logstash oder Graylog, dann sollte man darauf achten, dass die Felder auch entsprechend typisiert sind. In den meisten Fällen ergibt sich das aus der Art von Information, die im Feld gespeichert wird automatisch – man sollte dennoch immer wieder mal kontrollieren, ob nicht das eine oder andere durchgeschlüpft ist. Es sollte aber auch nichts dagegen sprechen, die Multifields von Elastic Search zu nutzen. Wird also ein Feld vom Typ keyword gefordert, kann man es auch als string in Elasticsearch schreiben, da der immer sowohl als text und als keyword abgelegt wird.

Der Umstieg

Wer schon ein funktionierendes Logmanagement hat, kann übrigens ziemlich sanft auf ECS umsteigen. ECS erlaubt nämlich ausdrücklich auch, eigene Felder zu definieren. Anders ausgedrückt sollten die relevanten Informationen in den angegebenen Feldern vorhanden sein. Ausser der dabei entstehenden Ressourcenverschwendung spricht aber nichts dagegen, die Daten auch in den zuvor genutzten Feldern vorzuhalten, solange man migriert. Man kann also die Information durchaus duplizieren, falls das nötig ist.

Wer noch ältere Clients im Einsatz hat, muss ohnedies vorsichtig sein, da Elastic die Standardfelder, die automatisch hinzugefügt werden, im Laufe der Zeit in einer nicht abwärtskompatiblen Art verändert hat. So kommen insbesondere Logs, die über Syslog verschickt wurden mit einem host Feld, in dem schlicht der Hostname drin steht. Laut ECS (und damit auch in Events von Beats) ist host aber ein “Nested Field”, das selbst wieder Unterfelder beinhaltet. Schickt man also in den selben Index Events, die man über Syslog-Protokoll erhalten hat und solche, die via Beats eingeliefert wurden, dann hat man leicht einen type mismatch. Dabei ist das nur eines von mehreren möglichen Beispielen. Die Logs von Elasticsearch und Logstash bzw. Graylog zeigen, wenn Events abgelehnt werden und üblicherweise auch wieso.

Eine gewisse Herausforderung ist dabei wieder, sich in die verschiedenen Positionen hineinzuversetzen. Aus Sicht des Logadmins ist der Client vielleicht der Agent, der die Nachricht verschickt, aber aus der Sicht dessen, der die Nachricht zur Überwachung seiner Applikation benötigt, ist der Client der, der mit seiner Applikation gesprochen hat. Dafür gibt es eben eigene Felder wie agent oder event, die Metadaten beinhalten können, die sich nur auf das Logmanagement beziehen, nicht auf den Inhalt der Nachricht. Das Problem ist aber nicht ECS spezifisch, sondern allgemein etwas, das Logadmins plagt.

Abschliessendes

Wer neue Regeln zum Zerlegen von Events anlegt, sollte aber von vornherein darauf achten, dass das ECS eingehalten wird. Dazu sollte man noch ein Feld mitgeben, das die ECS Version anzeigt, um in Kibana für Klarheit zu sorgen und ggf. noch ein paar Regeln kurz vor den Outputs einzuführen, die alte Nachrichten nachbessern. Das haben wir z.B. auch in der Logstash Pipeline für Icinga Logs getan.

Wer sich dazu noch etwas ausführlicher erzählen lassen möchte, kann ja mal in einer unserer Elastic Stack Schulungen vorbei schauen.

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

Logstash automatisiert ausrollen? Freilich!

Der Lennart sagt mir ja immer, ich soll nicht über ungelegte Eier sprechen, aber momentan fasziniert mit das Thema einfach zu viel, als dass ich nicht drüber was schreiben könnte. Dass ich gern mit dem Elastic Stack arbeite, sollten auch weniger aufmerksamere Leser schon mitbekommen haben, aber mit Ansible hab’ ich mich bisher recht zurückgehalten. Da ich aber eigentlich beides ganz gern mag, dachte ich mir, ich verbinde es mal.

 

Mit Ansible ist es wie bei den meisten Configmanagementsystemen: Man fängt mal an, was zu bauen, findet’s gut, lernt was dazu, findet’s nicht mehr gut, baut’s neu, findet’s richtig gut, lernt dazu, findet’s eher mies, baut’s neu, ein Loch ist Eimer, lieber Reinhard, lieber Reinhard.

Deshalb dachte ich, ich bemüh’ mich jetzt mal, eine Rolle für Logstash zu bauen, die man auch wirklich guten Gewissens so rausgeben kann. Falls was nicht so schön ist, gibt’s dann wenigstens die ganzen lieben Leute da draußen, die Pull Requests machen *wink*. Hier also der aktuelle Stand unserer Ansible Rolle für Logstash.

Ich geb’ ja zu, es ist noch eine recht frühe Version, aber sie ist immerhin so gebaut, dass sie umfassend konfigurierbar ist und auch der Linter von ansible-galaxy beschwert sich dabei nicht mehr. Anders ausgedrückt: Sie kann noch nicht extrem viel, aber das, was sie kann, kann sie ziemlich gut, meiner Meinung nach.

Ein schönes Feature, das mir besonders zusagt ist, dass sie einen dazu bringt, die Konfiguration der einzelnen Pipelines in einem Git Repository zu pflegen und zwar ein Repository pro Pipeline. Damit kann man die Rolle schön in Kombination mit unserer Logstash Pipeline für Icinga Logs nutzen. Ein paar Beispielpipelines, die aktuell nur Logs von A nach B schaufeln, habe ich in meinen persönlichen GitHub Account gelegt, von wo sie auch als Beispiele bei der Installation verwendet werden können. Ob das so bleibt, entscheidet sich noch, auf jeden Fall soll die Pipeline mit minimaler oder keiner Konfiguration zumindest mal Basisfunktionalität in Logstash herstellen. Ganz so, wie Elastic das geplant hat – ein einfacher Einstieg für Neulinge. Aber auch ausgefeiltere Setups sind damit möglich.

Besonders gut funktioniert die Rolle übrigens gemeinsam mit einer Rolle für Redis, aber das ist alles in der Readme beschrieben.

Weitere Rollen zum Rest vom Stack werden wohl noch kommen und die Logstash Rolle kann auch noch einiges an zusätzlichen Konfigoptionen brauchen. Lasst Euch also nicht aufhalten, Issues aufzumachen oder Pullrequests zu schicken.

 

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 Stack viel neues, aber sicher!

Mit der Veröffentlichung von Elastic Stack 7 kamen bereits eine Menge Neuerungen in den Stack aber auch in den beiden darauf folgenden Releases Elastic Stack 7.1 und 7.2 wurde es nicht langweilig. Vieles davon wurde aber nicht sonderlich ins Rampenlicht gerückt oder gar groß diskutiert. Ich möchte heute mal zwei Neuerungen erwähnen und damit verbundene Auffälligkeiten.

Elastic Stack 7.1 und Elastic Stack 6.8 Elasticserach Security X-PACK Basic License

Als ich zum ersten mal am 21.05.2019 durch Zufall auf dem Elastic Blog gelesen habe, dass seit dem 20.05.2019 mit dem Release von Elastic Stack 7.1 und Elastic Stack 6.8.0 eine Basis Elasticsearch X-Pack Security verfügbar ist, dachte ich nur so: “OK” und wo ist die Diskussion wo sind die Aufhänger? Fehlanzeige nichts von alle dem.

X-Pack Security Basic License

Folgend will ich euch kurz schildern was in der Basic License möglich ist:

  • Elasticsearch HTTP und Transport TLS Encryption der Kommunikation
  • Index Security und Kibana Security mit Benutzerauthentifizierung und Rechte-Management mittels Rollen. Jedoch kommt die Basic Variante ohne LDAP/AD und Rechte-Management auf Dokumenten-Ebene und Feld-Ebene
  • Alle Komponenten können nun mit TLS und Benutzerauthentifizierung mit Elasticsearch kommunizieren

Besonders interessant dabei ist der Punkt “Index Security und Kibana Security”. Einfach ausgedrückt kann man damit Namensschemata für Indices angeben, auf die User Zugriff haben oder nicht. Auch wenn feldbasierte Rechte schön wären, reicht das meist aus, um effektiv User einzuschränken. z.B. können dann Webmaster auf alle logstash-webserver-* , DBAs auf alle logstash-db-* und Security-Leute auf alle logstash-* Indices und die darin gespeicherten Events zugreifen.

Nun noch ein kleiner Hinweis:

Ihr könnt einem User nur Rechte auf bereits vorhandene Index Pattern/Schema im Kibana geben, welche bekanntlich nur erstellt werden können wenn ein Index bereits besteht. Somit müsst ihr zum Beispiel einem User den Ihr in Logstash für das Schreiben via “logstash-output-elasticsearch” verwenden wollt, für die initiale Erstellung Superuser-Rechte vergeben. Dies ist zugegebener maßen etwas umständlich.

Bei Gelegenheit aber mehr zu diesem Thema in einem neuen Blog-Post.

Beats Logging

Die oben genannte Änderung fand in Beiträgen von Elastic auf Ihrem Blog einen Platz oder in den Breaking Changes. Jedoch gab es auch Änderungen welche weder in den Breaking Changes zu Elastic Stack 7.0 noch in einem Blogeintrag erwähnt wurden. Jedoch ist für mich die Neuerung das Logging für alle Beats über stderr in den journald zu schreiben, eine Erwähnung in den Breaking Changes wert und nicht nur in den Release Notes. So kommt es, dass jede Beats Variante unweigerlich in das System-Log schreibt und eine Option wie `logging_to_syslog: true` keine Wirkung zeigt. Denn die Einstellung wird über eine Umgebungsvariable im Systemd-Unit File als Default gesetzt, welche Einstellungen in einer Beats-Konfiguration hinfällig macht.

Nicht jeder aber möchte die Logs eines Beats in seinem System-Logs haben. Um dies zu verhindern ist eine Änderung des Unit-Files notwendig. Diese nimmt man wie folgt:

systemctl edit elasticsearch
[Service]
Environment="BEAT_LOG_OPTS="
systemctl daemon-reload
systemctl start

Die neuen Releases des Elastic Stack seit 7.x haben noch wesentlich mehr neues zu Entdecken wie z.B eine SIEM Lösung in Kibana oder das ILM im Stack welches nun auch in den Beats und Logstash vollständig integriert ist. Jedoch alles in einem Blog-Post zu verarbeiten wäre zu viel. Darum werden wir uns bemühen für euch in weiteren Blog-Posts das ein oder andere vorzustellen.

Kurz erklärt soll aber “ILM” werden, das Regeln in Elasticsearch hinterlegt, wann ein Index rotiert oder gelöscht werden soll. Das ersetzt Cronjobs mit REST-Calls oder den Curator und bietet eine einfache Möglichkeit Hot/Warm-Architekturen umzusetzen.

Auch spannend wird es für uns unsere Trainings für euch anzupassen so das diese dem neuen Elastic Stack 7.x gerecht werden. Da ich mich schon seit mehren Jahren mit dem Elastic Stack auseinander setze, finde ich gerade die Entwicklung im Kibana und dem Management des Stacks als sehr interessant. Diese bringt doch für viele eine große Erleichterung in der Wartung eines Stacks. Ich bin gespannt wie sich das entwickelt.

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

Von Ausbildung und Grok Debuggern

Vor mittlerweile einigen Wochen hatte ich eine “Elastic Stack”- Schulung bei Daniel. Bei der in wenigen Tagen alle Bestandteile des Stacks erst oberflächlich und dann in Tiefe bearbeitet worden sind.

Elastic Stack ist ein Set von Tools, die zwar von der gleichen Firma entwickelt werden und entsprechend gut aufeinander abgestimmt sind, jedoch auch einzeln ihre Anwendungsmöglichkeit finden können. Dieser besteht aus:

  • Kibana – ein Web-UI zur Analyse der Logs in dem u. a. Dashboards mit benutzerdefinierten Grafiken angelegt werden können.
  • Elasticsearch – eine Suchmaschine beziehungsweise ein Suchindex.
  • Logstash – ein Tool zum Verwalten von Events und Logs.
  • Beats – werden von Elastic als anwendungsfallspezifische Daten-Shipper beworben.

Übung macht den Meister

Damit die Themen aus der Schulungen gefestigt werden wird uns in der Regel direkt ein Projekt zu teil, welches sich mit den Schulungsthemen beschäftigt. Nach der “Fundamentals for Puppet”-Schulung vom Lennart wurde mir ein Icinga-Puppet-Projekt zugewiesen und zwar eine kleine Test-Umgebung für mich selbst mit Puppet aufzubauen. Genau das Gleiche war auch nach der “Elastic Stack”-Schulung der Fall, ein kleineres Projekt mit Icinga-Logs bei dem ich einfach ein bisschen mit Grok Filtern rumspielen sollte.

Spätestens da ist mir wieder bewusst geworden, dass die meisten unserer Consultants für sich irgendein Spezialgebiet gesetzt haben und das Dirk uns bewusst viel mit den Themen arbeiten lässt um festzustellen, was uns liegt und was uns Spaß macht. Bis jetzt habe ich weder etwas gegen Puppet noch Elastic und bis im Juli die “Advanced Puppet”-Schulung ansteht, hab ich auch noch ein weiteres Puppet-Projekt vor mir, aber dazu vielleicht beim nächsten Mal mehr.

I grok in fullness

Wenn wir schon mal beim Elastic Stack sind dann können wir gleich zu Grok Filtern in logstash kommen. I grok in fullness bedeutet übersetzt so viel wie Ich verstehe komplett. Zwar kann man das nicht immer guten Gewissens behaupten, aber immerhin versteht man jedes Mal ein bisschen mehr. Dieses Zitat ist auf der Seite des altbekannten Grok Debuggers zu finden.

An dieser Stelle ist es vielleicht ganz interessant den nun schon zwei Jahre alten Blog-Post von Tobi aufzugreifen. Seit schon geraumer Zeit ist auch in Kibana direkt ein Grok Debugger zu finden. Den Debugger kann man unter dem Reiter Dev Tools finden. Hier ein kleines Beispiel:

Der Grok Debugger in Kibana sieht nicht nur besser aus und ist einfacher zu erreichen. Er hat mir auch in der ein oder anderen Situation geholfen, da er auch das ein oder andere Pattern kennt, dass der alteingesessen Grok Debugger nicht kennt. Viel Spaß beim Grok Filter bauen!

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.

Viel hilft viel? Nicht immer.

Wenn Systeme gesized werden, fällt üblicherweise bald die Frage: “Was brauchen wir denn besonders viel? CPU? Ram? I/O?” Elasticsearch ist ein schönes Beispiel, in dem man einfach antworten kann: “Alles!” Es braucht CPU, Ram, I/O, Platz, Netzwerkdurchsatz und alles möglichst viel. Tatsächlich braucht es eigentlich möglichst viele Maschinen, die dann jeweils von allem etwas mitbringen – daher auch die Empfehlung, immer auf Hardware zu setzen, weil sonst irgendwas zum Flaschenhals wird (z.B. das SAN).

Es gibt aber eine Ausnahme und schuld ist, wie so oft ( 😉 ): Java. Gibt man Java zu viel Ram, stellt es intern die Verwaltung seiner Pointer um und verliert dadurch so viel Performance, dass man noch ziemlich viel zusätzlichen Ram drauf schmeissen muss, um das wieder auszugleichen. Die genauen Zahlen variieren, liegen aber ungefähr so: Wenn man eine Schwelle überschreitet, die zwischen 30 und 32GB liegt, fällt die Performance so ab, dass man erst bei ca. 46GB wieder auf dem Stand von vor Überschreiten der Schwelle ist. Die ca. 16GB sind also verloren.

Da die Schwelle aber variabel ist, trägt man entweder zu niedrig an oder überschreitet sie unbemerkt. Elasticsearch bietet dabei aber eine einfache Möglichkeit, herauszufinden, ob die Schwelle schon überschritten wurde:

$ curl -s -XGET http://elastic02-hot.widhalm.or.at:9200/_nodes | jq '.nodes[].jvm.using_compressed_ordinary_object_pointers'
"true"
"true"
"true"
"true"
"true"

Dabei fragt man über die API eines Knoten den Zustand aller Knoten ab. Wenn so viele true als Antwort kommen, wie Knoten im Cluster sind, dann ist alles ok. Jedes false zeigt einen Knoten, der zu viel Ram zur Verfügung hat. Gesetzt in /etc/elasticsearch/jvm.options. Als Lösung: Einfach weniger Ram eintragen und die Knoten neu starten (immer nur dann, wenn der Cluster gerade im Status “green” ist)

Wer jq noch nicht installiert hat, sollte das nachholen, da damit wunderbar JSON geparsed werden kann. Ein paar Beispiele gibt’s hier.

Den Check würde ich übrigens regelmässig wiederholen. Ich habe noch keine genauen Daten, wie sich z.B. Updates darauf auswirken und ob sie nicht auch wirklich variabel sein kann.

(Photo by Liam Briese on Unsplash)

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

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