Zabbix SSD Monitoring 2026: NVMe, SMART und Pushover-Alarme

Zabbix SSD Monitoring 2026 – Praxisleitfaden für zuverlässige Datenträger- und Windows-Server-Überwachung.

Ein Speicherausfall kommt selten völlig ohne Warnsignale. Freie Kapazität schrumpft über Wochen, Log-Dateien wachsen unerwartet, Backups belegen zusätzliche Volumes oder NVMe-Laufwerke melden steigenden Verschleiß. Trotzdem bleiben Warnungen in Unternehmen manchmal unbeachtet, weil nur das Gesamtlaufwerk überwacht wird, Trigger falsch gesetzt sind oder niemand die Meldung erhält. Zabbix SSD Monitoring 2026 kombiniert automatische Dateisystemerkennung, belastbare Speichergrenzen, Prognosen und SMART-Telemetrie mit mobilen Benachrichtigungen. Dieser Praxisleitfaden erklärt die Umsetzung für Windows Server und gemischte IT-Infrastrukturen – inklusive Zabbix Agent 2, NVMe-Status und der offiziellen Pushover-Webhook-Integration.

Autor: Salman Dolatpanah Gortlar · GORTNET IT-Dienstleistungen · 30. Oktober 2026

Kernempfehlung: Kapazität, Wachstum und Hardwaregesundheit getrennt überwachen und kritische Probleme bis zum Bereitschaftsteam testen.

Warum Speicherüberwachung mehr als eine Prozentzahl ist

Eine Partition mit 90 Prozent Nutzung kann auf einem riesigen Datenvolume noch ausreichend Spielraum bieten. Dieselben 90 Prozent auf einer kleinen Systempartition können dagegen bedeuten, dass Windows-Updates, Logs oder temporäre Dateien sofort Probleme bekommen. Auslastung in Prozent und absolut verfügbarer Platz müssen deshalb gemeinsam bewertet werden. Ebenso wichtig ist die Veränderung über die Zeit: Eine Systempartition, die innerhalb eines Tages um 15 Gigabyte wächst, benötigt eine andere Reaktion als ein seit Monaten stabil gefülltes Archiv.

Trennen Sie drei Risiken: Kapazitätsmangel, technische Datenträgerfehler und Probleme beim Backup beziehungsweise Restore. Diese Risiken sind verbunden, aber nicht identisch. Ein SSD-Laufwerk mit sehr guten SMART-Werten kann aus Platzmangel eine Anwendung stoppen. Umgekehrt kann eine fast leere SSD plötzlich kritische Gerätefehler melden. Für jedes Risiko benötigt das Monitoring passende Items, Triggers und Reaktionsschritte.

Zabbix SSD Monitoring 2026: Inventar und Zuständigkeiten

Erstellen Sie zunächst eine Liste der produktiven Server, Volumes, virtuellen Datenträger und wichtigen Dateisysteme. Ergänzen Sie Laufwerksbuchstaben, Mount-Points, Dienste und die verantwortlichen Administrationsgruppen. Eine Windows-C:-Partition benötigt gewöhnlich andere Grenzwerte als ein großes Archivvolume. SQL-Datenbanken, VM-Storage, Protokollpartitionen und Backup-Repositories müssen daher nach ihrer tatsächlichen Funktion betrachtet werden.

Bei mehreren Umgebungen helfen Hostgruppen und Templates für DEV, TEST, QA und PROD, ohne automatisch identische Schwellenwerte für jede Laufwerksklasse vorzugeben. Hinterlegen Sie pro Host technische Verantwortung und Eskalation. Es reicht nicht, alle Speicherprobleme einem allgemeinen Dashboard zuzuordnen, wenn ein kritischer Alarm nachts keinem aktiven Ansprechpartner zugestellt wird. Dokumentieren Sie außerdem, welche Mount-Points nicht überwacht oder ausdrücklich ignoriert werden sollen.

Filesystem Low-Level Discovery verwenden

Zabbix bietet Low-Level Discovery für Dateisysteme. Damit können nach unterstützter Agent-Konfiguration neu auftauchende Partitionen automatisch gefunden und passende Items und Trigger-Prototypen erzeugt werden. Für Windows existieren Dateisystemmetriken wie verfügbarer und insgesamt nutzbarer Platz. Der Administrator muss jedoch prüfen, welche Disks und Dateisystemtypen tatsächlich erfasst werden und ob Filter für Spezialpartitionen oder entfernte Volumes geeignet sind.

