Seite wählen

NETWAYS Blog

NETWAYS stellt sich vor – Alvar Penning

This entry is part 62 of 62 in the series NETWAYS stellt sich vor

Name: Alvar Penning

Position bei NETWAYS: Developer

Ausbildung: B.Sc. Informatik

Bei NETWAYS seit: Oktober 2023

 

 

 

Wie bist Du zu NETWAYS gekommen und was genau gehört zu Deinem Aufgabenbereich?

Anschließend an mein Studium und einer Zeit in der wissenschaftlichen Arbeit landete ich vorerst in der Systemadministration. Ein Dschungel an verschiedenen Projekten, Netzen und Betriebssystemen führte mir hier die Wichtigkeit von gutem Monitoring vor Augen. Mit der Zeit wechselten die Aufgaben und der Softwareentwicklungsaspekt kam mehr hinzu.

Außerhalb der Lohnarbeit pflege ich verschiedene IT-Infrastrukturen; teils privat, teils in oder für Gruppen. Hierbei setze ich stets auf Freie Software, zu der ich, falls es sich anbietet und es im Rahmen meiner Möglichkeiten liegt, gerne Änderungen zurückgebe.

Diese zwei Stränge lassen sich bei NETWAYS wunderbar zusammenfügen, wo ich nun an Icinga mitarbeite. Mit sowohl einem Systemadministrationshintergrund als auch Erfahrung in der Programmiersprache Go werde ich zu den neueren Icinga-Diensten beitragen können.

 

Welche größeren, besonders interessanten Projekte stehen künftig an?

Einer dieser neueren Dienste, welcher sich gerade erst im Entstehen befindet, ist Icinga Notifications. Hierbei handelt es sich um eine grundlegende Überarbeitung der Verarbeitung von Monitoring Events, dem Verwalten von Incidents und dem schlussendlichen Absenden von Benachrichtigungen über verschiedenste Kanäle. Besonders schön am Mitarbeiten an einer so neuen Komponente ist, dass man diese in größeren Teilen von Grund auf mitgestalten kann.

 

Was macht Dir an Deiner Arbeit am meisten Spaß?

Die Mitarbeit an Freier Software ist per se ein großer Motivator. Dass ich in einer Programmiersprache arbeiten kann, welche mir persönlich gefällt, macht es natürlich noch besser. Dazu kommt ein freundliches, offenes Team, welches für eine angenehme Arbeitsatmosphäre sorgt.

 

Was machst Du, wenn Du mal nicht bei NETWAYS bist?

Wie eingangs erwähnt, habe ich auch in meiner Freizeit das eine oder andere IT-bezogene Projekt, welches hin und wieder der Pflege bedarf. Dies nehme ich gerne als Anlass, um mich selber weiterzubilden.

Sonst, wenn ich Abstand von der digitalen Welt benötige, treibt es mich ins Grüne – oder zur aktuellen Jahreszeit eher ins matschige Braun-Graue. Dort bin ich gerne wandernd, laufend oder radfahrend unterwegs.

 

Wie geht es in Zukunft bei Dir weiter?

Hier plane ich, mich tiefer im Icinga-Kosmos zurechtzufinden, um auch an anderen Teilprojekten arbeiten zu können. Mehr wird die Zeit zeigen.

Alvar Penning
Alvar Penning
Developer

Nachdem Alvar in der Welt der Systemadministration die essentielle Wichtigkeit von gutem Monitoring hautnah erfahren hat, stieß er 2023 als Developer zu Icinga hinzu. Dort trägt er mit seiner Begeisterung an Freier Software und Go-Erfahrung zum Core Team bei. Wenn der Arbeitslaptop zugeklappt ist, bewegt er sich gerne draußen in der Natur - wandernd, laufend oder radelnd - oder hat alternativ eben den Privatlaptop aufgeklappt.

Monitoring-Plugin check_system_basics: Erstes Release!

