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

Autor: Daniel Neuberger

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.

Einfaches verschlüsseltes Backup

This entry is part of 8 in the series Icinga 2 Best Practice

Seit In­kraft­tre­ten der DSVGO  ist Datenschutz in aller Munde. Da wird es einmal Zeit auch den Datenschutz des Monitoring-Servers zu überdenken. Dabei denke ich in diesem Fall nicht an die diversen Härtungsmaßnamen wie SSL für Webserver und Datenbank. Auch Icinga2 erzwingt bei seinen API Verbindungen immer verschlüsselte Verbindungen.

Wo bleiben aber die Backup Dateien? Einmal erzeugt, verlassen sie den Server und liegen dann ‘woanders’. Zum Glück ist es nicht unbedingt nötig, dass man dem File Server voll vertraut. Eventuell ist es günstig die Backup in irgendeine Cloud zu schieben, oder auf den semi public File Server der Unternehmens. Mit Hilfe von GPG kann man seine Daten einfach verschlüsseln und sicherstellen, dass alle Berechtigten sie auch wieder entschlüsseln können. Im folgenden wird erklärt wie man GPG benutzt um ein icinga2 Backup für eine Gruppe von Berechtigten zu verschlüsseln ohne das der private key einer Person den Monitoring Server oder den Backup Server berührt.

1.) gpg Schlüsselpaar erstellen

Am einfachsten benutzt man das CLI tool gpg um den key zu erzeugen. Das sollte man aber auf einem sicheren System machen, z.B. dem eigenen Laptop oder Arbeitsplatz PC. Anschließend wird der öffentliche Teil an einen Keyserver gesendet um den Schlüsselaustausch zu vereinfachen.

$ gpg --full-gen-key
[...]
Ihr Name ("Vorname Nachname"): Max Mustermann
Email-Adresse: max.mustermann@example.org

pub rsa2048 2018-05-31 [SC] [verfällt: 2023-05-30]
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0BA2D8D6
Max Mustermann <max.mustermann@example.org>
$ gpg --keyserver pool.sks-keyservers.net --send-key 0BA2D8D6

2.) Monitoring Server mit Schlüsseln versorgen

Auf dem Server kann man mit Hilfe der gpg group Funktion die Daten mit den public keys einer ganzen Gruppe verschlüsseln. Hierfür muss man diese Gruppe in der ~/.gnupg/gpg.conf anlegen.

$ vim .gnupg/gpg.conf +80
group icingabackup = max.mustermann@example.org john.doe@example.org

Anschließend kann man die public keys vom keyserver laden und ihnen das Vertrauen aussprechen. Nur wenn man allen Schlüsseln “absolutes Vertrauen” ausspricht läuft der encryption Prozess ohne weitere Rückmeldungen ab.

$ gpg --keyserver pool.sks-keyservers.net --search-keys max.mustermann@example.org
gpg: suche nach "max.mustermann@example.org" auf hkp-Server pool.sks-keyservers.net
(1)  Max Mustermann (Test) <mustermann@example.org>
      4096 bit RSA key 0BA2D8D6, erzeugt: 2013-11-18

$ gpg --keyserver pool.sks-keyservers.net --recv-keys 0BA2D8D6
$ gpg --edit 0BA2D8D6 trust
  5 = Ich vertraue ihm absolut

$ gpg --keyserver pool.sks-keyservers.net --search-keys johndoe@example.org
gpg: suche nach "johndoe@example.org" auf hkp-Server pool.sks-keyservers.net
(1)  John Doe (Work email) johndoe@example.org
      4096 bit RSA key 732D8994, erzeugt: 2018-04-20, verfällt: 2020-04-19
$ gpg --keyserver pool.sks-keyservers.net --recv-keys 732D8994
$ gpg --edit 732D8994 trust
  5 = Ich vertraue ihm absolut 

3.) Backup erzeugen und verschlüssen

Das kurze bash Script sammelt Dateien von icinga2 und icingaweb, erzeugt einen mysqldump, packt alles zusammen und verschlüsselt es zum Schluss. Alle Schritte sind im Script kommentiert. Bitte lesen sie unbedingt auch die Hinweise in der icinga2 Dokumentation zu diesem Thema.

#!/bin/bash

DATE=`date +%Y%m%d%H%M`

# Backup script for icinga2 and icingaweb2
# Choose which parts will be backed up.
BACKUP_ICINGA2=true
BACKUP_ICINGAWEB2=true
BACKUP_MYSQL=true
ENABLE_ENCRYPTION=true
DELETE_OLD_FILES=true

# Backup target dir
BACKUPDIR=/data/icinga2_backup

# Backup retention time. Files will be deleted after 14 days
RETENTION_TIME=14

# Icinga2 settings
ICINGA2FILES="/etc/icinga2 /var/lib/icinga2 /etc/default/icinga2"

# Icingaweb2 settings
ICINGAWEB2FILES="/etc/icingaweb2 /usr/share/icingaweb2"
HTTPD_ETCDIR="/etc/apache2"

# mysql settings
MYSQL_DATABASES="mysql icinga icingaweb director"
MYSQL_ETCDIR="/etc/mysql"
MYSQL_DUMP="$BACKUPDIR/tmp/icingaMysqlDump.sql.gz"

# encryption settings
GPG_RECIPIENT=icingabackup

# Ensure Backupdir exists
[ ! -d $BACKUPDIR ] && mkdir -p $BACKUPDIR/tmp

# Add icinga2 folders
if [ $BACKUP_ICINGA2 = true ]; then
  BACKUPFILES+=" $ICINGA2FILES"
fi


# Add icingaweb2 folders
if [ $BACKUP_ICINGAWEB2 = true ]; then
  BACKUPFILES+=" $ICINGAWEB2FILES"
  BACKUPFILES+=" $HTTPD_ETCDIR"
fi


# Add my folders and mysqldump
if [ $BACKUP_MYSQL = true ]; then
  BACKUPFILES+=" $MYSQL_ETCDIR"
  if [ ! -z "$MYSQL_DATABASES" ]; then
    mysqldump --create-options --databases ${MYSQL_DATABASES} | gzip > $MYSQL_DUMP
    BACKUPFILES+=" $MYSQL_DUMP"
  fi
fi

# make archive
TAR=$BACKUPDIR/icingaBackup_${DATE}.tar.gz
if [ ! -z "$BACKUPFILES" ]; then
  # Archive all files and delete mysqldump
  tar -czf $TAR $BACKUPFILES 2> /dev/null && [ -e $MYSQL_DUMP ] && rm $MYSQL_DUMP
fi

# encrypt archive
if [ $ENABLE_ENCRYPTION = true ]; then
  gpg --encrypt --recipient icingabackup $TAR && rm $TAR
fi

# delete everything older than 14 days
if [ $DELETE_OLD_FILES = true ]; then
  find $BACKUPDIR -mtime +$RETENTION_TIME -exec rm \{\} \;
fi

4.) Cron

Um das Backupscript jeden Tag auszuführen kopiert man es auf den Server und trägt es im crontab ein:

root@icingaMaster# crontab -e
  @daily /root/backup_icinga2.sh

5.) Decrypt

Da beim verschlüsseln alle User der Gruppe icingabackup berechtigt wurden kann jeder aus dieser Gruppe die Dateien wieder entschlüsseln.

gpg –output icinga2Backup.tar.gz –decrypt icinga2Backup.tar.gz.gpg

 

Christoph Niemann

Autor: Christoph Niemann

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Azubiprojektwoche 2018

This entry is part 16 of 16 in the series Azubis erzählen

Wir, die 8 NETWAYS Azubis, haben wie jedes Jahr ein kleines Projekt umgesetzt. Und zwar in einer Woche und mit einem bestimmten Budget. Zuerst haben wir uns überlegt, welches Projekt Spaß macht und für uns nützlich sein kann.

