Landing Page
In modernen IT-Umgebungen reicht ein simples "Ping OK" längst nicht mehr aus. Wo Admins früher monolithische Serverlandschaften mit statischen IP-Adressen überwachten, prägen heute dynamische Hybrid-Cloud-Architekturen, Container-Cluster und verteilte Microservices den IT-Betrieb. IT-Verantwortliche und Systemadministratoren stehen vor der Herausforderung, nicht nur die Verfügbarkeit einzelner Systeme zu garantieren, sondern die Leistungsfähigkeit und Integrität der gesamten Service-Kette lückenlos nachzuvollziehen.
Inhalt
- Vom reaktiven Monitoring zur Observability
- Die drei Säulen der Observability (MELT)
- Domänen & Anwendungsfelder: Infrastruktur, Netzwerk & APM
- Auswertung, Automatisierung & Incident Management
- FAQs
Vom reaktiven Monitoring zur Observability
Klassisches Monitoring und moderne Observability werden häufig synonym verwendet, beschreiben technisch und methodisch jedoch zwei unterschiedliche Reifegrade der IT-Überwachung.
Das klassische Monitoring blickt reaktiv auf ein System und konzentriert sich auf bekannte Fehlerbilder (Known Unknowns). Es beantwortet im Wesentlichen die Frage, ob ein System oder Dienst verfügbar ist. Sobald definierte Grenzwerte überschritten werden – etwa bei einer CPU-Auslastung von über 90 Prozent oder dem Auftreten von HTTP-500-Fehlern – schlägt das System Alarm.
Die Observability geht einen entscheidenden Schritt weiter: Sie beschreibt die Eigenschaft eines Systems, seinen inneren Zustand allein anhand seiner externen Ausgabedaten zu erklären. Damit adressiert sie unvorhergesehene Probleme (Unknown Unknowns) und liefert die Antwort auf die Frage, warum sich eine Anwendung fehlerhaft verhält oder Latenzen aufbaut.
Für den Aufbau einer nachhaltigen Überwachungsstrategie haben sich verschiedene Methoden etabliert. Google SRE definierte mit den "Four Golden Signals" – Latenz, Datenverkehr, Fehler und Sättigung – ein universelles Gerüst für verteilt arbeitende Systeme. Ergänzend dazu unterscheiden wir zwischen zwei komplementären Ansätzen:
- Die USE-Methode (Utilization, Saturation, Errors) richtet den Blick auf die physischen und virtuellen Ressourcen wie CPU, Arbeitsspeicher und Storage.
- Die RED-Methode (Rate, Errors, Duration) fokussiert sich direkt auf die Performance von Anwendungs- und Microservice-Architekturen.
Eine der größten Gefahren beim Aufbau von Überwachungssystemen bildet die sogenannte Alert Fatigue (Alarmmüdigkeit). Wenn Administratoren täglich mit hunderten unkritischen Warnungen geflutet werden, sinkt die Reaktionsgeschwindigkeit bei echten Notfällen drastisch. Eine tragfähige Strategie trennt daher strikt zwischen informativen Logeinträgen für spätere Analysen und kritischen Alarmen, die ein sofortiges manuelles Eingreifen erfordern.
Tier-0-Systeme in Windows-Umgebungen überwachen
Remotehilfe in Intune und Schnellhilfe unter Windows
Observability als Fundament digitaler Resilienz
PRTG-Home-Lab einrichten
Die drei Säulen der Observability (MELT)
Um ein IT-System observierbar zu machen, erfassen, aggregieren und korrelieren IT-Admins Telemetriedaten kontinuierlich. Das technische Fundament dieser Architektur bilden die drei Säulen Metrics, Events/Logs und Traces (MELT).
Metriken sind numerische Werte, die Systeme in festen Zeitintervallen erfassen und als Zeitreihendaten (Time Series Data) speichern. Sie bilden das Rückgrat für Performancemonitoring, Trendanalysen und vorausschauendes Kapazitätsmanagement. Werkzeuge wie Prometheus, VictoriaMetrics oder InfluxDB erfassen hierbei fortlaufend die Auslastung von Host-Systemen, den Netzwerkdurchsatz oder die Request-Raten von Webservern.
Während Metriken zeigen, dass eine Ressource belastet ist, liefern Logs den detaillierten Kontext zum genauen Zeitpunkt des Geschehens. Sie enthalten strukturierten oder unstrukturierten Text, den Anwendungen und Betriebssysteme bei spezifischen Ereignissen schreiben. Systeme wie Grafana Loki, OpenSearch oder der Elastic Stack (ELK) bündeln diese Protokolle zentral und ermöglichen eine gezielte Ursachenanalyse (Root Cause Analysis) bei Systemfehlern oder Sicherheitsvorfällen.
In modernen Microservice-Architekturen stößt die Kombination aus Metriken und Logs an ihre Grenzen. Hier kommt Distributed Tracing ins Spiel. Technologien wie OpenTelemetry oder Jaeger vergeben für jede Benutzeranfrage eine eindeutige Trace-ID und verfolgen deren Weg über sämtliche Systemgrenzen, Datenbanken und APIs hinweg. Dadurch lässt sich millisekundengenau lokalisieren, an welcher Stelle innerhalb der Verarbeitungskette Engpässe entstehen.
Verbindungsqualität mit Orb dauerhaft überwachen
Download der Woche: Beszel
Domänen & Anwendungsfelder: Infrastruktur, Netzwerk & APM
Die Anforderungen an die Überwachung variieren stark je nach Schicht im IT-Stack. Eine professionelle Gesamtarchitektur deckt sämtliche Ebenen ab – von der Hardware im Rechenzentrum bis hin zur Code-Ausführung in der Anwendung.
Das Fundament jeder IT-Landschaft bildet die Überwachung von physischen Hypervisoren wie Proxmox VE oder VMware ESXi sowie den darauf betriebenen Linux- und Windows-Instanzen. Neben der reinen Hardware-Gesundheit stehen hier ZFS- und LVM-Storagepools, Kernel-Events und die Integrität essenzieller Systemdienste im Mittelpunkt. Etablierte Open-Source-Plattformen wie Icinga 2, Checkmk oder Zabbix bieten für diese klassischen Szenarien mächtige Regelwerke.
In Kubernetes-Clustern und dynamischen Docker-Umgebungen versagen klassische, IP-basierte Überwachungsansätze, da Systeme Container kontinuierlich neu starten und verschieben. Das Monitoring passt sich hier adaptiv an. Prometheus hat sich in diesem Umfeld als Standard etabliert, um Pod-Status, Ressourcen-Limits und Service-Mesh-Traffic dynamisch zu erfassen und über Langzeitspeicher wie Thanos einzubinden.
Switches, Router, Firewalls und VPN-Endpunkte erfordern spezialisierte Abfragemechanismen. Neben der klassischen Abfrage von Hardwaresensoren und Schnittstellen-Traffic via SNMP (v2c/v3) gewinnt die Auswertung von Flow-Daten via NetFlow, sFlow oder IPFIX an Bedeutung, um Bandbreitenfresser und unautorisierte Datenflüsse im Netzwerk aufzudecken.
Das Application Performance Management (APM) blickt direkt in die Anwendung hinein und misst die Antwortzeiten aus Sicht der Nutzer. Ergänzend dazu simuliert das Synthetic Monitoring über automatisierte Skripte kontinuierlich kritische Workflows – wie etwa Anmeldevorgänge oder Datenbankabfragen –, um Performance-Einbrüche zu erkennen, bevor Kunden oder Mitarbeiter davon betroffen sind.
Mit RIPE Atlas die eigene Infrastruktur von außen prüfen
Monitoring der Active-Directory-Verbunddienste
Download der Woche: Cacti
Auswertung, Automatisierung & Incident Management
Das reine Sammeln von Telemetriedaten erzeugt noch keinen Mehrwert. Der tatsächliche Nutzen für den Betriebsalltag entsteht erst durch die korrelierte Visualisierung, die Automatisierung von Routineaufgaben und die Anbindung an das Incident-Management.
Ein zentrales Dashboard bündelt Daten aus unterschiedlichsten Quellen auf einer einzigen Oberfläche (Single Pane of Glass). Grafana hat sich hierbei als De-facto-Standard durchgesetzt. Es führt Metriken aus Prometheus, Logs aus Loki und Traces aus OpenTelemetry in gemeinsamen Ansichten zusammen und ermöglicht Administratoren das nahtlose Wechseln zwischen High-Level-Übersichten und detaillierten Fehlerprotokollen.
Moderne Überwachungssysteme konfigurieren IT-Profis nicht mehr manuell. Über NetBox als zentrale Source of Truth lassen sich Monitoringziele, IP-Subnetze und Schwellenwerte vollständig per API oder Ansible-Playbooks in die Monitoring-Engines einspeisen. Ändert sich etwas an der Infrastruktur, zieht das Monitoring automatisch nach.
Schlägt eine Überwachung an, muss die Benachrichtigung zielgerichtet erfolgen. Über definierte Eskalationsketten werden Alarme je nach Dringlichkeit an Messenger wie Matrix oder Teams sowie an Anruf-Dienste wie PagerDuty weitergeleitet. Zudem halten zunehmend AIOps-Ansätze Einzug: Machine-Learning-Algorithmen erkennen Abweichungen vom normalen Systemverhalten (Anomalie-Detektion) automatisch, sodass Fehlalarme bei geplanten Lastspitzen gar nicht erst entstehen.
Single Source of Truth mit NetBox
Speicherverwaltung und Automatisierung mit FSRM
Download der Woche: Monit
Häufig gestellte Fragen zu Monitoring & Observability
Klassisches Monitoring prüft reaktiv den Systemzustand anhand bekannter Schwellenwerte (Known Unknowns) und beantwortet die Frage, ob ein System verfügbar ist. Observability ist hingegen eine Systemeigenschaft: Sie ermöglicht es, den inneren Zustand eines komplexen, verteilten Systems allein anhand seiner externen Telemetriedaten zu erklären. Sie adressiert unvorhergesehene Fehlerbilder (Unknown Unknowns) und liefert die Antwort darauf, warum ein System fehlerhaft oder langsam reagiert.
MELT steht für Metrics, Events, Logs und Traces – die vier primären Telemetriedaten-Arten. Metriken sind numerische Zeitreihendaten zur Messung von Leistung und Auslastung (z. B. via Prometheus). Logs liefern den detaillierten Textkontext zu spezifischen Zeitpunkten (z. B. Anwendungsfehler). Distributed Traces verfolgen den Weg einzelner Anfragen über Microservice- und Datenbankgrenzen hinweg (z. B. via OpenTelemetry), um Latenzen punktgenau zu lokalisieren.
Die von Google definierten Four Golden Signals sind die zentralen Kennzahlen zur Bewertung der Service-Qualität: Latenz (Dauer der Anfragenerfüllung), Datenverkehr (Traffic/Systemlast), Fehler (Rate fehlerhafter Anfragen) sowie Sättigung (Auslastung der Systemressourcen wie Speichermedien oder CPU). Sie bilden das Fundament für die Messung von Service Level Indicators (SLIs) und Service Level Objectives (SLOs).
Die USE-Methode (Utilization, Saturation, Errors) ist ressourcenorientiert und analysiert physische oder virtuelle Hardwarekomponenten (z. B. CPU, RAM, Disk-I/O) auf Auslastung, Engpässe und Fehler. Die RED-Methode (Rate, Errors, Duration) ist hingegen anwendungsorientiert: Sie misst die Anzahl der Anfragen pro Sekunde, die aufgetretenen Fehler sowie die Bearbeitungsdauer im Anwendungs-Code und eignet sich besonders für Webdienste und Microservices.
Beim Pull-Prinzip (z. B. Prometheus) fragt der Monitoring-Server die Telemetriedaten in definierten Intervallen aktiv von den Zielen oder Exportern ab. Dies vereinfacht die zentrale Konfiguration und Zustandsüberwachung der Targets. Beim Push-Prinzip (z. B. Zabbix-Agenten oder InfluxDB) senden die überwachten Systeme oder Agenten ihre Metriken selbstständig an einen zentralen Kollektor. Push eignet sich besonders für kurzlebige Server-Instanzen, Serverless-Funktionen oder hochgradig abgesicherte Umgebungen hinter Firewalls.
OpenTelemetry ist ein herstellerneutrales Open-Source-Framework der CNCF (Cloud Native Computing Foundation). Es stellt standardisierte APIs, SDKs und Tools bereit, um Metriken, Logs und Traces aus Anwendungen zu generieren und zu exportieren. Da OTel das Sammeln von Daten von deren Analyse entkoppelt, verhindert es den Vendor-Lock-in: Unternehmen können Telemetriedaten einmalig instrumentieren und flexibel an unterschiedliche Analyse-Backends (wie Grafana, Jaeger oder Cloud-Dienste) weiterleiten.
Klassische Monitoring-Systeme setzen meist auf statische IP-Adressen und langlebige Host-Systeme. In Kubernetes-Clustern sind Pods und Container jedoch ephemer (flüchtig) und werden dynamisch skaliert oder verschoben. Kubernetes-Monitoring erfordert daher service-basierte Abfragemethoden, die Container-Laufzeiten verstehen, Metriken über automatisierte Service Discovery erfassen und Daten mit Kubernetes-Metadaten (z. B. Labels, Namespaces, Pod-Namen) anreichern.
Alert Fatigue (Alarmmüdigkeit) entsteht, wenn Administratoren durch eine Flut unkritischer, redundanter oder fehlerhafter Benachrichtigungen abgestumpft werden, wodurch kritische Notfälle übersehen werden. Sie lässt sich durch sinnvolle Schwellenwerte, dynamische Baselines, sauberes Gruppieren von Alarmen (Deduplizierung) sowie die strikte Trennung von sofort handlungsrelevanten Alarmen (Alerts) und informativen Systemereignissen (Notifications/Logs) vermeiden.
NetBox fungiert als zentrale Instanz zur Verwaltung von Infrastrukturdaten (IP-Adressen, Racks, VLANs, Gerätestandorte). Anstatt Monitoring-Ziele in Systemen wie Icinga, Prometheus oder Zabbix manuell einzupflegen, dient NetBox als automatisierte Datenquelle (Source of Truth). Über APIs oder Configuration-Management-Tools (z. B. Ansible) werden Monitoring-Engines automatisch aktualisiert, sobald neue Hardware im Netz inventarisiert wird.
Beim Synthetic Monitoring (auch Proactive Monitoring genannt) simulieren automatisierte Skripte kontinuierlich typische Benutzerinteraktionen über die Oberfläche oder Schnittstellen einer Anwendung (z. B. Login-Abläufe, Suchanfragen oder Checkout-Prozesse). Dadurch lassen sich Ausfälle, Funktionsfehler oder Performance-Einbrüche proaktiv erkennen und beheben, bevor echte Anwender davon betroffen sind.