top of page
  • Foto del escritorRan Isenberg

AWS Lambda Cookbook — Parte 2: Prácticas recomendadas de observabilidad


AWS Lambda Cookbook: eleve el código de su controlador (parte 2): capacidad de observación
Fotografía de RODNAE Productions en Pexels

Esta entrada de blog se centra en la observabilidad y analiza los siguientes temas:

  1. Monitoreo de métricas

  2. Rastreo con AWS-Xray.

Utilizaremos Powertools para AWS, CloudWatch y AWS X-Ray.


¿Qué hace que un controlador de AWS Lambda sea resistente, rastreable y fácil de mantener? ¿Cómo se escribe ese código?

En esta serie de blogs, intentaré responder estas preguntas compartiendo mis conocimientos y las mejores prácticas de AWS Lambda, para que no cometa los mismos errores que yo cometí antes.

  • Esta serie de blogs presenta progresivamente las mejores prácticas y utilidades agregando una utilidad a la vez.

  • La parte 1 se centró en el registro.

  • La parte 3 se centró en la observabilidad del dominio empresarial .

  • La parte 4 se centró en las variables de entorno .

  • La parte 5 se centró en la validación de entrada .

  • La parte 6 se centró en la configuración y los indicadores de características.

  • La parte 7 se centró en cómo iniciar su propio servicio sin servidor en dos clics.

  • Parte 8 centrado en las mejores prácticas de AWS CDK .


 

Proporcionaré un proyecto de plantilla de controlador AWS Lambda en Python, funcional y de código abierto.

Este controlador incorpora las mejores prácticas sin servidor y tiene todas las características necesarias para un controlador adecuado y listo para producción.

Cubriré el registro, la observabilidad, la validación de entrada, los indicadores de características, la configuración dinámica y cómo usar variables de entorno de forma segura.

Si bien los ejemplos de código están escritos en Python, los principios son válidos para todos los lenguajes de programación compatibles con las funciones de AWS Lambda.

Puede encontrar todos los ejemplos en este repositorio de GitHub, incluido el código de implementación de CDK.

 

Observabilidad

Libre de usar (CC0)
“En TI y computación en la nube, la observabilidad es la capacidad de medir el estado actual de un sistema en función de los datos que genera, como registros, métricas y seguimientos”, como se describe aquí .

La observabilidad de la función AWS Lambda es necesaria en dos dominios: técnico y comercial. El dominio técnico observa y monitorea métricas de bajo nivel como latencia, duración, tasa de error y uso de memoria. El dominio comercial observa los indicadores clave de rendimiento (KPI) definidos por el equipo de producto.

Este blog trata sobre el seguimiento y el rastreo como parte del ámbito técnico. La parte 1 de la serie abordó el registro y la parte 3 el ámbito empresarial.

 

Métricas de monitoreo

Al monitorear su controlador AWS Lambda, AWS CloudWatch es el servicio de referencia. Recopila métricas de servicio listas para usar de numerosos servicios de AWS, incluido AWS Lambda. Además, proporciona visibilidad a nivel macro del estado actual de sus controladores AWS Lambda y los servicios con los que se integra.

AWS CloudWatch mide las métricas de AWS Lambda en tres categorías: invocación, rendimiento y simultaneidad. Puede ver estas métricas en un panel de AWS CloudWatch y personalizarlo. Puede obtener más información sobre ellas aquí .


¿Qué métricas merecen atención adicional?

Esta lista contiene métricas de las tres categorías. Estas métricas pueden ayudarle a reducir sus tarifas mensuales e incluso a descubrir problemas antes de que se conviertan en una falla de producción.

  1. Tiempo de ejecución de AWS Lambda: intente que la duración sea lo más breve posible. Descubra anomalías y desviaciones de los promedios tan pronto como comiencen a aparecer. Además, sus funciones tienen tiempos de espera predefinidos. Asegúrese de que su controlador no se acerque al límite o podría correr el riesgo de que finalice.

  2. Uso de memoria: no subabastezca la memoria Lambda; controle el uso real de la memoria y deje un umbral suficiente. Tenga en cuenta que aumentar la memoria Lambda puede reducir el tiempo de ejecución total en algunos casos. Consulte aquí .

  3. Tasa de errores (excepciones no controladas, tiempos de espera): este número debería ser cercano a cero en un entorno saludable. Utilice el ID de solicitud o el ID de correlación para depurar los errores (como se mencionó en la primera parte de la serie). Además, preste atención a los cambios en las tasas de errores promedio porque cualquier anomalía aquí podría indicar un servicio fallido.

  4. Métricas relacionadas con la concurrencia de aprovisionamiento, limitación y porcentaje de uso. Estas métricas brindan información sobre el uso real de la concurrencia de aprovisionamiento. Estas métricas pueden evitar un rendimiento inadecuado debido a un aprovisionamiento insuficiente (mucha limitación y alcanzar el límite máximo de concurrencia) o un desperdicio de dinero debido a un aprovisionamiento excesivo y a tener un sistema principalmente inactivo. Siempre debe ajustar y estar atento para optimizar estas configuraciones.

