Comment implémenter l'agrégation de journaux pour AWS Lambda

Expédiez les journaux de vos fonctions Lambda à un service d'agrégation de journaux tel que Logz.io

Lors de l'exécution d'une fonction Lambda, tout ce que vous écrivez sur stdout (par exemple, en utilisant console.log dans Node.js) sera capturé par Lambda et envoyé à CloudWatch Logs de manière asynchrone en arrière-plan. Et cela sans ajouter de temps supplémentaire au temps d'exécution de votre fonction.

Vous pouvez trouver tous les journaux de vos fonctions Lambda dans CloudWatch Logs. Il existe un groupe de journaux unique pour chaque fonction. Chaque groupe de journaux se compose alors de nombreux flux de journaux, un pour chaque instance de la fonction exécutée simultanément.

Vous pouvez envoyer des journaux à CloudWatch Logs vous-même via l'opération PutLogEvents. Vous pouvez également les envoyer à votre service d'agrégation de journaux préféré, tel que Splunk ou Elasticsearch.

Mais rappelez-vous que tout doit être fait lors de l’invocation d’une fonction. Si vous passez des appels réseau supplémentaires lors de l’appel, vous paierez pour ce temps d’exécution supplémentaire. Vos utilisateurs devront également attendre plus longtemps pour que l'API réponde.

Ces appels réseau supplémentaires ne peuvent ajouter que 10 à 20 ms par appel. Mais vous avez des microservices et une action utilisateur unique peut impliquer plusieurs appels d'API. Ces 10 à 20 ms par appel d'API peuvent composer et ajouter plus de 100 ms à la latence de l'utilisateur, ce qui est suffisant pour réduire les ventes de 1% selon Amazon.

Alors, ne faites pas ça!

Traitez plutôt les journaux de CloudWatch Logs après coup.

Dans la console CloudWatch Logs, vous pouvez sélectionner un groupe de journaux et choisir de diffuser les données directement vers le service Elasticsearch hébergé par Amazon.

Ceci est très utile si vous utilisez déjà le service Elasticsearch hébergé. Toutefois, si vous évaluez toujours vos options, lisez ce message avant de vous décider sur Elasticsearch hébergé par AWS.

Vous pouvez également diffuser les journaux vers une fonction Lambda. Il existe même un certain nombre de plans de fonction Lambda pour pousser déjà CloudWatch Logs vers d'autres services d'agrégation de journaux.

Clairement, c’est quelque chose que beaucoup de clients d’AWS ont demandé.

Vous pouvez trouver des plans d’expédition pour l’envoi de CloudWatch Logs à Sumologic, Splunk et Loggly.

Vous pouvez utiliser ces modèles pour vous aider à écrire une fonction Lambda qui expédiera CloudWatch Logs à votre service d’agrégation de journaux préféré. Mais voici quelques points à garder à l’esprit.

Chaque fois que vous créez une nouvelle fonction Lambda, un nouveau groupe de journaux est créé dans les journaux CloudWatch. Vous souhaitez éviter un processus manuel d'abonnement de groupes de journaux à votre fonction d'envoi de journaux.

Activez plutôt CloudTrail, puis configurez un modèle d’événement dans CloudWatch Events pour appeler une autre fonction Lambda chaque fois qu’un groupe de journaux est créé.

Vous pouvez effectuer cette configuration unique dans la console CloudWatch.

Faites correspondre l'appel API CreateLogGroup dans CloudWatch Logs et déclenchez une fonction Lambda subscribe-log-group. Cette fonction abonnerait le nouveau groupe de journaux à la fonction d'envoi de journaux.

Si vous travaillez avec plusieurs comptes AWS, évitez de faire de la configuration un processus manuel. Avec la structure sans serveur, vous pouvez configurer la source d'événements pour cette fonction subscribe-log-group dans le fichier serverless.yml.

Une autre chose à garder à l'esprit est qu'il est nécessaire d'éviter de souscrire le groupe de journaux à la fonction de journaux d'expédition. Cela va créer une boucle d’appel infinie et c’est une leçon douloureuse que vous voulez éviter.

Une dernière chose.

Par défaut, lorsque Lambda crée un nouveau groupe de journaux pour votre fonction, la stratégie de rétention est définie sur Never Expire. C'est excessif, car les coûts de stockage des données peuvent augmenter avec le temps. C’est également inutile si vous expédiez déjà les journaux ailleurs!

Par défaut, les journaux de vos fonctions Lambda sont conservés dans CloudWatch Logs pour toujours.

Nous pouvons appliquer la même technique ci-dessus et ajouter une autre fonction Lambda pour mettre à jour automatiquement la stratégie de rétention sur une valeur plus raisonnable.

Voici une fonction Lambda permettant de mettre à jour automatiquement la stratégie de conservation des journaux à 30 jours.

Si vous avez déjà beaucoup de groupes de journaux existants, envisagez d'écrire des scripts uniques pour les mettre à jour tous. Vous pouvez le faire en récursant dans tous les groupes de journaux avec l'appel de l'API DescribeLogGroups.

Si vous êtes intéressé par l’application de ces techniques vous-même, j’ai élaboré un projet de démonstration simple à votre intention. Si vous suivez les instructions du fichier README et déployez les fonctions, tous les journaux de vos fonctions Lambda seront remis à Logz.io.