Supervision et monitoring pour piloter sans naviguer à vue

concevoir une architecture robuste ne suffit pas. Nous devons également savoir ce qu'il s'y passe réellement, en temps réel... sans attendre que les utilisateurs nous signalent les pannes.
Supervision et monitoring pour piloter sans naviguer à vue

Dans notre précédent article, nous avons exploré les mécaniques de gestion de charge et le rôle des répartiteurs de charge (le load balancer) pour élargir la tuyauterie de notre infrastructure. C’est une étape cruciale pour digérer le trafic. Cependant, posséder un excellent réseau ne suffit pas : encore faut-il disposer d’un tableau de bord pour vérifier la pression, détecter les fuites invisibles et comprendre la direction que prend le flux des requêtes.

Construire une application moderne assistée par l’IA nous donne une vitesse de livraison phénoménale. Mais pour éviter que cette vitesse ne se transforme en trajectoire aveugle, nous devons impérativement mettre en place des yeux et des oreilles au cœur de notre système. C’est tout l’enjeu du monitoring (l’observation et l’analyse en continu) d’un côté, et la supervision (le contrôle et l’alerte instantanée) de l’autre.

Passer du mode pompier au mode pilote

Lorsque nous ne disposons d’aucune mesure sur notre infrastructure, notre seule source d’information devient la plainte de l’utilisateur. C’est le zéro absolu de la gestion de production : nous subissons les événements, nous travaillons dans l’urgence et nous réparons les dégâts après coup… Sans véritable marge de manœuvre pour l’innovation.

L’objectif sera alors de renverser cette dynamique, en surveillant en continu les ressources, en étant alertés avant que la situation ne devienne critique.

Une infrastructure performante n’est pas une infrastructure qui ne plante jamais, c’est une infrastructure équipée pour nous dire exactement se trouvent les risques avant que la situation ne devienne critique.

Le Monitoring pour observer le système et décrypter les usages

Analyse du bilan de santé à moyen et long terme

Le monitoring est une démarche d’observation visant à collecter, stocker et analyser des données historiques sur le comportement de notre application.

Le premier besoin que nous voulons adresser est purement technique : comprendre la santé globale et les tendances de consommation de nos ressources (CPU, mémoire, trafic réseau). En surveillant en continu des données d’usage, comme le remplissage du volume hébergeant la base de données, nous pouvons anticiper une panne en agissant largement en amont. Cette surveillance nous permet également d’identifier les goulots d’étranglement dont nous avons parlé précédemment, et de vérifier de manière factuelle et chiffrée si nos choix d’optimisation ont eu les impacts escomptés.

Le second besoin est directement lié à l’évolution du produit : comprendre les usages qu’ont les clients de notre application. En observant le parcours de nos utilisateurs, nous pouvons identifier les fonctionnalités les plus populaires, repérer les pages sur lesquelles ils abandonnent leur navigation, ou détecter des frictions dans l’expérience utilisateur. Le monitoring n’est donc pas qu’un outil pour l’équipe technique ; c’est un levier stratégique pour faire évoluer le produit de façon pertinente, en nous appuyant sur des données réelles plutôt que sur des intuitions.

Les outils du monitoring

Une série d’outils particulièrement populaires constituent ce qu’on appelle la stack ELK. Elle se compose de trois briques correspondant aux trois initiales, chacune avec un rôle précis :

  • Elasticsearch se charge du stockage des données collectées. Nous l’alimentons en plaçant des sondes un peu partout dans nos applications (que nous devons bien souvent intégrer nous-même) et sur les ressources de notre infrastructure (souvent fournies par le fournisseur de l’offre Cloud) pour remonter ce qu’on appelle les logs d’utilisation.
  • Logstash se charge de récolter ces données et de les nettoyer et les enrichir pour les mettre en forme. De la sorte, nous pouvons exploiter un langage de requête spécialement optimisé pour extraire et analyser les informations par nous-même, sans nous noyer dans le flot de données qui peut être immense. Aujourd’hui, Logstash est complété, voire remplacé par de nouvelles solutions, comme Beats ou Filebeats.
  • Enfin, Kibana nous offre l’interface graphique permettant de visualiser les données sous la forme de graphiques et de tableaux de bord personnalisables.

