« Back
post_image

Approches pour une bonne gestion des logs dans une infrastructure cloud-native

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 essentiel à prendre en compte lors de la mise en place de l’architecture de base de votre application, plus tôt vous allez correctement le définir le mieux ce sera et vous noterez un 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 générale

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.
  • La base de données centrale va stocker les logs et permettre l’indexation des données et une 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 pour visualiser les logs et autoriser l’accès uniquement aux personnes habilités à les consulter. Le système va donc permettre par exemple la cohabitation de plusieurs projets/équipes.

 

Structuration des logs

Vos logs doivent être structurés afin qu’ils soient proprement indexés par le système de stockage central, facilitant 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 et l’appliquer avec TOUTES les applications déployées.

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.

Une fois que cela sera mis en place, je peux vous garantir que vous passerez beaucoup moins de temps à “fouiller” les logs.

 

Segregation et exportation vers un système central

Vos logs structurés 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 les 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.

Ce dernier doit donc avoir des accès privilégiés au noeud sur lequel il s’execute 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 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 container qui va s’exécuter dans 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 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.

Nous suivre et partager 🙂

About the Author

Leave a Reply

Copyright 2018 © Entrepreneur-Numerique.africa | CGU
error

Vous avez aimé? Partagez!