PRTG-Altlasten: Was in fast jeder gewachsenen Installation steckt

Wenn ich ein PRTG sehe, das seit 5 oder mehr Jahren läuft, weiß ich, was mich erwartet. Nicht weil die Admins schlampig waren, sondern weil Monitoring-Hygiene im Alltag immer hinten rüber fällt. Hier die 5 wiederkehrenden Altlasten, die ich in nahezu jeder Umgebung finde.

1. Die Namens-Kollektion aus 3 Epochen

Das erste, was ins Auge fällt, ist nie ein Fehler. Es ist die Namenskonvention, oder besser gesagt: ihr Fehlen. In gewachsenen Installationen finde ich typischerweise 3 bis 5 unterschiedliche Namensschemata nebeneinander:

• CPU Load (die ursprüngliche, kurze Variante)
• CPU_Load_% (die "wir brauchen Unterstriche für SNMP"-Phase)
• Server01 - CPU Last (der deutsche Zwischenruf)
• CPU Usage [%] (der englische Neu-Anlauf)
• old_CPULoad_DEPRECATED (die Warnung, die niemand befolgt hat)

Das ist kein Zeichen von Inkompetenz. Es ist ein Zeichen dafür, dass mindestens 2 verschiedene Administratoren zu verschiedenen Zeiten gedacht haben „ab jetzt machen wir es besser". Und der alte Bestand wurde nie migriert.

Warum das zählt: Sobald jemand ein Dashboard, eine Notification-Regel oder einen SNMP-basierten Filter über Sensornamen matchen will, werden inkonsistente Namen zur Falle. Ein Filter auf *CPU* trifft alles, CPU_Load* trifft nur die zweite Epoche. Alarme gehen an die falschen Leute, Reports zeigen Lücken.

2. Die pausierten Leichen

Wenn ich in der Sensor-Liste nach dem Pause-Filter sortiere, finde ich fast immer einen erstaunlich hohen Anteil pausierter Sensoren. Und wenn ich die Pause-Begründungen durchklicke, finde ich Perlen wie:

• "check later"
• "TBD"
• "pausiert Martin 2019"
• "temporär aus - Ticket #4372" (Ticket existiert nicht mehr)
• leer, ganz oft einfach leer

"Temporär aus" ist die Lüge, die Administratoren sich selbst erzählen, wenn sie keine Zeit haben, sauber zu entscheiden.

Jeder dieser pausierten Sensoren ist eine offene Entscheidung: Wird er noch gebraucht? Ist das zu überwachende System überhaupt noch da? War der ursprüngliche Grund mal gültig und ist inzwischen längst vergessen? In den meisten Fällen kann man mindestens die Hälfte dieser Pause-Leichen nach einer kurzen Prüfung ohne weiteres löschen.

3. Tags, die sich widersprechen

Tags sind eine von PRTGs besten Ideen. Ein flaches, übergreifendes Klassifizierungssystem, das über Ordnerstrukturen hinweg funktioniert. In der Theorie.

In der Praxis finde ich auf einem einzigen Sensor regelmäßig Tag-Kombinationen wie:

• wichtig + obsolete (gleichzeitig wichtig und veraltet?)
• v1 + v2 + v2_final (3 Versionen, eine Wahrheit)
• keep + delete_me (der Administrator konnte sich nicht entscheiden)
• 2019 + 2021 + 2024 (Jahre als Tags sind fast immer ein Symptom)
• DE, de, german, deutsch (gleiche Semantik, 4 Schreibweisen)

Der Grund: Tags werden ergänzt, fast nie entfernt. Jeder Administrator fügt seine eigene Klassifikation hinzu, niemand räumt alte auf. Das Ergebnis ist ein Tag-Friedhof, der seine eigentliche Funktion verliert, selektives Filtern.

4. Maps, die niemand mehr kennt

Ich bin in genügend PRTG-Installationen gewesen, um sagen zu können: Jede Installation hat mindestens eine Map, die niemand mehr erklären kann. Oft mehrere. Sie stehen im Map-Menü, sie zeigen irgendwas, waren mal farbig. Der Admin, der sie gebaut hat, ist längst bei einem anderen Arbeitgeber und niemand traut sich, sie zu löschen.

Noch schlimmer: Maps, die existieren, aber nicht mehr funktionieren. Sensoren wurden gelöscht, die Map zeigt jetzt "Sensor nicht gefunden" an roten Punkten. Die Map suggeriert Ausfälle, wo keine sind.

