racdata, une solution big data d’analyse de logs pour l

Racdata, une solution big data d’analyse delogs pour l’exploitation d’un datacenter

Gwendan ColardelleAcadémie de Nancy-Metz10 rue Santifontaine54035 Nancy

Michaël CoquardAcadémie de Nancy-Metz10 rue Santifontaine54035 Nancy

Tiana RalambondrainyAcadémie de Nancy-Metz10 rue Santifontaine54035 Nancy

Stéphane UrbanovskiAcadémie de Nancy-Metz10 rue Santifontaine54035 Nancy

RésuméRacdata est une solution big data de collecte et d'analyse de logs (et de toutes données événementielles)conçue par l'Académie de Nancy-Metz pour la supervision du datacenter national du ministère del'éducation (2000 équipements et serveurs). Cette solution a été construite autour de plusieurs logicielslibres, en particulier de la suite Elastic (Elasticsearch, Logstash, Kibana) et du gestionnaire de messagesRabbitMQ.

Ces logiciels peuvent être mis en œuvre rapidement dans une configuration simple par défaut. Cependant,ils nécessitent une connaissance de leur fonctionnement et une configuration avancée dans le cadre deleur utilisation en production avec des contraintes fortes de disponibilité. De plus, leur bonneconfiguration est également essentielle pour produire des données de qualité exploitables par les équipesmétier.

Nous présentons notre retour d’expérience de 5 ans d'exploitation de cette solution à l’échelle d’undatacenter, en précisant nos optimisations et paramétrages spécifiques mis en place. Le choixd'architecture et les optimisations techniques ont un impact significatif sur les performances, la qualitédes données et leur intégrité (nous traitons plus de 4000 événements par seconde). Le choix desprotocoles et des formats des événements est important pour la collecte, la transmission et le stockage deces événements.

Enfin, nous exposons une liste de bonnes pratiques techniques et organisationnelles pour utiliser ce typede solution dans un contexte big data, en académie ou en université.

Mots-clefsBig data, logs, exploitation, retour d’expérience, Elastic, Logstash, Kibana, Elasticsearch, RabbitMQ.

JRES 2017– Nantes 1/15

1 Présentation du projet

1.1 Contexte

Le Ministère de l’Éducation dispose d’un datacenter national : la Plate-forme d’Hébergement Mutualisé(PHM). Ce datacenter a pour vocation d’héberger les applications nationales centralisées du ministère. Ilhéberge notamment SIRHEN1, l'application RH du ministère. L’organisation associée, le Centre Nationalde Service, est une répartition par domaines de responsabilités : réseau, hébergement, supervision,applications. Le rectorat de Nancy est responsable de la supervision de la PHM. Pour mener à bien cettemission, il a mis en place un ensemble de solutions, parmi lesquelles Racdata pour le traitement desdonnées événementielles produites par l'ensemble de l'infrastructure et des applications hébergées sur ledatacenter : messages de logs, traps SNMP, événements de supervision, etc.Quelques chiffres :

• 2 sites physiques ;• 2 000 équipements d’infrastructure (réseau, stockage...), serveurs physiques et virtuels ;• 35 applications ;• 900 000 utilisateurs, agents de l'Éducation Nationale ;• 200 millions d'événements par jour (soit une moyenne de 2 300 événements par seconde) ;• 3 milliards d'événements indexés sur une moyenne de 14 jours ;• 6 To de données événementielles (réplication double incluse) sur une capacité totale de 48 To.

Si l'article présente succinctement les utilisations du projet, nous avons mis l'accent sur les difficultéstechniques et les solutions trouvées pour gérer charge dans un contexte industriel.

1.2 Cahier des charges

La solution mise en place a dû répondre aux objectifs suivants :• centraliser la collecte de toutes les données événementielles (applications et équipements) ;• construire une architecture en haute disponibilité ;• permettre la recherche rapide des événements (ordre de grandeur de la seconde) dans le cadre

d'une investigation sur incident ;• permettre aux maîtrises d’œuvre et d’ouvrage de disposer de tableaux de bord donnant une

vision globale en temps réel du système d’information ;• proposer un temps de rétention suffisant pour permettre le traitement analytique des données ;• s'intégrer de manière transparente avec les applications existantes (faible impact sur les

performances, pas de complexification des traitements métiers, peu de dépendances logicielles,intégration dans les processus de déploiement) ;

• être capable de générer des alertes en temps réel sur dysfonctionnement ;• permettre la gestion et le suivi des droits d'accès en consultation des données pour les personnels

habilités (identification, authentification et autorisation) ;• conserver les événements dans le cadre légal sur une durée d'un an ;• s'intégrer avec les outils existants des équipes d'infrastructure (vCenter, SIEM…).

1. Système d’Information des Ressources Humaines de l’Éducation Nationale


La solution présentée répond à un cas d’usage du big data : les usages sont variés (Variété), la quantité dedonnées à traiter est importante (Volume), les données arrivent, sont traitées et affichées en temps réel(Vélocité).

1.3 Exemples d'utilisation

Nous utilisons Racdata pour : • vérifier le bon fonctionnement de l’infrastructure de messagerie lors des campagnes de diffusion

mail du ministère (plus d’un million d’abonnés) ;• renforcer la sécurité et détecter des flux illégitimes (SSH sortant...) ;• suivre des flux des équipements réseau ;• remonter des erreurs applicatives pour corriger des applications (ex. Sirhen) ;• suivre en temps réel l’usage d’une application (nombre d’utilisateurs, fonctions utilisées...) ;• identifier l’origine d’incidents survenant sur les applications, etc.

Figure 1 - Tableau de bord de la supervision intégré de Racdata

2 Architecture

La figure 2 présente le fonctionnement générale de la solution : les événements sont collectés depuis leurssources. Ils sont ensuite analysés et stockées afin de pouvoir être consultés facilement depuis uneinterface utilisateur.

Figure 2 - Architecture fonctionnelle


Collecte

Analyse

Stockageet

indexation

IHM

Syslog

SNMP

JBoss

Windows

Sourcesd'événements

SMTP

2.1 Sources d’événements

Nous collectons les événements en provenance de plusieurs sources variées :• les logs système des serveurs Linux RHEL (environ 65 % des équipements) via l’agent

Rsyslog2 ;• les logs système des serveurs Windows (environ 7 % des équipements) via l’agent NXLog3 ;• les traps SNMP et les logs systèmes des équipements d’infrastructure : routeurs, commutateurs,

répartiteurs de charge, baies de stockage... (environ 28 % des équipements) ;• les logs applicatifs des serveurs JBoss via Log4j2 (appender AMQP) ;• les courriels des serveurs SMTP (bounce) ;• les événements de supervision Nagios via des scripts « event-handler » et un plugin « broker ».

2.2 Choix des briques logicielles

Notre choix s’est porté sur les logiciels désormais populaires de la pile Elastic (anciennement « ELK »)pour leur flexibilité et leur licence libre :

• Elasticsearch4 5 pour le stockage et l’indexation des événements ;• Kibana5 5 pour l’interface graphique de recherche de tableaux de bord ;• Logstash6 5 pour la collecte, l’extraction, la structuration et l’enrichissement des événements.

Logstash ne propose que depuis très récemment un mécanisme de gestion de files de messages (depuis laversion 5.1). Nous utilisons donc un gestionnaire de files de messages externe qui a l’avantage d’être libretout en étant extrêmement robuste et compatible nativement avec Logstash : RabbitMQ7.Logstash propose beaucoup de protocoles reconnus nativement et est extensible à l’aide de plugins JRuby.Dans notre cas, nous avons développé un plugin pour l’enrichissement des événements via une base Rediset pour le décodage d’un format d’événement propriétaire.

2. http://www.rsyslog.com

3. https://nxlog.co

4. https://www.elastic.co/products/elasticsearch

5. https://www.elastic.co/products/kibana

6. https://www.elastic.co/products/logstash

7. https://www.rabbitmq.com


http://www.rsyslog.com/

https://www.rabbitmq.com/

https://www.elastic.co/products/logstash

https://www.elastic.co/products/kibana

https://www.elastic.co/products/elasticsearch

https://nxlog.co/

2.3 Processus de traitement des événements

La Figure 3 présente le cheminement d’un événement à travers la solution. Chaque événement estatomique et traité de manière totalement indépendante des autres événements ce qui facilite la répartitionde la charge.

Figure 3 - Parcours d’un événement à travers les processus de traitementLes étapes de traitements sont les suivantes :

1. Les événements (quel que soit leur protocole) sont collectés par une instance Logstash. Cetteinstance effectue très peu de traitements afin d’être très rapide (jusqu’à 20000 événements parseconde) ;

2. Les événements sont envoyés à RabbitMQ8 qui les stocke dans une file de messages ;

8. Bien qu’il n’y ai qu’un seul processus RabbitMQ au sens OS, celui-ci est représenté plusieurs fois pour des raisons de lisibilité.


Logstash« collect »

RabbitMQ

Kibana

RabbitMQ

Logstash« analyse »

Elasticsearch

Logstash« DB »

Sourcesd’événements

Serveurs de collecteet d’analyse

Serveurs d’indexationet de présentation

DNSGeoIPCMDB...

Syslog TCP/UDP, traps SNMP, Log4j2, NXLog (Windows), Nagios, SMTP.

Logstash« archive »

Fichiers plats

Baie de stockage NFS

Applicationsspécialisées(stats. Web,SIEM...)

5

1

2

3

4

3. Des instances Logstash réparties sur plusieurs serveurs consomment les événements de la file eteffectuent les opérations d’analyse :◦ découpage des messages bruts ;◦ validation du format et typage (nombre entier ou flottant, conversion des dates au format

ISO 8601...) ;◦ normalisation des champs (regroupement de champs ayant des noms différents mais

contenant la même information) ;◦ enrichissement via des sources de données externes (DNS, CMDB9, GeoIP...). Des champs

sont créés dans l’événement pour ajouter les informations récupérées.4. Les événements sont envoyés à RabbitMQ qui les duplique vers plusieurs files de messages, une

par destination :◦ vers un archivage sous forme de fichiers plats compressés (taux de 95 % en gzip) à durée de

rétention longue (1 an légal) ;◦ vers les serveurs d’indexation (Elasticsearch) ;◦ vers des applications pour des traitements spécialisés comme les statistiques Web (Piwik,

AWStats) et la détection des anomalies (SIEM).5. Les utilisateurs peuvent effectuer des requêtes sur Elasticsearch via l'interface graphique Kibana

ou utiliser directement son interface REST (voir la partie sur la sécurité).

9. Configuration Management Database


2.4 Architecture physique

Les processus de traitement sont redondés en mode actif-actif afin de répartir la charge et d’assurer unemeilleure disponibilité du service (Figure 4).

Figure 4 - Architecture physique, répartition des processus et de la collecteVerticalement, nous avons effectué cette répartition en deux groupes de serveurs en tenant compte duprofil de charge :

• les serveurs de collecte et d’analyse supportent les opérations lourdes de traitement temps réel(extraction et structuration…). Ils supportent une activité continue mais sont aussi capablesd’absorber les pics d'activité à travers les files d'attente ;

• les serveurs d’indexation et de présentation qui supportent la base de données et l’interfacedoivent être réactifs lors des requêtes des utilisateurs. Ils disposent aussi d’une grande quantitéde stockage local pour les données indexées.

Horizontalement, nous avons défini des couples de serveurs pour chaque niveau de service :• production : équipements d’infrastructure, serveurs en production, etc. ;• hors-production : serveurs de pré-production, de qualification etc. ;• réseau : équipements réseaux qui produisent beaucoup d’événements similaires (pare-feux…).


Serveursde collecteet d’analyse

Serveurs d’indexationet de présentation

Sourcesd’événements

ES

LS

ES

LS

ES

LS

ES

LS

KiKi

RMQ

LS

LS

RMQ

RMQ

LS

LS

RMQ

RMQ

LS

LS

RMQ

RMQ

LS

LS

RMQ

Adresse IP« production »

Adresse IP« hors-production »

Adresse IP« réseau »

ES

La séparation des flux s'effectue à plusieurs niveaux :• lors de la collecte : une adresse IP virtuelle attribuée en mode actif-passif est réservée pour

chaque niveau de service ;• lors de l'analyse : des files d'attentes sont dédiées à chaque niveau de service. En sortie de ces

files, les événements sont distribués en mode « round-robin » vers les processus d'analyse ;• lors de l'indexation : des index10 sont dédiées à chaque niveau de service.

Nous avons utilisé cette organisation afin d’isoler simplement les flux de messages et réduire l'impact despics d'activité entre les niveaux de service.Cependant, les serveurs de collecte et d'analyse peuvent tout de même partager leurs ressources entreplusieurs niveaux de service (pour les flux « hors-production », moins prioritaires). Nous utilisons uncluster Elasticsearch unique pour faciliter la consultation et le croisement des données.Un cinquième nœud Elasticsearch hébergé sur un troisième site permet l'arbitrage en cas de split-brain.Ce nœud ne stocke pas de données.L' architecture est extensible en cas de besoin en ajoutant des serveurs d’analyse ou d’indexation.