Métricas de AWS CloudWatch
https://towardsdatascience.com/an-overview-of-cloudwatch-metrics-for-aws-lambda-41fc1f0e773
 

Alarmas de AWS CloudWatch

Otro aspecto importante de AWS CloudWatch son las alarmas. Las alarmas monitorean las métricas medidas y se activan cuando se alcanza un umbral predefinido. Las alarmas tienen varios estados: "OK", "ALARMA" y "DATOS INSUFICIENTES".

Debe prestar especial atención a las alarmas en el estado "ALARMA". Este estado significa que la métrica medida está fuera del umbral definido y se requieren más investigaciones o acciones inmediatas para que la métrica vuelva al umbral saludable.

Las alarmas pueden tener acciones. Pueden integrarse con otros servicios de AWS, como AWS SNS y AWS EventBridge. Puede enviar un SMS, un correo electrónico o incluso activar una función de AWS Lambda que cambie la configuración o inicie un proceso de implementación. Estas integraciones significan que puede crear alarmas complejas.

Una acción de alarma típica es una acción que notifica a un ingeniero de soporte de “extinción de incendios” que algo terrible ha sucedido o está a punto de suceder, y que debe tomar la iniciativa y salvar el día.

Regla de oro

  1. Lo mejor sería definir alarmas para su controlador en función de las métricas que mencioné en el blog. Establezca umbrales y límites adecuados. Conozca los límites de tiempo de ejecución aceptados y determine cómo se comporta su servicio en buen estado. Debe ser una combinación de uso anticipado, experiencia mínima aceptable para el cliente y costo.

  2. No se detenga en las métricas de AWS Lambda. AWS CloudWatch monitorea muchos servicios de AWS que se integran con AWS Lambda. Los servicios incluyen AWS SQS, API Gateway, SNS, EventBridge y más. Juntos, cuentan la historia completa de su entorno de producción.

Lea más sobre las alarmas aquí .

 

En general, AWS CloudWatch es un excelente servicio de monitoreo. Tiene muchas utilidades avanzadas, como Lambda Insights, detección de anomalías, etc. Algunas pueden resultarte más útiles que otras. Te recomiendo que investigues y determines qué funciones te brindan más valor, ya que es imposible cubrirlas todas en este blog.

Sin embargo, tenga en cuenta que los servicios de terceros, como DataDog , ofrecen capacidades similares o adicionales y se integran bien con AWS CloudWatch. Investigue lo que ofrecen los competidores. Es posible que satisfagan mejor sus necesidades.

 

Rastreo

AWS CloudWatch monitorea AWS Lambda a nivel macro . Sin embargo, eso no es suficiente. ¿Qué sucede a nivel micro ? ¿Cómo puede adentrarse en las entrañas de su controlador AWS Lambda y detectar cuellos de botella y problemas de rendimiento?

Supongamos que una alarma de AWS CloudWatch que monitorea la duración de su controlador ha pasado al estado "ALARMA". ¿Cómo se depura?

La utilidad de seguimiento AWS X-Ray y AWS Lambda Powertools al rescate.


Rayos X de AWS
Foto de cottonbro en Pexels

Rayos X de AWS

“Con X-Ray, puede comprender cómo se desempeñan su aplicación y sus servicios subyacentes para identificar y solucionar la causa raíz de los problemas y errores de rendimiento. X-Ray proporciona una vista integral de las solicitudes a medida que pasan por su aplicación y muestra un mapa de los componentes subyacentes de su aplicación”. — Documentación de AWS

Visor de línea de tiempo

En mi opinión, la utilidad más útil de AWS X-Ray es el visor de línea de tiempo . Permite ver una única invocación de función de AWS Lambda y analizar su funcionamiento y rendimiento internos. Cada función interna o llamada HTTP se rastrea y se presenta en una tabla fácil de leer.

AWS X-Ray permite buscar rastros de invocaciones individuales de AWS Lambda por nombre de servicio, ID de solicitud y otros parámetros.

¡Encontrar el cuello de botella de tu rendimiento nunca ha sido tan fácil!


Visor de línea de tiempo
Visor de línea de tiempo: https://awslabs.github.io/aws-lambda-powertools-python/latest/core/tracer/

Combinando rastros

Otra característica valiosa de la vista de línea de tiempo es la visualización de los seguimientos conectados en una única vista de línea de tiempo. Si su controlador de AWS Lambda envía una solicitud HTTP a otro controlador de AWS Lambda rastreado, el seguimiento de invocación específico del otro controlador también aparecerá en la misma página. Ambas tablas se presentan en una sola página. ¡Qué práctico!

Esta función es perfecta para optimizar el rendimiento y buscar "milisegundos" para ayudarte a aprovechar al máximo tu código. Facilita el proceso de depuración para identificar la llamada de servicio problemática que aumenta la duración general.

