L’observabilité peut ressembler à un projet d’ingénierie de plateforme, mais les petites applications en ont besoin aussi. La différence, c’est l’ampleur. Une petite application n’a pas besoin d’un programme de télémétrie gigantesque dès le premier jour. Elle a besoin d’une visibilité suffisante pour répondre rapidement à trois questions.
- L’application fonctionne-t-elle ?
- Si non, où échoue-t-elle ?
- Qui est affecté ?
Commencez par des logs structurés
Les logs en texte brut sont utiles jusqu’à ce que vous ayez besoin d’y effectuer des recherches sous pression. Les logs structurés facilitent la compréhension des incidents, car chaque ligne porte un contexte cohérent.
{
"level": "info",
"event": "checkout_completed",
"request_id": "req_4815",
"user_id": "usr_204",
"duration_ms": 184
}
Au minimum, incluez :
- Horodatage
- Niveau de log
- Nom de l’événement
- ID de requête
- ID d’utilisateur ou de compte lorsque c’est pertinent
- Durée pour les opérations importantes
Ajoutez des métriques alignées sur l’expérience utilisateur
Les métriques doivent décrire la santé des parcours orientés utilisateur, et non pas seulement les rouages internes du serveur.
| Parcours | Métrique utile | Alerter quand |
|---|---|---|
| Connexion | Taux de réussite des connexions | Passe sous la plage normale |
| Recherche | Temps de réponse P95 | Dépasse le seuil convenu |
| Paiement | Nombre de paiements échoués | Pics au-dessus de la référence |
| Tâches en arrière-plan | Âge de la file | La plus ancienne tâche continue de vieillir |
Le CPU et la mémoire comptent, mais ce sont rarement les premières métriques qu’un client ressent.
Tracez les chemins lents
Le traçage distribué est le plus précieux lorsqu’une requête franchit des frontières : serveur web, base de données, cache, passerelle de paiement, fournisseur de messagerie. Même une petite application peut tirer parti du traçage des quelques chemins qui comptent le plus.
Bons candidats :
- Création de compte
- Paiement
- Recherche
- Génération de rapports
- Traitement des webhooks
Tracez tout plus tard si l’application grandit. Tracez dès maintenant les chemins coûteux et fragiles.
Définissez un mini-runbook
Une alerte sans action suivante crée de l’anxiété. Chaque alerte doit répondre à :
- Que signifie cette alerte ?
- Quel tableau de bord dois-je ouvrir en premier ?
- Quels logs dois-je rechercher ?
- Qui est responsable du service ?
- Quel impact utilisateur est probable ?
Le runbook n’a pas besoin d’être parfait. Il doit simplement exister avant que l’alerte ne se déclenche à minuit.
Gardez la pile ennuyeuse
Une pile d’observabilité bien dimensionnée pourrait être :
- Des logs d’application envoyés vers un service consultable
- Des vérifications de disponibilité de base pour les points de terminaison publics
- Des métriques pour les cinq principaux parcours
- Le suivi des erreurs avec des étiquettes de version
- Le traçage pour deux ou trois chemins critiques
C’est suffisant pour rendre les petites applications bien moins mystérieuses.
Conclusion
L’observabilité ne consiste pas à collecter tous les signaux possibles. Il s’agit de collecter les signaux qui aident une équipe à protéger les utilisateurs, à déboguer plus vite et à comprendre comment le système se comporte dans le monde réel.
Comments