Case: Observability-as-a-Service

Lernziele

Nach dieser Lektion kannst du eine Observability-Plattform als Self-Service für 60 Teams designen: Metriken, Logs und Traces mit Tenant-Isolation, Self-Service-Dashboards und -Alerts ohne Ticket, und Guardrails gegen das, was solche Plattformen erfahrungsgemäß umbringt — unkontrollierte Kardinalität und Log-Volumen. Du kannst die Build-vs-Buy-Frage mit einer Kostenabschätzung statt mit Bauchgefühl beantworten.

Das Szenario

„Designe eine Observability-Plattform für 60 Teams mit rund 300 Services. Teams sollen Metriken, Logs und Traces nutzen, eigene Dashboards und Alerts anlegen — ohne Ticket beim Plattform-Team. Team A darf die Daten von Team B nicht sehen. Retention: Metriken 15 Tage, Logs 7 Tage, Traces 3 Tage.” Das Besondere an diesem Case: Hier ist Datenvolumen die zentrale Designgröße. Wer keine Abschätzung macht, designt blind — und genau das testet der Interviewer.

Anforderungen klären: erst rechnen, dann entscheiden

Die Klärungsfragen zielen auf die Mengen:

• „Wie viele Pods, wie gesprächig sind die Services?” — Angenommen: ~3.000 Pods über alle Umgebungen, normale Web-Workloads.
• „Managed oder self-hosted — gibt es eine Budget- oder Datenschutzvorgabe?” — Angenommen: Budget ist sensibel, Daten sollen im eigenen Account bleiben. Die Frage ist trotzdem explizit zu stellen, weil sie das halbe Design entscheidet.
• „Wer definiert Alerts — und wohin gehen sie?” — Angenommen: Teams alarmieren sich selbst (eigene On-Call-Rotationen), die Plattform liefert das Routing.
• „Gilt die Tenant-Isolation hart (Compliance) oder weich (Übersichtlichkeit)?” — Angenommen: hart für Logs (können personenbezogene Daten enthalten), weich für Metriken.

Jetzt die Abschätzung, laut und grob: 3.000 Pods × konservativ 1.000–2.000 aktive Zeitreihen pro Pod ergeben 3–6 Millionen aktive Serien — zu viel für eine einzelne Prometheus-Instanz, also braucht das Backend horizontale Skalierung. Logs: 300 Services × im Schnitt 0,5–1 GB/Tag ergeben 150–300 GB/Tag, bei 7 Tagen Retention rund 1–2 TB komprimiert im Object Storage. Traces ungesampelt wären ein Vielfaches des Log-Volumens — daraus folgt direkt: Sampling ist Pflicht, keine Option. Diese drei Zahlen sind das Skelett der ganzen Antwort.

Architektur: drei Signale, ein Schreibpfad, Mandanten ab Ingestion

Empfehlung: self-hosted auf Basis des Grafana-Ökosystems — Mimir (oder Thanos) für Metriken, Loki für Logs, Tempo für Traces, alle drei mit Object Storage als Backend und nativer Multi-Tenancy: Jeder Schreib- und Lesezugriff trägt eine Tenant-ID, die Daten sind pro Mandant getrennt gespeichert. Das ist der entscheidende Architekturpunkt: Isolation passiert bei der Ingestion, nicht erst im Dashboard. Ein Grafana-Filter, der Team B ausblendet, ist keine Isolation — eine Tenant-ID, ohne die die Query gar nicht erst Daten sieht, schon.

Der Sammelpfad ist einheitlich: OpenTelemetry Collector auf jedem Node (DaemonSet) plus ein zentrales Gateway-Deployment. Der Collector reichert alles mit team- und service-Labels aus den Pod-Metadaten an und setzt die Tenant-ID — Teams instrumentieren mit OTel-SDKs, ohne das Backend zu kennen. Das hält die Build-vs-Buy-Entscheidung reversibel: Der Export-Endpunkt ist austauschbar, die Instrumentierung bleibt.

