Zum Hauptinhalt springen

Open-E JovianDSS mit Checkmk überwachen

Wim Bonis
Monitoring Storage Open Source
Autor
Stylite AG
Spezialisten in ZFS storage solutions, security. Docker containerization for enterprise environments.
Inhaltsverzeichnis

Open-E JovianDSS ist eine weit verbreitete Enterprise-Storage-Lösung, die in vielen Rechenzentren zum Einsatz kommt. Für den zuverlässigen Betrieb ist ein durchgängiges Monitoring unerlässlich. Checkmk bietet hierfür eine elegante Möglichkeit: Über die REST API von Open-E lassen sich sämtliche relevanten Storage-Daten direkt in Checkmk einbinden – ganz ohne zusätzlichen Agenten auf dem Storage-System.

In diesem Artikel wird gezeigt, wie die Integration Schritt für Schritt eingerichtet wird.

Voraussetzungen
#

  • Checkmk-Server mit Netzwerkzugriff auf das Open-E System
  • Open-E JovianDSS mit aktivierter REST API
  • Admin-Zugang zu beiden Systemen
  • curl und python3 auf dem Checkmk-Server verfügbar

Schritt 1: REST API auf dem Open-E aktivieren
#

Zunächst muss die REST API auf dem Open-E JovianDSS aktiviert werden. Dazu in der Web-Oberfläche unter System Settings den Bereich REST API access aufrufen:

  1. Enable REST API access aktivieren
  2. Port auf 82 belassen (Standard)
  3. Access restriction auf Read-only setzen – für Monitoring reicht lesender Zugriff
  4. Username und Password festlegen
  5. Mit Apply bestätigen

Open-E JovianDSS System Settings – REST API aktivieren und Passwort setzen

💡 Optional: Im gleichen Bereich kann auch SNMP aktiviert werden, um zusätzliche Hardware-Daten (z. B. Temperaturen, Lüfter) über SNMP abzufragen. Die REST API liefert diese Daten allerdings bereits mit.

Schritt 2: API-Zugriff testen
#

Bevor die Integration in Checkmk konfiguriert wird, sollte der API-Zugriff vom Checkmk-Server aus getestet werden. Dazu per SSH auf den Checkmk-Server verbinden und folgenden Befehl ausführen:

curl -k -s -X GET \
  -u admin:DEIN_PASSWORT \
  -H 'Content-Type: application/json' \
  https://192.168.0.100:82/api/v3/monitoring/check-mk \
  | python3 -c 'import json,sys;obj=json.load(sys.stdin);print(obj["data"]["output"]);'
  • -k überspringt die SSL-Zertifikatsprüfung (selbstsigniertes Zertifikat)
  • -s unterdrückt die Fortschrittsanzeige
  • 192.168.0.100 ist die IP-Adresse des Open-E Systems (entsprechend anpassen)
  • Port 82 ist der Standard-API-Port von Open-E JovianDSS

Bei erfolgreicher Verbindung erscheint die Ausgabe im Checkmk-Agenten-Format – eine Auflistung aller verfügbaren Monitoring-Daten wie Filesystems, Interfaces, CPU und mehr.

Schritt 3: Host in Checkmk anlegen
#

Im nächsten Schritt wird das Open-E System als Host in Checkmk angelegt:

  1. Unter Setup → Hosts → Create host einen neuen Host erstellen
  2. Host name: z. B. open-e-system
  3. IPv4 address: IP des Open-E Systems (z. B. 192.168.0.100)
  4. Checkmk agent / API integrations: auf API integrations if configured, else Checkmk agent setzen
  5. Optional: SNMP auf SNMP v2 or v3 aktivieren, falls zusätzliche SNMP-Daten gewünscht sind

Checkmk Host-Konfiguration für das Open-E System mit IP-Adresse und API-Integration

Schritt 4: Custom Integration einrichten
#

Jetzt wird die eigentliche Datenabfrage konfiguriert. Checkmk bietet dafür die Möglichkeit, ein eigenes Programm anstelle des Standard-Agenten auszuführen:

  1. Unter Setup → Agents → Other integrations den Bereich Custom integrations öffnen
  2. Dort auf Individual program call instead of agent access klicken

Checkmk Other Integrations – Custom Integration für individuelle Programmaufrufe

  1. Eine neue Regel anlegen mit folgenden Einstellungen:
  • Description: jdss-rest-api
  • Command line to execute:
curl -k -s -X GET -u admin:DEIN_PASSWORT -H 'Content-Type: application/json' https://$_HOSTADDRESS_4$:82/api/v3/monitoring/check-mk | python3 -c 'import json,sys;obj=json.load(sys.stdin);print(obj["data"]["output"]);'
  • Condition type: Explicit conditions
  • Explicit hosts: Nur den Open-E Host auswählen (z. B. open-e-server)

Checkmk Regel-Konfiguration mit curl-Befehl und expliziter Host-Zuordnung

⚠️ Wichtig: Das Checkmk-Makro $_HOSTADDRESS_4$ wird zur Laufzeit automatisch durch die IPv4-Adresse des Hosts ersetzt. Die Regel sollte über Explicit hosts nur auf die Open-E Systeme beschränkt werden, damit der Befehl nicht versehentlich auf andere Hosts angewendet wird.

  1. Regel speichern und die Pending changes aktivieren

Schritt 5: Service Discovery durchführen
#

