Monitoring ou observabilité ?
Résumé : ces deux mots sont utilisés comme synonymes, à tort. Le monitoring surveille des indicateurs décidés à l'avance — il répond aux questions que vous saviez devoir poser. L'observabilité permet d'investiguer des situations jamais anticipées. Cette leçon clarifie la distinction, explique l'origine du terme, introduit la notion cruciale de cardinalité, et retrace l'histoire depuis 1999.
1. Les deux définitions
La formule la plus utile pour retenir : le monitoring répond à « mon système fonctionne-t-il comme prévu ? ». L'observabilité répond à « pourquoi se comporte-t-il de cette façon que je n'avais pas prévue ? ».
Précision essentielle : l'observabilité ne remplace pas le monitoring, elle l'englobe. Vous avez besoin des deux — d'alertes sur les problèmes connus, et de la capacité à investiguer l'inédit.
2. Un exemple concret qui tranche
C'est l'exemple canonique du domaine : un problème réel, invisible sur tous les tableaux de bord classiques, parce qu'il n'affecte qu'un sous-ensemble précis d'utilisateurs. Le monitoring agrège, et l'agrégation cache les minorités.
3. L'origine du terme — la théorie du contrôle
Le mot observabilité n'a pas été inventé par l'industrie du logiciel. Il vient de l'ingénierie des systèmes.
Le test de la boîte O4 est le meilleur outil d'évaluation qui existe. Posez-vous la question : « la dernière fois qu'un problème inédit est survenu, ai-je dû ajouter des logs et redéployer ? ». Si la réponse est oui — et c'est le cas dans la plupart des équipes — vous faites du monitoring, pas de l'observabilité.
4. La cardinalité — la notion technique clé
C'est le concept qui explique techniquement pourquoi le monitoring classique ne peut pas répondre à certaines questions.
L'erreur pratique la plus coûteuse en observabilité : ajouter une étiquette user_id à une métrique Prometheus. Avec 500 000 utilisateurs, vous créez 500 000 séries temporelles pour une seule métrique, et vous faites tomber votre serveur de supervision. C'est une panne classique, et elle survient généralement en production, pas en test.
La bonne pratique : les identifiants uniques vont dans les traces et les logs structurés, jamais dans les étiquettes de métriques.
5. Petite histoire — de Nagios à OpenTelemetry
Pourquoi ce changement était inévitable : Nagios répondait très bien à la question « ce serveur est-il en vie ? ». Mais dans une architecture où une requête traverse quinze services, tous les serveurs peuvent être « en vie » alors que le service utilisateur est cassé. Le changement d'échelle a imposé un changement d'approche.
Le nom à connaître : OpenTelemetry. C'est aujourd'hui le standard d'instrumentation, projet CNCF, et il apparaît de plus en plus dans les offres d'emploi. Son intérêt majeur : vous instrumentez une fois, et vous pouvez changer d'outil de visualisation sans réécrire votre code.
6. Le tableau comparatif
| Critère | Monitoring | Observabilité |
|---|---|---|
| Question traitée | Est-ce que ça fonctionne ? | Pourquoi ça se comporte ainsi ? |
| Type de problème | Connu, déjà rencontré | Inédit, jamais anticipé |
| Approche | Tableaux de bord et seuils prédéfinis | Exploration libre des données |
| Cardinalité supportée | Faible | Élevée |
| Sortie principale | Alertes | Investigation |
| Coût de stockage | Modéré | Plus élevé |
| Adapté à | Systèmes stables et bien connus | Systèmes distribués complexes |
| Outil typique | Prometheus, Zabbix, Nagios | Traçage, logs structurés, Honeycomb |
Lecture pratique de ce tableau : vous n'avez pas à choisir. Commencez par le monitoring — des alertes sur quelques indicateurs clés apportent une valeur immédiate. Ajoutez l'observabilité quand votre système devient distribué et que les problèmes deviennent difficiles à reproduire.
7. Comment savoir où vous en êtes
Conseil de progression : ne cherchez pas à sauter au niveau 5. Le niveau 2 apporte l'essentiel du bénéfice pour un effort modeste — mesurer le taux d'erreur et la latence de vos points d'entrée, et alerter dessus. Beaucoup d'équipes installent un système de traçage sophistiqué avant d'avoir une simple alerte sur leur taux d'erreur.
Retenir en 30 secondes
- Monitoring = surveiller des indicateurs prévus d'avance. Couvre les problèmes connus.
- Observabilité = comprendre l'état interne à partir de ce que le système émet, y compris pour des questions inédites.
- L'observabilité ne remplace pas le monitoring, elle l'englobe. Vous avez besoin des deux.
- Le test décisif : face à un problème nouveau, devez-vous ajouter des logs et redéployer ? Si oui, votre système n'est pas observable.
- Le terme vient de Rudolf Kálmán (1960) et de la théorie du contrôle.
- Cardinalité : ne mettez jamais un identifiant utilisateur dans une étiquette de métrique — vous ferez tomber votre serveur.
- Les identifiants uniques vont dans les traces et les logs structurés.
- Histoire : Nagios (1999) → Prometheus (2012) → traçage distribué (2015) → OpenTelemetry (2019).
- OpenTelemetry est le standard d'instrumentation à connaître : instrumentez une fois, changez d'outil librement.
- Visez d'abord le niveau 2 : taux d'erreur et latence de vos points d'entrée. C'est là qu'est l'essentiel du gain.