NETWAYS Blog

Multiline in Grok – Kein schönes Format

von Daniel Neuberger | Jan 7, 2021 | Graylog

In einem modernen Log-Management ist das Aufbereiten für die spätere Analyse unverzichtbar. Je schöner das Format ist, in welchem wir eine Information geliefert bekommen, desto einfacher ist deren Verarbeitung.
Das Aufbereiten der Daten ist oft eine große Herausforderung. Doch über die Jahre hinweg habe ich mir beholfen, indem ich mir ein standardisiertes Vorgehen angewöhnt habe. Und das nicht nur weil ich ein großer Fan der RFC5424 bin.

Egal ob ich mit Graylog oder Logstash arbeite, irgendwann kommt der Punkt an dem ein Grok-Filter benötigt wird, weil kein einfaches Key-Value-Format oder noch besser kein JSON-Format vorliegt.

Ein schönes Beispiel sind Stack-Traces einer JAVA-Anwendung in JBOSS:

[code lang=“plain“]
2020-07-02 23:54:32,979 [severity] [class] [thread]\n
traceline1\n
traceline2\n
traceline3]
[/code]

Eine solches Ereignis fängt immer mit den Meta-Informationen an und ich würde zuerst aus diesen Felder erzeugen und mich im Nachgang der eigentlichen Information dem Trace als Nachricht zuwenden. Dies erfordert aber das ich mittels Grok das Feld „message“ neu belegen kann. Dies ist die Voraussetzung für das weitere verarbeiten der Kern-Nachricht. Hier würde sich zum Beispiel ein Key-Value Filter anbieten.

Hierfür würden wir in der Implementierung von Grok in Logstash folgendes Muster benötigen:

[code lang=“plain“]
(?m)
[/code]

Doch nicht so in Graylog. Die Implementierung von Grok in Graylog erfordert einen anderes Muster zumindest für die Filter in den „Pipeline-Processors“

[code lang=“plain“]
(?s)
[/code]

Somit sind wir mit diesem Muster in der Lage die mehrzeilige Information als eine Nachricht in einem Grok-Filter in einer „Pipeline-Regel“ abzufangen.
Hier ein Beispiel in der gänze für ein mögliches JBoss Server-Log

[code lang=“plain“]
%{TIMESTAMP_ISO8601:timestamp}%{SPACE}%{WORD:severity}%{SPACE}\[%{HOSTNAME:jboss_class}\]%{SPACE}\[%{HOSTNAME:thread}\]\n(?<message>(?s).*)
[/code]

Diese Erkenntnis für die Multiline in Grok stammt aus dem folgenden Issue #2465.
Ich hoffe es hilft dem nächsten Suchenden, dem es ergeht wie mir um mit Zeilenumbrüchen in Grok umzugehen.

Wenn Ihr gerne mehr über Graylog oder die spannenden Welt des Informations- und Event-Management wissen wollt zögert nicht ein Training bei NETWAYS Events zu besuchen oder euch direkt Hilfe bei unseren Kollegen von Netways Professional Services zu holen.

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 Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

Lies mehr von Daniel und triff unser Team

Graylog 3.2 – Jetzt verfügbar

von Christian Stein | Feb 7, 2020 | NETWAYS, Linux, Technology, Graylog

Mit Graylog 3.2 haben die Kollegen von Graylog einen neuen Release bereitgestellt. Die größte Neuheit ist hierbei die Erweiterte Suche, die es erlaubt, bereits durchgeführte Suchen leichter zu wiederholen und Such-Worflows zu definieren. Sowohl für Nutzer der OpenSource als auch der Enterprise Variante gibt es einige Neuheiten. In unseren vergangenen Graylog Webinaren auf unserem YouTube Kanal sind wir bereits grob auf einige Neuerungen eingegangen. Der Downlod erfolgt entweder direkt über die Graylog-Webseite oder die bereitgestellten Pakete. Eine Migrationsanleitung von 3.1 auf 3.2 ist selbstverständlich verfügbar, als Graylog Partner unterstützen wir aber natürlich gerne bei einem Update.

Optimierte Suche

Mit der neuen Such-Funktion von Graylog können mehrere Suchen sehr einfach in eine einzelne Aktion kombiniert werden und liefern das Ergebnis in einer Ansicht aus. Ab hier können diese gelisteten Informationen nun genauer analysiert und gefiltert werden, um potentielle Angriffe, Fehler, Report-Informationen oder andere Daten zu erhalten. Darüber hinaus können Suchabfragen direkt innerhalb der Widgets von Dashboards angepasst und geändert werden, um schnell ein Feintuning vorzunehmen oder gänzlich neue Widgets mit erweiterten Suchkriteieren für eine noch bessere Übersicht anzulegen .

