Icinga2 GitLab Health Check

GitLab

Neulich hatten wir bei einigen GitLab Updates auf die neueste Version das Problem, dass die Dienste nach dem Update zwar korrekt alle wieder gestartet wurden und daher unser alter Monitoring Check “Service: gitlab” den Status “Gitlab OK: All services are running!” zurückgeliefert hat, auch der Check “Service: http git.netways.de” “HTTP OK: HTTP/1.1 200 OK” geliefert hat, und daher hat ohne manuelle Prüfung niemand vermutet, dass im Hintergrund doch etwas schief gelaufen war (z.B. die Datenbank Migration während einem Update, oder ein vergessenes skip-XXX File im /etc/gitlab Verzeichnis).

Auch wenn man das Update direkt auf der command line ausgeführt hat, konnte man in der abschliessenden Meldung nicht sehen, ob noch alles o.k. ist.

Festgestellt hat man das dann erst, wenn man sich in der GitLab Admin Area unter “Health Check” den Status angesehen hat.

Unten ein Beispiel wie es aussieht, wenn alles i.O. ist (Zur Info: Die Beispiel URL und Token gibt es nicht):

GitLab Status

D.h. ein neuer Check musste her, und den gibt es auch direkt bei GitLab zum Downloaden unter:

https://gitlab.com/6uellerBpanda/check_gitlab/blob/master/check_gitlab.rb

Der alte Check lief dabei direkt auf den einzelnen GitLab Hosts. Das war mit dem neuen Check allerdings ein Problem, weil er als Voraussetzung Ruby >2.3 hat, und wir z.B. noch einige Hosts unter Ubuntu Trusty betreiben.

Deshalb wird der neue Check direkt auf dem Monitoring Server (auch Ubuntu Trusty) ausgeführt, der zu diesem Zweck zusätzlich per rvm mit einem z.Zt. neuen Ruby 2.5.1 ausgestattet wurde, wobei im Ruby Skript das Shebang leider hardcoded eingetragen werden musste, weil es (zumindest unter Trusty) nicht anders funktioniert hatte (ohne grösseren Aufwand und vielen Änderungen an anderen Systemdateien):

#!/usr/local/rvm/rubies/ruby-2.5.1/bin/ruby

Nachdem die Token zum Zugriff im Bild oben seit einigen GitLab Versionen deprecated sind zugunsten einer IP Whitelist, hat das den Deploy des Checks zusätzlich erleichtert.

Der Aufruf des Checks sieht dann z.B. so aus:

root@icinga2-server:~# check_gitlab.rb -m health -s https://gitlab.netways.de -k
OK - Gitlab probes are in healthy state

Damit das dann auch funktioniert, muss auf der entfernten GitLab Instanz noch die IP Whitelist unter /etc/gitlab/gitlab.rb eingetragen werden:

gitlab_rails['monitoring_whitelist'] = ['127.0.0.1/8','10.XX.XX.XX/24']

Am besten checkt man natürlich nur über ein internes Netz, wie oben im Beispiel angegeben.

Das ganze kann man auch über ein GitLab Puppet Modul realisieren, indem man die Whitelist über Hiera oder Foreman verteilt:

Beispiel Hierarchie im Foreman:

gitlab:
    gitlab_rails:
      monitoring_whitelist:
      - 127.0.0.1/8
      - 10.XX.XX.XX/24  
Stefan Gundel

Autor: Stefan Gundel

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.

Icinga, Nagios, Naemon, OMD, Check_MK, Op5, Centreon oder Shinken – Teil III

Nach ca. 1,5 Jahren dachte ich mir heute das es mal wieder an der Zeit wäre meinen Monitoring-Tool-Vergleich zu aktualisieren. Schließlich musste ich nach 30 Minuten Recherche feststellen, dass mich die Rohrkrepierer der vergangenen Jahre nicht im Stich gelassen haben und weiter mit einem hohen Grad an Inaktivität glänzen. Auch die anderen Projekte blieben im Groben meiner Einschätzung treu und so war ich schon kurz davor meinen Texteditor zu schließen.

Beim Schließen eines der Browser-Tabs bin ich dann jedoch auf ein schönes Video meiner Freunde von Nagios gestoßen und das musste ich einfach verarbeiten. Dazu aber erst am Ende mehr, denn ihr sollt das Ergebnis meiner Arbeit ja auch erstmal lesen.

