Seite wählen

NETWAYS Blog

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
Systems Engineer

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.

OSMC 2023 | Day 3 Recap

Day two of the OSMC 2023 started rather quiet, but with a interesting set of talks. The following is a summary and review of some talks I watched and was interested in. Therefore not all of the talks are mentionend here and this should not be interpreted as a judgement of their quality or significance.

 

Automated update management with Renovate

Sebastian Gumprich describes his journey of introducing Renovate at scale at his work place. Renovate is a software for updating dependencies in software projects, which can be self-hosted and is therefore applicable in practically every environment.

Renovate analyses the software project which is called upon, detects the dependencies, fetches data about the available versions of those and applies then updates, if any are available, and it is configured to do so.

To integrate it better into the existing development process and to not apply more load on the developers, an application as a GitLab pipeline was chosen and realized. This approach was also scalable over a huge number of different projects and repositories then.

To work correctly (and do anything) Renovate needs some configuration, which is presented as JSON and, in most cases, rather small and easy to do

The presentation was partly about the technical ideas and problem, but also, arguably more importantly, about the human part, which I found most interesting. Part of this was, unsurprisingly, structured and extensive documentation of the relevant steps and procedures and common problems. But also some programmatic features were introduced, for example, automatically opening Issues in GitLab for faulty Renovate configuration.

To further reduce the hurdles to apply Renove to a specific project, the “Onboarding” Merge Request applying the relevant changes were quite verbose in what it should do, what the consequences would be and where and whom to ask in case of open questions.

These point may seem obvious or even trivial, but, and this is the opinion of the author, organizing different people and groups of people and communicate in a constructive and efficient way is one of the biggest hurdles in the business and approaches to this set of problems are often quite interesting and helpful.

 

Replacing NSClient++ for Windows Monitoring

The second talk I want to advertise here is Sven Nierlein’s presentation of a replacement for the NSClient++.

The start of talk was the expectable review of the NSClient++, a monitoring agent which was quite common in different availability and status monitoring setups in the past, especially on windows operating systems. Sadly the developement is progressing slower nowadays than in the past and some problems, which were not fixed, are increasingly a dealbreaker. Especially, some problems with the lack of current TLS protocols are problematic.

Writing a new agent was not really the first choice, but a comparison of current alternatives did not present a good solution since the introduction of completely new configuration, new protocols and different workflows was not a feasible way to go. The resolution was therefore to write a completely new, but compatible monitoring agent.

This offered some freedoms regarding the choice of tools. The choicethen went in the direction of the Golang language and the related toolchain. The new agent was called SNClient+ (where SN stands forSecure Naemon) and supports multiple protocols from the side of themonitoring system.

One of the is the NRPE protocol for compatibility reasons and, the prefered method, an HTTP-based method, which can be used with chec_nsc_web.

Additionally, to add more features, a general Prometheus exporter wasintegrated, which exposes the general operating system exporters of thePrometheus ecosystem. Therefore, the SNClient+ can also be used as the default node exporter.

To stay compatible and enhance the functionality further, there are not only built in plugins to test different properties on the host machine, but a generic functionality to execute third-party plugins is included.

A self-updating functionality is also built-in to make updates as easy as possible.

In summary, this is a promising new solution for an old problem and is likely worth a try.

 

Running the Infra at FOSDEM

Rather spontaneously, Sebastian Schubert made a presentation about the infrastructure at FOSDEM, one of the largest Free and Open Source Software events in the world. The event occurs yearly at the beginning of February in Brussels, and they expect around 10.000 visitors/day with around 20.000 devices which need to be connected to the internet. This would be, by itself, a challenging task, but it is a totally different scenario to deploy that kind of infrastructure for just a few days and there are no paid professionals, just volunteers which might turn up with no idea what, where and how.

The astonishing fact, that this kind of organization actually works (and that repeatedly and successfully) can probably not be admired enough.

