pixel
Select Page

NETWAYS Blog

Schulungsnotebooks in neuem Gewand

In diesem Jahr konnten wir endlich wieder mehr Vor-Ort Trainings durchführen als in den vergangenen Jahren und sogar vereinzelte Inhouse-Trainings bei Kunden waren möglich. Bisher haben wir bei unseren Präsenztrainings oder auch -workshops auf Notebooks mit CentOS 7 gesetzt, und zwar deshalb weil die automatische Provisionierung durch unseren sog. “Event”-Foreman in Kombination mit Puppet seit langer Zeit gut funktioniert.

Recovery-Eintrag

Da es in der Vergangenheit für die Kollegen allerdings sehr aufwändig war die Notebooks nach jedem Training wieder ins Büro zu schleppen, sie zu verkabeln und sie dann von Grund auf neu zu installieren, haben wir uns einen Trick einfallen lassen: Nach der automatischen Grundinstallation des Betriebssystems wird ein LVM-Snapshot des Base Images erstellt. Grob gesagt heißt das der Stand des Base Images wird eingefroren und alles was neu hinzukommt bzw. verändert wird (z.B. individuelle Schulungsvorbereitungen für verschiedene Trainings) belegt zusätzlichen Plattenplatz. Damit lässt sich das ursprüngliche Base Image ohne Neuinstallation eines Notebooks schnell wieder herstellen und kann so auf das nächste Training angepasst werden.

Ein weiterer Vorteil des Ganzen ist das die Schulungsteilnehmer ihre Arbeitsumgebung so gestalten können wie sie möchten und beispielsweise auch uns nicht bekannte Passwörter setzen können, mit dem Löschen des LVM-Snapshots ist alles wieder vergessen. Um es auch technisch nicht so affinen Kollegen einfach möglich zu machen Notebooks “zurückzusetzen”, gibt es hierfür beim Booten unser Schulungsnotebooks einen “Recovery”-Eintrag im GRUB-Bootloader der den LVM-Snapshot des Base Images ohne jedes Zutun zurückspielt und das Notebook anschließend neu startet.

Wie kommen aber nun die individuellen Schulungsvorbereitungen auf die Notebooks? Ist die Frage die wir uns auch gestellt haben. Individuelle Schulungsvorbereitungen können z.B. die virtuelle Maschine(n) für das Training sein, meistens auf Basis von Virtual Box, SSH Keys, Hosteinträge, bestimmte Browser oder andere Applikationen um den Schulungsteilnehmern die praktischen Übungen überhaupt möglich bzw. so einfach wie nur denkbar zu machen. Sie in den Provisionierungsprozess einzubauen scheidet ja aus, da die Notebooks wenn überhaupt nur unregelmäßig neu installiert werden sollen.

Also haben wir uns auch hier etwas überlegt: Wir haben im allgemeinem Base Image ein Bash-Skript mit einem statischen Link zur Nextcloud abgelegt. Dort findet sich ein weiteres Skript das auf die aktuell angebotenen Trainings und die jeweils dafür benötigten Schulungsvorbereitungen verweist. D.h. hier liegen beispielsweise dann auch die aktuellen virtuellen Maschinen. Um das Ganze auf den Notebooks umzusetzen verwenden wir wieder Puppet, hier war die Transition leichter da wir das in der Vergangenheit so ähnlich eh schon im Foreman hatten. Damit auch jeder der Kollegen ein Notebook individualisieren kann, gibt’s hierfür natürlich auch einfache Auswahldialoge. Wurde ein Notebook für ein bestimmtes Training vorbereitet, so löscht sich das Skript zur Vorbereitung und kann erst nach dem Recovery wieder ausgeführt werden.

Beispielhafter Auswahldialog für individuelle Schulungsvorbereitung (teils mit historischen Trainings)

Das alles sollte nun natürlich auch weiterhin funktionieren. Da CentOS 7 ab 2024 keine Maintenance Updates mehr bekommt und wir bei manchen Schulungen die nativ auf den Notebooks durchgeführt werden auch etwas mit den veralteten Versionsständen zu kämpfen haben, fiel unsere Entscheidung auf CentOS Stream 9 als neues Betriebssystem für unsere Schulungsnotebooks. Damit wir überhaupt dran denken konnten CentOS Stream zu provisionieren musste erstmal das Debian auf unserem “Event”-Foreman angehoben werden, danach folgten viele kleine Updates von Foreman 1.22 bis zum aktuellen Release 3.4.0 und auch Puppet bzw. die Puppetmodule mussten aktualisiert werden. Im Foreman selbst waren die Mirrors für CentOS Stream einzurichten, Bereitstellungsvorlagen anzupassen und auch die Partitionierung haben wir aufgrund der gestiegenen Plattenkapazität der Notebooks adaptiert. Für einen automatischen Ablauf der Provisionierung nutzen wir das Foreman Discovery Plugin.

Foreman Discovery der Schulungsnotebooks

