UptimeAlien
UptimeAlien ist ein Monitoring-Dienst für Websites, APIs und Server. Er prüft in festen Intervallen, erkennt Ausfälle mit der nächsten fälligen Prüfung und alarmiert über den Kanal, den man tatsächlich liest. Betrieben wird er auf eigener Infrastruktur. Ich nutze ihn selbst für jede Anwendung, die ich in Wartung habe.
Über das Projekt
Uptime-Monitoring und Error-Tracking für Webseiten, APIs und Server: zwölf Prüfarten von HTTP, TCP und Ping über DNS, UDP und Zertifikatslaufzeiten bis zu Keyword-, JSON-Health- und Heartbeat-Checks, dazu zwölf Alarmkanäle von E-Mail und Discord über MQTT und ntfy bis PagerDuty. Mit öffentlichen Statusseiten, Incident-Verlauf und einer nativen Android-App fürs Monitoring unterwegs.
Funktionen im Überblick
- Zwölf Prüfarten, von HTTP, TCP und Ping bis Zertifikatslaufzeit, Keyword und Heartbeat
- Zwölf Alarmkanäle, von E-Mail, Discord und Slack über MQTT und ntfy bis PagerDuty
- Öffentliche Statusseiten und vollständiger Incident-Verlauf
- Checker-Worker als eigener Prozess, unabhängig von der Weboberfläche
- Native Android-App fürs Monitoring unterwegs
Warum ich es gebaut habe
Kommerzielle Monitoring-Dienste sind entweder teuer, sobald man mehr als eine Handvoll Checks braucht, oder sie schicken die Messdaten durch fremde Infrastruktur. Für den Betrieb eigener und fremder Anwendungen wollte ich beides nicht. Ich brauchte viele Checks, kurze Intervalle und die Gewissheit, dass Zugangsdaten und Statushistorie auf meinen eigenen Servern bleiben. Dazu kam ein praktisches Problem. Ein Ausfall um zwei Uhr nachts ist nur dann relevant, wenn die Benachrichtigung auch ankommt.
Wie es funktioniert
Ein eigenständiger Checker-Worker läuft als eigener Prozess neben der Web-Anwendung, liest die fälligen Prüfungen selbst aus der Datenbank und führt sie aus: HTTP und TCP, Ping und UDP, DNS-Auflösung, Zertifikats- und Domainlaufzeiten, Suche nach einem Schlüsselwort im Seiteninhalt, JSON-Health-Endpunkte, API-Prüfungen und Heartbeats fremder Cronjobs. Weil der Worker sich die Arbeit selbst zieht, statt von der Anwendung angestoßen zu werden, hängt das Monitoring nicht daran, dass die Weboberfläche gerade läuft. Erkannte Störungen landen in einem Incident-Verlauf mit Beginn, Ende und der Fehlermeldung der auslösenden Prüfung, statt nur „gerade offline" zu melden.
Alarmierung und Statusseiten
Benachrichtigungen gehen über zwölf Kanäle raus: E-Mail, Discord, Slack, Telegram, MQTT, ntfy, Gotify, PagerDuty, Opsgenie, generische Webhooks, Firebase Cloud Messaging für die eigene App und PushPig, meinen eigenen Push-Dienst. Welcher Kanal greift, hängt daran, wer erreicht werden soll: Ein Hausautomations-Setup hört auf MQTT, ein Team auf Discord oder Slack, eine Rufbereitschaft auf PagerDuty, ich selbst auf Push. Für Kunden und Nutzer gibt es öffentliche Statusseiten mit aktueller Verfügbarkeit und Verlauf. Das ersetzt die Rückfrage „liegt es an euch oder an mir?".
Technische Umsetzung
Die Web-Anwendung ist mit Next.js und React gebaut, der Datenzugriff läuft über Prisma, die Oberfläche über Tailwind CSS. Die Android-App ist native Kotlin-Entwicklung mit Jetpack Compose und bekommt Ausfälle per FCM zugestellt, sodass eine Störung auch ohne offenen Browser auffällt. Web und App teilen dasselbe Backend, ein Muster, das ich in Kundenprojekten genauso einsetze.
Weitere Projekte
Ein ähnliches Projekt im Kopf?
Was in meinen eigenen Produkten steckt, entwickle ich genauso für Ihr Vorhaben, von der Idee bis zum laufenden Betrieb.