Primero, instala Datadog Serverless Monitoring para comenzar a recopilar métricas, trazas (traces) y logs. Cuando la instalación se complete, consulta los siguientes temas y configura la instalación según tus necesidades de monitorización.

• Conectar la telemetría mediante etiquetas (tags)
• Recopilar las cargas útiles de solicitud y respuesta
• Recopilar trazas procedentes de recursos distintos de Lambda
• Configurar el rastreador de Datadog
• Seleccionar las frecuencias de muestreo para la ingesta de tramos (spans) de APM
• Filtrar o borrar información confidencial de las trazas
• Habilitar y deshabilitar la recopilación de trazas
• Conectar logs y trazas
• Vincular errores al código fuente
• Enviar métricas personalizadas
• Recopilar datos de perfiles
• Enviar la telemetría a través de PrivateLink o un proxy
• Enviar la telemetría a varias organizaciones de Datadog
• Activar el cumplimiento de FIPS
• Propagar el contexto de las trazas en los recursos de AWS
• Fusionar las trazas de X-Ray y Datadog
• Habilitar la firma de código para AWS Lambda
• Migrar a la Datadog Lambda Extension
• Migrar de x86 a arm64 con la Datadog Lambda Extension
• Configurar la Datadog Lambda Extension para hacer tests locales
• Instrumentar AWS Lambda con la API de OpenTelemetry
• Uso de Datadog Lambda Extension v67+
• Configuración del enlace automático para PutItem de DynamoDB
• Visualización y modelado correcto de los servicios de AWS
• Envío de logs a Observability Pipelines
• Solucionar problemas
• Referencias adicionales

Habilitar la detección de amenazas para observar los intentos de ataque

Recibe alertas sobre los atacantes que apuntan a tus aplicaciones sin servidor y responde rápidamente.

Para empezar, asegúrate de tener el rastreo habilitado para tus funciones.

Para habilitar la monitorización de amenazas, añade las siguientes variables de entorno a tu despliegue:

environment:
  DD_SERVERLESS_APPSEC_ENABLED: true
  AWS_LAMBDA_EXEC_WRAPPER: /opt/datadog_wrapper

Vuelve a desplegar la función e invócala. Al cabo de unos minutos, aparece en las vistas AAP.

Para ver en acción la detección de amenazas a las aplicaciones y las API, envía patrones de ataque conocidos a tu aplicación. Por ejemplo, envía una cabecera HTTP con el valor acunetix-product para activar un intento de ataque al analizador de seguridad:

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

Unos minutos después de habilitar tu aplicación y enviar los patrones de ataque, la información sobre las amenazas aparece en el Application Signals Explorer.

Conectar la telemetría mediante etiquetas

Conecta la telemetría de Datadog a través del uso de etiquetas personalizadas y de etiquetas reservadas (env, service y version). Puedes utilizarlas para navegar fácilmente por métricas, trazas y logs. Añade los parámetros adicionales que se indican a continuación en función de tu método de instalación.

datadog-ci lambda instrument \
    --env dev \
    --service web \
    --version v1.2.3 \
    --extra-tags "team:avengers,project:marvel"
    # ... otros argumentos obligatorios, como los nombres de las funciones

custom:
  datadog:
    # ... otros parámetros obligatorios, como el sitio de Datadog y la clave de la API
    env: dev
    service: web
    version: v1.2.3
    tags: "team:avengers,project:marvel"

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... otros parámetros obligatorios, como el sitio de Datadog y la clave de la API
      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 también puede enriquecer la telemetría recopilada con las etiquetas de recursos de AWS definidas en tus funciones de Lambda con un retraso de unos minutos.

• Si quieres recopilar la telemetría de tus funciones de Lambda mediante la Datadog Lambda Extension, habilita la Integración de AWS para Datadog. Esta característica se creó para enriquecer la telemetría con etiquetas personalizadas. Las etiquetas reservadas de Datadog (env, service y version) deben definirse en las variables de entorno correspondientes (DD_ENV, DD_SERVICE y DD_VERSION respectivamente). Las etiquetas reservadas también pueden definirse mediante los parámetros que ofrecen las integraciones de Datadog con las herramientas de desarrollo serverless. Esta característica no es compatible con funciones de Lambda implementadas con imágenes de contenedor.

