Primero, instala Serverless Monitoring de Datadog para comenzar a recopilar métricas, trazas y registros. Una vez que la instalación esté completa, consulta los siguientes temas para configurar tu instalación según tus necesidades de monitoreo.

• Conectar telemetría usando etiquetas
• Recopilar las cargas útiles de solicitud y respuesta
• Recopilar trazas de recursos que no son Lambda
• Configurar el SDK de Datadog
• Seleccionar tasas de muestreo para la ingestión de spans de APM
• Filtrar o eliminar información sensible de las trazas
• Habilitar/deshabilitar la recopilación de trazas
• Conectar registros y trazas
• Vincular errores a tu código fuente
• Enviar métricas personalizadas
• Recopilar datos de perfilado
• Envía telemetría a través de PrivateLink o proxy
• Envía telemetría a múltiples organizaciones de Datadog
• Habilita el cumplimiento de FIPS
• Propaga el contexto de trazas a través de los recursos de AWS
• Fusiona las trazas de X-Ray y Datadog
• Habilita la firma de código de AWS Lambda
• Migra a la extensión de Datadog Lambda
• Migrando de x86 a arm64 con la extensión de Datadog Lambda
• Configura la extensión de Datadog Lambda para pruebas locales
• Instrumenta AWS Lambda con la API de OpenTelemetry
• Usando la extensión de Datadog Lambda v67+
• Configura el enlace automático para DynamoDB PutItem
• Visualiza y modela los servicios de AWS correctamente
• Envía registros a los Pipelines de Observabilidad
• Recarga el secreto de la clave API periódicamente
• Soluciona problemas
• Lectura adicional

Habilita la detección de amenazas para observar intentos de ataque

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

Para comenzar, primero asegúrate de que tienes traza habilitada para tus funciones.

Para habilitar el seguimiento de amenazas, agregue las siguientes variables de entorno a su implementación:

environment:
  DD_SERVERLESS_APPSEC_ENABLED: true
  AWS_LAMBDA_EXEC_WRAPPER: /opt/datadog_wrapper

Vuelva a implementar la función e invóquela. Después de unos minutos, aparece en vistas de AAP.

Para ver la detección de amenazas de Protección de Aplicaciones y API en acción, envíe patrones de ataque conocidos a su aplicación. Por ejemplo, envíe un encabezado HTTP con el valor acunetix-product para activar un intento de ataque de escáner de seguridad:

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

Unos minutos después de habilitar su aplicación y enviar los patrones de ataque, aparece información de amenazas en el Explorador de Señales de Aplicación.

Conecte la telemetría utilizando etiquetas

Conecte la telemetría de Datadog a través del uso de etiquetas reservadas (env, service y version) y etiquetas personalizadas. Puede usar estas etiquetas para navegar sin problemas a través de métricas, trazas y registros. Agregue los parámetros adicionales a continuación para el método de instalación que utiliza.

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 también puede enriquecer la telemetría recopilada con las etiquetas de recurso de AWS existentes definidas en tus funciones Lambda con un retraso de unos minutos.

• Si estás recopilando telemetría de tus funciones Lambda utilizando la extensión Lambda de Datadog, habilita la integración de AWS de Datadog. Esta función está destinada a enriquecer tu telemetría con etiquetas personalizadas. Las etiquetas reservadas de Datadog (env, service y version) deben establecerse a través de las variables de entorno correspondientes (DD_ENV, DD_SERVICE y DD_VERSION respectivamente). Las etiquetas reservadas también se pueden establecer con los parámetros proporcionados por las integraciones de Datadog con las herramientas de desarrollo sin servidor. Esta función no funciona para las funciones de Lambda desplegadas con imágenes de contenedor.

• Si está recopilando telemetría de sus funciones de Lambda utilizando la función Lambda de Datadog Forwarder, establezca la opción DdFetchLambdaTags en true en la pila de CloudFormation para su Datadog Forwarder. Esta opción tiene como valor predeterminado verdadero desde la versión 3.19.0.

Recopila las cargas útiles de solicitud y respuesta

Datadog puede recopilar y visualizar las cargas útiles de solicitud y respuesta en JSON de las funciones de AWS Lambda, brindándole una visión más profunda de sus aplicaciones sin servidor y ayudando a solucionar fallas en las funciones de Lambda.

Esta función está deshabilitada por defecto. Sigue las instrucciones a continuación para el método de instalación que utilizas.

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>]);

