Seite wählen

Monitoring-Plugin check_system_basics: Erstes Release!

von | Jan 19, 2024 | NETWAYS

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.

14 Kommentare

  1. Dirk Melchers

    Hört sich gut an!
    Jetzt wäre es noch ein Traum, wenn das Plugin auch noch auf eurem Debian/Ubuntu Repo wäre – dann wäre eine Verwendung etwas einfacher 🙂

    Antworten
    • Lorenz Kästle

      Hallo Dirk,
      das ist es selbstverständlich als ’netways-plugins-system-basics` 🙂

      Antworten
      • Dirk Melchers

        Aber leider nicht im normalen stable Icinga-Repo – zumindest nicht für Ubuntu

        Falls netways ein eigenes Ubuntu-Repo hat, dann könntest Du hier evtl. noch auf die Adresse und den PGP-Key verweisen (oder auf eine Webseite, die die Einrichtung beschreibt)

        Antworten
  2. Marcel

    Hey,

    wird es auch eine x86-Version geben? 🙂

    Antworten
      • Marcel

        Klasse, vielen Dank. Hast du noch einen Tipp, wie ich die .conf-Datei in den Icinga2 Director importiert bekomme? 🙂

        Antworten
        • Lorenz Kästle

          Einen Director Basket hab ich leider nicht da, aber im einfachsten Fall generiert man die .conf-Datei und legt sie unter `/etc/icinga2/zones.d` in die passende Zone, wobei die „passende Zone“ vermutlich „global-templates“ oder idealerweise, falls vorhanden, sowas wie `linux-commands` ist.
          Kommt natürlich auf das Setup an.

          Dann einmal Icinga2 neu laden und im Director den kickstart durchführen. Dann sollte es unter „External Commands“ zu finden sein.

          Antworten
  3. Marcel

    Hallo Lorenz,

    das Verzeichnis ist bei mir leider nicht vorhanden bzw. ich habe keinen benannten Unterordner unter /zones.d. In der zones.conf ist aber soweit alles konfiguriert.

    Antworten
    • Lorenz Kästle

      Hallo Marcel,
      vermutlich benutzt du den Director. In dem Fall tippst du entweder die Konfigurations als neue CheckCommands im Director ab oder legst auf dem Master unter `zones.d` einen Ordner für die entsprechende Zone an (Name des Ordners = Zonenname) und packst die Datei da rein.

      Antworten
  4. Ingo Kathmann

    Ein SLES-Paket wäre wunderbar.

    Antworten
    • Lorenz Kästle

      Hallo Ingo,
      Es ist jetzt mindestes für SLES 15.5 ein Paket vorhanden. Bei anderen Versionen/Distributionen wirds aber langsam schwierig 🙂

      Antworten
  5. Matthias Dillier

    Der Check sieht sehr gut aus, danke!

    Beim Filesystem-Check vermissen wir die Möglichkeit, include und exclude Optionen zu kombinieren resp. die Priorität der Optionen festzulegen. Z.B. exclude alle btrfs Filesysteme ausser jene mit einem bestimmten Mountpfad oder exclude alle Filesystem unter einem bestimmten Pfad aber include einzelne von dort doch und Ähnliches.
    Konkret haben wir recht viele, unterschiedliche Systeme und wir möchten uninteressante Filesysteme nicht anzeigen. Eine Variante bei uns wäre es auch, via Optionen in /etc/fstab include oder exclude zu machen, aber die Optionen dort sind nicht alle verfügbar. Offenbar kann man nur jene aus dem Output des mount-Befehls angeben.

    Antworten
    • Lorenz Kästle

      Hallo Matthias Dillier,
      Das ist, mehr oder weniger, eine Designentscheidung gewesen, die Komplexität in der Benutzung soll möglichst niedrig sein ohne große Einbussen im Einsatz zu haben (und ohne positionsabhängige Parameter zu verwenden).
      Das ist dann natürlich ein Balanceakt.

      Bei konkreten Wünschen und Ideen würde ich mich freuen, wenn diese als Issue im Entwicklungsrepository zu plaziert werden. Wenn der Vorschlag gut in das Konzept passt, kann es gut sein, dass er implementiert wird.

      Antworten

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr Beiträge zum Thema NETWAYS

NETWAYS stellt sich vor – Kleon Rockenbach

Name: Kleon Rockenbach Alter: 29 Position bei NETWAYS: Systems Engineer Bei NETWAYS seit: April 2024       Was genau gehört zu Deinem Aufgabenbereich bei NETWAYS? Als Teil des MyEngineer-Teams bin ich aktuell für den First-Level-Support unserer Kunden...

Monthly Snap Juni 2024

Hallo zusammen! Im Juni stand dieses Jahr nicht nur die stackconf im Mittelpunkt, denn Anfang des Monats fand auch der Icinga Summit in Berlin statt. Ein hervorragender Monat also! Aber, wie immer, hatten wir in unserem Blog eine gute Themen- Mischung für Euch!  ...

Einblicke aus der Technikwoche 2024

Vor ein paar Wochen hatte die Azubis aus dem ersten Lehrjahr die Möglichkeit, an einer Technikwoche teilzunehmen, wodurch wir uns Einblicke in verschiedene technische Abteilungen und ihre täglichen Abläufe verschaffen konnten. Hier ist ein Einblick in meine...