3 Optimisations et préconisations techniques

Durant la conception et l'exploitation de Racdata, nous avons effectué des optimisations qui ont un impactnon négligeable sur les performances et sur la qualité de l'analyse.

3.1 Performances

3.1.1 Parallélisme et VirtualisationElasticsearch, Logstash et RabbitMQ exploitent pleinement une architecture multi-cœur. Nous avons doncutilisé des machines physiques qui disposent d'un grand nombre de CPU (total de 20 cœurs). Nousutilisons des machines virtuelles dans le cas d'un déploiement sur des petits environnements (équipe dedéveloppement par exemple).

3.1.2 Optimisation des expressions régulièresLa quasi totalité des événements collectés sont des messages de log au format « Syslog » (plus de 99 %en nombre de messages dont 90 % pour les équipements réseaux). Ceci pose plusieurs difficultés :

• Les constructeurs de matériels ne respectent pas toujours les RFC11 ;

• La partie « utilisateur » du message contient parfois elle-même une structure à analyser ;

• Le message n'est pas structuré pour être analysée algorithmiquement.Logstash fournit un mécanisme générique et flexible pour le découpage des messages (appelé « Grok »)qui s'appuie sur l'utilisation d'expressions régulières. Celles-ci doivent être optimisées avec soin pouréviter les backtracking catastrophiques qui peuvent ralentir ou même bloquer le traitement desévénements. En effet, l'implémentation du moteur d'expressions régulières joni utilisée par Logstashn'utilise pas d'automates déterministes (l'article [1] en présente une implémentation).Par exemple, nous avons pu gagner environ 5 ms de traitement par message en réécrivant la règlesuivante (découpage des messages de logs d'un pare-feu Stonesoft) :

# CEF:0|McAfee|Firewall|5.8.0|50000|Connection_Discarded|0|msg...# Version initialeCEF:(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)# Version optimiséeCEF:([^|]*)\|([^|]*)\|([^|]*)\|([^|]*)\|([^|]*)\|([^|]*)\|([^|]*)\|\|([^|]*)

10. Un index Elasticsearch correspond à une zone de stockage indépendante.

11. RFC 3164 « syslog BSD » ou RFC 5424


Ceci représente un gain global de 13 % sur la vitesse de traitement en temps réel des événements.Nous avons pu mettre en évidence d'autres cas moins triviaux en mettant en place une supervision sur letemps d'analyse de chaque événement (ajout d’un champ dédié avec tableau de bord dans Kibana).L’impact de cette supervision est négligeable.Enfin, lorsqu’il est possible de configurer un format de message de log dans une application (ApacheHTTP...), il faut toujours concevoir ce format pour qu’il puisse être interprété efficacement et sansambiguïté : échapper les caractères, utiliser des préfixes, ne pas stocker deux champs identiques à lamême position etc.

3.1.3 Gestion de la mémoirePar défaut, le système d'exploitation RHEL active le mécanisme « Transparent Huge Pages » (THP) quipermet d'économiser de la mémoire en la défragmentant sous forme de huge pages. Cependant, lesmachines virtuelles Erlang (RabbitMQ) et Java (Logstash, Elasticsearch) fragmentent la mémoire(beaucoup d’appels à mmap()) ce qui force le mécanisme THP à ralentir l'ensemble des processus. Cephénomène est d’autant plus fort avec une quantité de RAM élevée (dans notre cas, 64 Go par serveur).Nous avons observé des diminutions de la vitesse de traitement allant jusqu’à 300 %.Le problème a été résolu en désactivant totalement THP dans les paramètres du noyau et en allouant leshuge pages manuellement.

3.1.4 Stockage des files d'attentesToutes les files d'attentes sont stockées sur disque. En effet, celles-ci sont très rapides en raison del'utilisation intensive du cache disque (très bien géré sur les OS modernes). Elles permettent de stockerune grande quantité de données contrairement à l'utilisation de la RAM seule. De telles files d’attentespeuvent traiter 20 000 messages de 1 ko par seconde sur une seule thread et stocker plusieurs millions demessages en cas de congestion ou d’indisponibilité d’un processus d’analyse.Des files de ce type sont proposées depuis la version 3.6 de RabbitMQ12.

3.2 Contrainte temps réel

Pour disposer des données le plus rapidement possible après leur collecte, il est nécessaire de minimiser lalatence de traitement et de savoir détecter les points de contention.