Widget-Daten bearbeiten

Optimierte Such-Konfiguration (ENTERPRISE)

Neben den bereits erwähnten Änderungen wurden auch Kontext-Menüeinträge, Ansichten und Menüpunkte optimiert, erweitert oder gänzlich neu implementiert. Hierdurch gibt es nun die Möglichkeit, schnell einzelne Einträge auszublenden, zur Ansicht hinzuzufügen oder in die Anfrage zu integrieren.

Dadurch können gesammelte Daten noch einfacher und schneller zielgerichtet aufbereitet und dargestellt werden. Ein kompliziertes Arbeiten über mehrere Browser-Tabs gehören somit der Vergangenheit an. Mit den neuen Views ist ebenfalls eine leichtere Bedienung möglich.

Such-Views

Mit den neuen Views können Suchkritieren nun einfach in einen View hinzugefügt und für eine spätere, weitere Verwendung gespeichert werden. Das Speichern der Suchen ist jedoch nur mit Graylog ENTERPRISE möglich. Mit diesem neuen Feature werden Such-Dashboards überflüssig, da die Darstellung der Inhalte direkt in der Suchmaske erfolgt. Neben klassischen Countern sind hier alle Ansichten wie Diagramme, Averages und Daten Tabellen vorhanden. Wird die Such-Query geändert, aktualisieren sich automatisch alle hinterlegten View-Widgets und liefern exakte Informationen basierend auf der Widget-Konfiguration zurück. Gerade für Fehleranalysen oder bei potentiellen Angriffen sind hier schnelle Auswertungen möglich, um potenzielle Ursachen herauszufinden und den Impact so gering wie möglich zu halten.

Neue Alerts (ENTERPRISE)

Mit den neuen Alerts können nun endlich dynamische Inhaltslisten genutzt und gegen mehrere Konditionen auf einmal geprüft werden. Die dynamischen Listen sind dabei eine Kombination aus Alarmierungs-Parametern und Datentabellen. Dies erlaubt es beispielsweise, Alarmierungskriterieren dynamisch anzupassen, je nachdem welche Informationen innerhalb einer Datentabelle vorhanden sind. Hierdurch steigt nicht nur die Flexibilität für die Alarmierung, sondern vereinfacht in vielen Fällen auch die Konfiguration.

Ein Beispiel ist die Alarmierung an Personen innerhalb einer AD-Gruppe. Wird die Liste der Benutzer im AD direkt geändert, werden diese umgehend berücksichtigt. Wenn neue Kollegen in das Team aufgenommen werden, wird dadurch eine Anpassung der Nachrichtenempfänger in Graylog überflüssig . Sobald der Benutzer im AD hinzugefügt wird, wird dieser automatisch bei künftigen Alarmen berücksichtigt.

Um Alarmierungen noch gezielter gestalten zu können, bietet Graylog 3.2 nun die Möglichkeiten mehrere Konditionen für einen Alarm zu definieren. Ein Beispiel wären hierfür fehlerhafte Logins innerhalb eines bestimmten Zeitraums. Möchte man prüfen, ob sich ein Benutzer 20 mal innerhalb eines Zeitraums von beispielsweise 5 Minuten falsch anmeldet, erfolgt dies über zwei Konditionen. Die erste würde prüfen, wie viele fehlerhafte Logins insgesamt stattfinden. Die zweite Konditionen würde dies auf den Zeitraum von 5 Minuten einschränken. Sobald beide Konditionen eintreffen, also 20 fehlerhafte Loginversuche in einem Zeitraum von 5 Minuten erfolgen, wird alarmiert.

Vollbild Dashboards

Mit Graylog 3.2 ist ein lang erwartetes Feature endlich verfügbar. Ein Vollbild Dashboard.

Nutzt man Graylog auf einem Dashboard Fernseher ist dies nun nativ in einem Vollbild-Modus möglich, ohne hierfür spezielle Browser-Funktionen oder Erweiterungen installieren zu müssen.

Neugierig auf die neue Graylog Version geworden? Dann am besten gleich direkt ausprobieren! Alternativ stellen wir die neuen Features bei Interesse gerne vor oder unterstützen bei der Installation, Konfiguration oder grundlegenden Einrichtung. Wir freuen uns über eine Kontaktaufnahme!

Christian Stein

Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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".

Lies mehr von Christian und triff unser Team

Namen sind Schall und Rauch? Lieber nicht.

von Thomas Widhalm | Jan 31, 2020 | Elastic Stack, Graylog

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

Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Lies mehr von Thomas und triff unser Team

Eine Reise in Richtung Graylog – Webinar Serie

von Christian Stein | Sep 2, 2019 | Graylog, NETWAYS, Webinare, Apps

