Beats, Logstash, Elasticsearch, Kibana… une gestion centralisé des logs en entreprises

De nos jours, toutes sociétés ayant un parc informatique sont soumises à la problématique de la gestion des logs. Que ce soit des serveurs, des applications, des sites ou du matériel. Avoir 3 serveurs et 2 applications ne nécessite pas une gestion spéciale. Mais il arrive à un moment où une gestion centralisée devient importante. De plus, l’arrivée du GDPR (RGPD) en Europe pourrait également être une raison supplémentaire de mettre une vraie gestion des logs dans une entreprise.

J’ai eu l’occasion d’étudier et de mettre en place une solution basée sur les produits gravitant autour de Elasticsearch de la société Elastic. Je vous propose dans la suite un retour d’expérience basé sur un mix de ce que j’ai eu l’occasion de faire, ce qui pourrais être mieux fait et surtout sur le pourquoi.

Beats, Logstash, Elactisearch, Kibana… c’est quoi tout ça ?

Elastic est une société proposant une suite de logiciels permettant entre autres la gestion des logs. Si les produits sont utilisables gratuitement, certaines options supplémentaires existent sous forme de licences annuelles.

Les beats sont différentes applications que l’on installe sur des machines qui seront chargées de récupérer des logs et des informations et de les envoyer aux sorties compatibles.

  • Filebeat qui lit les fichiers.
  • Metricbeat en charge de récupérer des indicateurs sur des serveurs (Systèmes d’exploitation, MySQL…)
  • Packetbeat pour récupérer des données réseaux.
  • Winlogbeat pour récupérer les logs se trouvant dans l’Eventviewer.
  • Auditbeat qui récupère des données du framework audit Linux.
  • Heartbeat qui va récupérer des données en faisant des tests de disponibilité des services.

Logstash est pour sa part un serveur qui sera en charge de récupérer les données de différentes sources (envoyées par des beats, lecture de syslogs….), de les traiter ou les filtrer si besoin et de les envoyer à une sortie pour par exemple le stockage ou l’envoi de messages.

Elasticsearch est pour sa part le système de stockage des données. Les beats, mais bien plus souvent Logstash lui enverront les données et les stockera. Bien sûr, c’est également ce système qui sera en charge de la recherche des données via les différents outils et API.

Kibana est l’interface qui permettra l’accès aux données via un navigateur web.

Bien sûr, il suffit de faire une recherche sur internet pour retrouver différents outils fonctionnant avec les outils ci-dessus. Que ce soit sous forme de plug-ins, comme surcouche ou tout simplement nouveau système fonctionnant avec.

Pourtant, c’est bien beau d’avoir des applications et des serveurs, mais il faut aussi et surtout savoir quoi envoyer à ces outils et comment le faire en diminuant les risques de perte.

Quels logs ?

Que ce soit les logs d’une machine Windows (Eventviewer), d’une machine Linux, les logs d’applications disponibles dans des fichiers, de matériel tels que des switchs, des firewalls, des routers… le nombre de sources peut vite devenir exponentiel. Qui dit sources différentes, dit systèmes de captation différents : lecture de fichiers, lecture de systèmes spécifiques, syslog…

Il faudra toutefois étudier et catégoriser les sources de logs en fonction du type, de leurs pérennités et de la quantité.

Syslog

Un cas le plus problématique va être la gestion du syslog. En effet, soit vous recevez et gérez le message, soit il est perdu à tout jamais. Et tout le monde sait qu’un log en temps normal n’est pas toujours utile, mais ça sera justement au moment ou quelque chose présentera un problème que les logs manqueront.  La mise en place de plusieurs niveaux de gestion sera alors nécessaire.

Il faut se rendre compte aussi qu’une solution idéale n’existe pas. Ainsi une coupure réseau directement après l’équipement empêchant toute communication avec le ou les serveurs stockant les logs verra les logs perdus. À moins qu’une solution de stockage locale puisse éventuellement prendre le relais. Mais attention à l’espace disque ou mémoire nécessaire. Mais des solutions existent pour réduire au maximum ce risque telles que le doublement des connexions physiques et des équipements réseau intermédiaires avec basculement automatique en mode actif/passif ou de façon transparente en cas de fonctionnement en mode actif/actif.

Une des premières solutions sera de doubler la destination des logs. Cela permettra d’éviter une perte de données si un des serveurs venait à poser problème. Mais cela ajoutera un problème supplémentaire, celle de la gestion des doublons au niveau stockage, mais surtout un doublement des ressources nécessaires que ce soit réseau ou de puissance afin de gérer ce double flux de logs. Éléments à prendre en compte dans le calcul. Pour les doublons, une gestion de ceux est possible au niveau de Logstash. Celui-ci qui sera d’ailleurs la destination des syslog via son plug-in input dédié à ce protocole que ce soit en TCP ou UDP.