Additional to providing network access (and some services there), there is also the video and streaming setup for the hundreds of different talks, which must not only be recorded, but also, ideally, be live-streamed to the internet (currently over third parties).

For this purpose, self-designed hardware boxes were used in the past to re-encode the video and audio in first step on site, which are increasingly replaced by more common laptops. These serves as a kind of “render farm” to prepare the material for the viewer.

Following that was a short introduction to the tools used in the network setup and especially some problems regarding using IPv6-only network in the 2020s where some parts of the internet are still only reachable via IPv4. One example here was the usage coreDNS as a replacement for bind9 (for resource usage reasons).

A generally good idea mentioned then was the introduction of monitoring on- and off-site where data was replicated and still available when there was an incident which took the equipment of the FOSDEM crew at the university offline.

Another interesting point added was the general availability of practically all relevant material to the, public which allows interested parties to get some ideas how everything works there and maybe allows the adaption to other purposes.

 

openITCOCKPIT Community Edition – Einfache Konfiguration, Module, API und mehr

In this talk, Jens Michelsons presented openITCOCKPIT monitoring system, which is one of the “Nagios-similar” monitoring systems they created at the it-novum company.

The focus lies there on creating an easily usable web-based system, where everything is integrated. A powerful HTTP API serves as the main interface for all the different components and is well documented. This allows small scale configurations via the web interface or more automated setups with other tools.

A speciality of openITCockpit is problably their own monitoring agent for remote hosts and the strong integration of other tools, including the CheckMK agent, into their systems. A migration of an existing setup in openITCockpit or extending one with other tools is therefore less painful than it could be.

Remarkable was also the extended live demo (always a risk in a presentation) which presented a typical but not simple workflow for adding some systems to the monitoring, including a combining logic of different tests.

 

Zabbix – Powerful enterprise grade monitoring driven by Open Source

Appropriately, the following talk was about Zabbix, a system quite similar in many regards to openITCockpit. Wolfgang Alper described the working principles of Zabbix and what the main concepts and functionalities are.

The direct comparison was quite interesting, as one can recognize common ideas and components, but also where philosophies and ideas differ and how different problems were addressed.

One of the most important ideas in Zabbix is the separation of concerns, where gathering of data, storage, problem detection, alarming and escalation are split up programmatically and can be treated individually. The definition of these steps and their interfaces allows developers to focus on a specific part without having to worry about the whole.

Another part of the talk was dedicated to how Zabbix handles large scale and distributed setups. At this point, a part of the Zabbix software components which is called “Proxy” comes into play, and relays directions from the central system to outliers and data the other way round.

All in all Zabbix is probably a capable tool to do the classic network monitoring task, but of course not limited to that.

 

Lorenz Kästle
Lorenz Kästle
Systems Engineer

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.

Linux Monitoring mit Icinga – so löst du bekannte Probleme

This entry is part 5 of 5 in the series Icinga. Einfach. Erklärt.

Beim Betrieb von Computerinfrastrukturen treten früher oder später Probleme auf. Typischerweise schon bei der Einrichtung und später bei Änderungen, aber auch im “Normalbetrieb”. Die Ursachen dafür sind entweder extern, intern oder eine Mischung aus beidem. Zu regelmäßig auftretenden externen Ursachen zählen zum Beispiel eine Änderung des Kontextes der Maschinen, wie etwa ein Strom- und/oder Netzwerkausfall oder Updates, die etwas am äußeren Verhalten eines Programmes ändern.
Aber auch schlicht der Fortlauf der Zeit muss hier erwähnt werden. Eine tragische und unaufhaltsame Gewissheit, die durchaus technische Bedeutung hat, etwa in der Gültigkeit von Zertifikaten oder Problemen mit der Zeitsynchronisation.

Intern können Probleme durch eine bestehende Fehlkonfiguration entstehen. Dieser Begriff ist jedoch etwas Vorsicht zu genießen, da es durchaus Szenarien gibt, in denen eine bestimmte Konfiguration zum Zeitpunkt der Entstehung durchaus richtig und angemessen war. Oftmals zeigt sich erst im Verlauf von Monaten oder Jahren oder durch Änderung des Kontextes, dass die damals „richtigen“ Einstellungen problematisch sind.