3.2.1 Enrichissement des événementsPour enrichir les événements sans bloquer ou ralentir leur traitement, nous utilisons plusieurs mécanismesde cache (LRU13 en RAM, rafraîchissement périodique d’un cache Redis). Le mécanisme de cache choisidépend du compromis à faire en cas d’indisponibilité des sources de données :

• rafraîchissement asynchrone : aucune latence ;• timeout très faible : latence faible et interrogation de la source de données à la demande ;• « push » des modifications en mémoire : aucune latence et mise à jour immédiate.

3.2.2 Priorisation des fluxDans notre cas, la priorisation consiste en une séparation des flux couplée à un mécanisme de « round-robin ». Ainsi, les événements des files d'attentes chargées sont naturellement traités avec une prioritéplus faible. Ce mécanisme a l'avantage de ne pas dégrader les performances tout en étant simple à gérer.De plus, il couvre la plupart des situations de congestion.Pour les situations plus complexes, l'utilisation de files d'attentes de grande capacité et supervisées entemps réel (100 Go par serveur soit environ 100 millions d'événements) nous permet d'intervenirmanuellement à temps.

3.3 Format et qualité des données

3.3.1 Format unique et structuré des événementsNous avons défini un format unique pour tous les événements échangés entre les processus. Ce formatest basé sur une structure hiérarchique de clé-valeurs optionnelles et dont le chemin est fixe. L'objectif estd'obtenir les propriétés suivantes :

• l'unicité du traitement : tous les processus d'analyse (quelque soit leur niveau de service) peuvent

12. Ce type de files existent aussi sur Kafka et Rsyslog (files « disk »).

13. Least Recently Used : l'entrée du cache la moins récemment utilisée est remplacée en priorité.


traiter n'importe quel événement. Ainsi, il est plus simple de modifier l'architecture pour adapterla capacité de traitement (ajout de processus d'analyse, déplacement d'une adresse de collecteetc.) ;

• la spécialisation des champs : les valeurs de nature différente (par exemple, une adresse IP et unhostname) sont stockés dans des champs différents afin de faciliter leur typage, leur dé-duplication et leur traitement. Si une valeur n'est pas présente, le champ correspondant n'est pascréé ;

• la dé-normalisation : lorsque cela est nécessaire, plusieurs champs peuvent être créés pourstocker la même information sous des formats différents. Par exemple, une URI complète peutêtre stockée dans un champ et les composants de son chemin dans un autre. Dans certains cas, unchamp peut être ajouté pour regrouper les valeurs de plusieurs autre champs afin de faciliter lesrequêtes. Par exemple, l'adresse IP d'un client HTTP n'est pas présente dans le même champ si leserveur web qui a produit l'événement se trouve derrière un répartiteur de charge ou si il est situédirectement en frontal ;

• le regroupement hiérarchique : les données d'un même événement ayant des relations entre-ellessont regroupées dans une même branche afin de pouvoir les traiter de manière atomique. Parexemple, un événement contenant les données d'un message de log Apache HTTP possède unebranche nommée « apache » ;

• l'extensibilité : lorsque de nouveaux formats doivent être implémentés, de nouveaux champs sontsimplement ajoutés. Il n'y a pas de règle fixe sur le nommage des nouveaux champs (mais il fautéviter un conflit avec les noms existants) ;

• la conservation des informations d'origine : toutes les informations de l'événement d'origine sontconservées soit sous forme brute, soit sous forme découpée (si elles sont suffisantes pourreconstituer l'événement d'origine) ;

• l'idempotence : tous les événements peuvent être rejoués à travers les processus d'analyse enutilisant les informations d'origine stockées dans l'événement. Aucun champ n'est renommé lorsdu processus d'analyse ;

• l'ouverture et la lisibilité : le format de sérialisation JSON14 est utilisé afin de rendre lisiblel'événement par un être humain tout en conservant de bonnes performances de traitement.

14. JavaScript Object Notation, http://json.org


http://json.org/

Voici un exemple d'événement (certains champs sont omis pour plus de lisibilité) :

{ […] "firewall":{ "source":{ "ip":"172.16.0.1", "port":26362 }, "destination":{ "ip":"172.16.0.2", "port":53 } }, "syslog":{ "ip":"172.16.0.3", "severity":{ "code":5, "label":"notice" }, "facility":{ "code":23, "label":"local7" } }, "message":"traffic DNS start from 172.16.0.1 to 172.16.0.2", […]}

Pour les échanges internes vers les files de messages, nous couplons ce format au protocole de transportAMQP15 natif à RabbitMQ, qui fournit un mécanisme d’acquittement applicatif (sémantique at leastonce), de chiffrement (TLS) et d’authentification.

3.3.2 Indexation, typage et normalisation des valeurs de champsElasticsearch stocke les données en utilisant le mécanisme d’index inversé fourni par Lucene16. Cetteforme de stockage est efficace à condition de choisir un type optimal pour les valeurs des champs (gain enespace de stockage et accélération des opérations de comparaisons) et de minimiser le nombre de valeurspossibles par champ (gain en espace de stockage, chaque valeur différente étant stockée en unexemplaire).Ainsi, de manière systématique :

• les valeurs similaires sont regroupées par conversion idempotente ou table de correspondance.Par exemple, CRITICAL et critical sont fusionnées en critical (lowercase) ;

• lorsque ceci est possible, les chaînes de caractères sont normalisées et converties vers les typesnatifs proposés par Elasticsearch (nombres, dates, booléens...). Par exemple, la valeur "42"sous forme de chaîne de caractères est convertie en nombre entier 42.

3.3.3 HorodatageLes horloges des serveurs de collecte et des sources d'événements doivent être synchronisées (via NTP)afin de retrouver l’ordre correct des événements.Logstash et Elasticsearch proposent par défaut l’utilisation du format ISO8601 qui permet de sérialiser lazone de temps. Ce format doit être utilisé en priorité pour éviter les situations de décalage lors duchangement d’heure ou pour la collecte des événements dans d’autres zones géographiques (DOM-

15. Advanced Message Queuing Protocol

16. Bibliothèque Java de moteur de recherche full-text développée par la fondation Apache, https://lucene.apache.org


https://lucene.apache.org/

TOM…).