Wer sich nun selbst ein Bild von unseren Schulungsnotebooks machen möchte, dem kann ich natürlich auch nicht nur deswegen eines unserer Trainings oder einen unserer angebotenen Workshops ans Herz legen. Vielleicht auch im Zuge der diesjährigen OSMC (Open Source Monitoring Conference).

Markus Waldmüller
Markus Waldmüller
Lead Consultant

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Grafana queries InfluxDB

Christoph hat euch ja bereits in einem früheren Blogpost vor ca. einem Jahr näher gebracht wie man Icinga 2 und InfluxDB 2 miteinander “zum Reden” bringt. Seit Icinga 2.13 steht nun auch der Influxdb2Writer zur Verfügung, welchen Afeef in seinem Blogpost benützt.

Ich möchte euch heute darauf basierend zeigen wie man nun das Setup erweitert und Grafana mit InfluxDB 2 konnektiert. Da InfluxDB 2 zum aktuellen Zeitpunkt sowohl die neue Flux Open Source Query Language (Flux) als auch noch die ältere Influx Query Language (InfluxQL) unterstützt, gibt es dafür grundsätzlich zwei verschiedene Möglichkeiten.

Zuerst stellen wir jedoch sicher das bereits ein Bucket für Icinga existiert und kopieren die ID für später:

$ influx bucket list
b860eefe6e38c504 icinga infinite 168h0m0s 6533ea60dddd2193 implicit

InfluxQL

Fangen wir mit der etwas aufwändigeren Methode an. Diese ist nötig wenn man InfluxDB 2 mittels InfluxQL abfragen möchte und geht nur auf CLI-Ebene. Dafür erstellen wir eine v1-Authentifizierung namens “grafana” mit lesendem Zugriff auf das Icinga-Bucket:

$ influx v1 auth create --username grafana --password ****** --read-bucket b860eefe6e38c504
$ influx v1 auth list

Genau dieser “username” und das zugehörige “password” wird dann bei Grafana in der jeweiligen Data Source mit der Query Language “InfluxQL” als “User” bzw. “Password” eingetragen. Zusätzlich geben wir bei “Database” den Namen des Buckets, in unserem Fall “icinga”, an.

Flux

Für Flux gestaltet sich das Ganze etwas einfacher, da hier die native Authentifizierung verwendet werden kann:

$ influx auth create --description grafana --read-bucket b860eefe6e38c504
$ influx auth list

Bei der Data Source mit der Query Language “Flux” ist dann in Grafana der soeben erstellte lange und kryptische “Token” einzutragen. Außerdem wird das Bucket, beispielhaft “icinga”, und die Organisation benötigt. Diese wird beim initialen Setup von InfluxDB generiert und lässt sich wie folgt herausfinden:

$ influx org list

Wem das jetzt etwas zu Trocken war, dem kann ich gerne unsere Schulung zum Thema InfluxDB & Grafana nahe legen. Dort wird das im Kontext nochmal anschaulicher erklärt und auch Rückfragen sind natürlich gestattet.

Markus Waldmüller
Markus Waldmüller
Lead Consultant

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Stresstest für InfluxDB

Nach einer frischen Installation von InfluxDB, egal ob auf einem dedizierten System oder nicht, frägt man sich vielleicht wie leistungsfähig das Graphing Setup nun wirklich ist oder wie viel es denn eigentlich verträgt?

Diese Fragen lassen sich mit influx-stress beantworten. Das in Golang geschriebene Helferchen ist über GitHub erhältlich und feuert beliebig viele einstellbare Metriken an InfluxDB. Dabei spielt es keine Rolle ob es lokal oder remote von einem anderen System aus aufgerufen wird.

Installation

Nachdem das Repository heruntergeladen wurde, wird das Ganze mit “go build” kompiliert:

# git clone https://github.com/influxdata/influx-stress.git
# cd influx-stress/cmd/influx-stress/
# go build -o /usr/local/bin/influx-stress

Vorbereitungen

Das Tool unterstützt derzeit nur die Authentifizierung für v1, allerdings kann man auf diese bei Bedarf auch komplett verzichten. Mit InfluxDB OSS 2.x kann dafür die “InfluxDB 1.x compatibility API” benutzt werden. Außerdem empfiehlt es sich für die Tests ein eigenes Bucket anzulegen um es später in einem Rutsch wieder zu löschen oder um gleich eine passende Retention Policy zu definieren.

# influx bucket create -n stress
# influx bucket list
# influx v1 auth create --username stress --password ****** --write-bucket f596604f968324ff
# influx v1 dbrp create --bucket-id f596604f968324ff --db stress --rp infinite

Let’s go!

