Présentation

L’article OTel‑Native by Design expose la philosophie selon laquelle chaque composant logiciel doit publier ses traces, métriques et logs au format OpenTelemetry (OTel). En adoptant le protocole OTLP (protobuf sur gRPC ou HTTP) et les conventions sémantiques définies par la communauté, un produit devient immédiatement compatible avec n’importe quel backend d’observabilité : Jaeger, Prometheus, Grafana Cloud, Elastic, etc. Cette approche supprime le besoin de développer des exportateurs spécifiques à chaque destination.

Architecture OTel‑Native

Le modèle repose sur trois couches : le SDK d’instrumentation, le Collector et les exportateurs. Le SDK expose des API de traces, métriques et logs (ex. TracerProvider, MeterProvider) et encode les données selon les conventions SemConv. Le Collector, déployé en tant que processus autonome ou sidecar, reçoit les flux OTLP, applique des pipelines de traitement (batching, tail‑based sampling, enrichissement) puis les redirige vers plusieurs exportateurs configurés simultanément. Cette architecture permet le dual‑export : les mêmes données sont envoyées à un système de stockage à long terme et à un outil d’analyse en temps réel.

Implémentation concrète

Un exemple typique en Go montre la création d’un tracer et la configuration d’un exporter OTLP :

import (
    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/sdk/trace"
    "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
)

func initTracer() {
    exp, _ := otlptracegrpc.New(context.Background(), otlptracegrpc.WithEndpoint("otel-collector:4317"))
    tp := trace.NewTracerProvider(trace.WithBatcher(exp))
    otel.SetTracerProvider(tp)
}

Le même code fonctionne avec les SDK Java, Python ou .NET, la seule différence réside dans le package importé. Le Collector, quant à lui, se configure via un fichier YAML où chaque receiver (OTLP) est relié à une chaîne de processor puis à plusieurs exporter (ex. jaeger, prometheusremotewrite). Cette configuration déclarative garantit que le produit reste « OTel‑Native » même si l’infrastructure sous‑jacente évolue.

Impacts, limites et bonnes pratiques

Le principal avantage est la portabilité : un même binaire peut être déployé dans des environnements cloud, on‑prem ou edge sans modification du code d’instrumentation. Cependant, la dépendance au Collector introduit une latence supplémentaire due au traitement en pipeline, surtout lorsqu’on active le batch et le retry. De plus, la cardinalité des attributs doit être maîtrisée ; des dimensions trop nombreuses peuvent saturer les backends et augmenter les coûts de stockage. Enfin, la migration d’applications legacy nécessite souvent un wrapper ou un agent d’instrumentation (ex. l’agent Java 3.0) pour injecter les appels OTel sans toucher au code source.