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
• 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 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 la creación de perfiles (beta pública)
• Enviar la telemetría a través de PrivateLink o un proxy
• Enviar la telemetría a varias organizaciones de Datadog
• 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
• Solucionar problemas
• Referencias adicionales

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

Recibe alertas sobre atacantes que tengan como objetivo tus aplicaciones serverless y responde con rapidez.

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, aparecerá en las vistas ASM.

Para ver la detección de amenazas de Application Security Management en acción, envía patrones de ataque conocidos a tu aplicación. Por ejemplo, envía un encabezado HTTP con el valor acunetix-product para activar un intento de ataque de escaneo de seguridad:

curl -H 'My-ASM-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 (tags) 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 Datadog(this, "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"
});
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 Datadog(this, "Datadog", {
    // ... otros parámetros obligatorios, como el sitio de Datadog y la clave de la API
    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": "****"
      }
]

Recopilar trazas procedentes de recursos distintos de Lambda

Datadog puede inferir tramos (spans) 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 las invocaciones rastreadas de APM para las funciones serverless, define la variable de entorno DD_TRACE_SAMPLE_RATE en una función con un valor entre 0,000 (no se rastrea ninguna invocación de la función de Lambda) y 1,000 (se rastrean todas las invocaciones).

Las métricas se calculan en función del 100 % del tráfico de la aplicación, y son precisas independientemente de la configuración del muestreo.

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 a través de la Datadog Lambda Extension está habilitada de forma predeterminada.

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 Datadog(this, "Datadog", {
    // ... otros parámetros obligatorios, como el sitio de Datadog y la clave de la API
    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 Datadog(this, "Datadog", {
    // ... otros parámetros obligatorios, como el sitio de Datadog y la clave de la API
    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 usas la función de Lambda del Forwarder para recopilar trazas y logs, dd.trace_id se inserta automáticamente en los logs (habilitada por la variable de entorno DD_LOGS_INJECTION). Las vistas de trazas y logs de Datadog se conectan mediante el ID de traza de Datadog. Esta característica es compatible con la mayoría de aplicaciones que utilizan tiempos de ejecución y loggers populares (consulta la 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 stack traces) al código fuente de tus funciones de Lambda en los repositorios de 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 la creación de perfiles (beta pública)

Continuous Profiler de Datadog está disponible en versión beta para Python en la versión 4.62.0 y la versión de capa 62 y anteriores. Esta característica opcional se habilita mediante la definición de 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.

# Habilitar el envío doble para métricas
DD_ADDITIONAL_ENDPOINTS={"https://app.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://app.datadoghq.eu": ["<your_api_key_4>"]}
# Habilitar el envío doble para APM (trazas)
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>"]}
# Habilitar el envío doble para APM (perfilado)
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>"]}
# Habilitar el envío doble para 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.

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

Para testear la imagen de contenedor de tu función de Lambda de forma local con la Datadog Lambda Extension instalada, debes definir DD_LOCAL_TEST como true en tu entorno de tests local. De lo contrario, la extensión esperará respuestas de API de las extensiones de AWS 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.

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