• Si quieres recopilar la telemetría de tus funciones de Lambda mediante la Función de Lambda del Datadog Forwarder, define la opción DdFetchLambdaTags como true en el stack tecnológico de CloudFormation de tu Datadog Forwarder. De forma predeterminada, el valor de esta opción es true desde la versión 3.19.0.

Recopilar las cargas útiles de solicitud y respuesta

Datadog puede recopilar y visualizar las cargas útiles de solicitud y respuesta JSON de las funciones de AWS Lambda. Esto te dará más datos sobre tus aplicaciones serverless y te ayudará a solucionar los errores de tu función de Lambda.

Esta característica está deshabilitada de forma predeterminada. Sigue las instrucciones que se indican a continuación en función del método de instalación que utilices.

datadog-ci lambda instrument \
    --capture-lambda-payload true
    # ... otros argumentos obligatorios, como los nombres de las funciones

custom:
  datadog:
    # ... otros parámetros obligatorios, como el sitio de Datadog y la clave de la API
    captureLambdaPayload: true

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... otros parámetros obligatorios, como el sitio de Datadog y la clave de la API
      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>]);

Para evitar que se envíe a Datadog información confidencial incluida en objetos JSON de solicitud o respuesta, puedes borrar parámetros específicos.

Para hacerlo, añade un archivo datadog.yaml nuevo a la misma carpeta del código de tu función de Lambda. Podrás enmascarar los campos en la carga útil de Lambda mediante el bloque replace_tags dentro de los parámetros de apm_config en el archivo datadog.yaml:

apm_config:
  replace_tags:
    # Reemplaza "foobar" cada vez que aparezca en cualquier etiqueta por "REDACTED":
    - name: "*"
      pattern: "foobar"
      repl: "REDACTED"
    # Reemplaza "auth" en los encabezados de solicitud por una cadena vacía
    - name: "function.request.headers.auth"
      pattern: "(?s).*"
      repl: ""
    # Reemplaza "apiToken" en la carga útil de respuesta por "****"
    - name: "function.response.apiToken"
      pattern: "(?s).*"
      repl: "****"

Como alternativa, puedes rellenar la variable de entorno DD_APM_REPLACE_TAGS en tu función de Lambda para enmascarar campos específicos:

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

Para recopilar cargas útiles de los servicios de AWS, consulta Capturar solicitudes y respuestas de los servicios de AWS.

Recopilar trazas procedentes de recursos distintos de Lambda

Datadog puede inferir tramos de APM en función de los eventos de Lambda entrantes para los recursos gestionados de AWS que activan la función de Lambda. Esto puede ayudarte a visualizar la relación entre los recursos gestionados de AWS e identificar problemas de rendimiento en tus aplicaciones serverless. Consulta más detalles sobre el producto.

Los siguientes recursos son compatibles en estos momentos:

• API Gateway (API REST, API HTTP y WebSocket)
• URL de funciones
• SQS
• SNS (los mensajes de SNS entregados a través de SQS también son compatibles)
• Flujos (streams) de Kinesis (si los datos son una cadena JSON o una cadena JSON codificada en base64)
• EventBridge (eventos personalizados, donde Details es una cadena JSON)
• S3
• DynamoDB

Para deshabilitar esta característica, define DD_TRACE_MANAGED_SERVICES como false.

DD_SERVICE_MAPPING

DD_SERVICE_MAPPING es una variable de entorno que cambia los nombres de los servicios distintos de Lambda anteriores. Opera con pares old-service:new-service.

Sintaxis

DD_SERVICE_MAPPING=key1:value1,key2:value2…

Hay dos formas de interactuar con esta variable:

Cambiar el nombre de todos los servicios de un tipo

Para cambiar el nombre de todos los servicios anteriores asociados a una integración de AWS Lambda, utiliza estos identificadores:

Cambiar el nombre de servicios específicos

Para un enfoque más granular, utiliza estos identificadores específicos de los servicios:

Ejemplos con descripción

Para cambiar el nombre de los servicios posteriores, consulta DD_SERVICE_MAPPING en la documentación de configuración del rastreador.

Configurar el rastreador de Datadog

