Configurar Serverless Monitoring para AWS Lambda
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.
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.
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.
Asegúrate de usar la última versión de la Datadog CLI y ejecuta el comando datadog-ci lambda instrument
con los argumentos adicionales adecuados. Por ejemplo:
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
Asegúrate de usar la última versión del complemento Datadog Serverless Plugin y aplica las etiquetas con los parámetros env
, service
, version
y tags
. Por ejemplo:
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"
De forma predeterminada, si no defines env
y service
, el complemento utiliza automáticamente los valores stage
y service
de la definición de la aplicación serverless. Para deshabilitar esta característica, defineenableTags
como false
.
Asegúrate de usar la última versión de la macro serverless de Datadog y aplica las etiquetas con los parámetros env
, service
, version
y tags
. Por ejemplo:
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"
Asegúrate de usar la última versión de la construcción del CDK serverless de Datadog y aplica las etiquetas con los parámetros env
, service
, version
y tags
. Por ejemplo:
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>]);
Si vas a recopilar la telemetría de tus funciones de Lambda mediante la Datadog Lambda Extension, define las siguientes variables de entorno en tus funciones de Lambda. Por ejemplo:
- DD_ENV: dev
- DD_SERVICE: web
- DD_VERSION: v1.2.3
- DD_TAGS: team:avengers,project:marvel
Si quieres recopilar la telemetría de tus funciones de Lambda mediante la Función de Lambda del Datadog Forwarder, define env
, service
, version
y las etiquetas adicionales como etiquetas de recursos de AWS en tus funciones de Lambda. Asegúrate de que la opción DdFetchLambdaTags
esté definida 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.
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
Esta característica es compatible con Python, Node.js, Go, Java y .NET.
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.
Asegúrate de usar la última versión de la Datadog CLI y ejecuta el comando datadog-ci lambda instrument
con el argumento adicional --capture-lambda-payload
. Por ejemplo:
datadog-ci lambda instrument \
--capture-lambda-payload true
# ... otros argumentos obligatorios, como los nombres de las funciones
Asegúrate de usar la última versión del Datadog Serverless Plugin y define captureLambdaPayload
como true
. Por ejemplo:
custom:
datadog:
# ... otros parámetros obligatorios, como el sitio de Datadog y la clave de la API
captureLambdaPayload: true
Asegúrate de usar la última versión de la macro serverless de Datadog y define el parámetro captureLambdaPayload
como true
. Por ejemplo:
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
Asegúrate de usar la última versión de la construcción del CDK serverless de Datadog y define el parámetro captureLambdaPayload
como true
. Por ejemplo:
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>]);
Define la variable de entorno DD_CAPTURE_LAMBDA_PAYLOAD
como true
en tus funciones de Lambda.
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
En estos momentos, esta característica es compatible con Python, Node.js, Java y .NET.
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:
Integración de AWS Lambda | Valor de DD_SERVICE_MAPPING |
---|
lambda_api_gateway | "lambda_api_gateway:newServiceName" |
lambda_sns | "lambda_sns:newServiceName" |
lambda_sqs | "lambda_sqs:newServiceName" |
lambda_s3 | "lambda_s3:newServiceName" |
lambda_eventbridge | "lambda_eventbridge:newServiceName" |
lambda_kinesis | "lambda_kinesis:newServiceName" |
lambda_dynamodb | "lambda_dynamodb:newServiceName" |
lambda_url | "lambda_url:newServiceName" |
Cambiar el nombre de servicios específicos
Para un enfoque más granular, utiliza estos identificadores específicos de los servicios:
Servicio | Identificador | Valor de DD_SERVICE_MAPPING |
---|
API Gateway | ID de la API | "r3pmxmplak:newServiceName" |
SNS | Nombre del tema | "ExampleTopic:newServiceName" |
SQS | Nombre de la cola | "MyQueue:newServiceName" |
S3 | Nombre del bucket | "example-bucket:newServiceName" |
EventBridge | Origen del evento | "eventbridge.custom.event.sender:newServiceName" |
Kinesis | Nombre del flujo | "MyStream:newServiceName" |
DynamoDB | Nombre de la tabla | "ExampleTableWithStream:newServiceName" |
URL de Lambda | ID de la API | "a8hyhsshac:newServiceName" |
Ejemplos con descripción
Comando | Descripción |
---|
DD_SERVICE_MAPPING="lambda_api_gateway:new-service-name" | Cambia el nombre de todos los servicios anteriores lambda_api_gateway a new-service-name |
DD_SERVICE_MAPPING="08se3mvh28:new-service-name" | Cambia el nombre del servicio anterior específico 08se3mvh28.execute-api.eu-west-1.amazonaws.com a new-service-name |
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.
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>]);
Define la variable de entorno DD_TRACE_ENABLED
como true
en tus funciones de Lambda.
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>]);
Define la variable de entorno DD_TRACE_ENABLED
como false
en tus funciones de Lambda.
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:
- Obtén el ID de traza de Datadog mediante
dd-trace
y añádelo a tu log. - Clona el pipeline de logs de Lambda predeterminado, que es de solo lectura.
- Habilita el pipeline clonado y deshabilita el predeterminado.
- 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 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.
Puedes habilitar el envío múltiple con una clave de API de texto sin formato al configurar las siguientes variables de entorno en tu función de Lambda.
# 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}]
La extensión de Datadog es compatible con la recuperación automática de valores de AWS Secrets Manager para cualquier variable de entorno con el prefijo _SECRET_ARN
. Puedes utilizar esta estrategia para almacenar de forma segura tus variables de entorno en Secrets Manager y aprovechar la característica de envío múltiple de Datadog.
- Establece la variable de entorno
DD_LOGS_CONFIG_FORCE_USE_HTTP
en tu función de Lambda. - Añade el permiso
secretsmanager:GetSecretValue
a los permisos del rol de IAM de tu función de Lambda. - Crea un secreto nuevo en Secrets Manager para almacenar la variable de entorno de las métricas de envío múltiple. El contenido debe ser similar a este:
{"https://app.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://app.datadoghq.eu": ["<your_api_key_4>"]}
. - Define la variable de entorno
DD_ADDITIONAL_ENDPOINTS_SECRET_ARN
en tu función de Lambda como el ARN del secreto antes mencionado. - Crea un secreto nuevo en Secrets Manager para almacenar la variable de entorno de APM (trazas) de envío múltiple. El contenido debe ser similar a este:
{"https://trace.agent.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://trace.agent.datadoghq.eu": ["<your_api_key_4>"]}
. - Define la variable de entorno
DD_APM_ADDITIONAL_ENDPOINTS_SECRET_ARN
en tu función de Lambda para que sea igual que el ARN del secreto antes mencionado. - Crea un secreto nuevo en Secrets Manager para almacenar la variable de entorno de APM (creación de perfiles) de envío múltiple. El contenido debe ser similar a este:
{"https://trace.agent.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://trace.agent.datadoghq.eu": ["<your_api_key_4>"]}
. - Define la variable de entorno
DD_APM_PROFILING_ADDITIONAL_ENDPOINTS_SECRET_ARN
en tu función de Lambda para que coincida con el ARN del secreto antes mencionado. - Crea un secreto nuevo en Secrets Manager para almacenar la variable de entorno de los logs de envío múltiple. El contenido debe ser similar a este:
[{"api_key": "<your_api_key_2>", "Host": "agent-http-intake.logs.datadoghq.com", "Port": 443, "is_reliable": true}]
. - Define la variable de entorno
DD_LOGS_CONFIG_ADDITIONAL_ENDPOINTS_SECRET_ARN
en tu función de Lambda para que coincida con el ARN del secreto antes mencionado.
La extensión de Datadog es compatible con el descifrado automático de valores de AWS KMS para cualquier variable de entorno con el prefijo _KMS_ENCRYPTED
. Puedes utilizar esta estrategia para almacenar de forma segura tus variables de entorno en KMS y aprovechar la característica de envío múltiple de Datadog.
- Establece la variable de entorno
DD_LOGS_CONFIG_FORCE_USE_HTTP=true
en tu función de Lambda. - Añade los permisos
kms:GenerateDataKey
y kms:Decrypt
a los permisos del rol de IAM de tu función de Lambda. - Para habilitar el envío múltiple de las métricas, cifra
{"https://app.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://app.datadoghq.eu": ["<your_api_key_4>"]}
con KMS y define la variable de entorno DD_ADDITIONAL_ENDPOINTS_KMS_ENCRYPTED
de modo que coincida con su valor. - Para habilitar el envío múltiple de las trazas, cifra
{"https://trace.agent.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://trace.agent.datadoghq.eu": ["<your_api_key_4>"]}
con KMS y define la variable de entorno DD_APM_ADDITIONAL_KMS_ENCRYPTED
de modo que coincida con su valor. - Para habilitar el envío múltiple de la creación de perfiles, cifra
{"https://trace.agent.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://trace.agent.datadoghq.eu": ["<your_api_key_4>"]}
con KMS y define la variable de entorno DD_APM_PROFILING_ADDITIONAL_ENDPOINTS_KMS_ENCRYPTED
de modo que coincida con su valor. - Para habilitar el envío múltiple de los logs, cifra
[{"api_key": "<your_api_key_2>", "Host": "agent-http-intake.logs.datadoghq.com", "Port": 443, "is_reliable": true}]
con KMS y define la variable de entorno DD_LOGS_CONFIG_ADDITIONAL_ENDPOINTS_KMS_ENCRYPTED
de modo que coincida con su valor.
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.
- Actualiza
@datadog/datadog-ci
a la última versión. - Actualiza el argumento
--layer-version
y configúralo con la última versión de tu tiempo de ejecución. - Configura el argumento
--extension-version
con la última versión de la extensión, que es 66
. - Define las variables de entorno obligatorias
DATADOG_SITE
y DATADOG_API_KEY_SECRET_ARN
. - Elimina el argumento
--forwarder
. - Si configuraste tu integración de AWS para Datadog de modo que suscriba automáticamente los grupos de logs del Forwarder a Lambda, deshabilita esta característica cuando migres todas las funciones de Lambda de esa región.
- Actualiza
serverless-plugin-datadog
a la última versión, que instala de forma predeterminada la Datadog Lambda Extension, a no ser que hayas definido addExtension
como false
. - Define los parámetros obligatorios
site
y apiKeySecretArn
. - Define los parámetros
env
, service
y version
si antes los definiste como etiquetas de recursos de Lambda. El complemento los definirá automáticamente en las variables de entorno reservadas de Datadog, como DD_ENV
, al utilizar la extensión. - Elimina el parámetro
forwarderArn
, a no ser que quieras que el Forwarder continúe recopilando logs procedentes de recursos distintos de Lambda y tengas subscribeToApiGatewayLogs
, subscribeToHttpApiLogs
o subscribeToWebsocketLogs
definidos como true
. - Si configuraste tu integración de AWS para Datadog de modo que suscriba automáticamente los grupos de logs del Forwarder a Lambda, deshabilita esta característica cuando migres todas las funciones de Lambda de esa región.
- Actualiza el stack tecnológico de CloudFormation
datadog-serverless-macro
de modo que seleccione la última versión. - Configura el parámetro
extensionLayerVersion
con la última versión de la extensión, que es 66
. - Define los parámetros obligatorios
site
y apiKeySecretArn
. - Elimina el parámetro
forwarderArn
. - Si configuraste tu integración de AWS para Datadog de modo que suscriba automáticamente los grupos de logs del Forwarder a Lambda, deshabilita esta característica cuando migres todas las funciones de Lambda de esa región.
- Actualiza
datadog-cdk-constructs
o datadog-cdk-constructs-v2
a la última versión. - Configura el parámetro
extensionLayerVersion
con la última versión de la extensión, que es 66
. - Define los parámetros obligatorios
site
y apiKeySecretArn
. - Define los parámetros
env
, service
y version
si antes los definiste como etiquetas de recursos de Lambda. La construcción los definirá en las variables de entorno reservadas de Datadog, como DD_ENV
, al utilizar la extensión. - Elimina el parámetro
forwarderArn
. - Si configuraste tu integración de AWS para Datadog de modo que suscriba automáticamente los grupos de logs del Forwarder a Lambda, deshabilita esta característica cuando migres todas las funciones de Lambda de esa región.
- Actualiza la capa de la biblioteca Lambda de Datadog de tu tiempo de ejecución a la última versión.
- Instala la última versión de la Datadog Lambda Extension.
- Define las variables de entorno obligatorias
DD_SITE
y DD_API_KEY_SECRET_ARN
. - Define las variables de entorno
DD_ENV
, DD_SERVICE
y DD_VERSION
si antes las definiste como etiquetas de recursos de Lambda. - Elimina el filtro de suscripción que transmite logs procedentes del grupo de logs de tu función de Lambda al Datadog Forwarder.
- Si configuraste tu integración de AWS para Datadog de modo que suscriba automáticamente los grupos de logs del Forwarder a Lambda, deshabilita esta característica cuando migres todas las funciones de Lambda de esa región.
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: