Izstrādātājs Mets Dagans 12. augustā publicēja tabulu ar OpenTelemetry valodu bibliotēku apvienošanas statistiku par pēdējiem 24 mēnešiem. C++ bibliotēkā šajā laikā apvienoti 544 izmaiņu pieprasījumi. To izdarīja četri cilvēki. 86,1 % pieprasījumu apvienoja viens un tas pats cilvēks. Kotlin bibliotēkā 281 pieprasījumu apvienoja divi cilvēki, no tiem 79,7 % viens. Ruby bibliotēkā 213 pieprasījumus apvienoja pieci cilvēki, aktīvākajam 78,7 %.
OpenTelemetry statusa lapa tajā pašā brīdī C++ bibliotēkai rāda statusu stable visiem trim signāliem: pēdām, metrikām un žurnāliem. Tāds pats statuss ir PHP bibliotēkai, kurai divos gados apvienošanas tiesības izmantoja divi cilvēki. Statuss stable projektā nozīmē saskarnes garantiju. Kad funkcija tur nokļūst, to vairs nevar mainīt.
OpenTelemetry ir CNCF projekts, kas apvieno pēdu, metriku un žurnālu vākšanu vienā protokolā, lai lietotnes instrumentāciju nesaistītu ar konkrētu novērojamības pārdevēju. Instrumentāciju raksta vienreiz, datus sūta uz OTLP, tālāk tos var novirzīt uz Datadog, Grafana vai pašmitinātu Jaeger. Tāpēc tas, cik veselīga ir bibliotēka konkrētajā valodā, izlemj, vai šis solījums attiecīgajā projektā vispār strādā.
Kā izskatās bibliotēkas, kur slodze ir sadalīta
Dagana tabulā ir arī valodas bez šādas koncentrācijas. Go bibliotēkā 686 pieprasījumus apvienoja pieci cilvēki, aktīvākajam 36,9 %. .NET bibliotēkā 657 pieprasījumus apvienoja seši cilvēki, aktīvākajam 31,5 %. Salīdzinājumam viņš paņēma divus citus CNCF projektus. Prometheus 1849 pieprasījumus apvienoja 31 cilvēks, aktīvākajam 14,4 %. Envoy 5432 pieprasījumus apvienoja 28 cilvēki, aktīvākajam 35,8 %.
Starpība nav tikai procentos. Prometheus un Envoy ir attiecīgi 31 un 28 cilvēki ar tiesībām apvienot kodu. OpenTelemetry Kotlin bibliotēkai to ir divi, PHP bibliotēkai divi.
Trīs spēki, kas viens otru bloķē
Dagans sāka ar pieņēmumu, ka runa ir par parasto atvērtā koda problēmu: pārāk liela iecere pret pārāk mazu komandu. Skaitļi viņu noveda pie cita skaidrojuma. Projektam vienlaikus ir stingra saskarņu stabilitātes garantija, tvērums pāri divpadsmit valodām un plāns uzturētāju sols. Šie trīs faktori kopā rada motivāciju balsot pret jaunām funkcijām. Ja apvienoto funkciju vairs nevar mainīt, drošākais lēmums uzturētājam ir to neapvienot vispār.
Dagans šo situāciju apraksta kā trīs virzienu sadursmi: stabilitātes solījums, uzturētāju trūkums un tvērums, kas aug ātrāk par abiem pārējiem.
Ceļš vienai jaunai funkcijai iet caur sešiem posmiem. Vispirms OTEP priekšlikums, tad specifikācija, tad semantiskās konvencijas, tad valodu bibliotēkas, tad instrumentācijas pakotnes un tikai beigās kolektors ar OTLP. Katrā posmā ir sava uzturētāju grupa. Ja kāda no tām sastāv no diviem cilvēkiem, tur rodas rinda.
Rinda semantiskajās konvencijās
Trīs lēnākie pieprasījumi semantisko konvenciju repozitorijā mērāmi mēnešos. Pieprasījums #2083 ar Model Context Protocol konvencijām tika atvērts 2025. gada 10. aprīlī un apvienots 2026. gada 12. janvārī. Tas ir 277 dienas, 28 komiti, 17 komentāri un 148 recenziju komentāri. Pieprasījums #2617 ar Google Compute Engine instanču etiķetēm gaidīja no 2025. gada 12. augusta līdz 2026. gada 28. aprīlim un savāca 29 komentārus. Pieprasījums #1698 mainīja atribūtu prefiksu no azure_ un az. uz azure. un gaidīja 188 dienas ar trim komentāriem.
Pēdējais gadījums ir pamācošs. Trīs komentāri sešarpus mēnešos nenozīmē strīdu par saturu. Tas nozīmē, ka pieprasījumu vienkārši neviens neskatīja.
Python bibliotēkas lēnākajiem pieprasījumiem kopīga ir viena iezīme. Tiem uzlikta etiķete, kas prasa papildu uzturētāja apstiprinājumu publiskās saskarnes izmaiņām.
Ko par to raksta lietotāji
Hacker News diskusijā par Dagana tabulu galvenā sūdzība nebija par rindu garumu. Vairāki izstrādātāji rakstīja par abstrakcijas slāņu cenu procesorā, īpaši Python un Ruby bibliotēkās. AWS Lambda lietotāji minēja OpenTelemetry slāņa ietekmi uz aukstā starta laiku. Atkārtojās arī konkrēti tehniski iebildumi. Atribūti OTLP protokolā tiek kodēti kā karšu masīvs, nevis kā karte, kas apgrūtina apstrādi. Izlases lēmums tiek pieņemts pieprasījuma sākumā, tāpēc vēlāk pamanītu anomāliju vairs nevar pacelt pilnā pēdā. Django instrumentācija piespiež ielādēt iestatījumus noteiktā starta brīdī, kas lauž lietotnes ar vairākpakāpju inicializāciju.
Daļa sūdzību attiecas uz projektēšanas izvēlēm, kur uzturētāju skaits neko nemaina. Specifikācija pēdas, metrikas un žurnālus apraksta kā trīs atsevišķus modeļus, tāpēc arī bibliotēkās tie ir trīs atsevišķi ceļi ar savu konfigurāciju. Vairāki diskusijas dalībnieki norādīja, ka kolektors praksē jāizvieto divos slāņos, gan pie pašas lietotnes, gan kā centrālā vārteja. Vienam vidēja izmēra projektam tā ir liela cena par pārdevēja neatkarību.
Daži rakstīja, ka pēc mēģinājuma izsūtīt metrikas no Python lietotnes atgriezās pie Prometheus. Neviens no OpenTelemetry uzturētājiem diskusijā neatbildēja.
Kas piedāvāts vietā
Dagans piedāvā starp experimental un stable ielikt vēl vienu pakāpi: laikā ierobežotu beta statusu ar vismaz 12 mēnešu ilgumu, pēc kura funkciju vai nu izmet, vai pārceļ uz stabilo. Otrs priekšlikums attiecas uz statusa lapu. Šobrīd vārds stable izskatās vienādi bibliotēkai ar sešiem uzturētājiem un bibliotēkai ar diviem, tāpēc lietotājs no tā neuzzina, cik ātri viņa kļūdas ziņojumu kāds izlasīs. Trešais priekšlikums ir publiski nosaukt, kurām valodām uzturētāji ir vajadzīgi.
Statusa lapa pati par sevi kļūdu neslēpj. Kotlin bibliotēkai visiem trim signāliem tur ir statuss development, Rust bibliotēkai visiem trim beta, Ruby bibliotēkai pēdas ir stabilas, bet metrikas un žurnāli paliek izstrādes stadijā. Problēma ir tur, kur koncentrācija ir augsta, bet uzraksts saka, ka viss ir gatavs.
22. augustā OpenTelemetry C++ repozitorijā bija 287 atvērtas problēmas, PHP repozitorijā 86. Abām bibliotēkām statusa lapā joprojām ir stable visiem trim signāliem.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.