3.3.4 Formats structurés et multi-lignesCertaines applications peuvent générer des messages de log contenant plusieurs lignes. Or souvent, cesmessages sont stockés dans des fichiers plats puis relus par un agent tel que Rsyslog. Dans ce cas, chaqueligne sera traitée comme un événement indépendant et il sera difficile voire impossible de rattacher ceslignes entre elles (l’ordre étant perdu si leur timestamp est le même).Lorsque cela est possible, l’application doit être configurée pour exporter ses messages de log dans unformat sérialisé ou utiliser un protocole qui supporte le framing sans passer par l’écriture d’un fichier.Dans notre cas, nous préconisons l’utilisation d’AMQP et notre format unifié d’événement. Nousexportons les messages de log des serveurs JBoss de cette manière (utilisation de JSONLayout etAmqpAppender sous Log4j2). Ainsi, les stacktraces Java restent structurées et sont stockées dans unévénement unique...

3.4 Intégrité des données

3.4.1 Contrôle de flux des sources d'événementsLorsqu’une source d’événement envoie ses données aux serveurs de collecte, ceux-ci peuvent ne pas êtredisponibles (problème réseau, processus de collecte saturé). Dans ce cas, il est nécessaire de trouver uncompromis entre :

• perdre les événements. Ceci est le seul choix possible pour les équipements qui utilisent leprotocole UDP. Augmenter la taille par défaut de réception du buffer UDP17 diminue grandementles pertes ;

• stocker les événements pour leur retransmission ultérieure. Ceci est possible sur certainséquipements et sur les serveurs (en configurant des files de messages dans Rsyslog et NXLog)mais en limitant la taille des données stockées.

Dans tous les cas, il ne faut jamais bloquer le processus qui génère l’événement pour éviter un effet deréaction en chaîne qui risque de ralentir ou bloquer les services métiers.

3.5 Sécurité

Elasticsearch ne possède par défaut aucun mécanisme d’authentification et de gestion des droits :n’importe qui ayant accès au port TCP 9200 ou 9300 peut effectuer n’importe quelle opération sur uncluster Elasticsearch ! (récupération ou suppression de toutes les données...)Cette fonctionnalité est proposée officiellement sous la forme d’un plugin sous licence propriétaire18.Pour une petite installation, il est possible d’utiliser un reverse-proxy mais celui-ci ne permet pas dedifférencier les droits des utilisateurs (il est difficile d’analyser le contenu des requêtes JSON).Nous avons d’abord utilisé la solution du reverse-proxy, avant de passer par un plugin dédié(ReadonlyREST puis Search Guard) qui permet d'authentifier les utilisateurs directement surElasticsearch lors des requêtes REST.Certaines fonctionnalités de ces plugins ne sont pas libres mais tous proposent au minimum uneauthentification HTTP « basic », une base d'utilisateurs interne (fichiers plats) et une séparation des droitspar index.D'autres méthodes d'authentifications et backends sont disponibles (suivant les plugins) : Kerberos, JSONweb token, LDAP...