Para evitar que se envíen datos sensibles dentro de los objetos JSON de solicitud o respuesta a Datadog, puede eliminar parámetros específicos.

Para hacer esto, agregue un nuevo archivo datadog.yaml en la misma carpeta que el código de su función Lambda. La ofuscación de campos en la carga útil de Lambda está disponible a través del bloque replace_tags dentro de la configuración de apm_config en 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: "****"

Como alternativa, también puede poblar la variable de entorno DD_APM_REPLACE_TAGS en su función Lambda para ofuscar 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 servicios de AWS, consulte Capturar Solicitudes y Respuestas de Servicios de AWS.

Recopile trazas de recursos que no son de Lambda

Datadog puede inferir los spans de APM basándose en los eventos de Lambda entrantes para los recursos administrados por AWS que activan la función de Lambda. Esto puede ayudar a visualizar la relación entre los recursos administrados por AWS e identificar problemas de rendimiento en sus aplicaciones Serverless. Consulte detalles adicionales del producto.

Los siguientes recursos son actualmente compatibles:

• API Gateway (API REST, API HTTP y WebSocket)
• URLs de función
• SQS
• SNS (los mensajes de SNS entregados a través de SQS también son compatibles)
• Kinesis Streams (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 desactivar esta función, establezca DD_TRACE_MANAGED_SERVICES en false.

DD_SERVICE_MAPPING

DD_SERVICE_MAPPING es una variable de entorno que renombra los nombres de servicios upstream no Lambda. Funciona con old-service:new-service pares.

Sintaxis

DD_SERVICE_MAPPING=key1:value1,key2:value2…

Hay dos formas de interactuar con esta variable:

Renombrar todos los servicios de un tipo

Para renombrar todos los servicios upstream asociados con una integración de AWS Lambda, utilice estos identificadores:

Renombrar servicios específicos

Para un enfoque más granular, utilice estos identificadores específicos de servicio:

Ejemplos con descripción

Para renombrar servicios descendentes, consulte DD_SERVICE_MAPPING en la documentación de configuración del rastreador.

Configurar el SDK de Datadog

Para ver qué bibliotecas y marcos están instrumentados automáticamente por el cliente APM de Datadog, consulte Requisitos de compatibilidad para APM. Para instrumentar aplicaciones personalizadas, consulte la guía de APM de Datadog para instrumentación personalizada.

Seleccione tasas de muestreo para la ingestión de spans de APM

Para gestionar la tasa de muestreo de invocación rastreada por APM para funciones Serverless, establezca la variable de entorno DD_TRACE_SAMPLING_RULES en un valor entre 0.000 (sin rastreo de invocaciones de funciones Lambda) y 1.000 (rastrear todas las invocaciones de funciones Lambda).

Notas:

• El uso de DD_TRACE_SAMPLE_RATE está en desuso. Utilice DD_TRACE_SAMPLING_RULES en su lugar. Por ejemplo, si ya configuró DD_TRACE_SAMPLE_RATE a 0.1, configure DD_TRACE_SAMPLING_RULES a [{"sample_rate":0.1}] en su lugar.
• Las métricas de tráfico generales, como trace.<OPERATION_NAME>.hits, se calculan en función de las invocaciones muestreadas solo en Lambda.

Para servicios de alto rendimiento, generalmente no es necesario que recoja cada solicitud individual, ya que los datos de trazas son muy repetitivos; un problema lo suficientemente importante siempre debería mostrar síntomas en múltiples trazas. Los controles de ingestión le ayudan a tener la visibilidad que necesita para solucionar problemas mientras se mantiene dentro del presupuesto.

El mecanismo de muestreo predeterminado para la ingestión se llama head-based sampling. La decisión de mantener o descartar una traza se toma al principio de la traza, al inicio del span raíz. Esta decisión se propaga a otros servicios como parte de su contexto de solicitud, por ejemplo, como un encabezado de solicitud HTTP. Debido a que la decisión se toma al inicio de la traza y luego se transmite a todas las partes de la traza, debe configurar la tasa de muestreo en el servicio raíz para que tenga efecto.

Después de que los spans han sido ingeridos por Datadog, el Filtro de Retención Inteligente de Datadog indexa una proporción de trazas para ayudarle a monitorear la salud de sus aplicaciones. También puede definir filtros de retención personalizados para indexar los datos de trazas que desea conservar por más tiempo para apoyar los objetivos de su organización.

Aprenda más sobre la Canalización de Trazas de Datadog.

Filtrar o eliminar información sensible de las trazas

Para filtrar trazas antes de enviarlas a Datadog, consulte Ignorando Recursos No Deseados en APM.

Para eliminar atributos de trazas por seguridad de datos, consulte Configurar el Agente de Datadog o el Rastreador para Seguridad de Datos.

Habilitar/deshabilitar la recolección de trazas

La recolección de trazas a través de la extensión de Lambda de Datadog está habilitada por defecto.

Si desea comenzar a recolectar trazas de sus funciones de Lambda, aplique las configuraciones a continuación:

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>]);