Para ver qué bibliotecas y marcos instrumenta de forma automática el cliente de Datadog APM, consulta los Requisitos de compatibilidad para APM. Para instrumentar las aplicaciones personalizadas, consulta la guía de Datadog APM en la sección sobre instrumentación personalizada.

Seleccionar las frecuencias de muestreo para la ingesta de tramos de APM

Para gestionar la frecuencia de muestreo de invocaciones de APM rastreadas de las funciones sin servidor, configura la variable de entorno DD_TRACE_SAMPLING_RULES en la función con un valor entre 0.000 (sin rastreo de invocaciones de funciones Lambda) y 1.000 (con rastreo de todas las invocaciones de funciones Lambda).

Notas:

• El uso de DD_TRACE_SAMPLE_RATE está obsoleto. Utiliza DD_TRACE_SAMPLING_RULES en su lugar. Por ejemplo, si ya configuraste DD_TRACE_SAMPLE_RATE como 0.1, configura DD_TRACE_SAMPLING_RULES como [{"sample_rate":0.1}] en su lugar.
• Las métricas de tráfico globales como trace (traza).<OPERATION_NAME>.hits se calculan en función de las invocaciones muestreadas sólo en Lambda.

Para los servicios de alto rendimiento, normalmente no es necesario que recopiles todas las solicitudes, porque los datos de las trazas son muy repetitivos. Los problemas suficientemente graves siempre deberían poder detectarse en varias trazas. Los controles de ingesta te permiten solucionar los problemas sin salirte del presupuesto.

El mecanismo de muestreo predeterminado para la ingesta se denomina head-based sampling (muestreo basado en la fase inicial). La decisión sobre si se debe mantener o eliminar una traza se toma al inicio de la traza, cuando comienza el tramo raíz. Luego, esta decisión se propaga a otros servicios como parte de su contexto de solicitud, por ejemplo, un encabezado de solicitud HTTP. Como la decisión se toma al inicio de la traza y luego se transmite al resto de la traza, debes configurar la frecuencia de muestreo en el servicio raíz para que surta efecto.

Cuando Datadog ingiere los tramos, el filtro de retención inteligente de Datadog indexa una proporción de trazas que contribuye a la monitorización del estado de tus aplicaciones. También puedes definir filtros de retención personalizados para indexar los datos de trazas que quieras mantener durante más tiempo para ayudar a alcanzar los objetivos de tu organización.

Obtén más información acerca del Datadog Trace Pipeline.

Filtrar o borrar información confidencial de las trazas

Para filtrar las trazas antes de enviarlas a Datadog, consulta Ignorar los recursos no deseados en APM.

Para borrar atributos de trazas por razones de seguridad de los datos, consulta Configurar el Datadog Agent o su rastreador para la seguridad de los datos.

Habilitar y deshabilitar la recopilación de trazas

La recopilación de trazas (traces) a través de la extensión Datadog Lambda está activada por defecto.

Si quieres empezar a recopilar las trazas de tus funciones de Lambda, aplica las configuraciones que se indican a continuación:

datadog-ci lambda instrument \
    --tracing true
    # ... otros argumentos obligatorios, como los nombres de las funciones

custom:
  datadog:
    # ... otros parámetros obligatorios, como el sitio de Datadog y la clave de la API
    enableDDTracing: true

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... otros parámetros obligatorios, como el sitio de Datadog y la clave de la API
      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>]);

Deshabilitar la recopilación de trazas

Si quieres dejar de recopilar las trazas de tus funciones de Lambda, aplica las configuraciones que se indican a continuación:

datadog-ci lambda instrument \
    --tracing false
    # ... otros argumentos obligatorios, como los nombres de las funciones

custom:
  datadog:
    # ... otros parámetros obligatorios, como el sitio de Datadog y la clave de la API
    enableDDTracing: false

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... otros parámetros obligatorios, como el sitio de Datadog y la clave de la API
      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>]);

Conectar logs y trazas

Si usas la extensión de Lambda para recopilar trazas y logs, Datadog añade automáticamente el ID de solicitud de AWS Lambda al tramo aws.lambda en la etiqueta request_id. Además, los logs de Lambda para la misma solicitud se añaden en el atributo lambda.request_id. Las vistas de trazas y logs de Datadog se vinculan mediante el uso del ID de solicitud de AWS Lambda.

