Kontext
Ein hoher fünfstelliger Jahresvertrag bei einem Observability-Vendor, dessen Stärke Full-Stack-Tracing über Services hinweg war. Das Produkt war gut. Die Drift war, dass das Ingest-Modell voraussetzte, dass wir ein OpenTelemetry-SDK in jedem Service einbauten, den wir beobachten wollten.
Wir hatten zwei Services auf einem Custom-RPC-Framework, das nicht zum SDK passte. Die Vendor-Roadmap hatte nichts dazu, einen Nicht-OTel- Adapter zu bauen, sie verdoppelten OTel als universelles Pipe-Modell. Unsere Roadmap hatte nichts dazu, diese zwei Services auf OTel umzuschreiben, weil das Rewrite den Aufwand für ein Tracing-Nice-to-have nicht wert war.
Wir zahlten den vollen Preis für ein Tool, das ungefähr 60 % unserer Produktions-Oberfläche abdeckte.
Was wir verlieren würden
Ich benannte das explizit, bevor ich irgendetwas anderes vorschlug, weil zu benennen, was du aufgibst, die einzige ehrliche Form einer Build-vs-Buy-Entscheidung ist.
- Distributed-Trace-Visualisierung über Services hinweg. Ihr Flame-Graph-UI war ehrlich besser als alles, was wir bauen würden.
- Die "smarte" Anomaly-Detection. Nützlich, aber nie der Auslöser für einen Page, das war immer ein Threshold-basierter Alert.
- Vendor-managed Retention. Das würde jetzt uns gehören.
Was wir behalten würden
- Query-Level-Dashboards (Grafana auf Postgres-basierten Timeseries).
- Incident-Timelines (ein 50-Zeilen-Slack-Archive-Scraper plus eine Postgres-Tabelle).
- Threshold-basierte Alerts (schon in PagerDuty, vendor-unabhängig).
Die Entscheidung
Den Vendor durch eine 400-Zeilen-Ingestion-Pipeline ersetzen, in Postgres schreiben, mit Grafana abfragen. Einen Engineer-Monat upfront zahlen, den Vertrag sparen.
Was eingetreten ist
Der Build kam in drei Sprints rein, nicht in einem. Der Slip lag an den langweiligen Teilen, die ich unterschätzt hatte:
- Multi-Tenant-Scoping in der Ingest-API (ein Sprint ungeplante Auth-Arbeit).
- Backfill von zwei Monaten historischer Daten, damit die "vorher / nachher"-Graphen in Incident-Reviews kein Loch hatten.
- Die Retention-Story, was behalten, was rollupen, was droppen, fraß einen Sprint Tuning.
Achtzehn Monate später: noch in Produktion, war nie Quelle eines Incidents. Das Team, das die Distributed-Trace-Visualisierung verlor, holte das meiste über eine zusammengestrickte View aus strukturierten Logs zurück; nicht so gut, aber gut genug für die Fälle, in denen sie es tatsächlich brauchten.
Was ich anders machen würde
Ich würde von Tag eins drei Sprints budgetieren, nicht einen. Die Schätzung war optimistisch aus dem offensichtlichen Grund: ich budgetierte die Kernarbeit, nicht das umliegende Scaffolding. Auth, Multi-Tenant-Scoping, Retention-Tuning, Backfill, das war alles die eigentliche Arbeit, und vorhersehbar genug, dass ich hätte padden sollen.
Ich würde auch das Was wir verlieren-Doc als Einseiter schreiben und zirkulieren, bevor der Build startet, nicht als Teil meines Pitches an die Führungsebene. Zwei Engineers hoben in der ersten Build-Woche das Flame-Graph-Verlust-Argument hervor. Hätten sie das Doc früher gesehen, hätten wir es entweder sauber adressiert oder, wahrscheinlicher uns geeinigt, dass der Verlust akzeptabel ist, und wären schneller vorangekommen.