Deshabilitar la recolección de trazas

Si desea dejar de recolectar trazas de sus funciones de Lambda, aplique las configuraciones a continuación:

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>]);

Conecte registros y trazas

Si está utilizando la extensión de Lambda para recolectar trazas y registros, Datadog agrega automáticamente el ID de solicitud de AWS Lambda al aws.lambda span bajo la etiqueta request_id. Además, los registros de Lambda para la misma solicitud se agregan bajo el atributo lambda.request_id. Las vistas de trazas y registros de Datadog están conectadas utilizando el ID de solicitud de AWS Lambda.

Si está utilizando la función Lambda Forwarder para recopilar trazas y registros, dd.trace_id se inyecta automáticamente en los registros (habilitado por defecto con la variable de entorno DD_LOGS_INJECTION). Las vistas de trazas y registros de Datadog están conectadas utilizando el ID de traza de Datadog. Esta función es compatible con la mayoría de las aplicaciones que utilizan un runtime y un registrador populares (consulte el soporte por runtime).

Si está utilizando un runtime o un registrador personalizado que no es compatible, siga estos pasos:

• Al registrar en JSON, necesita obtener el ID de traza de Datadog utilizando dd-trace y agregarlo a sus registros bajo el campo dd.trace_id:

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

• Al registrar en texto plano, necesita:
  1. Obtener el ID de traza de Datadog utilizando dd-trace y agregarlo a su registro.
  2. Clonar la canalización de registro de Lambda predeterminada, que es de solo lectura.
  3. Habilitar la canalización clonada y deshabilitar la predeterminada.
  4. Actualizar las reglas del parser Grok de la canalización clonada para analizar el ID de traza de Datadog en el atributo dd.trace_id. Por ejemplo, utilice la regla my_rule \[%{word:level}\]\s+dd.trace_id=%{word:dd.trace_id}.* para registros que se vean como [INFO] dd.trace_id=4887065908816661012 My log message.

Vincule errores a su código fuente

La integración del código fuente de Datadog le permite vincular su telemetría (como trazas de pila) al código fuente de sus funciones Lambda en sus repositorios de Git.

Para obtener instrucciones sobre cómo configurar la integración del código fuente en sus aplicaciones sin servidor, consulte la sección Incrustar información de Git en sus artefactos de construcción.

Recopilar datos de perfilado

El Profiler Continuo de Datadog está disponible en Vista Previa para la versión 4.62.0 del tracer de Python y la versión 62 de la capa y anteriores. Esta función opcional se habilita configurando la variable de entorno DD_PROFILING_ENABLED a true.

El Profiler Continuo funciona generando un hilo que toma periódicamente una instantánea de la CPU y el heap de todo el código Python en ejecución. Esto puede incluir el propio profiler. Si deseas que el profiler se ignore a sí mismo, establece DD_PROFILING_IGNORE_PROFILER en true.

Envía telemetría a través de PrivateLink o proxy

La Extensión de Lambda de Datadog necesita acceso a internet público para enviar datos a Datadog. Si tus funciones de Lambda están desplegadas en una VPC sin acceso a internet público, puedes enviar datos a través de AWS PrivateLink al datadoghq.com sitio de Datadog, o enviar datos a través de un proxy para todos los demás sitios.

Si estás utilizando el Forwarder de Datadog, sigue estas instrucciones.

Envía telemetría a múltiples organizaciones de Datadog

Si deseas enviar datos a múltiples organizaciones, puedes habilitar el envío dual utilizando una clave API en texto plano, 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 un uso más avanzado, consulta la guía de envío dual.

Habilita la conformidad con FIPS

Para habilitar la conformidad con FIPS para funciones de AWS Lambda, sigue estos pasos:

