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
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)
Bandbreite
Die Unstable Version von Jitsi:
# install the key
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
# add the unstable repo
sh -c "echo 'deb https://download.jitsi.org unstable/' > /etc/apt/sources.list.d/jitsi-unstable.list"
apt update
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:
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-videobridge 1132-1 amd64 WebRTC compatible Selective Forwarding Unit (SFU)
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:
# install the key
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
# add the unstable repo
sh -c "echo 'deb https://download.jitsi.org unstable/' > /etc/apt/sources.list.d/jitsi-unstable.list"
apt update
apt install jitsi-videobridge
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:
# 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
….
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:
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 "uuidgen" 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
Auf Debian 10 tritt mit Java 11 folgender Fehler auf:
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 "opens com.sun.management.internal" 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)
Dieser kann beseitigt werden mittels folgender Ergänzung am Ende der Java System Properties in der Datei “/etc/jitsi/videobridge/config”:
JAVA_SYS_PROPS="-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"
Nun können wir die Videobridge starten:
systemctl enable jitsi-videobridge && systemctl start jitsi-videobridge
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:
stunServers: [
{ urls: 'stun:stun.schlund.de:3478' },
{ urls: 'stun:stun.t-online.de:3478' },
{ urls: 'stun:stun.1und1.de:3478' },
{ urls: 'stun:stun.einsundeins.de:3478' },
{ urls: 'stun:stun.gmx.de:3478' },
],
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:
VirtualHost "jitsi.yourdomain.example"
-- enabled = false -- Remove this line to enable this host
authentication = "internal_plain"
-- Properties below are modified by jitsi-meet-tokens package config
-- and authentication above is switched to "token"
--app_id="example_app_id"
--app_secret="example_app_secret"
-- 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 = "/etc/prosody/certs/jitsi.yourdomain.example.key";
certificate = "/etc/prosody/certs/jitsi.yourdomain.example.crt";
}
-- we need bosh
modules_enabled = {
"bosh";
"pubsub";
"ping"; -- Enable mod_ping
}
In der Datei “/etc/jitsi/meet/jitsi.example.com-config.js” geben wir nun den neuen VirtualHost an:
var config = {
hosts: {
// XMPP domain.
domain: 'jitsi.yourdomain.example',
// When using authentication, domain for guest users.
anonymousdomain: 'guest.jitsi.yourdomain.example',
[...]
}
}
Nun müssen wir noch jifico dazu veranlassen auch eine Authentifizierung durch zu führen und die Klasse in der “/etc/jitsi/jicofo/sip-communicator.properties” laden:
org.jitsi.jicofo.auth.URL=XMPP:jitsi.example.com
Danach müssen die Dienste neu gestartet werden:
sudo systemctl restart prosody.service
sudo systemctl restart jicofo.service
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:
prosodyctl register jitsi-meet.example.com
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
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...
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.
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:
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
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...
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.
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:
Mal sehen wie lange meine Verliebtheit hier anhält :-)…
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...
KidsCamp bedeutet “Urlaub vom Alltag” – Kindern und Jugendlichen eine Möglichkeit zu bieten deren Familien sich keinen Urlaub leisten können oder schlichtweg in einem nicht geordneten familiären Umfeld leben. In diesem für die Kinder kostenlosen Kurzurlaub ist es das Ziel, durch einmalige Erlebnisse Freude und Spaß zu bringen und dabei Freundschaft, Teamgeist, Freude und ein gesteigertes Selbstwertgefühl den Kindern zu vermitteln.
Getragen wird das ganze vom Urlaubskinder e.V welcher 2010 aus einem gemeinschaftlichen Projekt Rotaract und Rotary Clubs hervorging. Der Verein unterstützt dabei aktiv die jeweiligen Organisatoren der eigenständigen Projekte durch die Bereitstellung von Materialen und Know-How. Daneben werden finanzielle Risiken übernommen und aktiv bei der Abwicklung und Einwerbung der Projektfinanzen mitgearbeitet.
Durchgeführt wird ein solches KidsCamp von Rotaractern und nicht Rotaractern auf ehrenamtlicher Basis. Diese jungen Erwachsenen sind verantwortlich für die Planung und Durchführung eines solchen Zeltlagers, welche stets politisch und religiös unabhängig sind. Aus diesem Verständnis heraus werden die Kinder durch Patenschaften, unabhängig von ihrer Herkunft und Religion eingeladen. Diese Patenschaften werden meist von rotarischen Clubs übernommen und die Auswahl oft mit Schulen und Jugendämtern vor Ort abgestimmt. Im Rahmen dieser Patenschaften werden die anfallenden Kosten für eine Teilnahme durch die rotarischen Clubs getragen. Somit stellen die Rotray Clubs die finanzielle Stütze und die Rotaract Clubs stemmen das Camp. Aber auch externe Sponsoren und Aktive Helfer sind keine Seltenheit und herzlich willkommen. Genug der Theorie, jetzt geht es ab auf Safari. Ihr verfolgt vielleicht meine Blog-Posts, und habt mitbekommen, dass ich mich in meiner Freizeit bei Rotary und Rotaract engagiere, um Gutes zu tun und Gutes zu wirken. So kam es, dass meine Frau und ich als Helfer auf dem KidsCamp 2018 unseres Distriktes unter dem Motto Safari dabei waren. Ich muss gestehen, dass ich am Anfang sehr blauäugig an die ganze Sache herangegangen bin. Ich hätte nie gedacht welch Anstrengung ein solches Camp doch darstellt. 5 Tage lang wurde 60 Kindern ein einzigartiges Safari Erlebnis an der Effelter Mühle im schönen Franken geboten, mit grossartiger Unterstützung von zeitweise bis zu 55 Helfern. Unter dem Motto Safari wurden die Kinder als Jung-Ranger in Teams ausgebildet und mussten zudem ihrem (Plüsch)-Wildtier als Gruppe Pate stehen. Dabei wurde sich mit den Kindern sportlich mit Spiel und Spaß betätigt, gebastelt und ein Ausflug in den Wildtierpark unternommen. Weitere Highlights waren die große Hüpfburg und die Wasserrutschbahn welche die Freiwillige Feuerwehr für uns am wohl wärmsten Tag bereitstellte.
Man könnte annehmen, dass 55 Helfer für 60 Kinder Einzelbetreuung bedeutet, dem ist aber nicht so. Ein 13 köpfiges Team hat fast 24h Stunden am Tag die Lagerküche betrieben um Kinder sowie Helfer an fünf Tagen mit drei Mahlzeiten am Tag zu versorgen. Es wurde von einem Team das Materialzelt betreut. Es mussten mehrfach am Tag sanitäre Bereiche gereinigt werden, Nachtwachen gestellt werden und jeder Gruppe von Kindern waren 24 Stunden rund um die Uhr zwei Zeltbetreuer zugeteilt. Alle Betreuer wurden im Vorfeld des Zeltlagers entsprechend auf diese Aufgabe pädagogisch Vorbereitet. Nicht zu vergessen musste ein Orga-Team ständig Entscheidungen treffen und es gab auch einen Camp-Arzt, der das ein oder andere Trostpflaster verteilen musste. Kurzum gab es immer für jeden etwas zu tun. Meine Frau war in der Küche eingeteilt und verbrachte mit mir eine Nachtwache. Ich selbst war als Springer und Safari-Fotograf dabei. So kam es das ich immer überall ein wenig dabei war und sehr viel von den Kindern und dem Camp-Geschehen direkt erleben konnte und in ca. 4000 Bilder festhielt. Dabei war ich nicht selten mehr als 16 Stunden auf den Beinen, bei so manchem Helfer keine Seltenheit.
Aus der Sicht als Betreuer kann ich sagen, dass einzelne Schicksale einem doch näher gehen als man selbst denkt. Es ist eine große Freude zu sehen wie so manches Kind sich über diese 5 Tage hinweg entwickelt und beim Erleben des Camps spürbar Freude erfährt. Allein diese Momente waren jede Anstrengung und das Geben seiner eigenen Kräfte wert.
Aber warum schreibe ich darüber in unserem Blog? Unser lieber Bernd entschied auf meine Anfrage hin, dass ich für die drei Werktage entgeltlich von der Arbeit freigestellt wurde. Dafür möchte ich mich herzlich bedanken. Dies zeigt das NETWAYS GmbH nicht nur als Arbeitgeber eine soziale Verantwortung durch Beschäftigung als wichtig erachtet wird, sondern auch ehrenamtliches Engagement zum Dienste am nächsten eine Beachtung und Unterstützung findet.
Wer nun Lust bekommen hat die Arbeit des Urlaubskinder e.V zu unterstützen, den möchte ich herzlich einladen aktiv mitzumachen oder in Form von Sachspenden, Geldspenden oder Fördermitgliedschaften beizutragen. Ein weiteres noch junges Projekt ist das Youthcamp, welches Jugendlichen den Einstieg in eine berufliche Zukunft ermöglichen soll, zu welchem sie womöglich trotz Eignung nicht aus eigener Kraft oder der des Umfelds finden würden. Hierzu kann ich euch hoffentlich nächstes Jahr berichten.
Neben dem sozialen Engagement ist es auch Bestandteil für mich, in allen Lebenslagen nach leitenden Prinzipien und Werten zu handeln. So stelle ich mich jeden Tag aufs neue der Vier-Fragen-Probe, an welcher ich mich für mein Wirken und Sein orientiere. Diese möchte ich euch mit auf den Weg geben:
Bei allem, was wir denken, sagen oder tun, sollten wir uns fragen:
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?”
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...
Vor dieser Frage stand ich neulich bei einem Kunden. Und dank dem Rat netter Kollegen kam sogar eine ansehnliche Lösung hervor. Wer kennt das nicht – Applikationen, die in einem Linux-HA Cluster laufen worauf über eine Cluster-Virtual-IP zugegriffen wird. An diese VIP-Ressource sind der Applikationsprozess und womöglich eingehängter Speicher als weitere Cluster-Ressource angeknüpft. Somit sprechen wir von zwei Cluster-Ressourcen, die mit einer Cluster-Ressource der VIP verknüpft sind. Diese Abhängigkeit definiert, dass die Anwendung immer nur auf einem aktiven Cluster-Node im zugewiesener VIP laufen kann. Dies ergibt einen Active und einen Passive Node (in unserem Fallbeispiel!)
Was bedeutet das genau?
Die Cluster-VIP kann von Active zum Passive Host anhand von Fehler-Kriterien geschwenkt werden. Somit schwenkt der gesamte Betrieb der Applikation vom aktiven Host auf den passiven Host. Dort wird der Applikationsprozess gestartet und die Disk eingehängt. Würden wir jetzt einfach auf beiden Servern neben den System-Standards noch die Applikation gezielt überwachen, würden wir auf einem der beiden Nodes für den fehlenden Prozess und die fehlende Disk immer den Status “Critical” bzw. den Status “Unknown” beim Ausführen des Disk-Checks zurückbekommen.
Lösung!
Um eine Überwachung über die Cluster-VIP zu realisieren, verwenden wir ein eigenes Plugin welches als Wrapper fungiert. Der Check verwendet die Cluster-VIP als Parameter und überprüft ob diese an einem lokalen Interface konfiguriert ist. Wird an einem Interface die Cluster-VIP-Ressource zugewiesen, führt das Plugin den eigentlichen Check aus. Dieser wird als zweiter Parameter übergeben und entspricht dem Namen des Checks, z.B. “check_disk”. Durch den Aufruf des Kommandos mit dem Argument “$@” werden alle Parameter des Wrapper-Scripts an das Plugin übergeben.
Sollte auf einem Cluster-Node die Cluster-VIP nicht zugewiesen sein, gibt der Check den Status “OK” und den Plugin-Output “YES! VIP down & I’m STANDBY” zurück.
Einrichten des Check-Commands
Nun können wir dieses Plugin im PluginDir-Pfad auf dem zu überwachenden Host ablegen. Zusätzlich benötigen wir noch ein CheckCommand, welches das Wrapper-Script aufruft und dann die Parameter von “disk” erwartet. Dies kann man so lösen, dass mittels “import” das bestehende “disk” CheckCommand importiert wird und lediglich das auszuführende “command” mit dem Wrapper-Script überschrieben wird. Die Einbindung des CheckCommands sollte am Icinga-2-Master erfolgen, statisch in “commands.conf” oder im Director.
Im folgenden sind die Beispiele für eine Disk, Prozess und Logfile-Check aufgeführt. Dieses Set könnte einer typischen Cluster-Applikation entsprechen. Wir definieren einen Service-Prozess und einen Filesystem-Mount/Disk die als Cluster-Ressource an die Cluster-VIP gebunden sind. Diese Applikation schreibt auch Log-Dateien, die möglicherweise zu überwachen sind.
Die zugehörigen Service-Definitionen könnten so definiert werden:
apply Service "vip-disk" {
check_command = "vip-disk"
vars.app_vip = host.vars.app_vip
command_endpoint = "..."
assign where host.vars.app_vip
}
apply Service "vip-procs" {
check_command = "vip-procs"
vars.app_vip = host.vars.app_vip
command_endpoint = "..."
assign where host.vars.app_vip
}
apply Service "vip-logfiles" {
check_command = "vip-logfiles"
vars.app_vip = host.vars.app_vip
command_endpoint = "..."
assign where host.vars.app_vip
}
Und hier ein Auszug zur Darstellung im icingaweb2:
Service-List Icingaweb2
Service – Plugin Output Icingaweb2
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...
Wir werden alle leider nicht jünger. Jeder altert anders. Viele benötigen im Alter Pflege. Fakt ist, die Zahl derer die pflegebedürftig sind, steigt stetig. Es gibt viele fleißige und fürsorgliche Menschen, die in dem Dienstleistungssektor der Pflege arbeiten. Nur leider gibt es eben genau so viele von diesen Menschen, die oftmals miserabel bezahlt werden oder unter den widrigsten Bedingungen und mit knappsten Mitteln diese Dienstleistung erbringen müssen. Oftmals bleiben dabei die zu pflegenden Menschen und ihre Bedürfnisse sowie deren Lebensfrohsinn auf der Strecke.
Kurz und knapp gesagt: der Zustand in den deutschen Pflegeeinrichtungen und deren Branche ist oftmals alles andere als rosig und ist für alle Beteiligten eher unangenehm. Deshalb hat es sich die Power Challenge #1min.care zum Ziel gesetzt, für die in der Pflege Arbeitenden und deren Leistungen mit einem 24-stündigen Applaus, sprich 1440 Minuten, und ebenso vielen Videos mit Applaus, die hierfür gesammelt werden, unser aller Dankbarkeit auszudrücken. Jeder kann mitmachen!
Und weil meine Kolleginnen und Kollegen, um mal unseren lieben Bernd zu zitieren, “ein arschgeiler Haufen sind”, haben auch wir eine Minute die Arbeit in der Pflege mit Applaus gewürdigt. So haben wir kurzer Hand nach unserem wöchentlichen Montags-Stand-Up-Meeting gemeinsam geklatscht:
An dieser Stelle möchte ich mich bei meinen Kolleginnen und Kollegen für diesen Einsatz bedanken und sagen: IHR seit Top!
Alles was ihr als Firma, Verein oder was auch immer braucht, ist ein Gerät zum Video aufnehmen und ein klein wenig Zeit! Alle weiteren Informationen zu der Challenge findet Ihr unter #1min.care
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...
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:
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.
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.
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
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...
In einem Gespräch mit einem Kollegen kommt mein Engagement zur Sprache. Es fallen die Begriffe Rotaract und Rotary International. Unser lieber Bernd hört auf einem Ohr mit und fragt mich “Und was machst du? Was ist das?”.
Kurz erkläre ich, dass die rotarische Familie also Rotary international neben Rotary aus mehreren Organisationen besteht und ich selbst einem Rotaract Club (Club Churfranken) angehöre. Rotaract, das steht für “Rotary in Action” und ist eine Organisation für Schüler, Studenten, Auszubildende und junge Menschen im Berufsleben von 18 bis zum 30 Lebensjahr mit dem Motto “Lernen, Helfen, Feiern”. Der rotarische Gedanke ‘Service above Self’ ist das, was verbindet. Dieser Gedanke geht auf in regionalen Projekten bis hin zu globalen Projekten in denen oft unterschiedliche Clubs aus verschiedensten Ländern zusammen wirken. In einem Satz kann man sagen: Es geht darum Freundschaft zu fördern, zur Verständigung beizutragen und mit seinem Fertigkeiten und Mitteln gemeinsam gutes zu wirken.
Abschließend erwähne ich zum Punkt internationale große Projekte, unter anderem Shelterbox, und werde prompt gebeten dieses ausführlicher zu erklären. ShelterBox ist eine von Rotarier Tom Handerson 1999 gegründetes Projekt gewesen und heute eine eigenständige Hilfsorganisation innerhalb von Rotary International. Aber was ist eine Shelterbox?
ShelterBox versorgt Menschen, die durch Naturkatastrophen oder Konflikte ihre Existenzgrundlage verloren haben, mit Notunterkünften und einem Grundstock an lebensnotwendigen Hilfsgütern. Da jede Katastrophe anders ist, entscheiden wir für jeden Einsatz individuell, welche Materialien wir vor Ort verteilen. Durch die kompakten Maße unserer Hilfsgüter gelangen wir auch in abgelegene Regionen, die oft nur zu Fuß oder mit Lasttieren erreichbar sind.
Unsere Überlebenskiste wiegt bis zu 55 Kilogramm und beinhaltet das, was eine Familie nach einer Katastrophe am aller nötigsten braucht, wie zum Beispiel ein Zelt, Decken, Wasserfilter, Moskitonetze, Solarlampen, Geschirr und vieles mehr. Familien, deren Häuser beschädigt, aber nicht vollständig zerstört wurden, bekommen ein ShelterKit mit Werkzeug und Zeltplanen an die Hand, um eigenständig mit dem Wiederaufbau beginnen zu können. Zudem sorgen unsere Klassenzimmer in der Box dafür, dass der Schulbetrieb trotz aller Widrigkeiten weitergehen kann.
Shelterbox basiert auf der Arbeit Ehrenamtlicher sogar bei der Ersthilfe und ist ausschließlich spenden finanziert. So kommt es, das auch unser Club und ich selbst, das ein oder andere mal für Shelterbox eine Spendenaktionen veranstalten.
Aber warum schreibe ich darüber in unserem Blog? Unser lieber Bernd fand die ganze Sache gut und somit hat die NETWAYS GmbH gerne eine Shelterbox gespendet. Dies zeigte mir, dass es bei NETWAYS um mehr geht und ich mit meinen Prinzipien und Wertevorstellungen die Wahl meines Arbeitgebers im Einklang sehen kann.
Sobald wir wissen, in welchem der unzähligen Katastrophen und Krisengebieten die von uns gespendete ShelterBox im Einsatz ist, bekommt ihr ein Update. Wer selbst mit einer Shelterbox unterstützen möchte, kann dies mit Spenden an:
IBAN: DE85 1002 0500 0001 3284 00
BIC: BFSWDE33BER
Verwendungszweck: ShelterBox, Ihr Name + E-Mail-Adresse oder Anschrift
verwirklichen.
Neben dem sozialen Engagement ist es auch Bestandteil, in allen Lebenslagen nach den leitenden Prinzipien und Werten zu handeln. So stelle ich mich jeden Tag aufs neue der Vier-Fragen-Probe, an welcher ich mich für mein Wirken und Sein orientiere. Diese möchte ich euch mit auf den Weg geben:
Bei allem, was wir denken, sagen oder tun, sollten wir uns fragen:
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?”
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...
Vor kurzem durfte ich mich damit beschäftigen, wie man schnell und halbwegs vernünftig eine Art Reporting für Performance-Daten für Icinga 2 umsetzen kann. Um solche Daten entsprechend aufzubereiten bedarf es weiterer Open-Source-Software. Meiner Meinung nach eignet sich Graphite hierzu am besten. Ich möchte heute einen kurzen Einblick in die Möglichkeiten geben.
Graphite ist ein Werkzeug, welches aus drei Komponenten besteht: Carbon-Cache als Datensammler, Whisper als Storage-Backend und Graphite-Web um die Graphen visuell und als API bereitzustellen. Icinga 2 schreibt die Performance-Daten mit dem “graphite”-Feature direkt an den Carbon-Cache-TCP-Socket. Welche Möglichkeiten habe ich als Anwender nun, diese historischen Daten für meine Zwecke in Reporting zu verwenden?
Eigentlich ganz einfach: Graphite liefert eine eigene Render-API. Diese bietet die Möglichkeit, die Daten als Graph, csv , json, pdf und einige weitere Formate zu generieren. Der Anwender kann diese Daten als REST-API Aufruf im Browser oder beispielsweise curl in der Shell abholen. Dabei können verschieden Metriken und Aggregationen auf Graphen angewandt und unterschiedliche Werte gebündelt abgerufen werden.
Wie fange ich an?
Generell wird die URL wie folgt aufgebaut: http://grtaphite.ip/render?target=icinga2..services.*.*.perfdata.*.value
Im gezeigten Beispiel kann man für die “target”-Metriken auch Wildcards verwenden, um etwa mehrere Services gleichzeitig abzufragen. Dies entspricht dem Dateipfad im Whisper-Backend. Man kann allerdings auch Listen oder Arrays angeben, um gezielt bestimmte Werte abzufragen.
Es gibt unterschiedliche Möglichkeiten, die Daten für die entsprechenden Ausgaben weiterzuverarbeiten. Die wohl wichtigsten sind &from für die Zeit und &format für die Formatierung der Daten.
Metrik “Baum”
Um die Werte für die CPU-Load abzufragen, muss der entsprechende Service in Icinga 2 definiert sein und Performance-Daten nach Graphite schreiben. Im Screenshot sieht man im Baum “services” – “load”, letzterer stellt den Service-Namen dar. Der Sub-Knoten “load” liefert die Information, dass hier das “load” CheckCommand verwendet wurde. Tip an dieser Stelle: Lässt sich etwa für Dashboard-Templates als eindeutiger Schlüssel verwenden in Grafana.
Performance-Daten liefern zum einen “perfdata”, worin einzelne Metriken mit ihrem Namen abgelegt werden, etwa “load1” und darunter “value” als Wert und Thresholds, etwa “crit” und “warn”, sofern definiert. Zusätzlich können auch Metadaten von Icinga 2 geschrieben werden, die man aber explizit in der Konfiguration einschalten muss (“metadata”).
Einzelne Metrik abfragen
Im folgenden interessiert uns aber lediglich der Wert der Metrik “load1” als einzelner Wert. Um eine ordentliche Ausgangsbasis zu erhalten, wählen wir den Zeitraum der letzten 3 Stunden. Tip: Es sind relative und absolute Zeitangaben möglich. http://192.168.100.101/render?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.load1.value&height=800&width=600&from=-3hours
Mehrere Metriken zusammenfassen
Man kann diese Abfrage auch erweitern, indem man mehrere Werte gleichzeitig abfrägt: http://192.168.100.101/render?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.{load1,load15,load5}.value&height=800&width=600&from=-3hours
Mehrere Hosts mit der gleichen Metrik abfragen
Eine Abfrage mit verschiedenen Servern für “load15” als Metrik könnte so aussehen: http://192.168.100.101/render?target=icinga2.icinga*op_foreman_local.services.load.load.perfdata.load15.value&height=800&width=600&from=-3hours
Formatierung
Die Darstellung der Daten setzt immer eine &height und eine &width als Parameter voraus. Es ist auch möglich hier Tortendiagramme mit verschiedenen Funktionen für Mittelwerte und Summen aufzurufen.
Man kann die erhaltenen Daten auch als CSV-Werte formatieren und dann beispielsweise mit curl abspeichern. Alternativ kann man sich diese Werte auch direkt im Browser anzeigen lassen.
Wie bereits erwähnt lassen sich die Daten auch im JSON-Format anzeigen. Dies kann wieder über den Browser oder mittels curl erfolgen.
Das folgende Beispiel rendert alle erhaltenen Datenpunkte als JSON-Format:
Um die JSON-Daten in der Console zu visualisieren kann man Zach Holman’s Spark verwenden:
[root@graphite ~]# curl 'http://192.168.100.101/render/?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value&from=-3hours&format=json' | python -mjson.tool | grep ',' | grep -v '\]' | spark
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 3695 0 3695 0 0 230k 0 --:--:-- --:--:-- --:--:-- 240k
▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▃▃▅▅▅▃▃▃▃▅▅███▅▅▃▃▃▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
Conclusio
Das war nur ein kleiner und rudimentärer Überblick was über die Render-API möglich ist. Jedoch bietet sie genügend Anregung um mehr mit Graphite, Icinga 2 und Metriken zu machen. Die Render-APi bietet zudem die Möglichkeit, programmatisch in Scripts darauf zuzugreifen. Mir hat es zumindest Lust auf mehr gemacht und ich denke, dass ich noch weitere Blogposts zu diesem Thema schreiben werde 🙂
Falls ihr nicht warten könnt, hier nochmal der Link zur Doku. Oder ihr schaut einfach mal bei uns in der Graphite-Schulung vorbei und lernt die Render-API am praktischen Beispiel kennen.
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...
Name: Daniel Neuberger Alter: 31 Position bei NETWAYS: Senior Consultant
Ausbildung: Fachinformatiker für Systemintegration Bei NETWAYS seit: April 2017
Was genau gehört zu Deinem Aufgabenbereich bei NETWAYS? Bei NETWAYS bin ich als Senior Linux Consultant für die Beratung und die Umsetzung beim Kunden vor Ort verantwortlich. Meine Themenschwerpunkte sind Icinga2, Elastic, Ansible und Bareos. Ein weiterer Aufgabenbereich ist das Halten von Trainings für Bareos und Icinga2. Was macht Dir an Deiner Arbeit am meisten Spaß?
Wenn ich in immer unterschiedlichen Umgebungen und mit wechselnden Anforderungen mit dem Kunden gemeinsam eine entsprechende Lösung finden und umsetzen kann, dann bringt mir meine Arbeit Spaß. Das Arbeiten mit Menschen ist das was die Arbeit in der IT für mich nicht eintönig werden lässt. Auch ein gutes kollegiales Umfeld ist mir wichtig und steigert den Spaß bei der Arbeit entscheidend. Wie bist Du zur IT und speziell Linux und anderer Open Source Software gekommen?
Zur IT als Beruf kam ich erst spät. Bis zu meiner ersten Lehre mit 21 beschränkte sich der Umgang mit Computern seit meinem 13 Lebensjahr auf das Spielen und dieses für solches entsprechend zu warten und zu rüsten. Dann kam die erste Lehre als käufmännischer Assistent für Informationsdatenverarbeitung und danach die zweite Lehre zum Fachinformatiker wo meine Leidenschaft für Linux entfacht wurde. Das erste größere Open Source Projekt, mit dem ich dann in Berührung kam, war Bacula, was auch der Grundstein für meine nach der Lehre folgenden Consulting-Jahre im Open Source Backup Bereich für Bacula und Bareos war. Welche größeren oder besonders interessanten Projekte stehen zukünftig an?
42 Was machst Du, wenn Du mal nicht bei NETWAYS bist?
Wenn ich nicht bei NETWAYS bin, dann erhole ich mich gerne in der Natur beim Mountain Biken oder beim Arbeiten und Entspannen in unserem Garten hinter dem Haus. Dort stehen auch unsere Bienen, deren Pflege und Zucht ich mich gemeinsam mit meiner Frau widme. Wenn ich dann nicht mal vom Rad gestürzt bin oder die Bienen mich zerstochen haben, gehe ich auch noch auf die Matte und mache etwas Judo. Wie geht es in Zukunft bei Dir weiter? Das ist immer schwer zu sagen. Man kann die Zukunft nicht voraus sagen. Aber man kann sich diese vorstellen und versuchen, diese entsprechend der Vorstellung zu gestalten. In dieser Vorstellung freue ich mich langfristig darauf, bei NETWAYS meinem Beruf im Einklang mit meinem privaten Leben nachgehen zu können.
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...
Genug der Theorie, jetzt geht es ab auf Safari. Ihr verfolgt vielleicht meine 
ruppe Pate stehen. Dabei wurde sich mit den Kindern sportlich mit Spiel und Spaß betätigt, gebastelt und ein Ausflug in den Wildtierpark unternommen. Weitere Highlights waren die große Hüpfburg und die Wasserrutschbahn welche die Freiwillige Feuerwehr für uns am wohl wärmsten Tag bereitstellte.
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.
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.
