Commencez par installer la surveillance sans serveur Datadog afin de commencer à recueillir des métriques, traces et logs. Une fois cette première étape terminée, consultez les rubriques suivantes pour configurer votre installation afin de répondre à vos besoins en matière de surveillance.

Métriques

• Recueillir des métriques à partir de ressources non Lambda
• Envoyer des métriques custom

Logs

• Filtrer ou nettoyer des données des logs
• Désactiver la collecte de logs
• Recueillir des logs à partir de ressources non Lambda
• Parser et transformer des logs
• Associer des logs à des traces

APM

• Associer des données de télémétrie à l’aide de tags
• Recueillir les charges utiles des requêtes et réponses
• Recueillir des métriques à partir de ressources non Lambda
• Recueillir des logs à partir de ressources non Lambda
• Recueillir des traces à partir de ressources non Lambda
• Filtrer ou nettoyer des données des logs
• Désactiver la collecte de logs
• Parser et transformer des logs
• Configurer le traceur Datadog
• Choisir les taux d’échantillonnage pour l’ingestion des spans APM
• Filtrer ou nettoyer des informations sensibles des traces
• Désactiver la collecte de traces
• Associer des logs à des traces
• Associer des erreurs à votre code source
• Envoyer des métriques custom
• Envoyer des données OpenTelemetry à Datadog
• Envoyer des données de télémétrie via PrivateLink ou un proxy
• [Envoyer des données de télémétrie à plusieurs organisations Datadog](#envoyer-des donnees-de-telemetrie-a-plusieurs-organisations-Datadog)
• Propager le contexte de traces vers des ressources AWS
• Fusionner des traces X-Ray et Datadog
• Activer la signature de code pour AWS Lambda
• Migrer vers l’extension Lambda Datadog
• Migrer de x86 à arm64 avec l’extension Lambda Datadog
• Configurer l’extension Lambda Datadog pour effectuer des tests locaux
• Dépannage
• Pour aller plus loin

Autres

• Associer des données de télémétrie à l’aide de tags
• Recueillir les charges utiles des requêtes et réponses
• Recueillir des métriques à partir de ressources non Lambda
• Recueillir des logs à partir de ressources non Lambda
• Recueillir des traces à partir de ressources non Lambda
• Filtrer ou nettoyer des données des logs
• Désactiver la collecte de logs
• Parser et transformer des logs
• Configurer le traceur Datadog
• Choisir les taux d’échantillonnage pour l’ingestion des spans APM
• Filtrer ou nettoyer des informations sensibles des traces
• Désactiver la collecte de traces
• Associer des logs à des traces
• Associer des erreurs à votre code source
• Envoyer des métriques custom
• Envoyer des données OpenTelemetry à Datadog
• Envoyer des données de télémétrie via PrivateLink ou un proxy
• [Envoyer des données de télémétrie à plusieurs organisations Datadog](#envoyer-des donnees-de-telemetrie-a-plusieurs-organisations-Datadog)
• Propager le contexte de traces vers des ressources AWS
• Fusionner des traces X-Ray et Datadog
• Activer la signature de code pour AWS Lambda
• Migrer vers l’extension Lambda Datadog
• Migrer de x86 à arm64 avec l’extension Lambda Datadog
• Configurer l’extension Lambda Datadog pour effectuer des tests locaux
• Dépannage
• Pour aller plus loin

Associer des données de télémétrie à l’aide de tags

Associez entre elles les données de télémétrie Datadog à l’aide de tags réservés (env, service et version) et personnalisés. Ces tags vous permettent d’explorer facilement vos métriques, traces et logs. Ajoutez les paramètres supplémentaires ci-dessous en fonction de la méthode d’installation que vous avez suivie.

datadog-ci lambda instrument \
    --env dev \
    --service web \
    --version v1.2.3 \
    --extra-tags "team:avengers,project:marvel"
    # … autres arguments requis, par exemple le nom des fonctions

custom:
  datadog:
    # … autres paramètres requis, comme la clé d'API et le site Datadog
    env: dev
    service: web
    version: v1.2.3
    tags: "team:avengers,project:marvel"

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # … autres paramètres requis, comme la clé d'API et le site Datadog
      env: dev
      service: web
      version: v1.2.3
      tags: "team:avengers,project:marvel"

const datadog = new Datadog(this, "Datadog", {
    // … autres paramètres requis, comme la clé d'API et le site Datadog
    env: "dev",
    service: "web",
    version: "v1.2.3",
    tags: "team:avengers,project:marvel"
});
datadog.addLambdaFunctions([<FONCTIONS_LAMBDA>]);

Datadog peut également enrichir les données de télémétrie recueillies à l’aide de tags de ressource AWS existants définis sur vos fonctions Lambda, avec un retard de quelques minutes.

• Si vous recueillez des données de télémétrie à partir de vos fonctions Lambda à l’aide de l’extension Lambda Datadog, activez l’intégration Datadog/AWS. Cette fonctionnalité vise à enrichir vos données de télémétrie avec des tags personnalisés. Les tags réservés Datadog (env, service et version) doivent être définis via les variables d’environnement correspondantes (respectivement DD_ENV, DD_SERVICE et DD_VERSION). Il est également possible de les définir à l’aide des paramètres fournis par les intégrations Datadog et des outils de développement sans serveur. Cette approche n’est pas valable pour les fonctions Lambda déployées avec des images de conteneur.

• Si vous recueillez des données de télémétrie à partir de vos fonctions Lambda à l’aide de la fonction Lambda du Forwarder Datadog, définissez l’option DdFetchLambdaTags sur true dans la pile CloudFormation pour votre Forwarder Datadog. Depuis la version 3.19.0, cette option prend par défaut la valeur true.

Recueillir les charges utiles des requêtes et réponses

Datadog peut recueillir et visualiser les charges utiles des requêtes et réponses JSON de vos fonctions AWS Lambda. Vous bénéficiez ainsi d’informations pertinentes sur vos applications sans serveur, pour un dépannage simplifié des échecs de vos fonctions Lambda.

Cette fonctionnalité est désactivée par défaut. Suivez les instructions ci-dessous pour la méthode d’installation que vous avez suivie.

datadog-ci lambda instrument \
    --capture-lambda-payload true
    # … autres arguments requis, comme le nom des fonctions

custom:
  datadog:
    # … autres paramètres requis, comme la clé d'API et le site Datadog
    captureLambdaPayload: true

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # … autres paramètres requis, comme la clé d'API et le site Datadog
      captureLambdaPayload: true

const datadog = new Datadog(this, "Datadog", {
    // … autres paramètres requis, comme la clé d'API et le site Datadog
    captureLambdaPayload: true
});
datadog.addLambdaFunctions([<FONCTIONS_LAMBDA>]);

Pour éviter d’envoyer à Datadog des données sensibles dans les objets JSON des requêtes ou réponses, vous pouvez nettoyer certains paramètres.

Pour ce faire, ajoutez un nouveau fichier datadog.yaml dans le même dossier que le code de votre fonction Lambda. Pour obfusquer des champs dans la charge utile Lambda, utilisez le bloc replace_tags dans les paramètres apm_config du fichier datadog.yaml :

apm_config:
  replace_tags:
    # Remplacer toutes les occurrences de « foobar » dans les tags par « CENSURÉ » :
    - name: "*"
      pattern: "foobar"
      repl: "CENSURÉ"
    # Remplacer « auth » dans les en-têtes des requêtes par une chaîne vide
    - name: "function.request.headers.auth"
      pattern: "(?s).*"
      repl: ""
    # Remplacer « apiToken » dans la charge utile des réponses par « **** »
    - name: "function.response.apiToken"
      pattern: "(?s).*"
      repl: "****"

Il est également possible de définir la variable d’environnement DD_APM_REPLACE_TAGS sur votre fonction Lambda afin d’obfusquer certains champs :

DD_APM_REPLACE_TAGS=[
      {
        "name": "*",
        "pattern": "foobar",
        "repl": "CENSURÉ"
      },
      {
        "name": "function.request.headers.auth",
        "pattern": "(?s).*",
        "repl": ""
      },
      {
        "name": "function.response.apiToken",
        "pattern": "(?s).*"
        "repl": "****"
      }
]

Recueillir des métriques à partir de ressources non Lambda

Datadog peut non seulement recueillir en temps réel des métriques Lambda optimisées, mais également vous aider à recueillir des métriques relatives aux ressources gérées par AWS, comme les ressources API Gateway, AppSync et SQS. Vous pouvez ainsi surveiller l’intégralité de votre application sans serveur. Les tags de ressource AWS correspondants sont également ajoutés aux métriques.

Pour recueillir ces métriques, configurez l’intégration Datadog/AWS.

Recueillir des logs à partir de ressources non Lambda

Les logs générés par des ressources gérées (outre les fonctions Lambda AWS) 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 :

• API : API Gateway, AppSync et ALB
• Files d’attente et flux : SQS, SNS et Kinesis
• Datastores : DynamoDB, S3 et RDS

Recueillir des traces à partir de ressources non Lambda

Datadog peut déduire des spans APM en fonction des événements Lambda reçus pour les ressources gérées par AWS qui déclenchent une fonction Lambda. Vous pouvez ainsi visualiser plus facilement la relation entre les ressources gérées par AWS et identifier plus rapidement les problèmes de performances de vos applications sans serveur. Consultez cet article de blog (en anglais) pour obtenir plus d’informations sur les solutions incluses.

Les ressources suivantes sont actuellement prises en charge :

• API Gateway (API REST, API HTTP et WebSocket)
• URL de fonction Lambda
• SQS
• SNS (les messages SNS distribués via SQS sont également pris en charge)
• Flux Kinesis (si les données correspondent une chaîne JSON ou à une chaîne JSON codée en base64)
• EventBridge (événements personnalisés pour lesquels Details prend la forme d’une chaîne JSON)
• S3
• DynamoDB

Pour désactiver cette fonctionnalité, définissez DD_TRACE_MANAGED_SERVICES sur false.

Filtrer ou nettoyer des données des logs

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 :

logs_config:
  processing_rules:
    - type: exclude_at_match
      name: exclude_start_and_end_logs
      pattern: (START|END) RequestId

Datadog vous conseille de conserver les logs REPORT. En effet, ils permettent de remplir la liste d’invocations des vues des fonctions sans serveur.

Pour nettoyer ou filtrer d’autres logs avant de les envoyer à Datadog, consultez la section Collecte de logs avancée.

Désactiver la collecte de logs

Par défaut, la collecte de logs via l’extension Lambda Datadog est activée.

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 Datadog
    enableDDLogs: false

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # … autres paramètres requis, comme la clé d'API et le site Datadog
      enableDDLogs: false

const datadog = new Datadog(this, "Datadog", {
    // … autres paramètres requis, comme la clé d'API et le site Datadog
    enableDatadogLogs: false
});
datadog.addLambdaFunctions([<FONCTIONS_LAMBDA>]);

Parser et transformer des logs

Pour parser et transformer vos logs dans Datadog, consultez la documentation relative aux pipelines de logs Datadog.

Configurer le traceur Datadog

Pour découvrir quelles bibliothèques et quels frameworks sont automatiquement instrumentés par le client APM Datadog, consultez la section Exigences de compatibilité pour APM. Pour instrumenter des applications personnalisées, consultez le guide sur l’instrumentation personnalisée pour la solution APM de Datadog.

Choisir les taux d’échantillonnage pour l’ingestion des spans APM

Pour gérer le taux d’échantillonnage des invocations tracées par APM pour des fonctions sans serveur, définissez la variable d’environnement DD_TRACE_SAMPLE_RATE de la fonction sur une valeur comprise entre 0.000 (aucun tracing des invocations de fonction Lambda) et 1.000 (tracing de toutes les invocations de fonction Lambda).

Les métriques sont calculées en tenant compte de l’intégralité du trafic de l’application. Votre configuration d’échantillonnage ne nuit donc aucunement à leur justesse.

Pour les services qui génèrent beaucoup de requêtes, puisque les données des traces sont très répétitives, vous n’avez généralement pas besoin de recueillir chaque requête : les problèmes suffisamment graves sont systématiquement détectables dans plusieurs traces. Les paramètres d’ingestion vous permettent de visualiser les données dont vous avez besoin pour diagnostiquer des problèmes tout en respectant votre marge d’erreur.

L’échantillonnage en amont constitue le mécanisme d’ingestion par défaut. La décision de conserver ou d’ignorer la trace est prise au tout début du cycle de vie de la trace, à la création de la span racine. Cette décision est ensuite propagée vers les autres services par l’intermédiaire du contexte de la requête (par exemple, sous la forme d’un en-tête de requête HTTP). La décision est prise au début de la trace, puis transmise durant toutes les étapes de la trace. Ainsi, vous devez configurer le taux d’échantillonnage sur le service root afin de l’appliquer.

Lorsque Datadog ingère les spans, le filtre de rétention intelligent Datadog indexe une partie de vos traces pour vous aider à surveiller l’intégrité de vos applications. Vous pouvez également définir des filtres de rétention personnalisés dans le but d’indexer les données des traces que vous souhaitez conserver plus longtemps, en accord avec les objectifs de votre organisation.

En savoir plus sur le pipeline de traces Datadog.

Filtrer ou nettoyer des informations sensibles des traces

Pour filtrer les traces avant de les envoyer à Datadog, consultez la section Ignorer les ressources non désirées dans APM.

Si vous avez besoin de nettoyer les attributs de vos traces pour des raisons de sécurité, consultez la section Configurer l’Agent Datadog ou le traceur pour assurer la sécurité des données.

Désactiver la collecte de logs

La collecte de traces via l’extension Lambda Datadog est activée par défaut. Si vous ne souhaitez pas recueillir de traces à partir de vos fonctions Lambda, suivez les instructions ci-dessous :

datadog-ci lambda instrument \
    --tracing false
    # … autres arguments requis, comme le nom des fonctions

custom:
  datadog:
    # … autres paramètres requis, comme la clé d'API et le site Datadog
    enableDDTracing: false

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # … autres paramètres requis, comme la clé d'API et le site Datadog
      enableDDTracing: false

const datadog = new Datadog(this, "Datadog", {
    //… autres paramètres requis, comme la clé d'API et le site Datadog
    enableDatadogTracing: false
});
datadog.addLambdaFunctions([<FONCTIONS_LAMBDA>]);

Associer vos logs à vos traces

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 :
  1. Récupérez l’ID de trace Datadog à l’aide de dd-trace, puis ajoutez-le à votre log.
  2. Dupliquez le pipeline de logs Lambda par défaut, qui est en lecture seule uniquement.
  3. Activez le pipeline dupliqué et désactivez le pipeline par défaut.
  4. 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.

Associer des erreurs à votre code source

Grâce à l’intégration du code source Datadog, vous pouvez associer vos données de télémétrie (comme vos stack traces) au code source de vos fonctions Lambda dans GitHub. Suivez les instructions ci-dessous pour activer cette fonctionnalité. Remarque : vous devez procéder au déploiement depuis un référentiel Git local qui n’est ni « dirty » ni en avance par rapport à un référentiel distant.

# … autres variables d'environnement requises, comme DATADOG_SITE

# requis, permet d'importer les métadonnées Git
export DATADOG_API_KEY=<CLÉ_API_DATADOG>

# facultatif, DATADOG_API_KEY est utilisé si cette variable d'environnement n'est pas définie
export DATADOG_API_KEY_SECRET_ARN=<ARN_SECRET_CLÉ_API_DATADOG>

datadog-ci lambda instrument \
    --source-code-integration=true
    # … autres arguments requis, comme le nom des fonctions

custom:
  datadog:
    # … autres paramètres requis, comme le site Datadog
    apiKey: <CLÉ_API> # requis, permet d'importer les métadonnées Git
    apiKeySecretArn: <ARN_SECRET_CLÉ_API> # facultatif, apiKey est utilisé si ce paramètre n'est pas défini
    enableSourceCodeIntegration: true # valeur par défaut : true

async function main() {
  // Bien ajouter @datadog/datadog-ci via votre gestionnaire de packages
  const datadogCi = require("@datadog/datadog-ci");
  const gitHash = await datadogCi.gitMetadata.uploadGitCommitHash('{Datadog_API_Key}', '<SITE>')

  const app = new cdk.App();
  // Passer la valeur au constructor ExampleStack dans le hash
  new ExampleStack(app, "ExampleStack", {}, gitHash);
}

export class ExampleStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps, gitHash?: string) {
    ...
    ...
    datadog.addGitCommitMetadata([<VOS_FONCTIONS>], gitHash)
  }
}