An dieser Stelle tritt Monitoring auf den Plan und nimmt seinen Platz in einer gut geplanten IT-Infrastruktur ein. Enterprise-Monitoringlösungen wie Icinga versuchen bei der Voraussage, Entdeckung und Behebung von Problemen zu helfen. Um dir einen guten und vielfältigen Eindruck von den Möglichkeiten eines gut eingerichteten Monitoringtools zu geben, gehe ich in diesem Blogpost auf einige klassische und häufige Probleme, speziell im Kontext von Linux (und damit häufig auch anderen unixoiden Betriebssystemen) ein.

Im Laufe meines Beitrags werde ich regelmäßig auf die Monitoring Plugins eingehen, da diese beim Erkennen von Problemen eine wichtige Rolle spielen. Diese Zusammenstellung an Plugins ist neben Icinga auch für den Einsatz mit anderen Monitoring-Systemen geeignet, solange diese die Monitoring Plugins unterstützen.

Gängige Probleme auf Linux-Maschinen und Monitoringlösungen mit Icinga

Dateisysteme erreichen die Kapazitätsgrenzen

Ein nicht sehr häufiges (bezogen auf die Auftretenswahrscheinlichkeit), aber fatales Problem ist ganz klassisch, dass im Betrieb ein Dateisystem bis an die Kapazitätsgrenzen vollläuft. Dies führt üblicherweise dazu, dass das System seinen Betrieb ganz oder teilweise einstellt, jedoch ist das Fehlerbild potenziell auf den ersten Blick nicht offensichtlich. Beispielsweise können Programme keine großen Dateien mehr anlegen, beziehungsweise wird das Schreiben derselben abgebrochen, aber kleine, temporäre Dateien sind vielleicht (für den Moment) noch möglich.
Das führt je nach betrachteter Software und deren Fehlerbehandlung dazu, dass erst mal noch alles in Ordnung erscheint. Ein Webdienst wird weiterhin ansprechbar sein und kleine Abfragen durchaus beantworten, dann aber bei anderen (bei denen dann versucht wird größere Dateien zu schreiben) die Bearbeitung abbrechen und nur noch Fehler ausgeben, aber nicht vollständig abstürzen.

Ein anderes Beispiel ist eine Datenbank, die zwar noch lesende Zugriffe durchführen kann, aber eben keine Schreibenden. In diesen Fällen wird ein einfacher Test auf die Funktionalität des Dienstes (das init-System des Systems bescheinigt, dass der Dienst läuft; entsprechende Anfragen auf bestimmten Ports werden noch angenommen) ein positives Ergebnis bescheinigen. Trotzdem ist die eigentliche Hauptfunktionalität nicht mehr gegeben.

In einem typischen Szenario, in dem die Checks für das System lokal (oder aus der Ferne über gängige Transportwege wie SSH) ausgeführt werden, ist die klassische und gängigste Wahl beim Monitoring mit Icinga check_disk ( aus den Monitoring Plugins (Debian- und Suse-artige Distributionen) bzw. nagios-plugins (RedHat-Familie)). Zwar ist die Benutzung teilweise etwas ungewöhnlich (Stichwort Gruppierung), aber für unkomplizierte Dateisystem-Setups (und damit die häufigsten) durchaus noch ausreichend.

Ein typischer Aufruf könnte etwa so aussehen:

# ./plugins/check_disk -w 2% -c 1% \
    -X none -X tmpfs -X fuse.portal -X fuse.gvfsd-fuse \
    -X sysfs -X proc -X squashfs -X devtmpfs
