Contexte
Le projet COLOSS, visant à moderniser la plateforme de gestion de journaux [1] du CC-IN2P3, est entré progressivement en production depuis le début de l’année 2016. La plateforme gère tous les jours plus d’un milliard d’événements, dont 10% sont stockés sur disque pendant un an. La provenance des informations est très variée :
- Journaux du système d’exploitation
- Messages applicatifs
- Événements d’appareillages d’infrastructure (climatiseurs, onduleurs, etc.)
- Mesures de performance des serveurs (cpu, mémoire, réseau, etc.)
- Comptabilité des "jobs" exécutés sur la ferme de calcul
Le système permet aux administrateurs et exploitants de services du CC-IN2P3 d’injecter leurs données d’exploitation et de les consulter par la suite. Deux interfaces utilisateur sont mises à disposition à cet effet. La première permet l’analyse instantanée du flux d’événements via un système d’abonnement synchrone. Elle est utilisée notamment pour la remontée d’alertes et le suivi en temps réel des conséquences d’une intervention. Sa faible latence (au plus 200ms) est très utile pour un suivi haut niveau à la suite d’une mise à jour ou d’un changement en amont. La deuxième interface permet une analyse historique des événements, très utile pour les investigations post-mortem, la comptabilité, ou encore la fouille de données. Les deux interfaces sont disponibles à la fois sous forme d’IHM [2] et d’API [3], afin de permettre une intégration facilitée aux autres services.
Architecture
L’architecture de COLOSS repose entièrement sur une suite de logiciels libres. Un résumé de leur fonction au sein de la pile est exposé aux paragraphes suivants.
syslog-ng
Le logiciel syslog-ng est un gestionnaire de journaux ("logs"). Édité par la société Balabit, son domaine de fonctionnalités dépasse largement le cadre que son nom indique. En effet, bien qu’initialement développé pour remplacer le service UNIX syslogd, il permet dans sa dernière version (3.7.3) de traiter des événements provenant d’un large éventail de sources différentes, et de les acheminer vers un jeu très diversifié de destinations. Il remplit au CC-IN2P3 toutes les fonctions vitales de gestion des "logs", notamment la réception, le filtrage, l’analyse syntaxique, l’enrichissement et le routage vers d’autres systèmes. Il permet par exemple d’indexer les documents dans Elasticsearch en utilisant le protocole natif (node). Un des grands avantages de syslog-ng par rapport à ses alternatives est son efficacité : écrit en langage C et utilisant des routines optimisées, il permet un passage à l’échelle vertical. En effet, une instance au CC-IN2P3 gère en moyenne 2000 événements par seconde avec une charge négligeable. Lors de pics de trafic, une simple instance traite presque 100 000 événements par seconde avec une charge de 50%. L’instance en question s’exécute sur une machine virtuelle avec 8 vCPU et 8G de RAM. En outre, l’architecture COLOSS permet d’orchestrer plusieurs instances syslog-ng grâce au logiciel puppet, permettant ainsi un passage à l’échelle horizontal de l’infrastructure.
collectd
collectd est un système de collection et de traitement de métriques. Il est traditionnellement utilisé pour surveiller les compteurs de performance des systèmes d’exploitation de type UNIX. Il permet notamment de suivre l’évolution dans le temps du remplissage des systèmes de fichier, ou encore de mesurer le taux d’utilisation des processeurs. Son architecture est basée sur un noyau logiciel minimaliste entouré de "plugins", ce qui lui permet d’avoir une empreinte mémoire et "cpu" très réduite. Par conséquent, il convient parfaitement à la fois aux systèmes embarqués et aux grands systèmes, dans lesquels l’on peut activer un grand nombre de "plugins". Le CC-IN2P3 utilise collectd pour interroger les compteurs système (cpu, mémoire, disque, réseau), matériels (températures, puissances électriques) et applicatifs. Ceux-ci sont ensuite envoyés à Riemann pour le traitement centralisé. On peut configurer des seuils afin d’attacher un état à chaque événement ("ok", "warning"
ou "critical"), ce qui permet de générer des notifications.
Elasticsearch
Elasticsearch est un moteur de recherche distribué, qui permet de stocker et indexer des documents JSON. Il permet notamment des recherches de type "full-text", qui sont particulièrement appréciées par les utilisateurs. Son API très riche permet à la fois d’administrer le "cluster" et d’effectuer des requêtes précises sur le contenu. Un grand nombre de clients est disponible dans la plupart des langages de programmation courants, et sa popularité vient en grande partie de l’excellente interface graphique permettant de consulter les données qu’il contient : Kibana. Elasticsearch est utilisé au CC-IN2P3 pour stocker la totalité des "logs" pendant un an, ce qui représente près de 60 milliards de documents. Il sera également utilisé pour stocker les métriques dans le cadre du projet sampler, dont le but est de remplacer le système actuel basé sur RRDTool.
Riemann
Le gestionnaire de flux Riemann est sans doute le moins connu de la bande. C’est un logiciel écrit en Clojure qui permet une gestion extrêmement flexible du flux d’événements qui le traverse du fait que son fichier de configuration est un vrai mini-programme. Il est utilisé au CC-IN2P3 pour effectuer des agrégations dynamiques, des seuillages de métrique et traiter les abonnements synchrones. Ce dernier point permet à un utilisateur de s’abonner à un flux d’événements grâce au protocole websocket, et ceci avec une latence très faible (quelques millisecondes). On peut le voir comme un tail -f
centralisé pour les logs.
La vie d’un événement dans COLOSS
Pour mieux comprendre la fonction de COLOSS, nous allons suivre la vie d’un message, depuis sa source jusqu’à l’utilisateur final. Prenons l’exemple du message suivant, qui est émis par un pilote du noyau Linux d’un serveur dans la nouvelle salle machine de Villeurbanne :
L’événement est capturé par syslog-ng grâce à la directive de son fichier de configuration qui lui indique d’intercepter les "logs" système. Il est ensuite enrichi avec des informations propres au CC-IN2P3 (nom du "datacenter", position dans l’armoire, fonction du serveur, etc.). La suite comprend le passage dans un système d’analyse syntaxique de syslog-ng (patterndb) qui permet de classifier le message et de le structurer en extrayant des couples clé/valeur. Pour l’exemple précis, on extrait les valeurs concernant le nom du disque impacté (sdb) et le numéro du secteur (42). Pour l’heure, le message a évolué et ressemble à :
Il est ensuite passé en revue par plusieurs filtres qui permettent de choisir le ou les chemins précis prévus pour cet événement particulier. En l’occurrence, il s’agit d’une erreur sérieuse de type matérielle, et l’événement est donc acheminé vers Nagios, qui est le système d’alerte et de notifications du CC-IN2P3. En outre, comme tous les événements, il est aussi aiguillé vers Elasticsearch pour le stockage et l’indexation long terme, et Riemann pour la partie faible-latence ("temps réel"). En dernière étape, Riemann achemine notre événement dans un navigateur exécuté sur une machine de la "control-room", et apparaît avec une couleur rouge (événement critique) sur un des trois grands écrans, bien visible par l’utilisateur final censé alerter le service concerné. L’événement sera aussi visible pendant un an lorsqu’une personne effectuera une recherche dans Kibana, pour autant qu’il corresponde aux critères de recherche.
La suite
Bien que la nouvelle plateforme de gestion des logs permette le passage à l’échelle en multipliant le nombre de serveurs, il reste la problématique de gestion du contenu. En effet, la quantité de données ne cesse de grandir avec les infrastructures et les projets des chercheurs pour lesquels elles sont mises à disposition. L’analyse syntaxique est statique, dans la mesure où les différentes règles d’analyse sont confectionnées par des humains. Et c’est bien cette partie qui ne grandit pas aussi vite que le reste : le personnel du CC-IN2P3 ! Par conséquent, il est urgent de trouver une solution pour automatiser ce processus. Nous réfléchissons actuellement à un système d’apprentissage automatique qui permettrait d’aller dans ce sens en mettant en évidence automatiquement des tendances dans l’évolution des données, et aussi en prédisant l’état des services : la météo du CC-IN2P3 ! "Demain, il fera beau en salle machine et peu de pannes se manifesteront en salle. Cependant, après-demain il risque d’y avoir une panne du service X avec une probabilité de 43%". Une collaboration avec d’autres sites est prévue dans ce sens, dont le GSI de Darmstadt, qui a déjà effectué des recherches dans le domaine.
Publications
La phase de développement du projet a été jalonnée par plusieurs présentations lors de conférences internationales (IEEE HPCMASPA 2014, Open Academy October 2014, HEPiX Spring 2016) et d’événements nationaux ou encore locaux (Elasticsearch Lyon User Group Mars 2015, AG Aramis Avril 2016, Clojure User Group Juin 2016). Les articles suivants ont été publiés et concernent chacun un aspect précis de l’architecture :
Fabien WERNLI (CC-IN2P3)