Si estás utilizando la función del Forwarder Lambda para recopilar trazas y logs, dd.trace_id se inyecta automáticamente en logs (habilitado por defecto con la variable de entorno DD_LOGS_INJECTION). Las vistas de traza y log de Datadog se conectan utilizando el ID de traza de Datadog. Esta característica es compatible con la mayoría de las aplicaciones que utilizan un tiempo de ejecución y un registrador populares (ver compatibilidad por tiempo de ejecución).

Si usas un tiempo de ejecución o un logger personalizado no compatible, sigue estos pasos:

• Al generar logs en JSON, debes obtener el ID de traza de Datadog mediante dd-trace y añadirlo a tus logs en el campo dd.trace_id:

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

• Para generar logs de texto sin formato, tienes que hacer lo siguiente:
  1. Obtén el ID de traza de Datadog mediante dd-trace y añádelo a tu log.
  2. Clona el pipeline de logs de Lambda predeterminado, que es de solo lectura.
  3. Habilita el pipeline clonado y deshabilita el predeterminado.
  4. Actualiza las reglas del analizador Grok del pipeline clonado para analizar el ID de traza de Datadog en el atributo dd.trace_id. Por ejemplo, utiliza la regla my_rule \[%{word:level}\]\s+dd.trace_id=%{word:dd.trace_id}.* para los logs que tengan este aspecto [INFO] dd.trace_id=4887065908816661012 My log message.

Vincular errores al código fuente

La integración del código fuente de Datadog te permite vincular tu telemetría (como trazas de stack tecnológico) al código fuente de tus funciones Lambda en tus repositorios Git.

Para obtener instrucciones sobre cómo configurar la integración del código fuente en tus aplicaciones serverless, consulta la sección Integrar información de Git en los artefactos de compilación.

Recopilar datos de perfiles

El Continuous Profiler de Datadog está disponible en Vista Previa para Python versión 4.62.0 y para la capa versión 62 y anteriores. Esta función opcional se activa configurando la variable de entorno DD_PROFILING_ENABLED como true.

Continuous Profiler genera un subproceso que toma periódicamente una snapshot de la CPU y el montículo de todo el código de Python en ejecución. Esto puede incluir el propio generador de perfiles. Si quieres que el generador de perfiles se ignore a sí mismo, define DD_PROFILING_IGNORE_PROFILER como true.

Enviar la telemetría a través de PrivateLink o un proxy

La Datadog Lambda extension necesita acceder a la red pública de Internet para enviar datos a Datadog. Si tus funciones de Lambda están desplegadas en una VPC sin acceso a una red pública, puedes enviar datos a través de AWS PrivateLink al sitio de Datadog datadoghq.com o a través de un proxy para cualquier otro sitio.

Si usas el Datadog Forwarder, sigue estas instrucciones.

Enviar la telemetría a varias organizaciones de Datadog

Si quieres enviar datos a varias organizaciones, puedes habilitar el envío múltiple con una clave de API de texto sin formato, AWS Secrets Manager o 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}]

Para obtener información sobre un uso más avanzado, consulta la guía de Envío múltiple.

Habilitar el cumplimiento FIPS

Para habilitar el cumplimiento de FIPS de las funciones AWS Lambda, sigue estos pasos:

1. Utiliza una capa de extensión que cumpla con FIPS haciendo referencia al ARN apropiado:

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

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

2. Para las funciones Lambda que utilizan Python, JavaScript o Go, configura la variable de entorno DD_LAMBDA_FIPS_MODE como true. Esta variable de entorno:

   • En el modo FIPS, las funciones auxiliares para métricas de Lambda requieren la extensión que cumpla con FIPS para el envío de métricas
   • Utiliza endpoints AWS FIPS para la búsqueda de claves de API
   • Está activado por defecto en los entornos GovCloud

3. Para las funciones Lambda que utilizan Ruby, .NET o Java, no es necesario configurar ninguna variable de entorno adicional.