Die Frage, die ich Admin-Teams dann stelle, ist immer: „Wann hat das letzte Mal jemand auf diese Map geschaut, um eine Entscheidung zu treffen?" In den meisten Fällen ist die Antwort: "Weiß ich nicht. Lange nicht."

5. Fehlende Dependencies und die Alarm-Flut, die daraus entsteht

Die technisch interessanteste Altlast und gleichzeitig die schmerzhafteste, weil sie erst im Ernstfall wehtut. PRTG hat ein hervorragendes Dependency-System: Du kannst einem Sensor sagen „melde mich nur, wenn mein Master-Sensor grün ist". Damit verhinderst du, dass beim Ausfall eines Routers gleichzeitig 87 Sensoren roten Alarm schlagen.

Das Problem: Dependencies werden fast nie konsequent gesetzt. Was ich typischerweise sehe:

• Der primäre Router ist als Master definiert, alle darunter hängenden Sensoren haben eine Auto-Dependency auf den Router-Ping
• Aber: Switches dazwischen sind nicht berücksichtigt. Fällt ein Distribution-Switch aus, alarmieren 40 Sensoren parallel, obwohl ein einziger die Ursache wäre
• Noch schlimmer: Redundant angebundene Server haben 2 Uplinks, aber die Dependency ist nur auf einen gesetzt. Fehlalarme bei geplantem Switch-Maintenance
• WAN-Strecken zu Außenstandorten haben oft gar keine Dependencies. Jede Internet-Störung erzeugt eine Alarm-Flut für die Außenstelle

Die Folge: Das Admin-Team entwickelt über die Jahre eine Alarm-Müdigkeit. Bei einem Ausfall kommen 30 Mails auf einmal und niemand liest sie mehr sorgfältig. Echte Probleme gehen im Rauschen unter. Die Ironie: Das Monitoring-System funktioniert technisch einwandfrei. Es ist nur nutzlos geworden.

Was diese Altlasten gemeinsam haben

Alle 5 Punkte haben einen gemeinsamen Nenner: Sie sind keine Bugs. Sie sind Pflegezustand. Ein Pflegezustand, der schleichend entstanden ist. Niemand im Team hat ihn aktiv verschlechtert, aber auch niemand aktiv verbessert.

Die ehrliche Diagnose: Monitoring-Hygiene ist der Job, den niemand macht, weil Betrieb immer Priorität hat. Das ist nicht böse gemeint. Es ist die Standard-Realität in jedem IT-Team mit mehr Aufgaben als Kapazität. Deshalb lohnt es sich, diese Arbeit einmal konzentriert von außen machen zu lassen. Als Audit mit Fixpreis, nicht als weiteres Neben-Projekt, das nie fertig wird.

Was du heute schon tun kannst

Du willst einen ersten Eindruck vom Zustand deiner eigenen Umgebung? 4 Fragen, die du dir in 15 Minuten selbst beantworten kannst:

1. Pause-Quote: Wie viele Sensoren in deinem PRTG sind aktuell pausiert? Über 10 % = Zeit zum Aufräumen.
2. Namens-Stichprobe: Filtere nach den letzten 20 angelegten Sensoren. Sehen sie gleich benannt aus wie die ersten 20, die je angelegt wurden? Wenn nein: du hast mindestens 2 Epochen parallel.
3. Tag-Hygiene: Geh in Setup → Tags und schau die Liste an. Wie viele Tags kommen nur einmal vor? Wie viele sehen wie Duplikate aus (wichtig vs. Wichtig vs. WICHTIG)?
4. Map-Check: Öffne den Map-Bereich. Welche Map wurde zuletzt tatsächlich angeklickt? Wenn du das nicht weißt, ist die Map vermutlich keinen Pflegeaufwand wert.

Das sind 4 einfache Indikatoren, die dir nach 15 Minuten sagen, ob dein Monitoring schon in die Pflegeaufwands-Spirale gerutscht ist. Und die gute Nachricht: Sobald du die 4 Antworten hast, weißt du auch, wo du anfangen solltest.

Im nächsten Artikel zeige ich, wie sich einige dieser Altlasten mit 20 Zeilen Python und der PRTG-API automatisch finden lassen, ohne manuelle Klick-Orgie.