Für das Basis-Monitoring von Linux-Maschinen existieren viele Plugins im Monitoring-Universum. Grundlegende Änderungen an den zugrunde liegenden Schnittstellen sind eher selten, da viele Programme sehr langfristig darauf aufbauen. Deshalb erfüllen aktuelle Lösungen teilweise seit Jahrzehnten noch ihre Aufgabe.
Nichtsdestotrotz gibt es gelegentlich neue Schnittstellen, etwa die Pressure Stall Information”-Schnittstelle des Linux Kernels, die entweder als Ersatz für bisherige Ansätze dienen (“load”) oder als Ergänzung, um eine andere Perspektive hinzufügen.

Einführung in check_system_basics

Unabhängig von den zugrunde liegenden Schnittstellen zum System, ist die Schnittstelle zum Monitoringsystem selbst (in unserem Fall typischerweise Icinga) an sich deutlich flexibler. Hier haben sich Gewohnheiten etabliert, die aber nicht unbedingt immer den optimalen Ansatz abbilden oder der Kontext hat sich mit der Zeit gewandelt und dementsprechend ist der damalige Ansatz heute nicht mehr ganz zeitgemäß.

Aus dem Wunsch heraus, die oben genannten Probleme anzugehen und eine Lösung zur Linux Systemüberwachung anzubieten ist das Monitoring Plugin “check_system_basics” hier bei NETWAYS entstanden. Die Idee ist dahinter ist, grundlegende Systemeigenschaften mit einer möglichst konsistenten und eingängigen Parametrisierung und einer ästhetisch ansprechenden Ausgabe testen zu können. Zusätzlich wurden eine einfachere Wartung sowie die Möglichkeit der modularen Entwicklung als Ziele formuliert. Um das zu erreichen wurde Golang als Programmiersprache gewählt. Dabei dient die hauseigene Bibliothek go-check als Basis für die Funktionalität.

Kernfunktionen von check_system_basics

check_system_basics bietet in seiner aktuellen Version (also während des Verfassens dieses Blogposts) sechs verschiedene Modi, die auf spezifische Aspekte der Systemgesundheit und Leistungsfähigkeit ausgerichtet sind. Die Modi reichen von der Speicher- und Swapspeichernutzung bis zum Zustand des Netwerk-Interfaces.

Memory

Dieser Modus befasst sich mit dem Erfassen und Bewerten der Arbeitsspeicher- und Swapspeicher-Nutzung.
Im einfachsten Fall sieht die Benutzung schlicht so aus:

# ./check_system_basics memory 
[OK] - states: ok=2 
\_ [OK] RAM 
  \_ [OK] Available Memory (27 GiB/31 GiB, 85.49%) 
  \_ [OK] Free Memory (24 GiB/31 GiB, 76.17%) 
  \_ [OK] Used Memory (4.0 GiB/31 GiB, 12.74%) 
\_ [OK] Swap Usage 0.00% (0 B / 32 GiB) 
|available_memory=28686442496B;;;0;33554198528 free_memory=25557921792B;;;0;33554198528 used_memory=4274946048B;;;0;33554198528 swap_used=0B;;;0;3423390515

Arbeitsspeicher- und Swap-Nutzung werden hier zusammengefasst, da sie zusammenhängen und semantisch in einen gemeinsamen Bereich fallen. Die Absicht hinter der Formatierung der Ausgabe ist es, die Teilbereiche getrennt darzustellen, aber gleichzeitig eine schnelle Erfassung aller wichtigen Werte zu ermöglichen. Auch eigentlich redundante Werte (wie die Prozentangabe) sind hier enthalten, um möglichst alle offenen Fragen auf einmal beantworten zu können.
Die Parametrisierung der Checks kann fein-granular gegen spezifische Messwerte vorgenommen werden und in absoluten oder relativen Werten erfolgen.

Eine Übersicht über die verfügbaren Parameter kann mit

# ./check_system_basics memory --help

generiert werden.

Filesystem

Dieser Modus befasst sich mit den im System eingehängten Dateisystemen. Klassischerweise wird hier check_disk verwendet, das aber ein paar (subjektive) Nachteile aufweist.

