Prometheus
64k ★
Time-Series-Datenbank
Scraped Metriken alle 15 Sekunden, speichert sie in einer eigenen TSDB, beantwortet Abfragen via PromQL. Das Herz des Stacks.
Apache-2.0Go
Stack im Einsatz
Observability-Stack — Prometheus + Grafana + Loki
Sieben Container, die zusammen einen vollständigen Observability-Stack bilden: Metriken sammeln, Logs aggregieren, Dashboards bauen, Alerts schicken. Eine konkrete Alternative zu Datadog und New Relic für Hoster und IT-Teams, die ihre Infrastruktur selbst im Blick behalten wollen.
Compose für den zentralen Observability-Host
services:
prometheus:
image: prom/prometheus:v3.5.0
container_name: prometheus
restart: unless-stopped
ports: ["9090:9090"]
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
- prometheus_data:/prometheus
command:
- --config.file=/etc/prometheus/prometheus.yml
- --storage.tsdb.retention.time=30d
networks: [observability]
grafana:
image: grafana/grafana:11.5.0
container_name: grafana
restart: unless-stopped
ports: ["3000:3000"]
volumes:
- grafana_data:/var/lib/grafana
environment:
- GF_SERVER_ROOT_URL=https://obs.hoster.de
- GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_ADMIN_PASS}
networks: [observability]
loki:
image: grafana/loki:3.4.2
container_name: loki
restart: unless-stopped
ports: ["3100:3100"]
volumes:
- ./loki-config.yaml:/etc/loki/local-config.yaml
- loki_data:/loki
command: -config.file=/etc/loki/local-config.yaml
networks: [observability]
alertmanager:
image: prom/alertmanager:v0.28.1
container_name: alertmanager
restart: unless-stopped
volumes:
- ./alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro
networks: [observability]
volumes:
prometheus_data:
grafana_data:
loki_data:
networks:
observability:Sieben Komponenten in einem Stack
Jede Komponente macht eine Sache gut. Zusammen ergeben sie einen Stack, der vollständig auf eigenem Server läuft und keine SaaS-Abhängigkeit hat. Alle sieben sind echtes Open Source.
Grafana
74k ★
Dashboards + Alerting
Frontend für und . Dashboards für Hosts, Container, Kunden. Alertmanager-Integration für Slack/E-Mail.
AGPL-3.0TypeScript
Loki
28k ★
Log-Aggregation
Wie für Logs: kein Volltext-Index, sondern Labels. Sehr ressourcen-effizient. Abfragen via LogQL.
AGPL-3.0Go
Promtail
28k ★
Log-Shipper auf jedem Host
Sammelt Logs aus journald, Docker-Containern, Dateipfaden und sendet sie an . Auf jedem zu überwachenden Host installiert.
AGPL-3.0Go
cAdvisor
19k ★
Container-Metriken
Liest CPU-, RAM-, Netzwerk-Metriken pro . Exportiert sie im Prometheus-Format. Auf jedem Container-Host läuft eine Instanz.
Apache-2.0Go
node_exporter
13k ★
Host-Metriken
Misst CPU-Load, RAM, Disk-IO, Netzwerk-Counter, System-Last des Hosts selbst. Auf jedem überwachten Host als Service oder Container.
Apache-2.0Go
Netdata
79k ★
Realtime-Monitoring (optional)
All-in-One-Echtzeit-Monitoring mit eigener UI. Ergänzend zu + — für 1-Sekunde-Reaktion bei akuten Problemen.
GPL-3.0C
Was leistet der Stack zusammen?
Die sieben Komponenten arbeiten in einem klaren Datenfluss: node_exporter und sammeln Metriken auf jedem überwachten Host und liefern sie auf Port 9100/8080 aus. scraped diese Endpunkte alle 15 Sekunden und speichert sie in einer Time-Series-DB. Promtail sammelt Logs aus Containern und journald und schickt sie an zur Aggregation. zeigt beides — Metriken und Logs — in Dashboards mit Alerting.
Das Ergebnis: eine einzige UI für alle Hosts, alle Container, alle Services. Wer wissen will, ob der Webshop seines Kunden noch läuft, ob die DB-Last hoch ist, ob ein bestimmter Fehler im Log auftaucht — schaut in , nicht in 18 separate SSH-Sessions. Datadog leistet dasselbe, aber kostet bei 18 Hosts ca. 5.000 €/Jahr — der Self-Hosted-Stack ist einmaliges Setup plus ein .
Warum ein Hoster Observability self-hosted
Ein kleiner Hosting-Anbieter mit 15–25 Kunden-VPS auf eigener Hardware hat zwei Probleme ohne zentrales Monitoring: Erstens kommt jede Information vom Kunden — 'Mein Shop ist down', 'der Server reagiert langsam', 'meine Mails kommen nicht durch'. Reaktiv. Zweitens, wenn man sich selbst Klarheit verschafft, geht es über 18 SSH-Sessions, htop, journalctl. Skaliert nicht.
Ein Observability-Stack dreht beides um: man sieht in , dass die Disk auf VPS-12 zu 91 % voll ist — bevor der Kunde ein Ticket öffnet. Alerts gehen per Slack raus. Logs sind durchsuchbar über alle Hosts gleichzeitig. Datadog würde dasselbe leisten — aber bei einem 6-Personen-Hoster machen 5.000 € Lizenzkosten pro Jahr einen großen Unterschied.
Mandantenfall
Schmidt-Werlich Hosting
Kleiner Managed-Services-Provider in Niedersachsen, 6 Personen, 18 Kunden-VPS auf eigenen Hetzner-Servern. Vor 8 Monaten von 'jeder loggt sich einzeln ein' auf zentralen Observability-Stack umgestellt. Heute: 1 Grafana-Dashboard für alle, Slack-Alerts für jedes Disk-Memory-Service-Problem, 30 Tage Metriken-Historie für Post-Mortems.
Einheitlicher Überblick über 18 VPS
Ein Dashboard, das den Zustand aller 18 Kunden-VPS auf einen Blick zeigt — CPU, RAM, Disk, Service-Status. Statt 18× SSH und htop.
Proaktive Alerts statt Tickets
Disk > 85 %, Memory > 90 %, Service nicht erreichbar — Slack-Alert in der Hoster-Channel. Bevor der Kunde merkt, dass etwas nicht stimmt, wird gehandelt.
30 Tage Metriken-Historie
Bei einem Post-Mortem: 'Warum war Server-X letzte Woche Mittwoch zwischen 14 und 16 Uhr nicht erreichbar?' — Antwort aus , mit Grafiken. Statt Mutmaßungen.
Container-Metriken pro Kunde
Welcher Kunde verbraucht wie viel RAM/CPU auf welcher ? Wichtig für faire Abrechnung und für Kapazitätsplanung. liefert pro Container die Daten.
Cross-Host Log-Analyse
Fehler-Pattern über alle 18 finden: 'Wer hat in den letzten 24 Stunden 5xx-Spikes?' — eine LogQL-Abfrage statt 18 SSH-Sessions mit grep.
Optional: Public Status-Page
Aus den Grafana-Daten heraus eine öffentliche Status-Page für Kunden generieren. Vertrauensbildend, reduziert Tickets bei bekannten Wartungsfenstern.
Acht produktive Patterns im Betrieb
Konkrete Setups, die Schmidt-Werlich seit 8 Monaten täglich nutzen. Jeder Pattern ersetzt entweder eine reaktive Tätigkeit oder ein Loch, das ohne zentrales Monitoring gar nicht gesehen wurde.
Host-Übersicht in Grafana
Hauptdashboard 'Hosts Overview': eine Zeile pro , Spalten für CPU%, RAM%, Disk%, Load, Uptime. Rote Zellen über Schwellwerten. Tagesblick: 30 Sekunden. Vorher: 30 Minuten Round-Robin-SSH.
Container-Übersicht
Dashboard 'Containers': zeigt für jeden Host alle laufenden Container mit RAM-/CPU-Verbrauch. Filter nach Kunde, nach Container-Image, nach Status. liefert die Daten, macht die Tabelle.
Slack-Alerts via Alertmanager
Prometheus-Regel: 'disk_usage{instance=*} > 85 over 5m' → Alertmanager → Slack-Webhook in #hosting-alerts. Plus Email-Fallback. Recovered-Notifications, wenn Problem behoben.
Log-Aggregation via Promtail
Auf jeder läuft Promtail als Service, liest Docker-Container-Logs und journald. Schickt zentral an . Label-Konvention: {host, container, customer, severity} — ermöglicht präzise Filterung.
LogQL für Fehler-Pattern
Beispiel: {level="error"} |= "connection refused" | rate(1m) zeigt Connection-Errors über alle Hosts der letzten Stunde. Anomalien sichtbar in Sekunden, ohne ssh + grep.
Custom-Dashboards pro Kunde
Pro Kunde ein eigenes Dashboard: nur dessen , dessen Container, dessen Logs. Beim Beratungsgespräch zeigt Schmidt-Werlich seinem Kunden konkret, wie dessen Infrastruktur sich entwickelt.
Prometheus-TSDB-Backup
Nächtliches Snapshot-Backup der Prometheus-TSDB (durchgehend Replikation würde Stack-Aufwand verdoppeln). 30 Tage Retention, älteres auf separates NAS verschoben für Compliance-Cases.
Public Status-Page
status.schmidt-werlich.de zeigt für jeden Kunden eine öffentliche Status-Ampel. Aus Prometheus-Daten generiert via Statping-Container. Reduziert Tickets bei bekannten Wartungsfenstern um ca. 40 %.
Was der Stack als Ganzes leistet
Sechs Stack-Level-Funktionen — Eigenschaften, die erst durch das Zusammenspiel der Komponenten entstehen.
Single-Pane-of-Glass
Eine UI für alle Daten. Egal ob Metriken, Logs oder Alerts: ist die zentrale Anlaufstelle. Mitarbeitende müssen nur ein System lernen, nicht sieben.
Time-Series-Datenbank mit Retention
speichert Metriken effizient (1 GB pro Million Datenpunkten). Standard-Retention 15 Tage, leicht auf 30 oder 90 Tage erweiterbar. Post-Mortems werden zur Routine.
Log-Aggregation ohne Volltext-Overkill
indexiert nicht den Volltext (wie Elasticsearch), sondern nur Labels. Resultat: 10× weniger RAM/Disk als ELK-Stack bei vergleichbarer Funktionalität für Log-Suche.
Multi-Host-Sammlung
Prometheus-Federation oder einfaches Multi-Target-Scraping: ein zentraler saugt Metriken von beliebig vielen Hosts ein. Skaliert von 5 bis 500 Hosts ohne Architektur-Umbau.
Alerting mit Routing
Alertmanager: pro Alert-Regel Empfänger definieren (Slack, Email, ). Silencing für Wartungsfenster. Inhibition: wenn Cluster down, keine 200 Einzel-Service-Alerts.
Container + Host gemeinsam
node_exporter für Host-Level (RAM, Disk, Load), für Container-Level (pro Container CPU, RAM, Netz). Beide zusammen geben das vollständige Bild — Host-Druck und Container-Druck.
Beispiel Prometheus-Alert-Regel
# /etc/prometheus/alerts/disk.yml
groups:
- name: disk
interval: 30s
rules:
- alert: DiskUsageHigh
expr: |
(
(node_filesystem_size_bytes - node_filesystem_avail_bytes)
/ node_filesystem_size_bytes
) * 100 > 85
for: 5m
labels:
severity: warning
annotations:
summary: "Disk auf {{ $labels.instance }} > 85% voll"
description: |
Mountpoint {{ $labels.mountpoint }} auf Host
{{ $labels.instance }} ist zu {{ $value | printf \"%.1f\" }}%
ausgelastet. Wartung erforderlich.
# → Alertmanager → Slack #hosting-alertsAlternativen ehrlich verglichen
Wenn der Self-Hosted-Stack nicht passt — was sonst?
Drei Alternativen mit unterschiedlichen Stärken. Der Self-Hosted-Stack ist der pragmatische Default für und kleine Hoster.
SaaS-Marktführer
Datadog
Datadog Inc., USA
- + Exzellente UX, sehr breite Integrations-Bibliothek
- + Out-of-the-box, in 30 Minuten produktiv
- − Sehr teuer (ab 15$/Host/Monat, kumulativ)
- − US-Cloud, Metriken-Daten wandern außer Haus
SaaS mit Freitier
New Relic
New Relic Inc., USA
- + 100 GB Ingest/Monat kostenlos
- + APM (Application Performance Monitoring) integriert
- − Nach Freitier Preise vergleichbar mit Datadog
- − US-Cloud, Metriken außerhalb DSGVO
Klassisch self-hosted
Zabbix
Zabbix LLC, GPL-2.0
- + Sehr ausgereift, seit 2001 produktiv
- + Auch ohne Docker einsetzbar
- − Monolithisch (eine große App)
- − UI fühlt sich altertümlich an
Faustregel: Wer 5–100 Hosts hat, IT-affine Mitarbeitende und Beratungs-Support, ist mit dem Self-Hosted-Stack pragmatisch unterwegs. Datadog/New Relic skalieren nur über den Geldbeutel — bei 50+ Hosts werden sie deutlich teurer als ein zusätzlicher Mini-PC. Zabbix bleibt eine Option für reine Infrastruktur-Monitoring ohne Container-Tiefe.
Pricing
Open Source. Ein zusätzlicher Host. Kein SaaS.
Lizenz
Alle 7 Komponenten Open Source: Prometheus + cAdvisor + node_exporter unter Apache-2.0, Grafana + Loki + Promtail unter AGPL-3.0, Netdata unter GPL-3.0. Für Eigenbetrieb ohne Re-Distribution keine Auflagen.
Laufende Kosten
Ein zusätzlicher Observability-Host: VPS mit 4–8 GB RAM, 100 GB Storage (Hetzner CPX31 ab 15 €/Monat). Plus minimaler Overhead auf jedem überwachten Host (node_exporter + cAdvisor + Promtail = ca. 50 MB RAM/Host). Bei 18 Hosts: 0,9 GB RAM zusätzlich verteilt.
Aufwand
Initial-Setup mit allen 7 Komponenten + ersten 5 Hosts: 2–3 Tage. Roll-Out auf weitere Hosts: 30 Minuten pro Host. Dashboard-Aufbau für Hoster-Setup (Multi-Tenant, Kunden-Dashboards, Alerts): 2 Beratungstage.
Datadog für 18 Hosts: ca. 5.000 €/Jahr. New Relic free tier reicht für ca. 10 Hosts. Self-Hosted-Stack: einmaliges Setup (5–8 Beratungstage) + 15 €/Monat . Break-even gegen Datadog bei Hosting-Anbietern typischerweise nach 2–4 Monaten.
Verwandte Themen
Observability ergänzt das übrige Toolset
macht externe Checks (HTTPS, DNS), macht Container-Inspektion, der Stack liefert die Infrastruktur-Sicht:
Bereit für den nächsten Schritt?
Kostenloses Erstgespräch. Unverbindlich. In 30 Minuten wissen Sie, ob und wie KI Ihrem Unternehmen helfen kann.