Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Configuration des groupes de CloudWatch journaux
Par défaut, crée CloudWatch automatiquement un groupe de journaux /aws/lambda/<function name> portant le nom de votre fonction lors de son appel initial. Pour configurer votre fonction afin d’envoyer des journaux à un groupe de journaux existant, ou pour créer un nouveau groupe de journaux pour votre fonction, vous pouvez utiliser la console Lambda ou AWS CLI. Vous pouvez également configurer des groupes de journaux personnalisés à l'aide des commandes CreateFunctionet de l'API UpdateFunctionConfigurationLambda et de la ressource AWS Serverless Application Model (AWS SAM) AWS: :Serverless : :Function.
Vous pouvez configurer plusieurs fonctions Lambda pour envoyer des journaux au même groupe de CloudWatch journaux. Par exemple, vous pouvez utiliser un seul groupe de journaux pour stocker les journaux de toutes les fonctions Lambda qui constituent une application particulière. Lorsque vous utilisez un groupe de journaux personnalisé pour une fonction Lambda, les flux de journaux créés par Lambda incluent le nom et la version de la fonction. Cela garantit que le mappage entre les messages du journal et les fonctions est préservé, même si vous utilisez le même groupe de journaux pour plusieurs fonctions.
Le format de dénomination des flux de journaux pour les groupes de journaux personnalisés suit cette convention :
YYYY/MM/DD/<function_name>[<function_version>][<execution_environment_GUID>]Notez que lors de la configuration d'un groupe de journaux personnalisé, le nom que vous sélectionnez pour votre groupe de journaux doit respecter les règles de dénomination CloudWatch des journaux. En outre, les noms de groupes de journaux personnalisés ne doivent pas commencer par la chaîne aws/. Si vous créez un groupe de journaux personnalisé en commençant par aws/, Lambda ne sera pas en mesure de créer le groupe de journaux. Par conséquent, les journaux de votre fonction ne seront pas envoyés à CloudWatch.
Pour modifier le groupe de journaux d’une fonction (console)
-
Ouvrez la page Functions
(Fonctions) de la console Lambda. -
Choisissez une fonction.
-
Dans la page de configuration de la fonction, choisissez Outils de surveillance et d’exploitation.
-
Dans le volet de configuration de la journalisation, choisissez Modifier.
-
Dans le volet Groupe de journalisation, pour le groupe de CloudWatch journaux, sélectionnez Personnalisé.
-
Sous Groupe de journaux personnalisé, entrez le nom du groupe de CloudWatch journaux auquel votre fonction doit envoyer des journaux. Si vous entrez le nom d’un groupe de journaux existant, votre fonction utilisera ce groupe. S’il n’existe aucun groupe de journaux portant le nom que vous entrez, Lambda créera un nouveau groupe de journaux portant ce nom pour votre fonction.
Pour modifier le groupe de journaux d’une fonction (AWS CLI)
-
Pour modifier le groupe de journaux d’une fonction existante, utilisez la commande update-function-configuration
. aws lambda update-function-configuration \ --function-name myFunction \ --logging-config LogGroup=myLogGroup
Pour indiquer un groupe de journaux personnalisé lorsque vous créez une fonction (AWS CLI)
-
Pour spécifier un groupe de journaux personnalisé lorsque vous créez une nouvelle fonction Lambda à l'aide de AWS CLI, utilisez l'
--logging-configoption. L’exemple de commande suivant crée une fonction Lambda Node.js qui envoie des journaux à un groupe de journaux nommémyLogGroup.aws lambda create-function \ --function-name myFunction \ --runtime nodejs24.x \ --handler index.handler \ --zip-file fileb://function.zip \ --role arn:aws:iam::123456789012:role/LambdaRole \ --logging-config LogGroup=myLogGroup
Autorisations du rôle d’exécution
Pour que votre fonction puisse envoyer des CloudWatch journaux à Logs, elle doit disposer de l'PutLogEventsautorisation logs :. Lorsque vous configurez le groupe de journaux de votre fonction à l’aide de la console Lambda, Lambda ajoute cette autorisation au rôle dans les conditions suivantes :
-
La destination du service est définie sur CloudWatch Logs
-
Le rôle d'exécution de votre fonction n'est pas autorisé à télécharger les journaux dans CloudWatch Logs (la destination par défaut)
Note
Lambda n’ajoute aucune autorisation Put pour les destinations de journal Amazon S3 ou Firehose.
Lorsque Lambda ajoute cette autorisation, elle autorise la fonction à envoyer des journaux à n'importe quel groupe de CloudWatch journaux Logs.
Pour empêcher Lambda de mettre automatiquement à jour le rôle d’exécution de la fonction et de le modifier manuellement, développez Autorisations et décochez Ajouter les autorisations requises.
Lorsque vous configurez le groupe de journaux de votre fonction à l'aide de AWS CLI, Lambda n'ajoute pas automatiquement l'logs:PutLogEventsautorisation. Ajoutez l’autorisation au rôle d’exécution de votre fonction si elle ne l’a pas déjà. Cette autorisation est incluse dans la politique AWSLambdaBasicExecutionRole
CloudWatch journalisation pour les instances gérées Lambda
Lorsque vous utilisez des instances gérées Lambda, d'autres considérations s'appliquent à l'envoi de journaux vers CloudWatch Logs :
Exigences de mise en réseau VPC
Les instances gérées Lambda s'exécutent sur des instances appartenant au client EC2 au sein de votre VPC. Pour envoyer des CloudWatch journaux à Logs et des traces à X-Ray, vous devez vous assurer qu' AWS APIs ils sont routables depuis votre VPC. Vous avez plusieurs options:
-
AWS PrivateLink (recommandé) : AWS PrivateLinkà utiliser pour créer des points de terminaison VPC pour les services Logs CloudWatch et X-Ray. Cela permet à vos instances d'accéder à ces services en privé sans avoir besoin d'une passerelle Internet ou d'une passerelle NAT. Pour plus d'informations, consultez la section Utilisation CloudWatch des journaux avec les points de terminaison VPC de l'interface.
-
Passerelle NAT : configurez une passerelle NAT pour autoriser l'accès Internet sortant à partir de vos sous-réseaux privés.
-
Passerelle Internet : pour les sous-réseaux publics, assurez-vous qu'une passerelle Internet est configurée sur votre VPC.
Si CloudWatch Logs ou X-Ray ne APIs sont pas routables depuis votre VPC, vos journaux de fonctions et vos traces ne seront pas fournis.
Invocations simultanées et attribution de journaux
Les environnements d'exécution des instances gérées Lambda peuvent traiter plusieurs appels simultanément. Lorsque plusieurs appels sont exécutés simultanément, leurs entrées de journal sont entrelacées dans le même flux de journal. Pour filtrer et analyser efficacement les journaux provenant d'appels simultanés, vous devez vous assurer que chaque entrée de journal inclut l'ID de AWS demande.
Nous recommandons l'une des approches suivantes :
-
Utiliser des enregistreurs d'exécution Lambda par défaut (recommandé) : Les bibliothèques de journalisation par défaut fournies par les environnements d'exécution gérés par Lambda incluent automatiquement l'ID de demande dans chaque entrée de journal.
-
Implémenter une journalisation JSON structurée : si vous créez un environnement d'exécution personnalisé ou si vous avez besoin d'une journalisation personnalisée, implémentez des journaux au format JSON qui incluent l'ID de demande dans chaque entrée. Les instances gérées Lambda ne prennent en charge que le format de journal JSON. Incluez le
requestIdchamp dans vos journaux JSON pour activer le filtrage par invocation :{ "timestamp": "2025-01-15T10:30:00.000Z", "level": "INFO", "requestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "message": "Processing request" }
Grâce à l'attribution de l'ID de demande, vous pouvez filtrer CloudWatch les entrées du journal Logs pour un appel spécifique à l'aide des requêtes CloudWatch Logs Insights. Par exemple :
fields @timestamp, @message | filter requestId = "a1b2c3d4-e5f6-7890-abcd-ef1234567890" | sort @timestamp asc
Pour plus d'informations sur les exigences de journalisation des instances gérées Lambda, consultez. Comprendre l'environnement d'exécution des instances gérées Lambda