Der erste davon ist bereits die Namensgebung, wobei dies vermutlich schon sehr von der persönlichen Perspektive abhängt. Tatsächlich ist der Betrachtungsgegenstand keine “Disk”, also ein magnetischer Festspeicher mit rotierenden Scheiben, sondern die darauf abgelegten Dateisysteme. Zudem ist die einzeilige Darstellung schon bei einer relativ geringen Anzahl von Dateisystemen unübersichtlich. Diese Ausgabe ist der historischen Limitierung auf eine einzige Ausgabezeile geschuldet, eine Beschränkung, die oft nicht mehr existiert. Auch hier wird zur besseren Übersichtlichkeit eine Darstellung als “Baum” gewählt:

[OK] - states: ok=5 
\_ [OK] / (42.11% used space, 83.54% free inodes) 
    \_ [OK] Space usage 
        \_ [OK] Percentage of free space: 57.89% 
    \_ [OK] Inodes 
        \_ [OK] Percentage of used inodes: 16.46% 
\_ [OK] /snap (42.11% used space, 83.54% free inodes) 
    \_ [OK] Space usage 
        \_ [OK] Percentage of free space: 57.89% 
    \_ [OK] Inodes 
        \_ [OK] Percentage of used inodes: 16.46% 
\_ [OK] /boot (43.19% used space, 99.72% free inodes) 
    \_ [OK] Space usage 
        \_ [OK] Percentage of free space: 56.81% 
    \_ [OK] Inodes 
        \_ [OK] Percentage of used inodes: 0.28% 
\_ [OK] /var (75.22% used space, 92.84% free inodes) 
    \_ [OK] Space usage 
        \_ [OK] Percentage of free space: 24.78% 
    \_ [OK] Inodes 
        \_ [OK] Percentage of used inodes: 7.16% 
\_ [OK] /home (49.32% used space, 94.45% free inodes) 
    \_ [OK] Space usage 
        \_ [OK] Percentage of free space: 50.68% 
    \_ [OK] Inodes 
        \_ [OK] Percentage of used inodes: 5.55% 
|/_space_free=34419593216B;;;0;62669000704 /_space_used=25032798208B;;;0;62669000704 /_space_used_percentage=42.106% /_space_free_percentage=57.894%;5:100;2:100 /_inodes_free=3264260;;;0;3907584 /_inodes_used=643324;;;0;3907584 /_inodes_free_percentage=83.537% /_inodes_used_percentage=16.463%;99;98 /snap_space_free=34419593216B;;;0;62669000704 /snap_space_used=25032798208B;;;0;62669000704 /snap_space_used_percentage=42.106% /snap_space_free_percentage=57.894%;5:100;2:100 /snap_inodes_free=3264260;;;0;3907584 /snap_inodes_used=643324;;;0;3907584 /snap_inodes_free_percentage=83.537% /snap_inodes_used_percentage=16.463%;99;98 /boot_space_free=265634816B;;;0;493201408 /boot_space_used=201981952B;;;0;493201408 /boot_space_used_percentage=43.194% /boot_space_free_percentage=56.806%;5:100;2:100 /boot_inodes_free=124580;;;0;124928 /boot_inodes_used=348;;;0;124928 /boot_inodes_free_percentage=99.721% /boot_inodes_used_percentage=0.279%;99;98 /var_space_free=58994331648B;;;0;250843787264 /var_space_used=179032711168B;;;0;250843787264 /var_space_used_percentage=75.215% /var_space_free_percentage=24.785%;5:100;2:100 /var_inodes_free=14510565;;;0;15630336 /var_inodes_used=1119771;;;0;15630336 /var_inodes_free_percentage=92.836% /var_inodes_used_percentage=7.164%;99;98 /home_space_free=241836023808B;;;0;502813065216 /home_space_used=235360329728B;;;0;502813065216 /home_space_used_percentage=49.321% /home_space_free_percentage=50.679%;5:100;2:100 /home_inodes_free=29518844;;;0;31252480 /home_inodes_used=1733636;;;0;31252480 /home_inodes_free_percentage=94.453% /home_inodes_used_percentage=5.547%;99;98