DISK OK - free space: / 32892MiB (58% inode=83%); /boot 257MiB (57% inode=99%); /var 147782MiB (65% inode=92%); /home 154929MiB (34% inode=96%); /boot/efi 503MiB (98% inode=-);| /=24961351680B;61414781747;62041463193;0;62668144640 /boot=197132288B;482974105;487902412;0;492830720 /var=83065044992B;245826626519;248335061483;0;250843496448 /home=314740572160B;492755872645;497783993794;0;502812114944 /boot/efi=7340032B;524078284;529426022;0;534773760

# ./plugins/check_disk -w 2% -c 1% -N ext2 -N ext4
DISK OK - free space: / 32892MiB (58% inode=83%); /boot 257MiB (57% inode=99%); /var 147782MiB (65% inode=92%); /home 154935MiB (34% inode=96%);| /=24961351680B;61414781747;62041463193;0;62668144640 /boot=197132288B;482974105;487902412;0;492830720 /var=83065044992B;245826626519;248335061483;0;250843496448 /home=314734280704B;492755872645;497783993794;0;502812114944

In diesem Beispiel werden die Grenzwerte für Dateisysteme so gesetzt, dass der Warnzustand bei weniger als zwei Prozent freiem Speicherplatz und der Kritische bei weniger als einem Prozent auftritt. Die Sammlung an -X-Parametern (beziehungsweise das komplementäre -N) schließt diverse Dateisystemtypen aus, die nicht geprüft werden sollen. Die von mir in diesem Beispiel ausgeschlossenen Dateisystemtypen fallen nicht unter die Kategorie, die man hier im Auge hat. Hierbei handelt es sich um Dateisysteme die meine Dateien persistent auf magnetische Platten oder Halbleiterspeicher fixieren.

Alternativ können check_disk gezielt ein oder mehrere Befestigungspunkte übergeben werden:

./plugins/check_disk -w 2% -c 1% -p /home -p /boot
DISK OK - free space: /home 154935MiB (34% inode=96%); /boot 257MiB (57% inode=99%);| /home=314733232128B;492755872645;497783993794;0;502812114944 /boot=197132288B;482974105;487902412;0;492830720

Zur Feinjustierung existieren noch mehr Optionen, ein check_disk --help kann sehr hilfreich sein. Das Setzen von Grenzwerten für die Benutzung von Inodes mittels -W und -K ist leider ein viel zu häufig vergessenes Problem. Ein Mangel an freien Inodes bietet ein sehr ähnliches Bild wie eine Mangel an freiem Platz, jedoch ist es weniger offensichtlich (und tritt auch deutlich seltener auf).

Alternativen zu check_disk sind diverse andere Monitoring Plugins, wie etwa disk_usage der Linuxfabrik. Damit wird zu großen Teilen dieselbe Problematik abgedeckt. Weiterhin gibt es Plugins, die Rand- oder Sonderfälle behandeln, die außerhalb des Funktionsumfangs der klassischen Plugins liegen.
Sonderfälle dieser Art wären etwa kompliziertere Setups mit Dateisystemen mit einer größeren Menge an Funktionen wie etwas btrfs, xfs oder zfs. Hier ist eine einfache Aussage, wie die von mir bereits betrachtete “Wie viel Platz ist frei/belegt?” nicht so einfach zu treffen. Als wäre das noch nicht genug, gibt es hierbei noch die Problematik von Netzwerk- und verteilten Dateisystemen, die auch etwas komplexer ist.

TLDR

Mindestens das root-Dateisystemen sollte mit check_disk oder etwas Ähnlichem überwacht werden, als Checkintervall reichen fünf Minuten locker aus. Zusätzliche Dateisysteme für das Persistieren von Daten sollten äquivalent überwacht werden. Auch sollte überwacht werden, ob noch genügend Inodes frei sind.

Swapping

Swap-Speicher ist ein Bereich im Langzeitspeicher, der zur Auslagerung von Arbeitsspeicherinhalten dienen kann (Stichwort “Auslagerungsdatei” unter Windows). In Zeiten von sehr limitierter Arbeitsspeicherkapazität eine nützliche Funktion, um kurzfristige Kapazitätsengpässe handhaben zu können, ohne Nutzerprogrammen den angeforderten Speicher zu verweigern. Zusätzlich dient der Swap-Bereich heutzutage oft als Speicherort für Arbeitsspeicherinhalte, wenn eine Maschine in einen Ruhezustand versetzt und der (physikalische) Arbeitsspeicher ebenfalls außer Betrieb geht (Stichwort: “Hibernation”).

