Tout d’abord, installez Datadog Serverless Monitoring pour commencer à collecter des métriques, des traces et des journaux. Une fois l’installation terminée, consultez les sujets suivants pour configurer votre installation selon vos besoins de surveillance.

• Connecter la télémétrie à l’aide de balises
• Collecter les charges utiles de requête et de réponse
• Collecter des traces à partir de ressources non-Lambda
• Configurer le SDK Datadog
• Sélectionner les taux d’échantillonnage pour ingérer les spans APM
• Filtrer ou supprimer les informations sensibles des traces
• Activer/désactiver la collecte de traces
• Connecter les journaux et les traces
• Lier les erreurs à votre code source
• Soumettre des métriques personnalisées
• Collecter des données de profilage
• Envoyer la télémétrie via PrivateLink ou un proxy
• Envoyer la télémétrie à plusieurs organisations Datadog
• Activer la conformité FIPS
• Propager le contexte de trace sur les ressources AWS
• Fusionner les traces X-Ray et Datadog
• Activer la signature de code AWS Lambda
• Migrer vers l’extension Datadog Lambda
• Migration de x86 vers arm64 avec l’extension Datadog Lambda
• Configurer l’extension Datadog Lambda pour les tests locaux
• Instrumenter AWS Lambda avec l’API OpenTelemetry
• Utiliser l’extension Datadog Lambda v67+
• Configurer le lien automatique pour DynamoDB PutItem
• Visualiser et modéliser correctement les services AWS
• Envoyer des journaux vers les pipelines d’observabilité
• Recharger périodiquement le secret de la clé API
• Déboguer
• Lectures complémentaires

Activer la détection des menaces pour observer les tentatives d’attaque

Recevez des alertes lorsque des acteurs malveillants ciblent vos applications sans serveur et prenez rapidement des mesures.

Pour commencer, assurez-vous d’abord que le tracing est activé pour vos fonctions.

Pour activer la surveillance des menaces, ajoutez les variables d’environnement suivantes à votre déploiement :

environment:
  DD_SERVERLESS_APPSEC_ENABLED: true
  AWS_LAMBDA_EXEC_WRAPPER: /opt/datadog_wrapper

Redéployez la fonction et invoquez-la. Après quelques minutes, elle apparaît dans les vues AAP.

Pour voir la détection des menaces de protection des applications et des API en action, envoyez des modèles d’attaque connus à votre application. Par exemple, envoyez un en-tête HTTP avec la valeur acunetix-product pour déclencher une tentative d’attaque de scanner de sécurité :

curl -H 'My-AAP-Test-Header: acunetix-product' https://<YOUR_FUNCTION_URL>/<EXISTING_ROUTE>

Quelques minutes après avoir activé votre application et envoyé les modèles d’attaque, les informations de menace apparaissent dans l’Explorateur de signaux d’application.

Connecter la télémétrie à l’aide de balises

Connectez la télémétrie Datadog grâce à l’utilisation de balises réservées (env, service et version) et de balises personnalisées. Vous pouvez utiliser ces balises pour naviguer sans effort à travers les métriques, les traces et les journaux. Ajoutez les paramètres supplémentaires ci-dessous pour la méthode d’installation que vous utilisez.

datadog-ci lambda instrument \
    --env dev \
    --service web \
    --version v1.2.3 \
    --extra-tags "team:avengers,project:marvel"
    # ... other required arguments, such as function names

custom:
  datadog:
    # ... other required parameters, such as the Datadog site and API key
    env: dev
    service: web
    version: v1.2.3
    tags: "team:avengers,project:marvel"

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... other required parameters, such as the Datadog site and API key
      env: dev
      service: web
      version: v1.2.3
      tags: "team:avengers,project:marvel"

