Dans cette vidéo, je partage mon expérience sur l’observabilité des fonctions Lambda écrites en Go, en me concentrant particulièrement sur la mise en place d’une solution de logging efficace sans dépendre de packages tiers. L’observabilité est un aspect crucial du développement serverless, et il est essentiel de mettre en place des pratiques robustes dès le début d’un projet. La journalisation représente souvent le premier niveau d’observabilité, et sa bonne implémentation peut faire la différence entre une application facile à maintenir et un cauchemar opérationnel.

Pourquoi cette approche ?

Avec l’arrivée de Go 1.21 et son nouveau package slog, j’ai décidé d’explorer une alternative aux packages tiers traditionnels comme Zap ou Logrus. Cette décision n’a pas été prise à la légère, car ces packages sont largement utilisés et ont fait leurs preuves dans la communauté. Cependant, la maintenance de dépendances externes peut devenir un défi à mesure qu’un projet grandit. L’objectif était de simplifier nos dépendances tout en maintenant un niveau élevé de qualité dans nos logs. La standardisation native offerte par slog représentait une opportunité intéressante de réduire notre dette technique tout en conservant toutes les fonctionnalités essentielles dont nous avions besoin.

Les points clés abordés dans la vidéo

Dans cette présentation, j’explore en détail l’utilisation du package slog de Go 1.21 pour mettre en place une journalisation structurée. Cette nouvelle approche représente un changement significatif dans la façon dont Go gère nativement la journalisation. Je démontre comment le package offre une API élégante et performante pour gérer les logs structurés, tout en restant simple à utiliser. La démonstration inclut une implémentation complète d’un handler Lambda AWS personnalisé, qui permet d’optimiser la gestion des logs dans un environnement serverless. J’explique également en détail le processus de configuration des logs au format JSON, montrant comment ce format facilite l’analyse et l’exploitation des données de logging. Un aspect particulièrement important de la présentation concerne l’intégration de l’AWS Request ID dans les logs, une fonctionnalité cruciale pour le suivi des requêtes dans un environnement distribué. Enfin, je partage mon expérience concrète de migration, détaillant les défis rencontrés et les solutions mises en place pour assurer une transition en douceur de nos fonctions Lambda existantes vers cette nouvelle approche.

Le Handler Lambda personnalisé

J’ai développé un handler Lambda personnalisé qui permet d’intégrer automatiquement l’AWS Request ID dans chaque log. Cette approche améliore considérablement la traçabilité des requêtes dans nos systèmes distribués. Le développement de ce handler a été guidé par plusieurs années d’expérience dans la gestion d’applications serverless et les nombreux défis rencontrés en production. L’une des principales innovations de ce handler est sa capacité à maintenir un contexte cohérent tout au long de l’exécution de la fonction, permettant ainsi une traçabilité complète de chaque requête. Le handler gère également automatiquement la structuration des logs et l’enrichissement des métadonnées, ce qui simplifie grandement le travail des développeurs. Pour faciliter son adoption et permettre à la communauté d’en bénéficier, j’ai décidé de rendre le code source disponible sur GitHub, encourageant ainsi les contributions et les améliorations collaboratives.

Avantages de cette approche

L’adoption de cette nouvelle méthode de logging apporte des bénéfices substantiels à plusieurs niveaux de notre stack technique. En premier lieu, elle simplifie considérablement notre architecture en éliminant le besoin de gérer des dépendances tierces pour le logging, ce qui réduit les risques de conflits et simplifie nos déploiements. Du point de vue des performances, l’utilisation des packages natifs de Go nous permet d’obtenir une exécution plus efficace de nos fonctions, avec une empreinte mémoire réduite et des temps de démarrage à froid améliorés. La maintenabilité est également grandement améliorée grâce à une base de code plus légère et plus cohérente, ce qui facilite l’onboarding des nouveaux développeurs et réduit le temps nécessaire pour les diagnostics. La standardisation du format de nos logs à travers toutes nos fonctions Lambda nous permet de mettre en place des outils d’analyse plus efficaces et d’automatiser certaines tâches de monitoring. Enfin, l’amélioration de l’observabilité nous donne une visibilité sans précédent sur le comportement de nos fonctions en production, nous permettant de détecter et résoudre les problèmes plus rapidement.

Retour d’expérience

Cette transition vers une solution native de logging s’est révélée être un choix stratégique judicieux qui a dépassé nos attentes initiales. Non seulement nous avons réussi à simplifier notre stack technique, mais nous avons également constaté une amélioration significative dans la qualité et l’exploitabilité de nos logs. Les temps de développement ont été réduits grâce à la simplification de notre architecture, et nos équipes ont gagné en efficacité dans le diagnostic et la résolution des problèmes. L’utilisation de logs structurés au format JSON s’est avérée particulièrement précieuse, nous permettant de mettre en place des analyses plus sophistiquées et des alertes plus précises. L’intégration systématique de l’AWS Request ID dans chaque entrée de log a transformé notre capacité à suivre et debugger les requêtes à travers notre système, réduisant significativement le temps moyen de résolution des incidents.

Conclusion

La mise en place d’une solution de logging efficace est un élément fondamental pour maintenir des applications serverless fiables et performantes. Avec l’évolution continue de Go et l’introduction de packages puissants comme slog, nous disposons désormais d’outils natifs capables de répondre à nos besoins les plus exigeants en matière de logging. Cette approche démontre qu’il est possible de construire des solutions robustes et élégantes sans nécessairement dépendre de packages tiers. Je vous encourage vivement à explorer cette approche dans vos propres projets, à tester le handler que j’ai partagé sur GitHub, et à contribuer à son amélioration. Votre expérience et vos retours seront précieux pour faire évoluer cet outil et en faire bénéficier l’ensemble de la communauté Go.

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.