ELK reproduit ainsi une pile assez classique de traitement de l’information : récupération et nettoyage des données, stockage, et rendu graphique des informations.

Des outils spécifiques permettent de traquer l’activité sur nos interfaces web. Deux très connus sont Google Analytics et Matomo, mais il en existe bien d’autres. Au-delà de ça, ces outils reprennent une logique assez similaire à la suite ELK : nous plaçons des sondes dans l’interface web, de sorte à détecter les clics sur les boutons, l’ouverture des pages, le fait de scroller pour monter ou descendre sur la page, etc. Ensuite, ces outils stockent ces informations de sorte que nous puissions modéliser l’activité et le parcours des utilisateurs sur l’application. Ces outils exploitent également l’ensemble des informations que les navigateurs web sont capables de capter et d’exposer des informations techniques et statistiques fournies par le navigateur (comme sa propre identité, ou bien des données de session) permettant de déterminer les horaires de connexion de nos utilisateurs, la durée de leurs sessions, etc.

La Supervision pour contrôler et alerter en temps réel

Le moniteur cardiaque de l’unité de soin intensif

Si le monitoring est le médecin analysant notre bilan sur le temps long, la supervision sert à répondre à une question simple et binaire : « Est-ce que mon service fonctionne correctement à la seconde même ? ». La supervision, combinée au monitoring d’alerte (lui-même souvent assimilé à la supervision) est essentielle pour déclencher des démarches opérationnelles immédiates.

Nous les utilisons pour définir des seuils critiques. Par exemple, si le taux d’erreurs réseau dépasse 5% sur les trois dernières minutes, ou si notre serveur d’application ne répond plus du tout aux requêtes de test (pings), le système de supervision doit se réveiller. Son rôle principal est alors de déclencher une alerte immédiate (par e-mail, sur notre canal Slack, ou via des outils de gestion d’incidents comme PagerDuty) pour notifier l’équipe avant que l’ensemble des clients ne soient bloqués.

Les outils de la supervision

Si le monitoring repose sur des sondes, donc l’envoi de notifications, la supervision s’appuie beaucoup plus sur l’envoi de requêtes de suivi. Par exemple Prometheus passe son temps à interroger nos services à intervalles réguliers via des points d’entrées spécifiques. De la sorte, il collecte pour nous des métriques sous la forme de séries temporelles (des données numériques associées à un horodatage précis). Pour le reste, nous retrouvons une logique similaire à celle du monitoring, car là aussi, il faut afficher les informations d’une façon ou d’un autre. Dans le cas de la supervision avec Prometheus, son partenaire habituel est Grafana, grâce à qui nous pouvons disposer d’écrans de contrôle en temps réel et gérer les règles de déclenchement des alertes.

D’autres solutions très connues bonnes à connaître sont Zabbix (un outil historique très robuste, pour surveiller la santé du réseau et des machines virtuelles), et Datadog (solution tout en un, incluant également le monitoring). Une tendance va d’ailleurs à considérer la supervision comme une partie du monitoring, qui intègre alors collecte, visualisation, et alerting.

Placer la télémétrie entre les mains de notre IA

Comprendre ces concepts de monitoring et de supervision est la suite logique de nos efforts sur la gestion de charge. Lors de notre précédent article, nous avons vu l’importance de comprendre l’architecture pour correctement orienter l’analyse des blocages avec son IA.

Les outils de supervision et monitoring sont précisément les thermomètres qui nous fournissent les données factuelles indispensables. En cas de ralentissement ou de comportement anormal, nous pouvons soumettre à notre IA les rapports de logs de notre stack ELK ou les graphiques de métriques de Prometheus. Notre IA sera d’autant plus une aide précieuse que le volume de données peut être très conséquent (et par là même coûteux à héberger).

Fort de toutes ces mesures précises, remontées automatiquement par notre infrastructure (ce qu’on appelle la télémétrie), notre binôme IA pourra réaliser un diagnostic chirurgical et nous proposer des corrections pertinentes sur le code ou l’infrastructure.

Ressources (et quelques lectures intéressantes)


Write a comment