Diese Möglichkeiten kommen natürlich mit einem Preis. Festspeicher (“long term storage”) ist immer noch um Größenordnungen langsamer als Arbeitsspeicher (der wiederum deutlich langsamer als die
Speicher (“L*-Caches”) in der CPU ist). Die Auslagerung von aktiv genutzten Arbeitsspeicherinhalten kann dazu führen, dass ein System langsam bis an die Grenze der Benutzbarkeit gebracht wird. Das ist bei einem PC störend und frustrierend, kann jedoch bei Produktivmaschinen teilweise noch schlimmere Konsequenzen haben.
Eine Maschine, die ohnehin gerade unter Last steht, weil sie zum Beispiel sehr viele Abfragen erhält, wird, wenn das Swapping beginnt, sehr viel langsamer werden, was dann die Belastung typischerweise nicht senkt. Es sollte deshalb sichergestellt sein, dass die Nutzung von Swapspeicher (im Normalbetrieb) sowohl in Hinsicht der Quantität (Prozent an freiem/benutzten Speicher) als auch im zeitlichen Rahmen begrenzt ist.

Klassisch bietet sich hier check_swap (wiederum Monitoring Plugins|nagios-plugins) an, beispielsweise:

# ./plugins/check_swap -w 60% -c 20%
SWAP OK - 100% free (36863MB out of 36863MB) |swap=38653657088B;23192194200;7730731400;0;38653657088

In diesem Beispiel wird getestet, ob weniger als 60 Prozent des Swapspeichers frei ist (Grenzwert für WARNING) bzw. 20 Prozent (Grenzwert für CRITICAL). Eine temporär hohe Nutzung mag (je nach Szenario) durchaus erlaubt sein, aber längerfristig dürfte dies ein Problem darstellen.
Als groben Richtwert könnte man vielleicht fünfzehn Minuten anlegen, nach denen jemand alarmiert werden sollte. Das Checkintervall dürfte mit ein, zwei oder drei Minuten ausreichend bedient sein.

Wie hoch ist die Systemlast?

Ganz generell sind Systemressourcen limitiert, seien es CPU-Zeit, Speicher, andere Prozessoren und natürlich die ganzen Schnittstellen dazwischen. Manchmal lässt sich nicht oder nur schlecht an einzelnen kleinen Metriken ablesen, wenn ein Engpass besteht, zumindest wenn die Werte nur eine Teilmenge aller Werte darstellen und die wichtigen Metriken nicht enthalten sind. In unixoiden Systemen gibt es aus diesen und anderen Gründen die load-Metrik, die zwar die Details vermissen lässt, aber zuverlässig einen Indikator für ein Problem liefert.

Händisch kann die load mit dem Programm uptime (beispielsweise) abgerufen werden:

# uptime
 12:21:58 up  1:25,  1 user,  load average: 0.40, 0.38, 0.23

Die load besteht hier aus den drei Zahlenwerten 0.40,0.38 und 0.23, mit einem Aggregatswert über eine Minute, fünf Minuten und fünfzehn Minuten.

Alternativ direkt aus dem Proc-Dateisystem:

# cat /proc/loadavg
0.00 0.06 0.12 1/1316 27272

Und in “proc (5)” findet sich dann auch eine Erklärung der Zahlen.

Wer sich jetzt nicht jedes Mal die Arbeit machen will, diese Werte mit einem händisch eingegebenen Befehl aufzurufen und auszulesen, kann auf eine automatisierte Überwachung durch Check-Plugins, in diesem Fall check_load (Monitoring Plugins|nagios-plugins) setzen. Die Grenzwerte sind in diesem Fall etwas schwierig zu bestimmen, da die “zu hohe Last” stark vom Kontext abhängt.
Generell lässt sich sagen, dass eine load von eins fast der Idealwert ist, da sich damit (im Durchschnitt) immer ein Prozess in der Warteschlange befindet.