Wir haben uns dann für ein Online-Spiel mit Fragen zur Allgemeinbildung entschieden. Über den Nutzen lässt sich streiten, aber das es Spass macht war klar. Anschließend haben wir uns in drei Gruppen geteilt.

  • In der erster Gruppe  (Die Techniker) waren Noah und Philipp mit der Programmierung ( Node.js, socket.io beschäftigt
  • In der Zweiter Gruppe (Content-Gruppe) , waren Nicole, Feu, Lukas, Killian und ich. Wir haben die Fragen und Antworten vorbereitet
  • Ufuk hat sich um Media und Präsentation gekümmert 

Damit die Präsentation vor dem Rest der Firma etwas unterhaltsamer ist, haben wir uns dafür entschieden, eine kleine Party und Präsentation am Ende des Projektes zu machen. Lukas und ich sorgten für Catering und haben für die Kolleginnen und Kollegen gekocht.

Darüber hinaus hat Nicole das Projekt vor den NETWAYS Mitarbeitern präsentiert. Da wir Open Source mögen und damit arbeiten, hat Noah den Quelltext unter diesem Link zur Verfügung gestellt https://github.com/N-o-X/GraddlerWars .

Ein Paar Fotos und eine Video lassen diese schöne und gemeinsame Zeiten nicht vergessen.

 

For a Handful of (Vagrant) Boxes

Servus alle miteinand,

Wer kennt das folgende Szenario nicht? Mit viel neuer Software, welche gerade (manuell) getestet werden muss, dachte ich mir, ich baue mal schnell eine Vagrant Box auf Basis von Debian 9, um Tests unter einem Stretch durchzuführen.

Falsch gedacht !!

Anstelle eines libvirt install auf der Kommandozeile und eines tar-Befehls zum Packen des eigentlichen Box-Images,
musste ich mit einer kleinen Widrigkeiten im Bereich der Netzwerkkonfiguration kämpfen.

Aber eins nach dem anderen.
Fangen wir mit dem Image für die libvirt Maschine an:

virt-install --name=linuxconfig-vm \
--vcpus=1 \
--memory=1024 \
--cdrom=/tmp/debian-9.4.0-amd64-netinst.iso \
--disk size=10 \
--os-variant=debian9

Dies war noch der unproblematische Teil der Installation.
Danach erfolgt in der VM das nachziehen von Berechtigungen für den Vagrant User.

sudo visudo -f /etc/sudoers.d/vagrant
vagrant ALL=(ALL) NOPASSWD:ALL

Hinzufügen des Vagrant public Keys:

mkdir -p /home/vagrant/.ssh
chmod 0700 /home/vagrant/.ssh
wget --no-check-certificate \
https://raw.github.com/mitchellh/vagrant/master\/keys/vagrant.pub \
-O /home/vagrant/.ssh/authorized_keys
chmod 0600 /home/vagrant/.ssh/authorized_keys
chown -R vagrant /home/vagrant/.ssh

Wenn man nicht so Wach war, um rechtzeitig im Installationsmenü schon SSH mitzuinstallieren, muss es per Hand nachgeholt werden:

sudo apt-getinstall -y openssh-server
sudo nano /etc/ssh/sshd_config
AuthorizedKeysFile %h/.ssh/authorized_keys

Danach kann das System so präpariert werden, wie man es benötigt.

Das Image der VM noch verkleinern und in box.img umbenennen:

qemu-img convert -c -O qcow2 debian9.qcow2 small.qcow2
mv small.qcow2 box.img

Alles handlich verpacken und dem Vagrant Box Store hinzufügen:

tar czvf debian9.box ./metadata.json ./Vagrantfile ./box.img
vagrant box add --name debian9 debian9.box

Hier allerdings fingen meine Probleme an.
Nach dem Packen der Box, dem Hinzufügen zum Boxstore und einem Erwartungsvollen “vagrant up” erhielt ich “==> default: Waiting for domain to get an IP address…”, was zu keinem Erfolg führte und ich wahrscheinlich jetzt immer noch warten würde.

Nach einem erneuten Hochfahren der VM mit dem virt-manager und nachschauen, ob das network device fehl konfiguriert ist, konnte ich keinen Fehler feststellen.

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

Gefühlte Jahrtausende von Recherche später, wurde mir folgendes klar:

Debian hat in neuen Versionen eine Änderung der Device-Namen vorgenommen.
Vagrant wartet vergeblich auf “eth0”, weil ein network device Namens “ens21” existiert, wenn ich die VM mit “vagrant up” starte.

Also zurück in die VM und das folgende Kommandos abgesetzt:

sudo nano /etc/default/grub

Im Editor dann folgende Anpassungen vornehmen:

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

Damit das auch greift, muss abschließend die Konfiguration für den Grub-Bootmanager neu erstellt werden:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Reboot. “vagrant up” und Tada … Spannung Trommelwirbel => Tusch ! Die VM erhält eine IP und startet wie man es schon von Anfang an erwartete.

Ich hoffe ich konnte damit den ein oder anderen vor dem Verlust von allzuviel Lebenszeit bewahren.

Ein sonniges WE wünscht

David Okon

Autor: David Okon

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

Ausbildung bei Netways im Software-Development

This entry is part 1 of 16 in the series Azubis erzählen

Worum gehts denn heute?

Wie läuft eigentlich so eine Ausbildung bei Netways ab?
Was wird geboten?
Was wird erwartet?
Wäre das vielleicht was für mich?

Auf diese Fragen werde ich versuchen heute eine Antwort zu geben 🙂


Name: Jennifer Mourek
Ausbildungsberuf: Fachinformatiker für Anwendungsentwicklung
Abteilung: Development
Lehrjahr: 2

Rückblick:

Die Hälfte meiner Ausbildung ist schon vorbei, seit anderthalb Jahren bin ich nun hier in der Netways-Family.
Meinen letzten Bericht über meine Ausbildung hatte ich ziemlich zu Anfang geschrieben, voller Begeisterung und nur einen Monat nachdem ich bei Netways angefangen hatte.

Seitdem hat sich viel getan aber mein Enthusiasmus ist kein bisschen abgeklungen!

Mein Werdegang:

Gestartet habe ich mit einem eher kleinen Wissensschatz: Ich wusste wie man einen Computer bedient, war der deutschen und englischen Sprache mächtig und in der Lage simple Skripts zu schreiben. Das wars aber auch schon.

Meiner Einarbeitungsphase bestand aufgrund meiner eher mangelhaften Vorkenntnisse der IT Welt aus etwa 2 Monate intensiven Coaching meiner neuen und Gott seis gedankt, sehr geduldigen Kollegen.
Man hat mich langsam, Schritt für Schritt, an das Leben als Entwickler herangeführt.

DAY 0
Zuerst durfte ich ein bisschen skripten und zwar einen einfachen kleinen Parser, der nützliche Statistiken aus .po files auslesen sollte basteln.
Diese Statistiken sollte ich dann in eine “schöne” CLI Ausgabe weiterverarbeiten damit wir einen besseren Überblick über den Status unserer Lokalisation in IcingaWeb2 bekommen.

ZWEI MONATE SPÄTER…
Danach gings an tatsächliche Arbeit mit Web2, das heißt: Bugs fixen, Features entwickeln, Module basteln und alles was dazugehört.
Damit wurde ich dann endgültig in die große weite Welt (oder auch die Untiefen) der IcingaWeb2 Codebase geworfen.

FÜNF MONATE NACH BEGINN
Ich hatte noch einige weitere kleine Projekte, die sich zum Beispiel mit dem CI Runnen von Gitlab, oAuth, Webforms, den von uns genutzten Frameworks und vielem mehr.

NEUN MONATE SIND VORBEI!
Mein erstes Projekt bei dem ich teil des Teams war, war die komplette Renovation von Icinga Exchange.
Die Wahl von Frameworks und Tools, Reverse Engineering, Code-Qualität und sinnvolle Strukturierung von Grund auf bei größeren Projekten waren hierbei der Fokus.

START DES ZWEITEN AUSBILDUNGSJAHRES
Inzwischen habe ich durch die flexible und projektorientierte Struktur in der Development Abteilung schon mit den meisten Kollegen zusammen an einem Projekt getüftelt und gelernt sowohl im Team, als auch eigenständig zu arbeiten.
Die Projekte waren bisher immer sehr Abwechslungsreich und es jeder profitiert von dem Wissen der anderen Teammitgliedern.
(Für mich ist es immer ein besonders gutes Gefühl, wenn ich deutlich erfahreneren Kollegen etwas Neues zeigen kann ^-^)

Vor einigen Wochen hat für mich auch die Abteilungs-Rotation begonnen.
Die erste Station war Administration und bald geht es weiter mit Events, Sales, Managed Services und Support.
Eine sehr interessante Sache mal zu sehen, was in den anderen Abteilungen alles so geleistet wird!

Aus reinem Interesse hat sich inzwischen ein relativ solides Netz an Wissen entwickelt.
Die regelmäßigen Gesprächen mit meinen Ausbildungsbeauftragten (Ausbilder und Teamleads) war es mir möglich mitzubestimmen auf welchen Gebieten ich mich spezialisieren will und mich durch Feedback ständig zu verbessern.
Ich blicke auch gerne nach vorne und freue mich darauf noch lange Zeit mit meinen Freunden und Kollegen zusammenzuarbeiten!

Was wird von unseren Azubis erwartet?

Die wichtigsten Eigenschaften die man mitbringen sollte wenn man bei uns in eine Ausbildung starten will wären Folgende:

  • Offenheit
  • Teamfähigkeit
  • Kontaktfreudigkeit
  • Technisches Interesse
  • Wissbegierde

Es uns super wichtig, dass sich die neuen Kollegen gut bei uns einfinden können und zu uns passen,
einfach weil wir viel in sich ständig neu durchmischenden Teams arbeiten.
(Unsere Türschildchen stimmen praktisch nie)

Man bekommt die Chance, sehr sich schon während der Ausbildung um seine eigenen, kleinen Projekte zu kümmern.
Ein gewisses Verantwortungsbewusstsein ist von daher auch nicht schlecht.
Aber keine Sorge, es ist immer jemand da, auf den man mit Problemen zukommen kann, man steht definitiv nie alleine da 🙂

Was dein technisches Wissen angeht: Das wichtigste ist ehrliches Interesse.
Deinem Stand und deinen individuellen Fähigkeiten entsprechend werden dir unsere Ausbilder zu dir passende Aufgaben geben und sich so um dich kümmern, dass dein Potenzial optimal genutzt wird.
Solange du dich für den Job begeistern kannst und die Motivation hast zu lernen kommt der Rest wie von selbst!

Das Umfeld:

Durch den familiären und freundschaftlichen Umgang mit allen Kollegen und den zahlreichen Firmen-Unternehmungen fühlt man sich auch sofort gut aufgehoben.

In einem typischen Netways Jahr kann man mit diesen Events wie diesen (und noch vielen mehr) rechnen:  

Ich persönlich versuche alles mitzunehmen, was irgendwie Platz findet im Terminkalender.
Bisher hatte ich immer super viel Spaß und habe viele neue Freundschaften geschlossen, sowohl innerhalb der Firma und mit Besuchern unserer Veranstaltungen ^-^

(Manch Einem sind es auch ein paar zu viele Events, aber das ist wohl Geschmackssache und der Großteil der Veranstaltungen sind ja optional 😉 )


tl;dr
Ausbildung bei Netways: fordernd, lehrreich, spaßig und eventful.
Bei Interesse bewirb dich hier!

Jennifer Mourek

Autor: Jennifer Mourek

Jennifer (von eigentlich jedem nur "Feu" genannt) verbrachte ihre Kindheit im schönen Steigerwald und kämpfte sich bis zum Abitur durch die Schule. Seit September 2016 unterstützt sie nun im Rahmen ihrer Ausbildung zum Fachinformatiker die Development Abteilung bei Netways und widmet sich dort dem Web Development. Ihre Freizeit verbringt sie hauptsächlich in den virtuellen Welten von 'Dota 2' und diversen anderen Games, an der Kletterwand in der Boulderhalle oder damit ihren Freunden und Kollegen auf die Nerven zu gehen.

Noob vs. Icinga 2

Nachdem unser Michael Friedrich letzte Woche einen Blog-Post zum 9. Icinga Geburtstag auf icinga.com veröffentlicht hat, fängt man schon mal an, über die eigenen ersten Schritte mit dem Icinga 2 Stack nachzudenken. Vor allem, wenn man auf einem Live-System mal wieder über etwas aus der Anfangszeit stolpert.

 

Eines meiner ersten Aha!-Erlebnisse war recht klein, jedoch wurde mir dann versichert, dass da auch gestandene User bzw. Admins darüberstolpern. Kern der Frage war damals: “Warum geht dieser *biep* http-check nicht?!” Als Symptom zeigte sich, dass unserem Check der Zugriff verweigert wurde – und das, obwohl doch alle Permissions korrekt gesetzt waren. Da grübelt und googlet der Junior System Engineer erstmal eine Zeit lang. Um das Verfahren hier abzukürzen – es gibt folgende Möglichkeiten, das Problem anzugehen:

Der Grund liegt darin, dass der Check durch den Parameter –expect einen String mit dem Returnwert 200 als Default erwartet. Von daher kann man

  • als Quick’n’Dirty Lösung ganz einfach eine leere Datei mit dem Namen index.html im entsprechenden Verzeichnis angelegt werden
  • den String nach –expect auf einen sicher zu erwartenden Wert setzen, z. B. 302.
  • mit –url einen Pfad angeben, der geprüft werden soll, z. B. /start/menu

Auch schön war der Punkt, an dem man verstanden hat, was es mit dem Parameter command_endpoint auf sich hat – und man plötzlich merkt, dass unterschiedliche Festplatten z. B. auch unterschiedliche Füllstände aufweisen. Genauso faszinierend ist es natürlich auch, dass man durch Apply Rules viele Services weitläufig ausrollen oder umgekehrt auch einschränken kann.

Um nun abschließend einen unserer NETWAYS Consultants zu zitieren: “Das Kommando icinga2 daemon -C sollte man jedem neuen User irgendwohin tätowieren!”

Als Fazit aus den letzten zwei Jahren mit Icinga 2 kann ich ziehen, dass einem der Einstieg recht gut und schnell gelingt – egal, ob es sich um das Aufsetzen, die Wartung oder die täglich Nutzung handelt. Wer sich vor allem von letzterem gerne selbst überzeugen möchte, kann bei den NETWAYS Web Services in unserem kostenfreien Testmonat sowohl einen Icinga 2 Master als auch Satellite starten. Wer sich gerne tiefer in die Materie einarbeiten möchte, kann sich auf icinga.com schlau machen. Dort ist nicht nur die offizielle Dokumentation zu finden, sondern auch Termine zu Trainings und Events. Sehr zu empfehlen ist auch die überarbeitete Auflage des Buches Icinga 2: Ein praktischer Einstieg ins Monitoring von Lennart Betz und Thomas Widhalm.

Bildquelle: https://memegenerator.net/instance/40760148/jackie-chan-dafuq-is-wrong-with-ur-icinga-checks

Nicole Lang

Autor: Nicole Lang

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest Bücher und zockt auch mal gerne.