7.3 ELK : Une couche multi-usages
7.3.5 Une architecture modulaire
L’architecture des différents composants de la solution ELK définissent quel niveau de redondance et de performance l’ensemble va avoir. La solution la plus simple consiste à mettre en place une instance de chaque logiciel (Fig 7.6).
Fig 7.6 – Architecture Simple de ELK
Cette architecture simple est bien appropriée pour effectuer des tests rapidement. Cependant elle n’est pas très adaptée à une architecture de production pour plusieurs raisons :
• On ne peut pas forcément installer Logstash sur tous les équipements. En effet, les baies et switchs SAN sont des équipements propriétaires où l’administrateur n’as pas accès au système sous-jacent.
• Logstash est bien adapté pour être déployé sur des serveurs afin de lire et de retransmettre les logs systèmes ou applicatives. Cependant, si on utilise le protocole SYSLOG cela impliquerait de configurer celui-ci différemment sur chaque équipement afin de définir chaque instance de Logstash comme destination SYSLOG.
Chapitre 7. La surveillance de l’infrastructure 7.3. ELK : Une couche multi-usages
Afin de résoudre certains de ces problèmes, on peut mettre en place une architecture différente (Fig. 7.7) :
Fig 7.7 – Architecture SYSLOG de ELK
Cette architecture découpe Logstash en deux parties et introduit Redis [11] entre les deux. Redis est un dépôt de structures de données. Il est souvent utilisé comme cache pour des bases de données ou comme logiciel de file de message au même titre que RabbitMQ.
• Une partie “shipper” centralisée ayant la responsabilité de récolter et retransmettre les événe- ments vers Redis. Ces événements peuvent alors provenir d’autres Logstash installés sur des serveurs ou directement arriver via SYSLOG. L’avantage est que chaque équipement utilisant SYSLOG sera configuré de la même manière. Cette partie réalisera le moins de traitement possible sur les événements.
• Une partie “indexer” centralisée ayant la responsabilité de récupérer les événements dans Redis, effectuer les traitements des événements et envoyer le tout vers Elasticsearch.
Cette architecture a le principal avantage de permettre de ne pas perdre de messages en cas d’in- disponibilité d’Elasticsearch. En effet, si Elasticsearch venait à être indisponible, l’indexer n’enverrait plus de messages et ne lirait plus de messages en provenance de Redis. Redis continue cependant à se remplir de messages en provenance du “shipper”. Le shipper ne se bloquera donc plus et les événements utilisant SYSLOG comme protocole ne seront plus perdu. Au redémarrage d’Elasticsearch l’indexer commencera à traiter les messages en attente dans Redis. Redis étant spécifiquement conçu pour ce type d’utilisation il peut stocker un très grand nombre de messages sans impacter ses performances.
Chapitre 7. La surveillance de l’infrastructure 7.3. ELK : Une couche multi-usages
Afin de rendre cette architecture complètement redondante il ne reste plus qu’à multiplier les instances de chaque composants et les relier entre eux (Fig. 7.8).
Fig 7.8 – Architecture redondante SYSLOG de ELK
Il reste cependant deux problèmes à résoudre dans cette architecture. Les deux se situant au niveau des points d’entrées SYSLOG dans les shipper Logstash :
• Certains équipements n’acceptent qu’une destination SYSLOG.
• Ceux qui en acceptent plusieurs envoient le même événement aux deux destinations.
Ces problèmes peuvent être résolus en réutilisant des composants de l’architecture des contrôleurs OpenStack (Fig. 5.7). C’est-à-dire utiliser une unique adresse IP virtuelle (VIP) via keepalived et utiliser Linux Virtual Server [10] sur chacun des serveurs hébergeant shipper Logstash afin de répartir la charge. LVS sera choisi pour la simple raison que celui-ci supporte aussi la répartition de charge du protocole UDP alors que HAProxy ne supporte que le protocole TCP.
Chapitre 7. La surveillance de l’infrastructure 7.3. ELK : Une couche multi-usages
7.3.6 Bilan
La centralisation des événements est un élément essentiel pour faciliter la détection, la classification et l’analyse de ceux-ci. Parmi les protocoles les plus connus, grâce à sa souplesse et à ses éléments de normalisation, le protocole SYSLOG parait le plus adapté à être utilisé pour transférer des événements.
Une fois le transfert des événements effectués, le couple Logstash et Redis est d’une grande utilité. Il permet de normaliser les événements qui ne le sont pas déjà et enrichir ceux-ci. De plus, via le nombre impressionnant de modules, Logstash permet de récupérer des événements provenant d’autres sources ne supportant pas le protocole SYSLOG. Redis quant à lui permet d’assurer une grande disponibilité de l’architecture et d’éviter les pertes de messages lors d’indisponibilités du moteur de stockage Elasticsearch.
Le stockage d’une grande quantité de données est relativement aisé. Cependant, la consultation d’une grande quantité de données peut être une tâche difficile. Il faut pouvoir répondre aux demandes de recherches dans un temps raisonnable. Il ne serait pas envisageable de stocker une telle quantité dans une base de donnée traditionnelle. Elasticsearch est spécifiquement conçu pour répondre à ce type de cas d’usage. Son architecture interne en fait un moteur de recherche très performant, tout en garantissant la future croissance des données ainsi que la redondance nécessaire à un système de surveillance. Son API simple et standardisée permet d’effectuer des requêtes complexes tout en garantissant des temps de réponses raisonnables pour les utilisateurs.
Le portail web Kibana est un plus appréciable et facilement abordable par des utilisateurs n’étant pas des développeurs. Il permet de générer très rapidement des rapports visuels mettant en exergue les événements importants parmi une très grande quantité de données.
Je vais à présent présenter l’architecture de surveillance en place au sein du service responsable du stockage. Nous allons voir pourquoi le projet de substitution de celui-ci par la couche logicielle ELK a été initié et réalisé. Je vais aussi aborder l’accostage de cette surveillance avec le projet de service d’infrastructure OpenStack.
C h a p i t r e