Wie auch in den vergangenen Posts behandle ich hier nur die Systeme, welche aus dem ursprünglichen Nagios-Ökosystem entsprungen sind. Wer es gerne etwas breiter haben möchte, dem sei der Besuch der diesjährigen OSMC besonders ans Herz gelegt. Noch nie hatten wir so ein vielfältiges und umfangreiches Programm wie 2018 und freuen uns auf viele bekannte aber auch uns unbekannte Referenten. Auf jeden Fall anmelden und dabei sein.

Los geht’s mit einem gekürzten Update und Überblick der aktuellen Landschaft:

Shinken: Im Master gab es dieses Jahr ganze 6 commits und man hat irgendwie den Eindruck das die Luft bei den Freunden etwas raus ist. Auch auf der Enterprise Website sind die letzten News vom April 2016 und ich würde sagen das Ding ist tot. Ich kann mich auch an einige Tweets erinnern, in denen die Entwickler selbst aufeinander los gegangen sind, kann sie jedoch aktuell nicht finden.

Fazit: Ich werde es in Zukunft nicht mehr weiter betrachten, da es sich mit Shinken etwa so verhält wie mit Bratwurstgehäck. Ne gute Idee, wenn es frisch ist, jedoch sollte man die Finger davon lassen wenn es zu lange rumliegt.

Op5: Die Kollegen aus Schweden sind seit Jahren immer fleißig am Werk und seitdem sie Naemon an Stelle von Nagios verwenden, fokussieren sie sich noch mehr auf ihre beiden Hauptkomponenten Merlin und Ninja. Diese werden auch ordentlich als Open Source Projekte und sehr transparent vorangetrieben. Klar ist natürlich das Op5 selbst einen anderen Revenue-Stream hat und mit dem veredelten Produkt Op5 Monitor auf dem Markt aktiv ist. Was mir nicht eingeht ist ihr Logging Produkt Op5 Log Analytics. Natürlich verstehe ich den geschäftlichen Hintergrund und das Ziel dem eigenen Kunden eine Komplettlösung aus einer Hand zu verkaufen. Warum man bei Op5, ähnlich wie bei Nagios, glaubt die Elastic-Lösungen nochmal mit einem eigenen Logo und ergänzendem Flickwerk versehen zu müssen ist mir schleierhaft. Da würde es soviel andere Dinge geben, mit denen sich die Jungs schnell ein Alleinstellungsmerkmal schaffen könnten, aber sie werden schon ihre Gründe haben. UPDATE: Ich habe gerade gesehen das Op5 erst vor wenigen Tagen von der ITRS Gruppe übernommen worden ist. Bleibt also spannend, was die neue Mutter, welche bereits ähnliche Lösungen im Portfolio, daraus macht.

Fazit: Ich denke noch immer, dass Op5, besser gesagt Op5 Monitor, eine solide Unternehmenslösung ist, mit der man sehr viele Anwendungsfälle lösen kann. Wie bei allen Veredlern ist der Schritt über den Standard hinaus immer etwas schwieriger, aber zugegeben braucht das auch nicht jeder. Open Source ist es natürlich nur bedingt, da die Kernkomponenten zwar offen entwickelt werden, aber die fertige Lösung natürlich der USP von Op5 und somit kostenpflichtig ist.

Check_MK: Erstmal Gratulation zur neuen Website und dem Rebranding! Nachdem ich dort schon einige Monate nicht mehr war, ist mir das als erstes positiv aufgefallen. Beim Rest scheint sich im Großen und Ganzen nicht viel verändert zu haben. Das will jetzt nicht heissen das die Kollegen aus München nichts machen, aber ich kann einfach nichts finden. Auf der Website wurde die Screenshot-Section bereits aktualisiert, aber das Demo System hat zumindest noch das alte Design. Auch das Changelog gibt mir keinen Aufschluss auf grundlegend neues, sondern listet überwiegend Bugfixes. Falls jemand der es besser weiß die entsprechenden Infos für mich hat werde ich es gerne nachtragen. Ich hab mir noch ein paar Videos von der Check_MK Konferenz reingezogen, konnte aber nichts finden, was mir jetzt besonders aufgefallen ist.

Fazit: Wenn ich mir ansehe, was die Kollegen so voran treibt, verhält es sich im Fazit ähnlich wie bei Op5. Wenngleich mir bei Op5 das Webinterface besser gefällt, vermute ich das Check_MK die technisch stärkere Lösung ist, da sie sich den käuflichen Varianten auch vom Nagios-Core befreit hat und schon seit vielen Jahren seinen CMC verwendet. Auch gibt es eine API, aber auch Check_MK ist aus meiner Sicht nicht für Automatisierung gemacht, sondern verfolgt einen ganzheitlichen und integrierten Ansatz. Check_MK kümmert sich selbst um Verteilung und Installation seiner Software und zielt auf einen Markt ab, der eine vollintegrierte Lösung haben möchte. Richtig sinnvoll geht das dann aber nur mit der Enterprise- oder Managed-Service Edition.