Envoyer des métriques custom

Vous pouvez envoyer des métriques custom pour surveiller une logique opérationnelle personnalisée.

Envoyer des données OpenTelemetry à Datadog

1. Indiquez à OpenTelemetry que les spans doivent être exportées à l’extension Lambda Datadog.

   // instrument.js
   
   const { NodeTracerProvider } = require("@opentelemetry/sdk-trace-node");
   const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http');
   const { Resource } = require('@opentelemetry/resources');
   const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');
   const { SimpleSpanProcessor } = require('@opentelemetry/sdk-trace-base');
   
   const provider = new NodeTracerProvider({
      resource: new Resource({
          [ SemanticResourceAttributes.SERVICE_NAME ]: 'rey-app-otlp-dev-node',
      })
   });
   
   provider.addSpanProcessor(
      new SimpleSpanProcessor(
          new OTLPTraceExporter(
              { url: 'http://localhost:4318/v1/traces' },
          ),
      ),
   );
   provider.register();
   

2. Ajoutez l’instrumentation d’OpenTelemetry pour AWS Lambda. Cela revient à ajouter la couche de tracing.

   // instrument.js
   
   const { AwsInstrumentation } = require('@opentelemetry/instrumentation-aws-sdk');
   const { AwsLambdaInstrumentation } = require('@opentelemetry/instrumentation-aws-lambda');
   const { registerInstrumentations } = require('@opentelemetry/instrumentation');
   
   registerInstrumentations({
      instrumentations: [
          new AwsInstrumentation({
              suppressInternalInstrumentation: true,
          }),
          new AwsLambdaInstrumentation({
              disableAwsContextPropagation: true,
          }),
      ],
   });
   