Für Werte größer als eins wird die Beurteilung schwieriger. Die Zahlenwerte aus meinem Beispiel stammen von einem Laptop ohne größere Aktivitäten (nur zwei Webbrowser). Für eine größere Maschine, etwa einen Datenbankserver mit 16 (oder mehr) CPU-Kernen, kann ein Wert von 40 auch normal sein und durchaus noch einen akzeptablen Betriebszustand darstellen. Die Option -r für check_load dividiert die load-Werte durch die Anzahl der CPU-Kerne, um eine gewisse “Normalisierung” der Werte zu erreichen, die meistens angemessen ist.

Ein angemessenes Monitoring wäre ein Checkintervall von einer bis drei Minuten mit Benachrichtigung nach fünfzehn Minuten. Als Grenzwerte wären 3,3,3 für WARNING und 5,5,5 für CRITICAL als einigermaßen konservative Einschätzung angemessen.

Ausfälle von Services (systemd) und Prozessen

In den meisten Fällen stellen Maschinen Dienste für Menschen oder andere Maschinen bereit und es ist normalerweise von gesteigertem Interesse, ob dieser Dienst auch läuft. In den meisten Linux-Distributionen ist systemd als Event- und Servicemanager im Einsatz und sollte dazu benutzt werden, durchgängig laufende Programme zu verwalten.

Mittels check_systemd lässt sich ermitteln, ob Dienste (bzw. generalisiert, systemd-units) in einem fehlerhaften Zustand sind oder nicht.

Dazu ein Beispiel mit dem SSH-Serverdienst (openssh):

# ./check_systemd.py -u ssh
SYSTEMD OK - ssh.service: active | count_units=490 data_source=cli startup_time=6.193;60;120 units_activating=8 units_active=332 units_failed=2 units_inactive=148

Im Hintergrund sind Dienste am Ende aber auch “nur” Prozesse und du möchtest potenziell diverse Eigenschaften von Prozessen überprüfen (etwa CPU-Nutzungszeit (in Prozent), oder die Größe des benutzten Speicherbereichs). Erste Anlaufstelle ist für mich check_procs.

Beispielsweise kannst du damit überprüfen, ob Zombieprozesse vorhanden sind:

# ./plugins/check_procs -s Z -w 1
PROCS OK: 0 processes with STATE = Z | procs=0;1;;0;

Ein weiterer Anwendungsfall ist die Überprüfung aller Prozesse, die mehr als zwei Prozent der CPU-Zeit verschlingen:

# ./plugins/check_procs --metric CPU -w 2
CPU WARNING: 1 warn out of 310 processes | procs=310;;;0; procs_warn=1;;;0; procs_crit=0;;;0;

Dateieigenschaften – warum Probleme auftreten können

An vielen Stellen muss überprüft werden, ob eine oder mehrere Dateien vorhanden sind und/oder bestimmte Eigenschaften aufweisen, beispielsweise ob sie älter oder jünger als ein gewisses (relatives) Datum sind, größer oder kleiner als ein Grenzwert sind oder bestimmte Berechtigungen haben. Die Ergebnisse einer solchen Überprüfung können als Indikator für ein Problem in einem Programm dienen, etwa, dass Dateien in einem Spooler-Verzeichnis nicht schnell genug abgeholt werden.

Glücklicherweise ist das ein Bereich, der sich relativ einfach durch selbstgeschriebene, auf den Nutzungsfall abgestimmte Skripte abdecken lässt. Wenn man den passenden find Befehl zusammengebaut hat, kann man nach den Monitoring Plugins Guidelines dann ein Monitoring Plugin bauen, dass den eigenen Spezialfall abdeckt.

