Les logs générés par des ressources gérées (outre les fonctions AWS Lambda) peuvent être utiles pour identifier la cause à l’origine des problèmes de vos applications sans serveur. Datadog vous conseille de recueillir les logs des ressources gérées par AWS suivantes dans votre environnement :
custom:datadog:# … autres paramètres requis, comme la clé d'API et le site DatadogenableDDLogs:true
Transform:- AWS::Serverless-2016-10-31- Name:DatadogServerlessParameters:# … autres paramètres requis, comme la clé d'API et le site DatadogenableDDLogs:true
constdatadog=newDatadog(this,"Datadog",{// … autres paramètres requis, comme la clé d'API et le site Datadog
enableDatadogLogs: true});datadog.addLambdaFunctions([<FONCTIONS_LAMBDA>]);
Définissez la variable d’environnement DD_SERVERLESS_LOGS_ENABLED sur true sur vos fonctions Lambda.
Si vous ne souhaitez plus recueillir de logs à l’aide de la fonction Lambda du Forwarder Datadog, supprimez le filtre d’abonnement du groupe de logs CloudWatch de votre propre fonction Lambda.
Si vous ne souhaitez plus recueillir de logs à l’aide de l’extension Lambda Datadog, suivez les instructions ci-dessous pour la méthode d’installation que vous avez suivie :
custom:datadog:# … autres paramètres requis, comme la clé d'API et le site DatadogenableDDLogs:false
Transform:- AWS::Serverless-2016-10-31- Name:DatadogServerlessParameters:# … autres paramètres requis, comme la clé d'API et le site DatadogenableDDLogs:false
constdatadog=newDatadog(this,"Datadog",{// … autres paramètres requis, comme la clé d'API et le site Datadog
enableDatadogLogs: false});datadog.addLambdaFunctions([<FONCTIONS_LAMBDA>]);
Définissez la variable d’environnement DD_SERVERLESS_LOGS_ENABLED sur false sur vos fonctions Lambda.
Pour en savoir plus, consultez la section Log Management.
Pour exclure les logs START et END, définissez la variable d’environnement DD_LOGS_CONFIG_PROCESSING_RULES sur [{"type": "exclude_at_match", "name": "exclude_start_and_end_logs", "pattern": "(START|END) RequestId"}]. Vous pouvez également ajouter un fichier datadog.yaml dans le répertoire racine de votre projet avec le contenu suivant :
Si vous utilisez l’extension Lambda pour recueillir des traces et des logs, Datadog ajoute automatiquement l’ID de la requête AWS Lambda à la span aws.lambda via le tag request_id. En outre, les logs Lambda d’une même requête partagent le même attribut lambda.request_id. L’ID de requête AWS Lambda permet d’associer les vues des traces et des logs Datadog.
Si vous utilisez la fonction Lambda du Forwarder pour recueillir des traces et des logs, dd.trace_id est automatiquement injecté dans les logs (grâce à la variable d’environnement DD_LOGS_INJECTION). L’ID de trace Datadog permet d’associer les vues des traces et des logs Datadog. Cette fonctionnalité est compatible avec la majorité des applications utilisant un runtime et un logger connus (voir la prise en charge pour chaque runtime).
Si vous utilisez un runtime ou un logger personnalisé qui n’est pas pris en charge, procédez comme suit :
Si vos logs sont au format JSON, vous devez récupérer l’ID de trace Datadog à l’aide de dd-trace, puis l’ajouter à vos logs via le champ dd.trace_id :
{"message":"This is a log","dd":{"trace_id":"4887065908816661012"}// ... the rest of your log
}
Si vos logs sont en texte brut, procédez comme suit :
Récupérez l’ID de trace Datadog à l’aide de dd-trace, puis ajoutez-le à votre log.
Dupliquez le pipeline de logs Lambda par défaut, qui est en lecture seule uniquement.
Activez le pipeline dupliqué et désactivez le pipeline par défaut.
Modifiez les règles du parser Grok du pipeline dupliqué afin de parser l’ID de trace Datadog dans l’attribut dd.trace_id. Vous pouvez par exemple utiliser la règle my_rule \[%{word:level}\]\s+dd.trace_id=%{word:dd.trace_id}.* pour les logs dont le format est [INFO] dd.trace_id=4887065908816661012 Mon message de log.