3. Appliquez l’instrumentation au moment de l’exécution. Par exemple, pour Node.js, utilisez NODE_OPTIONS.

   # serverless.yml
   
   functions:
     node:
       handler: handler.handler
       environment:
         NODE_OPTIONS: --require instrument
   

4. Activez OTel via la variable d’environnement DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT ou DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT. Ajoutez la version 41 ou une version ultérieure de l’extension Datadog. N’ajoutez pas la couche de tracing Datadog.

   # serverless.yml
   
   provider:
     name: aws
     region: sa-east-1
     runtime: nodejs18.x
     environment:
       DD_API_KEY: ${env:DD_API_KEY}
       DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT: localhost:4318
     layers:
       - arn:aws:lambda:sa-east-1:464622532012:layer:Datadog-Extension:42
   

5. Procédez au déploiement.

Envoyer des données de télémétrie via AWS PrivateLink ou un proxy

L’extension Lambda Datadog doit pouvoir accéder à Internet pour envoyer des données à Datadog. Si vos fonctions Lambda sont déployées dans un VPC sans accès à Internet, vous pouvez envoyer vos données via AWS PrivateLink pour le site Datadog datadoghq.com ou via un proxy pour tous les autres sites.

Si vous utilisez le Forwarder Datadog, suivez ces instructions.