Die erste Ebene in diesem “Baum” sind die einzelnen Dateisysteme, die zweite Ebene sind Tests auf bestimmte Eigenschaften des Dateisystems. In diesem einfachen Beispiel sind die Eigenschaften die Nutzung des Speicherplatzes und der Inodes. Mit diesem Schema sollte sehr schnell erkennbar sein, welches Dateisystem welchen Problemzustand aufweist.

Die Parametrisierung erlaubt hier das Eins- und Ausschließen von Dateisystemen basierend auf dem Dateisystemtyp, dem Pfad des zugrundeliegenden Gerätes, dem Einhängepfad und der verwendeten Einhängeoptionen, sowie natürlich das Setzen von Grenzwerten für die Auslastung.

Die möglichen Parameter können wiederum mittels --help ausgegeben werden:

# ./check_system_basics filesystem --help

Als Anmerkung sei hier noch zu erwähnen, dass bewusst auf die Möglichkeit, unterschiedliche Grenzwerte für verschiedene Dateisysteme festzulegen, verzichtet wurde. Die Verwendung alternativer  Plugins, etwa check_disk wird dadurch unnötig kompliziert und es ist einfacher diese Logik im Monitoringsystem selbst abzubilden.

PSI

Wie bereits weiter oben erwähnt ist die “PSI” (“Pressure Stall Information”)-Schnittstelle relativ neu im Linux Kernel ( ~2018 ) und hat vergleichsweise selten Einzug in Monitoringsysteme gefunden. Ein
tragischer Umstand, da sie gute Metriken zur Erkennung einer Ressourcenknappheit bietet.

An dieser Stelle soll keine tiefere Diskussion zu einzelnen Werte stattfinden, dafür kann auf die entsprechende Dokumentation verwiesen werden. Kurz zusammengefasst erhält man durch die PSI-Schnittstelle Prozentangaben wie stark die Ressourcen “CPU”, “IO” (Daten lesen oder schreiben) und “Memory” überlastet sind.
Damit ist es ein besserer Ersatz für die noch weit verbreitete Betrachtung und Interpretation von load-Werte.

Die simple Ausführung sieht dann wie folgt aus:

[OK] - states: ok=3
\_ [OK] CPU Full Pressure - Avg10: 0.00, Avg60: 0.00, Avg300: 0.00
\_ [OK] IO Pressure - Avg10: 0.05, Avg60: 0.04, Avg300: 0.00
\_ [OK] Memory Pressure - Avg10: 0.00, Avg60: 0.00, Avg300: 0.00
|cpu-some-avg10=0%;@30:100;@95:100;0;100 cpu-some-avg60=0%;@30:100;@95:100;0;100 cpu-some-avg300=0%;@30:100;@95:100;0;100 cpu-some-total=10431234c;@30:100;@95:100;0 cpu-full-avg10=0%;@30:100;@95:100;0;100 cpu-full-avg60=0%;@30:100;@95:100;0;100 cpu-full-avg300=0%;;;0;100 cpu-full-total=0c;;;0 io-some-avg10=0.05%;@30:100;@95:100;0;100 io-some-avg60=0.04%;@30:100;@95:100;0;100 io-some-avg300=0%;@30:100;@95:100;0;100 io-some-total=35037331c;@30:100;@95:100;0 io-full-avg10=0.05%;@30:100;@95:100;0;100 io-full-avg60=0.04%;@30:100;@95:100;0;100 io-full-avg300=0%;;;0;100 io-full-total=34421878c;;;0 memory-some-avg10=0%;@30:100;@95:100;0;100 memory-some-avg60=0%;@30:100;@95:100;0;100 memory-some-avg300=0%;@30:100;@95:100;0;100 memory-some-total=57c;@30:100;@95:100;0 memory-full-avg10=0%;@30:100;@95:100;0;100 memory-full-avg60=0%;@30:100;@95:100;0;100 memory-full-avg300=0%;;;0;100 memory-full-total=57c;;;0

