Monitoring-Konzept
Stell dir vor, du betreust 60 Server, 25 Switches, drei Datenbanken und eine handvoll Anwendungen. Ein Anruf kommt: „Die Buchhaltungssoftware ist langsam.". Ohne Monitoring beginnst du jetzt: einloggen, CPU prüfen, RAM prüfen, Festplatte prüfen, Netzwerk prüfen, Datenbank prüfen, Logs lesen, Anwendung neu starten und hoffen. Mit Monitoring schaust du auf einen Bildschirm: Server A4 hat seit 14:20 Uhr eine CPU-Last von 95 %, weil ein Backup-Job klemmt. Genau darum geht es bei Monitoring: nicht reagieren wenn was schiefgeht, sondern es vorher wissen. Diese Lektion legt das Fundament: was monitort man, in welcher Tiefe, wer pollt wen und warum „proaktiv" mehr ist als nur ein Schlagwort. Die einzelnen Werkzeuge – Nagios, Zabbix, Prometheus – kommen in den nächsten Lektionen.
1) Die vier Ebenen des Monitorings
Monitoring ist nie nur eine Schicht. Eine Anwendung kann langsam sein, weil die CPU ausgelastet ist – oder weil der Switch Pakete verliert – oder weil die Datenbank-Indexe fehlen. Du brauchst Sichtbarkeit auf jeder Ebene, von unten nach oben. Klick die Ebenen an, um zu sehen, was dort jeweils gemessen wird:
2) Push vs. Pull – wer fragt wen?
Es gibt zwei grundlegende Architekturen, wie Messwerte vom Zielsystem zum Monitoring-Server kommen. Du musst beide kennen, weil unterschiedliche Tools unterschiedliche Ansätze fahren – Nagios und Prometheus pollen (Pull), Zabbix und Telegraf können beides, Graphite und InfluxDB-Telegraf-Stacks pushen typisch:
Pull – Monitoring fragt
+ Monitoring entscheidet Takt & Reihenfolge
+ Ziel kann „dumm" sein (Agent optional)
− Bei vielen Zielen wird Monitoring zum Flaschenhals
− Firewall muss eingehende Verbindung erlauben
Push – Ziel schickt
+ Skaliert besser auf viele Quellen
+ Ziel kann hinter NAT/Firewall stehen
− Monitoring weiß nicht, ob „keine Daten" = OK oder = down
− Agent ist Pflicht
3) Agent vs. agentless
Eine weitere Grundsatzentscheidung: läuft auf dem überwachten System ein Agent (Hintergrundprozess, der Daten sammelt und meldet) oder wird agentlos über offene Protokolle (SNMP, SSH, WMI, HTTPS) abgefragt? Agentlos ist einfacher beim Rollout (kein Paket installieren, kein Update-Stress), aber begrenzt im Detailgrad. Agentbasiert liefert mehr (Anwendungs-Internals, Custom-Checks, lokale Logs), bringt aber zusätzlichen Pflegeaufwand. Spring-Boot-Anwendungen exponieren z. B. einen /metrics-Endpoint – das ist effektiv ein eingebauter Agent. Switches haben kaum Agentenoption, also bleibt SNMP. Mehr zu agentbasiertem Konfigurations-Rollout in Ansible-Playbooks.
4) Reaktiv vs. proaktiv – der eigentliche Wert
Der größte Unterschied zwischen schlechtem und gutem Monitoring ist nicht das Werkzeug, sondern die Haltung. Reaktives Monitoring meldet, wenn etwas kaputt ist – proaktives Monitoring meldet, bevor etwas kaputt geht:
❌ Reaktiv
Alarm sagt: „Server ist down."
- Disk voll → Anwendung crasht → Alarm „Service nicht erreichbar"
- Speicherleck → OOM-Killer → Alarm „Prozess weg"
- Anrufender Kunde meldet das Problem zuerst
✓ Proaktiv
Alarm sagt: „Disk wird in 7 Tagen voll."
- Disk-Trend → Warnung bei 80 %, Alarm bei 90 %
- Speicherverlauf → Warnung bei stetigem Wachstum
- Du weißt es vor dem Kunden
Proaktiv funktioniert nur, wenn du Trends messen und Schwellenwerte definieren kannst. Beides braucht historische Daten – und damit eine Zeitreihen-Datenbank. Mehr zur Schwellenwert-Definition in Schwellenwerte & Alerting und zur Prognose in Kapazitätsplanung.
5) Was misst man? Die wichtigsten Kennzahlen
Folgende Werte gehören in jedes ernstzunehmende Monitoring – das sind die Pflichtangaben, die du in einer IHK-Aufgabe nennen können solltest:
| Ebene | Kennzahl | Warum wichtig |
|---|---|---|
| Hardware | CPU-Last, RAM-Auslastung, Disk-Füllstand, Disk-I/O, Temperatur | Erste Ursachen-Schicht bei Performance-Problemen |
| Netzwerk | Bandbreite, Paketverluste, Latenz, Interface-Status, Errors/Drops | Verbindet alles; Engpässe oft hier |
| Betriebssystem | Load Average, Swap-Nutzung, offene Datei-Handles, Anzahl Prozesse | Symptom-Indikatoren oberhalb der Hardware |
| Dienste | Port-Erreichbarkeit, Antwortzeit, Statuscode, Zertifikat-Ablauf | Stellt fest, ob der Dienst nicht nur läuft, sondern auch nutzbar ist |
| Anwendung | Request-Rate, Fehlerquote, Response-Time (p50/p95/p99), Queue-Länge | Was der Benutzer tatsächlich erlebt |
| Business | Bestellungen/Min., Logins/Sek., Conversion-Rate | „Funktioniert das System für den eigentlichen Zweck?" |
Die letzte Zeile – Business-Metriken – ist die Königsdisziplin. „Server up" bedeutet nichts, wenn niemand mehr bestellen kann. In ITIL spricht man hier von Business Service Monitoring. Mehr dazu in Service Level Management & SLA.
6) Was Monitoring nicht ist
Drei Abgrenzungen, die in Prüfungsfragen gerne kommen:
- Monitoring ≠ Logging. Monitoring sind Metriken (Zahlen über Zeit). Logging sind Ereignisse (Texte mit Zeitstempel). Beides ergänzt sich; mehr zur Log-Seite in Syslog und Log-Analyse.
- Monitoring ≠ Alerting. Monitoring sammelt – Alerting reagiert. Du kannst etwas messen, ohne sofort jemanden zu wecken. Daten ohne Alarm sind oft sinnvoll (Trends), Alarme ohne Daten unmöglich.
- Monitoring ersetzt kein Troubleshooting. Es zeigt, wo es brennt, nicht warum. Die Wireshark-Analyse danach machst du immer noch selbst.
7) Datenschutz und Monitoring
Monitoring greift in Systeme ein, die personenbezogene Daten verarbeiten. Login-Versuche, IP-Adressen, Mailheader – alles kann personenbezogen sein. Das Verarbeiten ist nicht verboten, aber muss in den TOMs dokumentiert und im VVT erfasst sein, mit klar definierter Aufbewahrungsfrist. Beim Beschäftigtendatenschutz ist Vorsicht geboten – Performance-Monitoring eines Mitarbeiter-Laptops berührt schnell Verhaltens- und Leistungskontrolle und braucht eine Vereinbarung mit dem Betriebsrat. Mehr generell in DSGVO-Grundprinzipien (Datenminimierung!).
Zusammenfassung
Monitoring verschiebt IT-Betrieb von „auf Anruf reagieren" zu „Probleme sehen, bevor sie eskalieren". Vier Ebenen – Hardware, Betriebssystem, Dienste/Anwendung, User Experience – müssen abgedeckt sein. Datenfluss läuft als Pull (Monitoring fragt) oder Push (Agent meldet), agentbasiert oder agentlos. Wichtigste Haltung: proaktiv statt reaktiv – Trends & Schwellenwerte statt „kaputt-Alarme". Monitoring liefert Metriken, nicht Logs (siehe Syslog) und ist nicht dasselbe wie Alerting. DSGVO und Beschäftigtendatenschutz müssen mitgedacht werden, gerade beim Loggen von IPs und Aktionen.
Verwandte Lektionen: SNMP · Syslog · Schwellenwerte & Alerting · und mehrWeitere relevante LektionenNagios & IcingaGrafana & PrometheusKapazitätsplanungService Level ManagementIncident ManagementSystematische FehlersucheTOMs (DSGVO)