Journaux ou "logs"

Une infrastructure comme celle du Centre de Calcul de l’IN2P3 comporte un grand nombre de serveurs, d’équipements réseau, d’appareillages électriques et climatiques afin de remplir sa mission de fournisseur d’infrastructure aux laboratoires et à la grille. Tous ces éléments génèrent un grand nombre de messages et d’informations techniques sur leur fonctionnement que l’on appelle respectivement journaux ("logs" en anglais) et métriques. Si l’on compte le nombre d’événements que produisent les 400 000 points de mesures, 2000 serveurs, 200 alimentations intelligentes, 50 climatiseurs et 10 onduleurs connectés, sans oublier le générateur, on arrive à près d’un milliard par jour.

La nouvelle infrastructure de gestion d’événements qui est à l’étude depuis près d’un an permet de traiter de manière semi-automatique ce flux d’informations à destination des personnels techniques du CC-IN2P3. Elle permet de répondre efficacement et avec une faible latence aux pannes logicielles et matérielles qui se présentent. En outre, un certain nombre de journaux doivent être conservés légalement pendant un an.

Exemple : Un disque dur tombe en panne

Pour mieux comprendre la fonction du système, suivons le chemin d’un événement à travers la nouvelle infrastructure. Un disque dur système d’un serveur tombe en panne : l’électronique embarquée dans le composant notifie le pilote du noyau Linux qui gère le matériel correspondant. L’interruption génère un message qui est reçu par le logiciel de collecte des événements (rsyslogd) du serveur. Voici son contenu sous forme brute :

2014-05-30T14:34:53 node01 ata2.00 : exception Emask 0x0 SAct 0xffff SErr 0x0 action 0x0

L’événement est ensuite transféré sur un analyseur distant via le protocole syslog. L’événement est ensuite normalisé selon un paradigme commun afin de figurer dans un catalogue intelligible. C’est le composant patterndb du logiciel syslog-ng [1] qui s’occupe de cette tâche : il transforme les informations textuelles du message d’origine en structure de données. Chaque événement se voit assigner au moins cinq valeurs caractéristiques :

 l’horodatage précis
 le service caractérisant le composant
 son état de santé
 l’hôte dont il émane
 sa date de péremption.

Ces cinq couples valeurs fondamentales ont pour fonction notamment de permettre à l’opérateur humain de discerner clairement les symptômes de pannes éventuelles, et de classifier les flux d’événements. Voici la forme normalisée de notre événement disque :

"timestamp" : "2014-05-30T14:34:53", "host" : "node01", "service" : "kernel-drivers/ata-2.00", "state" : "warning", "ttl" : 300 "kernel" : "type" : "exception", "emask" : "0x0", "sact" : "0xffff", "serr" : "0x0", "action" : "0x0"

Et ensuite ?

L’étape suivante est le transfert conditionnel simultané vers d’autres systèmes de traitement adaptés : analyse synchrone, stockage et indexation, alerte, etc. Selon des règles prédéfinies, l’événement est acheminé vers un ou plusieurs de ces systèmes d’infrastructure.

Le système d’analyse synchrone, implémenté grâce au logiciel Riemann [2], reçoit pour sa part la totalité des événements. Il permettra à un opérateur humain de visualiser en temps-réel le flux d’événements, en affichant dans un navigateur web les événements selon des critères de recherche pertinents. La latence de ce genre de visualisation est très faible (de l’ordre de quelques millisecondes) et permet un temps de réaction très rapide. Il est notamment utilisé dans la control room du CC-IN2P3. L’événement de notre exemple y apparaîtrait typiquement en jaune (warning) :

La totalité des messages est également acheminée vers le logiciel Elasticsearch [3] qui permet de les enregistrer de manière semi-permanente. Ce moteur de recherche distribué permet d’indexer les données de manière très ciblée, et permet de trouver des incidents parmi des millions en une fraction de secondes. Il est livré avec une interface graphique très puissante (Kibana) qui permet à l’opérateur d’explorer les journaux de manière intuitive, et notamment de faire une analyse post-incident extrêmement efficace en remontant dans le temps. Dans la copie d’écran suivante, l’ensemble des connexions par ssh d’une journée (8 millions de journaux) est représenté sous forme géographique :

D’autres systèmes sont également consommateurs d’un sous-ensemble des événements traités par syslog-ng, il s’agit par exemple de la messagerie, et de Nagios [4] qui est le système central de gestion des alarmes au CC-IN2P3.

Et les métriques ?

400 000 métriques sont collectées par intervalles réguliers au CC-IN2P3 en utilisant collectd [5]. Des seuils prédéfinis sont appliqués et peuvent déclencher des alertes via le même mécanisme que décrit précédemment, en utilisant Riemann. La différence avec les logs réside dans le fait que c’est le logiciel rrdtool [6] qui se charge du stockage historique, par opposition à Elasticsearch pour les logs. Il est envisagé d’utiliser un stockage commun dans l’avenir. La copie d’écran suivante illustre le suivi temps-réel des données de performance d’un serveur virtuel via l’interface web riemann-dash [ 2 ] :

FABIEN WERNLI