# Supervisión, depuración y solución de problemas de funciones de Lambda
AWS Lambda se integra con otros Servicios de AWS para ayudarlo a monitorear y solucionar problemas de sus funciones de Lambda. Lambda supervisa automáticamente las funciones de Lambda en nombre y los informes de métricas a través de Amazon CloudWatch. Para ayudarlo a monitorear su código cuando se ejecuta, Lambda realiza un seguimiento automáticamente del número de solicitudes, la duración de la invocación por solicitud y el número de solicitudes que dan lugar a un error.
Puede utilizar otros Servicios de AWS para solucionar problemas de sus funciones de Lambda. En esta sección, se describe cómo utilizar estos Servicios de AWS para la monitorización, rastreo, depuración y solución de problemas de sus funciones y aplicaciones de Lambda. Para obtener más información sobre el registro de funciones y los errores en cada tiempo de ejecución, consulte las secciones de cada tiempo de ejecución.
**Topics**
+ [Precios](#monitoring-console-metrics-pricing)
+ [Uso de métricas de CloudWatch con Lambda](monitoring-metrics.md)
+ [Uso de registros de funciones de Lambda](monitoring-logs.md)
+ [Registro de llamadas a la API AWS Lambda mediante AWS CloudTrail](logging-using-cloudtrail.md)
+ [Visualice las invocaciones de la función de Lambda mediante AWS X-Ray](services-xray.md)
+ [Supervise el rendimiento de las funciones con Amazon CloudWatch Lambda Insights](monitoring-insights.md)
+ [Monitoreo de aplicaciones de Lambda](applications-console-monitoring.md)
+ [Monitoreo del rendimiento de las aplicaciones con Amazon CloudWatch Application Signals](monitoring-application-signals.md)
+ [Depuración de forma remota de funciones de Lambda con Visual Studio Code](debugging.md)
## Precios
CloudWatch una capa gratuita permanente. Más allá del umbral de capa gratuita, CloudWatch hace cargos por métricas, paneles, alarmas, registros e información. Para más información, consulte [Precios de Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
# Uso de métricas de CloudWatch con Lambda
Cuando la función de AWS Lambda termina de procesar un evento, Lambda envía métricas sobre la invocación a Amazon CloudWatch. No necesita conceder ningún permiso adicional a su rol de ejecución para recibir las métricas de las funciones y estas métricas no tienen ningún costo adicional.
Hay muchos tipos de métricas asociadas a las funciones de Lambda. Estos incluyen métricas de invocación, métricas de rendimiento, métricas de simultaneidad, métricas de invocación asíncrona y métricas de asignación de orígenes de eventos. Para obtener más información, consulte [Tipos de métricas de funciones de Lambda](monitoring-metrics-types.md).
En la consola de CloudWatch, se pueden [ver estas métricas](monitoring-metrics-view.md) y crear gráficos y paneles con ellas. Se pueden configurar alarmas para responder a cambios en el uso, el rendimiento o las tasas de error. Lambda envía datos de métricas a CloudWatch en intervalos de 1 minuto. Para obtener información más inmediata sobre su función de Lambda, puede crear [métricas personalizadas de alta resolución](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html). Se aplican cargos por las métricas personalizadas y las alarmas de CloudWatch. Para obtener más información, consulte [Precios de Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
# Visualización de métricas para funciones de Lambda
Utilice la consola de CloudWatch para ver las métricas de sus funciones de Lambda. En la consola, puede filtrar y clasificar métricas de funciones por nombre de función, alias, versión o UUID de asignación de orígenes de eventos.
**Para ver métricas en la consola de CloudWatch**
1. Abra la [página Metrics (Métricas)](https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2:graph=~();namespace=~'AWS*2fLambda) (espacio de nombres de `AWS/Lambda`) de la consola de CloudWatch.
1. En la pestaña **Examinar**, en **Métricas**, elija una de las siguientes dimensiones:
+ **Por nombre de función** (`FunctionName`): vea las métricas agregadas de todas las versiones y alias de una función.
+ **Por recurso** (`Resource`): vea las métricas de una versión o el alias de una función.
+ **Por versión ejecutada** (`ExecutedVersion`): vea las métricas para una combinación de alias y versión. Utilice la dimensión `ExecutedVersion` para comparar las tasas de error de dos versiones de una función que son objetivos de un [alias ponderado](configuration-aliases.md).
+ **Por UUID de asignación de orígenes de eventos** (`EventSourceMappingUUID`): permite ver las métricas de una asignación de orígenes de eventos.
+ **En todas las funciones** (ninguna): vea las métricas agregadas de todas las funciones de la Región de AWS actual.
1. Elija una métrica. La métrica debería aparecer automáticamente en el gráfico visual, así como en la pestaña **Métricas graficadas**.
De forma predeterminada, los gráficos utilizan la estadística `Sum` para todas las métricas. Para elegir una estadística diferente y personalizar el gráfico, utilice las opciones de la pestaña **Métricas Gráficas** .
**nota**
La marca temporal de una métrica refleja cuándo se invocó la función. Dependiendo de la duración de la invocación, esto puede ser varios minutos antes de la emisión de la métrica. Por ejemplo, si la función tiene un tiempo de espera de 10 minutos, retroceda más de 10 minutos al buscar para obtener métricas precisas.
Para obtener más información acerca de CloudWatch, consulte la [Guía del usuario de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html).
# Tipos de métricas de funciones de Lambda
En esta sección, se describen los tipos de métricas de Lambda disponibles en la consola de CloudWatch.
**Topics**
+ [Métricas de invocación](#invocation-metrics)
+ [Métricas de implementación](#deployment-metrics)
+ [Métricas de desempeño](#performance-metrics)
+ [Métricas de simultaneidad](#concurrency-metrics)
+ [Métricas de invocación asíncrona](#async-invocation-metrics)
+ [Métricas de asignación de orígenes de eventos](#event-source-mapping-metrics)
## Métricas de invocación
Las métricas de invocación son indicadores binarios del resultado de la invocación de una función de Lambda. Visualice estas métricas con la estadística `Sum`. Por ejemplo, si la función devuelve un error, Lambda envía la métrica `Errors` con un valor de 1. Para obtener un recuento del número de errores de la función que se hayan producido cada minuto, consulte el valor de `Sum` de la métrica `Errors` con un período de 1 minuto.
+ `Invocations`: el número de veces que se invoca el código de la función, incluidas las invocaciones correctas y las invocaciones que dan lugar a un error de la función. Las invocaciones no se registran si la solicitud de invocación se limita o da lugar a un error de invocación. El valor de `Invocations` equivale al número de solicitudes facturadas.
+ `Errors`: el número de invocaciones que dan lugar a un error de función. Los errores de la función incluyen las excepciones lanzadas por el código y las excepciones lanzadas por el tiempo de ejecución de Lambda. El motor de ejecución devuelve errores para problemas como tiempos de espera y errores de configuración. Para calcular la tasa de error, divida el valor de `Errors` por el valor de `Invocations`. Tenga en cuenta que la marca de hora de una métrica de error refleja cuándo se invocó la función, no cuando se produjo el error.
+ `DeadLetterErrors`: en el caso de la [invocación asíncrona](invocation-async.md), el número de veces que Lambda intenta enviar un evento a una cola de mensajes fallidos (DLQ) sin conseguirlo. Pueden producirse errores de mensaje fallido debido a recursos mal configurados o límites de tamaño.
+ `DestinationDeliveryFailures`: en el caso de la invocación asíncrona y la [asignación de orígenes de eventos](https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html) admitida, es el número de veces que Lambda intenta enviar un evento a un [destino](invocation-async-retain-records.md#invocation-async-destinations) sin conseguirlo. Para la asignación de orígenes de eventos, Lambda admite los destinos de orígenes de secuencias (DynamoDB y Kinesis). Pueden producirse errores de entrega debido a errores de permisos, recursos mal configurados o límites de tamaño. También pueden producirse errores si el destino que ha configurado es de un tipo no admitido, como una cola FIFO de Amazon SQS o un tema FIFO de Amazon SNS.
+ `Throttles`: el número de solicitudes de invocación que se han limitado. Cuando todas las instancias de función están procesando solicitudes y no hay simultaneidad disponible para escalar verticalmente, Lambda rechaza las solicitudes adicionales y muestra el error `TooManyRequestsException`. Las solicitudes limitadas y otros errores de invocación no cuentan como `Invocations` ni `Errors`.
**nota**
Con las [instancias administradas de Lambda](lambda-managed-instances.md), Lambda proporciona métricas de limitación detalladas que identifican la restricción específica que causa la limitación. Cuando se produce una limitación en el entorno de ejecución, se emite exactamente una de las siguientes submétricas con un valor de 1, mientras que las tres restantes se emiten con un valor de 0. La métrica `Throttles` siempre se emite junto con estas submétricas.
`CPUThrottles`: invocaciones limitadas por el agotamiento de CPU en el entorno de ejecución.
`MemoryThrottles`: invocaciones limitadas por el agotamiento de memoria en el entorno de ejecución.
`DiskThrottles`: invocaciones limitadas por el agotamiento de disco en el entorno de ejecución.
`ConcurrencyThrottles`: invocaciones limitadas cuando se alcanza el límite de concurrencia del entorno de ejecución.
+ `OversizedRecordCount`: en el caso de los orígenes de eventos de Amazon DocumentDB, la cantidad de eventos que su función recibe de su flujo de cambios que tienen un tamaño superior a 6 MB. Lambda elimina el mensaje y emite esta métrica.
+ `ProvisionedConcurrencyInvocations`: el número de veces que se invoca el código de la función con [simultaneidad aprovisionada](provisioned-concurrency.md).
+ `ProvisionedConcurrencySpilloverInvocations`: el número de veces que se invoca el código de la función con simultaneidad estándar cuando ya se usa toda la simultaneidad aprovisionada.
+ `RecursiveInvocationsDropped`: el número de veces que Lambda ha detenido la invocación de la función porque se detecta que la función forma parte de un bucle recursivo infinito. La detección de bucles recursivos supervisa la cantidad de veces que se invoca una función como parte de una cadena de solicitudes mediante el seguimiento de los metadatos agregados por los SDK de AWS compatibles. De forma predeterminada, si la función se invoca como parte de una cadena de solicitudes aproximadamente 16 veces, Lambda descarta la siguiente invocación. Si deshabilita la detección de bucles recursivos, esta métrica no se emite. Para obtener más información acerca de esta característica, consulte [Utilice la detección de bucles recursivos de Lambda para evitar bucles infinitos](invocation-recursion.md).
## Métricas de implementación
Las métricas de implementación proporcionan información sobre los eventos de implementación de la función de Lambda y los procesos de validación relacionados.
+ `SignatureValidationErrors`: el número de veces que se ha implementado un paquete de códigos con errores en la validación de la firma cuando la política de configuración de la firma de código está establecida en `Warn`. Esta métrica se emite cuando las comprobaciones de caducidad, discordancia o revocación fallan, pero la implementación sigue estando permitida debido a la configuración de la política de `Warn`. Para obtener más información sobre la firma de código, consulta [Uso de la firma de código para verificar la integridad del código con Lambda](configuration-codesigning.md).
## Métricas de desempeño
Las métricas de rendimiento proporcionan detalles de rendimiento sobre una única invocación de función. Por ejemplo, la métrica `Duration` indica la cantidad de tiempo en milisegundos que la función gasta procesando un evento. Para obtener una idea de la rapidez con la que su función procesa eventos, consulte estas métricas con la estadística `Average` o `Max`.
+ `Duration`: la cantidad de tiempo que el código de función pasa procesando un evento. La duración facturada de una invocación es el valor de `Duration` redondeado hacia arriba a los milisegundos más cercanos. `Duration` no incluye el tiempo de arranque en frío.
+ `PostRuntimeExtensionsDuration`: la cantidad acumulativa de tiempo que el tiempo de ejecución dedica a ejecutar código para extensiones después de que se haya completado el código de función.
+ `IteratorAge`: en el caso de los orígenes de eventos de DynamoDB, Kinesis y Amazon DocumentDB, la antigüedad del último registro del evento. Esta métrica mide el tiempo transcurrido desde que una secuencia recibe el registro hasta que la asignación de origen de eventos envía el evento a la función.
+ `OffsetLag`: en el caso de los orígenes de eventos autoadministrados de Apache Kafka y Amazon Managed Streaming para Apache Kafka (Amazon MSK), la diferencia de desplazamiento entre el último registro escrito en un tema y el último registro que procesó el grupo de consumidores de la función. Aunque un tema de Kafka puede tener varias particiones, esta métrica mide el retraso de desplazamiento en el nivel del tema.
`Duration` también admite estadísticas percentiles (`p`). Utilice percentiles para excluir valores atípicos que sesgan las estadísticas `Average` y `Maximum`. Por ejemplo, la estadística `p95` muestra la duración máxima del 95 % de las invocaciones, sin incluir el 5 % más lento. Para obtener más información, consulte [Percentiles](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Percentiles) en la *Guía del usuario de Amazon CloudWatch*.
## Métricas de simultaneidad
Lambda informa de las métricas de simultaneidad como un recuento agregado del número de instancias que procesan eventos en una función, versión, alias o Región de AWS. Para ver lo cerca que está de alcanzar los [límites de simultaneidad](lambda-concurrency.md#concurrency-quotas), consulte estas métricas con la estadística `Max`.
+ `ConcurrentExecutions`: el número de instancias de función que están procesando eventos. Si este número alcanza la [cuota de ejecuciones simultáneas](gettingstarted-limits.md#compute-and-storage) de la región o el límite de [simultaneidad reservada](configuration-concurrency.md) de la función, Lambda limita las solicitudes de invocación adicionales.
+ `ProvisionedConcurrentExecutions`: el número de instancias de función que están procesando eventos con [simultaneidad aprovisionada](provisioned-concurrency.md). Para cada invocación de un alias o versión con simultaneidad aprovisionada, Lambda emite el recuento actual. Si la función está inactiva o no recibe solicitudes, Lambda no emite esta métrica.
+ `ProvisionedConcurrencyUtilization`: para una versión o alias, el valor de `ProvisionedConcurrentExecutions` dividido entre la cantidad total de simultaneidad aprovisionada asignada. Por ejemplo, si configura una simultaneidad aprovisionada de 10 para su función y su `ProvisionedConcurrentExecutions` es 7, entonces su `ProvisionedConcurrencyUtilization` es 0,7.
Si la función está inactiva o no recibe solicitudes, Lambda no emite esta métrica porque se basa en `ProvisionedConcurrentExecutions`. Tenga esto en cuenta si utiliza `ProvisionedConcurrencyUtilization` como base para las alarmas de CloudWatch.
+ `UnreservedConcurrentExecutions`: en el caso de región, número de eventos que están procesando las funciones que no tienen simultaneidad reservada.
+ `ClaimedAccountConcurrency`: para una región, es la cantidad de simultaneidad que no está disponible para las invocaciones bajo demanda. `ClaimedAccountConcurrency` es igual a `UnreservedConcurrentExecutions` más la cantidad de simultaneidad asignada (es decir, la simultaneidad reservada total más la simultaneidad total aprovisionada). Para obtener más información, consulte [Cómo trabajar con la métrica `ClaimedAccountConcurrency`](monitoring-concurrency.md#claimed-account-concurrency).
## Métricas de invocación asíncrona
Las métricas de invocación asíncrona proporcionan detalles sobre las invocaciones asíncronas desde los orígenes de eventos y las invocaciones directas. Puede establecer umbrales y alarmas para recibir notificaciones sobre ciertos cambios. Por ejemplo, cuando hay un aumento no deseado en el número de eventos en cola para su procesamiento (`AsyncEventsReceived`). O bien, cuando un evento ha estado esperando mucho tiempo para que se procese (`AsyncEventAge`).
+ `AsyncEventsReceived`: el número de eventos que Lambda pone correctamente en cola para su procesamiento. Esta métrica proporciona información sobre la cantidad de eventos que recibe una función de Lambda. Supervise esta métrica y establezca alarmas para establecer umbrales para comprobar si hay problemas. Por ejemplo, para detectar un número no deseado de eventos enviados a Lambda y para diagnosticar rápidamente los problemas derivados de configuraciones incorrectas de desencadenadores o funciones. Los desajustes entre `AsyncEventsReceived` y `Invocations` pueden indicar una disparidad en el procesamiento, eventos que se descartan o un posible retraso en las colas.
+ `AsyncEventAge`: el tiempo transcurrido entre el momento en que Lambda pone correctamente en cola el evento y el momento en que se invoca la función. El valor de esta métrica aumenta cuando se vuelven a intentar los eventos debido a errores de invocación o a limitaciones. Supervise esta métrica y establezca alarmas para conocer los umbrales de las diferentes estadísticas cuando se produzca una acumulación de colas. Para solucionar problemas de aumento en esta métrica, consulte la métrica `Errors` para identificar los errores de función y la métrica `Throttles` para identificar los problemas de simultaneidad.
+ `AsyncEventsDropped`: el número de eventos que se descartan sin ejecutar correctamente la función. Si configura una cola de mensajes fallidos (DLQ) o un destino `OnFailure`, los eventos se enviarán allí antes de que se descarten. Los eventos se descartan por varias razones. Por ejemplo, los eventos pueden superar la antigüedad máxima del evento o agotar el número máximo de reintentos, o bien la simultaneidad reservada puede estar establecida en 0. Para solucionar problemas por los que se descartan los eventos, consulte la métrica `Errors` para identificar los errores de función y la métrica `Throttles` para identificar los problemas de simultaneidad.
## Métricas de asignación de orígenes de eventos
Las métricas de asignación de orígenes de eventos ofrecen información sobre el comportamiento de procesamiento de su asignación de orígenes de eventos.
Actualmente, las métricas de asignación de orígenes de eventos están disponibles para los orígenes de eventos de Amazon SQS, Kinesis, DynamoDB, Amazon MSK y Apache Kafka autoadministrado.
Para la asignación de orígenes de eventos con configuración de métricas, ahora también puede consultar todas las métricas relacionadas con la ESM en la pestaña **Supervisar** desde la página de la consola **Lambda** > **Recursos adicionales** > **asignación de orígenes de eventos**.
**Cómo habilitar métricas o una asignación de orígenes de eventos (consola)**
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija la función para la que desea habilitar las métricas.
1. Elija **Configuración** y, a continuación, seleccione **Desencadenadores**.
1. Elija la asignación de orígenes de eventos para el que desee habilitar las métricas y, a continuación, elija **Editar**.
1. En la **configuración de la asignación de orígenes de eventos**, elija **Habilitar métricas** o seleccione una opción en la lista desplegable **Métricas**.
1. Seleccione **Save**.
Como alternativa, puede habilitar las métricas para la asignación de orígenes de eventos por programación mediante el objeto [EventSourceMappingMetricsConfig](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingMetricsConfig.html) en su [EventSourceMappingConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingConfiguration.html). Por ejemplo, el siguiente comando de la CLI [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) habilita las métricas para una asignación de orígenes de eventos:
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--metrics-config Metrics=EventCount
```
Hay 3 grupos de métricas: `EventCount`, `ErrorCount` y `KafkaMetrics`, y cada grupo tiene varias métricas. No todas las métricas están disponibles para cada origen de eventos. En la siguiente tabla se resumen las métricas compatibles con cada tipo de origen de eventos.
Debe activar el grupo de métricas para recibir métricas relacionadas con las métricas. Por ejemplo, configure EventCount en la configuración de métricas para que tenga `PolledEventCount`, `FilteredOutEventCount`, `InvokedEventCount`, `FailedInvokeEventCount`, `DroppedEventCount`, `OnFailureDestinationDeliveredEventCount` y `DeletedEventCount`.
| Métrica de asignación de orígenes de eventos | Grupo de métricas | Amazon SQS | Flujos de Kinesis y DynamoDB | Amazon MSK y Apache Kafka autoadministrado |
| --- | --- | --- | --- | --- |
| `PolledEventCount` | `EventCount` | Sí | Sí | Sí |
| `FilteredOutEventCount` | `EventCount` | Sí | Sí | Sí |
| `InvokedEventCount` | `EventCount` | Sí | Sí | Sí |
| `FailedInvokeEventCount` | `EventCount` | Sí | Sí | Sí |
| `DroppedEventCount` | `EventCount` | No | Sí | Sí |
| `OnFailureDestinationDeliveredEventCount` | `EventCount` | No | Sí | Sí |
| `DeletedEventCount` | `EventCount` | Sí | No | No |
| `CommittedEventCount` | `EventCount` | No | No | Sí |
| `PollingErrorCount` | `ErrorCount` | No | No | Sí |
| `InvokeErrorCount` | `ErrorCount` | No | No | Sí |
| `OnFailureDestinationDeliveryErrorCount` | `ErrorCount` | No | No | Sí |
| `SchemaRegistryErrorCount` | `ErrorCount` | No | No | Sí |
| `CommitErrorCount` | `ErrorCount` | No | No | Sí |
| `MaxOffsetLag` | `KafkaMetrics` | No | No | Sí |
| `SumOffsetLag` | `KafkaMetrics` | No | No | Sí |
Además, si la asignación de orígenes de eventos está en [modo aprovisionado](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), Lambda proporciona la siguiente métrica:
+ `ProvisionedPollers`: en el caso de las asignaciones de orígenes de eventos en modo aprovisionado, el número de sondeos de eventos que se ejecuta activamente. Consulte esta métrica mediante el uso de la calculadora `MAX`.
+ (Solo para orígenes de eventos de Amazon MSK y Apache Kafka autoadministrado) `EventPollerUnit`: en el caso de las asignaciones de orígenes de eventos en modo aprovisionado, el número de unidades de sondeador de eventos que se ejecuta activamente. Consulte esta métrica mediante el uso de la calculadora `SUM`.
+ (Para orígenes de eventos de Amazon MSK y Apache Kafka autoadministrado) `EventPollerThroughputInBytes`: en el caso de las asignaciones de orígenes de eventos en modo aprovisionado, el tamaño total de los registros de los sondeadores de eventos que se sondean desde el origen de eventos. Puede indicarle el rendimiento actual de los sondeos. Consulte esta métrica mediante el uso de la calculadora `SUM`.
Aquí hay más detalles sobre cada una de las métricas:
+ `PolledEventCount`: el número de eventos que Lambda lee correctamente del origen de eventos. Si Lambda sondea los eventos, pero recibe un sondeo vacío (no hay registros nuevos), Lambda emite un valor 0 para esta métrica. Utilice esta métrica para detectar si la asignación de orígenes de eventos sondea correctamente los nuevos eventos.
+ `FilteredOutEventCount`: para la asignación de orígenes de eventos con un [criterio de filtro](invocation-eventfiltering.md), el número de eventos filtrados según ese criterio de filtro. Utilice esta métrica para detectar si la asignación de orígenes de eventos filtra correctamente los eventos. Para los eventos que coinciden con los criterios del filtro, Lambda emite una métrica 0.
+ `InvokedEventCount`: el número de eventos que invocaron la función de Lambda. Utilice esta métrica para comprobar que los eventos que invocan correctamente la función. Si un evento provoca un error de función o una limitación, `InvokedEventCount` podría contar varias veces el mismo evento sondeado debido a los reintentos automáticos.
**aviso**
Las asignaciones de orígenes de eventos de Lambda procesan cada evento al menos una vez, y puede producirse un procesamiento duplicado de registros. Por este motivo, los eventos pueden contarse varias veces en las métricas que incluyen recuentos de eventos.
+ `FailedInvokeEventCount`: el número de eventos que invocaron la función de Lambda, pero fallaron. Las invocaciones pueden fallar debido a problemas de configuración de la red, permisos incorrectos o la eliminación de una función de Lambda, versión o alias. Si la asignación de orígenes de eventos tiene habilitadas [las respuestas por lotes parciales](services-sqs-errorhandling.md#services-sqs-batchfailurereporting), `FailedInvokeEventCount` incluye cualquier evento `BatchItemFailures` que no esté vacío en la respuesta.
**nota**
La marca temporal de la métrica `FailedInvokeEventCount` representa el final de la invocación de la función. Este comportamiento difiere de otras métricas de errores de invocación de Lambda, que tienen una marca temporal al inicio de la invocación de la función.
+ `DroppedEventCount`: el número de eventos que Lambda descartó debido a la caducidad de o al agotamiento de los reintentos. En concreto, se trata del número de registros que superan los valores configurados para `MaximumRecordAgeInSeconds` o `MaximumRetryAttempts`. Es importante destacar que esto no incluye la cantidad de registros que caducan por superar la configuración de retención del origen de eventos. Los eventos descartados también excluyen los eventos que envíe a un [destino en caso de fallo](invocation-async-retain-records.md). Utilice esta métrica para detectar una acumulación creciente de eventos.
+ `OnFailureDestinationDeliveredEventCount`: en el caso de las asignaciones de orígenes de eventos con un [destino en caso de fallo](invocation-async-retain-records.md) configurado, el número de eventos enviados a ese destino. Utilice esta métrica para supervisar los errores de función relacionados con las invocaciones desde este origen de eventos. Si se produce un error en la entrega al destino, Lambda gestiona las métricas de la siguiente manera:
+ Lambda no emite la métrica `OnFailureDestinationDeliveredEventCount`.
+ Para la métrica `DestinationDeliveryFailures`, Lambda emite un 1.
+ Para la métrica `DroppedEventCount`, Lambda emite un número igual al número de eventos en los que no se pudo entregar.
+ `DeletedEventCount`: el número de eventos que Lambda elimina con éxito después de procesarlos. Si Lambda intenta eliminar un evento pero no lo consigue, Lambda emite una métrica 0. Utilice esta métrica para asegurarse de que los eventos procesados correctamente se eliminen de su origen de eventos.
+ `CommittedEventCount`: el número de eventos que Lambda confirmó con éxito después de procesarlos. Es la suma de las diferencias entre el último desplazamiento confirmado y el desplazamiento confirmado actual de cada partición en la asignación de orígenes de eventos de Kafka.
+ `PollingErrorCount`: el número de errores que se producen cuando Lambda no logra sondear las solicitudes del origen de eventos. Lambda solo emite estos datos de métricas cuando se produce un error.
+ `InvokeErrorCount`: el número de errores que se producen cuando Lambda no logra invocar su función. Tenga en cuenta que la invocación consiste en registros por lotes. El número está a nivel de lote, no a nivel de recuento de registros. Lambda solo emite estos datos de métricas cuando se produce un error.
+ `SchemaRegistryErrorCount`: el número de errores que se producen cuando Lambda no logra recuperar el esquema o deserializar con este. Lambda solo emite estos datos de métricas cuando se produce un error.
+ `CommitErrorCount`: el número de errores que se producen cuando Lambda no logra confirmar en el clúster de Kafka. Lambda solo emite estos datos de métricas cuando se produce un error.
+ `MaxOffsetLag`: el máximo de retrasos de desplazamiento (diferencia entre los desplazamientos más recientes y los confirmados) en todas las particiones de la asignación de orígenes de eventos.
+ `SumOffsetLag`: la suma de los retrasos de desplazamiento en todas las particiones de la asignación de orígenes de eventos.
Si la asignación de orígenes de eventos está deshabilitada, no recibirá las métricas de asignación de orígenes de eventos. También es posible que falten métricas si CloudWatch o Lambda están experimentando una disminución de la disponibilidad.
# Uso de registros de funciones de Lambda
Para ayudarlo con los errores de solución de problemas, AWS Lambda supervisa automáticamente las funciones de Lambda en su nombre. Puede ver los registros de las funciones de Lambda mediante la consola de Lambda, la consola de CloudWatch, la AWS Command Line Interface (AWS CLI) o la API de CloudWatch. También puede configurar Lambda para enviar registros a Amazon S3 y Firehose.
Siempre que el [rol de ejecución](lambda-intro-execution-role.md) de la función cuente con los permisos necesarios, Lambda captura los registros de todas las solicitudes gestionadas por la función y los envía a Registros de Amazon CloudWatch, que es el destino predeterminado. También puede utilizar la consola de Lambda para configurar Amazon S3 o Firehose como destinos de registro.
+ **Registros de CloudWatch** es el destino de registro predeterminado para las funciones de Lambda. Registros de CloudWatch ofrece capacidades de visualización y análisis de registros en tiempo real, con soporte para crear métricas y alarmas basadas en los datos de registro.
+ **Amazon S3** es económico para el almacenamiento a largo plazo, y servicios como Athena se pueden utilizar para analizar los registros. La latencia suele ser mayor.
+ **Firehose** ofrece una transmisión administrada de registros a varios destinos. Si necesita enviar registros a otros servicios de AWS (por ejemplo, OpenSearch Service o la API de datos de Redshift) o plataformas de terceros (como Datadog, New Relic o Splunk), Firehose simplifica ese proceso al proporcionar integraciones prediseñadas. También puede transmitir a puntos de conexión HTTP personalizados sin necesidad de configurar una infraestructura adicional.
## Elección de un destino de servicio al que enviar los registros
Tenga en cuenta los siguientes factores clave al elegir un servicio como destino para los registros de funciones:
+ **La administración de costos varía según el servicio.** Amazon S3 suele proporcionar la opción más económica para el almacenamiento a largo plazo, mientras que Registros de CloudWatch le permite ver registros, procesarlos y configurar alertas en tiempo real. Los costos de Firehose incluyen tanto el servicio de transmisión como el costo asociado con el destino al que lo configura para transmitir.
+ **Las capacidades de análisis difieren entre los servicios.** Registros de CloudWatch destaca en la supervisión en tiempo real y se integra de forma nativa con otras características de CloudWatch, como Información de registros y Live Tail. Amazon S3 funciona bien con herramientas de análisis como Athena y puede integrarse con varios servicios, aunque puede requerir una configuración adicional. Firehose simplifica la transmisión directa a servicios de AWS específicos (como OpenSearch Service y la API de datos de Redshift) y plataformas de terceros compatibles (como Datadog y Splunk) al proporcionar integraciones prediseñadas, lo que podría reducir el trabajo de configuración.
+ **La configuración y la facilidad de uso varían según el servicio.** Registros de CloudWatch es el destino de registro predeterminado: funciona de forma inmediata sin necesidad de configuración adicional y permite ver y analizar los registros de forma sencilla a través de la consola de CloudWatch. Si necesita que los registros se envíen a Amazon S3, tendrá que llevar a cabo una configuración inicial en la consola de Lambda y configurar los permisos del bucket. Si necesita que los registros se envíen directamente a servicios como OpenSearch Service o plataformas de análisis de terceros, Firehose puede simplificar ese proceso.
## Configuración de destinos de registro
AWS Lambda admite varios destinos para los registros de funciones. Esta guía explica los destinos de registro disponibles y le ayuda a elegir la opción adecuada según sus necesidades. Independientemente del destino que elija, Lambda ofrece opciones para controlar el formato de registro, el filtrado y la entrega.
Lambda admite los formatos JSON y de texto sin formato para los registros de sus funciones. Los registros estructurados JSON ofrecen una capacidad de búsqueda mejorada y permiten el análisis automatizado, mientras que los registros de texto sin formato ofrecen simplicidad y, potencialmente, reducen los costos de almacenamiento. Para controlar qué registros envía Lambda al destino elegido, puede configurar los niveles de registro tanto para los registros del sistema como de la aplicación. El filtrado le ayuda a administrar los costos de almacenamiento y facilita la búsqueda de las entradas de registro pertinentes durante la depuración.
Para obtener instrucciones detalladas de configuración para cada destino, consulte las siguientes secciones:
+ [Envío de registros de funciones de Lambda a Registros de CloudWatch](monitoring-cloudwatchlogs.md)
+ [Envío de registros de funciones de Lambda a Firehose](logging-with-firehose.md)
+ [Envío de registros de funciones de Lambda a Amazon S3](logging-with-s3.md)
## Configuración de controles de registro avanzados para las funciones de Lambda
Para tener más control sobre cómo se registran, procesan y consumen los registros de sus funciones, Lambda ofrece las siguientes opciones de configuración del registro:
+ **Formato de registro**: seleccione entre texto sin formato y el formato JSON estructurado para los registros de su función.
+ **Nivel de registro**: para los registros estructurados en formato JSON, elija el nivel de detalle de los registros que Lambda envía a CloudWatch, como `FATAL`, `ERROR`, `WARN`, `INFO`, `DEBUG` y `TRACE`.
+ **Grupo de registro**: elija el grupo de registro de CloudWatch al que su función envía los registros.
Para obtener más información sobre la configuración de los controles de registro avanzados, consulte las siguientes secciones:
+ [Configuración de los formatos de registro JSON y de texto sin formato](monitoring-cloudwatchlogs-logformat.md)
+ [Filtrado a nivel de registro](monitoring-cloudwatchlogs-log-level.md)
+ [Configuración de grupos de registros de CloudWatch](monitoring-cloudwatchlogs-loggroups.md)
# Configuración de los formatos de registro JSON y de texto sin formato
Al capturar las salidas del registro como pares clave-valor JSON, resulta más fácil buscar y filtrar resultados cuando se depuran las funciones. Con los registros con formato JSON, también puede agregar etiquetas e información contextual a sus registros. Esto puede ayudarlo a realizar un análisis automatizado de grandes volúmenes de datos de registro. A menos que su flujo de trabajo de desarrollo se base en herramientas existentes que consumen registros de Lambda con texto sin formato, le recomendamos que seleccione JSON como formato de registro.
**Instancias administradas de Lambda**
Las instancias administradas de Lambda solo admiten el formato de registro JSON. Cuando crea una función de instancias administradas, Lambda configura automáticamente el formato de registro en JSON y no se puede cambiar a texto sin formato. Para obtener más información acerca de las instancias administradas, consulte [Instancias administradas de Lambda](lambda-managed-instances.md).
Para todos los tiempos de ejecución administrados por Lambda, puede elegir si los registros del sistema de su función se deben enviar a Registros de Amazon CloudWatch en texto sin formato o formato JSON no estructurado. Los registros del sistema son los registros que Lambda genera y, a veces, se conocen como registros de eventos de plataforma.
En el caso de los [tiempos de ejecución compatibles](#monitoring-cloudwatchlogs-logformat-supported), cuando se utiliza uno de los métodos de registro integrados compatibles, Lambda también puede generar los registros de aplicación de la función (los registros que genera el código de la función) en formato JSON estructurado. Al configurar el formato de registro de la función para estos tiempos de ejecución, la configuración que elija se aplicará tanto a los registros del sistema como de la aplicación.
Para los tiempos de ejecución compatibles, si su función utiliza una biblioteca o un método de registro compatibles, no necesita realizar ningún cambio en el código existente para que Lambda capture los registros en formato JSON estructurado.
**nota**
El uso del formato de registro JSON agrega metadatos y codifica los mensajes de registro como objetos JSON que contienen una serie de pares clave-valor. Por este motivo, es posible que aumente el tamaño de los mensajes de registro de la función.
## Tiempos de ejecución y métodos de registro compatibles
Actualmente, Lambda admite la opción de generar registros de aplicaciones en formato JSON estructurado para los siguientes tiempos de ejecución.
| Idioma | Versiones compatibles |
| --- | --- |
| Java | Todos los tiempos de ejecución de Java excepto Java 8 en Amazon Linux 1 |
| .NET | .NET 8 y versiones posteriores |
| Node.js | Node.js 16 y posteriores |
| Python | Python 3.8 y posteriores |
| Rust | n/a |
Para que Lambda envíe los registros de aplicación de la función a CloudWatch en formato JSON estructurado, la función debe utilizar las siguientes herramientas de registro integradas para generar los registros:
+ **Java**: el registrador `LambdaLogger` o Log4j2. Para obtener más información, consulte [Registro y supervisión de las funciones de Lambda de Java](java-logging.md).
+ **.NET**: la instancia `ILambdaLogger` del objeto de contexto. Para obtener más información, consulte [Registro y supervisión de las funciones de Lambda de C\$1](csharp-logging.md).
+ **Node.js**: los métodos de la consola `console.trace`, `console.debug`, `console.log`, `console.info`, `console.error` y `console.warn`. Para obtener más información, consulte [Registro y supervisión de las funciones de Lambda de Node.js](nodejs-logging.md).
+ **Python**: la biblioteca `logging` de Python estándar. Para obtener más información, consulte [Registro y supervisión de las funciones de Lambda de Python](python-logging.md).
+ **Rust**: la caja de `tracing`. Para obtener más información, consulte [Registro y supervisioón de las funciones de Lambda en Rust](rust-logging.md).
Para otros tiempos de ejecución de Lambda administrados, Lambda actualmente solo admite de forma nativa la captura de registros del sistema en formato JSON estructurado. Sin embargo, puede seguir capturando los registros de aplicaciones en formato JSON estructurado en cualquier tiempo de ejecución con herramientas de registro, como Powertools para AWS Lambda, que generan salidas de registro con formato JSON.
## Formatos de registro predeterminados
Actualmente, el formato de registro predeterminado para todos los tiempos de ejecución de Lambda es texto sin formato. En el caso de las instancias administradas de Lambda, el formato de registro es siempre JSON y no se puede cambiar.
Si ya utiliza bibliotecas de registro, como Powertools para AWS Lambda, para generar los registros de funciones en formato JSON estructurado, no necesita cambiar el código si selecciona el formato de registro JSON. Lambda no codifica dos veces ningún registro que ya esté codificado en JSON, por lo que los registros de la aplicación de su función seguirán capturándose como antes.
## Formato JSON para registros del sistema
Al configurar el formato de registro de la función como JSON, se captura cada elemento de registro del sistema (evento de plataforma) como un objeto JSON que contiene pares clave-valor con las siguientes claves:
+ `"time"`: la hora en que se generó el mensaje de registro
+ `"type"`: el tipo de evento que se está registrando
+ `"record"`: el contenido de la salida del registro
El formato del valor `"record"` varía según el tipo de evento que se registre. Para obtener más información consulte () [Tipos de objetos `Event` de la API de telemetría](telemetry-schema-reference.md#telemetry-api-events). Para obtener más información sobre los niveles de registro asignados a los eventos de registro del sistema, consulte [Asignación de eventos a nivel de registro del sistema](monitoring-cloudwatchlogs-log-level.md#monitoring-cloudwatchlogs-log-level-mapping).
A modo de comparación, los dos ejemplos siguientes muestran la misma salida de registro en formato JSON estructurado y de texto sin formato. Tenga en cuenta que, en la mayoría de los casos, los eventos de registro del sistema contienen más información cuando se generan con formato JSON que cuando se generan con texto sin formato.
**Example Texto sin formato:**
```
2024-03-13 18:56:24.046000 fbe8c1 INIT_START Runtime Version: python:3.12.v18 Runtime Version ARN: arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0
```
**Example JSON estructurado:**
```
{
"time": "2024-03-13T18:56:24.046Z",
"type": "platform.initStart",
"record": {
"initializationType": "on-demand",
"phase": "init",
"runtimeVersion": "python:3.12.v18",
"runtimeVersionArn": "arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0"
}
}
```
**nota**
La [Acceso a datos de telemetría en tiempo real para extensiones mediante la API de telemetría](telemetry-api.md) siempre emite eventos de plataforma, como `START` y `REPORT`, en formato JSON. La configuración del formato de los registros del sistema que Lambda envía a CloudWatch no afecta el comportamiento de la API de telemetría de Lambda.
## Formato JSON para registros de aplicaciones
Al configurar el formato de registro de la función como JSON, las salidas del registro de aplicación escritas con las bibliotecas y los métodos de registro compatibles se capturan como un objeto JSON que contiene pares de clave-valor con las siguientes claves:
+ `"timestamp"`: la hora en que se generó el mensaje de registro
+ `"level"`: el nivel de registro asignado al mensaje
+ `"message"`: el contenido del mensaje de registro
+ `"requestId"` (Python, .NET y Node.js) o `"AWSrequestId"` (Java): el ID de solicitud único para la invocación de la función
Según el tiempo de ejecución y el método de registro que utilice la función, este objeto JSON también puede contener pares de claves adicionales. Por ejemplo, en Node.js, si la función utiliza métodos `console` para registrar objetos de error con varios argumentos, el objeto JSON contendrá pares de clave-valor adicionales junto con las claves `errorMessage`, `errorType`, y`stackTrace`. Para obtener más información sobre los registros con formato JSON en diferentes tiempos de ejecución de Lambda, consulte [Registro y supervisión de las funciones de Lambda de Python](python-logging.md), [Registro y supervisión de las funciones de Lambda de Node.js](nodejs-logging.md), y [Registro y supervisión de las funciones de Lambda de Java](java-logging.md).
**nota**
La clave que Lambda utiliza para el valor de marca de tiempo es diferente para los registros del sistema y los registros de la aplicación. En el caso de los registros del sistema, Lambda usa la clave `"time"` para mantener la coherencia con la API de telemetría. Para los registros de la aplicación, Lambda sigue las convenciones de los tiempos de ejecución compatibles y utiliza `"timestamp"`.
A modo de comparación, los dos ejemplos siguientes muestran la misma salida de registro en formato JSON estructurado y de texto sin formato.
**Example Texto sin formato:**
```
2024-10-27T19:17:45.586Z 79b4f56e-95b1-4643-9700-2807f4e68189 INFO some log message
```
**Example JSON estructurado:**
```
{
"timestamp":"2024-10-27T19:17:45.586Z",
"level":"INFO",
"message":"some log message",
"requestId":"79b4f56e-95b1-4643-9700-2807f4e68189"
}
```
## Configuración del formato de registro de su función
Para configurar el formato de registro de la función, puede utilizar la consola de Lambda o la AWS Command Line Interface (AWS CLI). También puede configurar el formato de registro de una función mediante los comandos de la API de Lambda [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) y [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html), el recurso de AWS Serverless Application Model (AWS SAM) [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html) y el recurso de CloudFormation [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html).
Cambiar el formato de registro de la función no afecta a los registros existentes almacenados en Registros de Amazon CloudWatch. Solo los registros nuevos utilizarán el formato actualizado.
Si cambia el formato de registro de la función a JSON y no establece el nivel de registro, Lambda establece automáticamente el nivel de registro de la aplicación y el nivel de registro del sistema de la función en INFO. Esto significa que Lambda envía a Registros de CloudWatch solo las salidas de registro de nivel INFO e inferiores. Para obtener más información sobre el filtrado a nivel de registro de aplicaciones y sistemas, consulte [Filtrado a nivel de registro](monitoring-cloudwatchlogs-log-level.md).
**nota**
Para los tiempos de ejecución de Python, cuando el formato de registro de la función está establecido en texto sin formato, la configuración de nivel de registro predeterminada es WARN. Esto significa que Lambda envía a Registros de CloudWatch solo las salidas de registro de nivel WARN e inferiores. Al cambiar el formato de registro de la función a JSON, se modifica este comportamiento predeterminado. Para obtener más información acerca de los registros de Python, consulte [Registro y supervisión de las funciones de Lambda de Python](python-logging.md).
En el caso de las funciones de Node.js que emiten registros en formato de métricas integradas (EMF), cambiar el formato de registro de la función a JSON podría provocar que CloudWatch no reconozca las métricas.
**importante**
Si su función utiliza Powertools para AWS Lambda (TypeScript) o las bibliotecas cliente de EMF de código abierto para emitir registros EMF, actualice las bibliotecas de [Powertools](https://github.com/aws-powertools/powertools-lambda-typescript) y [EMF](https://www.npmjs.com/package/aws-embedded-metrics) a las versiones más recientes para asegurarse de que CloudWatch pueda seguir analizando los registros correctamente. Si cambia al formato de registro JSON, también le recomendamos que realice pruebas para asegurarse de que es compatible con las métricas integradas de la función. Para obtener más información sobre las funciones de node.js que emiten registros EMF, consulte [Uso de bibliotecas cliente de formato de métricas integradas (EMF) con registros JSON estructurados](nodejs-logging.md#nodejs-logging-advanced-emf).
**Para configurar el formato de registro de una función (consola)**
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija una función.
1. En la página de configuración de funciones, elija **Herramientas de supervisión y operaciones**.
1. En el panel **Configuración de registros**, seleccione **Editar**.
1. En **Contenido del registro**, para **Formato de registro**, seleccione **Texto** o **JSON**.
1. Seleccione **Save**.
**Cambio del formato de registro de una función existente (AWS CLI)**
+ Para cambiar el formato de registro de una función existente, utilice el comando [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html). Configure la opción `LogFormat` en `LoggingConfig` para que sea `JSON` o `Text`.
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON
```
**Para establecer el formato de registro al crear una función (AWS CLI)**
+ Para configurar el formato de registro al crear una función nueva, utilice la opción `--logging-config` en el comando [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html). Establezca `LogFormat` en `JSON` o `Text`. El siguiente comando de ejemplo crea una función de Node.js que genera registros en formato JSON estructurado.
Si no especifica un formato de registro al crear una función, Lambda utilizará el formato de registro predeterminado para la versión de tiempo de ejecución que seleccione. Para obtener información sobre los formatos de registro predeterminados, consulte [Formatos de registro predeterminados](#monitoring-cloudwatchlogs-format-default).
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogFormat=JSON
```
# Filtrado a nivel de registro
Lambda puede filtrar los registros de su función para que solo se envíen a Registros de Amazon CloudWatch los registros con un nivel de detalle determinado o inferior. Puede configurar el filtrado a nivel de registro por separado para los registros del sistema de la función (los registros que Lambda genera) y los registros de la aplicación (los registros que genera el código de la función).
Para [Tiempos de ejecución y métodos de registro compatibles](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-logformat-supported), no necesita realizar ningún cambio en el código de la función para que Lambda filtre los registros de aplicación de su función.
Para todos los demás tiempos de ejecución y métodos de registro, el código de la función debe generar los eventos de registro en `stdout` o `stderr` como objetos con formato JSON que contengan un par clave-valor con la clave `"level"`. Por ejemplo, Lambda interpreta la siguiente salida de `stdout` como un registro de nivel DEBUG.
```
print('{"level": "debug", "msg": "my debug log", "timestamp": "2024-11-02T16:51:31.587199Z"}')
```
Si el campo de valor `"level"` no es válido o falta, Lambda asignará a la salida del registro el nivel INFO. Para que Lambda utilice el campo de marca de tiempo, debe especificar el tiempo con un formato de marca de tiempo [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) válido. Si no proporciona una marca de tiempo válida, Lambda asignará al registro el nivel INFO y agregará una marca de tiempo por usted.
Cuando asigne un nombre a la clave de marca de tiempo, siga las convenciones del tiempo de ejecución que esté utilizando. Lambda admite la mayoría de las convenciones de nomenclatura habituales que utilizan los tiempos de ejecución administrados.
**nota**
Para usar el filtrado a nivel de registro, la función debe estar configurada para usar el formato de registro JSON. Actualmente, el formato de registro predeterminado para todos los tiempos de ejecución administrados por Lambda es texto sin formato. Para obtener información sobre cómo configurar el formato de registro de la función como JSON, consulte [Configuración del formato de registro de su función](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-set-format).
Para los registros de aplicaciones (los registros generados por el código de la función), puede elegir entre los siguientes niveles de registro.
| Nivel de registro | Uso estándar |
| --- | --- |
| TRACE (más detallado) | La información más detallada que se utiliza para rastrear la ruta de ejecución del código |
| DEBUG | Información detallada para la depuración del sistema |
| INFO | Mensajes que registran el funcionamiento normal de su función |
| WARN | Mensajes sobre posibles errores que pueden provocar un comportamiento inesperado si no se abordan |
| ERROR | Mensajes sobre problemas que impiden que el código funcione según lo esperado |
| FATAL (menos detallado) | Mensajes sobre errores graves que hacen que la aplicación deje de funcionar |
Al seleccionar un nivel de registro, Lambda envía los registros de ese nivel y de niveles inferiores a Registros de Amazon CloudWatch. Por ejemplo, si establece el nivel de registro de la aplicación de una función en WARN, Lambda no envía las salidas de registro en los niveles INFO y DEBUG. El nivel de registro de aplicaciones predeterminado para el filtrado de registros es INFO.
Cuando Lambda filtra los registros de aplicaciones de la función, a los mensajes de registro sin nivel se les asignará el nivel de registro INFO.
Para los registros del sistema (los registros generados por el servicio Lambda), puede elegir entre los siguientes niveles de registro.
| Nivel de registro | Uso |
| --- | --- |
| DEBUG (más detallado) | Información detallada para la depuración del sistema |
| INFO | Mensajes que registran el funcionamiento normal de su función |
| WARN (menos detallado) | Mensajes sobre posibles errores que pueden provocar un comportamiento inesperado si no se abordan |
Al seleccionar un nivel de registro, Lambda envía los registros a ese nivel y a niveles inferiores. Por ejemplo, si establece el nivel de registro del sistema de una función en INFO, Lambda no envía las salidas de registro en el nivel DEBUG.
De forma predeterminada, Lambda establece el nivel de registro del sistema en INFO. Con esta configuración, Lambda envía los mensajes de registro `"start"` y `"report"` a CloudWatch automáticamente. Para recibir registros del sistema más o menos detallados, cambie el nivel de registro a DEBUG o WARN. Para ver una lista de los niveles de registro a los que Lambda asigna diferentes eventos de registro del sistema, consulte [Asignación de eventos a nivel de registro del sistema](#monitoring-cloudwatchlogs-log-level-mapping).
## Configuración del filtrado a nivel de registro
Para configurar el filtrado a nivel de registro de aplicaciones y sistemas para su función, puede utilizar la consola de Lambda o la AWS Command Line Interface (AWS CLI). También puede configurar el nivel de registro de una función con los comandos de la API de Lambda [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) y [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html), el recurso de AWS Serverless Application Model (AWS SAM) [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html) y el recurso de CloudFormation [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html).
Tenga en cuenta que si establece el nivel de registro de la función en el código, esta configuración tiene prioridad sobre cualquier otra configuración a nivel de registro que configure. Por ejemplo, si usa el método `setLevel()` de `logging` de Python para establecer el nivel de registro de la función en INFO, esta configuración tiene prioridad sobre la configuración WARN que configure mediante la consola de Lambda.
**Para configurar el nivel de registro de sistema o aplicación de una función existente (consola)**
1. Abra la [página de Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija una función.
1. En la página de configuración de funciones, elija **Herramientas de supervisión y operaciones**.
1. En el panel **Configuración de registros**, seleccione **Editar**.
1. En **Contenido del registro**, para **Formato de registro**, asegúrese de seleccionar **JSON**.
1. Con los botones de opción, seleccione el **Nivel de registro de la aplicación** y el **Nivel de registro del sistema** que desee para su función.
1. Seleccione **Save**.
**Para configurar el nivel de registro de la aplicación o del sistema de una función existente (AWS CLI)**
+ Para cambiar el nivel de registro de la aplicación o del sistema de una función existente, utilice el comando [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html). Se utiliza `--logging-config` para establecer `SystemLogLevel` en uno de los siguientes valores: `DEBUG`, `INFO` o `WARN`. Configure `ApplicationLogLevel` en una de las siguientes opciones: `DEBUG`, `INFO`, `WARN`, `ERROR` o `FATAL`.
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
**Para configurar el filtrado a nivel de registro al crear una función**
+ Para configurar el filtrado de nivel de registro al crear una función nueva, utilice `--logging-config` para establecer las claves `SystemLogLevel` y `ApplicationLogLevel` en el comando [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html). Configure `SystemLogLevel` en una de las siguientes opciones: `DEBUG`, `INFO` o `WARN`. Configure `ApplicationLogLevel` en una de las siguientes opciones: `DEBUG`, `INFO`, `WARN`, `ERROR` o `FATAL`.
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
## Asignación de eventos a nivel de registro del sistema
Para los eventos de registro a nivel de sistema generados por Lambda, la siguiente tabla define el nivel de registro asignado a cada evento. Para obtener más información sobre los eventos que figuran en la tabla, consulte [Referencia del esquema `Event` de la API de telemetría de Lambda](telemetry-schema-reference.md).
| Nombre de evento | Condición | Nivel de registro asignado |
| --- | --- | --- |
| initStart | runtimeVersion está configurado | INFO |
| initStart | runtimeVersion no está configurado | DEBUG |
| initRuntimeDone | status=success | DEBUG |
| initRuntimeDone | status\$1=success | WARN |
| initReport | initializationType\$1=on-demand | INFO |
| initReport | initializationType=on-demand | DEBUG |
| initReport | status\$1=success | WARN |
| restoreStart | runtimeVersion está configurado | INFO |
| restoreStart | runtimeVersion no está configurado | DEBUG |
| restoreRuntimeDone | status=success | DEBUG |
| restoreRuntimeDone | status\$1=success | WARN |
| restoreReport | status=success | INFO |
| restoreReport | status\$1=success | WARN |
| iniciar | - | INFO |
| runtimeDone | status=success | DEBUG |
| runtimeDone | status\$1=success | WARN |
| report | status=success | INFO |
| report | status\$1=success | WARN |
| extensión | state=success | INFO |
| extensión | state\$1=success | WARN |
| logSubscription | - | INFO |
| telemetrySubscription | - | INFO |
| logsDropped | - | WARN |
**nota**
La [Acceso a datos de telemetría en tiempo real para extensiones mediante la API de telemetría](telemetry-api.md) siempre emite el conjunto completo de eventos de plataforma. La configuración del nivel de los registros del sistema que Lambda envía a CloudWatch no afecta el comportamiento de la API de telemetría de Lambda.
## Filtrado a nivel de registro de aplicaciones con tiempos de ejecución personalizados
Al configurar el filtrado a nivel de registro de aplicaciones para su función, en segundo plano, Lambda establece el nivel de registro de la aplicación en el tiempo de ejecución mediante la variable de entorno `AWS_LAMBDA_LOG_LEVEL`. Lambda también establece el formato de registro de la función mediante la variable de entorno `AWS_LAMBDA_LOG_FORMAT`. Puede utilizar estas variables para integrar los controles de registro avanzados de Lambda en un [tiempo de ejecución personalizado](runtimes-custom.md).
Para poder configurar los ajustes de registro de una función mediante un tiempo de ejecución personalizado con la consola de Lambda, AWS CLI y las API de Lambda, configure el tiempo de ejecución personalizado para comprobar el valor de estas variables de entorno. A continuación, puede configurar los registradores de su tiempo de ejecución de acuerdo con el formato y los niveles de registro que seleccione.
# Envío de registros de funciones de Lambda a Registros de CloudWatch
De forma predeterminada, Lambda captura automáticamente los registros de todas las invocaciones de funciones y los envía a Registros de CloudWatch, siempre que el rol de ejecución de la función tenga los permisos necesarios. De forma predeterminada, estos registros se almacenan en un grupo de registro denominado /aws/lambda/**. Para mejorar la depuración, puede insertar instrucciones de registro personalizadas en el código, que Lambda integrará sin problemas con Registros de CloudWatch. Si es necesario, puede configurar su función para enviar registros a un grupo diferente con la consola de Lambda, la AWS CLI o la API de Lambda. Consulte [Configuración de grupos de registros de CloudWatch](monitoring-cloudwatchlogs-loggroups.md) para obtener más información.
Puede ver los registros de las funciones de Lambda mediante la consola de Lambda, la consola de CloudWatch, el AWS Command Line Interface (AWS CLI) o la API de CloudWatch. Para obtener más información, consulte [Visualización de los registros de CloudWatch para funciones de Lambda](monitoring-cloudwatchlogs-view.md).
**nota**
Los registros pueden tardar de 5 a 10 minutos en aparecer después de una invocación de la función.
## Permisos de IAM necesarios
Su [rol de ejecución](lambda-intro-execution-role.md) necesita los siguientes permisos para cargar registros en los registros de CloudWatch:
+ `logs:CreateLogGroup`
+ `logs:CreateLogStream`
+ `logs:PutLogEvents`
Para obtener más información, consulte [Uso de políticas basadas en identidad (políticas de IAM) para los registros de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-identity-based-access-control-cwl.html) en la *Guía del usuario de Amazon CloudWatch*.
Puede agregar permisos de registros de CloudWatch mediante la política administrada de `AWSLambdaBasicExecutionRole` de AWS proporcionada por Lambda. Ejecute el siguiente comando para agregar esta política a su rol:
```
aws iam attach-role-policy --role-name your-role --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
Para obtener más información, consulte [Trabajo con políticas administradas de AWS en el rol de ejecución](permissions-managed-policies.md).
## Precios
No se aplican cargos adicionales por utilizar los registros de Lambda; no obstante, sí se aplican los cargos estándar de Registros de CloudWatch. Para obtener más información, consulte los [precios de CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
# Configuración de grupos de registros de CloudWatch
De forma predeterminada, CloudWatch crea automáticamente un grupo de registro denominado `/aws/lambda/` para la función cuando se invoca por primera vez. Para configurar su función de manera que envíe registros a un grupo de registro existente o para crear un nuevo grupo de registro para su función, puede usar la consola de Lambda o la AWS CLI. También puede configurar grupos de registros personalizados con los comandos de la API de Lambda [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) y [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html), y el recurso [AWS::Serverless::Function]() de AWS Serverless Application Model (AWS SAM).
Puede configurar varias funciones de Lambda para enviar registros al mismo grupo de registro de CloudWatch. Por ejemplo, puede usar un único grupo de registro para almacenar los registros de todas las funciones de Lambda que componen una aplicación concreta. Cuando se utiliza un grupo de registro personalizado para una función de Lambda, los flujos de registro que Lambda crea incluyen el nombre y la versión de la función. Esto garantiza que se conserve la asignación entre los mensajes de registro y las funciones, incluso si utiliza el mismo grupo de registro para varias funciones.
El formato de denominación del flujo de registro para grupos de registro personalizados sigue esta convención:
```
YYYY/MM/DD/[][]
```
Tenga en cuenta que, al configurar un grupo de registro personalizado, el nombre que seleccione para el grupo de registro debe seguir las [reglas de nomenclatura de Registros de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html). Además, los nombres personalizados de los grupos de registros no deben empezar por la cadena `aws/`. Si crea un grupo de registros personalizado empezando por `aws/`, Lambda no podrá crear el grupo de registros. Como resultado, los registros de la función no se enviarán a CloudWatch.
**Cambio del grupo de registro de una función (consola)**
1. Abra la [página de Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija una función.
1. En la página de configuración de funciones, elija **Herramientas de supervisión y operaciones**.
1. En el panel **Configuración de registros**, seleccione **Editar**.
1. En el panel **Grupo de registro**, para el **Grupo de registro de CloudWatch**, elija **Personalizado**.
1. En **Grupo de registro personalizado**, introduzca el nombre del grupo de registro de CloudWatch al que quiere que su función envíe registros. Si introduce el nombre de un grupo de registro existente, su función utilizará ese grupo. Si no existe ningún grupo de registro con el nombre que ingresa, Lambda creará un nuevo grupo de registro para su función con ese nombre.
**Cambio del grupo de registro de una función (AWS CLI)**
+ Para cambiar el grupo de registro de una función existente, utilice el comando [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html).
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogGroup=myLogGroup
```
**Para especificar un grupo de registro personalizado al crear una función (AWS CLI)**
+ Para especificar un grupo de registro personalizado al crear una nueva función de Lambda con la AWS CLI, utilice la opción `--logging-config`. El siguiente comando de ejemplo crea una función de Lambda de Node.js que envía registros a un grupo de registro denominado `myLogGroup`.
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogGroup=myLogGroup
```
## Permisos de rol de ejecución
Para que su función envíe registros a Registros de Amazon CloudWatch, debe tener el permiso [logs:PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html). Cuando configura el grupo de registro de su función mediante la consola de Lambda, Lambda agregará este permiso al rol en las siguientes condiciones:
+ El destino del servicio está configurado como Registros de CloudWatch
+ El rol de ejecución de su función no tiene permisos para cargar registros en Registros de CloudWatch (el destino predeterminado)
**nota**
Lambda no agrega ningún permiso Put para los destinos de registro de Amazon S3 o Firehose.
Cuando Lambda agrega este permiso, otorga a la función permiso para enviar registros a cualquier grupo de registro de Registros de Amazon CloudWatch.
Para evitar que Lambda actualice automáticamente el rol de ejecución de la función y, en su lugar, lo edite manualmente, expanda **Permisos** y deje la opción **Agregar permisos necesarios** sin marcar.
Al configurar el grupo de registro de la función con la AWS CLI, Lambda no agregará el permiso `logs:PutLogEvents` automáticamente. Agregue el permiso al rol de ejecución de su función si aún no lo tiene. Este permiso se incluye en la política administrada [AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole$jsonEditor).
## Registro de CloudWatch para instancias administradas de Lambda
Cuando utiliza [instancias administradas de Lambda](lambda-managed-instances.md), hay consideraciones adicionales a la hora de enviar registros a Registros de CloudWatch:
### Requisitos de red de la VPC
Las instancias administradas de Lambda se ejecutan en instancias de EC2 propiedad del cliente dentro de su VPC. Para enviar registros a Registros de CloudWatch y seguimientos a X-Ray, debe asegurarse de que estas API de AWS puedan enrutarse desde su VPC. Dispone de varias opciones para hacerlo:
+ **PrivateLink de AWS (recomendado):** utilice [PrivateLink de AWS](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) para crear puntos de conexión de VPC para los servicios Registros de CloudWatch y X-Ray. Esto permite que sus instancias accedan a estos servicios de forma privada sin necesidad de una puerta de enlace de Internet o una puerta de enlace NAT. Para obtener más información, consulte [Uso de Registros de CloudWatch con puntos de conexión de VPC de tipo interfaz](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html).
+ **Puerta de enlace NAT**: configure una puerta de enlace NAT para permitir el acceso saliente a Internet desde sus subredes privadas.
+ **Puerta de enlace de Internet**: en el caso de las subredes públicas, asegúrese de que la VPC tenga configurada una puerta de enlace de Internet.
Si las API de Registros de CloudWatch o X-Ray no pueden enrutarse desde su VPC, los registros y seguimientos de sus funciones no se entregarán.
### Invocaciones simultáneas y atribución de registros
Los entornos de ejecución de las instancias administradas de Lambda pueden procesar varias invocaciones de forma simultánea. Cuando se ejecutan varias invocaciones simultáneamente, sus entradas de registro se intercalan en el mismo flujo de registro. Para filtrar y analizar de forma eficaz los registros de las invocaciones simultáneas, debe asegurarse de que cada entrada del registro incluya el identificador de la solicitud de AWS.
Recomendamos uno los siguientes enfoques de seguridad:
+ **Utilice registradores de tiempo de ejecución de Lambda predeterminados (recomendado)**: las bibliotecas de registro predeterminadas que proporcionan los tiempos de ejecución administrados de Lambda incluyen automáticamente el identificador de solicitud en cada entrada de registro.
+ **Implemente un registro JSON estructurado**: si está creando un [tiempo de ejecución personalizado](runtimes-custom.md) o necesita un registro personalizado, implemente registros con formato JSON que incluyan el identificador de solicitud en cada entrada. Las instancias administradas de Lambda solo admiten el formato de registro JSON. Incluya el campo `requestId` en sus registros JSON para permitir el filtrado por invocación:
```
{
"timestamp": "2025-01-15T10:30:00.000Z",
"level": "INFO",
"requestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"message": "Processing request"
}
```
Con la atribución de identificador de solicitud, puede filtrar las entradas de registro de Registros de CloudWatch para una invocación específica mediante consultas de Información de Registros de CloudWatch. Por ejemplo:
```
fields @timestamp, @message
| filter requestId = "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
| sort @timestamp asc
```
Para obtener más información sobre los requisitos de registro de las instancias administradas de Lambda, consulte [Descripción del entorno de ejecución de instancias administradas de Lambda](lambda-managed-instances-execution-environment.md).
# Visualización de los registros de CloudWatch para funciones de Lambda
Puede ver los registros de Amazon CloudWatch de la función de Lambda mediante la consola de Lambda, la consola de Registros de CloudWatch, o la AWS Command Line Interface (AWS CLI). Siga las instrucciones en las siguientes secciones para acceder a los registros de la función.
## Registros de funciones de streaming con Live Tail de Registros de CloudWatch
Live Tail de Registros de Amazon CloudWatch ayuda a solucionar rápidamente los problemas de las funciones, ya que muestra una lista de streaming de los nuevos eventos de registro directamente en la consola de Lambda. Puede ver y filtrar los registros ingeridos desde las funciones de Lambda casi en tiempo real, lo que ayuda a detectar y resolver problemas con mayor rapidez.
**nota**
Las sesiones de Live Tail generan costos según el tiempo de uso de la sesión por minuto. Para obtener más información sobre precios, consulte [Precios de Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
### Comparación de Live Tail y --log-type Tail
Existen varias diferencias entre Live Tail de Registros de CloudWatch y la opción [LogType: Tail](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html#lambda-Invoke-request-LogType) de la API de Lambda (`--log-type Tail` en la AWS CLI):
+ `--log-type Tail` devuelve solo los primeros 4 KB de los registros de invocación. Live Tail no comparte este límite y puede recibir hasta 500 eventos de registro por segundo.
+ `--log-type Tail` captura y envía los registros con la respuesta, lo que puede afectar a la latencia de respuesta de la función. Live Tail no afecta a la latencia de respuesta de la función.
+ `--log-type Tail` solo admite invocaciones sincrónicas. Live Tail funciona para invocaciones asíncronas y sincrónicas.
**nota**
Las [instancias administradas de Lambda](lambda-managed-instances.md) no admiten la opción `--log-type Tail`. Utilice Registros de CloudWatch Live Tail o consulte Registros de CloudWatch directamente para ver los registros de las funciones de instancias administradas.
### Permisos
Se requieren los siguientes permisos para iniciar y detener las sesiones de Live Tail de Registros de CloudWatch:
+ `logs:DescribeLogGroups`
+ `logs:StartLiveTail`
+ `logs:StopLiveTail`
### Inicio de una sesión de Live Tail en la consola de Lambda
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija el nombre de la función.
1. Elija la pestaña **Prueba**.
1. En el panel **Evento de prueba**, elija **Live Tail de Registros de CloudWatch**.
1. En **Seleccionar grupos de registro**, el grupo de registros de la función está seleccionado de forma predeterminada. Puede seleccionar hasta cinco grupos de registro a la vez.
1. (Opcional) Para mostrar solo los eventos de registro que contengan determinadas palabras u otras cadenas, escriba la palabra o la cadena en el cuadro **Agregar patrón de filtro**. El campo de filtros distingue entre mayúsculas y minúsculas. Puede incluir varios términos y operadores de patrones en este campo, incluidas las expresiones regulares (regex). Para obtener más información sobre la sintaxis de los patrones, consulte [Filter pattern syntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html) en la *Guía del usuario de Registros de Amazon CloudWatch*.
1. Elija **Iniciar**. Los eventos de registro que coincidan comenzarán a aparecer en la ventana.
1. Para detener la sesión de Live Tail, seleccione **Detener**.
**nota**
La sesión de Live Tail se detiene automáticamente tras 15 minutos de inactividad o cuando se agota el tiempo de espera de la sesión de la consola de Lambda.
## Acceso a los registros de la función con la consola
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Seleccione una función.
1. Elija la pestaña **Supervisar**.
1. Elija **Ver registros de CloudWatch** para abrir la consola de CloudWatch.
1. Desplácese hacia abajo y seleccione el **flujo de registro** para las invocaciones de la función que desee consultar.
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/log-stream.png)
Cada instancia de una función de Lambda tiene un flujo de registro dedicado. Si una función se escala verticalmente, cada instancia simultánea tiene su propio flujo de registro. Cada vez que se crea un nuevo entorno de ejecución en respuesta a una invocación, se genera un nuevo flujo de registro. La convención de nomenclatura de los flujos de registro es:
```
YYYY/MM/DD[Function version][Execution environment GUID]
```
Un entorno de ejecución único escribe en el mismo flujo de registro durante su vida útil. El flujo de registro contiene los mensajes de ese entorno de ejecución y también cualquier resultado del código de la función de Lambda. Todos los mensajes tienen marca de tiempo, incluidos los registros personalizados. Incluso si la función no registra ningún resultado del código, se generan tres declaraciones del registro mínimas por invocación (START, END y REPORT):
![\[monitoreo y observabilidad (figura 3)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/monitoring-observability-figure-3.png)
Estos registros muestran:
+ **RequestId**: se trata de un identificador único generado por solicitud. Si la función de Lambda vuelve a intentar una solicitud, este ID no cambia y aparece en los registros para cada reintento posterior.
+ **Inicio/Fin**: marcan una única invocación, de modo que todas las líneas de registro intermedias pertenecen a la misma invocación.
+ **Duración**: el tiempo total de invocación de la función controladora, excluido el código `INIT`.
+ **Duración facturada**: aplica una lógica de redondeo para fines de facturación.
+ **Tamaño de memoria**: la cantidad de memoria asignada a la función.
+ **Máxima memoria utilizada**: la cantidad máxima de memoria utilizada durante la invocación.
+ **Duración de inicialización**: el tiempo que se tarda en ejecutar la sección de código `INIT`, fuera del controlador principal.
## Acceso a los registros con la AWS CLI
La AWS CLI es una herramienta de código abierto que lo habilita para interactuar con los servicios de AWS mediante el uso de comandos en el intérprete de comandos de la línea de comandos. Para completar los pasos de esta sección, debe disponer de la [versión 2 de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
Puede utilizar la [CLI de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) para recuperar registros de una invocación mediante la opción de comando `--log-type`. La respuesta contiene un campo `LogResult` que contiene hasta 4 KB de registros con codificación base64 a partir de la invocación.
**Example recuperar un ID de registro**
En el ejemplo siguiente se muestra cómo recuperar un *ID de registro* del campo `LogResult` para una función denominada `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail
```
Debería ver los siguientes datos de salida:
```
{
"StatusCode": 200,
"LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...",
"ExecutedVersion": "$LATEST"
}
```
**Example decodificar los registros**
En el mismo símbolo del sistema, utilice la utilidad `base64` para decodificar los registros. En el ejemplo siguiente se muestra cómo recuperar registros codificados en base64 para `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
La opción **cli-binary-format** es obligatoria si va a utilizar la versión 2 de la AWS CLI. Para que esta sea la configuración predeterminada, ejecute `aws configure set cli-binary-format raw-in-base64-out`. Para obtener más información, consulte [Opciones de la línea de comandos globales compatibles con AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) en la *Guía del usuario de la AWS Command Line Interface versión 2*.
Debería ver los siguientes datos de salida:
```
START RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Version: $LATEST
"AWS_SESSION_TOKEN": "AgoJb3JpZ2luX2VjELj...", "_X_AMZN_TRACE_ID": "Root=1-5d02e5ca-f5792818b6fe8368e5b51d50;Parent=191db58857df8395;Sampled=0"",ask/lib:/opt/lib",
END RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8
REPORT RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Duration: 79.67 ms Billed Duration: 80 ms Memory Size: 128 MB Max Memory Used: 73 MB
```
La utilidad `base64` está disponible en Linux, macOS y [Ubuntu en Windows](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Es posible que los usuarios de macOS necesiten usar `base64 -D`.
**Example get-logs.sh script**
En el mismo símbolo del sistema, utilice el siguiente script para descargar los últimos cinco eventos de registro. El script utiliza `sed` para eliminar las comillas del archivo de salida y permanece inactivo durante 15 segundos para dar tiempo a que los registros estén disponibles. La salida incluye la respuesta de Lambda y la salida del comando `get-log-events`.
Copie el contenido de la siguiente muestra de código y guárdelo en su directorio de proyecto Lambda como `get-logs.sh`.
La opción **cli-binary-format** es obligatoria si va a utilizar la versión 2 de la AWS CLI. Para que esta sea la configuración predeterminada, ejecute `aws configure set cli-binary-format raw-in-base64-out`. Para obtener más información, consulte [Opciones de la línea de comandos globales compatibles con AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) en la *Guía del usuario de la AWS Command Line Interface versión 2*.
```
#!/bin/bash
aws lambda invoke --function-name my-function --cli-binary-format raw-in-base64-out --payload '{"key": "value"}' out
sed -i'' -e 's/"//g' out
sleep 15
aws logs get-log-events --log-group-name /aws/lambda/my-function --log-stream-name stream1 --limit 5
```
**Example macOS y Linux (solamente)**
En el mismo símbolo del sistema, es posible que los usuarios de macOS y Linux necesiten ejecutar el siguiente comando para asegurarse de que el script es ejecutable.
```
chmod -R 755 get-logs.sh
```
**Example recuperar los últimos cinco eventos de registro**
En el mismo símbolo del sistema, ejecute el siguiente script para obtener los últimos cinco eventos de registro.
```
./get-logs.sh
```
Debería ver los siguientes datos de salida:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
{
"events": [
{
"timestamp": 1559763003171,
"message": "START RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf Version: $LATEST\n",
"ingestionTime": 1559763003309
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tENVIRONMENT VARIABLES\r{\r \"AWS_LAMBDA_FUNCTION_VERSION\": \"$LATEST\",\r ...",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tEVENT\r{\r \"key\": \"value\"\r}\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "END RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "REPORT RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\tDuration: 26.73 ms\tBilled Duration: 27 ms \tMemory Size: 128 MB\tMax Memory Used: 75 MB\t\n",
"ingestionTime": 1559763018353
}
],
"nextForwardToken": "f/34783877304859518393868359594929986069206639495374241795",
"nextBackwardToken": "b/34783877303811383369537420289090800615709599058929582080"
}
```
## Análisis de registros y registros estructurados
Con Información de Registros de CloudWatch, puede buscar y analizar datos de registro mediante una [sintaxis de consulta](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) especializada. Realiza consultas en varios grupos de registros y proporciona un filtrado eficaz mediante la coincidencia de patrones de [expresiones regulares](https://en.wikipedia.org/wiki/Regular_expression) y [glob](https://en.wikipedia.org/wiki/Glob_(programming)).
Puede aprovechar estas capacidades mediante la implementación de un registro estructurado en las funciones de Lambda. El registro estructurado organiza los registros en un formato predefinido, lo cual facilita las consultas. El uso de los niveles de registro es un primer paso importante para generar registros fáciles de filtrar que separen los mensajes informativos de las advertencias o los errores. Por ejemplo, considere el siguiente código Node.js:
```
exports.handler = async (event) => {
console.log("console.log - Application is fine")
console.info("console.info - This is the same as console.log")
console.warn("console.warn - Application provides a warning")
console.error("console.error - An error occurred")
}
```
El archivo de registro de CloudWatch resultante contiene un campo independiente que especifica el nivel de registro:
![\[monitoreo y observabilidad (figura 10)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/monitoring-observability-figure-10.png)
Una consulta de Información de registros de CloudWatch puede filtrar por nivel de registro. Por ejemplo, para consultar únicamente los errores, puede utilizar la siguiente consulta:
```
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
```
### Registro estructurado JSON
JSON se suele utilizar para proporcionar una estructura a los registros de las aplicaciones. En el siguiente ejemplo, los registros se han convertido a JSON para generar tres valores distintos:
![\[monitoreo y observabilidad (figura 11)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/monitoring-observability-figure-11.png)
La característica Información de registros de CloudWatch descubre automáticamente los valores de la salida de JSON y analiza los mensajes como campos, sin necesidad de utilizar expresiones globales o regulares personalizadas. Al utilizar los registros estructurados en JSON, la siguiente consulta busca las invocaciones en las que el archivo cargado ocupa más de 1 MB, el tiempo de carga es superior a 1 segundo y la invocación no ha sido arranque en frío:
```
fields @message
| filter @message like /INFO/
| filter uploadedBytes > 1000000
| filter uploadTimeMS > 1000
| filter invocation != 1
```
Esta consulta podría producir el siguiente resultado:
![\[monitoreo y observabilidad (figura 12)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/monitoring-observability-figure-12.png)
Los campos detectados en JSON se completan automáticamente en el menú *Campos detectados* que aparece a la derecha. Los campos estándar generados por el servicio Lambda llevan el prefijo “@” y pueden ser consultados de la misma manera. Los registros de Lambda siempre incluyen los campos @timestamp, @logStream, @message, @requestId, @duration, @billedDuration, @type, @maxMemoryUsed, @memorySize. Si X-Ray está activado para una función, los registros también incluyen @xrayTraceId y @xraySegmentId.
Cuando un origen de eventos de AWS, como Amazon S3, Amazon SQS o Amazon EventBridge, invoca una función, se proporciona el evento completo como un objeto JSON de entrada. Al registrar este evento en la primera línea de la función, puede consultar cualquiera de los campos anidados mediante Información de registros de CloudWatch.
### Consultas de Insights útiles
En la siguiente tabla, se muestran ejemplos de consultas de Insights que pueden resultar útiles para supervisar las funciones de Lambda.
| Descripción | Ejemplo de sintaxis de consulta de |
| --- | --- |
| Los últimos 100 errores |
```
fields Timestamp, LogLevel, Message
\| filter LogLevel == "ERR"
\| sort @timestamp desc
\| limit 100
``` |
| Las 100 invocaciones más facturadas |
```
filter @type = "REPORT"
\| fields @requestId, @billedDuration
\| sort by @billedDuration desc
\| limit 100
``` |
| Porcentaje de arranques en frío en el total de invocaciones |
```
filter @type = "REPORT"
\| stats sum(strcontains(@message, "Init Duration"))/count(*) * 100 as
coldStartPct, avg(@duration)
by bin(5m)
``` |
| Informe percentil de la duración de Lambda |
```
filter @type = "REPORT"
\| stats
avg(@billedDuration) as Average,
percentile(@billedDuration, 99) as NinetyNinth,
percentile(@billedDuration, 95) as NinetyFifth,
percentile(@billedDuration, 90) as Ninetieth
by bin(30m)
``` |
| Informe percentil del uso de memoria de Lambda |
```
filter @type="REPORT"
\| stats avg(@maxMemoryUsed/1024/1024) as mean_MemoryUsed,
min(@maxMemoryUsed/1024/1024) as min_MemoryUsed,
max(@maxMemoryUsed/1024/1024) as max_MemoryUsed,
percentile(@maxMemoryUsed/1024/1024, 95) as Percentile95
``` |
| Invocaciones que utilizan el 100 % de la memoria asignada |
```
filter @type = "REPORT" and @maxMemoryUsed=@memorySize
\| stats
count_distinct(@requestId)
by bin(30m)
``` |
| Memoria promedio utilizada en todas las invocaciones |
```
avgMemoryUsedPERC,
avg(@billedDuration) as avgDurationMS
by bin(5m)
``` |
| Visualización de las estadísticas de memoria |
```
filter @type = "REPORT"
\| stats
max(@maxMemoryUsed / 1024 / 1024) as maxMemMB,
avg(@maxMemoryUsed / 1024 / 1024) as avgMemMB,
min(@maxMemoryUsed / 1024 / 1024) as minMemMB,
(avg(@maxMemoryUsed / 1024 / 1024) / max(@memorySize / 1024 / 1024)) * 100 as avgMemUsedPct,
avg(@billedDuration) as avgDurationMS
by bin(30m)
``` |
| Invocaciones en las que salió Lambda |
```
filter @message like /Process exited/
\| stats count() by bin(30m)
``` |
| Invocaciones con tiempo de espera agotado |
```
filter @message like /Task timed out/
\| stats count() by bin(30m)
``` |
| Informe de latencia |
```
filter @type = "REPORT"
\| stats avg(@duration), max(@duration), min(@duration)
by bin(5m)
``` |
| Memoria sobreaprovisionada |
```
filter @type = "REPORT"
\| stats max(@memorySize / 1024 / 1024) as provisonedMemMB,
min(@maxMemoryUsed / 1024 / 1024) as smallestMemReqMB,
avg(@maxMemoryUsed / 1024 / 1024) as avgMemUsedMB,
max(@maxMemoryUsed / 1024 / 1024) as maxMemUsedMB,
provisonedMemMB - maxMemUsedMB as overProvisionedMB
``` |
## Visualización de registros y paneles
Para cualquier consulta de Información de registros de CloudWatch, puede exportar los resultados a formato markdown o CSV. En algunos casos, es posible que resulte más útil crear [visualizaciones a partir de consultas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_Insights-Visualizing-Log-Data.html), siempre que exista al menos una función de agregación. La función `stats` permite definir agregaciones y agrupaciones.
El ejemplo anterior de *logInsightsJSON* filtraba según el tamaño y el tiempo de carga y excluía las primeras invocaciones. Esto dio como resultado una tabla de datos. Para monitorear un sistema de producción, puede resultar más útil visualizar los tamaños mínimo, máximo y promedio de los archivos para encontrar valores atípicos. Para ello, aplique la función de estadísticas con los agregados necesarios y agrúpelos según un valor temporal, por ejemplo, cada minuto:
Por ejemplo, fíjese en la consulta siguiente. Este es el mismo ejemplo de consulta que aparece en la sección [Registro estructurado JSON](#querying-logs-json), pero con funciones de agregación adicionales:
```
fields @message
| filter @message like /INFO/
| filter uploadedBytes > 1000000
| filter uploadTimeMS > 1000
| filter invocation != 1
| stats min(uploadedBytes), avg(uploadedBytes), max(uploadedBytes) by bin (1m)
```
Incluimos estos agregados porque puede ser más útil visualizar los tamaños mínimo, máximo y medio de los archivos para encontrar valores atípicos. Puede ver los resultados en la pestaña **Visualización**:
![\[monitoreo y observabilidad (figura 14)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/monitoring-observability-figure-14.png)
Cuando haya terminado de crear la visualización, si lo desea, puede agregar el gráfico a un panel de CloudWatch. Para ello, elija **Agregar al panel** situado encima de la visualización. Esto agrega la consulta como un widget y permite seleccionar intervalos de actualización automáticos, lo que facilita el monitoreo continuo de los resultados:
![\[monitoreo y observabilidad (figura 15)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/monitoring-observability-figure-15.png)
# Envío de registros de funciones de Lambda a Firehose
La consola de Lambda ahora ofrece la opción de enviar registros de funciones a Firehose. Esto permite la transmisión en tiempo real de sus registros a varios destinos compatibles con Firehose, incluidas herramientas de análisis de terceros y puntos de conexión personalizados.
**nota**
Puede configurar los registros de funciones de Lambda para que se envíen a Firehose mediante la consola de Lambda, la AWS CLI, AWS CloudFormation y todos los SDK de AWS.
## Precios
Para obtener información detallada sobre los precios, consulte [Precios de Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
## Permisos necesarios para el destino de registros de Firehose
Cuando utilice la consola de Lambda para configurar Firehose como destino del registro de su función, necesitará lo siguiente:
1. Los [permisos de IAM necesarios](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs) para usar Registros de CloudWatch con Lambda.
1. Para [configurar los filtros de suscripción con Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#FirehoseExample). Este filtro define qué eventos de registro se entregan a su flujo de Firehose.
## Envío de registros de funciones de Lambda a Firehose
En la consola de Lambda, puede enviar los registros de funciones directamente a Firehose después de crear una nueva función. Para hacerlo, siga estos pasos:
1. Inicie sesión en la consola de administración de AWS y abra la consola de Lambda.
1. Elija el nombre de su función.
1. Elija la pestaña **Configuración**.
1. Seleccione la pestaña **Herramientas de supervisión y operaciones**.
1. En la sección “Configuración de registro”, elija **Editar**.
1. En la sección “Contenido del registro”, seleccione un formato de registro.
1. En la sección “Destino de registro”, siga los pasos que se describen a continuación:
1. Seleccione un servicio de destino.
1. Elija **Crear un nuevo grupo de registro** o use un **Grupo de registro existente**.
**nota**
Si elige un grupo de registro existente para un destino de Firehose, asegúrese de que el grupo de registro que elija sea de tipo `Delivery`.
1. Elija un flujo de Firehose.
1. Aparecerá el grupo de registro `Delivery` de CloudWatch.
1. Seleccione **Save**.
**nota**
Si el rol de IAM proporcionado en la consola no tiene el permiso necesario, se producirá un error en la configuración del destino. Para corregirlo, consulte los permisos necesarios para el destino de registro de Firehose para proporcionar los permisos requeridos.
## Registro entre cuentas
Puede configurar Lambda para enviar registros al flujo de entrega de Firehose en una cuenta de AWS diferente. Esto requiere configurar un destino y establecer los permisos adecuados en ambas cuentas.
Para obtener instrucciones detalladas sobre cómo configurar el registro entre cuentas, incluidos los roles y las políticas de IAM que necesita, consulte [Setting up a new cross-account subscription](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html) en la documentación de Registros de CloudWatch.
# Envío de registros de funciones de Lambda a Amazon S3
Puede configurar su función de Lambda para enviar registros directamente a Amazon S3 mediante la consola de Lambda. Esta característica proporciona una solución rentable para el almacenamiento de registros a largo plazo y permite potentes opciones de análisis mediante servicios como Athena.
**nota**
Puede configurar los registros de funciones de Lambda para que se envíen a Amazon S3 mediante la consola de Lambda, la AWS CLI, AWS CloudFormation y todos los AWS SDK.
## Precios
Para obtener información detallada sobre los precios, consulte [Precios de Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
## Permisos necesarios para el destino de registros de Amazon S3
Cuando utilice la consola de Lambda para configurar Amazon S3 como destino del registro de su función, necesitará lo siguiente:
1. Los [permisos de IAM necesarios](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs) para usar Registros de CloudWatch con Lambda.
1. A [Configuración de un filtro de suscripciones de Registros de CloudWatch para enviar los registros de funciones de Lambda a Amazon S3](#using-cwl-subscription-filter-lambda-s3). Este filtro define qué eventos de registro se entregan a su bucket de Amazon S3.
## Configuración de un filtro de suscripciones de Registros de CloudWatch para enviar los registros de funciones de Lambda a Amazon S3
Para enviar registros desde Registros de CloudWatch a Amazon S3, debe crear un filtro de suscripción. Este filtro define qué eventos de registro se entregan a su bucket de Amazon S3. El bucket de Amazon S3 se debe usar en la misma región que el grupo de registro.
### Creación de un filtro de suscripción para Amazon S3
1. Cree un bucket de Amazon Simple Storage Service (Amazon S3). Recomendamos que utilice un bucket creado específicamente para Registros de CloudWatch. Sin embargo, si desea utilizar un bucket existente, vaya al paso 2.
Ejecute el siguiente comando y sustituya la región del marcador por la región que desee utilizar:
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket2 --create-bucket-configuration LocationConstraint=region
```
**nota**
`amzn-s3-demo-bucket2` es un ejemplo de nombre de bucket de Amazon S3. Está *reservado*. Para que este procedimiento funcione, debe reemplazarlo con el nombre único de su bucket de Amazon S3.
A continuación, se muestra un ejemplo de la salida:
```
{
"Location": "/amzn-s3-demo-bucket2"
}
```
1. Cree el rol de IAM que concede el permiso a Registros de CloudWatch para incluir datos en su bucket de Amazon S3. Esta política incluye una clave de contexto de condición global aws:SourceArn para ayudar a prevenir el confuso problema de seguridad adjunto. Para obtener más información, consulte [Confused deputy prevention](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions-confused-deputy.html).
1. Use un editor de texto para crear una política de confianza en un archivo `~/TrustPolicyForCWL.json`, como se indica a continuación:
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
},
"Action": "sts:AssumeRole"
}
}
```
1. Ejecute el comando create-role para crear el rol de IAM y especifique el archivo de política de confianza. Anote el valor de Role.Arn devuelto, ya que lo necesitará en un paso posterior:
```
aws iam create-role \
--role-name CWLtoS3Role \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoS3Role",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoS3Role"
}
}
```
1. Cree una política de permisos para definir las acciones que Registros de CloudWatch puede realizar en su cuenta. En primer lugar, utilice un editor de texto para crear una política de permisos en un archivo `~/PermissionsForCWL.json`:
```
{
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket2/*"]
}
]
}
```
Asocie la política de permisos con el rol mediante el siguiente comando `put-role-policy`:
```
aws iam put-role-policy --role-name CWLtoS3Role --policy-name Permissions-Policy-For-S3 --policy-document file://~/PermissionsForCWL.json
```
1. Elija un grupo de registro `Delivery` ya existente o cree un grupo de registro `Delivery` nuevo.
```
aws logs create-log-group --log-group-name my-logs --log-group-class DELIVERY --region REGION_NAME
```
1. `PutSubscriptionFilter` para configurar el destino
```
aws logs put-subscription-filter
--log-group-name my-logs
--filter-name my-lambda-delivery
--filter-pattern ""
--destination-arn arn:aws:s3:::amzn-s3-demo-bucket2
--role-arn arn:aws:iam::123456789012:role/CWLtoS3Role
--region REGION_NAME
```
## Envío de registros de funciones de Lambda a Amazon S3
En la consola de Lambda, puede enviar los registros de funciones directamente a Amazon S3 después de crear una nueva función. Para hacerlo, siga estos pasos:
1. Inicie sesión en la consola de administración de AWS y abra la consola de Lambda.
1. Elija el nombre de su función.
1. Elija la pestaña **Configuración**.
1. Seleccione la pestaña **Herramientas de supervisión y operaciones**.
1. En la sección “Configuración de registro”, elija **Editar**.
1. En la sección “Contenido del registro”, seleccione un formato de registro.
1. En la sección “Destino de registro”, siga los pasos que se describen a continuación:
1. Seleccione un servicio de destino.
1. Elija **Crear un nuevo grupo de registro** o use un **Grupo de registro existente**.
**nota**
Si elige un grupo de registro existente para un destino de Amazon S3, asegúrese de que el grupo de registro que elija sea de tipo `Delivery`.
1. Elija un bucket de Amazon S3 como destino para los registros de sus funciones.
1. Aparecerá el grupo de registro `Delivery` de CloudWatch.
1. Seleccione **Save**.
**nota**
Si el rol de IAM proporcionado en la consola no tiene los permisos necesarios, se producirá un error en la configuración del destino. Para solucionarlo, consulte [Permisos necesarios para el destino de registro de Amazon S3](#logging-s3-permissions).
## Registro entre cuentas
Puede configurar Lambda para enviar registros a un bucket de Amazon S3 en una cuenta de AWS diferente. Esto requiere configurar un destino y establecer los permisos adecuados en ambas cuentas.
Para obtener instrucciones detalladas sobre cómo configurar el registro entre cuentas, incluidos los roles y las políticas de IAM que necesita, consulte [Setting up a new cross-account subscription](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html) en la documentación de Registros de CloudWatch.
# Registro de llamadas a la API AWS Lambda mediante AWS CloudTrail
AWS Lambda se integra con [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html), un servicio que proporciona un registro de las acciones realizadas por un usuario, un rol o un Servicio de AWS. CloudTrail captura las llamadas a la API de Lambda como eventos. Las llamadas capturadas incluyen las llamadas desde la consola de Lambda y las llamadas desde el código a las operaciones de la API de Lambda. Mediante la información recopilada por CloudTrail, puede determinar la solicitud que se realizó a Lambda, la dirección IP desde la que se realizó, cuándo se realizó y detalles adicionales.
Cada entrada de registro o evento contiene información sobre quién generó la solicitud. La información de identidad del usuario le ayuda a determinar lo siguiente:
+ Si la solicitud se realizó con las credenciales del usuario raíz o del usuario.
+ Si la solicitud se realizó en nombre de un usuario de IAM Identity Center.
+ Si la solicitud se realizó con credenciales de seguridad temporales de un rol o fue un usuario federado.
+ Si la solicitud la realizó otro Servicio de AWS.
CloudTrail está activado en la Cuenta de AWS cuando usted crea la cuenta y tiene acceso automático al **Historial de eventos** de CloudTrail. El **Historial de eventos** de CloudTrail proporciona un registro visible e inmutable, que se puede buscar y descargar, de los últimos 90 días de eventos de gestión registrados en una Región de AWS. Para obtener más información, consulte [Trabajar con el historial de eventos de CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) en la *Guía del usuario de AWS CloudTrail*. No se cobran cargos de CloudTrail por ver el **Historial de eventos**.
Para mantener un registro permanente de los eventos en su Cuenta de AWS más allá de los 90 días, cree un registro de seguimiento o un almacén de datos de eventos de [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html).
**Registros de seguimiento de CloudTrail**
Un *registro de seguimiento* permite a CloudTrail enviar archivos de registro a un bucket de Amazon S3. Todos los registros de seguimiento que cree con la Consola de administración de AWS son multirregionales. Puede crear un registro de seguimiento de una sola región o multirregionales mediante la AWS CLI. Se recomienda crear un registro de seguimiento multirregional, ya que registra actividad en todas las Regiones de AWS de su cuenta. Si crea un registro de seguimiento de una sola región, solo podrá ver los eventos registrados en la Región de AWS del registro de seguimiento. Para obtener más información acerca de los registros de seguimiento, consulte [Creación de un registro de seguimiento para su Cuenta de AWS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) y [Creación de un registro de seguimiento para una organización](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html) en la *Guía del usuario de AWS CloudTrail*.
Puede crear un registro de seguimiento para enviar una copia de los eventos de administración en curso en su bucket de Amazon S3 sin costo alguno desde CloudTrail; sin embargo, hay cargos por almacenamiento en Amazon S3. Para obtener más información sobre los precios de CloudTrail, consulte [Precios de AWS CloudTrail](https://aws.amazon.com/cloudtrail/pricing/). Para obtener información acerca de los precios de Amazon S3, consulte [Precios de Amazon S3](https://aws.amazon.com/s3/pricing/).
**Almacenes de datos de eventos de CloudTrail Lake**
*CloudTrail Lake* le permite ejecutar consultas basadas en SQL sobre los eventos. CloudTrail Lake convierte los eventos existentes en formato JSON basado en filas al formato [ORC de Apache](https://orc.apache.org/). ORC es un formato de almacenamiento en columnas optimizado para una recuperación rápida de datos. Los eventos se agregan en *almacenes de datos de eventos*, que son recopilaciones inmutables de eventos en función de criterios que se seleccionan aplicando [selectores de eventos avanzados](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-concepts.html#adv-event-selectors). Los selectores que se aplican a un almacén de datos de eventos controlan los eventos que perduran y están disponibles para la consulta. Para obtener más información acerca de CloudTrail Lake, consulte [Trabajar con AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) en la *Guía del usuario de AWS CloudTrail*.
Los almacenes de datos de eventos de CloudTrail Lake y las consultas generan costos adicionales. Cuando crea un almacén de datos de eventos, debe elegir la [opción de precios](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-manage-costs.html#cloudtrail-lake-manage-costs-pricing-option) que desee utilizar para él. La opción de precios determina el costo de la incorporación y el almacenamiento de los eventos, así como el período de retención predeterminado y máximo del almacén de datos de eventos. Para obtener más información sobre los precios de CloudTrail, consulte [Precios de AWS CloudTrail](https://aws.amazon.com/cloudtrail/pricing/).
## Eventos de datos de Lambda en CloudTrail
Los [eventos de datos](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events) proporcionan información sobre las operaciones de recursos realizadas en o dentro de un recurso (por ejemplo, leer o escribir en un objeto de Amazon S3). Se denominan también operaciones del plano de datos. Los eventos de datos suelen ser actividades de gran volumen. De forma predeterminada, CloudTrail no registra la mayoría de los eventos de datos y el **historial de eventos** de CloudTrail no los registra.
Un evento de datos de CloudTrail que se registra de forma predeterminada para los servicios compatibles es `LambdaESMDisabled`. Para obtener más información sobre el uso de este evento para solucionar problemas con las asignaciones de orígenes de eventos de Lambda, consulte [Uso de CloudTrail para solucionar problemas de orígenes de eventos de Lambda deshabilitados](#cloudtrail-ESM-troubleshooting).
Se aplican cargos adicionales a los eventos de datos. Para obtener más información sobre los precios de CloudTrail, consulte [Precios de AWS CloudTrail](https://aws.amazon.com/cloudtrail/pricing/).
Puede registrar eventos de datos para el tipo de recurso de `AWS::Lambda::Function` mediante la consola de CloudTrail, la AWS CLI o las operaciones de la API de CloudTrail. Para obtener más información sobre cómo registrar los eventos de datos, consulte [Registro de eventos de datos con la Consola de administración de AWS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events-console) y [Registro de eventos de datos con la AWS Command Line Interface](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#creating-data-event-selectors-with-the-AWS-CLI) en la *Guía del usuario de AWS CloudTrail*.
En la siguiente tabla se muestra el tipo de recurso Lambda para el que puede registrar eventos de datos. La columna **Tipo de evento de datos (consola)** muestra el valor que se debe elegir en la lista de **tipos de eventos de datos** de la consola de CloudTrail. La columna **resources.type value** muestra el valor de `resources.type`, que especificaría al configurar los selectores de eventos avanzados mediante la AWS CLI o las API de CloudTrail. La columna **API de datos registradas en CloudTrail** muestra las llamadas a la API registradas en CloudTrail para el tipo de recurso.
| Tipo de evento de datos (consola) | resources.type value | API de datos registradas en CloudTrail |
| --- | --- | --- |
| Lambda | AWS::Lambda::Function | [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) |
Puede configurar selectores de eventos avanzados para filtrar según los campos `eventName`, `readOnly` y `resources.ARN` y así registrar solo los eventos que son importantes para usted. El siguiente ejemplo es la vista JSON de una configuración de eventos de datos que registra eventos solo para una función específica. Para obtener más información acerca de estos campos, consulte [https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html) en la *Referencia de la API de AWS CloudTrail*.
```
[
{
"name": "function-invokes",
"fieldSelectors": [
{
"field": "eventCategory",
"equals": [
"Data"
]
},
{
"field": "resources.type",
"equals": [
"AWS::Lambda::Function"
]
},
{
"field": "resources.ARN",
"equals": [
"arn:aws:lambda:us-east-1:111122223333:function:hello-world"
]
}
]
}
]
```
## Eventos de administración de Lambda en CloudTrail
Los [eventos de administración](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html#logging-management-events) proporcionan información sobre las operaciones de administración que se realizan en los recursos de su Cuenta de AWS. Se denominan también operaciones del plano de control. CloudTrail registra los eventos de administración de forma predeterminada.
Lambda admite el registro de las siguientes acciones como eventos de administración en los archivos de registro de CloudTrail.
**nota**
En el archivo de registro de CloudTrail, el `eventName` puede incluir información de la fecha y la versión, pero sigue haciendo referencia a la misma acción pública de la API. Por ejemplo, la acción `GetFunction` aparece como `GetFunction20150331v2`. La siguiente lista especifica en qué casos el nombre del evento difiere del nombre de la acción de la API.
+ [AddLayerVersionPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html)
+ [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) (nombre del evento: `AddPermission20150331v2`)
+ [CreateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_CreateAlias.html) (nombre del evento: `CreateAlias20150331`)
+ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) (nombre del evento: `CreateEventSourceMapping20150331`)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) (nombre del evento: `CreateFunction20150331`)
(Se omiten los parámetros `Environment` y `ZipFile` de los registros de CloudTrail para `CreateFunction`).
+ [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html)
+ [DeleteAlias](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteAlias.html) (nombre del evento: `DeleteAlias20150331`)
+ [DeleteCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteCodeSigningConfig.html)
+ [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html) (nombre del evento: `DeleteEventSourceMapping20150331`)
+ [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html) (nombre del evento: `DeleteFunction20150331`)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html) (nombre del evento: `DeleteFunctionConcurrency20171031`)
+ [DeleteFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionUrlConfig.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
+ [GetAlias](https://docs.aws.amazon.com/lambda/latest/api/API_GetAlias.html) (nombre del evento: `GetAlias20150331`)
+ [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)
+ [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)
+ [GetFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionUrlConfig.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [GetLayerVersionPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetLayerVersionPolicy.html)
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
+ [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)
+ [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html)
+ [ListFunctionUrlConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctionUrlConfigs.html)
+ [PublishLayerVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html) (nombre del evento: `PublishLayerVersion20181031`)
(Se omite el parámetro `ZipFile` de los registros de CloudTrail para `PublishLayerVersion`).
+ [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html) (nombre del evento: `PublishVersion20150331`)
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html) (nombre del evento: `PutFunctionConcurrency20171031`)
+ [PutFunctionCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionCodeSigningConfig.html)
+ [PutFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html)
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html)
+ [RemovePermission](https://docs.aws.amazon.com/lambda/latest/api/API_RemovePermission.html) (nombre del evento: `RemovePermission20150331v2`)
+ [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) (nombre del evento: `TagResource20170331v2`)
+ [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html) (nombre del evento: `UntagResource20170331v2`)
+ [UpdateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateAlias.html) (nombre del evento: `UpdateAlias20150331`)
+ [UpdateCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateCodeSigningConfig.html)
+ [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) (nombre del evento: `UpdateEventSourceMapping20150331`)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) (nombre del evento: `UpdateFunctionCode20150331v2`)
(Se omite el parámetro `ZipFile` de los registros de CloudTrail para `UpdateFunctionCode`).
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) (nombre del evento: `UpdateFunctionConfiguration20150331v2`)
(Se omite el parámetro `Environment` de los registros de CloudTrail para `UpdateFunctionConfiguration`).
+ [UpdateFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionEventInvokeConfig.html)
+ [UpdateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionUrlConfig.html)
## Uso de CloudTrail para solucionar problemas de orígenes de eventos de Lambda deshabilitados
Cuando cambia el estado de la asignación de orígenes de eventos mediante la acción de la API [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html), la llamada a la API se registra como un evento de administración en CloudTrail. Las asignaciones de orígenes de eventos también pueden pasar directamente al estado `Disabled` debido a errores.
Para los siguientes servicios, Lambda publica el evento de datos `LambdaESMDisabled` en CloudTrail cuando el origen del evento pasa al estado Deshabilitado:
+ Amazon Simple Queue Service (Amazon SQS)
+ Amazon DynamoDB
+ Amazon Kinesis
Lambda no admite este evento para ningún otro tipo de asignación de orígenes de eventos.
Si quiere recibir alertas cuando las asignaciones de orígenes de eventos para los servicios compatibles pasen al estado `Disabled`, configure una alarma en Amazon CloudWatch mediante el evento de CloudTrail `LambdaESMDisabled`. Para obtener más información sobre la configuración de una alarma de CloudWatch, consulte [Creating CloudWatch alarms for CloudTrail events: examples](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html).
La entidad `serviceEventDetails` del mensaje del evento `LambdaESMDisabled` contiene uno de los siguientes códigos de error.
**`RESOURCE_NOT_FOUND`**
El recurso especificado en la solicitud no existe.
**`FUNCTION_NOT_FOUND`**
La función adjunta al origen del evento no existe.
**`REGION_NAME_NOT_VALID`**
Un nombre de región proporcionado en la función o el origen del evento no es válido.
**`AUTHORIZATION_ERROR`**
Los permisos no se han establecido o están mal configurados.
**`FUNCTION_IN_FAILED_STATE`**
El código de función no se compila, se ha detectado una excepción irrecuperable o ha ocurrido una implementación incorrecta.
## Ejemplos de eventos de Lambda
Un evento representa una única solicitud de cualquier origen e incluye información sobre la operación de la API solicitada, la fecha y la hora de la operación, los parámetros de la solicitud, entre otras cosas. Los archivos de registro de CloudTrail no rastrean el orden en la pila de las llamadas a la API públicas, por lo que los eventos no aparecen en un orden específico.
El siguiente ejemplo muestra entradas de registro de CloudTrail que demuestra las acciones `GetFunction` y `DeleteFunction`.
**nota**
El `eventName` puede incluir información de la fecha y la versión, como `"GetFunction20150331"`, pero sigue haciendo referencia a la misma API pública.
```
{
"Records": [
{
"eventVersion": "1.03",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/myUserName",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "myUserName"
},
"eventTime": "2015-03-18T19:03:36Z",
"eventSource": "lambda.amazonaws.com",
"eventName": "GetFunction",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "Python-httplib2/0.8 (gzip)",
"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:iam::111122223333:user/myUserName is not authorized to perform: lambda:GetFunction on resource: arn:aws:lambda:us-west-2:111122223333:function:other-acct-function",
"requestParameters": null,
"responseElements": null,
"requestID": "7aebcd0f-cda1-11e4-aaa2-e356da31e4ff",
"eventID": "e92a3e85-8ecd-4d23-8074-843aabfe89bf",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
},
{
"eventVersion": "1.03",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/myUserName",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "myUserName"
},
"eventTime": "2015-03-18T19:04:42Z",
"eventSource": "lambda.amazonaws.com",
"eventName": "DeleteFunction20150331",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "Python-httplib2/0.8 (gzip)",
"requestParameters": {
"functionName": "basic-node-task"
},
"responseElements": null,
"requestID": "a2198ecc-cda1-11e4-aaa2-e356da31e4ff",
"eventID": "20b84ce5-730f-482e-b2b2-e8fcc87ceb22",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
]
}
```
Para obtener información sobre el contenido de los registros de CloudTrail, consulte [Contenido de los registros de CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html) en la *Guía del usuario de AWS CloudTrail*.
# Visualice las invocaciones de la función de Lambda mediante AWS X-Ray
Puede utilizar AWS X-Ray para visualizar los componentes de la aplicación, identificar cuellos de botella de rendimiento y solucionar problemas de solicitudes que dieron lugar a un error. Sus funciones de Lambda envían datos de rastreo a X-Ray, y X-Ray procesa los datos para generar un mapa de servicio y resúmenes de rastreo en los que se puede buscar.
Lambda admite dos modos de rastreo para X-Ray: `Active` y `PassThrough`. Con el rastreo `Active`, Lambda crea automáticamente segmentos de rastreo para las invocaciones de funciones y los envía a X-Ray. El modo `PassThrough`, por otro lado, simplemente propaga el contexto de rastreo a los servicios descendentes. Si ha habilitado el rastreo `Active` para su función, Lambda envía rastreos automáticamente a X-Ray para solicitudes de muestreo. Por lo general, el servicio ascendente, como Amazon API Gateway, o una aplicación alojada en Amazon EC2 que está instrumentada con el SDK de X-Ray, decide si las solicitudes entrantes deben ser rastreadas, luego agrega esa decisión de muestreo un encabezado de rastreo. Lambda usa ese encabezado para decidir si enviar o no el rastreo. Las trazas de los productores de mensajes anteriores, como Amazon SQS, se vinculan automáticamente a las trazas de las funciones de Lambda posteriores, lo que crea una vista integral de toda la aplicación. Para obtener más información, consulte [Seguimiento de aplicaciones basadas en eventos](https://docs.aws.amazon.com//xray/latest/devguide/xray-tracelinking.html) en la *Guía para desarrolladores de AWS X-Ray*.
**nota**
En la actualidad, el seguimiento de X-Ray no es compatible con las funciones de Lambda con Amazon Managed Streaming para Apache Kafka (Amazon MSK), Apache Kafka autoadministrado, Amazon MQ con ActiveMQ y RabbitMQ, o las asignaciones de orígenes de eventos de Amazon DocumentDB.
Para activar el seguimiento activo de la función Lambda mediante la consola, siga estos pasos:
**Cómo activar el seguimiento activo**
1. Abra la [página de Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija una función.
1. Elija **Configuration** (Configuración), y luego **Monitoring and operations tools** (Herramientas de supervisión y operaciones).
1. En **Herramientas de monitorización adicionales**, elija **Editar**.
1. En **CloudWatch Application Signals y AWS X-Ray**, seleccione **Habilitar** para **Seguimientos de servicios de Lambda**.
1. Seleccione **Save**.
La función necesita permiso para cargar datos de rastreo en X-Ray. Cuando activa el rastreo activo en la consola de Lambda, Lambda agrega los permisos necesarios al [rol de ejecución](lambda-intro-execution-role.md) de la función. De lo contrario, agregue la política [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess) al rol de ejecución.
X-Ray no sigue todas las solicitudes realizadas a la aplicación. X-Ray aplica un algoritmo de muestreo para garantizar que el seguimiento sea eficiente, a la vez que proporciona una muestra representativa de todas las solicitudes. La tasa de muestreo es 1 solicitud por segundo y un 5 por ciento de las solicitudes adicionales. La frecuencia de muestreo de X-Ray no se puede configurar para las funciones.
## Comprensión de los rastros
En X-Ray, un *seguimiento* registra información sobre una solicitud procesada por uno o varios *servicios*. Lambda registra 2 segmentos por seguimiento, lo que crea dos nodos en el gráfico de servicios. La siguiente imagen resalta estos dos nodos:
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/xray-servicemap-function.png)
El primer nodo, situado a la izquierda, representa el servicio de Lambda, que recibe la solicitud de invocación. El segundo nodo representa la función Lambda específica.
El segmento registrado para el servicio de Lambda, `AWS::Lambda`, abarca todos los pasos necesarios para preparar el entorno de ejecución de Lambda. Esto incluye programar la MicroVM, crear o desbloquear un entorno de ejecución con los recursos que configuró, así como también descargar el código de función y todas las capas.
El segmento `AWS::Lambda::Function` corresponde al trabajo realizado por la función.
**nota**
AWS está implementando cambios en el servicio Lambda. Debido a estos cambios, es posible que vea pequeñas diferencias entre la estructura y el contenido de los mensajes de registro del sistema y los segmentos de rastreo emitidos por diferentes funciones de Lambda en su Cuenta de AWS.
Este cambio afecta a los subsegmentos del segmento de la función. En los párrafos siguientes se describen los formatos antiguos y nuevos de estos subsegmentos.
Estos cambios se implementarán en las próximas semanas, y todas las funciones en todas las Regiones de AWS, excepto en las regiones de China y GovCloud, pasarán a utilizar el nuevo formato de mensajes de registro y segmentos de rastreo.
**Estructura de segmentos Lambda AWS X-Ray de estilo antiguo**
La estructura de X-Ray de estilo antiguo del segmento `AWS::Lambda` tiene el siguiente aspecto:
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/V2_sandbox_images/v1_XRay_structure.png)
En este formato, el segmento de la función tiene subsegmentos para `Initialization`, `Invocation` y `Overhead`. Solo para [Lambda SnapStart](snapstart.md), también hay un subsegmento `Restore` (que no se muestra en este diagrama).
El subsegmento `Initialization` representa la fase inicial del ciclo de vida del entorno de ejecución de Lambda. Durante esta fase, Lambda inicializa las extensiones y el tiempo de ejecución y ejecuta el código de inicialización de la función.
El subsegmento `Invocation` representa la fase de invocación donde Lambda invoca el controlador de funciones. Esto comienza con el registro en tiempo de ejecución y extensión y termina cuando el motor de ejecución está listo para enviar la respuesta.
(Solo para SnapStart de Lambda) El subsegmento `Restore` muestra el tiempo que tarda Lambda en restaurar una instantánea, cargar el tiempo de ejecución y ejecutar cualquier [enlace de tiempo de ejecución](snapstart-runtime-hooks.md) posterior a la restauración. El proceso de restauración de instantáneas puede incluir el tiempo dedicado a actividades fuera de la micro VM. Esta vez se informa en el subsegmento `Restore`. No se le cobrará por el tiempo que pase fuera de la micro VM para restaurar una instantánea.
El subsegmento `Overhead` representa la fase que ocurre entre el momento en que el motor de ejecución envía la respuesta y la señal para la siguiente invocación. Durante este tiempo, el motor de ejecución finaliza todas las tareas relacionadas con una invocación y se prepara para congelar el entorno limitado.
**importante**
Puede usar el SDK de X-Ray para extender el subsegmento `Invocation` con subsegmentos adicionales para llamadas descendentes, anotaciones y metadatos. No se puede acceder al segmento de función directamente o grabar trabajo hecho fuera del ámbito de invocación del controlador.
Para obtener más información acerca de las fases del entorno de ejecución de Lambda, consulte [Comprender el ciclo de vida del entorno de ejecución de Lambda](lambda-runtime-environment.md).
En el siguiente diagrama se muestra un ejemplo de seguimiento que utiliza la estructura de X-Ray de estilo antiguo.
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v1.png)
Observe los dos segmentos en el ejemplo. Ambos se denominan **my-function**, pero uno tiene un origen de `AWS::Lambda` y el otro tiene origen de `AWS::Lambda::Function`. Si el segmento `AWS::Lambda` muestra un error, el servicio Lambda tuvo un problema. Si el segmento `AWS::Lambda::Function` muestra un error, la función tuvo un problema.
**nota**
Ocasionalmente, es posible que observe una gran brecha entre las fases de inicialización e invocación de la función en sus trazas de X-Ray. En el caso de las funciones que utilizan la [simultaneidad aprovisionada](provisioned-concurrency.md), esto se debe a que Lambda inicializa las instancias de la función mucho antes de la invocación. Para las funciones que utilizan la [simultaneidad sin reservas (bajo demanda)](lambda-concurrency.md), Lambda puede inicializar proactivamente una instancia de función, incluso si no hay ninguna invocación. Visualmente, ambos casos se muestran como un intervalo de tiempo entre las fases de inicialización e invocación.
**Estructura de segmentos Lambda AWS X-Ray de estilo nuevo**
La estructura de X-Ray de estilo nuevo del segmento `AWS::Lambda` tiene el siguiente aspecto:
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/V2_sandbox_images/v2_XRay_structure.png)
En este formato nuevo, el subsegmento `Init` representa la fase inicial del ciclo de vida del entorno de ejecución de Lambda como antes.
No hay ningún segmento de invocación en el nuevo formato. En cambio, los subsegmentos de clientes se adjuntan directamente al segmento `AWS::Lambda::Function`. Este segmento contiene las siguientes métricas como anotaciones:
+ `aws.responseLatency`: el tiempo que tarda la función en ejecutarse
+ `aws.responseDuration`: el tiempo necesario para transferir la respuesta al cliente
+ `aws.runtimeOverhead`: la cantidad de tiempo adicional que necesitó el tiempo de ejecución para finalizar
+ `aws.extensionOverhead`: la cantidad de tiempo adicional que necesitaron las extensiones para finalizar
En el siguiente diagrama se muestra un ejemplo de seguimiento que utiliza la estructura de X-Ray de estilo nuevo.
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v2.png)
Observe los dos segmentos en el ejemplo. Ambos se denominan **my-function**, pero uno tiene un origen de `AWS::Lambda` y el otro tiene origen de `AWS::Lambda::Function`. Si el segmento `AWS::Lambda` muestra un error, el servicio Lambda tuvo un problema. Si el segmento `AWS::Lambda::Function` muestra un error, la función tuvo un problema.
Consulte los siguientes temas para obtener una introducción específica del seguimiento en Lambda:
+ [Instrumentación del código Node.js en AWS Lambda](nodejs-tracing.md)
+ [Instrumentación del código Python en AWS Lambda](python-tracing.md)
+ [Instrumentación del código Ruby en AWS Lambda](ruby-tracing.md)
+ [Instrumentación del código Java en AWS Lambda](java-tracing.md)
+ [Instrumentación del código Go en AWS Lambda](golang-tracing.md)
+ [Instrumentación de código C\$1 en AWS Lambda](csharp-tracing.md)
Para obtener una lista completa de los servicios que son compatibles con la instrumentación activa, consulte [los Servicios de AWS compatibles](https://docs.aws.amazon.com/xray/latest/devguide/xray-usage.html#xray-usage-codechanges) en la Guía para desarrolladores de AWS X-Ray.
## Comportamiento de rastreo predeterminado en Lambda
Si no tiene activado el rastreo `Active`, Lambda pasa por defecto al modo de rastreo `PassThrough`.
En el modo `PassThrough`, Lambda reenvía el encabezado de rastreo de X-Ray a los servicios descendentes, pero no envía los rastreos de forma automática. Esto es cierto incluso si el encabezado de rastreo contiene una decisión de muestrear la solicitud. Si el servicio ascendente no proporciona un encabezado de rastreo de X-Ray, Lambda genera un encabezado y toma la decisión de no muestrear. Sin embargo, puede enviar sus propios rastreos llamando a las bibliotecas de rastreo desde el código de su función.
**nota**
Anteriormente, Lambda enviaba los rastreos automáticamente cuando los servicios ascendentes, como Amazon API Gateway, añadían un encabezado de rastreo. Al no enviar rastreos de forma automática, Lambda le da el control para rastrear las funciones que son importantes para usted. Si su solución depende de este comportamiento de rastreo pasivo, cambie al rastreo `Active`.
## Permisos de rol de ejecución
Lambda necesita los siguientes permisos para enviar datos de seguimiento a X-Ray. Añada dichos permisos al [rol de ejecución](lambda-intro-execution-role.md) de su función.
+ [xray:PutTraceSegments](https://docs.aws.amazon.com/xray/latest/api/API_PutTraceSegments.html)
+ [xray:PutTelemetryRecords](https://docs.aws.amazon.com/xray/latest/api/API_PutTelemetryRecords.html)
Estos permisos se incluyen en la política administrada [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home?#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess).
## Habilitación del rastreo `Active` con la API de Lambda
Para administrar la configuración de seguimiento con la AWS CLI o el AWS SDK, utilice las siguientes operaciones de API:
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
El siguiente comando de ejemplo de la AWS CLI habilita el seguimiento activo en una función llamada **my-function**.
```
aws lambda update-function-configuration --function-name my-function \
--tracing-config Mode=Active
```
El modo de seguimiento forma parte de la configuración específica de la versión, cuando se publica una versión de la función. No se puede cambiar el modo de seguimiento de una versión publicada.
## Habilitación del rastreo `Active` con CloudFormation
Para activar el seguimiento en un recurso de `AWS::Lambda::Function` de una plantilla de CloudFormation, utilice la propiedad `TracingConfig`.
**Example [función-inline.yml](https://github.com/awsdocs/aws-lambda-developer-guide/blob/master/templates/function-inline.yml): configuración de rastreo**
```
Resources:
function:
Type: [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)
Properties:
TracingConfig:
Mode: Active
...
```
Para un recurso AWS Serverless Application Model de AWS SAM (`AWS::Serverless::Function`) , utilice la propiedad `Tracing`.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/template.yml): configuración de rastreo**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Tracing: Active
...
```
# Supervise el rendimiento de las funciones con Amazon CloudWatch Lambda Insights
Amazon CloudWatch Lambda Insights recopila y agrega métricas y registros de rendimiento en tiempo de ejecución de funciones de Lambda para las aplicaciones sin servidor. En esta página se describe cómo habilitar y utilizar Lambda Insights para diagnosticar problemas con las funciones de Lambda.
**Topics**
+ [Cómo monitorea las aplicaciones sin servidor de Lambda Insights](#monitoring-insights-how)
+ [Precios](#monitoring-insights-pricing)
+ [Tiempos de ejecución admitidos](#monitoring-insights-runtimes)
+ [Activación de Lambda Insights en la consola de Lambda](#monitoring-insights-enabling-console)
+ [Habilitación de Lambda Insights mediante programación](#monitoring-insights-enabling-programmatically)
+ [Uso del panel de información de Lambda Insights](#monitoring-insights-multifunction)
+ [Ejemplo de flujo de trabajo para detectar anomalías de función](#monitoring-insights-anomalies)
+ [Ejemplo de flujo de trabajo mediante consultas para solucionar problemas de una función](#monitoring-insights-queries)
+ [Siguientes pasos](#monitoring-console-next-up)
## Cómo monitorea las aplicaciones sin servidor de Lambda Insights
CloudWatch Lambda Insights es una solución de monitoreo y solución de problemas para aplicaciones sin servidor que se ejecutan en AWS Lambda. La solución recopila, agrega y resume métricas de nivel de sistema, incluido el tiempo de CPU, la memoria, el disco y el uso de red. También recopila, agrega y resume información de diagnóstico como inicios en frío y paradas de trabajo de Lambda para ayudarle a aislar problemas con las funciones de Lambda y resolverlos rápidamente.
Lambda Insights utiliza un nuevo CloudWatch Lambda Insights [extensión](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html), que se proporciona como una [capa de Lambda](chapter-layers.md). Cuando habilita esta extensión en una función de Lambda para un tiempo de ejecución admitido, recopila métricas de nivel de sistema y emite un único evento de registro de rendimiento para cada invocación de esa función de Lambda. CloudWatch utiliza el formato de métrica incrustado para extraer métricas de los eventos de registro. Para obtener más información, consulte [Uso de extensiones de AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html).
La capa de Lambda Insights amplía `CreateLogStream` y `PutLogEvents` para el grupo de registros de `/aws/lambda-insights/`.
## Precios
Cuando habilita Lambda Insights para la función de Lambda, Lambda Insights notifica 8 métricas por función y cada invocación de función envía alrededor de 1 KB de datos de registro a CloudWatch. Sólo hay que pagar por las métricas y registros que Lambda Insights notifica para la función. No se requieren cuotas mínimas ni políticas obligatorias de uso del servicio.¿. No hay que pagar por Lambda Insights si la función no se invoca. Para obtener más información sobre precios, consulte [Precios de Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
## Tiempos de ejecución admitidos
Puede utilizar Lambda Insights con cualquiera de los tiempos de ejecución que soportan [extensiones de Lambda](runtimes-extensions-api.md).
## Activación de Lambda Insights en la consola de Lambda
Puede habilitar el monitoreo mejorado deLambda Insights en funciones de Lambda nuevas y existentes. Cuando habilita Lambda Insights en una función de la consola de para un tiempo de ejecución compatible, Lambda agrega la [extensión](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html) de Lambda Insights como una capa a la función y verifica o intenta adjuntar la política [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor) al [rol de ejecución](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) de la función.
**Activar Lambda Insights en la consola de Lambda**
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija su función.
1. Elija la pestaña **Configuración**.
1. En el menú de la izquierda, elija **Herramientas de monitoreo y operación**.
1. En el panel **Herramientas adicionales de monitoreo**, elija **Editar**.
1. En **CloudWatch Lambda Insights**, active **Monitorización mejorada**.
1. Seleccione **Guardar**.
## Habilitación de Lambda Insights mediante programación
También puede habilitar Lambda Insights mediante la AWS Command Line Interface (AWS CLI), AWS Serverless Application Model (SAM) CLI, CloudFormation o AWS Cloud Development Kit (AWS CDK). Cuando habilita Lambda Insights mediante programación en una función para un tiempo de ejecución compatible, CloudWatch adjunta la política [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor) al [rol de ejecución](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) de la función.
Para obtener más información, consulte [Introducción a Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights-Getting-Started.html) en la *Guía del usuario de Amazon CloudWatch*.
## Uso del panel de información de Lambda Insights
El panel de Lambda Insights tiene dos vistas en la consola de CloudWatch: la vista general de múltiples funciones y la vista de una sola función. La vista general de múltiples funciones agrega las métricas de tiempo de ejecución para las funciones de Lambda en la cuenta y la región de AWS actuales. La vista de una sola función muestra las métricas de tiempo de ejecución disponibles para una sola función Lambda.
Puede utilizar información general del panel multifunción de Lambda Insights de la consola de CloudWatch para identificar funciones de Lambda utilizadas en exceso o infrautilizadas. Puede utilizar la vista de una sola función del panel de Lambda Insights de la consola de CloudWatch para solucionar problemas de solicitudes individuales.
**Para consultar las métricas de tiempo de ejecución de todas las funciones**
1. Abra la página [Multi-function (Múltiples funciones)](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) de la consola de CloudWatch.
1. Elija entre los intervalos de tiempo predefinidos o elija un intervalo de tiempo personalizado.
1. (Opcional) Elija **Add to dashboard (Agregar al panel)** para agregar los widgets al panel de CloudWatch.
![\[La informanción general de múltiples funciones en el panel de Lambda Insights.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/lambdainsights-multifunction-view.png)
**Para consultar las métricas de tiempo de ejecución de una sola función**
1. Abra la página [Single-function (Una sola función)](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:functions) de la consola de CloudWatch.
1. Elija entre los intervalos de tiempo predefinidos o elija un intervalo de tiempo personalizado.
1. (Opcional) Elija **Add to dashboard (Agregar al panel)** para agregar los widgets al panel de CloudWatch.
![\[La vista de una sola función en el panel de Lambda Insights.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/lambainsights-singlefunction-view.png)
Para obtener más información, consulte [Creación y uso de widgets en paneles de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html).
## Ejemplo de flujo de trabajo para detectar anomalías de función
Puede utilizar la vista general de múltiples funciones del panel de Lambda Insights para identificar y detectar anomalías de memoria informática con la función. Por ejemplo, si la vista general de múltiples funciones indica que una función utiliza una cantidad de memoria grande, puede consultar métricas detalladas de utilización de memoria en el panel **Memory Usage (Uso de memoria)**. A continuación, puede ir al panel de métricas para habilitar la detección de anomalías o crear una alarma.
**Para habilitar la detección de anomalías para una función**
1. Abra la página [Multi-function (Múltiples funciones)](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) de la consola de CloudWatch.
1. En **Function summary (Resumen de funciones)**, elija el nombre de la función.
La vista de una sola función se abre con las métricas de tiempo de ejecución de la función.
![\[El panel de resumen de funciones en el panel de Lambda Insights.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/lambdainsights-function-summary.png)
1. En el panel **Memory Usage (Uso de memoria)**, elija los tres puntos verticales y, a continuación, elija **View in metrics (Ver en métricas)** para abrir el panel **Metrics (Métricas)**.
![\[El menú del panel Memory Usage (Uso de memoria).\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/lambdainsights-memory-usage.png)
1. En la pestaña **Graphed metrics (Métricas gráficas)**, en la columna **Actions (Acciones)**, elija el primer icono para habilitar la detección de anomalías para la función.
![\[La pestaña Graphed metrics (Métricas gráficas) del panel Memory Usage (Uso de memoria).\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/lambdainsights-graphed-metrics.png)
Para obtener más información, consulta [Uso de la detección de anomalías de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html).
## Ejemplo de flujo de trabajo mediante consultas para solucionar problemas de una función
Puede utilizar la vista de una sola función en el panel de Lambda Insights para identificar la causa raíz de un pico en la duración de la función. Por ejemplo, si la vista general de múltiples funciones indica un aumento grande en la duración de la función, puede pausar o elegir cada función en el panel de **Duration (Duración)** para determinar qué función está causando el aumento. A continuación, puede ir a la vista de una sola función y revisar los **registros de aplicación** para determinar la causa raíz.
**Para ejecutar consultas en una función**
1. Abra la página [Multi-function (Múltiples funciones)](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) de la consola de CloudWatch.
1. En el panel **Duration (Duración)**, elija la función para filtrar las métricas de duración.
![\[Se elige una función en el panel de Duration (Duración).\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/lambdainsights-choose-function.png)
1. Abra la página [Una sola función](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:functions).
1. Elija el menú desplegable **Filter metrics by function name (Filtrar métricas por nombre de función)** y, a continuación, elija la función.
1. Para consultar los **Most recent 1000 application logs (1000 registros de aplicaciones más recientes)**, elija la pestaña **Application logs (Registros de aplicaciones)**.
1. Revise la **Timestamp (Marca temporal)** y el **Message (Mensaje)** para identificar la solicitud de invocación que desea solucionar problemas.
![\[Los Most recent 1000 application logs (1000 registros de aplicaciones más recientes).\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/lambdainsights-application-logs.png)
1. Para mostrar las **Most recent 1000 invocations (1000 invocaciones más recientes)**, elija la pestaña **Invocations (Invocaciones)**.
1. Seleccione la **Timestamp (Marca temporal)** o el **Message (Mensaje)** para la solicitud de invocación que desea solucionar problemas.
![\[Selección de una solicitud de invocación reciente.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/lambdainsights-invocations-function-select.png)
1. Elija el menú desplegable **View logs (Ver registros)** y, a continuación, elija **View performance logs (Ver registros de rendimiento)**.
Se abre una consulta autogenerada para la función en el panel de **Logs Insights**.
1. Elija **Run query (Ejecutar consulta)** para generar un mensaje de **Logs (Registros)** para la solicitud de invocación.
![\[Consulta de la función seleccionada en el panel de Logs Insights.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/lambdainsights-query.png)
## Siguientes pasos
+ Obtenga información sobre cómo crear un panel de CloudWatch Logs en [Create a Dashboard (Crear un panel)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html) en la *Guía del usuario de Amazon CloudWatch*.
+ Obtenga información sobre cómo agregar consultas a un panel de CloudWatch Logs en [Add Query to Dashboard or Export Query Results (Agregar consulta al panel o Exportar resultados de consulta)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) en la *Guía del usuario de Amazon CloudWatch*.
# Monitoreo de aplicaciones de Lambda
La sección **Aplicaciones** de la consola de Lambda incluye la pestaña **Monitoreo** en la que puede revisar un panel de Amazon CloudWatch con métricas agrupadas de los recursos de su aplicación.
**Para monitorizar una aplicación de Lambda**
1. Abra la página [Applications (Aplicaciones)](https://console.aws.amazon.com/lambda/home#/applications) de la consola de Lambda.
1. Elija **Monitoring (Monitorización)**.
1. Para ver más detalles sobre las métricas de cualquier gráfico, seleccione **Ver en métricas** en el menú desplegable.
![\[Un widget de monitorización.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/applications-monitoring-widget.png)
El gráfico aparece en una nueva pestaña, con las métricas pertinentes que se indican debajo del gráfico. Puede personalizar la vista de este gráfico, cambiando las métricas y los recursos mostrados, la estadística, el periodo y otros factores para obtener una mejor comprensión de la situación actual.
De forma predeterminada, la consola de Lambda muestra un panel básico. Puede personalizar esta página agregando uno o más paneles de Amazon CloudWatch a su plantilla de aplicación con el tipo de recurso [AWS::CloudWatch::Dashboard](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cw-dashboard.html). Si su plantilla incluye uno o varios paneles, la página le mostrará sus paneles en lugar del panel predeterminado. Puede cambiar entre los paneles con el menú desplegable en la parte superior derecha de la página. En el siguiente ejemplo se crea un panel con un único widget que crea gráficos del número de invocaciones de una función denominada `my-function`.
**Example plantilla de panel de funciones**
```
Resources:
MyDashboard:
Type: AWS::CloudWatch::Dashboard
Properties:
DashboardName: my-dashboard
DashboardBody: |
{
"widgets": [
{
"type": "metric",
"width": 12,
"height": 6,
"properties": {
"metrics": [
[
"AWS/Lambda",
"Invocations",
"FunctionName",
"my-function",
{
"stat": "Sum",
"label": "MyFunction"
}
],
[
{
"expression": "SUM(METRICS())",
"label": "Total Invocations"
}
]
],
"region": "us-east-1",
"title": "Invocations",
"view": "timeSeries",
"stacked": false
}
}
]
}
```
Para obtener más información acerca de la creación de paneles y widgets de CloudWatch, consulte [Estructura y sintaxis del cuerpo del panel](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/CloudWatch-Dashboard-Body-Structure.html) en la *Referencia de la API de Amazon CloudWatch*.
# Monitoreo del rendimiento de las aplicaciones con Amazon CloudWatch Application Signals
Amazon CloudWatch Application Signals es una solución de monitoreo del rendimiento de las aplicaciones (APM) que permite a los desarrolladores y operadores supervisar el estado y el rendimiento de sus aplicaciones sin servidor creadas con Lambda. Puede activar Application Signals con un solo clic desde la consola de Lambda y no necesita agregar ningún código de instrumentación ni dependencias externas a la función de Lambda. Después de habilitar Application Signals, puede ver todas las métricas y seguimientos recopilados en la consola de CloudWatch. En esta página, se describe cómo habilitar y ver los datos de telemetría de Application Signals para sus aplicaciones.
**Topics**
+ [Cómo se integra Application Signals con Lambda](#monitoring-application-signals-how)
+ [Precios](#monitoring-application-signals-pricing)
+ [Tiempos de ejecución admitidos](#monitoring-application-signals-runtimes)
+ [Activación de Application Signals en la consola de Lambda](#monitoring-application-signals-console)
+ [Uso del panel de Application Signals](#monitoring-application-signals-dashboard)
## Cómo se integra Application Signals con Lambda
Application Signals instrumenta automáticamente sus funciones de Lambda mediante las bibliotecas [AWS Distro for OpenTelemetry (ADOT)](https://aws-otel.github.io/) mejoradas, que se proporcionan a través de una [capa de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html). Application Signals lee los datos recopilados por la capa y genera paneles con métricas de rendimiento clave para sus aplicaciones.
Puede adjuntar esta capa con un solo clic y [habilitar Application Signals](#monitoring-application-signals-console) en la consola de Lambda. Cuando activa Application Signals desde la consola, Lambda hace lo siguiente en su nombre:
+ Actualiza el rol de ejecución de la función para incluir la `CloudWatchLambdaApplicationSignalsExecutionRolePolicy`. [ Esta política](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.html) proporciona acceso de escritura a los grupos de registros de AWS X-Ray y CloudWatch que se utilizan para Application Signals.
+ Agrega una capa a la función que la instrumenta automáticamente para capturar datos de telemetría, como las solicitudes, la disponibilidad, la latencia, los errores y las fallas. Para garantizar que Application Signals funcione correctamente, elimine cualquier código de instrumentación del SDK de X-Ray existente de su función. El código de instrumentación personalizado del SDK de X-Ray puede interferir con la instrumentación proporcionada por la capa.
+ Agrega la variable de entorno `AWS_LAMBDA_EXEC_WRAPPER` a la función y establece su valor en `/opt/otel-instrument`. Esta variable de entorno modifica el comportamiento de inicio de la función para utilizar la capa de Application Signals y es necesaria para una instrumentación adecuada. Si esta variable de entorno ya existe, asegúrese de que esté establecida en el valor requerido.
## Precios
El uso de Application Signals para sus funciones de Lambda conlleva costos. Para obtener más información sobre precios, consulte [Precios de Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
## Tiempos de ejecución admitidos
La integración de Application Signals con Lambda funciona con los siguientes tiempos de ejecución:
+ .NET 8
+ Java 11
+ Java 17
+ Java 21
+ Python 3.10
+ Python 3.11
+ Python 3.12
+ Python 3.13
+ Node.js 18.x
+ Node.js 20.x
+ Node.js 22.x
## Activación de Application Signals en la consola de Lambda
Puede habilitar Application Signals en cualquier función de Lambda existente mediante un [tiempo de ejecución compatible](#monitoring-application-signals-runtimes). Los siguientes pasos describen cómo habilitar Application Signals con un solo clic en la consola de Lambda.
**Cómo habilitar Application Signals en la consola de Lambda**
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija su función.
1. Elija la pestaña **Configuración**.
1. En el menú de la izquierda, elija **Herramientas de monitoreo y operación**.
1. En el panel **Herramientas adicionales de monitoreo**, elija **Editar**.
1. En **CloudWatch Application Signals y AWS X-Ray** y en **Application Signals**, seleccione **Habilitar**.
1. Seleccione **Save**.
Si es la primera vez que habilita Application Signals para su función, también debe realizar una configuración única de detección de servicios para Application Signals en la consola de CloudWatch. Tras completar esta configuración única de detección de servicios, Application Signals descubre automáticamente cualquier función de Lambda adicional para la que habilite Application Signals en todas las regiones.
**nota**
Tras invocar la función actualizada, los datos del servicio pueden tardar hasta 10 minutos en empezar a aparecer en el panel de Application Signals de la consola de CloudWatch.
## Uso del panel de Application Signals
Tras habilitar Application Signals para su función, podrá visualizar las métricas de la aplicación en la consola de CloudWatch. Puede ver rápidamente el panel de control de Application Signals asociado desde la consola de Lambda con estos pasos:
**Cómo ver el panel de Application Signals de su función**
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija su función.
1. Elija la pestaña **Supervisar**.
1. Pulse el botón **Ver Application Signals**. Esto lo lleva directamente al resumen de Application Signals para su servicio en la consola de CloudWatch.
Por ejemplo, en la siguiente captura de pantalla se muestran métricas de latencia, número de solicitudes, disponibilidad, tasa de fallos y tasa de errores de una función en un intervalo de tiempo de 10 minutos.
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/monitoring-application-signals-dashboard.png)
Para aprovechar al máximo su integración con Application Signals, puede crear objetivos de nivel de servicio (SLO) para su aplicación. Por ejemplo, puede crear SLO de latencia para garantizar que su aplicación responda rápidamente a las solicitudes de los usuarios y SLO de disponibilidad para hacer un seguimiento del tiempo de actividad. Los SLO pueden ayudarlo a detectar la degradación del rendimiento o las interrupciones antes de que afecten a sus usuarios. Para obtener más información, consulte [Objetivos de nivel de servicio (SLO)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html) en la Guía del usuario de Amazon CloudWatch.
# Depuración de forma remota de funciones de Lambda con Visual Studio Code
Con la característica de depuración remota de [AWS Toolkit for Visual Studio Code](https://aws.amazon.com/visualstudiocode/), puede depurar las funciones de Lambda que se ejecutan directamente en la nube de AWS. Esto resulta útil cuando se investigan problemas que son difíciles de replicar de forma local o que solo se diagnostican con registros.
Con la depuración remota, puede:
+ Establecer puntos de interrupción en el código de su función de Lambda.
+ Realizar la ejecución del código en tiempo real.
+ Inspeccionar las variables y el estado durante el tiempo de ejecución.
+ Depurar las funciones de Lambda implementadas en AWS, incluidas las de las VPC o con permisos de IAM específicos.
## Tiempos de ejecución admitidos
La depuración remota es compatible con los siguientes tiempos de ejecución:
+ Python (AL2023)
+ Java
+ JavaScript/Node.js (AL2023)
**nota**
La depuración remota es compatible con las arquitecturas x86\$164 y arm64.
## Seguridad y depuración remota
La depuración remota funciona dentro de los límites de seguridad de Lambda existentes. Los usuarios pueden adjuntar capas a una función mediante el permiso `UpdateFunctionConfiguration`, que ya tiene la capacidad de acceder a las variables de entorno y a la configuración de la función. La depuración remota no se extiende más allá de estos permisos existentes. En su lugar, agrega controles de seguridad adicionales mediante una tunelización segura y una administración automática de las sesiones. Además, la depuración remota es una característica totalmente controlada por el cliente que requiere permisos y acciones explícitos:
+ **Creación de túneles seguros de IoT**: el Toolkit de AWS debe crear un túnel seguro de IoT, lo que solo ocurre con el permiso explícito del usuario mediante `iot:OpenTunnel`.
+ **Administración de archivos adjuntos y tokens de la capa de depuración**: el proceso de depuración mantiene la seguridad mediante estos controles:
+ La capa de depuración debe estar asociada a la función de Lambda y este proceso requiere los siguientes permisos: `lambda:UpdateFunctionConfiguration` y `lambda:GetLayerVersion`.
+ Se debe actualizar un token de seguridad (generado mediante `iot:OpenTunnel`) en la variable de entorno de la función antes de cada sesión de depuración, lo que requiere `lambda:UpdateFunctionConfiguration`.
+ Por motivos de seguridad, este token se rota automáticamente y la capa de depuración se elimina automáticamente al final de cada sesión de depuración y no se puede volver a utilizar.
**nota**
La depuración remota es compatible con las arquitecturas x86\$164 y arm64.
## Requisitos previos
Antes de comenzar la depuración remota, asegúrese de que dispone de lo siguiente:
1. Una función de Lambda implementada en su cuenta de AWS.
1. AWS Toolkit for Visual Studio Code. Consulte [Configuración del AWS Toolkit for Visual Studio Code](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/setup-toolkit.html) para ver las instrucciones de instalación.
1. Debe tener instalada la versión **3.69.0** o posterior del Toolkit de AWS.
1. Credenciales de AWS configuradas en AWS Toolkit for Visual Studio Code. Para obtener más información, consulte [Autenticación y control de acceso](foundation-iac-local-development.md#lambda-functions-vscode-authentication-and-access-control).
## Depuración remota de las funciones de Lambda
Siga estos pasos para iniciar una sesión de depuración remota:
1. Abra AWS Explorer en VS Code seleccionando el icono AWS en la barra lateral izquierda.
1. Expanda la sección de Lambda para ver sus funciones.
1. Haga clic con el botón derecho en la función que desee depurar.
1. En el menú contextual, seleccione **Invocar remotamente**.
1. En la ventana de invocación que se abre, marque la casilla **Habilitar depuración**.
1. Haga clic en **Invocar** para iniciar la sesión de depuración remota.
**nota**
Las funciones de Lambda tienen un límite combinado de 250 MB para el código de la función y todas las capas adjuntas. La capa de depuración remota agrega aproximadamente 40 MB al tamaño de la función.
Una sesión de depuración remota finaliza cuando:
+ Selecciona **Eliminar configuración de depuración** en la pantalla de configuración de invocación remota.
+ Selecciona el icono de desconexión en los controles de depuración de VS Code.
+ Selecciona el archivo de controlador en el editor de VS Code.
**nota**
La capa de depuración se elimina automáticamente después de 60 segundos de inactividad tras su última invocación.
## Deshabilitación de la depuración remota
Hay tres formas de deshabilitar esta característica:
+ **Denegar actualizaciones de funciones**: establezca `lambda:UpdateFunctionConfiguration` en `deny`.
+ **Restringir los permisos de IoT**: deniegue los permisos relacionados con el IoT
+ **Bloquear capas de depuración**: deniegue `lambda:GetLayerVersion` para los siguientes ARN:
+ `arn:aws:lambda:*:*:layer:LDKLayerX86:*`
+ `arn:aws:lambda:*:*:layer:LDKLayerArm64:*`
**nota**
Al deshabilitar esta característica, se impide agregar la capa de depuración durante las actualizaciones de la configuración de la función.
## Información adicional
Para obtener más información sobre el uso de Lambda en VS Code, consulte [Desarrollo local de funciones de Lambda con VS Code](foundation-iac-local-development.md).
Para obtener instrucciones detalladas sobre la solución de problemas, los casos de uso avanzados y la disponibilidad regional, consulte [Depuración remota de funciones de Lambda](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html) en la Guía del usuario de AWS Toolkit for Visual Studio Code.