Après avoir présenté les différentes étapes que nous avons suivies pour déployer la stack ELK sur la VM de monitoring, passons, dans cette partie, aux conditions qui doivent être respectées lorsque l’on envoie les messages de logs des services de Picasoft sur l’infrastructure de monitoring.

Comme nous l’avons expliqué dans la partie destinée à l’explication de la stack ELK, les messages de logs sont formatés au niveau de Logstash, avant d’être stockés dans Elasticsearch sous forme d’objets JSON structurés. Pour être facilement utilisable par les membres de l’association Picasoft, l’infrastructure de monitoring doit permettre de filtrer les messages de logs selon le nom des services. De ce fait, les messages de logs doivent avoir un champ décrivant le service Docker émetteur du message. De cette manière, des filtres peuvent être appliqués lors d’une requête sur Elasticsearch pour n’avoir l’historique de l’activité que d’un service en particulier.

De même, il est nécessaire, en cas, de problèmes sur l’infrastructure de monitoring, que les services de Picasoft continuent de s’exécuter sans problèmes si jamais l’agrégateur de logs (Logstash) est down.

Enfin, un dernier critère FONDAMENTAL à respecter lors de l’envoi des messages sur l’infrastructure de monitoring, est d’utiliser SSL/TLS pour chiffrer les logs et éviter de les envoyer en “clair” sur le réseau. Cette condition est absolument nécessaire et cruciale pour assurer la confidentialité des données et la sécurité de l’infrastructure de Picasoft.

Notons qu’un 4e critère doit préférablement être respecté (pas fondamental, mais très pratique). Il consiste à conserver la commande docker logs qui permet d’avoir les logs des conteneurs Docker lorsque l’on est en SSH sur la machine. Cette commande, peut ne plus fonctionner dans certains cas (utilisation de certains log driver etc). Conserver cette commande est un vrai plus, car elle est très fréquemment utilisée pour debugger des problèmes sur l’infrastructure.

Ainsi, si l’on récapitule, 3 conditions (fondamentales) doivent être respectées lors de l’envoi des messages de logs des différentes VMs vers la VM de monitoring:

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
2. La non-interruption des services si jamais un problème survient sur l'infrastructure de monitoring
3. Le chiffrement des canaux de communication sur lesquels transitent les messages de logs (TLS)

Optionnel mais très désirable

4. La conservation de la commande "docker logs"