En esta serie de dos publicaciones, aprenderá a monitorear servicios sin servidor con CloudWatch mediante la creación de paneles, widgets y alarmas con AWS CDK.
En esta publicación, la segunda parte de la serie, utilizaremos AWS CDK para monitorear un servicio sin servidor de muestra con paneles de CloudWatch de acuerdo con los principios presentados en la primera publicación de la serie.
En la primera publicación , aprenderá qué significa monitorear un servicio sin servidor, por qué es esencial y cómo crear paneles de CloudWatch para monitorear su servicio sin servidor con widgets. Los widgets muestran información de registros de CloudWatch, métricas, métricas personalizadas y definen alarmas de CloudWatch como parte de un enfoque proactivo.
Tabla de contenido
Introducción
El uso de los paneles de AWS CloudWatch permite la supervisión centralizada de API Gateway, funciones Lambda y DynamoDB, lo que proporciona información en tiempo real sobre su rendimiento y estado operativo. Al agregar métricas, registros y alarmas, CloudWatch facilita el diagnóstico y análisis rápidos de problemas en todas sus aplicaciones sin servidor. Además, la configuración de alarmas garantiza una reacción inmediata ante actividades anómalas.
En esta publicación, escribiremos código CDK que crea paneles de CloudWatch que monitorean registros y métricas y crean alarmas para un servicio sin servidor de muestra.
Construiremos un panel que monitoree un servicio sin servidor de muestra: el servicio "pedidos".
Estos son los recursos que construiremos con AWS CDK.
Ejemplo de arquitectura de servicio sin servidor
El servicio 'pedidos' permite a los usuarios realizar pedidos de productos.
Construyamos un tablero de monitoreo para este servicio que implemente los conceptos introducidos en la primera parte de la serie .
Nuestro objetivo es supervisar la puerta de enlace de API de servicio, la función Lambda y las tablas de DynamoDB y asegurarnos de que todo esté en orden. Además, queremos visualizar las métricas de KPI de servicio.
Crearemos dos paneles de CloudWatch, un resumen de alto nivel y un resumen de bajo nivel, cada uno de los cuales servirá a una persona diferente. Los paneles mostrarán widgets de registros de CloudWatch (registros de errores para nuestras funciones Lambda) y métricas de CloudWatch de varios recursos.
Además, definiremos alarmas de CloudWatch para notificarnos sobre errores y degradaciones críticas del rendimiento.
Si desea comprender el razonamiento detrás de este enfoque y por qué el monitoreo es esencial, lea la primera parte de esta serie.
Puedes encontrar el código y el código de servicio aquí .
* El código es parte de mi proyecto de plantilla de libro de cocina AWS Lambda Handler.
Este repositorio proporciona una plantilla de servicio sin servidor, de código abierto, que funciona y se puede implementar con una función AWS Lambda y código Python de AWS CDK con todas las mejores prácticas y un flujo de trabajo de CI/CD completo. ¡Puede iniciar un servicio sin servidor en 3 clics!
Código CDK
Utilizaremos una biblioteca de código abierto: cdk-monitoring-constructs .
La biblioteca admite varios lenguajes de programación: Python, TypeScript, Java y C#.
La biblioteca proporciona "construcciones CDK fáciles de usar para monitorear su infraestructura de AWS con Amazon CloudWatch ". Abstrae la creación de widgets de CW y la simplifica con soporte listo para usar para muchos servicios de AWS, como API Gateway, Lambda, DynamoDB y más.
La biblioteca utiliza el concepto de clases de fábrica. Tiene clases de fábrica para crear un widget basado en un grupo de registros o en métricas de CW para una gran cantidad de servicios de AWS de uso común. También puede crear alarmas de CW con facilidad y monitorear métricas de CW personalizadas (KPI). Puede usar sus clases de fábrica para definir colores personalizados, tamaños de fuente, tamaños, configuraciones de alarma predeterminadas y más.
Utilizaremos la biblioteca para monitorear los recursos del servicio 'pedidos': función Lambda, Api Gateway y DynamoDB con facilidad.
A continuación se muestra una construcción de CDK L3 que crea todos los recursos de monitoreo. Repasemos lo que crea y profundicemos en cada sección.
Revisaremos tres funciones diferentes que construyen todos los recursos.
'_build_topic' - crea el tema SNS al que las alarmas enviarán detalles de alarma cuando se activen.
'_build_high_level_dashboard' - construye el tablero de alto nivel.
'_build_low_level_dashboard' - construye el tablero de bajo nivel.
Como entrada, recibimos el recurso API Gateway, dos tablas de DynamoDB y una lista de funciones Lambda para monitorear.
Repasemos cada una de las funciones en las líneas 14 a 16.
Tema de Alarmas
Las alarmas de CloudWatch son inútiles a menos que tengan una acción una vez que se activan. Hemos configurado las alarmas para enviar una notificación de SNS a un nuevo tema de SNS. Desde allí, puede usar cualquier suscripción (HTTPS/SMS/correo electrónico, etc.) para notificar a sus equipos sobre la alarma.
En las líneas 24 a 29, definimos la clave KMS que se utilizará para cifrar los mensajes SNS en reposo .
En las líneas 30-34, definimos el tema y utilizamos la clave que describimos anteriormente.
En las líneas 37 a 44, establecemos una política de permisos y permitimos que CloudWatch publique mensajes en el tema. Esto ocurrirá una vez que se active una alarma; CW enviará un mensaje de SNS que describa la alarma.
Ahora que tenemos el tema SNS, podemos pasarlo a las siguientes funciones utilizadas al crear alarmas CW.
Panel de control de alto nivel
Este panel está diseñado para ser una descripción general ejecutiva del servicio.
Las métricas totales de API Gateway brindan información sobre el rendimiento y la tasa de errores del servicio. También incluye una alarma sobre la tasa de errores de API Gateway.
Las métricas KPI también se incluyen en la parte inferior.
Personas que utilizan este panel: SRE, desarrolladores y equipos de productos (KPI).
Repasemos la función '_build_high_level_dashboard' que genera este tablero:
En las líneas 26 a 34, construimos la fachada del panel de control. Representa un panel de control en CW. Esta clase contiene todos los widgets que creamos y tiene varias funciones de fábrica que crean widgets y alarmas.
Puede anular su configuración predeterminada y establecer la fábrica predeterminada para alarmas, widgets y métricas con su configuración personalizada.
En las líneas 29-32, creamos una fábrica de alarmas y la configuramos para que todas las alarmas producidas por la fachada tengan una acción para enviar al tema SNS que definimos previamente una vez que se activen.
En la línea 35, agregamos un encabezado al tablero.
En las líneas 36 a 39, agregamos varios widgets que monitorean nuestra API Gateway: los cuatro widgets principales. Se proporcionan de manera predeterminada como parte de la biblioteca. En la línea 38, agregamos una alarma para un umbral de error para la API Gateway (HTPP 4XX o 5XX). La alarma utilizará la acción SNS predeterminada definida en las líneas anteriores.
En las líneas 40 a 51, creamos los widgets inferiores que monitorean la métrica personalizada de CloudWatch bajo el espacio de nombres 'orders_kpi' llamado 'ValidCreateOrderEvents'. Podemos agregar múltiples métricas a un grupo de widgets (línea 50), pero en el servicio 'orders', solo tenemos una.
Panel de control de bajo nivel
El objetivo es profundizar en todos los recursos del servicio. Requiere una comprensión de la arquitectura del servicio y sus partes móviles.
El panel proporciona las métricas de la función Lambda en cuanto a latencia, errores, limitaciones, simultaneidad aprovisionada e invocaciones totales.
Además, un widget de registros de CloudWatch muestra solo registros de "error" de la función Lambda.
En cuanto a las tablas de DynamoDB, tenemos la base de datos principal y la tabla de idempotencia para uso, latencia de operación, errores y limitaciones.
Personas que utilizan este panel: desarrolladores, SRE.
Repasemos el código CDK que crea estos widgets:
En las líneas 36 a 44, construimos la fachada del panel de control. Representa un panel de control en CW. Esta clase contiene todos los widgets que creamos y tiene múltiples funciones de fábrica que crean widgets y alarmas.
En las líneas 39-42, creamos una fábrica de alarmas y la configuramos para que todas las alarmas producidas por la fachada tengan una acción para enviar al tema SNS que definimos previamente una vez que se activen.
En la línea 45, agregamos un encabezado al tablero.
En las líneas 46 a 56, construimos las dos filas superiores del panel. Dos por función Lambda; en este caso, solo tenemos una función. Usamos la creación de widgets incorporada para la función Lambda para monitorear todos los aspectos cruciales de la función. En las líneas 47 a 49, definimos una alarma que monitorea la duración p90 de la función. Si desea obtener más información sobre las métricas de percentil, consulte mi primera publicación .
En las líneas 51 a 56, definimos un widget que muestra registros del grupo de registros de funciones Lambda, pero solo registros de ERROR.
En las líneas 58 y 59, utilizamos el soporte del widget DynamoDB integrado de la biblioteca para monitorear la base de datos principal y la tabla de idempotencia que tenemos.
Fragmento completo del CDK
Aquí está todo el código junto:
Puede encontrar el código de servicio actualizado aquí .