Server-Betriebszeit überwachen: Prüfungen, Tools und Alarme

Um die Betriebszeit eines Servers zu überwachen, führen Sie automatisierte Prüfungen von außerhalb des Servers aus (Ping, TCP-Port oder HTTP-Anfragen von mehreren Standorten), erfassen die eigenen Gesundheitssignale des Servers mit einem Agenten und alarmieren nur, wenn mehrere Standorte hintereinander fehlschlagen. Anschließend protokollieren Sie jeden Ausfall, damit Sie die Verfügbarkeit monatlich gegen Ihr SLA berechnen können.

Das Wichtigste in Kürze

• Externe synthetische Prüfungen beantworten „Erreichen Nutzer den Dienst?“, interne Agenten „Warum ist er ausgefallen?“. Sie brauchen beides.
• Prüfen Sie von mindestens drei Standorten aus und alarmieren Sie bei aufeinanderfolgenden Fehlern, um Fehlalarme durch einen einzelnen schlechten Netzwerkpfad zu vermeiden. Microsoft empfiehlt für Azure-Verfügbarkeitstests mindestens fünf Teststandorte.
• Testen Sie, was Nutzer verwenden: Eine HTTPS-Anfrage, die Statuscode und Seiteninhalt prüft, ist besser als ein Ping.
• Eine Verfügbarkeit von 99,9 % erlaubt immer noch etwa 43,8 Minuten Ausfall im Monat. Wissen Sie, was Ihr Ziel erlaubt, bevor Sie Alarmschwellen festlegen.
• Schließen Sie vereinbarte Wartungsfenster einheitlich aus und berichten Sie die Betriebszeit jeden Monat aus denselben Daten.

Was ist Server-Uptime-Monitoring?

Server-Uptime-Monitoring ist die laufende Prüfung, ob ein Server und die darauf laufenden Dienste erreichbar sind und korrekt antworten. Es liefert zweierlei: Alarme, wenn etwas ausfällt, und einen Verlauf, aus dem sich ein Verfügbarkeitsprozentsatz berechnen lässt.

Uptime und Verfügbarkeit hängen zusammen, sind aber nicht identisch. Ein Server kann eingeschaltet sein (hohe Uptime), während sein Webdienst Fehler liefert (geringe Verfügbarkeit). Für die meisten Unternehmen zählt die Verfügbarkeit des Dienstes aus Sicht der Nutzer.

Wie viel Ausfallzeit erlaubt welches Verfügbarkeitsziel?

Die Verfügbarkeit ist (Gesamtzeit − Ausfallzeit) ÷ Gesamtzeit. Die Tabelle rechnet gängige Ziele in erlaubte Ausfallzeit um, mit einem durchschnittlichen Monat von 730 Stunden.

Ein enges Ziel verändert die Überwachung. Bei 99,99 % kann ein Prüfintervall von fünf Minuten nicht einmal jede Verletzung erkennen, Sie brauchen also Prüfungen jede Minute oder schneller und eine Reaktion der Bereitschaft in Minuten. Das Kapitel des Google-SRE-Buchs zum Umgang mit Risiko (Embracing Risk) erklärt, warum jede weitere Neun mehr kostet und warum das Ziel dem Geschäftsbedarf folgen sollte.

Welche Prüfungen sollten Sie durchführen?

Externe (synthetische) Prüfungen

• ICMP-Ping: zeigt, dass der Host im Netzwerk antwortet. Günstig, aber viele Firewalls blockieren ihn, und ein Host kann auf Ping antworten, während seine Anwendungen ausgefallen sind.
• TCP-Port-Prüfungen: bestätigen, dass ein Dienst lauscht, zum Beispiel 443 für HTTPS, 3389 für RDP oder 5432 für PostgreSQL.
• HTTP(S)-Prüfungen: rufen eine URL ab und prüfen Statuscode, Antwortzeit und einen erwarteten Inhalt. Nutzen Sie einen eigenen Health-Endpunkt, der auch die Datenbankverbindung testet.
• TLS-Zertifikatsprüfungen: warnen vor dem Ablauf eines Zertifikats. Ein abgelaufenes Zertifikat ist für Nutzer ein Ausfall, auch wenn der Server gesund ist.
• DNS-Prüfungen: bestätigen, dass der Name auf die richtige Adresse auflöst.