Sind die Vorbereitungen gemacht, kann es losgehen. Mit “-f” läuft die Abgabe der Metriken so schnell wie möglich (fast as possible). Ich würde empfehlen zumindest noch mit “-r” (runtime) die Laufzeit einzuschränken, andernfalls würde es endlos laufen. Durch Eingabe von “–host” definiert man den Remotehost (Standard: “http://localhost:8086”).

# /usr/local/bin/influx-stress insert -f -r 1m --user stress --passs ****** --db stress

Eine beispielhafte Serie (für Icinga) könnte so aussehen: (Standard: “ctr,some=tag n=0i”)

# /usr/local/bin/influx-stress insert -r 1m ping4,hostname=agent.example.com,service=ping4,metric=rta crit=0.200000,min=0,unit="seconds",value=0.200000,warn=0.100000 --user stress --passs ****** --db stress

Nach erfolgtem Lauf bekommt man sowohl den Durchsatz (Throughput) als auch die geschriebenen Punkte (Points Written) angezeigt. Außerdem werden die Standardeinstellungen für die nicht definierten Parameter ausgegeben, die sich natürlich aber auch noch abändern lassen.

Using batch size of 10000 line(s)
Spreading writes across 100000 series
Output is unthrottled
Using 20 concurrent writer(s)
Running until ~18446744073709551615 points sent or until ~1m0s has elapsed
Write Throughput: 212335
Points Written: 13100000

Wer mehr zum Thema InfluxDB erfahren möchte, dem kann ich neben unseren üblichen Dienstleistungen auch unser InfluxDB & Grafana Training wärmstens ans Herz legen.

Markus Waldmüller
Markus Waldmüller
Lead Consultant

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Pimp your DNS!

Bei einem Consultingkunden hatte ich eine interessante Aufgabenstellung zu lösen: “Jedes Mal wenn die Domänencontroller geplant nacheinander durchgestartet werden führt das dazu, dass die Hosts im Monitoring (Icinga) kurzzeitig nicht erreichbar sind”. Auf die Frage warum die Domänencontroller regelmäßig durchgestartet werden möchte ich übrigens nicht näher eingehen 😉

Nach etwas Recherche hat sich dann herausgestellt dass das Problem aller Wahrscheinlichkeit nach am DNS liegt. Dazu sollte man wissen das die DNS-Auflösung über das sog. Resolver Configuration File die Datei “/etc/resolv.conf” bei mehreren Einträgen sequenziell läuft. D.h. das immer versucht wird über den zuerst eingetragen Nameserver aufzulösen, sollte das nicht funktionieren wird nach Erreichen des Timeouts (standardmäßig 5s) der nächste Eintrag probiert usw.

Was also tun? Den herkömmlichen Mechanismus zur DNS-Auflösung einfach ersetzen! Eine elegante und einfach zu installierende Alternative ist dnsmasq. Das Tool bietet zwar noch ein paar weitere Möglichkeiten, in meinem Fall reicht es aber schon aus das dnsmasq die Nameserver parallel befrägt (all-servers) und den nimmt, der am schnellsten antwortet. Am Beispiel von CentOS 7 lässt sich dnsmasq als Plugin über den Network Manager aktivieren. Dazu hinterlegen wir zuerst einmal die Hauptkonfiguration von dnsmasq in der Datei “/etc/NetworkManager/dnsmasq.d/dnsmasq.conf”:

resolv-file=/etc/resolv.dnsmasq
all-servers
interface=lo
bind-interfaces
cache-size=0

Danach übertragen wir die beispielhaften Nameserver aus “/etc/resolv.conf” nach “/etc/resolv.dnsmasq”:

nameserver 8.8.8.8
nameserver 8.8.4.4

Ist das passiert können wir im Network Manager über “/etc/NetworkManager/conf.d/dns.conf den DNS-Modus ändern:

[main]
dns=dnsmasq

Noch kurz den Network Manager neu laden:

systemctl reload NetworkManager.service

Und schon kommen wir in den Genuss der Auflösung via dnsmasq. Dabei ist zu beachten das der Network Manager die bisherigen Namerserver-Einträge in der “/etc/resolv.conf” entfernt und gegen lediglich einen Eintrag auf “127.0.0.1” ersetzt hat.

Beim betroffenen Kunden funktioniert die Lösung mit dnsmasq seit einigen Monaten zuverlässig und das auch wenn die Domänencontroller mal wieder durchgestartet werden. Und natürlich würde es mich freuen wenn wir auch Ihr Problem lösen können!

Markus Waldmüller
Markus Waldmüller
Lead Consultant

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Benachrichtigungen mit Icinga 2 mal anders

Vor Kurzem stand ich im Rahmen eines Kundentermins vor der Anforderung noch die Benachrichtigungen für das Icinga 2 Setup umzusetzen. “Soweit kein Problem” dachte ich mir, allerdings war die genaue Anforderung dann doch etwas speziell: Sowohl bei Hosts als auch bei Services können SLA’s gesetzt werden (“gold”, “silver” oder “bronze”). Wenn bei einem Service kein SLA gesetzt ist, greift das Servicelevel des Hosts. Hier der erste Entwurf dazu:

apply Notification "host-mail-gold" to Host {
  import "mail-host-notification"

  period = "gold"
  users = host.vars.contacts

  assign where host.vars.sla == "gold"
}

apply Notification "service-mail-gold" to Service {
  import "mail-service-notification"

  period = "gold"
  users = service.vars.contacts

  assign where (host.vars.sla == "gold" && ! service.vars.sla) || (service.vars.sla == "gold")
}

read more…

Markus Waldmüller
Markus Waldmüller
Lead Consultant

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.