3.5.1 Communications inter-processusToutes les communications entre les processus sont authentifiées, chiffrées et signées y compris entre lesmembres du cluster Elasticsearch.Cependant, les protocoles de collecte ne peuvent pas être tous sécurisés (Syslog en UDP) et nous nepouvons qu’utiliser des solutions de renforcement (réseau dédié, règles iptables et supervision).

3.5.2 Gestion des permissionsLorsqu’un utilisateur s’authentifie sur Elasticsearch (directement ou via Kibana), un filtre estautomatiquement appliqué à chacune de ses requêtes afin de n’afficher que les événements qui le

17. /proc/sys/net/core/rmem_max sous Linux

18. X-Pack


concerne.Pour faciliter cette tâche, nous ajoutons les groupes d’utilisateurs dans chaque événement parenrichissement.

3.5.3 AuthentificationL’authentification est centralisée dans un annuaire LDAP. Aucun compte générique n’est utilisé, ycompris pour les administrateurs (consultation des événements et connexions SSH).

3.5.4 AnonymisationLes informations sensibles présentes dans les événements peuvent être anonymisées (par hashage) ousupprimées par Logstash. Dans notre cas, nous utilisons cette possibilité pour hasher les noms desutilisateurs authentifiés et des adresses IP pour les événements des serveurs web.L'anonymisation ne concerne pas les événements archivés (qui ne doivent pas être altérés pour des raisonslégales).

4 Bonnes pratiques organisationnelles

Grâce à l’expérience acquise lors de l’exploitation de Racdata, nous avons identifié une série de bonnespratiques pour l’analyse des données événementielles.

4.1 En phase de développement et d’intégration

4.1.1 Conception des applicationsLes applications doivent être conçues et développées pour transmettre les informations de suivi deproduction dans leurs logs : les erreurs applicatives et les données métier à suivre (nombre d’utilisateurs,fonctions réalisées, transactions significatives, etc). Ainsi, ces logs peuvent directement être exploitéspour fournir une vue métier de l'application.

4.1.2 Intégration au processus de fourniture des environnementsLes configurations et les briques logicielles (agents) nécessaires pour la remontée des événements doiventêtre normalisées et intégrées au processus de fourniture des systèmes d’exploitation ou des applications(ex. machines virtuelles pré-configurées en mode PaaS ou SaaS).

4.2 En phase de production

4.2.1 Utilisation des référentiels d’enrichissementL'utilisation d'une base de donnée NoSQL impose quelques restrictions, notamment l'impossibilitéd'effectuer efficacement des jointures une fois les données stockées. Il est donc nécessaire dedé-normaliser19 et d'enrichir les événements en utilisant toutes les sources de données externes àdisposition :

• CMDB ;• serveurs DNS (résolutions inverses des adresses IP) ;• bases de données de géo-localisation (adresses IP des académies).

L’utilisation d’un référentiel contenant la description de tous les éléments du système d’information (ex.CMDB) est très utile pour localiser le contexte d’un événement (nom de l’application associée, plages demaintenance, niveau de criticité…) ou compléter des informations manquantes (adresses IP absentes duDNS).

4.2.2 Supervision de la solutionLe flux en entrée n’est pas prévisible. Des « tempêtes d’événements » peuvent survenir, par exemple pourles applications à campagnes (inscriptions, résultats d’examens) ou lors d’attaques réseaux (DDOS...).Ces augmentations brusques de trafic doivent pouvoir être détectées pour permettre une réaction adaptée :

• mise en attente des événements non prioritaires ;• filtrage des événements non légitimes ;• suspension de la collecte.

Dans notre cas, la priorisation est automatisée mais la mise en place du filtrage ou de la suspension est

19. Au sens « base de données »


décidée par une intervention humaine du fait de la diversité des situations possibles.

