Observability-as-a-Service für Tenants

Lernziele

Nach dieser Lektion kannst du erklären, warum Observability eine Plattform-Capability sein muss und kein DIY-Projekt jedes Teams, wie du Metriken, Logs und Traces als Self-Service für Tenants bereitstellst und welche Guardrails Kosten, Cardinality und Datenschutz in Grenzen halten. Du kannst den Unterschied zwischen „Wir haben Prometheus im Cluster” und „Observability-as-a-Service” benennen und typische Betriebsfehler erkennen.

Das Problem: Jedes Team baut sein eigenes Monitoring

Ohne zentrale Observability-Schicht passiert in wachsenden Organisationen immer dasselbe: Team A installiert Prometheus im eigenen Namespace, Team B nutzt einen SaaS-Dienst mit anderem Label-Schema, Team C schickt Logs per Sidecar an einen selbst gehosteten Loki — und Team D hat nichts, weil „wir schauen bei Problemen in die Pod-Logs”. Wenn um 14 Uhr der Shared Ingress ausfällt, brauchst du vier verschiedene Dashboards und niemand kann sagen, ob das Problem beim Ingress, beim DNS oder beim Backend liegt.

Das ist kein Tool-Problem, sondern ein Plattform-Problem. Observability ist Voraussetzung für Betrieb — und Betrieb ist Voraussetzung für Production. Wenn jedes Team Observability selbst aufsetzen muss, hast du eine ungleiche Verteilung: Manche Teams haben exzellente Dashboards, andere keinen einzigen Alert. Incidents dauern länger, Postmortems fehlen Daten, und das Platform-Team wird zum Auffangbecken für „kannst du mal schauen, warum mein Service nicht läuft?”

Observability-as-a-Service bedeutet: Die Plattform liefert Metriken, Logs und Traces als eingeschaltete Capability — nicht als optionales Extra. Ein neues Environment aus Lektion 31 kommt mit ServiceMonitor, Log-Pipeline und Trace-Exporter vorinstalliert. Das Team konfiguriert nur noch seine Schwellwerte, nicht die Infrastruktur dahinter.

Die drei Säulen als Tenant-Service

Metriken sind der schnellste Weg zu SLIs. Prometheus (oder ein kompatibler Stack wie Mimir oder Thanos) scrapt standardisierte Endpoints — /metrics auf dem Pod oder ein vorkonfigurierter ServiceMonitor im Workload-Chart. Die Plattform definiert Pflicht-Labels (team, environment, service) und Cardinality-Limits. Ohne Letzteres explodiert die Metrik-Kosten, sobald ein Team user_id als Label verwendet.

Logs brauchen eine zentrale Pipeline: Fluent Bit oder Vector als DaemonSet sammelt Container-Logs, reichert sie mit Kubernetes-Metadaten an und schickt sie an Loki, OpenSearch oder einen SaaS-Backend. Der Tenant sieht seine Logs über Grafana oder ein Portal — gefiltert nach Namespace und Service, nicht nach Node-SSH.

Traces sind die teuerste Säule, aber unverzichtbar für verteilte Systeme. OpenTelemetry als Standard-Instrumentierung, ein zentraler Collector, ein Backend wie Tempo oder Jaeger. Die Plattform liefert SDK-Konfiguration und Sampling-Defaults; Teams aktivieren Tracing per Annotation oder Environment-Variable, nicht durch eigenes Jaeger-Deployment.

Der entscheidende Punkt: Alle drei Säulen teilen dieselbe Tenant-Identität. Derselbe service-Label verknüpft Metrik-Spike, Log-Fehler und langsamen Trace — ohne dass der On-Call drei Systeme manuell korrelieren muss.

Self-Service ohne Wildwest

Self-Service heißt nicht „jeder darf alles”. Die Plattform stellt bereit:

• Vorkonfigurierte Dashboards pro Service-Typ (HTTP-API, Worker, CronJob) mit den wichtigsten RED-Metriken (Rate, Errors, Duration).
• Alert-Templates mit sinnvollen Defaults — der Tenant setzt Schwellwerte, nicht die Alertmanager-Routing-Regeln von Grund auf.
• Quota pro Tenant für Log-Volumen, Metrik-Serien und Trace-Samples.
• Retention-Stufen — sieben Tage für Debug, dreißig für Incidents, länger nur auf Antrag.

Was das Platform-Team nicht dem Tenant überlässt: Betrieb des Prometheus-Operators, TLS-Zertifikate der Log-Pipeline, Cardinality-Enforcement und die Verfügbarkeit des Observability-Stacks selbst. Das ist eure SLO-Verantwortung — und genau deshalb braucht Observability eigene SLIs, bevor ihr sie als Service verkauft.

Kosten und Cardinality: der unterschätzte Betriebsaspekt

