alex_aldo - Fotolia

Collecte de logs : les meilleures méthodes pour surveiller les microservices

La collecte de logs, dans une architecture orientée microservices, est une tâche beaucoup plus facile à dire qu’à faire. Joydip Kanjilal propose quelques bonnes pratiques pour renforcer l’enregistrement, la centralisation et l’analyse des informations issues des microservices.

par

Joydip Kanjilal

Publié le: 09 nov. 2020

Les logs applicatifs simplifient la résolution des problèmes, mais les équipes sont confrontées à plusieurs défis lorsqu’elles tentent d’exécuter de collecter ces précieux logs depuis des microservices, parce qu’il faut obtenir une vue centralisée de multiples services distribués.

Collecter des logs en provenance d’une application basée sur des microservices est bien plus complexe que de le faire dans un environnement monolithique.

Avec un monolithe, il suffit d’écrire les données sur un seul fichier, pour les consulter plus tard. Avec une application basée sur des microservices, il faut prendre en compte de nombreux composants, déployés sur de multiples serveurs, parfois situés dans des zones géographiques différentes. Or chaque microservice conserve son propre lot de logs.

Chaque service qui compose une architecture s’appuyant sur des microservices doit avoir sa propre stratégie de surveillance et de collecte de logs, afin de traiter les problèmes de manière proactive. Plus important encore, ces fichiers doivent être en ordre pour pouvoir facilement déboguer un problème. Une stratégie de collecte unique permet de concentrer le stockage des logs et éviter de se perdre dans une jungle d’informations, une fois que des centaines de microservices sont déployés.

La collecte de logs dans une architecture de microservices

Avec les microservices, de multiples services fonctionnent et communiquent entre eux en permanence, générant leurs propres logs en cours de route. Lorsqu’un ou plusieurs services tombent en panne, l’équipe doit savoir quel service a connu un problème et pourquoi. Il est également difficile de déchiffrer le flux complet des requêtes. Par exemple, quels services ont été appelés ? Et dans quel ordre et à quelle fréquence ce service est-il appelé ?

Voici quelques-unes des meilleures pratiques pour collecter les logs.

1. Utiliser un identifiant de corrélation

Un ID de corrélation est un identifiant unique que les développeurs utilisent pour séparer des ensembles d’opérations et suivre des requêtes individuelles. La manière dont l’ID de corrélation est généré importe peu, à condition qu’il soit unique, accessible aux services en aval et consigné avec diligence parmi les autres données importantes des appels de service.

Si la transaction passant par plusieurs services a un ID de corrélation, les opérateurs peuvent effectuer une recherche d’ID dans les journaux et consulter les données relatives aux appels de service individuels. Par exemple, pour savoir combien de fois un service a été utilisé. De cette façon, l’ID de corrélation peut identifier de quel service provient l’échec de la transaction.

2. Structurer les logs de manière appropriée

Si une application basée sur les microservices utilise différentes structures pour enregistrer les données dans leurs piles, elle peut entraver la standardisation des logs. Par exemple, un service peut utiliser une barre verticale comme délimiteur de champs, tandis qu’un autre service utilise une virgule. Dans ce cas-là, les opérateurs ne peuvent pas analyser correctement les différents logs.

La collecte structurée est une méthodologie qui simplifie cet aspect. Elle convertit les données de logs en un format consistant et prédéterminé qui peut aider les développeurs à interroger, rechercher et analyser les données de manière transparente. Cela nécessite de conserver les informations essentielles généralement disponibles dans un fichier JSON. La méthodologie est plus simple et plus flexible.

La structure des logs est importante pour le traçage, le débogage et le dépannage. Si vos données sont correctement structurées, elles sont lisibles et peuvent être facilement analysées par des systèmes automatisés.

3. Fournir les informations essentielles

Cette structure peut s’appuyer sur le type d’informations dont a besoin un responsable DevOps, pour suivre et réparer un service. En apportant les détails adéquats, un opérateur peut plus facilement trouver les causes d’une panne.

Les logs devraient au minimum, contenir les informations suivantes

Nom du service
Nom d’utilisateur
Adresse IP
ID de corrélation
Heure de réception du message en temps universel coordonné (UTC)
Latence
Nom de la méthode
Pile d’exécution

4. Visualiser les logs