Lesen und Self-Service: Grafana mit Teams aus dem IdP, pro Team ein Folder mit Schreibrechten und Datasources, die die Tenant-ID des Teams erzwingen. Dashboards und Alert-Regeln leben als Code im Team-Repo und kommen per GitOps in die Plattform — kein Ticket, aber auch kein Klick-Wildwuchs, der beim nächsten Grafana-Upgrade verloren geht. Alert-Routing über Alertmanager: das team-Label bestimmt den Empfängerkanal, die Plattform pflegt nur die Routing-Matrix.

Dazu zwei Dinge, die den Unterschied zwischen Folien-Architektur und Betriebsrealität machen. Erstens Limits pro Tenant: maximale aktive Serien, maximale Ingestion-Rate für Logs, Sampling-Quoten für Traces — in Mimir/Loki konfigurierbar und ab Tag eins gesetzt, damit ein einzelnes Team die Plattform nicht fluten kann. Zweitens Golden Dashboards: Wer einen Service über das Plattform-Template deployt, bekommt automatisch ein Standard-Dashboard (Request-Rate, Fehler, Latenz) und Basis-Alerts generiert. Self-Service heißt nicht „jedes Team baut bei null an”, sondern „der Standardfall ist schon da”.

Einwände des Interviewers

„Ein Team deployt ein Label mit User-IDs — Millionen neuer Zeitreihen. Was passiert?” Der Kardinalitäts-Klassiker. Antwort in Schichten: Per-Tenant-Limits lehnen Serien oberhalb der Quote ab, das Problem bleibt beim Verursacher statt die Plattform zu kippen; der Collector kann bekannte unbounded Labels (Request-IDs, User-IDs) schon beim Sammeln droppen; und das betroffene Team sieht in seinen eigenen Metriken, dass es am Limit ist. Ehrlich dazu: Limits verhindern den Plattform-Ausfall, nicht den Datenverlust des Verursachers — das ist Absicht.

„Warum nicht Datadog? Ihr betreibt hier fünf verteilte Systeme.” Nicht reflexhaft verteidigen, sondern rechnen: Bei 3.000 Hosts/Pods und Custom-Metrics-Preismodellen landen SaaS-Angebote in dieser Größenordnung schnell bei Beträgen, die mehrere Plattform-Engineer-Stellen finanzieren — und das Log-Volumen wird bei volumenbasierter Abrechnung zum Verhaltenssteuerer („loggt weniger, es ist teuer”). Aber den Gegenpunkt ehrlich machen: Self-Hosting kostet reale Engineering-Zeit, und unterhalb einer gewissen Größe ist Managed schlicht rational. Die starke Antwort ist eine Schwelle, keine Ideologie.

„Wie isolierst du wirklich — reicht ein Grafana-Folder?” Nein, und genau das sagen: Folder-RBAC regelt, wer welche Dashboards sieht, nicht, wer welche Daten abfragen kann. Harte Grenze ist die Tenant-ID an der Datasource bzw. am Query-Gateway — Team A kann mit seiner Datasource physisch nur den eigenen Mandanten abfragen, egal welche Query es schreibt.

„Traces samplen — verliert ihr dann nicht genau den interessanten Request?” Differenzieren: Head-Sampling (Entscheidung am Anfang des Requests) ist billig, verwirft aber blind. Tail-Sampling im Collector-Gateway entscheidet nach Abschluss des Requests — Fehler und langsame Requests werden bevorzugt behalten, der gesunde Durchschnitt wird ausgedünnt. Kostet Puffer-Ressourcen im Gateway, ist aber die Antwort auf genau diesen Einwand.

Praxis

Spiele den Case 40 Minuten mit Timer, am Whiteboard oder Papier. Pflichtbestandteile:

1. Die Mengenabschätzung für alle drei Signale — Serien, GB/Tag, Sampling-Folgerung — bevor du ein einziges Tool nennst.
2. Der Schreibpfad als erzählter Datenfluss: SDK → Node-Collector → Gateway (Labels, Tenant-ID, Tail-Sampling) → Backends → Object Storage.
3. Die Isolations-Aussage „Tenant-ID ab Ingestion, Folder-RBAC nur für Sichtbarkeit”.
4. Die Kardinalitäts-Antwort in Schichten inklusive der ehrlichen Grenze.
5. Eine Build-vs-Buy-Abwägung mit Zahl und Schwelle statt Meinung.

Wiederhole mit verschobener Vorgabe: „nur 8 Teams, 40 Services” — und prüfe, ob du den Mut hast, dann Managed oder einen einfachen kube-prometheus-stack ohne Mandanten-Backend zu empfehlen. Dieselbe Architektur für jede Größe vorzuschlagen ist ein Warnsignal.

Typische Stolperfallen

Ohne Abschätzung in die Tool-Liste springen. „Prometheus, Loki, Tempo, Grafana” kann jeder aufzählen. Die Zahlen (Millionen Serien → horizontal skalierendes Backend, GB/Tag → Object Storage, Traces → Sampling) sind das, was die Tool-Wahl begründet.

Isolation mit Dashboard-Sichtbarkeit verwechseln. Folder-Berechtigungen sind UI-Kosmetik; ohne Tenant-Trennung im Query-Pfad liest jedes Team mit etwas PromQL-Kreativität fremde Daten.

Self-Service ohne Limits. Eine Plattform, bei der 60 Teams unbegrenzt Serien und Logs erzeugen dürfen, wird von ihrem erfolgreichsten Nutzer zerstört. Quoten gehören in den ersten Wurf, nicht ins Backlog.

Die Plattform überwacht sich selbst nicht. Wenn der Monitoring-Stack ausfällt, wer merkt es? Ein kleiner, unabhängiger Meta-Monitoring-Pfad (externer Blackbox-Check, separater Alert-Weg) gehört erwähnt — ein Satz genügt.

Interview-Vorbereitung

Deine Kernbotschaft: Ein einheitlicher OTel-Sammelpfad, mandantenfähige Backends mit Tenant-ID ab Ingestion, Self-Service über Golden Dashboards und Alerts-as-Code, und Per-Tenant-Limits als Überlebensgarantie — Build vs. Buy entschieden über eine Volumenrechnung, nicht über Vorlieben.

Rechne mit diesen Follow-ups:

• „Warum OpenTelemetry als Sammelschicht?” — Vendor-neutrale Instrumentierung; das Backend bleibt austauschbar, die teure Arbeit (Instrumentierung in 300 Services) wird nie wiederholt.
• „Wie funktioniert Alerting konkret?” — Alert-Regeln als Code im Team-Repo, GitOps deployt sie in den Tenant, Alertmanager routet über das team-Label an die On-Call-Kanäle der Teams.
• „Was kostet die Plattform — und wem stellst du es in Rechnung?” — Object Storage und Compute pro Tenant sind über die Tenant-ID zurechenbar; Showback pro Team macht Volumen-Diskussionen sachlich.
• „Metriken 15 Tage — und wenn ein Team 13 Monate für Kapazitätsplanung will?” — Downsampling/Langzeit-Tier im Object Storage für ausgewählte aggregierte Serien statt Voll-Retention für alles.

Zusammenfassung

Der Observability-Case wird über Zahlen gewonnen: Millionen aktive Serien erzwingen ein horizontal skalierendes Backend, hunderte GB Logs pro Tag erzwingen Object Storage, Traces erzwingen Tail-Sampling. Darüber liegt die Plattform-Schicht: ein OTel-Sammelpfad, Tenant-Isolation ab Ingestion, Self-Service als Golden Dashboards plus Alerts-as-Code, Limits gegen den Noisy Neighbor der Telemetrie. In der nächsten Lektion geht es um die Plattform, die alle anderen füttert: eine CI/CD-Build-Plattform für 200 Repositories — schnell, gecacht und isoliert.