Für etwas generellere Fälle gibt es mit check_file_age aber bereits eine Option, die zumindest das Überprüfen auf Alter und Größe erlaubt.

# ./plugins-scripts/check_file_age -f plugins-scripts/check_file_age -w 300:30000000 -c 1: -W 1:300
FILE_AGE WARNING: plugins-scripts/check_file_age is 516096 seconds old and 5193 bytes | age=516096s;300:30000000;1: size=5193B;1:300;0:;0

In diesem Beispiel sollte die Datei plugin-scripts/check_file_age älter als eine Sekunde sein (kritische Bedingung), zwischen 300 und 30000000 Sekunden alt (Bedingung für den WARNING-Zustand) und zwischen einem und 300 Bytes gross (zweite Bedingung für WARNING).

Für alle die es etwas vielfältiger mögen, wären die Monitoring Plugins der Linuxfabrik, die mit file beginnen, eine Option.

Schlusswort

Die angesprochenen Probleme sind natürlich nur ein kleiner Teil der möglichen Problemstellungen, mit denen man als Systemadministrator konfrontiert wird. Zudem habe ich mich für diesen Beitrag auch ausschließlich auf Themen innerhalb einer Maschine limitiert. Die Thematik der Netzwerkproblembehandlung hätte den Rahmen mehr als gesprengt, bietet aber ein gutes Thema für weitere Blogposts.

Ich hoffe, ich konnte anhand meiner gewählten Beispiele verdeutlichen, welche Möglichkeiten der Einsatz von Monitoringlösungen wie Icinga bietet, besonders dann, wenn du ein Unix-basiertes Rechner- oder Servernetz betreibst. Und auch wenn ich mich im Rahmen dieses Posts auf die Ausführung der Checks über die Konsole beschränkt habe, lass dich davon bitte nicht abschrecken. Natürlich können all diese Eingaben auch (bis zu einem gewissen Punkt) mit der grafischen Lösung Icinga Director und die Weboberfläche Icinga Web durchgeführt werden.

Falls du und dein Unternehmen jetzt noch Hilfe bei der Einrichtung und Konfiguration von Icinga benötigt, lass es uns einfach wissen!

In der Zwischenzeit, bleibt zu hoffen dass diese Lektüre jemandem geholfen hat und wenn (aber auch wenn nicht), dann würde sich der Autor über Kommentare freuen.

Lorenz Kästle
Lorenz Kästle
Systems Engineer

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.

Prometheus jetzt verfügbar

Vielleicht dürfte dem einen oder anderen regelmässigen Besucher schon aufgefallen sein,
dass Prometheus in unser Produktportfolio aufgenommen wurde. Als Ergänzung zu den anderen Monitoringanwendungen
(Icinga2, ElasticStack, Graylog) bietet es eine gute Ergänzung für bestimmte Anwendungsszenarien die sonst
noch nicht oder nicht ideal abgedeckt werden konnten.

Die Installation ist zwar bei Prometheus prinzipiell sehr einfach (das statisch gelinkte Binary an den richtigen Ort kopieren und ausführen), aber das ist typischerweise nicht die beliebteste Art und Weise Software zu installieren,
schliesslich müssen dann Updates immer wieder mit dem gleichen Prozedere ausgebracht werden. Das wäre ja an sich nicht weiter schwierig zu automatisieren, aber wofür das Rad neu erfinden, das ist schliesslich die Aufgabe eines Paketmanagers.

Aus diesem Grund sind jetzt in den Netways Repositories Pakete für RHEL- und Debianartige Linux-Distributionen verfügbar. Für Debian(artige) gibt es Prometheus zwar schon paketiert aus den offizielen Quellen, aber aus Gründen der Konsequenz haben wir diese in der gleichen Version wie die RHEL-Pakete nochmals gebaut.

Das Prometheus entspricht eins zu eins dem Build der von Prometheus auch auf Github verfügbar ist.

Wir wünschen fröhliche Installation und wer noch Bugs/Probleme find, darf sie beh möchte uns darauf aufmerksam machen 🙂

