pixel
Select Page

NETWAYS Blog

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

Wie überwache ich eine Cluster-Applikation in Icinga 2?

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.
 

Plugin-Skript

#!/bin/bash
#
# License: GPLv2, Copyright: info@netways.de NETWAYS GmbH
#
#
plugin_dir=${0%/*}
VIP="$1"
vip_exists=`ip a|grep " inet ${VIP}/"`
echo $vip_exists
shift
command="$1"
shift
if [ ! "$vip_exists" ]; then
  echo "YES! VIP down & I'm STANDBY" && exit $OK
fi
exec ${plugin_dir}/${command} "$@"

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.

object CheckCommand "vip-disk" {
  import "plugin-check-command"
  import "disk"
  command = [ PluginDir + "/check_vip_app", "$app_vip$", "check_disk" ]
}
object CheckCommand "vip-procs" {
  import "plugin-check-command"
  import "procs"
  command = [
   PluginDir + "/check_vip_app",
   "$app_vip$",
   "check_procs"
  ]
}
object CheckCommand "vip-logfiles" {
  import "plugin-check-command"
  import "check_logfiles"
  command = [
    PluginDir + "/check_vip_app",
    "$app_vip$",
    "check_logfiles"
  ]
  timeout = 1m
}

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

Die NETWAYS klatscht! Bloß für wen?

1min.care

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

Elastic{ON} 2018 Reisebericht und Rückblick

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

 

Keynote und Party

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

 

1 Konferenztag

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

Elasticsearch

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

Kibana

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

Beats

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

Logstash

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

Party

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

 

2 Konferenztag

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

Talks

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

Unsere Entdeckung

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

Schön wars…

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

Daniel Neuberger
Daniel Neuberger
Senior Consultant

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

Trainings

Web Services

Events