Zum Hauptinhalt springen
Warum wir ein eigenes Server-Monitoring gebaut haben (anstelle von Prometheus oder Datadog)

Warum wir ein eigenes Server-Monitoring gebaut haben (anstelle von Prometheus oder Datadog)

·4 min·
Monitoring SaaS DevOps Linux Hinter-Den-Kulissen
Inhaltsverzeichnis

Die ewige Suche nach dem passenden Monitoring
#

Als DevOps- und Cloud-Engineers verbringen wir unsere Tage meistens damit, hochverfügbare Kubernetes-Cluster zu orchestrieren und Terraform-Pipelines zu schreiben. Aber abseits der großen Enterprise-Projekte haben wir alle diese eine Hetzner-Kiste, ein paar kleine VPS bei Netcup oder IONOS und diverse VMs für Kundenprojekte.

Und genau da fing der Frust an. Wie behält man diese Server im Blick, ohne direkt wieder ein halbes System-Engineering-Projekt daraus zu machen?

Wer heute Linux-Server überwachen will, landet meist bei einer dieser drei Sackgassen:

  1. Die Prometheus-Falle: Man setzt den klassischen Stack auf (Prometheus, Node Exporter, Grafana, Alertmanager). Das funktioniert super, hat aber einen massiven Wartungsschwanz. Man muss Updates einspielen, Backups machen und am Ende die ironische Frage beantworten: Wer überwacht eigentlich den Monitoring-Server, wenn der offline geht?
  2. Das Kreditkarten-Minenfeld: Man bucht Datadog oder New Relic. Absolut geniale Tools, aber für ein paar einfache VMs völlig überdimensioniert und unbezahlbar. Dazu kommt die Abrechnung, die sich oft wie ein Glücksspiel anfühlt. Und die DSGVO? Die US-Server dieser Anbieter treiben europäischen Rechtsabteilungen regelmäßig Schweißperlen auf die Stirn.
  3. Der Uptime-Trugschluss: Man nutzt einfache Ping-Dienste. Klar, man weiß, ob der Webserver auf Port 443 reagiert. Aber man merkt eben erst, dass die Festplatte zu 100 % voll ist oder der PostgreSQL-Dienst im Hintergrund im Bootloop steckt, wenn die Anwendung schon lange tot ist und die ersten Kunden anrufen.

Wir wollten ein echtes White-Box-Monitoring, das die inneren Werte des Servers (CPU, RAM, Disk, systemd-Dienste und Docker-Container) kennt, innerhalb von zwei Minuten läuft und uns nicht zwingt, Firewalls umzukonfigurieren oder DSGVO-Bedenken zu haben.

Weil wir nichts Passendes gefunden haben, haben wir es selbst gebaut: WatchGrid .


Die Vision: Kein Bullshit, kein Konfigurationsaufwand
#

Unser Ziel war ein Tool, das sich so einfach wie ein Uptime-Checker anfühlt, aber die Datentiefe eines echten Server-Agenten liefert.

Drei Dinge standen bei der Entwicklung ganz oben auf dem Zettel:

  • Ein-Befehl-Installation: Keine ellenlangen Config-Dateien. Ein Terminal-Befehl (curl | sh), und der Server taucht im Dashboard auf.
  • Sicherheit ohne offene Ports: Wer will schon eingehende Firewall-Ports für Monitoring öffnen? Unser in Go geschriebener Agent baut eine sichere HTTPS-Verbindung ausgehend zum WatchGrid-Backend auf. Fertig.
  • Zero Maintenance: Der Agent verbraucht kaum CPU, belegt nur wenige Megabyte RAM und aktualisiert sich im Hintergrund vollautomatisch selbst.
  • Standort Deutschland: Gehostet wird der gesamte Stack in deutschen, ISO-27001-zertifizierten Rechenzentren. Keine Cookies, kein Tracking, DSGVO-konform.

So läuft das Ganze ab
#

Die Architektur haben wir bewusst schlank gehalten. Der Agent sammelt die lokalen Daten und schickt sie verschlüsselt an unsere API:

graph TD
    subgraph "Ihr Linux-Server"
        Metrics["System-Metriken (CPU, RAM, Disk, systemd, Docker)"]
        Agent["Go-Agent (Leichtgewichtig)"]
        Metrics --> Agent
    end

    subgraph "WatchGrid Backend (Deutschland)"
        API["WatchGrid API-Gateway"]
        DB["Sichere Datenbank"]
        Dashboard["Dashboard (Uptime & Auslastung)"]
        Alerting["Alerting-System"]
        
        API --> DB
        DB --> Dashboard
        DB --> Alerting
    end

    subgraph "Benachrichtigungen"
        Channels["Kanäle (Slack, Discord, E-Mail, SMS, ntfy)"]
    end

    Agent -->|HTTPS ausgehend / TLS| API
    Alerting --> Channels

    style Agent fill:#1e40af,stroke:#1e3a8a,color:#fff
    style Dashboard fill:#10b981,stroke:#047857,color:#fff
    style Alerting fill:#ef4444,stroke:#b91c1c,color:#fff

Vom internen Tool zum SaaS-Produkt
#

Angefangen hat alles als kleines internes Tool, um unsere eigenen Server und Kundenprojekte zu überwachen. Aber im Gespräch mit befreundeten Entwicklern und Agenturen wurde schnell klar: Wir sind absolut nicht die Einzigen, die von komplexen Setups genervt sind.

Besonders Agenturen, die viele kleine bis mittlere Server für Kunden betreuen, standen vor demselben Problem. Sie wollten ihren Kunden einfache Uptime-Reports zeigen können, ohne dafür hunderte Euro auszugeben oder Stunden in Grafana-Dashboards zu versenken.

Deshalb haben wir die letzten Monate genutzt, um das Backend auf solide Füße zu stellen, das Dashboard intuitiv zu gestalten und eine Menge nützlicher Benachrichtigungskanäle anzubinden – von E-Mail und Slack über Discord, Gotify, Ntfy bis hin zu SMS-Benachrichtigungen für die wirklich kritischen Momente.


Ein faires Modell für Entwickler und Bastler
#

Wir sind selbst Entwickler und hassen undurchsichtige Paywalls. Deshalb war uns wichtig, dass man WatchGrid für private Setups und Sideprojects komplett kostenlos nutzen kann.

Unser Free-Tarif bleibt dauerhaft kostenlos:

  • Bis zu 3 Server (Agenten) im Monitoring
  • 5-Minuten-Intervall
  • 24 Stunden Historie
  • Benachrichtigungen via Discord, Gotify, Ntfy und Webhooks

Wenn Sie mehr Server benötigen, kürzere Intervalle (bis zu 30 Sekunden) oder zusätzliche Alarmierungswege wie SMS und Slack brauchen, gibt es kostenpflichtige Tarife (Basic, Pro und Enterprise) ab 12 € im Monat – flexibel anpassbar und ohne Lock-in.


Probieren Sie es einfach aus!
#

Wir haben WatchGrid gebaut, um uns das Leben als Admins und Entwickler leichter zu machen. Keine nervige Konfiguration, kein Wartungsaufwand, sondern einfach nur ein solides Monitoring, das Bescheid gibt, wenn es brennt.

Die Einrichtung des ersten Servers dauert unter einer Minute. Schauen Sie gerne auf watchgrid.de vorbei und testen Sie es selbst. Wir freuen uns riesig über Feedback, Kritik und Verbesserungsvorschläge!

Timo Staudinger
Autor
Timo Staudinger
Staff Engineer Cloud/DevOps

Verwandte Artikel

CI/CD in der Praxis
·5 min
DevOps Article
Ein kleiner Überblick, was es bei CI/CD zu beachten gibt und wie Sie es erfolgreich einsetzen
msmtp als SMTP Client einrichten
·7 min
Mail How-To Configuration Linux
Serverlogs und Ausgaben von fehlschlagenden Jobs per Mail erhalten? Mit msmtp kein Problem.
Restic Backups
·6 min
Backup How-To Scripting Linux
Wie mit wenig Aufwand und einem Shell-Skript ein nachhaltiges Backup-Konzept erzeugt werden kann.