4.2.3 Montée de version des composantsLes produits utilisés (suite Elastic, RabbitMQ) sont puissants mais évoluent rapidement. Leur mise à jourdoit s’inscrire dans le processus de gestion des mises en production et des déploiements. Dans notre cas,nous intégrons tous les logiciels destinés à la production dans des paquets (RPM pour les serveursRedHat).L’architecture doit être conçue de manière à permettre des montées de version fréquentes sans coupure deproduction. Une architecture distribuée facilite cet objectif (attention à la cohérence des versions pour lesnœuds d’un même cluster Elasticsearch). Actuellement, l'ensemble de la configuration est centralisée viaun outil de gestion de versions (SVN) et le déploiement s'effectue depuis un serveur d'administration àl'aide de scripts. Cette solution est amenée à évoluer vers l'outil Ansible.

4.2.4 Suivi de l'évolution des SI20

Il convient de mettre en place un processus de suivi pour répondre rapidement à l'évolution des SI :• gestion du changement : ajout d'une application, modification des règles d'analyse, ajout d'une

source d'événements, mise en place d'alertes et de tableaux de bord etc. ;• gestion de la capacité : stockage supplémentaire, puissance de calcul...

4.2.5 Formation et promotion de la solutionIl est important que les utilisateurs puissent percevoir la plus-value de la solution et être autonomes pourexploiter pleinement leurs données métier (création des tableaux de bord, recherche d’informations...).C'est pour cela qu'une attention particulière doit être portée à la formation et à la promotion de la solutionà destination des exploitants voire de la maîtrise d’ouvrage : présentation, travaux pratiques, liste dediffusion, etc.Pour ce faire, nous proposons un accompagnement pour la prise en main permettant de faciliter l'adoptionde la solution et l'adaptation au contexte de l'utilisateur.

4.2.6 Tableaux de bordUn des tableaux de bord les plus rapides à mettre en place est celui indiquant l’audience des applicationsen exploitant les données générés par les serveurs web21 (Figure 5). Il indique le nombre de visiteurs entemps réel, et les pages visitées, la répartition par serveur sur les cluster web, etc.

Figure 5 - Audience des applicationsRacdata est aussi adapté pour offrir une vision temps réel de l’infrastructure de messagerie. Le tableau debord par défaut inclut : le nombre de messages envoyés en temps réel, l’activité SMTP, l’activité desrelais et les domaines en erreur.

20. Système d'information. Dans ce contexte, il s'agit d'une application et de son environnement (logiciel, matériel dédié,utilisateurs).

21. Access logs sous Apache HTTP et équivalents


Enfin, le tableau de bord le plus pertinent est celui indiquant des données métier d’une application entemps réel. Ce tableau de bord ne peut être mis en place que si l’application renseigne ces informationsrégulièrement dans les événements (logs applicatifs). Nous préconisons le suivi de trois typesd’informations :

1. les données du cœur de métier : nombre de dossiers en cours de consultation pour uneapplication de ressources humaines, nombre d’inscription, etc. ;

2. la mesure d’audience : nombre de personnes connectées, origine, etc. ;3. les erreurs : erreurs applicatives, page non trouvée, etc.

5 Conclusion

5.1 Bilan

Nous avons montré comment une solution d’analyse de données événementielles construite autour d'unebase open source pouvait être déployée à l'échelle d'un datacenter. Un telle solution apporte une plus-value certaine, pour le développement, pour l’exploitation et pour le pilotage, aussi bien pour lesapplications que pour les infrastructures en production. Cependant, une bonne expertise technique estindispensable pour sa conception et son administration.Enfin, la mise en place d’une telle solution est plus efficace en suivant les bonnes pratiques identifiées, dudéveloppement jusqu’à la phase de production.

5.2 Évolutions

Racdata est actuellement utilisé pour les applications nationales. Nous souhaiterions étendre ses servicesaux académies en développement une offre SaaS22. L'objectif sera de fournir un service homogène et derendre les utilisateurs entièrement autonomes : multi-tenant, ensemble de la configuration possible depuisune interface web, agents pré-configurés.Cette solution n'étant pas figée, nous la faisons évoluer régulièrement en ajoutant de nouvelles sourcesd'événements et en continuant à optimiser ses performances. Nous travaillons actuellement à l'intégrationdes données timeseries et du protocole sFlow.

Bibliographie

[1] Russ Cox. Regular Expression Matching Can Be Simple And Fast, Janvier 2007.https://swtch.com/~rsc/regexp/regexp1.html

22. Software As A Service


https://swtch.com/~rsc/regexp/regexp1.html

racdata, une solution big data d’analyse de logs pour l

Documents