Mapa de servicios

Por último, el Mapa de servicios es otra característica útil. Los rastros no mienten. Los rastros exponen conexiones de servicios que no sabías que existían o que eran difíciles de comprender al mirar el código. El Mapa de servicios visualiza un flujo de solicitudes entre servicios en un gráfico en lugar de una tabla, como el visor de la línea de tiempo.

Ver información más detallada aquí .


Mapa de servicios de AWS CloudWatch
Mapa de servicios de AWS CloudWatch

Bueno, ¿dónde me inscribo?

Hagamos que nuestro controlador de AWS Lambda sea rastreable en AWS X-Ray y AWS CloudWatch Service Map. Podemos lograrlo agregando la utilidad de rastreo de AWS Powertools. AWS Lambda Powertools proporciona una envoltura delgada del SDK de AWS X-Ray mediante el uso de decoradores. Para comenzar a usar AWS X-Ray, debe hacer dos cosas:

  1. Define un objeto rastreador global y decora el controlador y cualquier función interna.

  2. Otorgue permisos a la función AWS Lambda para enviar datos a AWS X-Ray como se describe aquí .

 

Agreguemos la utilidad de seguimiento al código del controlador de AWS Lambda presentado en el primer blog . El controlador tenía la funcionalidad de registrador. Las instancias de clases globales de AWS Lambda Powertools (registrador y seguimiento) se definirán en el archivo “ utils/infra.py” . Estas instancias globales se definen en una carpeta de utilidad compartida para que puedan ser reutilizadas por todas las capas y archivos de servicio en AWS Lambda. También pueden ser compartidas por varios controladores cuando su servicio se expande y se agregan nuevos controladores a la carpeta “ handlers” .


En la línea 10, creamos una instancia de rastreador global con un nombre de servicio exacto.

El controlador reside en la carpeta “ handlers” en un archivo llamado “ my_handler.py”:

En la línea 6, importamos el trazador desde la carpeta de utilidades.

En la línea 14, decoramos el controlador, de modo que los rastros se capturen en toda la invocación del controlador y se envíen a AWS X-Ray al final. Según mi experiencia, es mejor establecer “capture_response” en Falso si su controlador podría devolver datos con información de identificación personal ( PII) u objetos de respuesta grandes. Haga clic aquí para obtener más detalles.

En la línea 9, agregamos el seguimiento de la función interna “inner_function_example”. Esto hace que la función interna sea rastreable y expone su tiempo de ejecución específico en AWS X-Ray. Debe usar este decorador para rastrear cualquier función no trivial que pueda tener problemas de rendimiento: si envía una solicitud HTTP a un servicio externo, usa AWS SDK o realiza cálculos complejos, decórela.

Puede encontrar todos los ejemplos de código en este repositorio de GitHub.


Una última cosa: Anotaciones de Tracer

Puede definir anotaciones personalizadas para ayudarlo a encontrar rastros de forma más rápida y sencilla en AWS X-Ray. Por ejemplo, puede buscar rastros por ID de cliente. Puede obtener más información al respecto aquí .

Sin embargo, si bien este mecanismo es excelente para facilitar la búsqueda de rastros, no reemplaza al registrador. No agregue demasiados metadatos a través del mecanismo de anotación; regístrelos.

 


Regla de oro

  1. Reducir los costos de rastreo. Los costos de rastreo de AWS X-Ray pueden acumularse. Las alarmas y los monitores de AWS CloudWatch le permitirán saber si el rendimiento de su controlador de AWS Lambda se está degradando. Le sugiero que deshabilite el rastreador de forma predeterminada y solo lo habilite (a través de una variable de entorno o explícitamente) mientras realiza pruebas comparativas o mientras intenta depurar un problema de rendimiento que NO se puede resolver examinando los registros.

  2. Realice evaluaciones comparativas de rendimiento tanto como sea posible, teniendo en cuenta las implicaciones de costos.

  3. Mejorar el tiempo de ejecución y la latencia no es algo trivial. Si bien este tema merece una publicación de blog aparte, aquí se ofrecen algunos consejos rápidos para mejorar ambos parámetros: habilitar la concurrencia aprovisionada (eliminar los arranques en frío), aumentar el tamaño de la memoria y ejecutar AWS Lambdas en procesadores Graviton. Haga clic aquí para obtener más detalles.

  4. Es fundamental tener en cuenta que el uso de la utilidad de seguimiento de AWS Powertools no lo limita a usar solo AWS X-Ray. Muchas soluciones de seguimiento de terceros ofrecen integración con AWS X-Ray (consulte la documentación de DataDog). Investigue, encuentre la herramienta que funcione mejor para usted y le brinde la mejor experiencia de observación general.

Próximamente

Con esto concluye la segunda parte de la serie. Acompáñenme en la siguiente parte, donde implemento métricas de dominio empresarial.


Un agradecimiento especial a:



Comentarios


bottom of page