Open-Source-Monitoring-Tools: Uptime, Status Pages, Metriken und Fehler

„Monitoring“ sind vier verschiedene Jobs: prüfen, dass deine Site antwortet, Usern mit einer Status Page sagen, was los ist, die Server darunter beobachten und die Fehler fangen, die dein Code wirft. Für jeden Job gibt es Open-Source-Tools, und die sechs unten laufen als eigene Instanz aus dem Nodion-One-Click-Katalog.

Eine Regel gilt für alle: betreibe den Monitor woanders als das, was er beobachtet, zum Beispiel in einer anderen Region. Sonst nimmt ein Ausfall App und das Tool, das ihn melden soll, gemeinsam mit.

Auf einen Blick

Tool	Job	Lizenz	Läuft mit
SolidPing	Uptime-Checks, Status Pages, On-Call	AGPL-3.0	PostgreSQL, Object Storage
Kener	Status Pages und Incidents	MIT	PostgreSQL, Valkey
Beszel	Server- und Container-Metriken	MIT	Volume
Komari	Leichte Server-Metriken	MIT	Volume (SQLite)
GlitchTip	Error Tracking, plus einfache Uptime-Checks	MIT	PostgreSQL, Volume, E-Mail-Zone
Rustrak	Error Tracking in einem kleinen Prozess	GPL-3.0	PostgreSQL, Volume

Wie wir ausgewählt haben

• Macht einen der vier Jobs gut: Uptime-Checks, Status Pages, Server-Metriken oder Error Tracking.
• Läuft als eigene Instanz aus einem Container-Image.
• OSI-Open-Source-Lizenz, geprüft gegen die LICENSE-Datei jedes Projekts.
• Kleiner Footprint: die Presets brauchen höchstens 1 GB Speicher.

1. SolidPing: Uptime-Checks

SolidPing ist ein voller Uptime-Monitor in einer Go-Binary. Die Checks gehen weit über HTTP hinaus: TCP, UDP, ICMP, DNS, SSL-Zertifikate und Domains, Mailserver, gRPC, Datenbanken, Message Queues und mehr. Checks können von Workern in mehreren Regionen laufen, und private Agents prüfen Ziele in deinem eigenen Netz über einen ausgehenden WebSocket (siehe das README). Obendrauf kommen Status Pages, Incidents, die einen Alert pro Ausfall statt pro Check senden, Wartungsfenster, On-Call-Rotationen mit Eskalation und Notifications an Slack, Discord, E-Mail, Webhooks, PagerDuty, ntfy und andere.

Lizenz: AGPL-3.0. Lizenzdatei, Projektseite.

Auf Nodion: ein Web-Prozess mit PostgreSQL und einem Object-Storage-Bucket. Melde dich mit admin@solidping.io und solidpass an; SolidPing zwingt dich beim ersten Login, ein neues Passwort zu setzen. Mach das direkt nach dem ersten Deploy, bevor du die URL teilst: diese Defaults sind öffentlich, wer sich zuerst anmeldet, beansprucht die Instanz.

SolidPing deployen

2. Kener: Status Pages

Kener fokussiert die Seite, die deine User sehen. Es baut gebrandete Status Pages mit deinem Logo, Farben und CSS, Light- und Dark Mode und Status-Widgets und Badges, die du woanders einbetten kannst. Incidents bekommen eine Timeline mit Updates, und Wartungsfenster werden im Voraus angekündigt. Kener führt außerdem eigene Checks aus (API, Ping, TCP, DNS, SSL, SQL und Heartbeat), benachrichtigt per E-Mail, Webhook, Slack oder Discord, und eine Instanz kann mehrere Status Pages bedienen.

Lizenz: MIT. Lizenzdatei, Projektseite.

Auf Nodion: ein Web-Prozess mit PostgreSQL und Valkey, die URL der App ist bereits als Keners Origin gesetzt. Beim ersten Öffnen zeigt Kener ein Setup-Formular für Name, E-Mail und Passwort des Owners.

Kener deployen

3. Beszel: Server-Metriken

Beszel beobachtet Maschinen statt URLs. Ein kleiner Agent auf jedem Server meldet CPU, Memory, Disk-Nutzung und I/O, Netz, Temperaturen, GPU-Nutzung und Docker- oder Podman-Container-Stats an den Hub, der die History hält und Alerts sendet. Es unterstützt mehrere User, OAuth- und OIDC-Login und automatische Backups auf Disk oder S3-kompatiblen Storage.

Lizenz: MIT. Lizenzdatei, Projektseite.

Auf Nodion: das Preset betreibt den Hub als einen Web-Prozess mit einem 10-GB-Volume. Agents gehören nicht zum Deploy: installiere sie auf den Maschinen, die du beobachten willst, sie können sich über WebSocket nach außen mit dem Hub verbinden. Der erste Besuch fordert dich auf, das Admin-Konto anzulegen.

