OTel gaat niet goed (en ik heb er een spreadsheet over gemaakt)

Leveranciers-SDK's voor observability zijn, om het netjes uit te drukken, 'hufterproof'. Je installeert het pakket, de dashboards laden automatisch de data, iemand anders maakt zich zorgen over hoe alle onderdelen in elkaar passen, en jij kunt doorgaan met je werk. OpenTelemetry daarentegen verwelkomt je bij de deur met een heleboel "experimentele" stempels en ongeveer zes verschillende manieren om een specifieke taak uit te voeren.

In verdediging van OpenTelemetry: dit was nooit het doel van het project. Ik heb respect voor het feit dat ze vast zijn blijven houden aan hun visie om een echt leverancier-agnostisch systeem te bouwen dat er niet om geeft wat je met de data doet. Ik heb nooit het gevoel gekregen dat een specifieke leverancier sterker wordt bevoordeeld binnen OTel, wat een knappe prestatie is gezien hoe lucratief en competitief het observability-ecosysteem is, en wetende dat de maintainers van dit project grotendeels in dienst zijn van precies die bedrijven.

Naarmate de jaren verstreken, begon ik echter zenuwachtig te worden. Discussies in de semantic-conventions repository slepen eindeloos voort. Verschillende talen hebben totaal verschillende verhalen. Golang en .NET zijn eersteklas burgers, maar andere talen lopen jaren achter.

Ik ben begonnen met het stellen van kritische vragen voordat ik OpenTelemetry aanbeveel aan kleinere teams die niet de tijd, het budget of de emotionele capaciteit hebben voor de complexiteit. Auto-instrumentatie is oprecht magisch, maar de afgrond tussen "auto-instrumentatie werkt" en "nu moet ik iets handmatig instrumenteren" is zo steil dat je mensen moet waarschuwen voordat je ze eroverheen duwt.

Dit narratief is al een tijdje gaande in de observability-ruimte; een vaag gevoel dat er "iets mis is in OTel-land". Laten we proberen hier daadwerkelijke data over te genereren. Is er een echt probleem, of is de perceptie van trage voortgang een illusie? Ligt het probleem aan een gebrek aan maintainers, een te grote scope, of iets daartussenin?

Mijn aanvankelijke gok was: "dit is een klassiek geval van een open-source project dat meer heeft gebeten dan het kan kauwen", met te weinig maintainers en budget. Dat speelt mee, maar er is meer aan de hand.

Het werkelijke probleem binnen OpenTelemetry is een "three-way crash". Je hebt een poort voor binaire stabiliteit die, in combinatie met een zeer kleine groep actieve maintainers, leidt tot begrijpelijke angst om een functie als 'niet-experimenteel' te markeren. Tel daar een enorme scope aan talen en frameworks bij op die ze proberen te ondersteunen, en je hebt een perfecte storm. Er is een sterke incentive om te discussiëren over potentiële problemen die een functie zou kunnen veroorzaken, omdat deze zodra ze zijn vastgelegd en als stabiel zijn verscheept, nooit meer gewijzigd kunnen worden.

Hoe OpenTelemetry werkt

OpenTelemetry probeert momenteel een duizelingwekkend aantal talen en frameworks te ondersteunen. Het is een gigantisch project dat tientallen talen, honderden bibliotheken en talloze backends beslaat. Om het overzichtelijk te houden, splitst het project het werk in twee categorieën:

  • Core: Direct beheerd door het OTel-project. Klein, stabiel, leverancier-neutraal en strikt beoordeeld. Dit is het oppervlak dat de specificaties definieert.
  • Contrib: Bijgedragen door de community en leveranciers. Breder, beweegt sneller en dekt de lange staart van integraties.

Er bestaat ook de otel-collector, het onderdeel dat naast je applicatie draait zodat je logs, metrics en traces kunt versturen. Deze volgt hetzelfde patroon. Voor de programmeertalen ziet de verdeling er als volgt uit:

  • opentelemetry-python (core): De API, SDK, OTLP-exporter, context propagation en resource detection primitives.
  • opentelemetry-python-contrib: Instrumentatiebibliotheken voor Flask, Django, requests, psycopg2, Redis, Kafka, boto3, etc.

Zaken die kunnen breken gaan naar contrib; zaken die niet mogen breken gaan naar core.

Dit veroorzaakt echter een conflict. Contrib is voor de meeste projecten enorme overkill. Je wilt niet 300 exporters toevoegen om er slechts één te gebruiken. Aan de taalzijde is dit geen groot probleem; pip install opentelemetry-instrumentation-flask geeft je precies wat je nodig hebt voor Flask. Aan de collector-zijde eindig je echter bij de OpenTelemetry Collector Builder om je eigen collector te maken (of je hoopt gewoon dat het standaard werkt). Hoewel het cool is dat dit bestaat, is het veel gevraagd van een team om deze scope op zich te nemen.

Het proces voor het toevoegen van een nieuwe functie

Ik geloof dat ik de workflow voor het toevoegen van een nieuwe functie aan OTel als volgt heb vastgesteld:

  1. OpenTelemetry Enhancement Proposal (OTEP): Een voorstel wordt ingediend.
  2. Specification: Zodra de OTEP is geaccepteerd, wordt de tekst opgenomen in de Specification-directory.
  3. Semantic Conventions: Hier worden de specifieke details bepaald. Dit is waar de meeste lange discussies plaatsvinden, omdat dit een nagenoeg permanente commitment aan het ontwerp is.
  4. SDK Implementatie: Elke SDK implementeert het API-oppervlak dat in de specificatie is gedefinieerd. (Sommige SDK's hebben inmiddels 2.0 breaking changes doorgevoerd, wat suggereert dat de angst voor breaking changes is afgenomen).
  5. Contrib / Instrumentatie: Dit is flexibeler; elk contrib-pakket kan onafhankelijk versienummeren, hoewel ze de nieuwste API/SDK zouden moeten volgen.
  6. Collector + OTLP: De data moet ergens heen. OTLP (het wire protocol) heeft zijn eigen stabiliteitscyclus en specificatie. Collector-componenten hebben hun eigen stabiliteitsstatus in hun README's, wat nogal inconsistent is.

Onduidelijkheden:

  • Het is onduidelijk hoe lang het proces van OTEP naar Specificatie duurt; er is geen voorspelbare cyclus.
  • De relatie tussen de verschillende stabiliteitsbeloften is onduidelijk. Werken Collector + OTLP in lockstep? Kan een taal "buiten scope" vallen als deze te ver achterblijft?

Het testen van de hypothese

Omdat OpenTelemetry een CNCF-project is, leek het zinvol om hen te vergelijken met andere CNCF-projecten, specifiek Envoy en Prometheus. Ik heb een Python-script gebruikt om de "gezondheid" van deze open-source projecten te meten over een periode van 24 maanden.

Bij Envoy zien we een gezond project met een goede distributie van auteurs, mergers en mensen die issues sluiten. Er is een brede groep mensen die kan bijspringen.

Als we dit vergelijken met een van de OpenTelemetry-talen, bijvoorbeeld PHP, zien we een heel ander beeld. De activiteit is extreem geconcentreerd rond slechts twee personen. Dit is geen gezond open-source project; ze hebben simpelweg niet genoeg mensen om de scope van OTel te dekken. Hetzelfde geldt voor Ruby.

De sterkste OTel-SDK's, zoals Golang en .NET (en in zekere mate Python), zien er gezonder uit.

Concentratie van onderhouders

Het eerste probleem is dat er te veel concentratie is bij te weinig maintainers. Idealiter zijn de auteurs niet ook de enige personen die PR's mergen en issues sluiten.

Ik denk dat de maintainers hun best doen om discussies publiek te houden, maar het project lijkt bevroren door de hoge verwachtingen van stabiliteit. Het is een klassiek geval van: "iemand moet de maintainers betalen". Het project is te complex om als hobby uit te voeren. Iemand die zich verbindt aan zulke lange stabiliteitscontracten kan niet rekenen op hobbyisten. De mensen die dit kritieke werk doen, hebben bovendien verwachtingen van hun werkgevers.

Overzicht van maintainer-concentratie (laatste 24 maanden):

RepositoryMerged PRsDistinct MergersTop-1 Merger %Top Merger Role
opentelemetry-cpp544486.1%Single human (marcalff)
opentelemetry-kotlin281279.7%Single human (fractalwrench)
opentelemetry-browser102479.5%Single human
opentelemetry-ruby213578.7%Single human
opentelemetry-js8291464.9%Highly concentrated
opentelemetry-python486461.4%Single human (xrmx)
opentelemetry-php181253.0%Two mergers total
semantic-conventions911949.7%Single human (lmolkova)
opentelemetry-go686536.9%Distributed bench
opentelemetry-dotnet657631.5%Distributed bench
prometheus1,8493114.4%Broad bench
envoy5,4322835.8%Broad bench

Semantische conventies

Gezien het enorme oppervlak aan frameworks en talen is het logisch om de discussie over conventies op één plek te concentreren: https://github.com/open-telemetry/semantic-conventions.

Als discussies tussen leveranciers de vertraging zouden veroorzaken, zouden we dat hier moeten zien in de PR's. Ik keek naar de traagste PR's:

PRDagenCommentsReviewsTopic
#2083277.517115MCP semantic conventions
#2617258.62913GCE instance labels
#1698187.937rename azure_ → azure.
#2619174.6248GCE instance group manager
#3118147.1198GraphQL Recommended vs Opt-In

Hoewel sommige PR's traag zijn, gaat het vaak om complexe onderwerpen. Interessant is dat deze vertraging niet direct doorstroomt naar de SDK/API-ruimte, wat suggereert dat OTel er goed in is om deze gesprekken te isoleren.

In Python zien we dat de traagste PR's niet gerelateerd zijn aan semantische conventies, maar aan de extra vereiste "Approve Public API check", die een extra maintainer vereist. Dit brengt ons terug bij het kernprobleem: te weinig maintainers.

Mogelijke oplossingen

Het patroon is duidelijk: een nieuwe functie doet er erg lang over om de eindgebruiker te bereiken omdat stabiliteit zeer serieus wordt genomen, terwijl de pool van talent beperkt is. De implementatie van de API en het doorvoeren van wijzigingen rust op een overwerkte groep maintainers.

Een idee is het toevoegen van een tijdgebonden beta-tier tussen "Experimental" en "Stable". Voor veel gebruikers bestaan experimentele functies simpelweg niet omdat ze te moeilijk toegankelijk zijn. Als een functie in een beta-fase zou zitten — waarbij bekend is dat de functie minstens 12 maanden blijft bestaan zonder verwijdering en toegankelijker is voor de gebruiker — zou het project veel meer bruikbare feedback krijgen.

Het traject zou dan zijn: Experimental → Beta → (12 maanden) → Verwijdering of Stable.

Momenteel bestaat "Beta" in OTel, maar dit wordt gebruikt voor SDK's, niet voor componenten. De huidige definities zijn als volgt:

  • Development: Niet alle onderdelen zijn aanwezig; mag niet in productie worden gebruikt; kan zonder waarschuwing worden verwijderd.
  • Alpha: Klaar voor beperkte, niet-kritieke productie-workloads; interfaces kunnen vaak veranderen zonder backward compatibility; kan op elk moment worden gedropt.
  • Beta: Interfaces (API, configuratie) worden zoveel mogelijk als stabiel behandeld; bedoeld voor breder gebruik na een Alpha-fase.
  • Release Candidate: Feature-complete en klaar voor bredere inzet; breaking changes zijn alleen toegestaan onder speciale omstandigheden met voorafgaande kennisgeving.
  • Stable: Klaar voor algemene beschikbaarheid (GA).
  • Deprecated: Ontwikkeling is gestopt; nieuwe versies zijn niet gepland; wordt na een bepaalde periode verwijderd.
  • Unmaintained: Geen actieve code-owner; zoekt naar nieuwe contributors.

Daarnaast is het misleidend om te suggereren dat Go en Ruby volgens dezelfde standaard worden onderhouden. Het pretenderen van pariteit creëert verwarring en wrok wanneer een gebruiker een ervaring verwacht die er niet is. Eerlijk zijn over onderhoudsniveaus zou mensen in staat stellen geïnformeerde keuzes te maken en zou meer hulp kunnen aantrekken voor de zwakkere tiers.

Ten slotte moet OpenTelemetry het probleem van het tekort aan maintainers openlijker communiceren. De community is zich waarschijnlijk niet bewust van de behoefte aan meer actieve, idealiter onafhankelijke maintainers.

OpenTelemetry is een geweldig project dat heroïsch werk verricht op deze schaal met zo weinig mensen. Maar om leveranciersspecifieke SDK's echt te kunnen vervangen, moeten we pragmatischer worden over wat realistisch is qua stabiliteitscontracten en het aantal ondersteunde talen. Breaking changes zijn niet zo rampzalig voor de community als deze beloften suggereren, mits ze goed worden gecommuniceerd. Met een zo dunne bezetting aan maintainers, moet er ergens iets wijken.