PRTG-Benachrichtigungen: Warum 80% der Alarme ignoriert werden

In fast jeder PRTG-Installation, die ich als Trainer oder Berater sehe, gibt es einen Outlook-Ordner namens „PRTG" mit 4.000 ungelesenen Mails. Das Monitoring läuft technisch einwandfrei. Nur liest niemand mehr, was es meldet. Das ist Alarm-Müdigkeit und sie macht jedes Monitoring wertlos.

Das Problem: Wenn alles rot blinkt, blinkt nichts

Alarm-Müdigkeit entsteht nicht über Nacht. Sie schleicht sich ein. Erst kommt die eine Mail zu viel bei einem geplanten Neustart. Dann kommen 40 Mails gleichzeitig, weil ein Switch kurz wackelt. Irgendwann erstellt jemand die Outlook-Regel: Betreff enthält „PRTG" → verschieben in Unterordner. Ab dem Moment ist das Monitoring tot, auch wenn der Server noch läuft.

Das Ergebnis sehe ich in meinen PRTG-Audits regelmäßig: Teams, die PRTG installiert haben, Sensoren pflegen, Lizenzen bezahlen, aber bei einem echten Ausfall trotzdem erst reagieren, wenn ein Anwender anruft. Das Monitoring hat seinen Zweck verloren.

Die 5 häufigsten Ursachen

1. Default-Schwellwerte nie angepasst

PRTG bringt bei den meisten Sensoren sinnvolle Defaults mit. Sinnvoll im Sinne von: lieber einmal zu viel warnen als einmal zu wenig. Das führt dazu, dass ein CPU-Sensor bei 90% für 10 Sekunden bereits „Warning" meldet. Auf einem Server, der gerade Windows-Updates installiert oder ein Backup komprimiert, ist das kein Problem. Es ist Normalbetrieb.

Wenn 200 Server mit Default-Schwellwerten laufen, kommen täglich Dutzende Warnungen rein, die alle korrekt sind (die CPU war kurz über 90%) und gleichzeitig alle irrelevant. Der Admin lernt schnell: Warning-Mails kann ich ignorieren. Und ab da ignoriert er auch die, die er nicht ignorieren sollte.

2. Jeder Sensor benachrichtigt einzeln

Ein klassisches Szenario: Ein Core-Switch startet nach einem Firmware-Update neu. Downtime: 90 Sekunden. In diesen 90 Sekunden melden sich alle Geräte hinter dem Switch als „Down". Bei einem Standort mit 40 Geräten sind das 40 separate E-Mails, jede mit eigenem Betreff, jede mit eigener Notification. Der Admin öffnet Outlook und sieht 40 rote Mails. Die eigentliche Information (Switch war kurz weg) geht unter.

3. Keine Abhängigkeiten konfiguriert

PRTG hat ein gutes Dependency-System. Du kannst jedem Sensor einen „Master-Sensor" zuweisen. Wenn der Master-Sensor ausfällt, werden alle abhängigen Sensoren automatisch pausiert statt alarmiert. Das verhindert genau die Kaskade aus Punkt 2.

In der Praxis sehe ich das fast nie konsequent konfiguriert. Die Auto-Dependencies auf Device-Ebene sind gesetzt (Ping als Master), aber die Netzwerktopologie ist nicht abgebildet. Ein Router fällt aus, 80 Sensoren dahinter melden sich einzeln. Dabei hätte eine einzige Meldung gereicht: „Router Standort-B ist down."

4. Eskalationsstufen fehlen

In vielen Installationen geht jede Benachrichtigung an die gleiche Verteilergruppe, sofort, ohne Abstufung. Das bedeutet: der Junior-Admin bekommt die gleiche Mail wie der Teamleiter, ob es ein Warning auf einem Testsystem ist oder ein Down auf dem Produktions-Datenbankserver.

Ohne Eskalation gibt es keine Priorisierung. Und ohne Priorisierung liest irgendwann niemand mehr die Mails, weil alle gleich aussehen.

5. Wartungsfenster nicht gepflegt

Jeden Dienstag um 22 Uhr laufen die Windows-Updates. Jeden ersten Samstag im Monat läuft das Backup-Fenster. Jeden Morgen um 6 startet der Batch-Job, der kurz alle CPU-Kerne auslastet. Das weiß das Team. PRTG weiß es nicht.

Die Folge: Jede Patch-Nacht produziert 30 bis 50 Fehlalarme. Reboots, kurze Downtimes, CPU-Spitzen. Alles erwartet, alles dokumentiert, alles ignoriert. Und weil die Mails am nächsten Morgen schon im Ordner liegen, werden sie zusammen mit den echten Problemen der Nacht weggeklickt.

Pragmatische Fixes: 5 Ursachen, 5 Lösungen

Schwellwerte anpassen

Die wichtigste Änderung ist oft die einfachste. CPU-Warning von 90% auf 95% hochsetzen und die Dauer von 10 Sekunden auf 5 Minuten. Das filtert alle kurzzeitigen Spitzen raus und meldet nur echte Dauerlast. Für Festplatten: Warning bei 10% frei statt bei 20%. Für Ping-Sensoren: Timeout von 1000ms auf 3000ms, wenn die Leitung über WAN geht.

Der Grundsatz: Ein Schwellwert muss so gesetzt sein, dass die Benachrichtigung eine Handlung auslöst. Wenn die Reaktion auf eine Warning-Mail regelmäßig „ist normal" ist, dann ist der Schwellwert falsch.

State-Trigger statt Einzelmeldungen

PRTG unterscheidet zwischen „Zustandsänderung" und „wiederholter Benachrichtigung". Der State-Trigger meldet nur den Wechsel: von OK auf Warning, von Warning auf Down, von Down auf OK. Das reduziert die Menge drastisch, weil nicht jeder einzelne Messwert eine Mail erzeugt, sondern nur der Übergang.

Dependencies in der Device-Tree-Struktur

Die Faustregel: Jedes Gerät im PRTG-Baum sollte eine Dependency auf den nächsthöheren Netzwerkknoten haben. Server hängen am Access-Switch, Access-Switches am Distribution-Switch, Distribution-Switches am Core. Fällt der Core aus, meldet nur der Core. Alles dahinter wird automatisch pausiert. Das ist 30 Minuten Konfigurationsarbeit, die hunderte überflüssige Alarme verhindert.

Eskalation in 3 Stufen, aber nicht für alles gleich

Eine bewährte Struktur, die in Audits als Zielbild dient:

1. Sofort: Ticket im Ticketsystem erstellen (kein Mensch wird benachrichtigt)
2. Nach 15 Minuten ohne Quittierung: Benachrichtigung an den diensthabenden Admin, Kanal abhängig von Zeit und Kritikalität (siehe unten)
3. Nach 30 Minuten: Anruf beim Teamleiter

Die Stufe 1 ist entscheidend. Wenn die erste Reaktion ein automatisches Ticket ist statt einer E-Mail, fällt der Outlook-Ordner als Engpass weg. Das Ticket hat eine Nummer, einen Status, einen Verantwortlichen. Es verschwindet nicht im Posteingang. Für Stufe 2 gilt: es gibt keine pauschale Regel. Ob SMS, Push-Notification oder E-Mail der richtige Kanal ist, hängt davon ab, ob Werktag oder Wochenende ist und ob es ein kritisches oder unkritisches System betrifft.

Werktags vs. Wochenende

Die Eskalationsregel ist nicht 24/7 gleich. Werktags reicht für Stufe 2 oft die PRTG-App-Push-Notification oder ein E-Mail-Popup. Der Admin sitzt am Rechner, hat PRTG-App auf dem Smartphone, Mail-Client ist offen. Am Wochenende oder nachts sieht das anders aus. Niemand hat nebenbei Outlook offen, nicht jeder nutzt die PRTG-App privat. Für Out-of-Hours muss Stufe 2 eine SMS sein, die piept auch, wenn das Handy im Flur liegt. Konkret heißt das: 2 parallele Notification-Trigger mit Schedule-Zuweisung. Einer für Mo–Fr 08–18 Uhr (Push/Mail), einer für Wochenende und Nachtzeiten (SMS).

Kritisch vs. unkritisch: nicht alles braucht SMS

Der zweite Differenzierungs-Hebel: welche Systeme lösen welche Eskalationskette aus. Ein ausgefallener Domain-Controller am Sonntag um 03:00 rechtfertigt eine SMS. Ein voller Drucker-Spooler auf Sekretariats-PC Nummer 17 nicht. Praxis-Regel:

• Kritische Systeme (Domain-Controller, zentraler Fileserver, Firewall, ERP-Datenbank, Internet-Uplink): volle Eskalation inkl. SMS, auch am Wochenende. Hier darf man geweckt werden.
• Unkritische Systeme (Drucker, Einzelplatz-Rechner, interne Test-Umgebungen, nicht-produktive VMs): Ticket am Anfang, Benachrichtigung per Mail am nächsten Werktag. Keine SMS, nie. Das kostet nur Nerven und verwässert die Reaktionsfähigkeit bei echten Problemen.

Umsetzung in PRTG: Kritische Systeme bekommen ein eigenes Tag (z.B. critical-24x7) und die Notification-Trigger filtern auf dieses Tag. Alles andere läuft über einen Standard-Trigger ohne SMS. Der Aufwand ist einmalig, die Wirkung dauerhaft.

Schedules und Maintenance Windows

Für wiederkehrende Wartungsfenster bietet PRTG Schedules. Der Patch-Dienstag bekommt einen Schedule von 22:00 bis 02:00, in dem Benachrichtigungen unterdrückt werden. Für einmalige Wartungen gibt es die manuelle Pause mit Begründung und automatischer Wiederaufnahme. 10 Minuten Setup pro Wartungsfenster sparen Dutzende Fehlalarme pro Monat.

Vorher/Nachher: Was sich konkret ändert

Die Reduktion um 80 bis 90% klingt optimistisch. In der Praxis ist sie realistisch, weil der größte Teil des Rauschens aus fehlenden Dependencies und nicht angepassten Schwellwerten stammt. Das sind keine komplexen Änderungen, sondern Konfigurationsarbeit.

Quick-Win: Die „Inbox Zero"-Methode für PRTG

Wenn du morgen anfangen willst, ohne alles umzubauen: Erstelle einen neuen Notification-Template, der nur für echte Handlungsaufforderungen genutzt wird. Nenne ihn „Action Required". Dieser Template geht an eine eigene Verteilergruppe mit maximal 3 Personen. Alle bestehenden Notifications bleiben wie sie sind und laufen weiter in den bisherigen Ordner.

Dann identifizierst du die 10 wichtigsten Sensoren in deiner Umgebung: Produktions-Datenbank, ERP-Server, Core-Switches, Internet-Uplink, Firewall. Diese 10 Sensoren bekommen den neuen Template zugewiesen. Alles andere bleibt beim Alten.

Das Ergebnis: Du hast sofort einen sauberen Kanal, der nur meldet, was wirklich zählt. Die restlichen 500 Sensoren laufen weiter wie bisher, aber du musst ihren Output nicht mehr lesen. Du liest nur noch „Action Required". Das ist der erste Schritt raus aus der Alarm-Müdigkeit.

Fazit: Weniger Alarme bedeuten mehr Reaktion

Das Ziel eines Monitoring-Systems ist nicht, möglichst viele Mails zu verschicken. Das Ziel ist, dass jemand reagiert, wenn es darauf ankommt. Jede Benachrichtigung, die ignoriert wird, trainiert das Team darin, Benachrichtigungen zu ignorieren. Das ist ein Teufelskreis, der sich nur durchbrechen lässt, indem man das Volumen radikal reduziert.

Die gute Nachricht: Die 5 Ursachen in diesem Artikel sind in den meisten Installationen innerhalb von 2 bis 3 Tagen behebbar. Keine Code-Änderungen, kein Toolwechsel, nur saubere Konfiguration. Und der Effekt ist sofort messbar: weniger Mails, höhere Lesequote, schnellere Reaktion.

In meinen PRTG-Schulungen sage ich oft: Ein Monitoring, das 100 Mails am Tag verschickt, ist kein Monitoring. Es ist Spam. Die Kunst liegt im Weglassen.

Falls du tiefer einsteigen willst: Im Artikel PRTG-Altlasten: Was in jeder Installation steckt beschreibe ich die typischen Altlasten, die oft Hand in Hand mit der Alarm-Müdigkeit gehen. Und im Artikel PRTG-API: Automation und Sanierung mit Python zeige ich, wie sich Schwellwerte und Dependencies per Skript über hunderte Sensoren gleichzeitig anpassen lassen.

Wer die wichtigen PRTG-Alarme am Ende übersichtlich in einem Dashboard für die Geschäftsführung bündeln will, findet das beim Grafana-Spezialist (NRW, RLP, Rhein-Main).