Le tableau de bord est vert, et pourtant les clients se plaignent que le paiement ne fonctionne pas. Si vous avez occupé ce poste, vous comprenez déjà la différence entre surveillance et observabilité. Votre surveillance n’a vérifié que ce que vous pensiez vérifier, et cet échec est quelque chose de nouveau.

Ce guide explique les deux idées sans le langage marketing et suit un incident fictif depuis l’alerte jusqu’à la cause profonde. Les journaux, traces et chiffres sont inventés pour illustrer le processus. Vous devez également savoir que les vendeurs et les praticiens tracent cette ligne différemment, et certains considèrent qu’il s’agit en partie d’une distinction marketing. Nous nous concentrons sur la partie pratique.

La réponse courte

La surveillance est une activité. Vous décidez à l’avance ce que vous souhaitez surveiller, comme le processeur, le taux d’erreur ou l’espace disque, et vous définissez des seuils qui déclenchent des alertes. Il répond : « Est-ce que la chose dont je m’inquiétais se produit ?

L’observabilité est une propriété de votre système. Le terme vient de la théorie du contrôle, où il décrit dans quelle mesure vous pouvez déduire l’état interne d’un système à partir de ses sorties externes. En pratique, il répond : « Que se passe-t-il et pourquoi, y compris pour des problèmes que je n’avais jamais anticipés ?

Pensez à une voiture. Les voyants du tableau de bord surveillent. Ils couvrent un ensemble de problèmes connus. Le port de diagnostic complet d’un mécanicien, qui permet à quelqu’un de poser de nouvelles questions sur n’importe quelle partie du moteur, est plus proche de l’observabilité.

Surveillance et observabilité côte à côte

Ce n’est pas un choix entre les deux. Vous avez toujours besoin d’alertes pour vous indiquer quand chercher.

Pourquoi la surveillance seule ne suffit pas

Avec une seule application sur un serveur, la liste des problèmes pouvant survenir est assez courte, vous pouvez donc toutes les regarder. Un système moderne peut comporter des dizaines de services, de files d’attente et d’API tierces, ainsi que des conteneurs qui vont et viennent. Les échecs deviennent des combinaisons que personne n’avait prédit : une région, un type de client, une version d’application spécifique et une seule dépendance lente.

Vous ne pouvez pas rédiger à l’avance un tableau de bord pour une question à laquelle vous n’avez pas pensé. Vous avez besoin de données qui vous permettent de les poser par la suite.

Journaux, métriques et traces

Ces trois types de télémétrie sont souvent appelés les piliers de l’observabilité. Chacun répond à une question différente :

Métriques

http_requests_total{service="checkout", status="500"} 1832
http_request_duration_seconds{service="checkout", quantile="0.95"} 2.4

Les métriques sont peu coûteuses à stocker et rapides à interroger, ce qui les rend idéales pour les tableaux de bord et les alertes. Méfiez-vous des étiquettes à cardinalité élevée, comme un identifiant utilisateur, dans de nombreux systèmes métriques, car elles peuvent augmenter considérablement les coûts.

Traces

Une trace suit une requête sur tous les services. Chaque étape est un span avec une heure de début et une durée :

POST /checkout                      2410 ms
├─ auth-service: verify token         18 ms
├─ cart-service: load cart            42 ms
├─ pricing-service: calculate       2290 ms   <-- slow
│  └─ SELECT coupons ...            2265 ms
└─ payment-service: not reached

Une trace rend évidente une étape lente, ce qui est très difficile à voir dans des journaux distincts provenant de services distincts.

Journaux

Les journaux fournissent le détail de ce qui s’est passé à un moment donné. Nous verrons comment les rendre utiles dans un instant.

Présentation d’un incident

Voici comment les pièces s’assemblent, dans un exemple fictif.

La surveillance a géré l’étape 1. Tout ce qui a suivi était l’observabilité. Notez comment chaque question découle de la réponse précédente. Personne n’aurait pu créer à l’avance un tableau de bord pour « la requête de coupon d’application mobile de la campagne d’aujourd’hui ». Pour le correctif lui-même, notre guide sur l’optimisation des requêtes SQL montre comment lire ce type de plan.

De meilleurs journaux

Les journaux en texte brut sont conçus pour les yeux humains et difficiles à interroger. Les Journaux structurés utilisent des champs sur lesquels une machine peut filtrer :

# Hard to search
ERROR Payment failed for user 42 after 3 tries

# Easy to search
{"level":"error","event":"payment_failed","user_id":"42",
 "attempts":3,"provider":"acme","trace_id":"a1b2c3","duration_ms":2410}

Avec le deuxième formulaire, vous pouvez immédiatement demander « combien de pannes par fournisseur au cours de la dernière heure ? » Le champ trace_id est particulièrement précieux, car il relie une ligne de journal à l’ensemble de la requête, pour chaque service touché.

N’enregistrez jamais de mots de passe, de jetons ou de numéros de carte et faites attention aux données personnelles. Comme l’explique notre guide, les JWT peuvent être réutilisés par toute personne qui les lit à partir d’un journal.

Les signaux d’or

Vous ne savez pas quoi surveiller ? Le livre Site Reliability Engineering de Google suggère quatre signaux pour les systèmes destinés aux utilisateurs :

Utilisez des percentiles pour la latence, car les moyennes masquent les requêtes lentes, comme nous l’avons montré dans tests de charge vs tests de stress.

Alerte les gens en qui ils ont confiance

Si les alertes se déclenchent en permanence, les gens arrêtent de les lire. Les bons suivent quelques règles :

• Alerte sur les symptômes ressentis par les utilisateurs. « Erreurs de paiement supérieures à 2 % » bat « CPU à 85 % ». Un processeur élevé qui ne nuit à personne ne devrait réveiller personne.
• Rendez chaque alerte exploitable. Si personne n’a besoin de faire quoi que ce soit, faites-en un élément du tableau de bord ou supprimez-le.
• Lien vers un runbook. Dites au répondeur où chercher et quoi essayer.
• Examinez-les régulièrement. Supprimez ou corrigez toute alerte qui a été ignorée le mois dernier.

Objectifs de niveau de service

Un SLO transforme « le site doit être rapide et fiable » en un objectif mesurable, comme « 99,9 % des demandes de paiement aboutissent sur 30 jours ». Cela permet d’éviter environ 0,1 % d’échecs, ce que l’on appelle un budget d’erreur. S’il vous en reste suffisamment, vous pouvez expédier plus rapidement, et s’il est presque épuisé, vous pouvez donner la priorité à la fiabilité. C’est un moyen utile de régler les différends entre rapidité de livraison et stabilité.

OpenTelemetry et outils

OpenTelemetry est une norme open source et indépendante du fournisseur pour générer et exporter des données de télémétrie. Il s’agit d’un projet de la Cloud Native Computing Foundation. Instrumenter avec cela signifie que vous pouvez modifier votre backend plus tard sans réécrire votre code. Il ne s’agit pas d’un produit de stockage ou de tableau de bord en soi, vous l’associez donc à un :

Vérifiez vous-même les fonctionnalités et les tarifs actuels, car ces produits changent souvent. Les coûts peuvent augmenter rapidement avec le volume de données, utilisez donc l’échantillonnage et définissez des limites de conservation.

Comment commencer

1. Commencez par les signaux en or pour votre service le plus important.
2. Ajoutez une ou deux alertes sur les symptômes remarqués par les utilisateurs.
3. Passez aux journaux structurés avec un ID de demande dans chaque ligne.
4. Ajoutez le traçage à votre parcours utilisateur principal avec OpenTelemetry, car l’auto-instrumentation peut couvrir de nombreux frameworks courants.
5. Liez les déploiements à vos graphiques afin que vous puissiez voir si une version de votre pipeline CI/CD a provoqué un changement.
6. Apprenez de chaque incident. Après chacun d’entre eux, demandez quelles données auraient permis une résolution plus rapide et ajoutez-les.

Une petite équipe avec un seul service n’a pas besoin d’une immense plateforme. Des mesures de base, de bons journaux et quelques alertes peuvent suffire. Le traçage gagne sa place à mesure que le nombre de services augmente.

Erreurs courantes

• Acheter un outil et l’appeler observabilité. La valeur vient d’une bonne instrumentation et de la façon dont vous utilisez les données.
• Traiter trois piliers comme une liste de contrôle. Séparer les données sans aucun moyen de les relier vous oblige à parcourir les onglets. Les identifiants partagés sont importants.
• Tout collecter. La télémétrie non filtrée coûte cher et ajoute du bruit.
• Trop de tableaux de bord. Quelques vues fiables dépassent une centaine que personne n’ouvre.
• Je pense que cela remplace les tests. Vous avez toujours besoin de tests avant la sortie. Cependant, les versions Canary se marient bien avec ces signaux.

Pour conclure

La surveillance vous indique que quelque chose s’est mal passé et l’observabilité vous donne les moyens de découvrir pourquoi. Le test pratique est simple : lorsqu’un problème inconnu apparaît, pouvez-vous en trouver la cause sans envoyer de nouveau code ? La prochaine fois que vous serez confronté à un incident, notez toutes les questions auxquelles vous n’avez pas pu répondre. Cette liste est votre feuille de route.

Questions fréquentes

Continuez à apprendre