Esta publicación se centra en la observabilidad, pero esta vez desde la perspectiva del dominio empresarial: métricas e indicadores clave de rendimiento empresariales. Usaremos métricas personalizadas de AWS CloudWatch.
¿Qué hace que un controlador de AWS Lambda sea resistente, rastreable y fácil de mantener? ¿Cómo se escribe un código de este tipo?
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 centra en el registro.
La Parte 2 se centra en la observabilidad : seguimiento y rastreo.
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.
Durante esta serie de blogs, 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.
¿Por qué debería importarle las métricas y los KPI?
“Las organizaciones pueden combinar el contexto empresarial con el análisis y el rendimiento de aplicaciones de pila completa para comprender el impacto empresarial en tiempo real, mejorar la optimización de la conversión, garantizar que las versiones de software cumplan con los objetivos comerciales esperados y confirmar que la organización cumple con los SLA internos y externos”. — como se describe aquí .
Las métricas comerciales, como se mencionó anteriormente, pueden impulsar su negocio hacia el éxito.
Las métricas constan de una clave y un valor. Un valor puede ser un número, un porcentaje, una tasa o cualquier otra unidad. Las métricas típicas son la cantidad de sesiones, usuarios, tasa de error, cantidad de vistas, etc.
Los KPI, indicadores clave de rendimiento, son métricas "especiales" que, en teoría, pueden predecir el éxito de su servicio. Los KPI están diseñados estratégicamente para respaldar el caso de uso comercial. Requieren un conocimiento profundo de su negocio y de sus usuarios y, como tal, requieren una definición cuidadosa. Los KPI sirven como un medio para predecir el futuro del negocio.
Si no logra cumplir con los KPI bien definidos, su servicio fracasará. Si logra cumplir con los KPI, su servicio tendrá más posibilidades de tener éxito.
Los distintos servicios definen distintas métricas como KPI. Un blog puede definir KPI como visitantes recurrentes, cantidad de suscriptores y tasa de rebote. Estas métricas indican si el blog está ganando terreno y generando suscriptores de manera constante.
También son útiles otras métricas que no son KPI. Se trata de métricas que muestran el pasado y el presente. Por ejemplo, las métricas de uso pueden hacer que te des cuenta de que has dedicado mucho tiempo a una función que a la mayoría de los usuarios no les interesa. Pueden ayudarte a centrarte en lo que importa y eso, a su vez, mejora los KPI y las posibilidades de éxito de tu servicio.
Ahora que tenemos una comprensión clara de por qué necesitamos métricas de dominio empresarial, analicemos el cómo.
Implementación
Al igual que con otras métricas integradas de AWS, queremos monitorearlas en AWS CloudWatch.
Queremos poder crear alarmas y mostrar los valores en paneles.
Supongamos que nuestro controlador de ejemplo, 'my_handler', está generando el KPI: ' cantidad de eventos válidos '. Incrementa la métrica en 1 por cada evento que pasa la validación de entrada. Dado que el controlador de ejemplo actual aún no tiene validación de entrada (se agregará en la parte 5 de la serie), todos los eventos de entrada siempre se consideran válidos y se cuentan según esta métrica.
Las métricas personalizadas se comportan como cualquier otra métrica integrada en los servicios de AWS CloudWatch.
Solo queda agregar el código que envía la métrica y definir los permisos de rol adecuados. Los permisos requeridos son 'cloudwatch: PutMetricData' , que se deben agregar a su rol de función de AWS Lambda.
En cuanto al código, AWS Lambda Powertools tiene una utilidad que hace exactamente eso: la utilidad Metrics .
Antes de profundizar en el ejemplo de código, repasemos algunos términos de métricas de AWS CloudWatch.
Un espacio de nombres contiene al menos una dimensión. Una dimensión consta de una clave y un valor y contiene una o más métricas. Las métricas tienen una clave, un tipo de unidad y un valor.
Hay varios tipos de unidades: conteo, tasa, porcentaje, segundos, bytes, etc.
Espacio de nombres ---> [ Dimensiones (clave, valor) ] ---> [ Métricas (clave, valor del tipo de unidad) ]
La siguiente imagen representa la jerarquía de métricas que deseamos definir:
El espacio de nombres ' my_product_kpi' contiene una dimensión con una clave de 'service' y un valor de 'my_service'. Esta dimensión contiene una métrica con una clave ' ValidEvents' de tipo de unidad numérica.
Poniéndolo todo junto
Antes de sumergirnos de lleno en el código, me gustaría señalar que una regla general es agregar métricas de KPI de negocios más adelante durante el desarrollo del servicio. Los requisitos y los KPI serán más evidentes a medida que se acerque la meta.
Agreguemos la utilidad de las métricas a las utilidades de registrador y trazador ya implementadas en los blogs anteriores.
Puede encontrar todos los ejemplos de código en este repositorio de GitHub.
En la línea 14, creamos una instancia global de la utilidad Métricas. El espacio de nombres se define como ' my_product_kpi '.
Y finalmente, la versión completa de ' my_handler.py' :
En la línea 8, importamos la utilidad de métricas globales. En la línea 16, agregamos un decorador de métricas, ' log_metrics '. Este decorador valida nuestras métricas generadas. Cada métrica tiene una unidad de métrica que define un tipo y un valor, y deben coincidir (los tipos de unidad numérica coinciden con un valor numérico, etc.). El decorador también serializa y envía las métricas a AWS CloudWatch al final de cada invocación. En la línea 23, agregamos la métrica ' ValidEvents ' y un recuento de 1 porque el controlador obtuvo un evento válido. ¡Eso es todo! El controlador ahora tiene capacidades integradas de registro, seguimiento y métricas, y ahora puede monitorear los KPI comerciales.
Próximamente
Con esto concluye la tercera parte de la serie. Acompáñenme en la siguiente parte, donde analizo y valido las variables del entorno de AWS Lambda.
Un agradecimiento especial a:
Ben Heymink
Comments