1. Usa una capa de extensión compatible con FIPS haciendo referencia al ARN apropiado:

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

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

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

   • En modo FIPS, las funciones auxiliares de métricas de Lambda requieren la extensión compatible con FIPS para la presentación de métricas
   • Utiliza puntos de conexión FIPS de AWS para búsquedas de claves API
   • Está habilitado por defecto en entornos de GovCloud

3. Para funciones de Lambda que utilizan Ruby, .NET o Java, no se necesita configuración adicional de la variable de entorno.

4. Para cumplir completamente con FIPS, configure su función de Lambda para usar un sitio de Datadog para Gobierno:

   • Establezca DD_SITE en ddog-gov.com (US1-FED) o us2.ddog-gov.com (US2-FED) Nota: Si bien los componentes de Lambda compatibles con FIPS funcionan con cualquier sitio de Datadog, solo los sitios de Datadog para Gobierno tienen puntos finales de recepción compatibles con FIPS.

Propague el contexto de traza a través de recursos de AWS

Datadog inyecta automáticamente el contexto de traza en las solicitudes salientes del SDK de AWS y extrae el contexto de traza del evento de Lambda. Esto permite a Datadog rastrear una solicitud o transacción a través de servicios distribuidos. Vea Propagación de Traza Serverless.

Fusionar traza de X-Ray y Datadog

AWS X-Ray admite el seguimiento a través de ciertos servicios administrados por AWS, como AppSync y Step Functions, lo cual no es compatible de forma nativa con Datadog APM. Puede habilitar la integración de Datadog X-Ray y fusionar la traza de X-Ray con la traza nativa de Datadog. Vea detalles adicionales.

Habilite la firma de código de AWS Lambda

La firma de código para AWS Lambda ayuda a garantizar que solo se implemente código de confianza desde sus funciones Lambda a AWS. Cuando habilita la firma de código en sus funciones, AWS valida que todo el código en sus implementaciones esté firmado por una fuente confiable, que usted define en su configuración de firma de código.

Si sus funciones Lambda están configuradas para usar la firma de código, debe agregar el ARN del Perfil de Firma de Datadog a la configuración de firma de código de su función antes de poder implementar funciones Lambda utilizando las Capas de Lambda publicadas por Datadog.

ARN del Perfil de Firma de Datadog:

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

Migre a la extensión de Datadog Lambda

Datadog puede recopilar los datos de monitoreo de sus funciones Lambda utilizando ya sea la función Lambda Forwarder o la extensión Lambda. Datadog recomienda la extensión Lambda para nuevas instalaciones. Si no está seguro, consulte Decidir migrar a la extensión de Datadog Lambda.

Para migrar, compare las instrucciones de instalación utilizando la Extensión de Datadog Lambda con las instrucciones utilizando el Forwarder de Datadog. Para su conveniencia, las diferencias clave se resumen a continuación.

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

Migrando de x86 a arm64 con la extensión Datadog Lambda

La extensión Datadog es un binario compilado, disponible en variantes x86 y arm64. Si estás migrando una función Lambda x86 a arm64 (o de arm64 a x86) utilizando una herramienta de despliegue como CDK, Serverless Framework o SAM, asegúrate de que tu integración de servicio (como API Gateway, SNS o Kinesis) esté configurada para usar las versiones o alias de la función Lambda, de lo contrario, la función puede no estar disponible durante aproximadamente diez segundos durante el despliegue.

Esto sucede porque migrar una función Lambda de x86 a arm64 consiste en dos llamadas API paralelas, updateFunction y updateFunctionConfiguration. Durante estas llamadas, hay una breve ventana donde la llamada updateFunction de Lambda se ha completado y el código se actualiza para usar la nueva arquitectura, mientras que la llamada updateFunctionConfiguration aún no se ha completado, por lo que la antigua arquitectura sigue configurada para la extensión.

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

Configura la extensión Datadog Lambda para pruebas locales

No todos los emuladores de Lambda son compatibles con la API de Telemetría de AWS Lambda. Para probar la imagen de contenedor de tu función Lambda localmente con la extensión Datadog Lambda instalada, necesitas establecer DD_SERVERLESS_FLUSH_STRATEGY en periodically,1 en tu entorno de pruebas local. De lo contrario, la extensión espera respuestas de la API de Telemetría de AWS Lambda y bloquea la invocación.

Instrumenta AWS Lambda con la API de OpenTelemetry