Beszel deployen

4. Komari: leichte Server-Metriken

Komari ist ein noch kleinerer Server-Monitor. Agents melden CPU, Memory, Disk, Netz und Uptime, und das Dashboard zeigt Livedaten im Sekundentakt plus History-Charts. Themes und Plugins ändern das Aussehen. Der Admin-Bereich enthält außerdem ein Web-Terminal für verbundene Server, schütze den Admin-Login also wie ein Root-Passwort.

Lizenz: MIT. Lizenzdatei, Projektseite.

Auf Nodion: ein Web-Prozess mit SQLite auf einem 10-GB-Volume. Melde dich als admin mit dem erzeugten ADMIN_PASSWORD aus dem Environment-Tab an. Agents verbinden sich über HTTPS zur URL der App zurück, es braucht also keinen extra eingehenden Port.

Komari deployen

5. GlitchTip: Error Tracking

GlitchTip ist ein Error Tracker, der mit Sentrys Client-SDKs funktioniert: zeige die DSN des SDKs, das du schon nutzt, auf deine Instanz, und Exceptions, Log-Nachrichten und Content-Security-Policy-Verletzungen landen an einem Ort. Es listet außerdem deine langsamsten Requests und Datenbankcalls und hat einfaches Uptime-Monitoring: es pinged deine Site oder wartet auf einen Heartbeat von einem Scheduled Job und alarmiert per E-Mail oder Webhook.

Lizenz: MIT. Lizenzdatei, Projektseite.

Auf Nodion: ein Web-Prozess mit PostgreSQL, einem 10-GB-Volume für Uploads und einer E-Mail-Zone für ausgehende Mail. Beim ersten Öffnen registrierst du den ersten User.

GlitchTip deployen

6. Rustrak: Error Tracking

Rustrak spricht ebenfalls das Sentry-Protokoll, ein bestehendes Sentry-SDK braucht also nur eine neue DSN. Es läuft als ein kleiner Prozess und nimmt Events an, indem es sie zuerst auf Disk schreibt, ein Traffic-Spike wartet also nicht auf die Datenbank. Neben Fehlern nimmt es Logs, Transactions, Release Health und Traces von AI-Agenten.

Lizenz: GPL-3.0. Lizenzdatei, Projektseite.

Auf Nodion: ein Web-Prozess mit PostgreSQL und einem 10-GB-Volume. Melde dich mit der E-Mail admin und dem Passwort nach dem Doppelpunkt in CREATE_SUPERUSER im Environment-Tab an.

Rustrak deployen

Monitoring, das in Nodion steckt

Wenn deine Apps auf Nodion laufen, ist der grundlegende Uptime-Check schon da. Monitoring im Dashboard (das Produkt nennt sie Observer) beobachtet jede http(s)-URL oder eine deiner Apps und ihre Domain, alle 30 Sekunden bis alle 30 Minuten, mit GET oder HEAD. Du setzt den Statuscode, den du erwartest, alles andere zählt als down. Alerts gehen an E-Mail, Slack, Discord, Google Chat, Telegram, Pushover, ntfy oder einen beliebigen Webhook, und jeder Check wird mit Response Time und Region gespeichert. Schlägt Nodions Probe statt deiner Site fehl, wird der Check markiert und zählt nicht als Downtime. Das Setup steht in den Monitoring-Docs.

Für eine öffentliche Status Page, Server-Metriken oder Error Tracking ergänze eines der Tools oben.

Ebenfalls einen Blick wert

• Tianji (Apache 2.0) verbindet Website-Analytics, Uptime-Checks und Status Pages in einer App und steht ebenfalls im One-Click-Katalog.
• Uptime Kuma (MIT) ist ein einfacher Uptime-Monitor mit HTTP-, TCP-, Ping- und DNS-Checks, vielen Notification-Diensten und mehreren Status Pages.

So wählst du

• Du willst viele Check-Typen, Status Pages und On-Call in einem Tool: SolidPing.
• Du brauchst vor allem eine polierte öffentliche Status Page mit Incidents: Kener.
• Du willst CPU, Memory, Disk und Container-Metriken von deinen Servern: Beszel, oder Komari für ein noch leichteres Setup.
• Du willst Fehler aus deinem Code mit den Sentry-SDKs fangen: GlitchTip, oder Rustrak für einen einzelnen kleinen Prozess.
• Deine Apps laufen schon auf Nodion und du brauchst Uptime-Alerts: das eingebaute Monitoring.

Jedes Tool läuft auf Nodion als eigene Instanz in der Region, die du wählst, EU Central (Frankfurt), US East oder US West. Alle Apps findest du im One-Click-Katalog.