Telemetrie selbst gehört: Ein selbstgehosteter Observability-Stack für digitale Souveränität
🇬🇧 Read in English~3 min read
devopsobservabilitysovereigntymonitoringprometheusgrafanaself-hosting
Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowSave products you love by clicking the heart icon.
Umfassender Leitfaden zum Erstellen effektiver Grafana-Dashboards für das Infrastruktur-Monitoring mit mehreren Datenquellen und Alerting.
Die Souveränitätsfrage 2026: Wer hält eigentlich eure Metriken? Die meisten Teams hängen Logs, Traces und Nutzerverhalten an einen in den USA gehosteten SaaS-Dienst und nennen das Observability. Die Rechnung kommt später — als Risiko für den Datenstandort, als Lock-in bei der Vertragsverlängerung und als Dashboard, das man nicht auditieren kann.
💡 Fakt: Jeder Error-Trace, jeder User-Agent und jeder Request-Pfad, den ihr an einen Observability-Anbieter sendet, verlässt eure Jurisdiktion. Unter der DSGVO ist das eine Transfer-Entscheidung, kein Konfigurationsdetail.
Eine gemanagte Observability-Plattform ist bequem — bis sie es nicht mehr ist. Die strukturellen Kosten sind die, die wehtun:
| Kosten | Was das bedeutet | Beispiel |
|---|---|---|
| Datenstandort | Telemetrie verlässt eure Jurisdiktion | EU-Nutzerdaten in einer US-Region |
| Vendor-Lock-in | Query-Sprache und Agenten sind proprietär | Kein Export ohne Re-Instrumentierung |
| Undurchsichtige Preise | Kosten skalieren mit Ingestion, nicht mit Wert | 10× Rechnung nach einem lauten Service |
📊 Die Trade-off in einem Satz: ihr tauscht Kontrolle gegen Bequemlichkeit — und Bequemlichkeit wächst sich zu Abhängigkeit aus.
Ein selbstgehosteter Stack bedeutet nicht, Telemetrie neu zu erfinden. Es bedeutet, vier ausgereifte Open-Source-Projekte hinter die eigene Netzwerkgrenze zu stellen:
🔍 Warum diese vier: es sind genau die Komponenten, auf die sich die CNCF-Landschaft bereits geeinigt hat. Sie selbst zu hosten, gibt euch den gleichen Workflow wie ein SaaS — minus dem Jurisdik-tionsproblem.
Vergleich: selbstgehostet vs. SaaS-Observability
| Dimension | Selbstgehostet (Prometheus / Loki / Grafana) | SaaS (Datadog / Grafana Cloud) |
|---|---|---|
| Datenstandort | Eure Infrastruktur | Region des Anbieters |
| Query-Sprache | PromQL / LogQL (offen) | Proprietär |
| Lock-in | Keiner — Standardformate | Hoch |
| Grenzkosten | Storage und Compute, die ihr ohnehin betreibt | Pro Host / pro GB Ingestion |
| Aufwand | Ihr betreibt es | Anbieter betreibt es |
Alloy steht am Rand eurer Services und liefert an Prometheus (Metriken) und Loki (Logs). Grafana liest beide. Es verlässt nichts euer Netzwerk:
services ──> Alloy ──> Prometheus (Metriken)
└─────> Loki (Logs)
Grafana ──queries──> Prometheus + Loki
scrape_configs:
- job_name: app
static_configs:
- targets: ["app:3000"]
- job_name: alloy
static_configs:
- targets: ["alloy:12345"]
logging {
level = "info"
}
loki.source.file "app_logs" {
targets = [{"__path__" = "/var/log/app/*.log"}]
forward_to = [loki.write.local.receiver]
}
loki.write "local" {
endpoint { url = "http://loki:3100/loki/api/v1/push" }
}
Selbsthosting ist nicht kostenlos. Die ehrliche Liste:
💡 Faustregel: wenn ein verpasstes Dashboard heute niemanden pagen würde, reicht ein selbstgehosteter Stack auf demselben Kubernetes, dem ihr ohnehin vertraut, vollauf aus.
/metrics-Endpunkt.Eure Telemetrie selbst zu besitzen ist die günstigste Souveränität, die ihr je kaufen werdet — denn für den Compute zahlt ihr ohnehin schon.