const datadog = new DatadogLambda(this, "Datadog", {
    // ... other required parameters, such as the Datadog site and API key
    env: "dev",
    service: "web",
    version: "v1.2.3",
    tags: "team:avengers,project:marvel"
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

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 collectez de la télémétrie de vos fonctions Lambda en utilisant l’extension Datadog Lambda, activez l’intégration AWS Datadog. Cette fonctionnalité est destinée à enrichir votre télémétrie avec des balises personnalisées. Les balises réservées de Datadog (env, service et version) doivent être définies via les variables d’environnement correspondantes (DD_ENV, DD_SERVICE et DD_VERSION respectivement). Les balises réservées peuvent également être définies avec les paramètres fournis par les intégrations Datadog avec les outils de développement serverless. Cette fonctionnalité ne fonctionne pas pour les fonctions Lambda déployées avec des images de conteneur.

• Si vous collectez la télémétrie de vos fonctions Lambda en utilisant la fonction Lambda Datadog Forwarder, définissez l’option DdFetchLambdaTags sur true dans la pile CloudFormation pour votre Datadog Forwarder. Cette option est par défaut à vrai depuis la version 3.19.0.

Collectez les charges utiles de requête et de réponse

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 utilisez.

datadog-ci lambda instrument \
    --capture-lambda-payload true
    # ... other required arguments, such as function names

custom:
  datadog:
    # ... other required parameters, such as the Datadog site and API key
    captureLambdaPayload: true

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... other required parameters, such as the Datadog site and API key
      captureLambdaPayload: true

const datadog = new DatadogLambda(this, "Datadog", {
    // ... other required parameters, such as the Datadog site and API key
    captureLambdaPayload: true
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

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. L’obfuscation des champs dans la charge utile Lambda est alors disponible via le bloc replace_tags dans les paramètres apm_config dans datadog.yaml :

apm_config:
  replace_tags:
    # Replace all the occurrences of "foobar" in any tag with "REDACTED":
    - name: "*"
      pattern: "foobar"
      repl: "REDACTED"
    # Replace "auth" from request headers with an empty string
    - name: "function.request.headers.auth"
      pattern: "(?s).*"
      repl: ""
    # Replace "apiToken" from response payload with "****"
    - name: "function.response.apiToken"
      pattern: "(?s).*"
      repl: "****"

En alternative, vous pouvez également définir la variable d’environnement DD_APM_REPLACE_TAGS sur votre fonction Lambda pour obfusquer des champs spécifiques :

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

Pour collecter des charges utiles des services AWS, voir Capturer les requêtes et les réponses des services AWS.

Collectez des traces à partir de ressources non-Lambda

Datadog peut inférer des spans APM en fonction des événements Lambda entrants pour les ressources gérées par AWS qui déclenchent la fonction Lambda. Cela peut aider à visualiser la relation entre les ressources gérées par AWS et à identifier les problèmes de performance dans vos applications serverless. Voir détails supplémentaires sur le produit.

Les ressources suivantes sont actuellement prises en charge :

• Passerelle API (API REST, API HTTP et WebSocket)
• URLs de fonction
• SQS
• SNS (les messages SNS livrés via SQS sont également pris en charge)
• Flux Kinesis (si les données sont une chaîne JSON ou une chaîne JSON encodée en base64)
• EventBridge (événements personnalisés, où Details est une chaîne JSON)
• S3
• DynamoDB

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

DD_SERVICE_MAPPING

DD_SERVICE_MAPPING est une variable d’environnement qui renomme les noms de services non-Lambda en amont. Il fonctionne avec old-service:new-service paires.

Syntaxe

DD_SERVICE_MAPPING=key1:value1,key2:value2…

Vous pouvez interagir avec cette variable de deux façons différentes :

Renommer tous les services d’un type

Pour renommer tous les services en amont associés à une intégration AWS Lambda, utilisez les identificateurs suivants :

Renommer des services spécifiques

Pour bénéficier d’un contrôle plus granulaire, utilisez les identificateurs suivants, qui sont propres à chaque service :

Exemples avec description

Pour renommer les services en aval, voir DD_SERVICE_MAPPING dans la documentation de configuration du traceur.

Configurer le SDK Datadog

Pour voir quelles bibliothèques et frameworks sont automatiquement instrumentés par le client APM de Datadog, voir Exigences de compatibilité pour APM. Pour instrumenter des applications personnalisées, voir le guide APM de Datadog pour l’instrumentation personnalisée.

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

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

Notes:

• L’utilisation de DD_TRACE_SAMPLE_RATE est obsolète. Utilisez DD_TRACE_SAMPLING_RULES à la place. Par exemple, si vous avez déjà défini DD_TRACE_SAMPLE_RATE sur 0.1, définissez DD_TRACE_SAMPLING_RULES sur [{"sample_rate":0.1}] à la place.
• Les métriques de trafic global telles que trace.<OPERATION_NAME>.hits sont calculées sur la base des invocations échantillonnées uniquement dans Lambda.

Pour les services à fort débit, il n’est généralement pas nécessaire de collecter chaque requête, car les données de trace sont très répétitives—un problème suffisamment important devrait toujours montrer des symptômes dans plusieurs traces. Les contrôles d’ingestion vous aident à avoir la visibilité dont vous avez besoin pour résoudre les problèmes tout en restant dans le budget.

Le mécanisme d’échantillonnage par défaut pour l’ingestion est appelé échantillonnage basé sur l’en-tête. La décision de conserver ou de supprimer une trace est prise dès le début de la trace, au début du span racine. Cette décision est ensuite propagée à d’autres services dans le cadre de leur contexte de requête, par exemple sous forme d’en-tête de requête HTTP. Parce que la décision est prise au début de la trace et ensuite transmise à toutes les parties de la trace, vous devez configurer le taux d’échantillonnage sur le service racine pour qu’il prenne effet.

Après que les spans ont été ingérés par Datadog, le Filtre de Rétention Intelligent de Datadog indexe une proportion de traces pour vous aider à surveiller la santé de vos applications. Vous pouvez également définir des filtres de rétention personnalisés pour indexer les données de trace que vous souhaitez conserver plus longtemps pour soutenir les objectifs de votre organisation.

En savoir plus sur le pipeline de traces Datadog.

Filtrer ou supprimer les 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.

Activer/désactiver la collecte de traces

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

Si vous souhaitez commencer à recueillir des traces à partir de vos fonctions Lambda, appliquez les configurations ci-dessous :

datadog-ci lambda instrument \
    --tracing true
    # ... other required arguments, such as function names

custom:
  datadog:
    # ... other required parameters, such as the Datadog site and API key
    enableDDTracing: true

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... other required parameters, such as the Datadog site and API key
      enableDDTracing: true

const datadog = new DatadogLambda(this, "Datadog", {
    // ... other required parameters, such as the Datadog site and API key
    enableDatadogTracing: true
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

Désactiver la collecte de traces

Si vous souhaitez interrompre la collecte de traces à partir de vos fonctions Lambda, appliquez les configurations ci-dessous :

datadog-ci lambda instrument \
    --tracing false
    # ... other required arguments, such as function names

custom:
  datadog:
    # ... other required parameters, such as the Datadog site and API key
    enableDDTracing: false

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... other required parameters, such as the Datadog site and API key
      enableDDTracing: false

const datadog = new DatadogLambda(this, "Datadog", {
    // ... other required parameters, such as the Datadog site and API key
    enableDatadogTracing: false
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

Connecter les journaux et les traces

Si vous utilisez l’extension Lambda pour collecter des traces et des journaux, Datadog ajoute automatiquement l’ID de requête AWS Lambda au span aws.lambda sous le tag request_id. De plus, les journaux Lambda pour la même requête sont ajoutés sous l’attribut lambda.request_id. Les vues de traces et de journaux de Datadog sont connectées en utilisant l’ID de requête AWS Lambda.

Si vous utilisez la fonction Lambda Forwarder pour collecter des traces et des journaux, dd.trace_id est automatiquement injecté dans les journaux (activé par défaut avec la variable d’environnement DD_LOGS_INJECTION). Les vues de traces et de journaux de Datadog sont connectées en utilisant l’ID de trace Datadog. Cette fonctionnalité est prise en charge pour la plupart des applications utilisant un runtime et un logger populaires (voir le support par runtime).

Si vous utilisez un runtime ou un logger personnalisé qui n’est pas pris en charge, procédez comme suit :

• Lors de la journalisation en JSON, vous devez obtenir l’ID de trace Datadog en utilisant dd-trace et l’ajouter à vos journaux sous le champ dd.trace_id :

  {
    "message": "This is a log",
    "dd": {
      "trace_id": "4887065908816661012"
    }
    // ... the rest of your log
  }
  

• Lors de la journalisation en texte brut, vous devez :
  1. Obtenez l’ID de trace Datadog en utilisant dd-trace et ajoutez-le à votre journal.
  2. Clonez le pipeline de journalisation Lambda par défaut, qui est en lecture seule.
  3. Activez le pipeline cloné et désactivez celui par défaut.
  4. Mettez à jour les règles du parseur Grok du pipeline cloné pour analyser l’ID de trace Datadog dans l’attribut dd.trace_id. Par exemple, utilisez la règle my_rule \[%{word:level}\]\s+dd.trace_id=%{word:dd.trace_id}.* pour les journaux qui ressemblent à [INFO] dd.trace_id=4887065908816661012 My log message.

Liez les erreurs à votre code source

L’intégration du code source Datadog vous permet de lier votre télémétrie (comme les traces de pile) au code source de vos fonctions Lambda dans vos dépôts Git.

Pour des instructions sur la configuration de l’intégration du code source sur vos applications sans serveur, consultez la section Intégrer les informations Git dans vos artefacts de construction.

Collectez des données de profilage

Le Profilage Continu de Datadog est disponible en aperçu pour la version 4.62.0 du traceur Python et la version 62 de la couche et antérieures. Cette fonctionnalité optionnelle est activée en définissant la variable d’environnement DD_PROFILING_ENABLED sur true.

Le Profilage Continu fonctionne en créant un thread qui prend périodiquement 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, définissez DD_PROFILING_IGNORE_PROFILER sur true.

Envoyez la télémétrie via PrivateLink ou via un proxy

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

Si vous utilisez le Forwarder Datadog, suivez ces instructions.

Envoyez la 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.

# Enable dual shipping for metrics
DD_ADDITIONAL_ENDPOINTS={"https://app.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://app.datadoghq.eu": ["<your_api_key_4>"]}
# Enable dual shipping for APM (traces)
DD_APM_ADDITIONAL_ENDPOINTS={"https://trace.agent.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://trace.agent.datadoghq.eu": ["<your_api_key_4>"]}
# Enable dual shipping for APM (profiling)
DD_APM_PROFILING_ADDITIONAL_ENDPOINTS={"https://trace.agent.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://trace.agent.datadoghq.eu": ["<your_api_key_4>"]}
# Enable dual shipping for logs
DD_LOGS_CONFIG_FORCE_USE_HTTP=true
DD_LOGS_CONFIG_ADDITIONAL_ENDPOINTS=[{"api_key": "<your_api_key_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.

Activez la conformité FIPS

Pour activer la conformité FIPS pour les fonctions AWS Lambda, suivez ces étapes :

1. Utilisez une couche d’extension conforme à FIPS en référencant l’ARN approprié :

arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension-FIPS:98
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension-ARM-FIPS:98

arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-Extension-FIPS:98
arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-Extension-ARM-FIPS:98

2. Pour les fonctions Lambda utilisant Python, JavaScript ou Go, définissez la variable d’environnement DD_LAMBDA_FIPS_MODE sur true. Cette variable d’environnement :

   • En mode FIPS, les fonctions d’aide aux métriques Lambda nécessitent l’extension conforme à FIPS pour la soumission des métriques.
   • Utilise les points de terminaison FIPS d’AWS pour les recherches de clés API.
   • Est activé par défaut dans les environnements GovCloud.

3. Pour les fonctions Lambda utilisant Ruby, .NET ou Java, aucune configuration supplémentaire de la variable d’environnement n’est nécessaire.

4. Pour une conformité FIPS complète de bout en bout, configurez votre fonction Lambda pour utiliser un site Datadog pour le gouvernement :

   • Définir DD_SITE sur ddog-gov.com (US1-FED) ou us2.ddog-gov.com (US2-FED) Remarque : Bien que les composants Lambda conformes FIPS fonctionnent avec n’importe quel site Datadog, seuls les sites Datadog pour le gouvernement disposent de points de terminaison d’ingestion conformes FIPS.

Propager le contexte de trace sur les ressources AWS

Datadog injecte automatiquement le contexte de trace dans les requêtes sortantes du SDK AWS et extrait le contexte de trace de l’événement Lambda. Cela permet à Datadog de tracer une requête ou une transaction à travers des services distribués. Voir Propagation de trace sans serveur.

Fusionner les traces X-Ray et Datadog

AWS X-Ray prend en charge le traçage à travers certains services gérés par AWS tels qu’AppSync et Step Functions, ce qui n’est pas pris en charge nativement par Datadog APM. Vous pouvez activer l’intégration Datadog X-Ray et fusionner les traces X-Ray avec les traces natives de Datadog. Voir détails supplémentaires.

Activer la signature de code AWS Lambda

La signature de code pour AWS Lambda aide à garantir que seul un code de confiance est déployé depuis vos fonctions Lambda vers AWS. Lorsque vous activez la signature de code sur vos fonctions, AWS valide que tout le code de vos déploiements est signé par une source de confiance, que vous définissez dans votre configuration de 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

Migrer vers l’extension Datadog Lambda

Datadog peut collecter les données de surveillance de vos fonctions Lambda soit en utilisant la fonction Lambda Forwarder, soit l’extension Lambda. Datadog recommande l’extension Lambda pour les nouvelles installations. Si vous n’êtes pas sûr, voir Décider de migrer vers l’extension Datadog Lambda.

Pour migrer, comparez les instructions d’installation utilisant l’extension Datadog Lambda avec les instructions utilisant le Forwarder Datadog. Pour votre commodité, les principales différences sont résumées ci-dessous.

Remarque : Datadog recommande de migrer d’abord vos applications de développement et de staging, puis de migrer les applications de production une par une.

Migration entre x86 et arm64 avec l’extension Lambda Datadog

L’extension Datadog est un binaire compilé, disponible en variantes x86 et arm64. Si vous migrez une fonction Lambda x86 vers arm64 (ou arm64 vers x86) en utilisant un outil de déploiement tel que CDK, Serverless Framework ou SAM, assurez-vous que votre intégration de service (comme API Gateway, SNS ou Kinesis) est configurée pour utiliser les versions ou alias d’une fonction Lambda, sinon la fonction peut être indisponible pendant environ dix secondes pendant le déploiement.

Cela se produit parce que la migration d’une fonction Lambda de x86 vers arm64 consiste en deux appels API parallèles, updateFunction et updateFunctionConfiguration. Pendant ces appels, il y a une brève fenêtre où l’appel Lambda updateFunction est terminé et le code est mis à jour pour utiliser la nouvelle architecture tandis que l’appel updateFunctionConfiguration n’est pas encore terminé, donc 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.

Configurez l’extension Lambda Datadog pour les tests locaux

Tous les émulateurs Lambda ne prennent pas en charge l’API de télémétrie AWS Lambda. Pour tester l’image de conteneur de votre fonction Lambda localement avec l’extension Lambda Datadog installée, vous devez définir DD_SERVERLESS_FLUSH_STRATEGY sur periodically,1 dans votre environnement de test local. Sinon, l’extension attend des réponses de l’API de télémétrie AWS Lambda et bloque l’invocation.

Instrumenter AWS Lambda avec l’API OpenTelemetry

Le SDK Datadog, qui est inclus dans l’extension Datadog Lambda lors de l’installation, accepte les spans et les traces générés par le code instrumenté avec OpenTelemetry, traite la télémétrie et l’envoie à Datadog.

Vous pouvez utiliser cette approche si, par exemple, votre code a déjà été instrumenté avec l’API OpenTelemetry. Vous pouvez également utiliser cette approche si vous souhaitez instrumenter en utilisant du code indépendant du fournisseur avec l’API OpenTelemetry tout en bénéficiant des avantages des SDK Datadog.

Pour instrumenter AWS Lambda avec l’API OpenTelemetry, définissez la variable d’environnement DD_TRACE_OTEL_ENABLED sur true. Voir Instrumentation personnalisée avec l’API OpenTelemetry pour plus de détails.

Utilisation de l’extension Datadog Lambda v67+

La version 67+ de l’extension Datadog est optimisée pour réduire considérablement la durée de démarrage à froid. Pour utiliser l’extension optimisée, définissez la variable d’environnement DD_SERVERLESS_APPSEC_ENABLED sur false. Lorsque la variable d’environnement DD_SERVERLESS_APPSEC_ENABLED est définie sur true, l’extension Datadog par défaut utilise la version plus ancienne entièrement compatible. Vous pouvez également forcer votre extension à utiliser la version plus ancienne en définissant DD_EXTENSION_VERSION sur compatibility. Datadog vous encourage à signaler tout retour d’information ou tout bogue en ajoutant une issue sur GitHub et en taguant votre issue avec version/next.

Configurer l’auto-linking pour DynamoDB PutItem

Disponible pour les environnements d’exécution Python et Node.js Lorsque des segments de vos requêtes asynchrones ne peuvent pas propager le contexte de trace, la fonctionnalité Span Auto-linking de Datadog détecte automatiquement les spans liés. Pour activer le Span Auto-linking pour l’opération PutItem des Flux de changement DynamoDB, configurez les noms des clés primaires pour vos tables.

ddtrace.config.botocore['dynamodb_primary_key_names_for_tables'] = {
    'table_name': {'key1', 'key2'},
    'other_table': {'other_key'},
}

// Initialize the tracer with the configuration
const tracer = require('dd-trace').init({
  dynamoDb: {
    tablePrimaryKeys: {
      'table_name': ['key1', 'key2'],
      'other_table': ['other_key']
    }
  }
})

export DD_BOTOCORE_DYNAMODB_TABLE_PRIMARY_KEYS='{
    "table_name": ["key1", "key2"],
    "other_table": ["other_key"]
}'

Cela permet d’instrumenter les appels DynamoDB PutItem avec des pointeurs de span. De nombreux appels API DynamoDB n’incluent pas les champs de clé primaire de l’élément en tant que valeurs séparées, donc ils doivent être fournis au SDK séparément. La configuration ci-dessus est structurée comme un dictionnaire (dict) ou un objet indexé par les noms des tables sous forme de chaînes (str). Chaque valeur est l’ensemble des noms de champs de clé primaire (sous forme de chaînes) pour la table associée. L’ensemble peut avoir exactement un ou deux éléments, selon le schéma de clé primaire de la table.

Visualisez et modélisez les services AWS par nom de ressource

Ces versions des couches Lambda Node.js, Python et Java ont apporté des modifications pour nommer, modéliser et visualiser correctement les services gérés par AWS.

Les noms de service reflètent le nom réel de la ressource AWS plutôt que seulement le service AWS :

• aws.lambda → [function_name]
• aws.dynamodb → [table_name]
• aws.sns → [topic_name]
• aws.sqs → [queue_name]
• aws.kinesis → [stream_name]
• aws.s3 → [bucket_name]
• aws.eventbridge → [event_name]

Vous pouvez préférer l’ancien modèle de représentation des services si vos tableaux de bord et vos moniteurs dépendent de la convention de nommage héritée. Pour restaurer le comportement précédent, définissez la variable d’environnement : DD_TRACE_AWS_SERVICE_REPRESENTATION_ENABLED=false

La configuration de modélisation des services mise à jour est recommandée.

Envoyez les journaux vers les pipelines d’observabilité

Version 87+ of the Datadog Lambda Extension allows users to send logs to Observability Pipelines.

To enable this feature, set these environment variables:

• DD_OBSERVABILITY_PIPELINES_WORKER_LOGS_ENABLED: true
• DD_OBSERVABILITY_PIPELINES_WORKER_LOGS_URL: <YOUR_OBSERVABILITY_PIPELINE_URL>

Voir Envoyer les journaux de l’extension Lambda Datadog vers les pipelines d’observabilité pour plus d’informations.

Rechargez périodiquement le secret de la clé API

Si vous spécifiez la clé API Datadog en utilisant DD_API_KEY_SECRET_ARN, vous pouvez également définir DD_API_KEY_SECRET_RELOAD_INTERVAL pour recharger périodiquement le secret. Par exemple, si vous définissez DD_API_KEY_SECRET_RELOAD_INTERVAL sur 43200, alors le secret est rechargé lorsque la clé API est nécessaire pour envoyer des données, et qu’il s’est écoulé plus de 43200 secondes depuis le dernier chargement.

Exemple de cas d’utilisation : Pour des raisons de sécurité, chaque jour (86400 secondes), la clé API est renouvelée et le secret est mis à jour avec la nouvelle clé, tandis que l’ancienne clé API reste valide pendant un jour supplémentaire en tant que période de grâce. Dans ce cas, vous pouvez définir DD_API_KEY_SECRET_RELOAD_INTERVAL sur 43200, de sorte que la clé API soit rechargée pendant la période de grâce de l’ancienne clé.

Ceci est disponible pour la version 88+ de l’extension Datadog Lambda.

Déboguer

Si vous rencontrez des difficultés pour configurer vos installations, définissez la variable d’environnement DD_LOG_LEVEL sur debug pour les journaux de débogage. Pour des conseils supplémentaires de dépannage, consultez le guide de dépannage de la surveillance sans serveur.

Lectures complémentaires

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 Configurer AWS Lambda pour la surveillance sans serveur avec DatadogCENTRE D'APPRENTISSAGE