Die Unterteilung erfolgt hier in die drei oben genannten Bestandteile und dort jeweils in die Werte für 10, 60 und 300 Sekunden. Diese sind so dem Kernel entnommen und wurden nicht über diese Zeiten gemessen, check_system_basics legt hier keinen Zustand im Dateisystem ab.

Die meisten Werte der Schnittstelle sind Prozentangaben, 0% bedeutet keine Überlastung, 100% eine vollständige.

Auch hier zeigt die Hilfe --help die möglichen Parameter an:

# ./check_system_basics psi --help

Zu beachten ist, dass die “PSI”-Schnittstelle nicht zwangsläufig aktiviert sein muss, manche Distributionen deaktivieren die Option normalerweise um etwas Leistung einzusparen. Wie dies geändert werden kann, ist jeweils in der Dokumentation der Distribution nachzulesen.

Load

Aus Gewohnheits- und Vollständigkeitsgründen ist ebenfalls eine Abfrage und Bewertung der “load”-Metrik enthalten:

[OK] - states: ok=3
\_ [OK] 1 minute average: 0.04
\_ [OK] 5 minute average: 0.06
\_ [OK] 15 minute average: 0.08
|load1=0.04;;;0 load5=0.06;;;0 load15=0.08;;;0

Parameter können mit der --help Flag ausgelesen werden:

# ./check_system_basics load --help

Sensors

Dieser Modus ist eher spartanisch, da er keine Parameter zur Konfiguration der Grenzwerte besitzt. Grundsätzlich liest und gibt check_system_basics hier die Werte der vom Kernel erkannten Hardwaresensoren aus. Damit kann z.B. der Temperaturverlauf in der CPU erfasst werden.

Auch ohne Grenzwerte kann dieser Modus einen Alarm auslösen, da der Kernel selbst Grenzwerte für bestimmte Sensoren hat und diese auch zur Verfügung stellt. Wenn nun ein Sensor nicht im “grünen” Wertebereich liegt, wird dies ebenfalls vom Monitoring-Plugin erfasst und dementsprechend ein Nicht-OK-Zustand ausgegeben, mit der Angabe, um welchen Sensor es sich handelt.

[OK] - states: ok=6
\_ [OK] acpitz
    \_ [OK] acpitz_temp1: Ok - 41C
\_ [OK] BAT1
    \_ [OK] BAT1_in0: Ok - 17.413V
    \_ [OK] BAT1_curr1: Ok - 0A
\_ [OK] nvme
    \_ [OK] Composite: Ok - 37C
\_ [OK] ACAD
\_ [OK] coretemp
    \_ [OK] Package id 0: Ok - 43C
    \_ [OK] Core 0: Ok - 39C
    \_ [OK] Core 1: Ok - 40C
    \_ [OK] Core 2: Ok - 39C
    \_ [OK] Core 3: Ok - 38C
\_ [OK] iwlwifi_1
    \_ [OK] iwlwifi_1_temp1: Ok - 47C
|acpitz_temp1=41C;;~:210 BAT1_in0=17.413V BAT1_curr1=0A Composite=37C;~:83;-5:87  'Package id 0'=43C;~:100;~:100 'Core 0'=39C;~:100;~:100 'Core 1'=40C;~:100;~:100 'Core 2'=39C;~:100;~:100 'Core 3'=38C;~:100;~:100 iwlwifi_1_temp1=47C

Netdev

Das letzte Element in dieser Liste bildet der netdev-Modus. Zu diesem Zeitpunkt noch sehr eingeschränkt, wird lediglich eine Warnung ausgegeben, wenn Netzwerk-“interfaces” nicht “up” sind und die Werte einiger Zähler der jeweiligen “interfaces” ausgegeben.

