OpenTelemetry : la mise en production commence avec le traçage

Clément Bohic,
OpenTelemetry production

Depuis quelques semaines, le cœur fonctionnel d’OpenTelemetry est considéré comme stable pour un usage en prod sur la partie traçage. Que reste-t-il à accomplir ?

Le saviez-vous ? La spécification OpenTelemetry est passée en version 1.0. C’était il y a près de trois mois… mais Google vient d’adresser un rappel.

Le groupe américain est l’un des principaux contributeurs actuels de ce projet qui vise à développer un standard ouvert pour la collecte et l’exportation des données de télémétrie. Il en est aussi un contributeur « historique », en tant que créateur d’OpenCensus, dont la fusion avec OpenTracing avait engendré OpenTelemetry.

Le passage de la spécification en v1 ne signifie pas que tous les éléments du projet sont stables. Une seule de ses briques fondamentales l’est en l’occurrence : le tracing. Pour qui utilisera l’API et le SDK, c’est la garantie d’une compatibilité avec toutes les versions mineures ultérieures. Ainsi que d’une durée minimale de support (pour l’API, au moins trois ans après la publication de la version majeure suivante ; pour le SDK, au moins un an).

La stabilité n’est pas encore effective avec l’ensemble des langages que supporte OpenTelemetry. Python et .NET font partie de ceux qui ont franchi le cap – tous deux en mars. On en reste au stade RC pour Java, Erlang, Go ou Node.js.

Les métriques pour novembre, les logs pour 2022

Dans la nomenclature du projet, on parle de « signaux » pour désigner les différentes catégories du « triptyque » de la télémétrie : traces, métriques et logs. Sur la partie métriques, le stabilité est prévue pour le 2e semestre 2021 (la date du 30 novembre figure sur la roadmap). Pour les logs, il faudra probablement attendre 2022.

OpenTelemetry architecture référence
l'architecture de référence d'OpenTelemetry

S'ils ont chacun leur cycle de vie, ces signaux s'appuient sur le même mécanisme de propagation. La collecte repose sur un outil unique déployable soit en tant qu'agent (au niveau de l'application ou de l'hôte), soit en tant que passerelle (cluster, datacenter, région).

Dans tous les cas, OpenTelemetry ne fait pas office de back-end : il y achemine les données, en exploitant des formats standard de type Jaeger et Prometheus. Aussi les fournisseurs d'outils de monitoring sont-ils nombreux à s'impliquer dans le projet.
Les dernières réunions du SIG « Spécifications » donnent une idée des forces en présence. Datadog, Dynatrace et New Relic, tous trois « leaders » dans le dernier Magic Quadrant de l'APM, sont par exemple de la partie. Au rang des participants réguliers figurent aussi les « trois grands » du cloud. On aura relevé des contributions plus périodiques de la part de Criteo, F5, Red Hat, Zalando ou encore Elastic. Ce dernier propose sa propre distribution d'OpenTelemetry. Comme AWS, Lightstep, New Relic, Splunk et Sumo Logic. Du côté de Google, on entend fournir une implémentation entre autres dans le cadre de l'offre Cloud SQL Insights.

Illustration principale © Cisco