OpenTelemetry steckt fest: Ein Datenblick auf Maintainer-Mangel und endlose Diskussionen
OTel isn't going well (and I made a spreadsheet about it)
OpenTelemetry gilt als Hoffnungsträger für vendor-neutrales Observability, doch die Community klagt seit Jahren über schleppende Fortschritte. Der Autor analysiert GitHub-Daten und zeigt: Die meisten SDKs hängen an wenigen Maintainern, während semantische Konventionen in endlosen PR-Diskussionen versinken. Ein Vergleich mit Envoy und Prometheus offenbart die strukturellen Probleme des Projekts.
Das eigentliche Problem in OpenTelemetry ist ein Dreifach-Crash: ein binäres Stabilitätsgate, eine sehr kleine Maintainer-Riege und ein enormer Umfang an Sprachen und Frameworks.
- osener
Was mich bei OpenTelemetry immer wieder verwirrt, ist, dass Tracing, Metriken und Logs alle unabhängig voneinander entworfen wurden. Ich wünschte, ich könnte meinen Code einmal annotieren und die endgültige Entscheidung, etwas als Metrik/Log/Trace zu exponieren, zur Laufzeit dynamisch treffen lassen.
Zum Beispiel: Wenn ich in einem Monitoring-Dashboard ein Diagramm ansehe und etwas Verdächtiges entdecke, möchte ich sagen können: "Wenn so etwas das nächste Mal wieder passiert, speichere mir bitte einen Trace." Das sollte ich mit einem einzigen Mausklick tun können.
Ich erinnere mich, dass sie die Tracing-Spezifikation/SDKs veröffentlichten und sagten: "Jetzt lasst uns mit Metriken und Logs weitermachen." Das ist mir nie ganz richtig vorgekommen.
- EdSchouten
Ich fand Instrumentierung nie als großes Problem. Klar, es erfordert mehr Aufwand, aber man bekommt viel mehr Wert, sobald man _geschäftliche_ Ereignisse versteht.
- psadri
OTel ist so frustrierend. Wenn es nicht auf dem besten Weg wäre, der klare Gewinner in diesem Bereich zu sein, würde ich mich nicht so sehr darüber beschweren. Aber heute:
1. Jeder große Anbieter hat immer noch eine seltsame Alpha-/Beta-Unterstützung für OTel, selbst nach all dieser Zeit.
2. Der Performance-Einbruch ist erheblich und lässt einen fragen, was der Sinn von Performance-Instrumentierung ist, wenn man jetzt doppelt so viel Rechenleistung/RAM benötigt, um dieselbe Arbeitslast auszuführen.
3. Serverless-Laufzeiten zahlen eine hohe Strafe für Kaltstarts mit OTel.
4. Man ist praktisch gezwungen, sowohl Gateway-Collector als auch Edge-Collector für jede realistische Nutzung zu betreiben.
5. Man muss die Ziel-Exporter immer noch auf einzigartige Weise konfigurieren. Das lässt einen fragen, was der Wert von OTel war.
6. Anbieter, die über den Umfang von OTel hinausgehen, benötigen immer noch ihre eigene maßgeschneiderte Instrumentierung. Was war dann der Sinn von all dem?