Nachdem die Sommerpause mit unseren Webinaren wieder vorbei ist, wollen wir gleich richtig durchstarten! Diesmal befassen wir uns mit einer Webinar-Serie rund um die Lösung Graylog, welche wir gemeinsam mit den Kollegen von Graylog durchführen.
Ziel ist es, vor allem die Möglichkeiten und die einfache Installation/Konfiguration aufzuzeigen und einen gesamten Überblick zu gewährleisten.

Starten werden wir daher direkt am 04. September um 10:30 Uhr mit dem ersten Teil „Graylog: Aufbau einer Log-Managament Umgebung„. Eine Anmeldung ist hier möglich.

Selbstverständlich haben wir die nächsten Teile bereits eingeplant – eine Übersicht findet sich in unserem Webinar-Kalender, oder ihr lest einfach weiter:

Graylog: Einrichten von Streams und Filtern (18. September 2019 um 10:30 Uhr)
Graylog: Enterprise Features (16. Oktober 2019 um 10:30 Uhr)
Graylog: Monitoring und Integration mit Icinga 2 (11. Dezember 2019 um 10:30 Uhr)

Wer darüber hinaus noch an unseren OpenStack Webinaren oder an unserer Cloud interessiert ist, der wird in diesem Jahr ebenfalls noch etwas geboten bekommen:

OpenStack: Netzwerk Integration mit VPN (20. November 2019 um 10:30 Uhr)
OpenStack: Kubernetes on OpenStack (Magnum) (27. November 2019 um 10:30 Uhr)

Wie üblich werden alle Webinare aufgezeichnet und auf unserem YouTube Channel veröffentlicht. Wir freuen uns auf eure Teilnahme und sind natürlich auch für Themen-Vorschläge offen!

Christian Stein

Manager Sales

Lies mehr von Christian und triff unser Team

In Love with new Features!

von Daniel Neuberger | Mrz 15, 2019 | Serien, Graylog

Graylog v3.0 unter der Lupe

Teil I

Am „Tag der Liebe“ dem Valentinstag 2019 wurde Graylog Version 3 veröffentlicht. Auf den ersten Blick könnte man vermuten, dass sich nichts geändert hat. Dies stimmt aber so nicht!

Es gibt drei Neuerungen in der Open Source Variante, wobei eine elementar ist (dazu unten mehr). In der Enterprise Variante kommen zu diesen Neuerungen dann noch Views und ein Reporting hinzu. Die Enterprise Features sind jedoch für jeden bis zu einer täglichen Log-Menge von 5GB mit einer entsprechenden Lizenz (im letzten Drittel auf der Download-Page anzufordern) frei Nutzbar. In diesem Artikel werden wir uns dem neuen Sidecar, Content Pack Feature und den neuen Grok Debugger kurz anschauen.

Sidecar (Breaking Change)

Mit Graylog Version 3 wird der Sidecar in die Version 1.0.0 gehoben. Bevor wir zu der Umsetzung in Graylog kommen, muss man über die neue Nutzung des Sidecars sprechen. War es doch in den alten Versionen üblich, dass Sidecar die Shipper wie Filebeat, Winlogbeat und NXlog installiert hat, muss man sich jetzt um deren Installation selbst kümmern. Sidecar ist jetzt in der Lage, jegliche Elastic Beats oder Syslog-Daemons parametrisiert zu steuern und zu starten. Hierbei werden die einzelnen Dienste als Prozess mit Commando-Parametern durch den Sidecar aufgerufen.

Beispiel:
[root@graylog ~]# ps aux | grep filebeat root 12836 0.0 0.6 498340 23524 ? Sl Mär13 0:27 /usr/share/filebeat/bin/filebeat -c /var/lib/graylog-sidecar/generated/filebeat-syslog-sysmodule-ssh-rpmbase.conf --path.home /usr/share/filebeat --modules system -M system.syslog.enabled=false -M system.auth.enabled=true -M system.auth.var.paths=[/var/log/secure]

Um den Filebeat wie oben gezeigt auszuführen, muss man folgende als Wert für die „Excecute Parameter“ eingetragen werden:
-c %s --path.home /usr/share/filebeat --modules system -M "system.syslog.enabled=false" -M "system.auth.enabled=true" -M "system.auth.var.paths=[/var/log/secure]"

Hierzu werden Konfigurationen für „Log Collectors“ global hinterlegt und als sogenannte „Configurations“ genutzt. Diese „Log Collectors“ können dann einen Filebeat, Auditbeat oder rSyslog mit der entsprechend generierten Konfiguration, welche auf dem Sidecar-Host unter „/var/lib/graylog-sidecar/generated/“ (z.b unter Linux) ausgerollt werden, steuern.