[WARNING] - states: warning=3 ok=2
\_ [OK] wlp170s0 is Up
\_ [WARNING] docker0 is Down
\_ [WARNING] tun0 is Unknown
\_ [WARNING] virbr0 is Down
\_ [OK] enx00e04c6801bd is Up
|wlp170s0_rx_bytes=3597690 wlp170s0_rx_errors=0 wlp170s0_rx_dropped=12914 wlp170s0_rx_packets=28422 wlp170s0_tx_bytes=338558 wlp170s0_tx_errors=0 wlp170s0_tx_dropped=0 wlp170s0_tx_packets=1441 docker0_rx_bytes=0 docker0_rx_errors=0 docker0_rx_dropped=0 docker0_rx_packets=0 docker0_tx_bytes=0 docker0_tx_errors=0 docker0_tx_dropped=0 docker0_tx_packets=0 tun0_rx_bytes=50674521 tun0_rx_errors=0 tun0_rx_dropped=0 tun0_rx_packets=53663 tun0_tx_bytes=5252457 tun0_tx_errors=0 tun0_tx_dropped=0 tun0_tx_packets=36064 virbr0_rx_bytes=0 virbr0_rx_errors=0 virbr0_rx_dropped=0 virbr0_rx_packets=0 virbr0_tx_bytes=0 virbr0_tx_errors=0 virbr0_tx_dropped=0virbr0_tx_packets=0 enx00e04c6801bd_rx_bytes=69051761 enx00e04c6801bd_rx_errors=0 enx00e04c6801bd_rx_dropped=13077 enx00e04c6801bd_rx_packets=225219 enx00e04c6801bd_tx_bytes=19850102 enx00e04c6801bd_tx_errors=0 enx00e04c6801bd_tx_dropped=0 enx00e04c6801bd_tx_packets=149016

check_system_basic: Installation

Das Plugin kann einfach von Github heruntergeladen werden, entweder als fertig kompiliertes Programm in den Releases oder natürlich im Quellcode zum selbst kompilieren.
Alternativ ist das Plugin auch für einige gängige Distributionen verfügbar.

Für Icinga-Benutzer ist die Integration zusätzlich vereinfacht, die Option --dump-icinga2-config generiert die notwendige Konfiguration als CheckCommand, beispielhaft etwa:

./check_system_basics --dump-icinga2-config > /etc/icinga2/zones.d/global-templates/commands.d/check_system_basics.conf

Feedback, Wünsche und Probleme

Da es sich hier noch um eine recht neue Entwicklung handelt, ist der Umfang der Optionen und Möglichkeiten noch recht gering. Der Fokus liegt aktuell zunächst darauf, eine Basisfunktionalität zu schaffen, die minimal und “sauber” ist. Über Wünsche und Ideen freuen wir uns als Entwickler:innen sehr, natürlich auch über die Meldung von Problemen und Bugs. Und selbstverständlich auch einfach nur über eine Meldung, wenn etwas gut funktioniert 🙂

Lorenz Kästle
Lorenz Kästle
Consultant

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.

NETWAYS stellt sich vor – Noé Costa

This entry is part 61 of 62 in the series NETWAYS stellt sich vor

Noé Costa (Selfie)

Name: Noé Costa

Alter: 26

Ausbildung: Informatiker EFZ (Applikationsentwicklung)

Position bei NETWAYS: Software Engineer

Bei NETWAYS seit: Oktober 2023

 

 

Was genau gehört zu Deinem Aufgabenbereich bei NETWAYS?

Nach meiner Auswanderung aus der Schweiz bin ich auf NETWAYS gestoßen, da ich bei meinem ehemaligen Arbeitgeber viel mit der Monitoringlösung Icinga 2 zu tun hatte und eine offene Stelle in meinem Fachbereich ausgeschrieben war.

So kam eines zum Anderen und ich durfte mich glücklicherweise dem familiären und kollegialen Team von NETWAYS anschließen.
Ich bin im Team der Webentwicklung bei Icinga untergebracht und kümmere mich hier um die Weiterentwicklung der web-basierten Icinga 2 Module wie Icinga Businessprocess, Icinga DB Web, Icinga Notifications oder dem Icinga Director, um mal einige Beispiele aufzuführen.

 

Was macht Dir an Deiner Arbeit am meisten Spaß?

