Une bonne gestion des logs fait partie des exigences à ne pas prendre à la légère dans la mise en place d’une infrastructure basée sur une architecture distribuée et cloud-native. Dans ces architectures vous avez généralement de multiples micro-services qui fonctionnent et communique entre elle pour fournir un service, du coup lorsqu’il ya des probleme ce n’est parfois pas évident de savoir à quel niveau ça coince. Grâce à une bonne organisation de vos logs, vous pouvez avoir un aperçu clair du fonctionnement de vos application, des messages échangés entre différents micro-services, des éventuelles erreurs, etc… en bref vous y retrouvez le traitement de bout en bout des requêtes émises vers votre application jusqu’à leur sortie, ce à partir d’une interface commune centralisant l’ensemble des logs.
Le traitement et la gestion des logs est donc un élément à penser et architecturer lors de la mise en place de l’architecture de base de votre application, le plus tôt vous allez vous caler a une architecture le mieux ce sera pour vous et vous allez vous rendre compte du gain énorme de temps qui va en découler lors des investigations. D’ailleurs ca fait partie des 12 caractéristiques importantes d’une application cloud-native.
Architecture
3 principaux composants constituent l’essentiel d’un système de gestion centralisée des logs :
- Le module d’exportation des journaux vers un système central de stockage.
- Le système central va stocker les journaux et permettre l’indexation des données et la recherche rapide. On privilégiera ici un système fournissant un mécanisme puissant de recherche sur le texte pouvant gérer plusieurs Tera de données, les logs étant très volumineux avec le temps.
- Et enfin un tableau de bord qui permettra de visualiser les différents logs et autoriser l’accès uniquement aux personnes habilités à les consulter, pour permettre la cohabitation entre plusieurs tenants par exemple.
Structuration de ses logs
Vos logs doivent être structurés afin qu’ils soient proprement indexés par le système de stockage central, facilitant ainsi les recherches lors de leur exploitation.
Le format json étant principalement utilisé par ces systèmes de stockage, il faudrait donc aligner vos journaux selon ce format dès que possible.
Ci-dessous un exemple de log, que vous pouvez adopter en fonction de la structure générale de votre application.
{“date”: “01-02-2020 04:00:20″,”composant”: “”,”fonction”: “”,”categorie”: “WARNING”,”message”: “”}
L’idée ici est de pouvoir faire des recherches du type : “Ressortir toutes les erreurs du composant xxx générés les 3 dernières heures, dont le message d’erreur contient le texte xxxx”
Chaque langage de programmation propose des librairies vous permettant d’écrire les logs suivant ce type de formatage.
Cette structuration doit être uniforme dans toutes les applications déployées. Une fois que cela sera mis en place, je peux vous garantir que vous aurez moins de mal a troubleshooter les problèmes en cas de panne et passerez beaucoup moins de temps à “fouiller” les logs.
Segregation et exportation vers un systeme central
Vos logs structures doivent maintenant être envoyés vers un système de base de données central qui va les persister et donc les rendre accessible même en cas de redémarrage du conteneur.
Plusieurs techniques sont possibles pour exporter vos logs. Nous allons discuter de 3 méthodes assez courantes :
- Mettre en place un exporter au niveau de chaque noeud.
Cette technique implique de faire tourner un agent sur chaque noeud qui va etre responsable de parser les logs de tous vos pods et de les exporter vers la base externe.
Il doit donc avoir des accès privilégiés au noeud sur lequel il tourne lui permettant de lire les logs générés par tous les conteneurs et écrits sur le disque du noeud.
Vu la nécessité de l’exécuter sur chaque noeud du cluster, il est recommandé de le faire tourner comme un daemonSet, mais il est aussi possible de faire fonctionner comme un service (type systemd) sur le noeud.
Cet agent va donc en gros effectuer ces actions :
* Parser les fichiers de logs
* Ajouter les tags utiles pour l’exploitation (tels que le namespace, le nom du pod)
* Envoyer vers l’outil de persistance
Plusieurs agents existent qui disposent des plugins pour implémenter ces scénarios, mais je recommande fluentd qui je pense est assez simple a mettre en place et très flexible.
- Utilisation d’un exporter de type sidecar qui va s’exécute avec chaque pod
Ici, chaque pod va embarquer un conteneur de type SideCar, ce dernier sera responsable de récupérer les logs du conteneur principal, éventuellement les transformer avant leur exportation.
Cette technique peut être utilisée dans un environnement multi-projet ou chaque client(projet) est responsable de gérer l’exportation de ses logs.
Elle est aussi préférée a la première lorsque les logs générés par les conteneurs ne sont pas correctement structurés et homogènes, le sideCar va donc les transformer et les mettre dans un format commun.
Je recommande aussi fluentd pour jouer le rôle de sideCar, mais beaucoup d’autres options sont possible.
- Utilisation d’un log driver de type Gelf pour envoyer directement le log vers la base
Gelf(Graylog Extended Logging Format) est un format populaire d’exportation des logs. Il améliore les fonctionnalités de syslog et est utilisé pour exporter les logs applicatifs vers diverses destinations.
Vous pouvez donc configurer vos pods avec Gelf comme driver pour les logs, et envoyer tous les logs applicatifs vers votre serveur Gelf.
Le serveur gelf ici peut être implémenté dans un serveur Graylog, ou alors comme un point d’entrée fluend (https://github.com/MerlinDMC/fluent-plugin-input-gelf) ou logstash, …
Système de stockage et de visualisation
- Elasticsearch et Kibana
La base elasticsearch ici va contenir toutes vos données et sera accessible a partir de l’outil Kibana qui va vous permettre de faire des requêtes et générer plusieurs types de visualisations.
Autant la base elasticsearch va grossir, autant la maintenir s’avérera de plus en plus coûteuse et nécessite la mise en place de plusieurs actions de maintenance.
Je vous recommande donc tant que c’est possible d’utiliser une solution cloud de type sas, qui va s’occuper de la maintenance et de l’élasticité des serveurs, vous permettant de vos focaliser sur votre coeur de métier.
- Graylog
Graylog est un outil qui a été conçu et designé pour la gestion des logs. Elle intègre en mode tout-en-un d’un puissant système qui va de la réception des logs jusqu’à leur présentation. Possédant aussi des fonctionnalités tels que :
* la gestion des accès pour la multiprojet,
* l’analyse des logs et l’envoi des notifications en cas de probleme
* L’archivage
J’ai eu a travailler plusieurs fois avec Graylog et je le recommande du fait de la facilité a le maintenir, la simplicité de la mise en place et son ergonomie. Je la recommande totalement aux PME/Startups.