OMD: Die Freunde von Consol schrauben weiter erfolgreich an ihrem OMD Labs (für welches wohl im September die nächste Version ansteht). Die Zusammenarbeit mit Check_MK hat sich ja schon vor einiger Zeit aufgelöst und so sind aus dem ehemaligen Gemeinschaftsprojekt nun zwei Lösungen entstanden. OMD Labs ist der eigentlichen Idee, nämlich unterschiedlichsten Komponenten für den User einfach zusammenzuschnüren, treu geblieben und sehr aktiv. Besonderes Augenmerk hat man in den letzten Versionen dem Thema Prometheus und der besseren Integration geschenkt. Nach wie vor werden verschiedenen Monitoring-Cores unterstützt und unter Thruk als zentraler Oberfläche zusammengeführt.

Fazit: Wer keine Lust, keine Zeit oder einfach keine Not hat, einzelne Monitoring-Komponenten zu installieren und anschließend zu konfigurieren, dem möchte ich OMD Labs ans Herz legen. Es ist eine solide und offene Open Source Lösung, welche kontinuierlich weiterentwickelt wird und stark vom Service-Know der beteiligten Personen profitiert. In Richtung Management-Sichten, Reporting usw. hat Check_MK mit Sicherheit mehr zu bieten, aber eben erst in den bezahlten Versionen. Hinzu kommt, dass es um OMD herum einen Community gibt und die ehemalige Check_MK Community in andere Kanäle abgewandert ist. Wer übrigens alternativ zu RRD Graphen will, kann das mit der Check_MK Raw Edition ebenfalls nicht machen und sollte gleich OMD nehmen.

Naemon: Sowohl OMD Labs (“Hauptcore”) als auch Op5 setzen auf Naemon als Monitoring-Engine. Neben Sven Nierlein schrauben auch einige andere Entwickler an Naemon und es gibt regelmäßig neue Versionen. Bei den Änderungen scheint es sich jedoch eher um kleinere Bug-Fixes und Änderungen zu halten und es sieht nicht so aus, als ob grundlegende Änderungen erfolgen. Grundsätzlich ist das aus der Perspektive der oben genannten Hauptnutzer auch verständlich, da sie die fehlenden Features des Cores in den Frameworks drum herum übernehmen. Beispiel wäre hier API oder direkt Graphing-Integration. Naemon wiederum besteht auch aus dem Core, Livestatus und Thruk als Ersatz für die alten Nagios-CGIs. Aus meiner Sicht ist nicht zu erwarten das hier groß etwas passiert, jedoch können User im Vergleich zu Shinken durchaus davon ausgehen, das auftretende Issues bearbeitet werden und zeitnah in eine Release fließen.

Fazit: Ich persönlich wüsste nicht warum man Naemon standalone einsetzen sollte und würde Interessenten gleich zur Verwendung von OMD Labs raten. Dort bekommen sie zum einen die notwendigen Add-ons mit dazu und können gleich das vorhandene Site-Management nutzen. Als simples Monitoring im kleinen Umfeld mag es aber durchaus seinen Dienst verrichten. Wer am Core selber etwas mehr Features benötigt ist mit Icinga2 sicherlich besser bedient, muss sich dann aber natürlich mit einer anderen Konfigurationssprache auseinandersetzen.

Centreon: Die französischen Kollegen blieben bisher in meinem Vergleich etwas unbeachtet. Das liegt in der Hauptsache einfach daran, dass wir und ich persönlich sehr wenig damit zu tun haben und Centern selten in anderen Umgebungen antreffen. Centreon (früher CES Standard) ist fully Open Source und steht samt Modulen und Webinterface auf der Website zum download bereit. Auch in ihrem Git sind die Kollegen recht aktiv und schrauben an den eigenen Komponenten, welche für die darauf aufbauenden Enterprise-Komponenten benötigt werden. Die Vergleichsmatrix zwischen Nagios und Centreon macht eigentlich auch einen sehr guten Eindruck, jedoch bin ich nicht dazu gekommen das System zu installieren und einem fachlichen Test zu unterwerfen.

