L’architecture serverless offre de nombreux avantages en termes de scalabilité et de résilience. Cependant, la nature distribuée de ces systèmes peut rendre la consolidation et l’analyse des logs particulièrement complexe. Dans cette vidéo, je partage une pratique simple mais efficace qui peut considérablement améliorer votre capacité à déboguer vos fonctions Lambda.

La problématique des logs dans un environnement serverless

Les fonctions Lambda s’intègrent nativement avec CloudWatch Logs, où tous les logs sont automatiquement acheminés. AWS nous offre une interface complète pour consulter ces logs, que ce soit via la console de gestion ou en utilisant la CLI. Ces outils proposent des fonctionnalités avancées comme le tri chronologique ou le filtrage par mots-clés. Cependant, cette apparente simplicité cache un défi de taille lorsque votre application commence à monter en charge.

Les limites d’une approche basée uniquement sur les timestamps

Lorsque le trafic est faible, il est relativement simple de s’appuyer sur les timestamps pour identifier les messages de log relatifs à une requête spécifique. Cette approche atteint rapidement ses limites dès que le trafic augmente. En effet, la nature même des fonctions Lambda implique des exécutions concurrentes, rendant impossible l’identification précise des logs d’une requête particulière sur la seule base des timestamps. Cette situation peut transformer une simple session de debugging en un véritable casse-tête, particulièrement lorsque vous devez reconstituer le parcours d’une requête qui a échoué.

La solution : le Request ID AWS

AWS génère automatiquement un identifiant unique (Request ID) pour chaque exécution de fonction Lambda. C’est un détail d’implémentation qui peut sembler anodin, mais qui devient un atout majeur pour l’observabilité de vos applications. Par défaut, cet identifiant apparaît déjà dans les logs au début et à la fin de chaque exécution. L’astuce consiste à systématiquement inclure cet identifiant dans chacun des messages de log émis par votre fonction. Cette pratique transforme radicalement votre capacité à suivre et déboguer les exécutions de vos fonctions.

Évolution des pratiques d’implémentation

Au fil des années, j’ai fait évoluer ma façon d’implémenter cette pratique. Initialement, je récupérais manuellement l’identifiant depuis le contexte Lambda et je configurais mon framework de logging préféré pour l’inclure comme attribut dans chaque message. Cette approche fonctionnait, mais nécessitait une configuration répétitive pour chaque nouvelle fonction. Aujourd’hui, j’utilise le projet slog-aws-lambda qui automatise complètement cette configuration. Cette évolution illustre parfaitement comment un petit outil bien conçu peut grandement simplifier une bonne pratique et en favoriser l’adoption.

Les bénéfices concrets

L’inclusion systématique du Request ID dans vos logs apporte des avantages immédiats. En premier lieu, elle vous permet de filtrer rapidement tous les logs relatifs à une exécution spécifique dans CloudWatch. Cette capacité devient particulièrement précieuse lors du diagnostic d’incidents en production, où chaque minute compte. De plus, cette pratique facilite la corrélation des logs entre différents services, un aspect crucial dans une architecture microservices. Elle permet également d’améliorer la collaboration entre les équipes, car chacun peut facilement référencer une exécution spécifique lors des discussions techniques.

Conclusion

La journalisation du Request ID est un exemple parfait de ces petites pratiques qui, une fois systématisées, transforment radicalement votre capacité à maintenir et déboguer des applications serverless. Elle illustre également l’importance de continuellement faire évoluer nos pratiques pour tirer parti des nouveaux outils à notre disposition. Si vous développez des fonctions Lambda, je vous encourage vivement à adopter cette pratique. Non seulement elle simplifiera votre travail quotidien, mais elle vous sera particulièrement précieuse dans ces moments critiques où vous devez rapidement comprendre ce qui se passe dans votre application.

Si vous êtes arrivé jusqu’ici, merci beaucoup d’avoir lu cet article !
J’espère qu’il vous a permis d’approfondir vos connaissances sur Go et le servleress.
Pensez à vous abonner à la liste de diffusion pour ne rater aucun article, le formulaire se trouve en bas de page.
Photo de couverture par Sam McGhee.