4. Para un cumplimiento de FIPS completo de extremo a extremo, configura tu función Lambda para utilizar el sitio US1-FED de Datadog:

   • Configura DD_SITE en ddog-gov.com (necesario para el cumplimiento de FIPS de extremo a extremo). Nota: Aunque los componentes Lambda que cumplen con FIPS funcionan con cualquier sitio de Datadog, sólo el sitio US1-FED dispone de endpoints de entrada que cumplen con FIPS.

Propagar el contexto de las trazas en los recursos de AWS

Datadog inyecta de forma automática el contexto de las trazas en las solicitudes de AWS SDK salientes y extrae el contexto de las trazas del evento de Lambda. Esto le permite rastrear una solicitud o transacción a través de servicios distribuidos. Consulta Propagación de trazas serverless.

Fusionar las trazas de X-Ray y Datadog

AWS X-Ray es compatible con el rastreo a través de determinados servicios gestionados de AWS, como AppSync y Step Functions, que no son compatibles con Datadog APM de forma nativa. Puedes habilitar la integración de X-Ray para Datadog y fusionar las trazas de X-Ray con las trazas nativas de Datadog. Consulta más información al respecto.

Habilitar la firma de código para AWS Lambda

La firma de código para AWS Lambda ayuda a garantizar que solo el código de confianza procedente de tus funciones de Lambda se despliega en AWS. Cuando habilitas la firma de código en tus funciones, AWS comprueba que todo el código de tus despliegues contenga una firma de un origen conocido, que tú defines en la configuración de la firma de código.

Si tus funciones de Lambda están configuradas para utilizar una firma de código, debes añadir el ARN del perfil de firma de Datadog a la configuración de firma de código de tu función antes de poder desplegar tus funciones de Lambda mediante el uso de las capas de Lambda que publica Datadog.

ARN del perfil de firma de Datadog:

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

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

Migrar a la Datadog Lambda Extension

Datadog puede recopilar los datos de monitorización de tus funciones de Lambda mediante la función de Lambda del Forwarder o la extensión de Lambda. Datadog recomienda utilizar la extensión para las instalaciones nuevas. Si no lo tienes claro, consulta Decidir migrar a la Datadog Lambda Extension.

Para proceder con la migración, compara las instrucciones de instalación de la Datadog Lambda Extension con las instrucciones del Datadog Forwarder. Las principales diferencias se resumen a continuación:

Nota: Datadog recomienda migrar las aplicaciones de desarrollo y de prueba primero y las aplicaciones de producción una por una.

Migrar de x86 a arm64 con la Datadog Lambda Extension

La extensión de Datadog es un archivo binario compilado, disponible en x86 y arm64. Si vas a migrar una función de Lambda de x86 a arm64 (o de arm64 a x86) mediante una herramienta de despliegue como el CDK, Serverless Framework o SAM, asegúrate de que la integración de tu servicio (como API Gateway, SNS o Kinesis) esté configurada para utilizar versiones o alias de una función de Lambda. De lo contrario, la función no estará disponible durante unos diez segundos durante el despliegue.

Esto ocurre porque migrar una función de Lambda de x86 a arm64 se hace mediante dos llamadas paralelas a la API, updateFunction y updateFunctionConfiguration. Durante estas llamadas, existe un breve periodo en el que la llamada de Lambda updateFunction y el código se actualizan para utilizar la arquitectura nueva, pero la llamadaupdateFunctionConfiguration aún no se completa, por lo que la arquitectura antigua sigue configurada para la extensión.

Si no puedes usar versiones de capa, Datadog recomienda configurar el Datadog Forwarder durante el proceso de migración de la arquitectura.

Configurar la Datadog Lambda Extension para hacer tests locales

No todos los emuladores Lambda son compatibles con la API de telemetría de AWS Lambda. Para probar la imagen de contenedor de tu función Lambda de forma local con la extensión Datadog Lambda instalada, necesitas configurar DD_SERVERLESS_FLUSH_STRATEGY en periodically,1 en tu entorno de test local. De lo contrario, la extensión esperará las respuestas de la API de telemetría de AWS Lambda y bloqueará la invocación.

Instrumentar AWS Lambda con la API de OpenTelemetry

La biblioteca de rastreo de Datadog, que se incluye en la Datadog Lambda Extension tras su instalación, acepta los tramos y trazas generados a partir del código instrumentado por OpenTelemetry, procesa la telemetría y la envía a Datadog.