Fazit: Ehrlich gesagt weiß ich zu wenig um deren aktuellen Entwicklungsstand um wirklich ein Fazit abzugeben. Um einen Eindruck zu gewinnen empfehle ich den Besuch des Demo-Systems, was wirklich solide aussieht und viele Features mitbringt, welche Op5 oder Check_MK nur gegen Einwurf von Münzen zur Verfügung stellen. Ich freue mich, dass Centreon dieses Jahr auch wieder auf der OSMC dabei ist und werde die Gelegenheit nutzen mit den Damen und Herren zu sprechen und mir das System zeigen zu lassen. Wenn ein Leser dieses Posts noch ein paar Anregungen dazu hat, dann bitte her damit.

Icinga: Im letzten Jahr ist nach außen sehr viel in den Modulen, wie bspw. dem Director passiert, welcher vor einigen Wochen in der Version 1.5 erschienen ist. Wir bereits vor zwei Jahren angekündigt arbeitet das Team gerade mit Hochdruck an der IcingaDB. Mit ihr wollen die Entwickler auch der letzten verbliebenen Nagios-Komponente (zumindest Schema und Funktionsweise) leb wohl sagen. Dabei handelt es sich aber nicht nur um ein neues DB-Schema um Auswertungen komfortabler zu gestalten. Es wird eben auch eine strikte Trennung zwischen Persistenten und Volatile Daten geben, um Millionen an Check sowohl im Core als auch im Web-Interface zu ermöglichen. Letztgenanntes bekommt eben dann auch ein neues Monitoring-Modul, welches ebenfalls an die neue Architektur angepasst werden muss. Da hier ein Großteil der verfügbaren Entwickler-Ressourcen reingesteckt wird, sind Themen wie NoMa und auch die Mobile-App etwas in Verzug geraten. Vergessen sind sie aber nicht, keine Sorge. Was Icinga stark macht ist der hohe Komfort bei der Integration anderer Lösungen und die Unterstützung einer Vielzahl von Konfigurationsmanagement-Lösungen. Gerade in größeren Umgebungen spielt Icinga hier seine Stärke aus. Auf Basis der neuen Architektur wird dann auch dem Thema Micro-Services eine stärkere Beachtung zukommen, da hier oft sehr volatile Anwendungen überwacht und das Monitoring quasi sekündlich an die neuen Rahmenbedingungen angepasst werden muss.

Fazit: Icinga ist dann das richtige Werkzeug, wenn man die am Markt befindlichen Lösungen für Metriken, Logmanagement, Konfigurationsmanagement usw. nach dem best-of-breed Ansatz kombinieren will. Der Anwender muss hier definitiv ein bisschen mehr Hand anlegen, um die unterschiedlichen Lösungen zusammenzubauen, profitiert dann aber auch von der Flexibilität, die er sich damit erarbeitet hat.

Das Fazit hat sich im Vergleich zum Vorjahr lustigerweise nicht geändert, wenngleich wir in vielen Punkten in Richtung einer besseren Integration und leichteren Installation arbeiten. Aber dazu gibt es in den nächsten Monaten noch vieles zu erzählen 🙂

Nagios: Als die Nagios-Konferenz in den USA mangels Teilnehmer im letzten Jahr abgesagt wurde hatte ich wirklich Mitleid. Es ist mir ein Rätsel, wie man ein Produkt und seine Community, welche im Übrigen für alle oben stehenden Produkte verantwortlich ist, an die Wand fahren kann. Nagios hatte einst alle Zügel in der Hand und die Entwickler haben nur so um die Möglichkeit der Mitarbeit gebettelt. Für die Benutzer war es das Beste was passieren konnte und so steht heute eine Produkt- und Ideenvielfalt zur Verfügung, welches es ohne Versagen von Nagios nicht gegeben hätte. Open Source at its finest würde ich sagen. Wir blicken sicherlich auf eine schwierige gemeinsame Vergangenheit zurück, aber letztendlich ist der Markt groß genug und ich gönne jedem, der hart daran arbeitet, seinen Erfolg. Bei Recherche der Nagios-Website sind mir dabei drei wesentliche Sachen und Neuerungen aufgefallen:

  • Auch Nagios hat sich vor vielen Jahren versucht die unterschiedlichen Projekte zu vergleichen und scheinbar haben sie diese Vergleiche auch ab und an aktualisiert. Die Vergleiche sind leider für jedes andere Produkt absolut lächerlich und entbehren jeder Grundlage. Dacia vergleicht sich ja in der Regel auch nicht mit Audi.
  • Ich hab mit der Demo ihres Log-Servers, Produktname Nagios Log Server, etwas gespielt und finde das Produkt eigentlich nicht schlecht. Wie bei Op5 stellt sich mir zwar die Frage ob man mit einer reinen Open Source Variante wie Elastic(Stack) oder Graylog nicht besser fährt, aber ich habe den Eindruck das man sich bei dem Produkt Mühe gegeben hat.
  • Am Core wird eigentlich nach wie vor “nichts” gemacht. Zwar gab es im letzten Jahr eine Enhancement-Release (4.4.0), aber das war eher auch nur Kleinigkeiten. Wie weit Nagios und Naemon da in der Zwischenzeit auseinander sind kann ich schwer beurteilen, ich habe aber nicht den Eindruck, dass es signifikante Unterschied. Im Vergleich zu den anderen Veredlern hätte Nagios ja eigentlich alles in der Hand, aber scheinbar keinen Druck, Not oder auch Know-how.