Si la récupération des données a déjà vu une solution possible, il faut toutefois toujours gérer le stockage à proprement parler. La solution simple serait de simplement l’envoyer à Elasticsearch. Toutefois, faire cela aura comme conséquence de perdre des données si le serveur venait à subir un problème (Connectivité, maintenance…) ou tout simplement en cas de charge importante de données à enregistrer. Bien sûr un mécanisme de buffer interne à Logstash existe mais il est limité. L’idéal étant toujours de séparer le frontend du backend avec un système intermédiaire. Dans ce que propose Elastic, une solution possible est d’envoyer les messages reçus via Syslog vers un système de messages tel que RabbitMQ, Kafka voire Redis. On aura ensuite un Logstash qui sera chargé de récupérer ces messages et qui enverra ceux-ci à Elasticsearch.

Le but étant de ne perdre aucun message, le premier Logstash sera le plus light possible. Dans notre cas, on aura simplement un input syslog et un output RabbitMQ, Kafka voir Redis. On ajoutera au maximum l’une ou l’autre information toute simple afin d’identifier la source et le cheminement du message. Le second Logstash sera chargé de lire les messages sur RabbitMQ, Kafka voir Redis, il fera le traitement ainsi que le filtrage avant de l’envoyer à Elasticsearch pour le stockage.

Les fichiers de logs

Pour les fichiers, ici on pourra choisir 2 implémentations: la version simple qui lira le fichier et l’enverra ensuite à Logstash pour directement le traiter et le stocker ou la version plus complexe, mais celle offrant certaines sécurités en passant par un système de queue.

La version simple verra l’installation d’un logiciel sur les machines qui ont des fichiers logs à envoyer vers Elasticsearch. On devra configurer quoi, comment et à quelle fréquence les lires ou les surveiller. La sortie sera en général Logstash qui sera en charge de traitement et du filtrage. Un filebeat pourra être connecté à plusieurs Logstash, que ce soit simultanément via un système de load balancing ou l’un à la suite de l’autre avec basculement en cas de pertes de connexions.

Une version plus complexe sera une version se rapprochant un peu de ce dont j’ai parlé pour syslog. Soit la version comme syslog où on envoi sur un Logstash qui lui sera en charge de l’envoyer sur un système RabbitMq, Kafka voir Redis ou une version plus intégrée où c’est le Filebeat en lui même qui se chargera de l’envoyer sur ces systèmes. Avec un petit bémol, Filebeat n’est capable d’envoyer en direct que sur du Kafka ou du Redis. Un Logstash prenant ensuite le relais pour récupérer sur ses systèmes les logs pour les traiter et les filtrer et les envoyer à Elasticsearch.

Petit point à prendre en compte si, pour l’une ou l’autre raisons, la destination des logs venait à ne pas être disponible, le système de queue interne prendrait le relais, mais se trouve quand même fort limité. L’idéal sera donc d’avoir que ce soit via l’un ou l’autre système que chaque message passe le moins de temps possible pour réduire les ressources nécessaires pour leur traitement sur les systèmes de productions.

Autre point, si la lecture peux se faire automatiquement, la gestion des fichiers de logs, elle, n’est pas possible. Il faudra dès lors prévoir à côté de ceci un autre système qui se chargera de l’archivage (si besoin) ou mieux la suppression de ceux-ci.

Pour les logs d’un système, la récupération peux se faire tout simplement avec Winlogbeat, le fonctionnement et les options seront identiques.

Les applications maisons

Si vous développez des applications maisons, vous générez probablement un grand nombre de log. Que ce soit juste pour le suivis ou tout simplement en cas d’erreur, il y a probablement autant de façons différentes de faire que de développeurs sur terre. Toutefois, on peux noter quelques tendances telles que l’envoi d’emails directement par l’application en cas d’erreur, l’écriture de logs dans des fichiers et un besoin de complexité et de charge pour la gestion de l’historique de ceux-ci.

L’idée que proposent les outils dans le style de la suite d’Elastic est de soulager les systèmes de production pour n’y laisser que le minimum. Ainsi, une des solutions possibles sera d’envoyer les logs sur un système tel que RabbitMQ, Kafka voire Redis. Cela impose certes une légère charge que ce soit en développement ou charge réseau. Mais cela évitera par la suite de devoir gérer des fichiers qui restent sur des serveurs, avec dans le cas de GDPR, des données sensibles. Il faudra probablement toutefois prévoir un système de secours en cas de pertes de connexions avec ce système de messages pour garder en local les logs, mais cela devra être étudié d’une façon globale en fonction de l’environnement qui aura été mis en place.

Le traitement

Récupérer les données est déjà un bon point. Mais il faudra régulièrement les traiter afin d’avoir quelque chose de plus évolué qu’une grande chaîne de textes. Mais il vous faudra probablement régulièrement mettre à jour ces différentes règles. La première chose à prévoir et qui existe depuis peu dans Logstash, c’est la création de pipelines différents. Il sera ainsi approprié de créer un pipeline par source différentes. Ainsi un changement sur une source n’impactera pas les autres. De plus chaque pipeline pourra ainsi avoir ses propres règles. Rien n’empêchera par exemple d’en avoir un pour Winlogbeat, plusieurs pour des Filebeats, un pour du Syslog, un pour RabbitMq, un pour Kafka et un pour Redis. Un pipeline en particulier pourra ainsi même envoyer des email en sortie en plus de l’envoi de stockage.

