Seite wählen

NETWAYS Blog

Multiline in Grok – Kein schönes Format

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

Ansible Host-Gruppen: Wer gehört zu wem?

Immer wieder kommt es vor, dass ich in größeren Ansible-Umgebungen arbeite. Diese enthalten eine Vielzahl von verschiedenen Gruppen im Inventory, die sich auch mal aus anderen Host-Gruppen zusammen setzen. Da ist es nicht immer leicht den Überblick zu behalten.
Da kommt es schon mal vor, prüfen zu wollen oder zu müssen ob alle Gruppen richtig aufgebaut sind oder korrekt interpretiert werden.
Nach ein wenig Recherche war auch schnell mit einem einfachen Ein-Zeiler eine Lösung gefunden, um sich anzeigen zu lassen in welcher Gruppe die einzelnen Server einsortiert sind oder wie sich die Gruppe im Ansible-Inventory zusammen setzt

[code lang=“plain“]
ansible -i <inventory> localhost -m debug -a ‚var=groups‘
[/code]

Dabei lässt sich entweder das Inventory-Verzeichnis oder eine konkrete Inventory-Hostdatei angeben.
Und weil es mit einem Beispiel immer besser ist:

[code lang=“bash“]
ansible -i hosts localhost -m debug -a ‚var=groups‘
localhost | SUCCESS => {
"groups": {
"all": [
"maja42310",
"maja42444",
"willy1334",
"willy24242",
"koenigin_blau"
],
"drohnen": [
"willy1334",
"willy24242"
],
"honigbienen": [
"maja42310",
"maja42444"
],
"honigbienenvolk": [
"maja42310",
"maja42444",
"willy1334",
"willy24242",
"koenigin_blau"
],
"koenigin": [
"koenigin_blau"
],
"ungrouped": []
}
}
[/code]

Da ich mir das nun mehr als ein mal nicht merken konnte, dachte ich mir ich schreib das mal hier auf. Vielleicht hilft es ja dem ein oder anderen und ich kann es mir jetzt besser merken:)

Wenn Ihr noch mehr über Ansible erfahren wollt, dann besucht doch einfach eines unserer Trainings bei Netways Events. Sollte es schon etwas konkreter sein und Ihr benötigt gezielt Hilfe, fragt doch gerne unsere Kollegen vom Sales Team ob Ihr nicht Unterstützung von Netways Professional Service bekommt.

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

Jitsi Best Practice und Skalierung

Seit nun mehr als zwei Wochen wird dort wo es möglich ist von Zu Hause aus gearbeitet. Home-Office für ALLE! Naja mindest für die die es können.

Damit ist auch von einem Tag auf den anderen der Bedarf an Kommunikations-Werkzeugen vor allem für Video-Konferenzen gestiegen.
Hierfür gibt es einige Plattformen welche mittels Jitsi Video- und Audiokommunikation als Service anbieten. Darunter auch NETWAYS Web Services
Jitsi ist eine Freie Software welche auch selbst betrieben werden kann.
Beim Betrieb von Jitsi jedoch zeigt sich das Jitsi sehr schwierig in der Skalierung ist. Es benötigt die richtigen Ressourcen und die richtigen Clients für die Nutzung, um nicht ab einer zweistelligen Zahl von Nutzern in einen reinen Ton- und Bildsalat zu enden. Die technischen Dokumentationen jedoch sind nicht sehr ausgeprägt und durch ihre Zerstreuung sehr schwer zu einem ganzen zusammen zu fügen.

Daher werden wir uns folgend mit den Punkten Anforderungen, Skalierung und Nutzung auseinander setzen.

Empfehlung für einen eigenen Jitsi Server/Videobridge

Nach meinen Tests und der Güte an vorhandenen Quellen zur Hilfe und Dokumentation komme ich zu folgendem Ergebnis:

    • Betriebssystem: Debian 10 oder Ubuntu 18.04.4 LTS
    • Soviel CPU wie geht
      (klingt komisch ist aber so)
      CPU: bei durchschnittlich 10 Teilnehmer pro Konferenz kommen ich mit 2vCPU für die Videobridge ganz gut klar. Mehr zur Skalierung der CPU findet ihr hier:

jitsi-videobridge-performance-evaluation

  • CPU Jitis/Jifico/Prosody: Hier würde auch eine (v)CPU ausreichen, hängt jedoch auch wieder von der Frequentierung ab.
  • RAM: 4-8 GB für beide Server-Varianten
  • Speicherplatz: max. 50 GB SSD für beide Server-Varianten
  • Eine hohe Bandbreite
  • Die Unstable Version von Jitsi:

[code lang=“plain“]
# install the key
wget -qO – https://download.jitsi.org/jitsi-key.gpg.key | apt-key add –
# add the unstable repo
sh -c &amp;amp;quot;echo ‚deb https://download.jitsi.org unstable/‘ &amp;amp;gt; /etc/apt/sources.list.d/jitsi-unstable.list&amp;amp;quot;
apt update
[/code]

Eine gute Installations-Anleitung dazu gibt es zum einen von Jan Doberstein auf seinem Blog jalogisch.de
oder auch sehr hilfreich und weiterführend auf der Seite lw1.at guides

Skalierung einer Jitsi Infrastruktur

Ausgangslage

Wir haben einen vollständig installierten Jitsi Server Namens jitsi.example.com auf Basis von Debian. Jetzt wollen wir mehr mehr Ressourcen bereit stellen, so müssen wir weitere jitsi-videobridge Instanzen aufsetzen.
In der vollständigen Installation eines Jitsi-Servers auf Basis von Debian 10 sind folgende Pakete installiert:

[code lang=“plain“]
ii jitsi-meet 1.0.4314-1 all WebRTC JavaScript video conferences
ii jitsi-meet-prosody 1.0.3914-1 all Prosody configuration for Jitsi Meet
ii jitsi-meet-web 1.0.3914-1 all WebRTC JavaScript video conferences
ii jitsi-meet-web-config 1.0.3914-1 all Configuration for web serving of Jitsi Meet
ii jitsi-videobridge2 1132-1 amd64 WebRTC compatible Selective Forwarding Unit (SFU)
[/code]

Der Part jitsi-videobridge ist der Teil der den jtisi-meet mit der Video und Audio Übertragung versorgt. Er schließt sich an jitsi-meet und dem verwendeten prosody (XMPP-Server) an.

Anbindung einer Videobridge

Dazu binden wir die die Paketquellen auf dem zweiten Server vb1.example.com ein und installieren die Videobridge:

[code lang=“plain“]
# install the key
wget -qO – https://download.jitsi.org/jitsi-key.gpg.key | apt-key add –
# add the unstable repo
sh -c &amp;amp;quot;echo ‚deb https://download.jitsi.org unstable/‘ &amp;amp;amp;gt; /etc/apt/sources.list.d/jitsi-unstable.list&amp;amp;quot;
apt update
apt install jitsi-videobridge2
[/code]

Sollte eine Firewall auf dem Server jitsi.example.com aktiviert sein so müssen wir den Port 5222 für eingehende Kommunikation öffnen.

Auf dem zweiten Server vb1.example.com passen wir jetzt die Datei „/etc/jitsi/videobridge/config“ an:

[code lang=“plain“]
# Jitsi Videobridge settings

# sets the XMPP domain (default: none)
JVB_HOSTNAME=jitsi.example.com

# sets the hostname of the XMPP server (default: domain if set, localhost otherwise)
JVB_HOST=jitsi.example.com
….
[/code]

Dann kommen wir zu Datei für die SIP-Kommunikation. Diese sollte vom Hauptserver jitsi.example.com übernommen werden und die UUID sollte hierbei auf jedem Server unterschiedlich gesetzt sein.
Die Datei „/etc/jitsi/videobridge/sip-communicator.properties“ wird wie folgt eingestellt:

[code lang=“plain“]
org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true
org.jitsi.videobridge.ENABLE_STATISTICS=true
# Notwendig falls der Server hinter einem NAT steht.
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=local-ip
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=public-ip
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=jitsi.example.com
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.jitsi.example.com
org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.auth.jitsi.example.com
#UUID am besten mit &amp;amp;quot;uuidgen&amp;amp;quot; neu gernieren muss auf beiden Servern Einzigartig sein.
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=9a6187f0-6d3f-46df-b1ff-ce7d2d69513a
org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true
[/code]