El SDK de Datadog, que se incluye en la extensión Datadog Lambda al instalarla, acepta los spans y trazas generados por el código instrumentado con OpenTelemetry, procesa la telemetría y la envía a Datadog.

Puedes usar este enfoque si, por ejemplo, tu código ya ha sido instrumentado con la API de OpenTelemetry. También puedes usar este enfoque si deseas instrumentar utilizando código independiente del proveedor con la API de OpenTelemetry mientras sigues obteniendo los beneficios de usar los SDK de Datadog.

Para instrumentar AWS Lambda con la API de OpenTelemetry, establece la variable de entorno DD_TRACE_OTEL_ENABLED en true. Consulte Instrumentación personalizada con la API de OpenTelemetry para más detalles.

Uso de Lambda Extension de Datadog v67+

La versión 67+ de la Extensión de Datadog está optimizada para reducir significativamente la duración del inicio en frío. Para usar la extensión optimizada, establezca la variable de entorno DD_SERVERLESS_APPSEC_ENABLED en false. Cuando la variable de entorno DD_SERVERLESS_APPSEC_ENABLED está establecida en true, la Extensión de Datadog predetermina a la versión anterior completamente compatible. También puede forzar a su extensión a usar la versión anterior estableciendo DD_EXTENSION_VERSION en compatibility. Datadog le anima a reportar cualquier comentario o error añadiendo un problema en GitHub y etiquetando su problema con version/next.

Configure el enlace automático para DynamoDB PutItem

Disponible para entornos de Python y Node.js. Cuando los segmentos de sus solicitudes asíncronas no pueden propagar el contexto de traza, la función de Enlace automático de tramos de Datadog detecta automáticamente los tramos vinculados. Para habilitar el enlace automático de Span para la operación PutItem de DynamoDB Change Streams, configure los nombres de las claves primarias para sus 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 que las llamadas a DynamoDB PutItem sean instrumentadas con punteros de tramo. Muchas llamadas a la API de DynamoDB no incluyen los campos de clave primaria del ítem como valores separados, por lo que deben proporcionarse al SDK por separado. La configuración anterior está estructurada como un diccionario (dict) u objeto con claves que son los nombres de las tablas como cadenas (str). Cada valor es el conjunto de nombres de campos 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.

Visualice y modele 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 administrados de AWS.

Los nombres de los servicios reflejan el nombre real del recurso de AWS en lugar de 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]

Puede preferir el modelo de representación de servicio anterior si sus dashboards y monitors dependen de la convención de nombres heredada. Para restaurar el comportamiento anterior, establezca la variable de entorno: DD_TRACE_AWS_SERVICE_REPRESENTATION_ENABLED=false

Se recomienda la configuración de modelado de servicio actualizada.

Envía registros a Observability Pipelines

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>

Consulte Enviar registros de Datadog Lambda Extension Forwarder a Observability Pipelines para más información.

Recargue el secreto de la clave de API periódicamente

Si especifica la clave de API de Datadog usando DD_API_KEY_SECRET_ARN, también puede establecer DD_API_KEY_SECRET_RELOAD_INTERVAL para recargar periódicamente el secreto. Por ejemplo, si establece DD_API_KEY_SECRET_RELOAD_INTERVAL en 43200, entonces el secreto se recarga cuando se necesita la clave de API para enviar datos, y ha pasado más de 43200 segundos desde la última carga.

Caso de uso de ejemplo: Por seguridad, cada día (86400 segundos), la clave de API se rota y el secreto se actualiza a la nueva clave, y la clave de API anterior se mantiene válida por otro día como período de gracia. En este caso, puede establecer DD_API_KEY_SECRET_RELOAD_INTERVAL en 43200, de modo que la clave de API se recargue durante el período de gracia de la clave anterior.

Esto está disponible para la versión 88+ de la Datadog Lambda Extension.

Solucionar problemas

Si tiene problemas configurando sus instalaciones, establezca la variable de entorno DD_LOG_LEVEL en debug para los registros de depuración. Para obtener consejos adicionales de solución de problemas, consulte la guía de solución de problemas de monitoreo sin servidor.

Lectura adicional

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

Instalar Serverless Monitoring para AWS LambdaDOCUMENTACIÓN Solucionar problemas de Serverless Monitoring para AWS LambdaDOCUMENTACIÓN Integración de Datadog con GitHubDOCUMENTACIÓN Configurar AWS Lambda para Serverless Monitoring con DatadogCENTRO DE APRENDIZAJE