Seite wählen

NETWAYS Blog

NETWAYS GitHub Update Juli 2023

This entry is part 6 of 9 in the series NETWAYS GitHub Update

Willkommen beim NETWAYS GitHub Update, unser monatlicher Überblick über unsere neuesten Releases.

Im Juli 2023 haben wir wieder einen ganzen Schwung spannender Updates an den Start gebracht. Dazu gehören unter anderem eine Aktualisierung der Golang Bibliothek für Check-Plugins, Version 1.2.5 unseres beliebten Icinga Installers sowie ein neuer Release des NETWAYS Support Collectors.

Zudem haben die Check-Plugins für Bareos, Elasticsearch und Logstash einige Änderungen spendiert bekommen!

Wenn du in Zukunft Updates direkt zu Release erhalten willst, folge uns einfach auf GitHub: https://github.com/NETWAYS/

check-bareos Release v2.0.0

Wir haben diesen Monat einen großen Refactor des Check Plugins durch, damit werden wir das Tool in Zukunft besser warten können. Gibt viele Änderungen, am besten die Release Notes lesen.

Changelog

  • Hinzugefügt: Viele neue Unittests!
  • Hinzugefügt: CLI Parameter unterstützen Thresholds
  • Ausgabe normalisiert und erweitert
  • Diverse Bugfixes

https://github.com/NETWAYS/check_bareos/releases/tag/v2.0.0

go-check Release v0.5.0

Ein etwas größeres Release unserer Golang Bibliothek für Check Plugins. Mit diesem Release haben wir einiges an Code aufgeräumt.

Changelog

  • Einige Abhängigkeiten entfernt
  • Breaking Change: metric und benchmark Pakete entfernt
  • Breaking Change: http/mock Paket entfernt
  • Breaking Change: Ältere Funktionen entfernt
  • Bugfix: Fehler in der Ausgabe von PartialResult gefixt
  • Viele kleine Fixes unter der Haube

https://github.com/NETWAYS/go-check/releases/tag/v0.5.0

check-elasticsearch Release v0.3.0

Changelog

  • Hinzugefügt: Neuer Subcheck für Ingest Pipelines
  • Refactor um teilweise kompatibel mit OpenSearch zu sein
  • Viele Optimierungen unter der Haube

https://github.com/NETWAYS/check_elasticsearch/releases/tag/v0.3.0

check-logstash Release v0.9.0

Changelog

  • Hinzugefügt: Neuer Subcheck für Logstash 8 Pipeline Metriken
  • Hinzugefügt: Neuer Subcheck für Logstash Pipeline Reload Fehler

https://github.com/NETWAYS/check_logstash/releases/tag/v0.9.0

support-collector Release v0.9.0

Changelog

  • Hinzugefügt: Viele neue Kollektoren (Elastic Stack, Prometheus, Graylog, MongoDB, Foreman, diverse Webserver)
  • Hinzugefügt: Neue CLI Option um sensitive Daten zu entfernen
  • Hinzugefügt: Das Tool sammelt jetzt auch teilweise Logdateien ein
  • Viele Abhängigkeiten unter der Haube aktualisiert

https://github.com/NETWAYS/support-collector/releases/tag/v0.9.0

icinga-installer Release v1.2.5

Changelog

  • Bugfix: Weitere PHP und Apache Konfiguration wird nun von Puppet verwaltet
  • Bugfix: Puppet Daemon auf Debian/Ubuntu deaktiviert

https://github.com/NETWAYS/icinga-installer/releases/tag/v1.2.5

Markus Opolka
Markus Opolka
Consultant

Markus war nach seiner Ausbildung als Fachinformatiker mehrere Jahre als Systemadministrator tätig und hat währenddessen ein Master-Studium Linguistik an der FAU absolviert. Seit 2022 ist er bei NETWAYS als Consultant tätig. Hier kümmert er sich um die Themen Container, Kubernetes, Puppet und Ansible. Privat findet man ihn auf dem Fahrrad, dem Sofa oder auf GitHub.

check_prometheus ist jetzt öffentlich verfügbar!

Monitoring ist komplex, das wissen wir hier bei NETWAYS leider zu gut. Deswegen laufen in der Infrastruktur auch mal gerne mehrere Tools für die Überwachung. Zwei gern gesehene Kandidaten sind dabei Icinga und Prometheus. Icinga und Prometheus erfüllen unterschiedliche Rollen im Monitoring, daher besteht oft Bedarf für eine Integration beider Tools. Genau dafür haben wir check_prometheus geschrieben, was wir nun der Öffentlichkeit zur Verfügung stellen.

https://github.com/NETWAYS/check_prometheus

Mit check_prometheus lassen sich der Status deiner Prometheus Server ermitteln, Alarme aus Prometheus auslesen und sogar PromQL aus Icinga auswerten. Das Check Plugin haben wir in Golang geschrieben, das heißt, es werden keine weiteren Abhängigkeiten auf der Icinga Instanz benötigt. Hier einige Beispiele für die Nutzung:

Wir können grundlegend zunächst mal prüfen, ob unser Prometheus Server erreichbar und operativ ist. Dafür nutzen wir den health Unterbefehl:

$ check_prometheus health

[OK] - Prometheus Server is Healthy. | statuscode=200

Natürlich können wir hier Adresse oder TLS Konfiguration als Parameter angeben.

Mit dem alert Unterbefehl, lässt sich außerdem der Status von in Prometheus definierten Alarmen überprüfen. Entweder eines oder mehrerer spezifischen Alarme:

$ check_prometheus alert --name "MyVeryImportantAlert"

[CRITICAL] - 1 Alerts: 1 Firing - 0 Pending - 0 Inactive
\_[CRITICAL] [MyVeryImportantAlert] - Job: [example] is firing - value: 1.00
| firing=1 pending=0 inactive=0

Oder auch einfach alle bereits in Prometheus definierten Alarme und deren Status:

$ check_prometheus alert

[CRITICAL] - 6 Alerts: 3 Firing - 0 Pending - 3 Inactive
\_[OK] [PrometheusTargetMissing] is inactive
\_[CRITICAL] [PrometheusAlertmanagerJobMissing] - Job: [alertmanager] is firing - value: 1.00
\_[OK] [HostOutOfMemory] - Job: [alertmanager]
\_[OK] [HostHighCpuLoad] - Job: [alertmanager]
\_[CRITICAL] [HighResultLatency] - Job: [prometheus] on Instance: [node01] is firing - value: 11.00
| total=6 firing=3 pending=0 inactive=3

Wenn wir keine Alarme in Prometheus definieren wollen, können wir mit dem query Unterbefehl auch direkt PromQL auswerten lassen und gegen Schwellwerte prüfen:

$ check_prometheus query -q my_very_important_metric{job="prometheus"}[10s]' -c5 -w 10

[WARNING] - 1 Metrics: 1 Critical - 0 Warning - 0 Ok
\_[WARNING] my_very_important_metric{instance="node01", job="prometheus"} - value: 15
| my_very_important_metric_node01_prometheus=15

Persönlich empfehle ich jedoch, Alarme in Prometheus zu definieren da wir hier weitere Möglichkeiten haben, den jeweiligen Alarm zu definieren (beispielsweise das for Schlagwort in der Alarm Definition).

Jetzt da wir unsere Prometheus Instanzen mit Icinga integriert haben, können wir uns ansehen, wie wir den Prometheus Alertmanager aus Icinga ansprechen können. Die Integration mit dem Prometheus Alertmanager ist glücklicherweise kein großes Problem. Durch die Prometheus Alertmanager HTTP API, können wir relativ leicht benutzerdefinierte Alarme mittels JSON erzeugen. Alles was wir brauchen ist ein Notification Plugin, das uns die Statusmeldung in Icinga nach JSON transformiert und diese an den Alertmanager schickt.

Da jede Benachrichtigungsstrategie anders aussieht, können wir hier keine universelle Lösung implementieren. Das heißt aber nicht, dass wir nicht Beispiele zur Verfügung stellen können. Im Repository findet ihr ein kleines Python Skript, dass sich ohne Abhängigkeiten auf jeder Icinga Instanz einsetzen lässt:

notify-alertmanager-example.py --hostname mynode01 --service ping --state 2

Hast du einen Bug gefunden, oder brauchst ein neues Feature? Melde dich einfach auf GitHub!

Markus Opolka
Markus Opolka
Consultant

Markus war nach seiner Ausbildung als Fachinformatiker mehrere Jahre als Systemadministrator tätig und hat währenddessen ein Master-Studium Linguistik an der FAU absolviert. Seit 2022 ist er bei NETWAYS als Consultant tätig. Hier kümmert er sich um die Themen Container, Kubernetes, Puppet und Ansible. Privat findet man ihn auf dem Fahrrad, dem Sofa oder auf GitHub.

Neues zum go-check

Lang ist es her, dass ein Blogpost über das hauseigene NETWAYS go-check geschrieben wurde. Seitdem hat sich das go-check immer weiterentwickelt und wurde mit vielen verschiedenen Funktionen erweitert, sodass die Pluginentwicklung noch einfacher von der Hand geht.

Um einen kurzen Umriss zu geben, bei dem go-check handelt es sich um GO Package, mit dem es möglich ist, schnell und einfach, Icinga Plugins zu entwickeln.

Ein Beispiel dafür wäre das Evaluieren von Thresholds und anschließendem Anhängen von Performance data im richtigen Format:

package main

import (
	"github.com/NETWAYS/go-check"
	"github.com/NETWAYS/go-check/perfdata"
)

func main() {
	config := check.NewConfig()
	config.Name = "check_new"
	config.Readme = `example Plugin Readme`
	config.Version = "1.0.0"

	return_code := check.Unknown

	plugin_output := ""

	crit_thresh := config.FlagSet.StringP("crit-example", "c", "20", "Critical threshold")

	warn_thresh := config.FlagSet.StringP("warn-example", "w", "10", "Warning threshold")

	example_val := config.FlagSet.Float64("example-val", 0.0, "Example value")

	config.ParseArguments()

	crit, err := check.ParseThreshold(*crit_thresh)
	if err != nil {
		check.ExitError(err)
	}

	warn, err := check.ParseThreshold(*warn_thresh)
	if err != nil {
		check.ExitError(err)
	}

	if crit.DoesViolate(*example_val) {
		return_code = check.Critical
		plugin_output = "Value is critical!"
	} else if warn.DoesViolate(*example_val) {
		return_code = check.Warning
		plugin_output = "Value is warning!"
	} else {
		return_code = check.OK
		plugin_output = "Everything is fine"
	}

	p := perfdata.PerfdataList{{
		Label: "example_label",
		Value: *example_val,
		Warn:  warn,
		Crit:  crit,
		Uom:   "Mb",
	}}

	example_perf := perfdata.Perfdata{
		Label: "another_perfdata",
		Value: 1.0,
		Warn:  &check.Threshold{Upper: 50.0},
		Crit:  &check.Threshold{Upper: 100.0},
	}

	p.Add(&example_perf)

	check.ExitRaw(return_code, plugin_output, "|", p.String())
}

Nach dem Kompilieren des Programms können beispielhaft Parameter mitgegeben werden:

go build -o check_test main.go

./check_test -c 20 -w 9 --example-val 10
WARNING - Value is warning! | example_label=10Mb;9;20 another_perfdata=1;50;100

Darüber hinaus gibt es folgende weitere Funktionen:

  • Konvertierung von IEC zu SI Einheit
  • Performance data in Human-readable Format
  • Http-Mock, welcher http-requests und results „dokumentiert“ und in XML speichert
  • Evaluierung des „schlechtesten“ Ergebnisses (Value) in einem Array

Somit bietet go-check ein schnelles und komfortables Package für die Entwicklung eines Icinga 2 Check Plugins. Für weitere Releases und Aktualisierungen, einfach bei dem offiziellen NETWAYS Organisation vorbei schauen.

Philipp Dorschner
Philipp Dorschner
Technical Service Manager

