Observabilité27 juillet 2026

Observabilité : relier les signaux techniques à une astreinte utile

Partir du parcours utilisateur, définir des SLI et SLO, puis déclencher des alertes qui appellent une action humaine claire.

Accumuler logs, métriques et traces ne garantit pas que l'équipe comprendra le prochain incident. L'observabilité devient utile lorsque les signaux répondent à deux questions : les utilisateurs rencontrent-ils un problème, et qui peut agir maintenant ?

OpenTelemetry décrit plusieurs signaux, notamment traces, métriques et logs. Ils montrent le chemin d'une requête, une mesure dans le temps et un événement détaillé. Sans identité de service ni conventions communes, leur collecte crée un nouveau silo.

Partir d'un parcours utilisateur

Choisissez un parcours important : connexion, paiement, synchronisation mobile ou traitement d'un fichier. Décrivez le résultat réussi, puis définissez un SLI : requêtes réussies, latence sous une limite ou fraîcheur d'une donnée.

Le SLO fixe l'objectif du SLI sur une fenêtre. Le chapitre Implementing SLOs recommande que métiers, développeurs et responsables de production s'accordent sur l'objectif et la politique de budget d'erreur. Copier un taux depuis un autre service ne dit pas ce que vos utilisateurs attendent.

Instrumenter le chemin critique

Propagez le contexte entre les appels et corrélez traces et logs. Commencez par les frontières : requête entrante, dépendance, base de données, file et résultat métier. L'instrumentation zero-code d'OpenTelemetry accélère le départ sur plusieurs runtimes, mais les étapes métier demandent souvent du code explicite.

Contrôlez les attributs avant export. Un identifiant de trace aide ; une donnée personnelle ou un secret n'a rien à faire dans la télémétrie. Adaptez rétention et échantillonnage au besoin de diagnostic et au coût.

Ne pager que pour agir

Le chapitre Google SRE sur la surveillance des systèmes distribués distingue ce qui doit interrompre une personne de ce qui peut attendre. Une page doit correspondre à un impact réel ou imminent et mener à une action connue.

Chaque alerte devrait nommer service, symptôme, SLO, changements récents et premier diagnostic. Si personne ne peut agir, transformez-la en ticket ou en tableau de bord. Analysez les alertes acquittées sans action : elles fatiguent l'équipe sans protéger le service.

Commencez avec un parcours, un SLI, un SLO, une politique et une alerte. Vérifiez les incidents manqués, faux positifs et diagnostics. L'objectif n'est pas de tout voir, mais de détecter ce qui compte et d'aider l'astreinte à agir.

Sources officielles

Partager cet article

Lire aussi