Linux-Server überwachen: Das komplette Monitoring-Konzept

Von der Erreichbarkeit über HTTP, SSH und SSL bis zu Docker, Cronjobs, Speicherplatz und echten Applikationschecks: So lässt sich ein Linux-Server sinnvoll überwachen – und wo UptimeRobot hineinpasst.

1. Was soll Monitoring eigentlich beantworten?

Gutes Monitoring beantwortet nicht nur die Frage „Ist der Server an?“, sondern mehrere Ebenen: Ist der Host erreichbar? Sind die benötigten Ports offen? Antwortet der Webserver? Funktioniert die Anwendung? Sind Hintergrundjobs gelaufen? Läuft der Speicher voll? Und vor allem: Bekomme ich die Information, bevor ein Benutzer mich anruft?

2. Die fünf Ebenen eines sinnvollen Linux-Monitorings

Wir unterscheiden sinnvollerweise Netzwerk/Host, Dienst, Anwendung, Hintergrundjobs und Systemressourcen. Ein einzelner Ping kann niemals alle fünf Ebenen ersetzen.

3. Ebene 1: Host und Netzwerk

Ping ist der einfachste externe Check. Er beantwortet: Reagiert der Host auf ICMP? Für SSH, SMTP, DNS oder andere TCP-Dienste ist ein Port-Monitor aussagekräftiger. UptimeRobot unterstützt Ping und Port Monitoring. Wichtig: Ein erfolgreicher Ping bedeutet nicht, dass Apache, Nginx, PHP oder die Datenbank funktionieren.

4. Ebene 2: HTTP/HTTPS

HTTP(S)-Monitoring prüft die Erreichbarkeit einer URL. Das ist für Websites, Reverse Proxies und einfache Health-Endpunkte ideal. Ein HTTP 200 ist aber nur ein Transport-/Antwortsignal. Eine Anwendung kann HTTP 200 liefern und trotzdem fachlich kaputt sein.

5. Ebene 3: API und Applikationslogik

Hier wird es interessant: UptimeRobot bietet API Monitoring, das JSON-Antworten und konkrete Felder per Assertions prüfen kann. Damit lässt sich beispielsweise nicht nur prüfen, ob /api/health antwortet, sondern ob status tatsächlich healthy lautet oder ein erwarteter Wert vorhanden ist.

6. Ebene 4: Cronjobs, Backups und geplante Tasks

Heartbeat Monitoring arbeitet umgekehrt: Dein Server oder Cronjob ruft regelmäßig eine eindeutige UptimeRobot-URL auf. Bleibt der Heartbeat aus, wird der Monitor als Down bewertet. Das eignet sich hervorragend für Backups, Datenimporte, Reports, Synchronisationen und Wartungsskripte.

7. Ebene 5: SSL und DNS

SSL- und Domain-Ablaufüberwachung verhindert eine der unangenehmsten Kategorien von Ausfällen: Zertifikat oder Domain läuft aus, obwohl der Server selbst völlig gesund ist. DNS Monitoring kann zusätzlich Änderungen an relevanten Records sichtbar machen.

8. Was UptimeRobot nicht ersetzt

UptimeRobot ist kein vollständiges Host-Monitoring wie Prometheus/node_exporter, Netdata, Zabbix oder Checkmk. CPU-Auslastung, RAM, Load Average, Disk I/O, Dateisystembelegung, Prozesse und systemd-Zustände sollten bei ernsthaften Servern separat überwacht werden.

9. Der clevere Hybrid: lokales Script + UptimeRobot Heartbeat

Genau hier kann UptimeRobot trotzdem sehr viel leisten. Ein lokales Script kann mehrere Bedingungen prüfen und nur bei Erfolg den Heartbeat senden. Beispiel: Apache aktiv, Docker aktiv, MariaDB aktiv, Root-Dateisystem unter 90 Prozent und Backup-Datei vorhanden. Erst wenn alles stimmt, wird der Heartbeat gesendet.

10. Beispiel: Linux-Healthcheck

Das folgende Beispiel ist bewusst einfach gehalten. Es verbindet lokale Prüfungen mit einem externen Heartbeat. Der konkrete UptimeRobot-Endpunkt wird pro Heartbeat-Monitor erzeugt.

#!/bin/bash
set -e

systemctl is-active --quiet apache2
systemctl is-active --quiet docker
systemctl is-active --quiet mariadb

USED=$(df -P / | awk 'NR==2 {gsub(/%/,"",$5); print $5}')
[ "$USED" -lt 90 ]

curl -fsS "https://heartbeat.uptimerobot.com/YOUR-ENDPOINT" >/dev/null

11. Beispiel: Docker-Container überwachen

Docker Healthchecks lassen sich lokal auswerten. Ein Script kann prüfen, ob ein Container healthy ist und erst danach den Heartbeat senden. So bleibt UptimeRobot die externe Alarmierungsinstanz, während Docker die lokale Detailinformation liefert.

#!/bin/bash
set -e

STATUS=$(docker inspect --format='{{.State.Health.Status}}' my-container)

[ "$STATUS" = "healthy" ]

curl -fsS "https://heartbeat.uptimerobot.com/YOUR-ENDPOINT" >/dev/null

12. Was ist mit CPU, RAM und Festplatte?

Für Metriken braucht man ein echtes Metrics-System. UptimeRobot kann externe Erreichbarkeit und synthetische Checks übernehmen; Prometheus/node_exporter oder vergleichbare Systeme liefern die internen Zeitreihen. Das ist kein Entweder-oder, sondern eine sinnvolle Kombination.

13. Monitoring-Architektur für einen typischen Debian-Server

Für einen kleinen Webserver würde ich mindestens HTTP/HTTPS, SSL, SSH-Port, DNS und einen Heartbeat für kritische Cronjobs verwenden. Bei einer API zusätzlich API Assertions. Bei Docker zusätzlich lokale Healthchecks. Für größere Umgebungen kommen Metriken und Log-Aggregation hinzu.

14. Warum externe Checks wichtig sind

Ein lokales Monitoring kann selbst ausfallen. Wenn der Server komplett tot ist, kann ein auf demselben Server laufender Agent keine Warnung mehr senden. Ein externer Dienst hat genau hier seinen Vorteil: Er beobachtet das System von außerhalb.

15. Fazit

UptimeRobot kann einen überraschend großen Teil des praktischen Availability-Monitorings abdecken. Es ersetzt kein vollständiges Linux-Observability-System, aber die Kombination aus HTTP, Ping, Ports, API-Checks, DNS, SSL und Heartbeats ist für viele kleine Server und Websites bereits sehr leistungsfähig.

UptimeRobot als Baustein

Für die Außenperspektive ist UptimeRobot sehr passend: Der Dienst prüft von außerhalb, ob dein System erreichbar ist. Für interne Metriken und Ursachenanalyse ergänzt du ein lokales Metrics-/Logging-System. So entsteht eine robuste Kombination statt eines überladenen Einzelsystems.

Weiterführende Quellen