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

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. 

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.