Une console de supervision affichant tout au vert un lundi matin ne prouve pas que la semaine passée s’est bien passée. Elle prouve que, à cet instant précis, rien ne dépasse les seuils configurés. C’est une photo. Et une photo ne raconte pas le film.
C’est à partir de ce constat simple (et pourtant rarement formulé) que s’est construite une partie de notre travail chez Sensor Factory : l’analyse comportementale des plateformes de supervision de nos clients. Pas l’analyse de l’infrastructure supervisée, mais de la supervision elle-même, de ce qu’elle produit, de ce qu’elle dit, et surtout de ce qu’elle murmure sans que personne ne l’entende vraiment.
Ce qu’une plateforme produit, au-delà des alertes
Chaque plateforme de supervision génère en permanence un flux d’événements. Des états DOWN, des retours UP, des seuils franchis, des checks qui échouent, des capteurs qui oscillent. Dans une organisation de taille intermédiaire, on parle facilement de plusieurs milliers d’événements par semaine. La plupart passent inaperçus, soit parce qu’ils ont été acquittés, soit parce qu’ils se sont résolus seuls avant que quelqu’un les voie, soit parce qu’ils arrivent la nuit quand personne n’est devant la console.
Ce flux, nous l’ingérons dans notre stack de centralisation de logs et nous le rendons lisible sur une semaine glissante. Ce qu’on y cherche, ce ne sont pas les incidents (les équipes les connaissent déjà). Ce sont les patterns : quels équipements génèrent le plus d’événements ? Quels types de capteurs sont les plus bruyants ? À quelles heures les problèmes se concentrent-ils ? Est-ce que ce volume augmente, diminue, dérive ?
C’est cette lecture-là, transversale, temporelle, détachée de l’instant, qui commence à raconter quelque chose d’intéressant.
La supervision aveugle au temps
Deux exemples, vécus, anonymisés.
Le CPU qui se dégrade sans jamais alerter. Un serveur applicatif présente régulièrement des pics de charge CPU. Rien d’anormal en apparence : le seuil d’alerte est configuré sur un pourcentage de saturation ponctuel, qui déclenche puis disparaît. Les équipes voient passer l’alerte, constatent que ça s’est résorbé, passent à autre chose. Ce que l’analyse comportementale montre, semaine après semaine, c’est que ces plateaux de saturation s’allongent. C’est précisément ce que Brendan Gregg, dans sa méthode USE, identifie comme le signal le plus traître : non pas l’erreur franche, mais la saturation qui dérive progressivement sans jamais franchir le seuil d’alerte configuré. Ce qui durait deux minutes il y a trois mois dure maintenant huit minutes. L’alerte sonne toujours, le seuil est toujours le même, mais le comportement du système a fondamentalement changé. Personne ne l’avait vu, parce que chaque alerte, prise isolément, semblait se comporter normalement.
L’espace disque qui se remplit la nuit. Une infrastructure de base de données, avec un process de backup nocturne classique : chaque nuit, un dump est généré sur disque, l’espace monte, une alerte se déclenche, puis le dump est archivé ou purgé et le matin tout est revenu sous les seuils. Vert. Propre. En journée, personne ne voit rien. Sauf qu’en regardant la tendance sur plusieurs semaines, on observe quelque chose de mécanique : le dump grossit. Pas parce que quelque chose dysfonctionne, mais parce que la base de données grossit, elle, tout à fait normalement. Le niveau de remplissage nocturne progresse semaine après semaine, millimètre par millimètre. La question qui s’impose alors est simple et inconfortable : que se passe-t-il le jour où l’espace disponible n’est plus suffisant pour générer le dump ? La réponse est brutale. La sauvegarde ne se fait pas. Silencieusement. Sans incident apparent. Jusqu’au jour où on en a besoin. L’alerte avait sonné chaque nuit depuis des mois. Personne n’avait vu qu’elle sonnait un peu plus fort à chaque fois.
Ces deux situations ont en commun une chose : l’alerte ne manquait pas, c’est la lecture dans le temps qui manquait. La console montrait une photo chaque fois correcte. Le film, lui, montrait une dégradation progressive que personne n’avait assemblée.
Le regard extérieur comme méthode
Il serait facile de conclure que les équipes internes ne font pas leur travail. Ce serait faux, et ce serait injuste. Le problème n’est pas une question de compétences, c’est une question d’angle.
Une équipe IT immergée dans son contexte traite les alertes au fil de l’eau, gère les priorités du moment, répond aux demandes métiers, jongle avec les contraintes politiques et budgétaires. Elle est dans le film, précisément. Ce qu’elle ne peut pas faire facilement, c’est en sortir pour le regarder de loin.
C’est là qu’un tiers intervient différemment. Pas parce qu’il serait plus compétent, mais parce qu’il est structurellement détaché du contexte interne. Il ne sait pas quelles tensions existent entre la DSI et tel métier. Il ne connaît pas l’historique de tel serveur ni les contraintes de tel éditeur. Il arrive avec les données brutes et une question naïve : pourquoi ce capteur bagote-t-il tous les lundis matin à 7h ?
Parfois la réponse est simple (une tâche planifiée, une fenêtre de maintenance mal gérée, un redémarrage de service). Parfois elle ouvre quelque chose que le client n’avait pas vu. Et parfois elle pointe un problème sur lequel il ne peut pas grand-chose, coincé entre un éditeur peu coopératif et une infrastructure héritée, mais au moins il le sait, il peut l’anticiper, il peut en informer sa direction.
C’est ce petit caillou dans la chaussure, celui qu’on n’avait pas senti parce qu’on marchait dessus depuis trop longtemps, qui justifie la démarche mieux que n’importe quel argumentaire technique.
De la réunion hebdomadaire à la mémoire long terme
L’analyse n’est pas un rapport qu’on envoie et qu’on oublie. Elle est le point de départ d’un échange.
Chaque semaine, le rapport est préparé en amont (top talkers, répartition temporelle des événements, signaux inhabituels, tendances) et présenté en réunion avec les équipes techniques du client. Le client apporte le contexte que les données ne donnent pas : cette alerte, c’était une maintenance planifiée. Ce pic, c’est une migration qu’on a faite jeudi. Ce site qui a coupé deux fois, c’est un problème avec l’opérateur qu’on suit depuis un mois.
Ce dialogue est capturé. Les commentaires, les explications, les actions décidées, tout est tracé dans le rapport, qui devient un document vivant. C’est OpsPilot, notre outil dédié à cette analyse, qui structure ce flux : centralisation des logs de supervision, mise en forme des dashboards d’analyse, et rapport hebdomadaire annoté en séance.
Au bout de quelques semaines, quelque chose change. On ne lit plus une semaine isolée, on lit une trajectoire. Les comparatifs S-1, S-2, S-3 commencent à raconter une histoire. Une tendance à la hausse sur un silo applicatif critique, une stabilisation progressive après une correction, une récurrence qui revient malgré les actions engagées. C’est là que la valeur de la démarche devient vraiment tangible.
Ce qu’on finit par construire ensemble
Au fil du temps, l’analyse se structure autour des enjeux réels du client, et plus seulement autour des équipements. On construit ce qu’on appelle des silos techniques et métiers, des vues qui agrègent les signaux autour d’un service, d’un périmètre, d’un risque identifié.
Pour un opérateur multi-sites, le silo qui compte, c’est la disponibilité réseau de chacun de ses établissements : nombre de coupures, durées, récurrences, comportements qui se ressemblent d’un site à l’autre. Pour un autre client, c’est la performance d’une application métier critique, dont les dégradations nocturnes commencent à déborder sur les heures ouvrées. Pour un troisième, c’est la santé d’une infrastructure de virtualisation dont les alertes datastore s’accumulent discrètement.
Ces silos deviennent des instruments de pilotage. Pas de surveillance passive, mais de compréhension active. Et la relation qui s’instaure avec les équipes techniques du client change de nature : on n’est plus le prestataire qui envoie des alertes, on est le tiers de confiance qui aide à voir ce qu’on ne voit plus quand on est dedans.
Ce que les données ne disent pas seules
Il faut être honnête sur une chose : cette démarche n’est pas magique, et elle n’est pas automatisable à 100 %. Les données donnent des signaux. C’est le dialogue avec les équipes qui leur donne un sens. Une tendance à la hausse peut être parfaitement légitime (une montée en charge planifiée, une extension de périmètre). Elle peut aussi être le signe avant-coureur d’un problème sérieux. La différence, c’est le contexte. Et le contexte, c’est le client qui le détient.
C’est pour ça que cette analyse n’a de valeur que dans la durée, et que dans la relation. Le rapport de la première semaine est utile. Celui de la dixième semaine, enrichi de dix échanges, de dix séries de commentaires, de dix décisions tracées, est précieux.
Ce qu’on cherche chaque semaine, ce n’est pas la fausse note (les outils la détectent). C’est le tempo qui change, la phrase qui se déforme progressivement. Ça, ça ne s’entend que si on écoute le morceau en entier.
Cette approche s’inscrit dans la vision que nous défendons chez Sensor Factory : la supervision n’est pas qu’un outil de détection d’incidents. C’est un flux d’information continu sur la santé réelle d’un système d’information, à condition de savoir le lire. Pour aller plus loin sur notre vision de la supervision et de l’observabilité, l’article de Matthieu « De l’observabilité à l’infrastructure » pose les fondations conceptuelles de ce que nous faisons au quotidien.
