Résumé

  • Dans leur texte de mai 2019, les fondateurs expliquaient que la coexistence de deux projets d’instrumentation presque compatibles constituait le problème principal. Ils voulaient des passerelles vers OpenTelemetry et prévoyaient de placer les anciens projets en lecture seule avant fin 2019.
  • L’annonce d’OpenTelemetry de mai 2023 fixait au 31 juillet l’archivage prévu de la plupart des dépôts OpenCensus, après une parité déclarée dans sept langages. Le dépôt opencensus-python restait une exception explicite.

Deux projets, une facture d’intégration

Pour voir ce qui se passe dans un service distribué, il faut que ses composants produisent des traces, des mesures et des journaux exploitables. Une partie de ce travail appartient aux équipes applicatives; une autre dépend des bibliothèques qu’elles utilisent. OpenTracing et OpenCensus cherchaient chacun à éviter que tout le monde réécrive les mêmes branchements. Leurs choix techniques différaient, mais leurs publics se recouvraient assez pour partager la même ressource rare : le temps des mainteneurs.

Le récit publié en 2019 par Ben Sigelman et Morgan McLean ne dissimulait pas l’embarras. Le plus gros problème des deux initiatives était précisément leur nombre. Devait-on instrumenter une bibliothèque pour l’une, pour l’autre, ou attendre? Un exploitant ne décide pas seul de l’API employée dans chaque dépendance. Deux projets voisins pouvaient donc laisser un service avec deux circuits de mesure qui se rejoignaient mal au moment du diagnostic.

La fusion de mai 2019 a donné aux contributions futures une destination commune, dans le bac à sable de la CNCF. Des représentants de Google, LightStep, Microsoft et Uber figuraient dans les premiers comités. Cette composition établissait un lieu de décision; elle ne mettait pas à jour les applications. Les fondateurs présentaient OpenTelemetry comme la prochaine version majeure d’OpenTracing et d’OpenCensus. Ils reconnaissaient ainsi que les deux héritages avaient des utilisateurs, des bibliothèques et des chemins de sortie différents.

La passerelle figurait dans le contrat initial

La compatibilité avec les deux prédécesseurs, par des passerelles logicielles, était une priorité annoncée dès le départ. Une passerelle permet de conserver temporairement une instrumentation ancienne tout en déplaçant la collecte et l’exportation vers le nouveau projet. Les responsables voulaient aussi raccourcir la période pendant laquelle trois projets seraient développés en parallèle. Leur objectif était la lecture seule pour OpenTracing et OpenCensus avant la fin de 2019. C’était un calendrier de projet, pas une preuve que toute application avait migré cette année-là.

Le code source peut cesser d’évoluer alors que des services continuent de le charger chaque matin. Entre les deux, il faut des versions publiées, des adaptations de bibliothèques, des tests de données et des déploiements. Les passerelles prouvent que les auteurs du projet connaissaient ce décalage. Ils ne demandaient pas à l’industrie de couper simultanément tous les câbles un vendredi soir.

En août 2021, la CNCF a annoncé l’entrée d’OpenTelemetry en incubation. Elle décrivait alors des API et SDK dans onze langages ainsi que la prise en charge des traces et mesures par son protocole. Elle indiquait aussi qu’OpenTracing devait être officiellement archivé et que les deux anciens projets seraient davantage dépréciés. Deux ans après l’accord, la sortie faisait encore partie du travail annoncé.

Le plan de 2023 avait une ligne d’exception

L’avis publié par OpenTelemetry en mai 2023 apportait des éléments concrets. Le projet déclarait avoir atteint la parité fonctionnelle avec OpenCensus en C++, .NET, Go, Java, JavaScript, PHP et Python. Il prévoyait d’archiver la plupart des dépôts GitHub d’OpenCensus le 31 juillet. Pas tous : opencensus-python contenait encore des composants recommandés pour un usage en production. Cette exception tient davantage du registre d’exploitation que du schéma de fusion bien net dessiné quatre ans plus tôt.

Le même avis détaillait des passerelles pour Go, Java, JavaScript et Python, tout en signalant que certains adaptateurs n’étaient pas encore publiés. Elles devaient permettre à l’instrumentation ancienne de transmettre ses données aux exportateurs OpenTelemetry, puis aux équipes de retirer progressivement les bibliothèques OpenCensus. Le projet précisait qu’il ne constituait pas un surensemble strict : une migration pouvait modifier les données de télémétrie. Une trace qui arrive encore n’a pas forcément le même contenu.

La date d’archivage avait une conséquence précise. Après le 31 juillet, annonçait le projet, les dépôts archivés ne recevraient plus de fonctions nouvelles ni de correctifs de sécurité; leur code et leurs paquets resteraient accessibles. L’application pouvait donc continuer de tourner avec un composant dont l’entretien collectif s’arrêtait. Il fallait connaître ce composant, la passerelle qui le remplaçait et l’exception qui empêchait une sortie uniforme.

Les comités fusionnent avant les services

L’accord de 2019 a réduit une concurrence qui dispersait l’instrumentation commune. Il a orienté les contributions futures vers une seule organisation. Mais un système déjà déployé obéit aux versions de ses dépendances et aux calendriers de ses mainteneurs. Les quatre années qui séparent l’annonce de la fusion du plan de retrait d’OpenCensus mesurent cette distance. Elles ne démontrent pas à elles seules que l’objectif « lecture seule » de 2019 a échoué : lecture seule et archivage sont deux étapes distinctes. Elles montrent qu’en 2023 le départ exigeait encore un inventaire, des ponts et une exception.

Le nom sur la porte avait changé; les câbles traversaient toujours l’ancien atelier.