Fazit: Es ist mir schleierhaft, wie und warum Nagios sich noch immer gegen andere Veredler wie Naemon oder Op5 durchsetzen kann. Klar haben sich alle anderen über die letzten Jahre vom Nagios-Core entkoppelt und sind nicht mehr auf Nagios angewiesen. Auf der anderen Seite sind alle anderen wesentlich innovativer, wenn es um das komplette Produkt geht.

Das oben angesprochene Highlight ist für mich jedoch das Nagios-Produkt-Video, welches ich auf der Landing-Page gefunden habe. Das Video mit dem Titel “Nagios – Customers First” bewirbt so ziemlich jede Branche auf dem Planeten, sagt aber ca. nix über Monitoring aus. Aber unterhaltsam ist es, daher bitte sehr:

 

Für Feedback bin ich gerne offen und wenn sich jemand ungerecht behandelt fühlt, möge sie oder er es mich bitte wissen lassen. Wenn es darauf hin etwas zu korrigieren oder klarzustellen gibt, werde ich das auch machen.

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

Einfaches verschlüsseltes Backup

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.

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.

Be a speaker at the OS Monitoring Conference this year!

 

We have some strong points for you to be a speaker at the Open Source Monitoring Conference 2018.

  1. Add new research to your list – Talk about your newest findings in development at the OSMC.
  2. Increase your productivity –  Writing a paper with your findings, tips, tricks and skills increases your number of activities.
  3. Be the OS Monitoring Agent of Change! – Do you think your ideas and thoughts can bring positive change to the OS community? If you do, the Open Source Monitoring Conference is the perfect platform for you to share your ideas with the community.
  4. Monitor your social life – Meet up with fellow experts and enjoy the opportunity to exchange and reflect with other OS monitoring enthusiasts.

Let’s do this! Submit your talk here. 

Keya Kher

Autor: Keya Kher

Keya hat im Oktober 2017 ihr Praktikum im Marketing bei NETWAYS gestartet. Seitdem lernt sie fleißig deutsch und fühlt sich bei NETWAYS schon jetzt pudelwohl. Sie hat viele Erfahrungen im Social Media Marketing und ist auf dem Weg, ein Grafikdesign-Profi zu werden. Wenn sie sich gerade nicht kreativ auslebt, entdeckt sie die Stadt oder schmökert im ein oder anderen Buch. Ihr Favorit ist “The Shiva Trilogy”.

April Snap 2018 > OSDC, OSCamp- Speakers, NETWAYS Web Services, Slack- Notification, WordPress

Hello May!! In April we expressed our gratitude to our OSDC sponsors for their support! Nicole reviewed GitLab security update. Jean offered solutions for a personal Linux backup. Markus promised more content for NETWAYS’ Graphing training. Marius announced NETWAYS Web Services: WordPress now up and running!

Keya asked if you are going to the OSDC Berlin!! And then she urged you to Join the OSCamp on June 14! Florian talked about Was kann eigentlich CSS-Grid? Max taught us how to Synchronize configuration with lsyncd. Then we reported on NETWAYS` Support to film project of TH Nuremberg. Marius brought us up to speed on Running Icinga in NWS with Slack notifications.

Philipp talked about Hard disk benchmark with bonnie ++Pamela told you to get ready for the OSDC 2018 Berlin! Marius shared his thoughts on Anpassungen der Nextcloud Login Seite werden nicht geladen. Keya announced the OSCamp 2018 – Speakers Line-up.

Keya Kher

Autor: Keya Kher

Keya hat im Oktober 2017 ihr Praktikum im Marketing bei NETWAYS gestartet. Seitdem lernt sie fleißig deutsch und fühlt sich bei NETWAYS schon jetzt pudelwohl. Sie hat viele Erfahrungen im Social Media Marketing und ist auf dem Weg, ein Grafikdesign-Profi zu werden. Wenn sie sich gerade nicht kreativ auslebt, entdeckt sie die Stadt oder schmökert im ein oder anderen Buch. Ihr Favorit ist “The Shiva Trilogy”.