Das ist eine sehr gute Frage. Ich denke, für mich ergibt sich der Spaß darin, die stetige Evolution der Programmiersprachen und deren Einsatzbereiche zu verfolgen und natürlich die unterschiedlichen Problemlösungen, welche ich Tag für Tag versuche zu erarbeiten. Man lernt stetig dazu, stagniert nicht und erlebt immer wieder diesen belohnenden Moment, wenn der geschriebene Programmcode die Logik fehlerfrei ausführt, welche man sich zuvor im Kopf und auf Papier zusammen konstruiert hat.

Übrigens: Der Belohnungseffekt steigert sich mit der Länge der davor her gegangenen Debugging-Sitzungen exponentiell 😉

 

Welche größeren, besonders interessanten Projekte stehen künftig an?

Ein großer Fokus liegt sicherlich auf dem Ausbau des neuen Icinga DB Backends, welches zukünftig noch leistungsstärkere und skalierbarere Installationen in komplexen Systemumgebungen für die Endkunden ermöglichen wird.

Auch an den diversen durch Icinga 2 bereitgestellten Modulen wird fleißig gearbeitet und mit der digitalen Wandlung der Industrie werden wir auch zukünftig viele Anforderungen aus der IT-Branche in der Icinga 2 Landschaft abbilden müssen. Uns wird also nie langweilig!

 

Was machst Du, wenn Du mal nicht bei NETWAYS bist?

Das kann ich so pauschal gar nicht definieren – alles und nichts trifft es glaube ich am besten. Sei es sich mal in Ruhe in ein neues Themengebiet einzulesen, eine Serie zu schauen oder den persönlichen Fahrdienst für die Partnerin zu spielen; von allem ist da etwas dabei.

 

Wie geht es in Zukunft bei Dir weiter?

Fürs Erste muss ich mich hier erst einmal in Deutschland einleben. Klar, die Kultur unterscheidet sich jetzt nicht unbedingt stark zur Schweiz, allerdings findet man doch immer wieder einige Unterschiede im Umgang mit den Menschen oder bei der Kommunikation.

Studieren möchte ich für den Moment nicht; schließe es aber auch nicht komplett aus. Wenn, dann auf jeden Fall etwas im Bereich der Informatik / Technik.
Dazu sei abschließend gesagt, dass ich mich im Bereich des Monitoring und vor allem auch bei der NETWAYS sehr wohlfühle und mich auch hier gerne weiterentwickeln werde.

Noé Costa
Noé Costa
Developer

Noé ist als Schweizer nach Deutschland ausgewandert und unterstützt das Icinga Team seit Oktober 2023 als Developer im Bereich der Webentwicklung. Er wirkt an der Weiterentwicklung der Webmodule von Icinga mit und ist sehr interessiert am Bereich des Monitorings und dessen Zukunft. Neben der Arbeit kocht er gerne, verbringt Zeit mit seiner Partnerin, erweitert sein Wissen in diversen Gebieten und spielt ab und an auch Computerspiele mit Bekanntschaften aus aller Welt.

Monthly Snap Dezember 2023

Ein glückliches und gesundes neues Jahr zusammen!

Kaum näherte sich der Dezember fing es in Nürnberg an zu schneien und es wurde für einige Tage richtig gemütlich.  Aber auch wenn viele vielleicht denken wir hatten nur Glühwein und Weihnachtsmarkt im Kopf, belehrt euch unser Blog vielleicht eines Besseren 😊

Das Beste in Dezember war natürlich unsere Weihnachtsfeier! Sebastian Z. hat diesen ganz speziellen Tag zusammengefasst, den wir mit Sicherheit nicht so schnell vergessen werden!

Aber wir hatten auch andere Themen für euch!