Interne (agentenbasierte) Signale

• Heartbeat: Der Agent meldet sich jede Minute; ein fehlender Heartbeat bedeutet, dass Host oder Agent ausgefallen ist.
• Uptime-Zähler des Systems: zeigt ungeplante Neustarts. Unter Linux nutzen Sie uptime oder last reboot; unter Windows hält die Ereignis-ID 6008 im Systemprotokoll ein unerwartetes Herunterfahren fest.
• Ressourcenmetriken: CPU, Arbeitsspeicher, Speicherplatz und Datenträgerlatenz. Volle Datenträger und erschöpfter Arbeitsspeicher sind häufige Ursachen für „läuft, funktioniert aber nicht“.
• Dienst- und Prozessstatus: Laufen Webserver, Datenbank oder geplanter Job?

Für Windows-Hosts listet unser Leitfaden zur Überwachung der Windows-Server-Leistung die sinnvollen Zähler auf.

Welche Tools können die Server-Betriebszeit überwachen?

Die Wahl ist weniger wichtig als der Aufbau. Auch ein selbst gehostetes Tool muss überwacht werden: Steht Ihr einziger Monitoring-Server im selben Rack wie die Server, die er beobachtet, reißt ein Stromausfall beide mit. Betreiben Sie mindestens eine externe Prüfung aus einem anderen Netz oder von einem Cloud-Service.

So richten Sie Uptime-Alarme ohne Fehlalarme ein

1. Mehrere Standorte nutzen. Microsoft empfiehlt für Azure-Verfügbarkeitstests mindestens fünf Teststandorte und als Alarmschwelle die Zahl der Standorte minus zwei, also zum Beispiel drei fehlschlagende von fünf.
2. Aufeinanderfolgende Fehler verlangen. Die Wiederholungsoption von Azure meldet einen Fehler erst, wenn drei aufeinanderfolgende Versuche scheitern; Microsoft weist darauf hin, dass etwa 80 % der Fehler bei einer Wiederholung verschwinden.
3. Schweregrad nach Auswirkung festlegen. Ein produktives Kundenportal alarmiert den Engineer in Bereitschaft; ein Testserver erzeugt ein Ticket.
4. Alarme an Personen leiten, die handeln können, mit Eskalation, wenn niemand innerhalb einer festgelegten Zeit bestätigt.
5. Geplante Wartung im Monitoring-Tool stummschalten, statt Alarme aus Gewohnheit zu ignorieren.
6. Auch bei Wiederherstellung alarmieren, damit das Team weiß, wann der Vorfall vorbei ist.

Googles SRE-Leitfaden zum Monitoring verteilter Systeme liefert eine nützliche Regel: Jede Seitenalarmierung (Page) sollte dringend und handlungsrelevant sein und einen Menschen erfordern. Alles andere gehört in ein Ticket oder ein Dashboard.

So berichten Sie die Betriebszeit gegen ein SLA

• Definieren Sie, was als ausgefallen gilt, zum Beispiel „Health-Endpunkt schlägt von drei von fünf Standorten bei zwei aufeinanderfolgenden Prüfungen fehl“.
• Vereinbaren Sie, welche Wartungsfenster ausgeschlossen werden, und erfassen Sie sie im Tool.
• Berechnen Sie die monatliche Verfügbarkeit aus den Prüfergebnissen, nicht aus dem Gedächtnis oder aus Ticketnotizen.
• Führen Sie ein Ausfallprotokoll mit Beginn, Ende, Ursache und Behebung. Muster, etwa Ausfälle nach jeder Patch-Nacht, zeigen, wo sich Investitionen lohnen.
• Vergleichen Sie Ihre Zahl mit dem, was Ihr Cloud-Anbieter zusagt. So sagt das Amazon Compute SLA 99,99 % monatliche Verfügbarkeit für EC2 zu, das über mehrere Availability Zones einer Region verteilt ist, aber nur 99,5 % für eine einzelne EC2-Instanz. Die Verfügbarkeit Ihrer Anwendung kann nie höher sein als die ihrer schwächsten Abhängigkeit.

