Esta publicación es la primera de la serie y se centra en las mejores prácticas de registro para funciones Lambda mediante AWS CloudWatch y Powertools para AWS.
¿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.
Proporcionaré un proyecto de plantilla de controlador AWS Lambda en Python, funcional y de código abierto.
Puede encontrar todos los ejemplos en este repositorio de GitHub, incluido el código de implementación de CDK.
Este controlador incorpora las mejores prácticas de Serverless y tiene todas las funciones necesarias para que un controlador esté listo para producción. Trataré cuestiones como el registro, el seguimiento, la validación de entradas, los indicadores de funciones, la configuración dinámica y cómo usar las variables de entorno de forma segura.
Si bien los ejemplos de código están escritos en Python, los principios son válidos para cualquier lenguaje de programación de controlador AWS Lambda compatible.
La mayoría de los ejemplos de código que aparecen aquí provienen del excelente repositorio AWS Lambda Powertools . He escrito varias de las utilidades mencionadas en esta serie de blogs y doné dos de ellas, elanalizador y los indicadores de características , a AWS Lambda Powertools.
Esta serie de blogs presenta progresivamente las mejores prácticas y utilidades agregando una utilidad a la vez.
La segunda parte se centró en la observabilidad: seguimiento y rastreo.
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 .
El punto de partida
Un controlador Lambda my_handler recibe una entrada de un evento de diccionario y un objeto de contexto Lambda. Devuelve una respuesta JSON. A continuación se muestra el controlador Lambda básico de AWS que se ve en muchos ejemplos de código de AWS.
El leñador
La primera utilidad puede ser la más sencilla de todas. Por lo general, el primer instinto es utilizar la función de impresión incorporada de Python como solución de registro. Sin embargo, no debería hacerlo. Python tiene una biblioteca de registro incorporada. Una clase de registrador proporciona una API simple que agrega visibilidad y depura información a su servicio AWS Lambda.
Dicho esto, te recomiendo encarecidamente que utilices la implementación del registrador de AWS Lambda Powertools . Es un contenedor de la biblioteca de registro de Python que proporciona capacidades adicionales, como la configuración de salida JSON (y muchas más).
¿Por qué es importante el formato de salida JSON?
De forma predeterminada, todos los registros de AWS Lambda se envían a AWS CloudWatch (siempre que proporcione a su AWS Lambda los permisos necesarios). Almacenar los registros en un solo lugar es excelente. Sin embargo, una depuración eficiente requiere capacidades de búsqueda de texto libre.
Los servicios de AWS, como AWS CloudWatch Logs Insights, indexan sus registros y ofrecen una búsqueda de texto libre sencilla. Los servicios de terceros pueden hacer eso; DataDog y Logz.io son algunos de ellos. Estos servicios facilitan la experiencia de depuración y lo ayudan a encontrar los problemas más rápido.
Sin embargo, puedes aprovechar todo el poder de estos motores de búsqueda solo cuando utilizas documentos estructurados JSON (en lugar de cadenas de una sola línea).
Revisemos el siguiente ejemplo, donde el mismo mensaje de registro está escrito en formato de cadena y JSON.
Los documentos basados en JSON le permiten mantener los datos de una manera más estructurada y organizada, buscar elementos de la jerarquía interna ( event_list[0] o user_data.company ) y tener tipos de datos que no sean cadenas ( int, bool, dict, list ). Esto, a su vez, le permite crear paneles y métricas calculadas que brindan mejor visibilidad e información sobre el estado actual de su controlador de AWS Lambda.
Poniéndolo todo junto
El siguiente ejemplo demuestra cómo utilizar el registrador AWS Lambda Powertools:
En la línea 8, creamos el registrador.
En la línea 12, establecemos el AWS request_id como el Identificación de correlación , que se agregará automáticamente a cualquier registro posterior a partir de ese punto. La identificación de correlación le permite encontrar todos los registros correspondientes a una sola solicitud en varios servicios y ejecuciones, siempre que los servicios a lo largo del camino la registren y la pasen de la misma manera. Facilita enormemente el proceso de depuración para una sola solicitud.
ID de solicitud de AWS es un identificador único que le permitirá identificar una ejecución de lambda específica entre las muchas ejecuciones de su AWS Lambda. AWS CloudWatch escribirá todos los registros de las ejecuciones en el mismo grupo de registros de AWS Cloudwatch, por lo que es necesario tener un identificador único. Puede leer más sobre esto aquí .
La línea 13 imprime un registro JSON con un nivel de depuración y el campo de mensaje es igual a " se llama a mi controlador ".
Regla de oro
No, repito, NO registres el contenido del parámetro de evento ni ninguna otra entrada que reciba tu AWS Lambda en su totalidad. Podrías estar registrando PII (Información de identificación personal) (número de identificación, número de teléfono, etc.). Podrías estar infringiendo regulaciones como el RGPD sin siquiera saberlo. Por eso es fundamental registrar solo los parámetros en los que confíes y que no tengan datos de PII o eliminarlos de PII antes de registrarlos. Puedes leer más sobre esto aquí .
Mantenga estático el mensaje de registro. Este es el mensaje que probablemente buscará. Cuando agrega valores dinámicos (valores de variables) al mensaje de registro, se vuelve imposible saber qué buscar en AWS Cloudwatch Logs Insights. Registre los valores de las variables en la sección adicional del registrador. En este ejemplo, “Recolectando pago” es una declaración genérica, mientras que los datos dinámicos se imprimen en el campo de diccionario adicional. Vea más ejemplos aquí .
Registre el inicio y el final de cualquier función. Cuantos más registros tenga, más fácil será comprender la causa raíz de un error.
Registre un error cada vez que se detecte una excepción. Agregue tantos detalles como sea posible sin exponer información de identificación personal.
Sea específico con el mensaje de registro. Debe poder comprender el mensaje y el contexto por sí solo sin tener que leer otros 20 registros antes de ese registro.
Asegúrese de utilizar siempre las mismas claves en la sección adicional del registrador para facilitar la búsqueda (elija “id” o “ID” y sea coherente).
Refactorizar . Si encuentra un problema que no puede comprender con solo mirar los registros, refactorice. Agregue registros o haga que los registros actuales sean más significativos. Los registros son invaluables para la preparación de la producción. Haga que cada registro cuente; de lo contrario, dedicará más tiempo a depurar y, aún más, a refactorizar los registros nuevamente.
No exageres.
Próximamente
Con esto concluye la primera parte de la serie. Acompáñenme en la siguiente parte , donde abordaré el seguimiento de AWS Lambda.
Un agradecimiento especial a:
Koby Aharon
Yaara Gradovitch
y Mauro Rois.