Katja blickte zurück auf das vergangene Jahr bei NETWAYS und teilte auch Links zu den beliebtesten Blog- Artikeln des Jahres. Die vielen Fotos lassen uns mit einem Lächeln im Gesicht das Jahr Revue passieren, Apostolos schrieb über effektive Zugriffskontrolle für GitLab Pages, Dirk hat besonderes Interesse an Sebastian Schubert’s Talk an der OSMC gehabt, und berichtete vom Thema What’s new with Grafana Labs’s Open Source Observability stack, Katja teilte Links zu den Talks der stackconf und der OSMC 2023, riet zum Save the Date für die stackconf 2024 und rief dazu auf bei den Open Source Camp für Kubernetes und DevOps Days 2024 teilzunehmen (der Call for Papers ist noch offen!)und Markus O. gab uns noch ein GitHub Update.

Falls jemand Themenwünsche für kommende Blogartikel hat, schreibt uns gerne. Bis zum nächsten Mal!

Header Foto von Cristian Escobar auf Unsplash

Catharina Celikel
Catharina Celikel
Office Manager

Catharina unterstützt seit März 2016 unsere Abteilung Finance & Administration. Die gebürtige Norwegerin ist Fremdsprachenkorrespondentin für Englisch. Als Office Manager kümmert sie sich deshalb nicht nur um das Tagesgeschäft sondern übernimmt nebenbei zusätzlich einen Großteil der Übersetzungen. Privat ist der bekennende Bücherwurm am liebsten mit dem Fahrrad unterwegs.

NETWAYS GitHub Update Dezember 2023

This entry is part 11 of 13 in the series NETWAYS GitHub Update

Willkommen beim NETWAYS GitHub Update, der monatliche Überblick über unsere neuesten Releases.

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

Der Dezember ist je nach Branche eine besonders anstrengende oder eine eher ruhige Zeit. Bei unseren GitHub-Releases ging es in diesem Monat ruhiger zu, einen Release haben wir aber für dich:

check-smseagle v2.0.1

Nach langer Vorbereitungszeit endlich ein neues Release! Die Version 2.0.1 enthält nur einen kleinen Bugfix für das große 2.0.0 Release.

Changelog

  • Support für (ausschließlich) Python 3
  • Support für die neue API Version v2
  • Support für CLI Optionen über Umgebungsvariablen

https://github.com/NETWAYS/check_smseagle/releases/tag/v2.0.1

Unsere Pläne für 2024

In 2023 war viel los auf unserem GitHub Account. Viele Issues wurden eröffnet und eine noch höhere Anzahl Pull Requests für unsere Projekte gestellt. Wir freuen uns, dass ein großer Teil davon bereits erfolgreich abgeschlossen und aufgenommen wurde.
Refaktorierung war für uns ein wichtiger Schwerpunkt des letzten Jahres und wir konnten einige interne Projekte endlich öffentlich zugänglich machen. So geht es hoffentlich auch 2024 weiter!

Außerdem planen wir Forks einiger beliebter Monitoring Check Plugins zu erstellen, die leider nicht mehr betreut werden. Auf weitere Informationen hierzu kannst du dich im Laufe des Jahres freuen!

Was wäre der Start in ein neues Jahr ohne einen kleinen Rückblick auf das vergangene Jahr? Hier unsere Highlights aus 2023:

icinga-installer Releases v1.0.0 – v1.2.7

Der icinga-installer – ein einfach zu benutzender Installer für Icinga ist im Februar 2023 in seiner v1.0.0 erschienen. Seitdem kamen einige Bugfixes und Anpassungen dazu, dass du nun einfach zu deiner funktionsfähigen Icinga Installation kommst.

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

check-influxdb v0.1.0

Changelog

  • Erster Release! Wir hoffen, Euch hilft das neue Plugin.

https://github.com/NETWAYS/check_influxdb/releases/tag/v0.1.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

 

ansible-role-ca Release v0.1.0

Wir bieten jetzt eine Ansible Rolle für die Verwaltung von CA und Zertifikaten an!

Die Rolle ist noch in einem sehr frühen Stadium, daher sind Pull Requests und allgemeines Feedback sehr Willkommen.

Changelog

  • Initiales Release!

https://github.com/NETWAYS/ansible-role-ca/releases/tag/0.1.0

 

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.