Una función Lambda procesa mensajes de dispositivos IoT. La empresa necesita métricas de rendimiento casi en tiempo real que cuenten cuántos mensajes recibe y procesa la función por intervalo de tiempo. La inicialización y el post-procesamiento no deben incluirse en la medición del rendimiento. ¿Qué debería implementar el desarrollador?

La opción correcta es modificar el código para publicar una métrica personalizada de CloudWatch cada vez que la función recibe y procesa un mensaje. Esto permite al desarrollador definir exactamente qué se mide (solo el procesamiento del mensaje, excluyendo inicialización y post-procesamiento) y cuándo se publica la métrica, proporcionando datos de rendimiento casi en tiempo real y altamente específicos. Las opciones incorrectas son: Usar la métrica ConcurrentExecutions de Lambda en CloudWatch: Esta métrica muestra cuántas instancias de la función se están ejecutando simultáneamente, no el número de mensajes procesados por intervalo de tiempo. Hacer que la aplicación registre el rendimiento en CloudWatch Logs y usar EventBridge: Aunque se pueden extraer métricas de los logs, este enfoque introduce latencia y complejidad adicional, no es "casi en tiempo real" para la métrica deseada y no es la forma más directa de publicar métricas personalizadas. Usar las métricas Invocations y Duration de Lambda: Invocations cuenta cuántas veces se invoca la función (lo que incluiría inicialización), y Duration mide el tiempo total de ejecución, lo que también incluye inicialización y post-procesamiento. Ninguna de estas métricas proporciona la granularidad necesaria para medir solo el procesamiento del mensaje.