Nach seiner Ausbildung zum Fachinformatiker bei der NETWAYS Professional Services GmbH wuchs das Interesse an Development und organisatorischen Themen. Heute unterstützt Philipp die Kollegen aus PS-Services als hybrider Mitarbeiter. Fünfzig Prozent seiner Zeit als Technical Service Manager und die anderen fünfzig Prozent als interner Entwickler. Als Ausgleich zu seiner Arbeit im Büro verbringt er seine Freizeit meistens beim Sport oder trifft sich mit Freunden.

Alle Jahre wieder, kommt der Advent of Code

…zumindest seit 2015. Bereits zum achten Mal haben Rätsel- und Programmierfreunde rund um die Welt in der Nacht vom 30. November auf den 1. Dezember dieses Jahr gebannt auf die Veröffentlichung des ersten Rätsels gewartet. Ihr habt davon noch nie gehört und wollt mehr über diesen kniffeligen Adventskalender wissen? Dann seid ihr hier und heute genau an der richtigen Stelle!

Advent of Was?

Der Advent of Code ist ein 25-tägiger Rätselspaß, der jährlich vom 1. Dezember bis einschließlich 25. Dezember stattfindet und einen täglich vor zwei neue Herausforderungen stellt, die es zu lösen gilt. Die Rätsel sind hierbei in eine weihnachtliche Rahmenhandlung eingebaut, sodass man durch den Advent hindurch beim Knobeln nebenbei noch eine Geschichte erzählt bekommt. Löst man jeden Tag beide Aufgaben, erhält man in Summe 50 Sterne. Außerdem schaltet man durch seine Lösungen nach und nach auf der Website ein Bild im ASCII-Stil frei und hat also zusätzlich so etwas wie einen klassischen Adventskalender, der als Motivation herhalten kann.

Ist man bei der Bearbeitung auch noch besonders schnell, kann man es auf die globale Rangliste schaffen und den Advent hindurch Punkte sammeln, was aber quasi ein Ding der Unmöglichkeit ist. Private Ranglisten, bspw. mit KollegInnen oder im Freundeskreis, sind hier die weniger frustrierende Alternative.

Mein tagesaktueller Adventskalender auf der Advent of Code Website

Mein aktueller Adventskalender auf der Advent of Code Website. Wie das Bild wohl in 17 Tagen aussehen wird?

Das Handwerkszeug

Wie genau man die Rätsel löst, bleibt jedem selbst überlassen. Die naheliegendste Lösung ist es, programmatische Ansätze in beliebigen, mehr oder weniger gängigen Programmiersprachen zu finden – es gibt jedoch auch glühende Anhänger von Tabellenkalkulationsprogrammen, die ihre täglichen Lösungen als Excel-Datei oder Google-Sheet veröffentlichen. Auch auf Papier, mittels Minecraft-Schaltungen oder in Factorio-Fabriken wurden bereits des Öfteren Lösungen gefunden.

Alle Rätsel vereint, dass es einen pro Teilnehmer individuellen “Rätselinput“ in Textform gibt, aus dem sich eine eindeutige Lösung extrahieren lässt – meist eine Zahlen- oder Buchstabenkombination oder das Ergebnis einer Berechnung. Zusätzlich gibt es immer zumindest 2-3 Beispiele, wie die Lösungen für hypothetische Eingaben aussehen würden, sodass man sich nicht zu 100% auf seine Fertigkeiten, ellenlange Textaufgaben lesen zu können, verlassen muss.

Zeit für etwas Neues

Viele Teilnehmer nutzen die sehr offen gestellten Aufgaben, um eine neue Programmiersprache auszuprobieren oder bestehende Kenntnisse zu vertiefen – so nutze ich die Gelegenheit bspw., um endlich einmal etwas nachhaltiger in Go reinzuschauen, anstatt einmal im Quartal ein paar Zeilen Code „zu verbrechen“. Auch einige unserer Azubis haben den Advent of Code für sich entdeckt und machen momentan ihre ersten Schritte in PHP, und wieder andere KollegInnen geben exotischen Sprachen eine Chance, von denen ich zuvor noch nie gehört habe. Aber auch wenn man keine Lust hat, von Grund auf etwas Neues zu lernen oder auszuprobieren, bietet der Advent of Code eine gute Möglichkeit zum winterlichen Gehirnjogging, bevor es abends auf den Weihnachtsmarkt geht.

