Dans le but d’acheminer les messages de logs des services vers la VM de monitoring, tout en respectant les critères décris précédemment, nous avons adopté plusieurs approches:
La première approche adoptée lorsque nous avons mis en place l’infrastructure de monitoring des services, a été d’utiliser le log-driver syslog au lancement des services. De cette manière, chaque service aurait été capable d’envoyer ses logs (“par lui-même”) directement à Logstash.
Pour se faire il est simplement nécessaire de lancer les conteneurs Docker avec les flags suivants:
docker run \ --log-driver=syslog \ --log-opt syslog-address=tcp://<SyslogServerIP>:1234 \ <image> <command>
Les avantages de cette solution résident dans sa facilité de mise en oeuvre. De plus, les noms des services émetteurs des messages de logs sont directement ajoutés aux messages, et l’utilisation du log driver syslog respecte automatiquement le format syslog pour les messages de logs.
Le problème quand les services reportent leurs logs directement à l’instance de Logstash via ce log-driver est dû au principe adopté par Docker, qui consiste à ne perdre aucun message de log des conteneurs. De ce fait, un service ne pouvant pas reporter ses messages de logs à Logstash va crasher et redémarrer jusqu’à ce qu’il puisse reporter ses messages de log. Ainsi, si Logstash ne tourne pas, ce sont tous les services de Picasoft qui risquent de ne plus pouvoir reporter leurs messages de log et donc qui risquent de crasher. On voit donc que la VM de monitoring devient un point de faille de l’infrastructure de Picasoft dans son intégralité.
La condition 2: L’ininterruption des services si jamais un problème survient sur l’infrastructure de monitoring n’étant pas respectée, il nous a fallu trouver des alternatives.
Selon Wikipedia, Rsyslog est un logiciel libre utilisé sur des systèmes d’exploitation de type Unix (Unix, Linux) transférant les messages des journaux d’événements sur un réseau IP. Rsyslog implémente le protocole basique syslog - qui centralise les journaux d’événements, permettant de repérer plus rapidement et efficacement les défaillances d’ordinateurs présents sur un réseau. Il présente la particularité d’en étendre les fonctionnalités en permettant, notamment, de filtrer sur des champs, de filtrer à l’aide d’expressions régulières et l’utilisation du protocole TCP de la couche transport. Ainsi, étant une solution built-in à notre problème de report de log entre les conteneurs Docker et Logstash il nous a paru de bonne augure de la choisir pour l’implémentation finale de l’infrastructure de monitoring. De cette manière, nos services Docker peuvent reporter leur logs sur la machine hôte sur laquelle ils s’exécutent, et, c’est Rsyslog qui, ensuite, prend le relais pour envoyer les messages de logs des conteneurs Docker à l’instance Logstash.
Contrairement aux logs driver de Docker tels que ‘syslog’, il nous a été nécessaire, pour utiliser Rsyslog d’écrire un petit peu de configuration. Toutefois, le vrai problème réside dans le fait que nous n’avons pas réussi, en utilisant cette méthode, à ajouter le nom des conteneurs émetteurs des messages de log. En effet, dans cette solution, nous avons utilisé le log driver journald, qui permet de reporter l’activité des conteneurs dans le journal du système de la machine hôte. L’utilisation de ce log driver ajoute les informations liées à Docker dans les métadonnées des messages. En revanche, pour pouvoir envoyer les messages de log à notre instance Logstash, Rsyslog, a besoin de lire les données de journald, puis de “construire” un message au format syslog, contenant toutes les données nécessaires au bon parsing du message par Logstash, et de l’envoyer par la suite. Or, après de nombreuses recherches, nous n’avons pas pu lire correctement les messages de logs depuis Rsyslog dans le journal. Le module d’import imjournal n’est pas présent dans la version rsyslogd 8.4.2 de notre distribution Debian. De ce fait, les métadonnées ajoutées par docker au moment de l’écriture des logs des conteneurs dans le journal ne pouvaient pas être récupérées, et le nom du conteneur émetteur des logs ne pouvait pas être ajouté aux messages de log.
De plus, même si l’utilisation du module imjournal était possible, la récupération des métadonnées du message de log est relativement délicate et, la configuration de rsyslog n’est pas des plus simples.
La condition 1: La présence d’un champ “service” qui indique le nom du service émetteur du message de log pour pouvoir appliquer des filtres lors des requêtes sur Elasticsearch n’étant pas respectée, il nous a fallu trouver une alternative
L’avantage majeur de Logspout réside dans sa simplicité de mise en place. En effet, Logspout est un log router pour conteneurs Docker. Ce dernier est lui-même un conteneur Docker qui s’attache aux autres conteneurs et qui récupère leurs messages de logs pour les router vers un serveur de destination. Logspout est très extensible et permet de mettre en place différentes solutions de routage de logs. Un des avantages majeur de Logspout est qu’il écoute sur la socket Docker pour récupérer les messages de log. Ainsi, il connaît par nature les conteneurs qui émettent chaque log. Ceci, nous évite, comme avec Rsyslog par exemple, de devoir le faire nous même. De plus, et c’est là l’atout majeur de Logspout, les conteneurs producteurs de log n’ont pas besoin d’être configurés de quelque manière que ce soit. C’est Logspout qui se charge de tout ! Ainsi, si un problème survient sur l’infrastructure de monitoring, et que Logstash est indisponible, c’est Logspout qui risque de crasher. Les autres conteneurs (exécutant les services de Picasoft) eux ne risquent rien, et continuent de s’exécuter quoi qu’il advienne.
La documentation de Logspout est, dans certains cas, relativement légère, ce qui peu être un obstacle lors de sa mise en place. De plus, nous avons rencontré des problèmes lorsqu’il a fallu supporter des communications utilisant TLS entre Logstash et Logspout.
Comme nous l’avons dit précédemment, nous avons rencontré des problèmes lors de la mise en place de TLS pour chiffrer les communications entre Logstash et Logspout. TLS n’est, d’ailleurs, à ce jour, PAS SUPPORTÉ !. Supporter le chiffrement des messages de logs lors de leur envoi à Logstash est FONDAMENTAL et doit être mis en place le plus rapidement possible.