Observabilité avec OpenTelemetry : instrumenter ce qui sert vraiment au diagnostic

Instrumenter une application est devenu simple : les bibliothèques actuelles produisent des traces, des métriques et des journaux avec quelques lignes de configuration. Le vrai travail commence après, quand il faut répondre à une question de diagnostic en moins de dix minutes.

Partir des questions, pas des composants

Nous commençons chaque intervention par une liste de questions concrètes posées par les équipes d'exploitation et de développement. Une observabilité réussie répond à quelques dizaines de questions précises, pas à toutes les questions imaginables.

• Quel service a produit l'erreur visible par l'utilisateur sur ce parcours ?
• Combien de temps a duré l'appel au système partenaire, et a-t-il été réessayé ?
• Quelle version applicative était déployée lorsque le ralentissement a commencé ?
• Quelle requête SQL concentre le temps de traitement sur cet écran ?
• Le message a-t-il été traité une seule fois, ou rejoué après incident ?

Le choix des attributs décide de l'utilité

Une trace sans attribut métier indique qu'une requête a échoué, jamais pourquoi. Nous ajoutons systématiquement des attributs à faible cardinalité, comme l'identifiant du parcours ou le type d'opération, et des attributs techniques limités, comme la version applicative et la région.

Les données personnelles restent exclues des attributs : identifiants clients, adresses et contenus de message ne doivent jamais apparaître dans une trace, un journal ou un nom de métrique.

@Service
class PaymentInstrumentation {

    private final ObservationRegistry registry;
    private final PaymentGateway gateway;

    PaymentInstrumentation(ObservationRegistry registry, PaymentGateway gateway) {
        this.registry = registry;
        this.gateway = gateway;
    }

    PaymentResult process(PaymentCommand command) {
        return Observation.createNotStarted("payment.process", registry)
                .lowCardinalityKeyValue("payment.method", command.method().name())
                .lowCardinalityKeyValue("app.version", Version.current())
                .observe(() -> {
                    Span.current().setAttribute("payment.amount.bucket", Buckets.of(command.amount()));
                    return gateway.authorize(command);
                });
    }
}

Le regroupement des montants en tranches plutôt qu'en valeur exacte est délibéré : un attribut à cardinalité élevée multiplie le coût de stockage et dégrade la lisibilité des agrégations.

Propagation du contexte et journaux corrélés

La propagation du contexte à travers les appels HTTP, les messages et les traitements asynchrones est ce qui distingue un système observable d'une collection de traces isolées. Nous vérifions cette propagation sur les chemins les plus complexes : appels sortants, consommateurs de messages et tâches planifiées.

Des alertes rattachées à des objectifs

Nous définissons un petit nombre d'objectifs de service par parcours critique, puis une alerte par objectif. Toute alerte sans action attendue est soit supprimée, soit transformée en indicateur consultable. Cette discipline est la seule façon de faire baisser durablement le bruit.

Une trace sans attribut métier raconte qu'une requête a échoué, jamais pourquoi.

Maîtriser le coût de stockage

Le coût de l'observabilité augmente par paliers invisibles : plus de services, plus d'attributs, plus de rétention. Nous suivons trois leviers : le taux d'échantillonnage par type de parcours, la rétention des traces par rapport aux journaux, et l'indexation des attributs de recherche. Une réduction du volume de trente à quarante pour cent est fréquente sans perte de capacité de diagnostic, à condition d'accepter de ne pas échantillonner les erreurs.

Ce qu'il faut retenir

L'observabilité utile se construit autour de questions de diagnostic et d'attributs choisis, pas autour d'un outil. Instrumentez les parcours critiques, excluez toute donnée personnelle, rattachez chaque alerte à un objectif, et surveillez le coût comme n'importe quelle ressource d'infrastructure.