Observability ist nicht kostenlos. In Cloud-Umgebungen zahlt ihr für Storage, Ingress und Compute der Pipeline. Selbst on-prem bindet Observability RAM und Disk — und schlecht designte Metriken skalieren linear mit Traffic, nicht mit Teamzahl.

Drei Regeln, die du als Platform Engineer durchsetzen solltest:

1. Keine unbounded Labels. user_id, request_id oder url_path als Prometheus-Label sind verboten — sie erzeugen pro Wert eine neue Zeitreihe. Das gehört in Logs oder Traces.
2. Sampling für Traces. 100 % Tracing in Produktion ist selten nötig. Head-based Sampling bei 1–10 % reicht für die meisten Diagnosen; Tail-based Sampling für Fehler-Spuren.
3. Log-Level-Disziplin. DEBUG in Produktion ohne Rate-Limit füllt das Backend. Default ist INFO; DEBUG nur temporär per Feature-Flag.

Diese Regeln gehören in Policy-as-Code und in die Onboarding-Dokumentation — nicht in ein Wiki, das niemand liest.

Praxis: Observability für ein neues Environment aktivieren

Gehe vom Staging-Environment aus Lektion 31 aus — Team Checkout, Service checkout-api.

1. Prüfe Auto-Discovery: Wurde beim Provisioning ein ServiceMonitor angelegt? Zeigt kubectl get servicemonitor -n checkout-staging einen Eintrag?
2. Metriken validieren: In Grafana das Team-Dashboard öffnen — kommen http_requests_total und Latenz-Histogramme an? Fehlen Labels, stimmt das Chart-Template.
3. Logs testen: Einen absichtlichen Fehler provozieren (curl gegen einen nicht existierenden Endpoint). Erscheint der Stacktrace in der Log-Ansicht innerhalb von 30 Sekunden?
4. Alert anlegen: Über das Self-Service-Portal einen Alert auf Error-Rate > 5 % für fünf Minuten setzen. Kommt die Test-Notification im Team-Channel an?
5. Trace optional aktivieren: OTel-Annotation setzen, eine Request-ID durch den Service jagen, im Trace-Backend den Call-Tree prüfen.

Wenn Schritt 1–4 ohne manuelles Eingreifen des Platform-Teams funktionieren, ist Observability-as-a-Service real — nicht nur auf Folien.

Typische Stolperfallen

„Prometheus läuft, also haben wir Observability” — Ein Prometheus ohne ServiceDiscovery, ohne Alerting und ohne Tenant-Trennung ist ein Metrik-Silo, kein Service.

Fehlende Korrelation: Metriken, Logs und Traces in drei getrennten UIs ohne gemeinsame Labels. Der On-Call verliert Minuten pro Incident — multipliziert mit Teamzahl.

Kein Platform-SLO für den Stack: Wenn Loki drei Stunden down ist, sind alle Teams blind — und niemand pagerd, weil „Observability kein Produktions-Service” ist. Ist es aber, sobald ihr ihn zentral anbietet.

Cardinality-Ausreißer erst bei der Rechnung entdeckt: Monitoring-Kosten explodieren, und das Platform-Team muss nachträglich Labels verbieten. Besser von Anfang an enforced.

Interview-Vorbereitung

Auf „Was ist Observability-as-a-Service?” antwortest du: Problem (ungleiche Monitoring-Reife, lange Incident-Zeiten, Platform-Team als Auffangbecken) → Lösung (zentrale Metriken/Logs/Traces als eingeschaltete Tenant-Capability mit Self-Service-Konfiguration) → Grenze (Plattform betreibt Pipeline und Enforcement, Teams besitzen Alerts und Dashboards) → Betrieb (Cardinality, Kosten, eigene SLOs).

Follow-ups:

• „Wie trennst du Tenants?” — Namespace-basierte RBAC in Grafana, Log-Filter, Prometheus-Recording-Rules oder dedizierte Tenants in Mimir/Loki.
• „RED oder USE?” — RED für Request-driven Services (APIs), USE für Ressourcen (Nodes, Datenbanken). Beides im Standard-Dashboard.
• „Wie verhinderst du Label-Explosion?” — Admission-Policy, Prometheus-Relabeling, Cardinality-Limits im Remote-Write-Backend.

Zusammenfassung

Observability-as-a-Service macht Metriken, Logs und Traces zur eingeschalteten Plattform-Capability: automatisch provisioniert mit jedem Environment, tenant-isoliert, mit Self-Service für Alerts und Dashboards. Das Platform-Team betreibt Pipeline, Cardinality-Kontrolle und Verfügbarkeit; Teams konfigurieren Schwellwerte, nicht Infrastruktur. Ohne gemeinsame Labels über alle drei Säulen und ohne eigene SLOs für den Stack bleibt Observability ein Flickenteppich.

Als Nächstes verschieben wir den Blick auf die Pipeline, die den Code ins Environment bringt: die CI/CD Build Platform mit Shared Runners, Caching und Artifact-Registry.