Au niveau traitement et filtrage, les possibilités sont presque infinies. Mais cela dépendra principalement des besoins spécifiques. Le seul point commun que l’on retrouvera en général c’est le traitement des messages pour récupérer l’heure originale d’un événement et non pas l’heure de réception du message par Logstash. De quoi suivre de façon chronologique les événements.

Le stockage

Une fois le choix fait concernant les logs à sauvegarder, et comment les récupérer. Il faudra faire le choix de comment bien les stocker. Dans la suite proposée par Elastic, le stockage est pris en charge par Elasticsearch. Pour un système de base surtout au niveau test, un simple serveur sera suffisant. Par contre dans un environnement en production où la masse de données et la sécurité de celle-ci deviennent importantes, un cluster de 2 instance sera le minima du minima à avoir. Trois instances dans un cluster sera le minimum. Ainsi, en cas de panne simple, il y aura toujours 2 instances activent avec la duplication des données.

Autre point à prévoir, celui du découpage des données dans des index. Un seul index peux exister, tout comme un découpage très complexe peut se faire. Dans une majorité des cas, un découpage temporel sera souvent idéal: par mois, par jour voire par heure dans le cas d’un grand nombre de données. Ce découpage permettra non seulement de faire des recherches plus rapides mais aussi de gérer plus facilement l’archivage voire la destruction des données. On pourra ainsi le faire par blocs et non pas en le faisant logs par logs. C’est un élément devenu important dans un grand nombre de cas avec la futur réglementation GDPR.

A partir d’un certain nombre mais aussi d’une certaine taille, ou encore un découpage temporel, un découpage plus spécifique pourra être mis en place. Par exemple si une source comporte 50% des logs. Si des règles légales imposent un stockage de données pour un temps déterminé. Toutes des raisons pouvant non seulement impacter la performance en temps réel mais aussi amenant un besoin de traitement par la suite au niveau stockage et destructions.

Petit bémol dans la version gratuite, il n’existe aucune sécurité. Ainsi il suffit d’un accès réseau pour faire ce qu’on l’on veut dans Elasticsearch. La solution est le passage par des systèmes ajoutant plus ou moins de sécurité. Que ce soit via un proxy tournant sous Nginx qui filtrera les requêtes ou par l’ajout du plugin payant X-Pack d’Elastic ou d’autres qui peuvent être aussi gratuit ou payant. Ces différentes possibilités permettront de plus ou moins sécuriser le système (Dépendant du choix fait). Cette sécurisation aura toutefois 2 bêtes et se montrera presque indispensable. Premièrement pour éviter que n’importe qui supprime des données ou en injecte des fausses par exemple. Mais aussi et surtout dans le cadre de GDPR que n’importe qui puissent accéder à des données pouvant être sensibles.

L’accès aux données

Pour l’accès aux données, c’est Kibana qui fera ce job pour la suite d’Elastic. Il s’agit d’une interface web permettant d’afficher tous les logs et d’y faire des recherches. Il y a de petites configurations à faire manuellement en fonction des index qui existent mais le reste est assez simple d’utilisation.

Au niveau sécurité, Kibana souffre des mêmes problèmes qu’Elasticsearch. Et pour cause, l’accès est virtuellement total à Elasticsearch. Il faudra dès lors passer par les mêmes choix de solutions de sécurité pour réduire les problèmes. Que ce soit une limitation partielle (Tout ou rien) à une solution très complexe basée sur des rôles et l’accès à certaines données dans certains index.

On résume ?

Voilà un petit tour avec quelques astuces sur ce qui est possible de faire avec les Beats, Logstash, Elasticsearch et Kibana. On pourra bien sur venir avec nos propres développement interroger Elasticsarch pour extraire, afficher voire alerter en fonction de ce que nous voulons. Bien sur divers autres outils existant sont disponibles sur le marché. Que ce soit gratuit ou payant, les possibilités sont pratiquement infinies.

Comme outil intéressant, j’ai par exemple retenu Elastalert. Un système développé par Yelp (Le site d’avis sur les commerces locaux) et qui, comme sont nom l’indique, est la gestion d’alertes sur les données étant sur Elasticsearch. Et cela trouvera toute son importance dans des cas où des alertes doivent être déclenchées par exemple si un événement se passe plus de x fois pendant un temps T.

Dans tous les cas, un bon travail au préalable d’identification des sources, mais aussi de ce qu’on désire en faire sera nécessaire afin de bien préparer le cheminement des données. Et bien sûr, une adaption constante sera nécessaire pour suive l’évolution des données qui seront remontées à la plateforme de logs.

Dernier conseil que je peux donner, c’est d’y aller par étapes. Faire l’ajout de sources une par une, en tout cas au début afin de vérifier que tout ce que nous souhaitons se passe bien. Car dans certains cas, le retour en arrière est au mieux complexe et au pire impossible.


One Comments

  • Christian

    03/05/2018

    Merci Jonathan pour cette présentation.. Je travaille actuellement sur ELK et je recherchais des explications claires en français … Merci

    Reply

Laisser un commentaire