Envoyer des données de télémétrie à plusieurs organisations Datadog

Si vous souhaitez envoyer vos données à plusieurs organisations différentes, vous pouvez activer la transmission multiple à l’aide d’une clé d’API en clair, d’AWS Secrets Manager, ou d’AWS KMS.

# Activer la transmission multiple pour les métriques
DD_ADDITIONAL_ENDPOINTS={"https://app.datadoghq.com": ["<votre_clé_API_2>", "<votre_clé_API_3>"], "https://app.datadoghq.eu": ["<votre_clé_API_4>"]}
# Activer la transmission multiple pour APM (traces)
DD_APM_ADDITIONAL_ENDPOINTS={"https://trace.agent.datadoghq.com": ["<votre_clé_API_2>", "<votre_clé_API_3>"], "https://trace.agent.datadoghq.eu": ["<votre_clé_API_4>"]}
# Activer la transmission multiple pour APM (profiling)
DD_APM_PROFILING_ADDITIONAL_ENDPOINTS={"https://trace.agent.datadoghq.com": ["<votre_clé_API_2>", "<votre_clé_API_3>"], "https://trace.agent.datadoghq.eu": ["<votre_clé_API_4>"]}
# Activer la transmission multiple pour les logs
DD_LOGS_CONFIG_USE_HTTP=true
DD_LOGS_CONFIG_ADDITIONAL_ENDPOINTS=[{"api_key": "<votre_clé_API_2>", "Host": "agent-http-intake.logs.datadoghq.com", "Port": 443, "is_reliable": true}]