Verwenden Sie ein gepflegtes Windows-Template als Ausgangspunkt und ändern Sie Discovery-Filter nachvollziehbar. Eine kleine Wiederherstellungspartition sollte nicht ungewollt dieselbe Alarmflut erzeugen wie ein produktives Datenlaufwerk. Prüfen Sie nach der Template-Zuweisung die entdeckten Dateisysteme gegen die tatsächliche Windows-Datenträgerverwaltung. Erst wenn die Erkennung stimmt, lassen sich zuverlässige Trigger mit den korrekten Volume-Labels und Laufwerksbuchstaben erstellen.

Warn- und Critical-Grenzen differenziert festlegen

Für einen ersten Pilot kann ein Warning bei etwa 80 Prozent und ein Critical bei 90 Prozent Belegung dienen. Diese Beispielwerte sind jedoch keine universelle Empfehlung für sämtliche Volumes. Auf einem SQL-Log-Laufwerk oder einer kleinen C:-Partition kann zusätzlich ein absoluter Grenzwert in Gigabyte notwendig sein. Für große Storage-Systeme muss geprüft werden, wie viel Platz bei der vorhandenen Änderungsrate für mehrere Tage Betrieb tatsächlich benötigt wird.

Definieren Sie die Grenzen anhand des Dienstes und der Reaktionszeit. Wenn am Wochenende niemand zusätzliche Kapazität bereitstellen kann, muss eine Warnung deutlich früher erfolgen. Ein kleiner freier Restwert lässt sich durch Warnschwellen, Wachstumstrends und die Zeit bis zur vorhersehbaren Erschöpfung bewerten. Testen Sie die Trigger zunächst mit kontrollierten Werten, statt darauf zu warten, dass die erste produktive Festplatte voll ist.

Prognosen und Wachstumsraten auswerten

Zabbix unterstützt Trend- und Prognosefunktionen, die für Kapazitätsplanung hilfreich sein können. Eine steigende Belegung kann beispielsweise eine erwartete Zeit bis zur Erreichung einer Grenze nahelegen. Solche Vorhersagen sind jedoch Schätzungen auf Basis vergangener Daten. Unregelmäßige Backupzyklen, monatliche Wartungen und sprunghaftes Logwachstum können einfache Trends verfälschen.

Ergänzen Sie daher eine zweite Warnlogik für außergewöhnliches Wachstum. Ein plötzliches Anwachsen von Logfiles oder Dump-Verzeichnissen ist auch dann interessant, wenn noch relativ viel freier Platz vorhanden ist. Die Prognose sollte nachvollziehbar auf historischen Messungen beruhen und mit der tatsächlichen Anwendungstätigkeit abgeglichen werden. Eine gute Strategie priorisiert sowohl drohende Kapazitätsengpässe als auch unerwartete Änderungen.

SMART und NVMe: Der Unterschied zur Kapazitätsmessung

S.M.A.R.T. liefert je nach Laufwerk Informationen zum technischen Zustand, zu Fehlern, Temperatur, Verschleiß oder verbleibender Lebensdauer. Zabbix Agent 2 stellt dafür die Itemkeys smart.disk.discovery und smart.disk.get bereit. Die offizielle Dokumentation nennt HDD, SSD und NVMe als grundsätzlich unterstützte Laufwerkstypen. Tatsächlich verfügbare Attribute sind allerdings von Hardware, Firmware, Controller und Betriebssystem abhängig.

Auf Windows sind nicht alle Discovery-Parameter identisch mit Linux: Der zusätzliche Discovery-Typ id wird nach Zabbix-Dokumentation auf Windows nicht unterstützt. Prüfen Sie die eingesetzte Agent-2-Version und die dazugehörigen SMART-Tools, Berechtigungen und Plugin-Einstellungen. Ein nicht entdecktes Laufwerk ist nicht automatisch gesund. Besonders Hardware-RAIDs oder Storagecontroller können SMART-Werte abschirmen, sodass ergänzende Herstellerüberwachung notwendig wird.

Zabbix Agent 2 für SMART prüfen

Bei Zabbix Agent 2 erfolgt die SMART-Abfrage über das entsprechende Plugin beziehungsweise die unterstützten Hilfsprogramme. Der Windows-Dienst muss die benötigten Hardwareinformationen lesen können. Testen Sie zunächst auf einem einzelnen, möglichst nicht geschäftskritischen Server, ob die lokale SMART-Erkennung sinnvolle JSON-Daten zurückgibt. Vergleichen Sie Seriennummer, Modell und Laufwerkspfad mit dem tatsächlichen Gerätebestand, bevor die Werte in ein produktives Template übernommen werden.

Achten Sie auf Rechte, ausführbare Tool-Pfade und die Funktionsfähigkeit nach einem Agent-Update. Externe Hardwarecontroller benötigen unter Umständen herstellerspezifische Managementwerkzeuge oder SNMP. Wenn sich ein physisches NVMe-Laufwerk hinter einem virtuellen Disk-Controller befindet, kann die VM selbst oft nur die virtuelle Kapazität und nicht den realen Verschleiß sehen. Der physische Storage-Zustand muss dann am Hypervisor oder Storage-System überwacht werden.