Nach dem Aktivieren der Änderungen kann die Service Discovery für den Open-E Host ausgeführt werden:

  1. Den Host öffnen und auf Save & run service discovery klicken
  2. Checkmk führt den konfigurierten curl-Befehl aus und erkennt automatisch alle verfügbaren Services

Das Ergebnis: Eine umfassende Übersicht aller Monitoring-Daten des Open-E Systems direkt in Checkmk.

Checkmk Services des Open-E Systems – Filesystems, Interfaces, CPU, Lüfter und mehr

Folgende Daten werden unter anderem überwacht:

  • Filesystems: Belegung und Trends aller Pools und Volumes
  • Netzwerk-Interfaces: Durchsatz, Fehler und Status der Bond- und Einzelinterfaces
  • CPU-Auslastung: Last und Prozessornutzung
  • IPM Sensoren: Lüfterdrehzahlen und Temperaturen
  • Heartbeat CRM: Cluster-Status und Ressourcen
  • Kompression und Deduplikation: Ratios der einzelnen Volumes

Schritt 6: Check-Parameter auf dem Open-E anpassen
#

Ein großer Vorteil der Checkmk-Integration in Open-E JovianDSS: Die Schwellwerte für die einzelnen Checks lassen sich direkt auf dem Storage-System konfigurieren – ohne Änderungen in Checkmk selbst.

Die Einstellungen sind über die Konsole des Open-E Systems erreichbar. Dazu per SSH oder direkt an der Konsole anmelden und unter Console tools → Add-ons → Check_MK Settings den Konfigurationsdialog öffnen:

Open-E Konsole – Check_MK Settings unter Console tools → Add-ons auswählen

Im Konfigurationsdialog stehen folgende Parameter zur Verfügung:

Open-E Checkmk Settings – Konfigurierbare Parameter für Schwellwerte und Intervalle

Nr.ParameterStandardwert
0Pool used capacity percent warning (%)80
1Pool used capacity percent critical (%)95
2Snapshot age warning (Sekunden)1800
3Snapshot age critical (Sekunden)3600
4SSD latency warning (ms)8
5SSD latency critical (ms)16
6HDD latency warning (ms)180
7HDD latency critical (ms)500
8System boot-disk latency warning (ms)120
9System boot-disk latency critical (ms)240
10SMART check intervalevery 2nd minute
11Restore defaults
12Disable Check_MK

Jeder Parameter kann einzeln angepasst werden. Nach der Änderung mit Save and Exit bestätigen.

💡 Tipp: Snapshot-Schwellwerte und Intervalle abstimmen
#

Besonders relevant sind die Snapshot-Age-Schwellwerte (Parameter 2 und 3). Standardmäßig wird eine Warnung ausgelöst, wenn der letzte Snapshot älter als 1800 Sekunden (30 Minuten) ist – bei über 3600 Sekunden (1 Stunde) wird der Check kritisch.

Das bedeutet: Die Snapshot-Erstellung auf dem Open-E sollte häufiger als alle 30 Minuten erfolgen, damit der Check nicht ständig anschlägt. Bei Stylite wurde das Snapshot-Intervall auf 20 Minuten eingestellt, um ausreichend Puffer zu haben.

Auch die Latenz-Schwellwerte für SSDs, HDDs und Boot-Disks sollten an die eigene Hardware angepasst werden. Die Standardwerte sind konservativ gewählt – in Hochleistungsumgebungen mit NVMe-SSDs können die SSD-Latenzschwellwerte ggf. noch niedriger angesetzt werden.

Fazit
#

Die Integration von Open-E JovianDSS in Checkmk über die REST API ist unkompliziert und liefert umfangreiche Monitoring-Daten ohne zusätzlichen Agenten. Mit einem einzigen curl-Befehl werden sämtliche relevanten Storage-Metriken – von Filesystem-Auslastung über Netzwerk-Interfaces bis hin zu Hardware-Sensoren – direkt in Checkmk verfügbar.

Für Fragen zur Implementierung oder spezifischen Anwendungsfällen im Storage-Monitoring stehe ich gerne zur Verfügung.


Wim Bonis ist CTO bei Stylite AG und beschäftigt sich schwerpunktmäßig mit Storage-Lösungen und IT-Infrastruktur.

Verwandte Artikel

Hot Spares in ZFS: Warum ein Hot-Spare oft mehr Risiko als Nutzen bringt
Wim Bonis
Storage ZFS RAID Open-E TrueNAS
ZFS Snapshot-Replikation in TrueNAS SCALE: Remote Backup mit Push und Pull
Wim Bonis
Storage ZFS TrueNAS Backup Replikation
S2N Konferenz 2025: Digitale Souveränität und Cyber-Resilienz im Fokus
Wim Bonis
Matteo Keller
News Storage Security Cloud
Can't Live Without You? Die Firewall-Illusion und die Realität
Wim Bonis
Security Firewall IT-Management Vendor-Beziehungen Open Source
OpenZFS Virtualisierung: Storage-Lösungen für moderne Infrastrukturen
Wim Bonis
Storage Tools ZFS
Ransomware: Geschichte, Schutzmaßnahmen und ZFS als Verteidigungslinie
Wim Bonis
Storage Security ZFS
TrueNAS Fans aufgepasst: Neue Features und Updates
Wim Bonis
Storage News ZFS
TrueNAS F-Serie: Performance-optimierte Storage-Lösungen
Wim Bonis
Storage Performance
FreeNAS, TrueNAS Core und OpenZFS: Ein Überblick
Wim Bonis
Storage Tools ZFS