Pour découvrir des options d’utilisation plus avancées, consultez le guide dédié à la transmission multiple.

Propager le contexte de traces vers des ressources AWS

Datadog injecte automatiquement le contexte des traces dans les requêtes AWS SDK sortantes et extrait le contexte des traces à partir des événements Lambda. Cela permet de tracer une requête ou une transaction sur des services distribués. Pour en savoir plus, consultez la section Propagation de traces sans serveur.

Fusionner des traces X-Ray et Datadog

AWS X-Ray prend en charge le tracing par l’intermédiaire de certains services gérés par AWS, comme AppSync et Step Functions, qui ne sont pas nativement pris en charge par la solution APM Datadog. Vous pouvez néanmoins activer l’intégration Datadog/X-Ray et fusionner les traces X-Ray avec les traces natives Datadog. Pour obtenir plus d’informations à ce sujet, consultez cette section.

Activer la signature de code pour AWS Lambda

Grâce à la signature de code pour AWS Lambda, vous êtes certain de ne déployer que du code fiable depuis vos fonctions Lambda vers AWS. Lorsque vous activez la signature de code sur vos fonctions, AWS vérifie que tout le code de vos déploiements est signé par une source fiable. Vous pouvez définir les sources auxquelles vous faites confiance depuis la configuration de la signature de code.