Puedes utilizar este enfoque si, por ejemplo, tu código ya se instrumentó con la API de OpenTelemetry. También puedes utilizar este enfoque si quieres instrumentar mediante código agnóstico del proveedor con la API de OpenTelemetry sin dejar de obtener los beneficios de utilizar las bibliotecas de rastreo de Datadog.

Para instrumentar AWS Lambda con la API de OpenTelemetry, define la variable de entorno DD_TRACE_OTEL_ENABLED como true. Consulta Instrumentación personalizada con la API de OpenTelemetry para obtener más detalles.

Uso de Datadog Lambda Extension v67+

La versión 67+ de Datadog Extension está optimizada para reducir significativamente la duración del arranque en frío. Para utilizar la extensión optimizada, establece la variable de entorno DD_SERVERLESS_APPSEC_ENABLED en false. Cuando la variable de entorno DD_SERVERLESS_APPSEC_ENABLED se establece en true, la Datadog Extension utiliza por defecto la versión anterior totalmente compatible. También puedes forzar a tu extensión a utilizar la versión anterior configurando DD_EXTENSION_VERSION en compatibility. Datadog te anima a informar de cualquier comentario o error añadiendo una incidencia en GitHub y etiquetando tu incidencia con version/next.

Configuración del enlace automático para PutItem de DynamoDB

Disponible para los tiempos de ejecución de Python y Node.js. Cuando los segmentos de tus solicitudes asíncronas no pueden propagar el contexto de traza, la función enlace automático de tramos de Datadog detecta automáticamente los tramos vinculados. Para habilitar el enlace automático de tramos para la operación PutItem de DynamoDB Change Streams, configura nombres de clave primaria para tus tablas.

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"]
}'

Esto permite instrumentar las llamadas PutItem a DynamoDB con punteros a tramo. Muchas llamadas a la API de DynamoDB no incluyen los campos de clave principal del elemento como valores independientes, por lo que deben proporcionarse al rastreador por separado. La configuración anterior está estructurada como un diccionario (dict) u objeto cuya clave son los nombres de tabla como cadenas (str). Cada valor es el conjunto de nombres de campo de clave primaria (como cadenas) para la tabla asociada. El conjunto puede tener exactamente uno o dos elementos, dependiendo del esquema de clave primaria de la tabla.

Visualización y modelado de los servicios de AWS por nombre de recurso

Estas versiones de las capas Lambda de Node.js, Python y Java lanzaron cambios para nombrar, modelar y visualizar correctamente los servicios gestionados de AWS.

Los nombres de los servicios reflejan el nombre real del recurso de AWS y no solo el servicio de 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]

Es posible que prefieras el modelo de representación de servicios anterior si tus dashboards y monitores dependen de la convención de nomenclatura heredada. Para restaurar el comportamiento anterior, establece la variable de entorno: DD_TRACE_AWS_SERVICE_REPRESENTATION_ENABLED=false

Se recomienda la configuración actualizada del modelado de servicios.

Envío de logs a Observability Pipelines

La versión 87+ de la Datadog Lambda Extension permite a los usuarios enviar logs a Observability Pipelines.

Para activar esta función, establece estas variables de entorno:

• DD_OBSERVABILITY_PIPELINES_WORKER_LOGS_ENABLED: true
• DD_OBSERVABILITY_PIPELINES_WORKER_LOGS_URL: <YOUR_OBSERVABILITY_PIPELINE_URL>

Nota: Tu Observability pipeline debe utilizar Http Server como fuente para procesar logs de Lambda Extension. No utilices Datadog Agent como fuente.

Solucionar problemas

Si tienes problemas para configurar tus instalaciones, define la variable de entorno DD_LOG_LEVEL como debug en los logs de depuración. Para obtener más consejos sobre cómo solucionar problemas, consulta la guía de solución de problemas de la monitorización serverless.

Referencias adicionales

Más enlaces, artículos y documentación útiles:

Instalar Serverless Monitoring para AWS LambdaDOCUMENTACIÓN Solucionar problemas relacionados con Serverless Monitoring para AWS LambdaDOCUMENTACIÓN Integración de GitHub para DatadogDOCUMENTACIÓN