SMART-Attribute nicht blind als Prozentwerte interpretieren

SMART-Attribute sind je nach Hersteller unterschiedlich kodiert. Ein Fehlerzähler bei einer SAS-Disk ist nicht automatisch mit einem NVMe-Medienfehlerwert gleichzusetzen. Auch die Anzeige von verbleibender Lebensdauer oder Percentage Used hat ein geräteabhängiges Verständnis. Verwenden Sie nur die im konkreten Datenträgertyp verlässlich interpretierten Felder und halten Sie deren Einheit und Aussagekraft im Monitoring dokumentiert fest.

Erstellen Sie Alarme für nachweislich relevante Fehlerzustände wie auffällige Medienfehler, kritische Warnungen, bestimmte Temperaturzustände oder deutlich erhöhten Verschleiß. Ein einzelner nicht kritischer Rohwert sollte nicht ohne Herstellerbezug einen nächtlichen Notfall auslösen. Für hochverfügbare Storage-Systeme gehören Controller- und RAID-Warnungen ausdrücklich dazu. Monitoring muss physische Fehler rechtzeitig identifizieren, nicht nur irreführende Ampelfarben erzeugen.

Hysterese und Trigger-Abhängigkeiten gegen Alarmflut

Ohne Hysterese kann ein Dateisystem an einer Schwelle ständig zwischen Problem und Recovery wechseln. Ein Backupjob belegt vorübergehend Platz, räumt ihn wieder frei und erzeugt jedes Mal mehrere Push-Nachrichten. Nutzen Sie geeignete Recovery-Schwellen und Trigger-Abhängigkeiten, damit ein Critical-Zustand den darunterliegenden Warning-Alarm nicht unnötig vervielfacht. Dokumentieren Sie außerdem Wartungsfenster und erwartete Spitzen der Laufwerkslast.

Eine Eskalation sollte stets die Dringlichkeit des Ereignisses widerspiegeln. Eine reine Kapazitätswarnung kann während der Geschäftszeit bearbeitet werden, ein unmittelbar drohender Datenbank- oder Backupausfall benötigt schnellere Reaktion. Definieren Sie, welche Trigger eine separate Nachricht auslösen dürfen und wann mehrere Symptome als ein zusammengehöriger Incident behandelt werden. Gute Alarmqualität spart Zeit und erhöht die Wahrscheinlichkeit, dass Mitarbeitende die wirklich wichtigen Meldungen beachten.

Pushover als offizielle Zabbix-Webhook-Integration

Zabbix stellt eine offizielle Pushover-Integration als Webhook-Medientyp bereit. Dafür wird auf Pushover-Seite ein Konto mit Anwendungstoken und Empfängerschlüssel eingerichtet. In Zabbix wird der Media Type importiert beziehungsweise konfiguriert und dem vorgesehenen Benutzerprofil zugewiesen. Die Herstellerdokumentation beschreibt zudem ein Makro für die URL des Zabbix-Frontends, damit Alarmnachrichten direkt zur betreffenden Problemansicht führen können.

Verwenden Sie keine Pushover-API-Tokens in öffentlichen Tickets oder Screenshots. Legen Sie fest, welche Zabbix-Actions die Nachricht an welche Bereitschaftsgruppe weiterleiten und was außerhalb der Arbeitszeit gilt. Eine technisch erfolgreiche API-Anfrage beweist noch nicht, dass der zuständige Mitarbeiter den Alarm gesehen hat. Testen Sie die gesamte Kette bis zum Endgerät, einschließlich Internetzugang, Pushover-Konto, Benachrichtigungseinstellungen und der anschließenden Recovery-Nachricht.

Action-Logik für Warning, High und Disaster

Ein effektiver Benachrichtigungsplan unterscheidet mindestens Warnungen und kritische Ausfälle. Bei gewöhnlichem Wachstum der C:-Partition kann eine Nachricht an das IT-Team genügen. Wenn eine produktive SQL-Partition innerhalb weniger Stunden vollzulaufen droht oder ein RAID-Datenträger ausfällt, ist eine klar priorisierte Eskalation sinnvoll. Die Zabbix-Trigger-Severity und passende Action-Conditions liefern dafür die Grundlage.

Richten Sie zudem einen zweiten Kommunikationsweg für den Ausfall des Monitoring-Servers selbst ein. Ein ausschließlich über dasselbe Zabbix-System ausgelöster Alarm kann nicht funktionieren, wenn dessen Backend nicht erreichbar ist. Dokumentieren Sie, wie ein Bereitschaftsteam die Ursache beurteilt und wann weitere Verantwortliche informiert werden müssen. Pushover ist ein Benachrichtigungskanal und keine vollständige Incident-Management-Plattform.

