Tracing distribué avec des applications sans serveur AWS Lambda
Associez vos traces sans serveur à vos métriques pour permettre à Datadog de vous offrir une vue d’ensemble détaillée et contextualisée des performances de votre application. Compte tenu de la nature distribuée des applications sans serveur, vous pouvez ainsi résoudre plus efficacement les problèmes de performance.
Les SDK Datadog pour Python, Node.js, Ruby, Go, Java et .NET prennent en charge le traçage distribué pour AWS Lambda.
Envoyez des traces depuis votre application sans serveur
Les SDK Datadog pour Python, Node.js, Ruby, Go, Java et .NET prennent en charge le traçage distribué pour AWS Lambda. Vous pouvez installer le SDK en suivant les instructions d’installation.
Recommandations d’exécution
Python et Node.js
La Datadog Lambda Library et les SDK pour Python et Node.js prennent en charge :
- Corrélation automatique des journaux et des traces Lambda avec l’ID de trace et injection de balises.
- Installation sans aucun changement de code en utilisant les intégrations Serverless Framework, AWS SAM et AWS CDK.
- Traçage des requêtes HTTP invoquant des fonctions ou des conteneurs Lambda en aval.
- Traçage des invocations consécutives de Lambda effectuées via le SDK AWS.
- Traçage des démarrages à froid
- Traçage des invocations asynchrones de Lambda via les services gérés par AWS
- API Gateway
- SQS
- SNS
- Intégration directe de SNS et SQS
- Kinesis
- EventBridge
- DynamoDB
- S3
- Step Functions
- Traçage de dizaines de bibliothèques supplémentaires prêtes à l’emploi Python et Node.js.
Pour les applications sans serveur Python et Node.js, Datadog vous recommande d’installer les SDK Datadog.
Vous cherchez à tracer des ressources sans serveur non listées ci-dessus ? Ouvrez une demande de fonctionnalité.
Ruby
La Datadog Lambda Library et les SDK pour Ruby prennent en charge :
- Corrélation automatique des journaux et des traces Lambda avec l’injection d’ID de trace et de balises.
- Traçage des requêtes HTTP invoquant des fonctions ou des conteneurs Lambda en aval.
- Traçage de dizaines de bibliothèques supplémentaires prêtes à l’emploi Ruby.
Vous pouvez tracer vos fonctions sans serveur dans Datadog avec les SDK Datadog.
Vous cherchez à tracer des ressources sans serveur non listées ci-dessus ? Ouvrez une demande de fonctionnalité.
Go
La Datadog Lambda Library et les SDK pour Go prennent en charge :
- Corrélation manuelle des journaux et des traces Lambda avec l’injection d’ID de trace et de balises.
- Traçage des requêtes HTTP invoquant des fonctions ou des conteneurs Lambda en aval.
- Traçage de dizaines de bibliothèques supplémentaires prêtes à l’emploi Go.
Pour les applications sans serveur Go, Datadog recommande d’installer les SDK Datadog.
Vous cherchez à tracer des ressources sans serveur non listées ci-dessus ? Ouvrez une demande de fonctionnalité.
Java
La Datadog Lambda Library et les SDK pour Java prennent en charge :
- Corrélation des journaux et des traces Lambda avec l’ID de trace et l’injection de balises. Voir Connexion des journaux et des traces Java pour plus de détails.
- Traçage des requêtes HTTP invoquant des fonctions ou des conteneurs Lambda en aval.
- Traçage de dizaines de bibliothèques supplémentaires prêtes à l’emploi Java.
Pour les applications sans serveur Java, Datadog recommande d’installer les SDK Datadog.
Avez-vous des commentaires sur les SDK Datadog pour les fonctions Lambda Java ? Assurez-vous de consulter les discussions en cours dans le canal #serverless de la communauté Slack Datadog.
.NET
Le SDK pour .NET prend en charge :
- Traçage des requêtes HTTP invoquant des fonctions ou des conteneurs Lambda en aval.
- Traçage de dizaines de bibliothèques supplémentaires prêtes à l’emploi .NET.
Pour les applications sans serveur .NET, Datadog recommande d’installer les SDK Datadog.
En savoir plus sur le tracing via des applications sans serveur Azure .NET.
Auto-liaison des spans
Datadog détecte automatiquement les spans liés lorsque des segments de vos requêtes asynchrones ne peuvent pas propager le contexte de trace. Par exemple, cela peut se produire lorsqu’une requête déclenche des Événements de changement S3 ou des Flux DynamoDB. Vous pouvez voir les spans auto-liés apparaître dans l’onglet Liens de spans. Ceux-ci apparaissent comme Retour ou Avance.
Retour : Le span lié a été causé par la trace que vous visualisez.
Avance : Le span lié a causé la trace que vous visualisez.
Les filtres d'échantillonnage et de
rétention des traces peuvent interférer avec l'auto-liaison. Pour améliorer vos chances de voir des spans auto-liés, augmentez votre taux d'échantillonnage ou ajustez vos filtres de rétention.
Technologies prises en charge
L’auto-liaison des spans est disponible pour :
Auto-liaison des flux de changement DynamoDB
Pour Flux de changement DynamoDB, l’auto-liaison des spans prend en charge les opérations suivantes :
PutItemUpdateItemDeleteItemBatchWriteItemTransactWriteItems
Auto-liaison des notifications de changement S3
Pour les notifications de changement S3, la liaison automatique de Span prend en charge les opérations suivantes :
PutObjectCompleteMultipartUploadCopyObject
Environnements hybrides
Pour une visibilité de bout en bout à travers les fonctions Lambda, les hôtes, les conteneurs et les services gérés, installez les SDK Datadog (dd-trace) à la fois sur vos fonctions Lambda et vos hôtes. Vos traces montrent alors une image complète des requêtes qui traversent les frontières de l’infrastructure.
Sur Lambda, installez dd-trace avec l’Extension Datadog Lambda, qui exécute l’Agent Datadog à l’intérieur de l’environnement d’exécution Lambda et envoie les traces directement à Datadog avec un minimum de surcharge. L’Extension Lambda est la méthode d’installation recommandée pour les applications sans serveur nouvelles et existantes.
Consultez la documentation APM de Datadog pour la configuration du traçage dans les environnements basés sur des conteneurs et des hôtes.
Profilage de vos Fonctions Lambda
Le Continuous Profiler de Datadog est disponible en Preview pour Python dans la version 4.62.0 et avec la couche v62 et supérieure. Cette fonctionnalité optionnelle est activée en définissant la variable d’environnement DD_PROFILING_ENABLED sur true.
Le Continuous Profiler fonctionne en créant un thread qui se réveille périodiquement et prend un instantané du CPU et du tas de tout le code Python en cours d’exécution. Cela peut inclure le profiler lui-même. Si vous souhaitez que le profiler s’ignore lui-même, définissez DD_PROFILING_IGNORE_PROFILER sur true.
Fusion de traces
Cas d’utilisation
Datadog recommande d’utiliser uniquement la [Datadog APM trace library] (dd-trace), mais dans certaines situations avancées, les utilisateurs peuvent combiner le traçage Datadog et AWS X-Ray en utilisant la fusion de traces. La fusion de traces est disponible pour les fonctions AWS Lambda en Node.js et Python. Si vous n’êtes pas sûr du SDK à utiliser, consultez choisir votre SDK.
Il y a deux raisons principales d’instrumenter à la fois dd-trace et les bibliothèques de traçage AWS X-Ray :
- Dans un environnement sans serveur AWS, vous tracez déjà vos fonctions Lambda avec
dd-trace, vous avez besoin du traçage actif AWS X-Ray pour un service géré par AWS que Datadog APM n’instrumente pas encore (comme AppSync), et vous souhaitez visualiser les dd-trace et les spans AWS X-Ray dans une seule trace. - Dans un environnement hybride avec à la fois des fonctions Lambda et des hôtes,
dd-trace instrumente vos hôtes, AWS X-Ray instrumente vos fonctions Lambda, et vous souhaitez visualiser les traces connectées pour les transactions à travers les fonctions Lambda et les hôtes.
Remarque : Cela peut entraîner des factures d’utilisation plus élevées. Les spans X-Ray continuent d’être disponibles dans vos traces fusionnées après 2 à 5 minutes. Dans de nombreux cas, Datadog recommande d’utiliser uniquement un seul SDK. En savoir plus sur le choix de votre SDK.
Voici des instructions de configuration pour les deux scénarios évoqués ci-dessus :
Fusion des traces dans un environnement sans serveur AWS
AWS X-Ray fournit à la fois un service backend AWS (traçage actif AWS X-Ray) et un ensemble de bibliothèques clientes. Activer uniquement le service backend AWS dans la console Lambda vous donne des spans Initialization et Invocation pour vos fonctions AWS Lambda. Vous pouvez également activer le traçage actif AWS X-Ray depuis les consoles API Gateway et Step Function.
Les bibliothèques clientes AWS X-Ray et Datadog APM (dd-trace) ajoutent des métadonnées et des spans pour les appels en aval en accédant directement à la fonction. En supposant que vous utilisez dd-trace pour tracer au niveau du gestionnaire, votre configuration devrait être similaire à ce qui suit :
- Vous avez activé le traçage actif AWS X-Ray sur vos fonctions Lambda depuis la console AWS Lambda et notre intégration AWS X-Ray au sein de Datadog.
- Vous avez instrumenté vos fonctions Lambda avec Datadog APM (
dd-trace) en suivant les instructions d’installation pour votre runtime Lambda. - Les bibliothèques tierces sont automatiquement patchées par
dd-trace, donc les bibliothèques clientes AWS X-Ray n’ont pas besoin d’être installées. - Définissez la variable d’environnement
DD_MERGE_XRAY_TRACES sur true sur vos fonctions Lambda pour fusionner les traces X-Ray et dd-trace (DD_MERGE_DATADOG_XRAY_TRACES en Ruby).
Traçage entre AWS Lambda et les hôtes
Propagation du contexte avec les SDK Datadog (recommandé)
Installez les SDK Datadog (dd-trace) sur vos fonctions Lambda et vos hôtes. Vos traces affichent alors automatiquement une vue complète des requêtes qui franchissent les limites de l’infrastructure, que ce soit AWS Lambda, des conteneurs, des hôtes sur site ou des services gérés.
Propagation des traces
Configuration requise
Une instrumentation supplémentaire est parfois nécessaire pour obtenir une trace unique et connectée dans les applications sans serveur Node et Python qui déclenchent des fonctions Lambda de manière asynchrone. Si vous débutez avec la surveillance des applications sans serveur dans Datadog, suivez nos étapes d’installation principales et lisez cette page sur le choix de votre SDK. Une fois que vous envoyez des traces de vos fonctions Lambda à Datadog en utilisant la Bibliothèque Lambda Datadog, vous voudrez peut-être suivre ces étapes pour relier les traces entre deux fonctions Lambda dans des cas tels que :
- Déclenchement de fonctions Lambda via Step Functions
- Invocation de fonctions Lambda via des protocoles non-HTTP tels que MQTT
Le tracing d’un grand nombre de services AWS gérés (liste complète) est pris en charge par défaut. Il n’est pas nécessaire de suivre les étapes décrites sur cette page.
Pour associer le contexte des traces entre plusieurs ressources générant des traces, vous devez procéder comme suit :
- Inclure le contexte de trace Datadog dans les événements sortants. L’événement sortant peut provenir d’un hôte ou d’une fonction Lambda avec
dd-trace installé. - Extraction du contexte de trace dans la fonction Lambda du consommateur.
Transmission du contexte de trace
Les extraits de code suivants permettent de transmettre le contexte des traces, par le biais des charges utiles sortantes, aux services qui ne prennent par en charge les en-têtes HTTP ou aux services gérés qui ne sont pas pris en charge de façon native par Datadog en Node et Python :
En Python, vous pouvez utiliser la fonction d’aide get_dd_trace_context pour passer le contexte de trace aux événements sortants dans une fonction Lambda :
import json
import boto3
import os
from datadog_lambda.tracing import get_dd_trace_context # Datadog tracing helper function
def handler(event, context):
my_custom_client.sendRequest(
{
'myCustom': 'data',
'_datadog': {
'DataType': 'String',
'StringValue': json.dumps(get_dd_trace_context()) # Includes trace context in outgoing payload.
},
},
)
En Node, vous pouvez utiliser la fonction d’aide getTraceHeaders pour passer le contexte de trace aux événements sortants dans une fonction Lambda :
const { getTraceHeaders } = require("datadog-lambda-js"); // Datadog tracing helper function
module.exports.handler = async event => {
const _datadog = getTraceHeaders(); // Captures current Datadog trace context.
var payload = JSON.stringify({ data: 'sns', _datadog });
await myCustomClient.sendRequest(payload)
Depuis les hôtes
Si vous ne passez pas le contexte de trace de vos fonctions Lambda, vous pouvez utiliser le modèle de code suivant à la place des fonctions d’aide getTraceHeaders et get_dd_trace_context pour obtenir le contexte de span actuel. Les instructions sur la façon de faire cela dans chaque runtime sont décrites ici.
const tracer = require("dd-trace");
exports.handler = async event => {
const span = tracer.scope().active();
const _datadog = {}
tracer.inject(span, 'text_map', _datadog)
// ...
Pour extraire le contexte de trace ci-dessus de la fonction Lambda du consommateur, vous devez définir une fonction d’extraction qui capture le contexte de trace avant l’exécution de votre gestionnaire de fonction Lambda. Pour ce faire, configurez la variable d’environnement DD_TRACE_EXTRACTOR pour pointer vers l’emplacement de votre fonction d’extraction. Le format pour cela est <FILE NAME>.<FUNCTION NAME>. Par exemple, extractors.json si l’extracteur json se trouve dans le fichier extractors.js. Datadog recommande de placer toutes vos méthodes d’extraction dans un seul fichier, car les extracteurs peuvent être réutilisés dans plusieurs fonctions Lambda. Ces extracteurs sont entièrement personnalisables pour s’adapter à tout cas d’utilisation.
Remarques :
- Si vous utilisez TypeScript ou un bundler comme webpack, vous devez
import ou require votre module Node.js où les extracteurs sont définis. Cela garantit que le module est compilé et inclus dans votre package de déploiement Lambda. - Si votre fonction Lambda Node.js s’exécute sur
arm64, vous devez définir l’extracteur dans le code de votre fonction au lieu d’utiliser la variable d’environnement DD_TRACE_EXTRACTOR.
Le code suivant comporte des extraits de fonction d’extraction que vous pouvez utiliser pour propager le contexte des traces à l’échelle d’un système tiers ou d’une API ne prenant pas en charge les en-têtes HTTP standard.
def extractor(payload):
trace_headers = json.loads(payload["_datadog"]);
trace_id = trace_headers["x-datadog-trace-id"];
parent_id = trace_headers["x-datadog-parent-id"];
sampling_priority = trace_headers["x-datadog-sampling-priority"];
return trace_id, parent_id, sampling_priority
exports.json = (payload) => {
const traceData = payload._datadog
const traceID = traceData["x-datadog-trace-id"];
const parentID = traceData["x-datadog-parent-id"];
const sampledHeader = traceData["x-datadog-sampling-priority"];
const sampleMode = parseInt(sampledHeader, 10);
return {
parentID,
sampleMode,
source: 'event',
traceID,
};
};
var exampleSQSExtractor = func(ctx context.Context, ev json.RawMessage) map[string]string {
eh := events.SQSEvent{}
headers := map[string]string{}
if err := json.Unmarshal(ev, &eh); err != nil {
return headers
}
// Using SQS as a trigger with a batchSize=1 so it's important we check
// for this as a single SQS message will drive the execution of the handler.
if len(eh.Records) != 1 {
return headers
}
record := eh.Records[0]
lowercaseHeaders := map[string]string{}
for k, v := range record.MessageAttributes {
if v.StringValue != nil {
lowercaseHeaders[strings.ToLower(k)] = *v.StringValue
}
}
return lowercaseHeaders
}
cfg := &ddlambda.Config{
TraceContextExtractor: exampleSQSExtractor,
}
ddlambda.WrapFunction(handler, cfg)
Envoi de traces à Datadog avec l’intégration X-Ray
Si vous avez une instrumentation X-Ray existante et que vous souhaitez continuer à l’utiliser, installez l’intégration AWS X-Ray pour envoyer des traces de X-Ray à Datadog. Pour les nouvelles applications sans serveur, Datadog recommande d’instrumenter les fonctions Lambda avec l’extension Datadog Lambda à la place.
Lectures complémentaires
Documentation, liens et articles supplémentaires utiles:
