Superviser un centre de données

Les outils en ligne de commande sont puissants, hautement personnalisables, et donnent accès à une quantité considérable d’informations, manipulable au seul clavier. Il permettent à l’utilisateur un contrôle total et un accès à une grand profondeur d’information.

Les techniciens auxquels s’adressent le produit présenté ici, sur lequel j’ai travaillé avec Use Design en 2022, sont habitués à ces outils en ligne de commande. Notre objectif est d’augmenter la qualité de l’information, et améliorer la prise de décision, en offrant à ces utilisateurs ce que n’offre pas la ligne de commande : Une synthèse et une consolidation des informations, par un prisme métier ou un prisme technique.

Présentation

L’application prend place dans un dispositif installé dans des centres de surveillance d’espace aérien. L’essentiel de l’information qui y est consultée est fournie par des radars, disséminés sur un territoire. En arrivant dans les centres de données, puis dans les salles opérationnelles, ces données sont traitées par un grand nombre d’applicatifs. Notre objectif est de fournir un outil qui améliore la supervision de cette infrastructure applicative.

Au coeur de l’infrastructure technique existent donc deux grands types d’objet : des interfaces externes, qui créent de la donnée (des radars), et des applications, avec différents niveaux de répllication, qui permettent de l’exploiter. Autour de ces objets en gravitent d’autres : des centres de données et des centres opérationnels, des machines qui permettent de consulter les données. Les données sont accessibles au sein de sessions, qui sont des sessions d’entrainement ou des sessions live.

On le voit : le système implique des objets physiques (des serveurs, des radars, des salles de travail, des connexions, des stations de travail) et virtuels (des sessions, des éxécutables). Des L’interface permettra de superviser l’ensemble de ces objets, de natures différentes, et offrira une vue consolidée de cet état.

Un cas critique : l’inondation de données

L’inondation de donnée permet de mesurer l’efficacité de l’outil dans une situation extrême. En cas de défection d’un applicatif clé, d’un problème matériel, d’un disque qui crashe, d’un serveur qui tombe, la configuration du système est là pour permettre à celui-ci de fonctionner, grâce à la réplication des objets softwares et hardware. Mais lorsqu’un objet physique comme un radar connait une défaillance, il inonde le système de données incorrectes. Le système de notification doit donc permettre une isolation rapide du problème.

Le système d’alerte recense tous les messages du système. C’est un journal, est le principe est le même principe que dans l’administration d’un serveur. Un journalctl -f /var/log/apache2 trace tous les messages du système. L’interface apporte ceci de plus qu’un filtre permet d’affiner les entrées du journal, en filtrant par niveau d’erreur. D’abord, les simples messages sont retirés de l’affichage. Ensuite, les erreurs secondaires s’effacent : seules les entrées critiques sont affichées.

Le nombre d’occurrences d’une alerte critique doit mettre rapidement sur la piste du problème. L’expertise, évidemment, et aussi l’utilisation de la couleur et du texte. De cette façon, l’affichage de la situation critique donne déjà une indication sur la nature du problème : est-ce un radar qui est tombé en panne ? Est-ce un problème électrique dans un centre de données ? Est-ce un pod qui crashe ? Où y a-t-il corrélation, où y a-t-il causalité ?

Résultat

L’expertise de l’utilisateur est essentielle, et L’interface lui offre une couche supplémentaire de sens pour l’aider dans la compréhension de l’état d’un système constitué d’objets physiques et de programmes informatiques, et répartis sur une vaste zone géographique. L’application permet donc de lier des informations techniques, et les orchestrer de façon à offrir une supervision. Elle offre une meilleure qualité de communication entre les différents rôles des centre de données et des centres opérationnels, et un drill-down plus rapide des erreurs.

Les deux clés de la réussite de ce travail sont

• Identifier les objets du système, leur nature, et leurs relations. En faisant ce travail, la compréhension de l’architecture du système est plus fine et permet d’identifier les axes d’amélioration
• Une intervention graphique minimale : je vois le résultat comme un terminal, mais avec juste ce qu’il faut de graphisme en plus : l’information est répartie en zones, avec l’aide différents niveaux de gris. La couleur apporte toujours un sens précis : problème d’un objet, et criticité, niveau de réplication, etc.

Du premier travail découle naturellement le second.