Lorenz Kästle
Lorenz Kästle
Systems Engineer

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.

OSMC 2022 | Recap Day 3

The third and last day of the OSMC 2022 has come to an end. Once again it looks like there is not enough time for all the talks be heard and all the conversations to be had. But waiting until everyone is bored would likely be worse. I visited some of the talks of this day, which I would like to mention. This is, by no means, a testimony to the quality or ingenuity of those or other talks, I haven’t seen, but rather a consequence of personal interest and limited time. Here is what I learned:

In 60 Minuten zum IoT Projekt auf der Basis von ThingsBoard

The biggest german railway company, the Deutsche Bahn, is, as are probably most railway companies, not know for the quick adaption of new trends or their cutting edge technology. This is in many cases, not the worst thing, since this lets the technologies hypes die down until they do something actually useful. Transporting people and cargo across great distances at high speed is not a field for ill-conceived
expermentation.

Nonetheless at some point, newer technological developments carry the possibility of improving the current situation. And the increasing maturity of IoT (“Internet of Things”) things led to an interest in the possibilities in the big world of managing a railway infrastructure. The amount of mobile and non mobile machinery and other assets is stunning and the maintenance or even keeping inventory is a rather complex task.

The increase of availability and ease of use of small sensor and networking devices can help here to create a more accurate picture of the individual systems. An example for this, mentioned in the talk by Holger Koch from DB Systel, is the observation of the amount of dust in the air in switch systems which are using electric relays. Measuring the amount of dust in the air allows a prediction of the need for maintenance to avoid errors. Complementary, unnecessary maintenance cycles can be avoided.

Many maintenance processes are on a fixed schedule and done to a specification which was developed at one point in time and is probably rather conservative. Acquisition of fine granular, new data could allow to analyze and improve those processes.

Holger presented here his experimental setup, which he uses to develop and discover these technologies. A collection of tried and tested components and a platform called ThingsBoard gives a stable basis, which takes care of a lot of the basic components like communications and the integration of and in other platforms. The platform uses some kind of open core model and should cover the use cases of most people in most situations.

Intermission – The Ignite Talks

The Ignite talks are, with their duration of only five minutes, easy to appreciate. The short duration forces the speakers to provide only a broad overview, which might interest even people foreign to the topic or very short little things, which might help for a specific problem. After a delicious lunch we’ve had the pleasure to listen to the Ignites „The O11y toolkit“ given by Julien Pivotto and „Event Driven Ansible“ by Sebastian Gumprich.

The O11y toolkit

The O11y toolkit is a practical toolkit for using Prometheus to make usage easier for people who prefer WebUI and APIs.

Event Driven Ansible

Ansible is push based, but what if one could let it trigger automatically based on some event. There is a way now and here one got a
short introduction into Event Driven Ansible.

Thruk3 – A Fresh Look

Sven Nierlein presented the newest version of the Thruk web interface to a crowd of happy users (or at least interested people). Thruk bundles multiple monitoring systems with the same interface together to present the user a unified interface. The main focus of the new version is mostly a revised look and feel. Some usage patterns and styles currently present in the web were differing increasingly from what Thruk presented before and while users were quite happy with the functionality, the interface was, to use a quote here, “ugly”.

The new interface looks quite modern and reworking it, was a chance taken to make the usage more intuitive and add some little changes to present better, more and|or better information or remove some unnecessary hurdles. For example, the introduction of a “copy to clipboard” button was not a huge change, but removes unnecessary time used for selecting and copying text and also the small error potential of not selecting correctly. So, a lot of “quality of life” fixes were introduced and can now be used, since the update is released and ready
for the rollout.

While this years OSMC has come to an end, I am already looking forward to next year! If you are interested in any of the above mentioned talks or would like to know what other talks were presented: Our conference Archives with all the recordings, slides and pictures will be released soon. Stay tuned!

Lorenz Kästle
Lorenz Kästle
Systems Engineer

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.