Wenn es eucht jetzt direkt in den Fingern juckt und ihr im Hintergrund bereits den Texteditor eurer Wahl gestartet habt, entlasse ich euch an dieser Stelle in den Advent. Aber auch ansonsten kann ich nur sagen: Probiert’s doch mal aus!

Daniel Bodky
Daniel Bodky
Consultant

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und berät nun Kunden zu den Themen Icinga2 und Kubernetes. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

NETWAYS Support Collector Roadmap

Den Support Collector konnte ich bereits in meinem letzten Blogpost vorstellen. Für alle die den Beitrag verpasst haben, hier kurz umrissen was es ist:
Bei dem Tool handelt es sich um einen von uns geschriebenen Datensammler, welche alle möglichen Support relevanten Daten von einem System sammelt und als ZIP verpackt. Das ZIP kann in Support Fällen an uns geschickt werden, damit wir uns einen Überblick über das System machen können.

Letzte Woche konnte mit Verzögerungen die Version 0.7.0 veröffentlich werden, welche nun auch Daten über die IcingaDB und Redis sammelt. Von Versionen bis hin zur Konfiguration und Service Status wird alles mit gesammelt.

Im Rahmen dieses Blogposts möchte ich euch einen kleinen Ausblick geben, welche möglichen Erweiterungen wir mit dem Support Collector noch abbilden möchten.

Systemweiter Datensammler

Zum aktuellen Stand sammelt der Support Collector Daten ein, speichert sie in eine Datei und verpackt dass alles zu einem großem ZIP. Das ganze passiert aber nur auf dem System auf welchen das Tool ausgeführt wird. Jetzt stehen wir natürlich vor dem „Problem“ dass Icinga 2 Umgebungen über mehrere Systeme verteilt sein können. So kann es sein dass einfach nur die Datenbank auf einem anderen Host läuft oder dass sich irgendwo noch ein zweiter Master bzw. Satelliten befindet. Aus Sicht des Supports wäre es natürlich schön auch diese Daten mit abzufragen.
Die Umsetzung des eben beschriebenen Vorhabens ist noch nicht ganz klar, da es hier neben vielen Kleinigkeiten vor allem die Security zu beachten gilt. Da wir uns auch vorstellen können, dass nicht ein jeder es gut findet, wenn wir komplette Systeme scannen, wird diese Funktion auch nur optional. Unser Augenmerk liegt darauf, dass der Benutzer frei entscheiden kann, was er gesammelt haben möchte.

Statistiken

Mit den gesammelten Daten lassen Sich natürlich auch aussagekräftige Statistiken erstellen. Anhand von diesen Daten könnten wir von den einfachsten Statistiken wie „Welche Versionen werden wie oft genutzt“, bis hin zu komplexen Themen wie „Durchschnittliche Größe eines Systems“ oder „Welche Hardware Specs für welche Icinga 2 Größe“ erstellen. Allerdings ist auch hier noch nicht zu eindeutig wie die Umsetzung aussehen soll, da hier ebenfalls die Security und Anonymität eine große und wichtige Rolle spielen.

Mit den zwei Punkten welche ich hier angesprochen habe, konnte ich euch nur einen kleinen Einblick gegeben, was an Feature Ideen noch in Planung sind. Sollte euch etwas einfallen, was aus eurer Sicht sinnvoll wäre umzusetzen, könnt ihr gerne ein Feature Request im Git Repository eröffnen.

Tobias Bauriedel
Tobias Bauriedel
Assistant Manager Operations

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns hat er seine Ausbildung zum Fachinformatiker für Systemintegration abgeschlossen und arbeitet nun im NETWAYS Professional Services - Team Operations und entwickelt nebenbei Projekte für die NPS. In seiner Freizeit engagiert er sich ehrenamtlich aktiv bei der Freiwilligen Feuerwehr als Atemschutzgerätetrager und Maschinist, bereist die Welt und unternimmt gerne etwas mit Freunden.