Zabbix Dashboard für Storage-Verantwortliche gestalten

Ein übersichtliches Storage-Dashboard zeigt die wichtigsten betroffenen Hosts, genutzte und freie Kapazität, Wachstumsrate, SMART-Status sowie laufende Trigger. Gruppieren Sie nach Systemkritikalität und Geschäftsdienst, nicht allein nach Alphabet. Für Windows-Server sollten wichtige Volumes einzeln sichtbar sein; ein gemittelter Wert über alle Laufwerke würde kritische Engpässe verdecken.

Verknüpfen Sie Problemwidgets mit passenden historischen Graphen und der verantwortlichen Hostgruppe. Zeigen Sie nach Möglichkeit den Zeitpunkt der letzten gültigen SMART-Abfrage und den Zustand des Agenten. Ein grüner Zustand ohne aktuelle Daten darf nicht als erfolgreicher Hardwarecheck gelten. Ergänzen Sie eine Liste ungeklärter Exceptions, damit bekannt ist, welche Geräte nicht unter die normale automatische Discovery fallen.

30-Tage-Einführung ohne unnötige Produktionsrisiken

Woche eins: Windows-Volumes, Datenträgertypen und vorhandene Zabbix-Templates inventarisieren. Woche zwei: File-System-Discovery überprüfen, Kapazitätsgrenzen und passende Recovery-Schwellen festlegen. Woche drei: SMART-Daten auf unterstützten physischen Hosts testen und RAID-Ausnahmen dokumentieren. Woche vier: Pushover-Webhooks einrichten, Benachrichtigungsketten testen und das Dashboard nach tatsächlichen Alarmen verbessern.

Nutzen Sie zum Test einen kontrollierten Pilot und simulieren Sie realistische Trigger, ohne produktive Volumes absichtlich bis zur Vollauslastung zu füllen. Messen Sie Zeit bis zur Erkennung, Zustellung und Bearbeitung. Die Einführung ist erst dann abgeschlossen, wenn auch die Wiederherstellung eines Problems korrekt signalisiert wird und kritische Meldungen eine eindeutige technische Verantwortung besitzen.

Häufige Fragen zu Zabbix SSD Monitoring 2026

Kann Zabbix SSD-Verschleiß direkt aus jeder Windows-VM lesen?

Nein. SMART-Daten können durch Virtualisierung und Controller verborgen bleiben. Dann ist die physische Storage-Plattform die richtige Überwachungsquelle.

Sind 80 und 90 Prozent immer passende Grenzwerte?

Nein. Sie eignen sich nur als Ausgangspunkt. Für kleine Systempartitionen und schnell wachsende Datenvolumes sind individuelle und absolute Werte nötig.

Unterstützt Zabbix Agent 2 NVMe- und SSD-SMART-Werte?

Die offizielle Dokumentation nennt HDD, SSD und NVMe; die tatsächlich verfügbaren Felder hängen von Hardware, Betriebssystem und Controller ab.

Ersetzt Pushover einen Bereitschafts- oder Incident-Prozess?

Nein. Der Webhook transportiert Alarme. Eskalationsregeln und verantwortlich zugewiesene Mitarbeitende müssen getrennt definiert werden.

Fazit: Früherkennung statt Notfalleinsatz

Zabbix SSD Monitoring 2026 liefert echten Mehrwert, wenn automatische Discovery, sinnvolle Schwellen, Hardwarediagnose und überprüfte Pushover-Benachrichtigungen ineinandergreifen. Eine technische Kennzahl ohne Reaktionsweg verhindert keinen Ausfall. Unternehmen sollten den Status nicht nur einmalig konfigurieren, sondern nach Änderungen an Storage, Windows oder Agenten regelmäßig kontrollieren.

Über den Autor

Salman Dolatpanah Gortlar veröffentlicht für GORTNET technische Leitfäden zu Serverbetrieb, Überwachung und IT-Sicherheit. Die dargestellten Schwellen sind Beispiele für ein Risiko-basiertes Konzept und müssen auf den jeweiligen Server zugeschnitten werden.

Weiterführende Artikel und GORTNET-Leistungen

• Zabbix mit KI und Monitoring kombinieren
• Disaster Recovery Plan testen
• Zabbix Monitoring bei GORTNET

Für eine individuell konzipierte Storage-Überwachung GORTNET kontaktieren.

Offizielle Zabbix-Dokumentation

• Zabbix Agent 2: Item Keys und SMART
• Zabbix: Pushover-Integration
• Zabbix: Low-Level Discovery
• Zabbix: Trigger-Konfiguration

Stand 30. Oktober 2026. Unterstützte Hardware- und Agentfunktionen nach installierter Zabbix-Version und Controller-Modell prüfen.