Monitoring informiert über Ausfälle; Redundanz verhindert sie. Betreiben Sie kritische Workloads auf mehr als einem Server oder einer Availability Zone hinter einem Load Balancer, damit ein einzelner Fehler den Dienst nicht lahmlegt. WorkBuster, eine SaaS-Recruiting-Plattform, läuft auf EC2 hinter einem Application Load Balancer mit Multi-AZ-MySQL-RDS, einer Auto-Scaling-Gruppe sowie CloudWatch-Dashboards und -Alarmen; die Fallstudie zu WorkBuster zeigt den vollständigen Aufbau.

Wie Opsio Ihnen hilft

Opsio betreibt 24/7-Monitoring und Incident Response für Server und Cloud-Workloads auf AWS, Azure und Google Cloud. Wir richten Prüfungen, Alarmweiterleitung und monatliche Verfügbarkeitsberichte ein, und unsere Engineers bearbeiten die Alarme. Siehe unsere Seiten zu Cloud-Monitoring und Support, Remote-Infrastruktur-Monitoring und Observability mit Prometheus und Grafana.

Häufig gestellte Fragen

Wie prüfe ich, wie lange ein Server schon läuft?

Unter Linux nutzen Sie uptime oder last reboot. Unter Windows öffnen Sie im Task-Manager die Registerkarte „Leistung“, führen systeminfo aus und lesen „Systemstartzeit“, oder sehen im Systemereignisprotokoll nach. Diese zeigen die Zeit seit dem letzten Start, nicht ob Dienste verfügbar waren.

Wie oft sollten Uptime-Prüfungen laufen?

Bei den meisten Produktivdiensten alle ein bis fünf Minuten. Stimmen Sie das Intervall auf Ihr Ziel ab: Bei 99,99 % bleiben nur etwa 4,4 Minuten Ausfall im Monat, ein Fünf-Minuten-Intervall ist also zu langsam, um das zu messen.

Reicht Ping, um die Server-Betriebszeit zu überwachen?

Nein. Ping belegt nur, dass der Netzwerk-Stack antwortet. Ergänzen Sie eine TCP- oder HTTPS-Prüfung gegen den Dienst, von dem Nutzer abhängen, idealerweise mit Inhaltsabgleich, sowie agentenbasierte Prüfungen auf dem Server selbst.

Was ist ein guter Uptime-Prozentsatz für einen Server?

Für Geschäftsanwendungen sind 99,9 % ein gängiges Ziel; kundennahe Dienste streben oft 99,95 % oder mehr an. Höhere Ziele erfordern Redundanz: AWS sagt zum Beispiel nur 99,5 % für eine einzelne EC2-Instanz zu, aber 99,99 % für EC2 über mehrere Availability Zones verteilt.

Kann ich die Betriebszeit kostenlos überwachen?

Ja. Open-Source-Tools wie Prometheus mit blackbox_exporter, Zabbix oder Nagios kosten keine Lizenz, auch wenn Sie mit Hosting und Wartungszeit zahlen. Die nativen Prüfungen der Cloud-Anbieter sind bei wenigen Endpunkten günstig.

Weiterführende Artikel

• Was ist Cloud-Monitoring?
• Was bedeutet Server- und Anwendungsüberwachung in Echtzeit?
• Wie überwacht man die Leistung eines Windows-Servers? Tools und Metriken