Auf Debian 10 tritt mit Java 11 folgender Fehler auf:

[code lang=“plain“]
VB 2020-03-21 19:29:23.687 SEVERE: [16] org.jitsi.utils.concurrent.RecurringRunnableExecutor.log() The invocation of the method org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.run() threw an exception.
java.lang.reflect.InaccessibleObjectException: Unable to make public long com.sun.management.internal.OperatingSystemImpl.getTotalPhysicalMemorySize() accessible: module jdk.management does not &amp;amp;quot;opens com.sun.management.internal&amp;amp;quot; to unnamed module @54ca3634
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
at java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
at org.jitsi.videobridge.stats.OsStatistics.getTotalMemory(OsStatistics.java:138)
at org.jitsi.videobridge.stats.VideobridgeStatistics.generate0(VideobridgeStatistics.java:703)
at org.jitsi.videobridge.stats.VideobridgeStatistics.generate(VideobridgeStatistics.java:450)
at org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.doRun(StatsManager.java:321)
at org.jitsi.utils.concurrent.PeriodicRunnableWithObject.run(PeriodicRunnableWithObject.java:87)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)
[/code]

Dieser kann beseitigt werden mittels folgender Ergänzung am Ende der Java System Properties in der Datei „/etc/jitsi/videobridge/config“:

[code lang=“plain“]
JAVA_SYS_PROPS=&amp;amp;quot;-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=videobridge -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi -Djava.util.logging.config.file=/etc/jitsi/videobridge/logging.properties –add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED&amp;amp;quot;
[/code]

Nun können wir die Videobridge starten:

[code lang=“plain“]
systemctl enable jitsi-videobridge &amp;amp;amp;&amp;amp;amp; systemctl start jitsi-videobridge
[/code]

An der Stelle geht auch ein Dank an Jan Doberstein der mich auf diese Spur gebracht hat und in seinem Blog-Folge Artikel zu Scaling Jitsi

Nutzung

Das Protkoll WebRTC, welches Jitsi nutzt, wird zur Zeit nur sauber von Google Chrome unterstützt. Somit sollte allen Nutzern dieser Browser, für die Anwendung am Notebook empfohlen werden. Für Androide und iOS Geräte gibt es Applikationen den jeweiligen App-Stores. Sehr schöne Zusammenfassung und eine ausführliche Benutzer-Anleitung hierzu gibt es auch auf der Seite des Freifunk München.

Sicherheit

Zum Thema Sicherheit empfiehlt es sich am Besten zuerst die Stunning-Server von Google in der Datei „/etc/jitsi/meet/jitsi.example.com-config.js zu ersetzen. Eine geeignete Stunning-Server Konfiguration kann wie folgt lauten:

[code lang=“plain“]
stunServers: [
{ urls: ’stun:stun.schlund.de:3478′ },
{ urls: ’stun:stun.t-online.de:3478′ },
{ urls: ’stun:stun.1und1.de:3478′ },
{ urls: ’stun:stun.hosteurope.de:3478′ },
{ urls: ’stun:stun.gmx.de:3478′ },
],
[/code]

Zustätzlich wenn Ihr nicht eine gänzlich freie Plattform, sondern eine mit Moderaten oder sogennante Host per Raum gestützte Instanz betreiben wollt, empfiehlt es sich in prosody und jitsi-meet die Benutzerauthentifzierung für das erstellen von Räumen zu aktivieren.
In der Datei für die prosody-Konfiguration „/etc/prosody/conf.avail/jitsi.example.com.cfg.lua“, setzen wir den Wert für „authentication“ auf „internal_plain“ und fügen einen neuen VirtualHost darunter ein ein:

[code lang=“plain“]
VirtualHost &amp;amp;quot;jitsi.yourdomain.example&amp;amp;quot;
— enabled = false — Remove this line to enable this host
authentication = &amp;amp;quot;internal_plain&amp;amp;quot;
— Properties below are modified by jitsi-meet-tokens package config
— and authentication above is switched to &amp;amp;quot;token&amp;amp;quot;
–app_id=&amp;amp;quot;example_app_id&amp;amp;quot;
–app_secret=&amp;amp;quot;example_app_secret&amp;amp;quot;
— Assign this host a certificate for TLS, otherwise it would use the one
— set in the global section (if any).
— Note that old-style SSL on port 5223 only supports one certificate, and will always
— use the global one.
ssl = {
key = &amp;amp;quot;/etc/prosody/certs/jitsi.yourdomain.example.key&amp;amp;quot;;
certificate = &amp;amp;quot;/etc/prosody/certs/jitsi.yourdomain.example.crt&amp;amp;quot;;
}
— we need bosh
modules_enabled = {
&amp;amp;quot;bosh&amp;amp;quot;;
&amp;amp;quot;pubsub&amp;amp;quot;;
&amp;amp;quot;ping&amp;amp;quot;; — Enable mod_ping
}
c2s_require_encryption = false

VirtualHost &amp;amp;quot;guest.jitsi.example.com&amp;amp;quot;
authentication = &amp;amp;quot;anonymous&amp;amp;quot;
c2s_require_encryption = false
[/code]

In der Datei „/etc/jitsi/meet/jitsi.example.com-config.js“ geben wir nun den neuen VirtualHost an:

[code lang=“plain“]
var config = {
hosts: {
// XMPP domain.
domain: ‚jitsi.yourdomain.example‘,

// When using authentication, domain for guest users.
anonymousdomain: ‚guest.jitsi.yourdomain.example‘,
}
}
[/code]

Nun müssen wir noch jifico dazu veranlassen auch eine Authentifizierung durchzuführen und die Klasse in der „/etc/jitsi/jicofo/sip-communicator.properties“ laden:

[code lang=“plain“]
org.jitsi.jicofo.auth.URL=XMPP:jitsi.example.com
[/code]

Danach müssen die Dienste neu gestartet werden:

[code lang=“plain“]
sudo systemctl restart prosody.service
sudo systemctl restart jicofo.service
[/code]

Für die Anbindung einer Authentifizierung in Prosody gibt es auch Enterprise fähige Funktionen für LDAP und Co. Die obige Lösung beschreibt es für ein überschaubares Setup, denn die Benutzer hier müssen dann im Anschluss mit der prosodctl generiert werden:

[code lang=“plain“]
prosodyctl register jitsi-meet.example.com
[/code]

Abschließend bleibt zusagen…

Es ist nicht leicht gute Dokumentationen zu Jitsi und dessen Betrieb zu finden, eben so wie für das Scalling. Eine einheitliche Dokumentation gibt es nicht und somit macht es einen Gesamtüberblick nicht sehr leicht.
Neben der Jitis-Community und der Docs auf GitHub gibt es eine paar bereits schon erwähnte Artikel aber auch die sind rah. Daher die Bitte wenn jemand verbesserungen hat, meldet euch gerne!

Wenn Ihr eine Instanz dringend benötigt und euch nicht mit dem Betrieb ausseinandersetzen könnt oder naja vielleicht nicht wollt, dann schaut doch einfach bei unseren Kollengen von NWS vorbei. Dort bekommt Ihr aktuell mit dem Code #StayAtHome eine kostenlose Jitsi-Instanz für drei Monate und das ganz ohne Abo-Falle!

Also bleibt Zuhause und fragt euch gerade in diesen Tagen doch mindestens einmal am Tag:

1. Ist es wahr?
2. Ist es fair für alle Beteiligten?
3. Wird es Freundschaft und guten Willen fördern?
4. Wird es dem Wohl aller Beteiligten dienen?“

(Das sollten wir uns bei allem Fragen, was wir denken, sagen oder tun IMHO!)

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

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

In Love with new Features!

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:

Liebe ist etwas völlig anderes als Verliebtheit.

Holger Kuntze, Paartherapeut
Mal sehen wie lange meine Verliebtheit hier anhält :-)…
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 Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.