Hier wird der Collector für einen Auditbeat konfiguriert:

Hier ist das Template Beispiel für einen Auditbeat:
auditbeat.modules: - module: auditd audit_rules: | # Things that affect identity. -w /etc/group -p wa -k identity -w /etc/passwd -p wa -k identity -w /etc/gshadow -p wa -k identity -w /etc/shadow -p wa -k identity -w /etc/passwd -p wra -k passwd -a exit,always -F arch=b64 -S clock_settime -k changetime # Unauthorized access attempts to files (unsuccessful). -a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access -a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=access -a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access -a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=access - module: file_integrity paths: - /bin - /usr/bin - /sbin - /usr/sbin - /etc - module: system datasets: - host # General host information, e.g. uptime, IPs - user # User information period: 1m user.detect_password_changes: true - module: system datasets: - process # Started and stopped processes - socket # Opened and closed sockets period: 1s setup.template.enabled: false output.logstash: hosts: ["192.168.0.1:5044"] processors: - add_host_metadata: ~ - add_cloud_metadata: ~ path: data: /var/lib/graylog-sidecar/collectors/auditbeat/data logs: /var/lib/graylog-sidecar/collectors/auditbeat/log

Danach kann man diesen Collector als Konfiguration nutzen und und ebenfalls anpassen:

Unter „Collectors Administration“ werden diese dann den einzelnen Sidecars zugeordnet:

In Anbetracht der Tatsache, dass sich so auch die Module eines Filebeats und andere Dienste vielseitiger nutzen lassen, ist der Wegfall der vorher vorhanden Automatisierung beim Rollout zu verkraften. Zumal mit der neuen Umsetzung die Versionsbindung bei den Beats wegfällt.

Wichtig ist auch zu wissen, dass die alten Graylog-Sidecars mit dieser Umsetzung nicht kompatibel sind und es deswegen unter dem Punkt „Collectors (Legacy)“ zu verwalten sind. Doch der Umstieg lohnt sich!

Content Packs

Die Zeit der Frustration hat ein Ende! War es doch in der Vergangenheit so, dass man immer wieder geniale Pipeline Konstrukte gebaut hat und sich gedacht hat: Jetzt habe ich hier doch ein gutes Setup, dass würde ich gerne wieder verwenden oder mit meiner Gemeinschaft teilen! Und da war er der Stolperstein, denn Pipelines und Pipeline Rules konnten nicht in einem Content Pack verarbeitet werden. Für Frust sorgte auch, wenn man ein Content Pack herausnehmen und aktualisieren wollte oder gar versehentlich zwei mal installierte! All dies hat jetzt ein Ende!

Mit der neuen Umsetzung der Content Packs lassen sich Element wie Pipelines, Pipeline Rules, Sidecar Collectoren und Configurations sowie die gewohnten Standards verarbeiten und mit einer umfangreichen Description und Herkunftsangabe exportieren, ja sogar Variablen können verwendet werden. Aber noch nicht genug – sind diese einmal erstellt, lassen diese sich in einer Versionierung aktualisieren und neu installieren. Damit ist man nun in der Lage, sich einen validen Werkzeugkasten aufzubauen, um für jeden Einsatz das richtige Werkzeug zu haben.

Grok Debugger

Immer wieder stolperte man über die Tatsache, dass sich die Umsetzung in Java-Grok doch von der bekannten Syntax des Groks in Logstash’s jruby unterscheidet. Man was ich mir schon die Finger wund getippt habe, um Escapes einzufügen, welche die Java-Implementierung fordert. Dies hat nun ein Ende. Will man jetzt einen Grok-Pattern einzeln anlegen oder bearbeiten, wird einem die Möglichkeit geboten, mit einem Beispiel-Datensatz dieses Pattern direkt zu testen.

So das waren jetzt ein paar Kurze Worte zu bereits drei der neuen Features. Aber ich bin mir sicher das jedes einzelne hier in diesem Blog noch mal Beachtung finden wird.

Und weil Spaß macht, dürft Ihr euch auf den nächsten Blogpost freuen, in dem die erste Version des „Graylog Linux Security and System Audit“ Content Pack veröffentlicht wird.

Und wer jetzt Lust auf mehr hat der ist herzlich eingeladen eine unserer Schulungen bei NETWAYS (z.b. vom Mai 28 – Mai 29 in Nürnberg) zu besuchen oder sich bei notwendiger Hilfe an unser Sales Team zu wenden, um von den kompetenten Kollegen von NETWAYS Professional Services bei den eigenen Herausforderungen rund um Graylog oder gar Elastic Hilfe zu erfahren.

Wer übrigens oben noch nicht dem Link zum Valentinstag im ersten Satz gefolgt ist hier ein Zitat: