Une application peut produire des millions de métriques et rester impossible à exploiter. Le support voit des clients bloqués alors que les graphes d’infrastructure sont verts ; l’astreinte reçoit des alertes de CPU sans impact et finit par ignorer le canal. Le problème n’est pas l’absence de données, mais l’absence de lien entre un signal et une décision.
Le vrai enjeu est de surveiller les promesses que l’application doit tenir : enregistrer une commande une seule fois, terminer un import avant la relève, rendre une décision visible au bon rôle ou rapprocher un paiement ambigu. Les ressources techniques servent au diagnostic ; elles ne remplacent pas le symptôme utilisateur.
Contre-intuitivement, une équipe gagne souvent en retirant des alertes. Une notification sans propriétaire, sans urgence et sans action épuise l’attention. La supprimer du canal d’appel tout en gardant sa métrique peut améliorer la détection des incidents qui exigent réellement une intervention.
Pour une application web métier exploitée dans la durée, l’observabilité doit accompagner la conception, le support et la reprise. La méthode relie promesses, seuils locaux, instrumentation et runbooks sans imposer un modèle d’astreinte universel.
Comprendre pourquoi davantage d’alertes aveugle
Le bruit vient des symptômes transitoires, des seuils copiés et des alertes redondantes. Un même ralentissement déclenche CPU, latence, timeout client et backlog. Quatre notifications ne décrivent pas quatre incidents. Sans regroupement ni causalité, elles multiplient les investigations.
La fatigue change le comportement : notifications mises en sourdine, seuils remontés sans analyse, accusés automatiques et surveillance parallèle par le métier. Le taux d’alertes sans action et le délai d’acquittement sont des signaux sur le système d’alerte lui-même.
Une alerte supprimée ne signifie pas un signal supprimé. Les données restent disponibles dans les tableaux et les diagnostics. Seul le canal interruptif est réservé à ce qui demande une action dans un délai défendable.
Commencer par les promesses métier
L’équipe choisit cinq à dix parcours dont l’échec change une opération : connexion, recherche, validation, génération, synchronisation, encaissement ou export. Pour chacun, elle décrit réussite, refus attendu, état inconnu et délai utile.
Une promesse contient une population et une fenêtre. « Les imports sont rapides » ne se mesure pas ; « l’import catalogue du matin termine avant l’ouverture du centre » peut produire un indicateur, un budget et un mode dégradé. Le chiffre découle de l’organisation locale.
Les refus fonctionnels restent visibles sans être des pannes. Une commande rejetée pour plafond dépassé est un résultat prévu ; une hausse soudaine peut néanmoins révéler une donnée ou une configuration erronée. Le signal sépare donc type et causalité présumée.
Choisir des signaux orientés décision
Un bon indicateur répond à « que risque l’utilisateur ? » et un bon diagnostic à « où chercher ? ». Taux de réussite confirmé, âge du plus ancien travail, état inconnu, durée du parcours et volume en rapprochement décrivent le service. CPU, mémoire, connexions et exceptions aident ensuite à expliquer.
Les compteurs techniques sans dénominateur sont trompeurs. Cent erreurs peuvent être critiques sur cent requêtes et invisibles sur dix millions. L’équipe conserve volume, population et période, puis segmente uniquement selon les décisions possibles.
Un indicateur métier doit venir d’un événement fiable, pas d’une chaîne de logs fragile. L’événement « commande_confirmée » est émis à la frontière de transaction appropriée ; un échec d’émission doit être traité comme un défaut de conception, pas masqué par le dashboard.
Qualifier les seuils avec une baseline locale
Le seuil commence par une distribution sur des semaines comparables : heures ouvrées, clôture, campagne ou nuit. L’équipe identifie saisonnalité, capacité normale et marge. Une valeur copiée d’un autre produit ignore volumes, délais et pratiques du support.
Si le taux de réussite descend sous une limite pendant cinq minutes, alors l’action peut être immédiate pour un parcours continu. Pour un batch quotidien, un seuil de progression ou une échéance absolue est plus pertinent. Les fenêtres et chiffres restent datés et révisables.
Les seuils à deux niveaux réduisent le bruit : avertissement vers une file de travail, critique vers l’astreinte. Le passage critique demande impact et action. Une mesure imprécise peut d’abord rester informative jusqu’à ce que sa relation avec les incidents soit démontrée.
Observer les parcours synchrones
Un parcours HTTP se mesure de l’entrée au résultat utilisateur. Le serveur peut répondre 200 tout en afficher une donnée vide ou un statut périmé. L’indicateur combine code, résultat métier et durée lorsque ces dimensions influencent la promesse.
Les percentiles révèlent la longue traîne ; la moyenne ne suffit pas. La segmentation par route peut être utile, mais les identifiants à forte cardinalité restent dans les traces ou logs. Une métrique avec un label par client détruit coût et lisibilité.
Les erreurs attendues sont classées. Authentification invalide, validation métier et panne de dépendance ne partagent pas la même alerte. Le tableau garde pourtant leur évolution, car une hausse de refus peut signaler une régression d’interface.
Voir l’âge et les blocages des files
La longueur d’une file seule est insuffisante. Mille travaux jeunes peuvent être absorbés ; dix messages anciens peuvent indiquer une poison pill qui bloque une partition. Âge du plus ancien, débit entrant, débit sortant, retries et dead letters forment une lecture plus utile.
Le traitement porte un identifiant d’intention, une date et une classe. Le monitoring suit succès confirmé, refus certain et état inconnu. Un retry n’est pas compté comme une nouvelle opération métier, sinon la reprise semble créer artificiellement de l’activité.
Le seuil dépend de la promesse. Un export peut attendre trente minutes, une réservation de stock non. L’alerte indique la classe touchée et le runbook de pause, isolation ou rejeu, plutôt qu’un simple « queue > 100 ».
Surveiller les traitements planifiés
Un cron qui n’a pas démarré ne produit parfois aucune erreur. L’application émet donc un heartbeat attendu, avec fenêtre de début et date de dernière réussite. Le run distingue absent, en cours, bloqué, partiellement terminé et terminé.
La progression se mesure par unité stable : lignes validées, comptes rapprochés ou partitions fermées. Un pourcentage sans dénominateur versionné trompe lorsque le volume change en cours de route. Les checkpoints rendent la reprise visible.
Le budget associe échéance métier et vitesse restante. Alerter uniquement après l’heure limite supprime toute capacité d’action. Une projection prudente peut avertir plus tôt, mais elle reste informative tant que sa précision n’est pas mesurée.
Cas concret : commandes bloquées sans erreur
Un portail accepte les commandes puis les transmet à l’ERP. Les réponses HTTP restent vertes et les workers consomment. Pourtant, certaines commandes ne dépassent jamais « en préparation » parce qu’un message de confirmation arrive avant la création de la référence locale.
Le premier monitoring comptait erreurs et longueur de file : rien d’anormal. L’équipe ajoute l’âge des commandes par état et une mesure « intention sans confirmation ». Par exemple, un avertissement apparaît après dix minutes parce que la préparation locale promet quinze minutes sur ce site.
Le seuil n’est pas présenté comme universel. Une autre filiale peut avoir une fenêtre différente. Si l’âge dépasse le budget, le runbook isole les identifiants, relit l’ERP et rapproche sans renvoyer à l’aveugle. Une trace relie intention, événement précoce et transition refusée.
Le test reproduit l’inversion, puis le tableau vérifie que le signal disparaît après rapprochement. L’alerte appelle seulement si le backlog ancien progresse ou si la date limite approche. Le bruit baisse tandis que le défaut auparavant silencieux devient actionnable.
Journaliser pour expliquer, pas pour tout stocker
Un log utile porte événement, service, environnement, version, corrélation, résultat et prochaine étape. Il ne répète pas chaque variable ni chaque succès nominal à un niveau interruptif. Les données sensibles sont exclues ou masquées selon un schéma connu.
Les niveaux ont un sens opérationnel. Error indique une opération non tenue qui nécessite investigation ou agrégation ; warning une situation récupérée ou proche d’une limite ; info une étape métier importante. Debug reste activable de façon bornée.
La rétention dépend du besoin de diagnostic et de preuve. Une durée plus longue augmente coût et exposition. L’équipe teste la purge, l’accès et la recherche, puis échantillonne les événements volumineux seulement si la décision reste possible.
Corréler traces et intentions métier
Une trace suit une requête ou un traitement à travers les composants. L’intention métier peut vivre plus longtemps que cette trace, traverser une file et plusieurs retries. Un identifiant stable relie les segments sans confondre tentative et opération.
Les spans nomment des opérations stables et ajoutent quelques attributs utiles : classe de parcours, résultat, partenaire. Les identifiants personnels ou libres ne deviennent pas des attributs de métrique. La cardinalité est une contrainte de conception.
L’échantillonnage conserve les erreurs et une part représentative du nominal selon la plateforme. Une trace absente ne doit pas rendre le run impossible : états métier et logs structurés gardent la preuve minimale.
Concevoir une alerte avec une action
Le message contient promesse touchée, population, début, valeur, seuil, lien vers vue et première action. Il évite les titres génériques. Le destinataire sait s’il doit acquitter, observer, limiter, basculer ou contacter un propriétaire.
Les alertes corrélées sont regroupées autour du symptôme principal. Une panne de base peut produire de nombreux signaux ; l’alerte de parcours reste la porte d’entrée et le diagnostic montre saturation ou connexions. L’équipe supprime les pages filles sans action distincte.
Chaque alerte possède une revue. Si elle n’a déclenché aucune action lors de cinq occurrences, elle retourne en mode informatif ou son seuil change. Ce nombre est un critère local de chantier, non une recommandation générale.
Construire des vues pour le run
La première vue répond à l’état des promesses : succès, délais, backlog ancien et modes dégradés. La seconde aide au diagnostic par dépendance. Une troisième peut servir à la capacité. Mélanger ces trois objectifs sur un écran crée une mosaïque illisible.
Le dashboard indique source, unité, fenêtre et dernière donnée. Un graphe vide se distingue d’un zéro. Les annotations de déploiement, configuration et incident facilitent la causalité sans conclure automatiquement.
Le support voit les parcours et identifiants qu’il peut traiter. La plateforme voit ressources et saturation. Le produit voit conséquence et tendance. Les vues partagent les mêmes événements mais adaptent le langage à la décision.
Relier signal, runbook et droit d’action
Un runbook commence par vérifier le symptôme et son périmètre. Il indique les lectures sûres, les actions réversibles, les droits nécessaires et les conditions d’escalade. Il ne se réduit pas à « redémarrer le service ».
Les commandes affichent un aperçu et demandent une intention explicite pour les écritures. Le rejeu est idempotent ou vérifie l’état avant d’agir. Les actions sensibles conservent auteur, motif et résultat.
Un exercice depuis l’alerte valide liens, accès et compréhension. Si le propriétaire est absent, une autre personne doit au moins diagnostiquer et contenir. Les étapes qui dépendent d’un savoir oral reviennent dans l’instrumentation ou la documentation.
Implémenter instrumentation et responsabilités
Contrats de télémétrie
Les entrées sont les événements de domaine, statuts, timestamps et identifiants de corrélation ; les sorties sont métriques agrégées, logs structurés et traces. Les responsabilités séparent équipe produit, plateforme et run. Les dépendances, seuils et règles de cardinalité sont versionnés avec leur propriétaire.
La journalisation précise résultat et repli ; le monitoring calcule âge et budget ; le runbook porte rollback et reprise. Chaque instrumentation a un test : compteur incrémenté au bon commit, span propagé dans la file, absence de secret et alerte rendue silencieuse lorsque le mode maintenance est prévu.
Déploiement compatible
Les anciens et nouveaux noms coexistent pendant une fenêtre. Les dashboards acceptent les deux versions, puis la migration supprime l’ancien après vérification. Le rollback de code ne doit pas rendre les signaux muets ; la procédure liste ce minimum de compatibilité.
Tester silence, rollback et reprise
L’équipe provoque trois choses : un défaut détecté, une panne sans télémétrie et une avalanche de symptômes. Elle vérifie page, regroupement, diagnostic et action. Le silence du collecteur possède son propre heartbeat indépendant de l’application.
Le rollback restaure une version compatible sans effacer les travaux en attente. La reprise traite backlog et quotas progressivement. Le monitoring distingue rattrapage prévu et nouvelle dégradation afin de ne pas appeler pendant chaque récupération.
Après exercice, l’équipe mesure délai de détection, temps avant première action et fermeture. Elle recherche surtout les hypothèses fausses : accès manquant, seuil trop tardif, identifiant absent ou action dangereuse.
Pour qui cette méthode de surveillance est utile
Elle convient aux produits où support, métier et technique voient des réalités différentes, où les batchs échouent silencieusement ou où l’astreinte reçoit trop de pages. Une équipe sans astreinte utilise les mêmes principes pour ses alertes en heures ouvrées.
Une petite équipe commence par trois promesses et un canal. Une organisation plus grande attribue des propriétaires par domaine et maintient un catalogue de services. Le niveau de formalisation suit le nombre d’intervenants et la criticité.
Un site de contenu simple n’a pas besoin de tracer chaque intention. Disponibilité, erreurs et publication peuvent suffire. Le dispositif reste proportionné : la télémétrie est un produit de run, pas un concours d’outils.
Erreurs fréquentes de surveillance applicative
- Alerter sur chaque exception. Les refus attendus et retries récupérés saturent le canal.
- Copier un seuil de CPU. La ressource ne dit ni la promesse touchée ni l’action attendue.
- Créer un label par client. La cardinalité explose, les coûts montent et les vues deviennent lentes.
- Journaliser les charges complètes. Secrets et données se diffusent sans améliorer le diagnostic agrégé.
- Ignorer les batchs silencieux. L’absence d’erreur n’est pas une preuve d’exécution.
- Écrire le runbook après l’incident. Les droits, commandes et modes dégradés doivent être exercés avant.
Matrice de décision : appeler, attendre ou informer
Si une promesse critique est rompue et qu’une action peut réduire l’impact maintenant, alors l’alerte appelle. Si l’action peut attendre la prochaine plage sans augmenter le dommage, elle ouvre un travail. Si le signal sert seulement à une tendance, il reste dans le tableau.
En revanche, une mesure incertaine ne devient pas page pour « être prudent ». Elle passe par une période d’observation. Les seuils sont comparés aux incidents réels, puis promus ou retirés. À éviter : un score unique de santé qui cache les parcours.
- À bloquer : impact actuel, action immédiate et propriétaire joignable.
- À documenter : dérive bornée, délai disponible et preuve conservée.
- À différer : capacité ou tendance sans geste immédiat.
- À refuser : signal redondant qui n’a modifié aucune décision observée.
Plan d’action : installer le dispositif en huit semaines
Semaines 1 et 2 : partir du run réel
L’équipe relit incidents, tickets support et alertes des deux derniers mois. Elle choisit cinq promesses et établit leur baseline : réussite, délai, âge ou état inconnu. Chaque alerte existante reçoit propriétaire, action et canal ; les orphelines passent en observation.
Les statuts et identifiants sont alignés entre produit, logs et support. Une première carte relie symptôme, diagnostics techniques et runbook. Le coût de télémétrie et la présence de données sensibles sont audités.
Semaines 3 à 5 : instrumenter et décider
Les événements de promesse, métriques d’âge et traces critiques sont livrés. Les dashboards séparent service et diagnostic. Trois alertes actionnables remplacent les grappes redondantes. Un test vérifie compteur, propagation et absence de secret.
Le support et l’exploitation jouent un incident de file et un batch absent. Les seuils sont ajustés aux temps observés ; les actions sans droits ou preuves enrichissent le runbook.
Semaines 6 à 8 : éprouver le silence et la reprise
Le collecteur est coupé, une avalanche est injectée et une restauration progressive est simulée. L’équipe confirme regroupement, heartbeat, rollback et distinction entre rattrapage et rechute. Une personne extérieure au pilote prend l’alerte.
La revue compare pages, actions, détection et bruit. Le périmètre s’étend si chaque page a conduit à une décision et si les défauts silencieux étudiés sont visibles. Sinon les signaux restent bornés jusqu’à correction.
Le transfert se conclut par une rotation réelle : un collègue extérieur reçoit une alerte, qualifie son impact, exécute la première action et passe la main avec les mêmes identifiants. Toute étape qui dépend encore du pilote ou d’un accès improvisé retourne dans le backlog avant l’ouverture d’un nouveau parcours.
S’appuyer sur des références d’observabilité
La documentation OpenTelemetry décrit métriques, logs et traces, tandis que les recommandations officielles Prometheus sur l’alerting insistent sur des alertes simples et actionnables.
Pour les processus longs, l’observabilité des workflows métier précise les états. Le test des exceptions aide à provoquer les signaux, et la stratégie de logging utile complète la gouvernance des traces textuelles.
Conclusion : surveiller les décisions, pas les outils
Une application bien surveillée rend ses promesses, ses états inconnus et ses retards visibles. Les métriques d’infrastructure expliquent ensuite la causalité ; elles ne sont pas le produit surveillé.
Le bruit recule lorsque chaque alerte a un impact, un propriétaire et une action. Les autres signaux restent disponibles pour la tendance ou le diagnostic sans interrompre l’équipe.
Commencez par le défaut le plus souvent découvert par un humain avant le monitoring. Décrivez la promesse, trouvez l’événement et jouez le runbook. Cette expérience révèle plus de lacunes qu’un inventaire abstrait de dashboards.
Si vos équipes naviguent entre alertes techniques et tickets métier sans diagnostic commun, Dawap peut vous accompagner pour rendre votre application web métier observable et reprenable.
