Problèmes et solutions

EDIT : Suite à des problèmes pour récupérer les noms de conteneurs avec rsyslog (voir ici), nous avons finalement décidé d’implémenter la solution utilisant Logspout

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 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>

Le problème quand les services reportent leurs logs directement à l’instance de Logstash est dû au principe adopté par Docker, qui stipule qu’aucun message de log ne doit être perdu. De ce fait, un service ne pouvant pas reporter ses messages de logs à Logstash est amené à 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é.

Pour corriger ce problème, nous avons pensé utiliser:

• Logspout
• rsyslog et journald

• Avantages: 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.
• Inconvénients: Bien que nous n’ayons pas une connaissance approfondie du fonctionnement de Logspout, un de ses défauts (en comparaison avec d’autres solutions telles que rsyslog) est dû au fait qu’il tourne lui aussi dans un conteneur Docker. En effet, lorsqu’il nous a fallu choisir entre rsyslog et Logspout, nous avons décidé de choisir rsyslog puisqu’il est built-in à la machine. De cette manière on s’assure que nos conteneurs Docker puissent TOUJOURS reporter leurs messages de logs quelque part sur la machine hôte (et donc qu’ils ne crashent pas).

plus de détails

• Avantages: 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 leurs 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.

• Inconvénients: 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. De plus, nous avons eu quelques difficultés à faire en sorte que les noms de nos services apparaissent en tant que champs dans nos messages (en non pas en métadonnées), pour qu’ensuite nous puissions filtrer les logs par nom de services.

Ainsi, travailler avec Rsyslog et journald nous a demandé plus de temps de configuration que de travailler simplement avec des solutions conteneurisées (propres à Docker). Toutefois, l’utilisation d’un logiciel par défaut de la machine nous a semblé être la meilleure solution pour limiter les risques liés au reporting des messages de log.