Lorsqu’ils travaillent sur des applications basées sur des microservices, développeurs doivent souvent examiner l’état d’une application, ainsi que les informations sur les éventuels problèmes, temps d’arrêt ou latence. Les équipes peuvent ajouter des fonctions de tableau de bord, qui fournissent une représentation visuelle des informations contenues dans les logs.

La visualisation des logs illustre les informations agrégées pour les services. Ces informations peuvent comprendre, sans s’y limiter, les requêtes, les réponses et la taille des réponses. Il existe différents outils de visualisation, tels que Grafana, Scalyr, Graylog, Kibana et Sematext.

5. Centraliser le stockage des logs

Mettre en place une architecture de stockage pour chaque microservice distribué est une tâche ardue, car chaque service nécessite son propre mécanisme d’enregistrement des événements. À mesure que le nombre de microservices augmente, ces mécanismes deviennent de plus en plus difficiles à gérer. Le stockage individuel des logs ajoute beaucoup de complexité, ce qui nuit à leur collecte et à leur analyse.

Il est préférable d’envoyer les logs à un seul endroit centralisé pour en faciliter l’accès. L’agrégation permet aux équipes de gérer et de coordonner plus facilement les données issues de ces fichiers. La maintenance de ce dépôt central permet également d’étudier les problèmes et de les corréler à des services spécifiques. Par exemple, les développeurs peuvent rechercher et analyser les journaux, ainsi que configurer des alertes qui se déclenchent dès que certains messages sont stockés dans les journaux.

En plus des processus de sauvegarde et de restauration, il convient de mettre en place une stratégie de stockage et de suppression de données. Accumuler les logs coûte vite très cher : les services de stockage hot/warm/cold ou d’archivage peuvent aider à mieux gérer les coûts. Pour effacer les logs, il faut vérifier si cela ne contrevient pas à la politique de gouvernance de données de son organisation ou aux obligations légales qu’elle doit respecter.

6. Interroger les logs

La capacité d’interroger efficacement les journaux est un élément essentiel pour trouver les défaillances qui se produisent dans plusieurs microservices. En utilisant l’ID de corrélation, un développeur ou un testeur doit pouvoir accéder au flux complet des demandes au sein de l’application.

Les équipes peuvent interroger les données des logs pour connaître le pourcentage de demandes échouées, le temps pris par chaque demande et la fréquence de chaque appel de service. Les outils permettant d’agréger ces données tels que la pile ELK, Splunk ou Sumo Logic, peuvent être utilisés pour compléter ces informations.

Quelques outils d’agrégation et de gestion de logs

Il existe plusieurs outils d’agrégation et de gestion des logs qui peuvent simplifier la collecte et aider à fournir des informations en temps réel sur les performances des applications. Voici quelques-uns des principaux outils :

Fluentd. Cet outil open source de collecte de données basé sur Windows peut unifier la collecte et la consommation de données. Il tire parti des parseurs intégrés standard, et les développeurs peuvent utiliser NLog pour enregistrer des données sur un nœud Fluentd. Fluentd est souvent utilisé par les utilisateurs de Docker et d’Elasticsearch.
Logstash. Il s’agit d’un agrégateur léger, open source, côté serveur, qui est utilisé pour collecter, intégrer et analyser les journaux. Logstash consomme beaucoup moins de mémoire que Fluentd.
Rsyslog. Il s’agit d’un framework de traitement des journaux hautement performant, modulaire et sécurisé. Il prend en charge les protocoles TCP, TLS et SSL et est compatible avec les bases de données MySQL, PostgreSQL et Oracle.
Loggly. Il s’agit d’une solution populaire d’analyse et de surveillance des logs, qui permet d’enregistrer les données des containers Docker. Les données saisies par Loggly peuvent être utilisées pour surveiller, analyser et optimiser les applications basées sur les microservices.

7. Gérer les problèmes

Les déploiements d’applications devraient s’appuyer sur un système d’alerte automatisé capable d’analyser les logs et d’envoyer des alertes chaque fois qu’un ou plusieurs services présentent un problème.

Les développeurs doivent également tenir compte du moment où les pannes surviennent, car il est possible qu’un composant de collecte soit hors service à un certain moment de la journée, en raison d’un nombre élevé de connexions ou de processus automatisés. Enfin, les applications devraient toujours inclure un service de secours capable de gérer les pannes de connexion et de restaurer les logs, si nécessaire.