Si vos fonctions Lambda ont été configurées de façon à utiliser la signature de code, vous devez ajouter l’ARN du profil de signature de Datadog à la configuration de signature de code de votre fonction avant de déployer les fonctions Lambda à l’aide des couches Lambda publiées par Datadog.

ARN du profil de signature de Datadog :

arn:aws:signer:us-east-1:464622532012:/signing-profiles/DatadogLambdaSigningProfile/9vMI9ZAGLc

arn:aws:signer:us-east-1:464622532012:/signing-profiles/DatadogLambdaSigningProfile/9vMI9ZAGLc

Migrer vers l’extension Lambda Datadog

Datadog peut recueillir les données de surveillance de vos fonctions Lambda via la fonction Lambda du Forwarder ou l’extension Lambda. Il est conseillé de privilégier l’extension Lambda pour les nouvelles installations. Si vous ne savez pas quelle approche adopter, consultez la section Choisir s’il est pertinent de migrer vers l’extension Lambda Datadog.

Pour procéder à la migration, comparez les instructions d’installation via l’extension Lambda Datadog avec celles via le Forwarder Datadog. Pour vous faciliter la tâche, les principales différences sont répertoriées ci-dessous.

Remarque : Datadog vous conseille de migrer en premier vos applications dev et staging, puis de migrer vos applications de production une par une.

Migrer de x86 à arm64 avec l’extension Lambda Datadog

L’extension Datadog est un binaire compilé disponible en version x86 ou arm64. Si vous migrez une fonction Lambda x86 vers arm64 (ou arm64 vers x86) à l’aide d’un outil de déploiement tel que CDK, Serverless Framework ou SAM, assurez-vous que votre intégration de service (telle que API Gateway, SNS ou Kinesis) est configurée pour utiliser les versions ou les alias d’une fonction Lambda. Dans le cas contraire, la fonction risquerait d’être indisponible pendant une dizaine de secondes lors du déploiement.

Ce problème est dû au fait que la migration d’une fonction Lambda de x86 vers arm64 implique deux appels API parallèles, updateFunction et updateFunctionConfiguration. Lorsque ces appels ont lieu, on observe un court laps de temps où l’appel updateFunction est terminé et où le code est mis à jour pour utiliser la nouvelle architecture alors que l’appel updateFunctionConfiguration n’est lui pas encore terminé, ce qui signifie que l’ancienne architecture est toujours configurée pour l’extension.

Si vous ne pouvez pas utiliser les paramètres LayerVersion, Datadog vous recommander de configurer le Forwarder Datadog durant le processus de migration vers la nouvelle architecture.

Configurer l’extension Lambda Datadog pour effectuer des tests locaux

Pour tester l’image du conteneur de votre fonction Lambda en local lorsque l’extension Lambda Datadog est installée, vous devez définir DD_LOCAL_TEST sur true dans votre environnement de test local. Si ce n’est pas le cas, l’extension attend des réponses de l’API d’extensions AWS et bloque l’appel.

Dépannage

Si vous ne parvenez pas à configurer vos installations, définissez la variable d’environnement DD_LOG_LEVEL sur debug pour activer les logs de debugging. Si vous avez besoin d’aide supplémentaire pour le dépannage, consultez le guide Dépannage de la surveillance sans serveur.

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles:

Installer la surveillance sans serveur pour AWS LambdaDOCUMENTATION Dépanner la surveillance sans serveur pour AWS LambdaDOCUMENTATION Intégration Datadog/GitHubDOCUMENTATION