Las métricas personalizadas de CloudWatch, que suelen utilizarse como indicadores clave de rendimiento (KPI), tienen aplicaciones versátiles que van más allá de su uso convencional. Powertools for AWS Lambda simplifica el proceso de redacción de estas métricas y permite casos de uso innovadores.
Este artículo le guiará a través de la personalización de la observabilidad mediante la integración de métricas de CloudWatch en las notificaciones push móviles, una estrategia que mejora significativamente la interacción con las aplicaciones móviles. Si es un ingeniero de datos que busca instrumentar una canalización de ingesta o un desarrollador de aplicaciones que busca entregar notificaciones de métricas específicas para el usuario, esta publicación le ofrece información valiosa adaptada a sus necesidades.
Introducción del autor invitado
Esta publicación fue escrita por Nathan Hanks, director ejecutivo de Protiviti en el área de Tecnologías emergentes. Nathan ha estado involucrado en el desarrollo de software durante más de 25 años, abarcando TI corporativa como empresario y consultor.
Puedes contactar a Nathan en LinkedIn .
Tabla de contenido
Antecedentes - El SmartHunter
Antes de analizar las métricas de CloudWatch, permítanme brindarles algo de contexto sobre cómo llegué a utilizar las métricas de CloudWatch. En resumen, escribí una aplicación móvil, The SmartHunter, que utiliza IA para ayudar a los cazadores a ser lo más competentes posible cuando deciden salir de cacería. Para esta aplicación, los usuarios cargan imágenes desde sus distintas cámaras de caza y el servicio de backend en la nube utiliza IA para ayudarlos a comprender dónde y cuándo deben planificar sus expediciones. Entonces, cuando los usuarios cargan estas imágenes (generalmente varios miles a la vez), una canalización de ingesta (compuesta por una serie de funciones lambda) procesa esas imágenes. Además del procesamiento central de estas imágenes, quería brindar observabilidad a los usuarios de la aplicación, brindándoles información sobre cuántas imágenes se procesaron y qué información se obtuvo de las imágenes. A continuación se muestra la aplicación, que muestra la capacidad de revisar las imágenes.
Soy un ávido usuario de Powertools para AWS Lambda y estoy usando métricas para mis propósitos: observar el sistema y recibir alertas sobre cómo se están ejecutando los procesos del sistema. (Si no estás familiarizado con Powertools, es esencialmente un conjunto sorprendente de herramientas que encapsula las mejores prácticas y patrones para crear aplicaciones basadas en Lambda). Sin embargo, no quería proporcionar ni exponer un panel de CloudWatch a los usuarios de mi aplicación. Pero sí quería encontrar una forma de exponer esas métricas, y creo que las notificaciones push ayudan a impulsar la interacción con tu aplicación. Así que me propuse descubrir cómo podía utilizar estas métricas y exponerlas a mis usuarios a través de la aplicación móvil.
Métricas de AWS CloudWatch al rescate
Si no conoce CloudWatch Metrics, consulte esta excelente serie de blogs sobre observabilidad y métricas. Aquí hay tres métricas clave para mi aplicación que les importan a los usuarios cuando cargan imágenes:
¿Cuántas imágenes se han subido?
¿Cuántos fueron procesados exitosamente?
¿Qué especies se identificaron en esas imágenes?
Como desarrollador, es posible que me interesen esos números en conjunto para saber cómo funciona el sistema. Sin embargo, a un usuario individual solo le interesan las métricas sobre sus imágenes. Ahí es donde entra en juego una dimensión. Una dimensión es simplemente metadatos adjuntos a una métrica que le permiten "dividirla en partes". En mi caso de uso, asigno una dimensión de "ID de rancho" a cada métrica; esto es simplemente un identificador para indicar que esta métrica se aplica al rancho de esta persona (una ubicación en un mapa). Como se mencionó anteriormente, Powertools hace que esto sea muy fácil; a continuación, se incluye un fragmento de código de una de mis funciones Lambda:
La clave aquí es la dimensión, línea 12. Como verás más adelante, esto me permite consultar métricas etiquetadas con esa dimensión, lo que proporciona la personalización a nivel de usuario. En este caso, estoy creando una métrica llamada "ImageIngested", que es la cantidad total de imágenes ingeridas para esa operación para ese usuario (como lo indica la dimensión).
Y, por último, la línea 13 es la que crea la métrica y la escribe en CloudWatch. En este caso, la unidad de la métrica es "Count", pero tenga en cuenta que MetricUnit es una enumeración y puede incluir unidades como "segundos". Powertools hace que esta línea de código sea mucho más sencilla, más legible y, en última instancia, más fácil de mantener que si utilizara boto3 .
Descripción general de alto nivel de la solución
Ahora que hemos creado las métricas, revisemos el proceso que impulsa la creación de métricas y cómo se entregan esas métricas a los usuarios. A continuación, se muestra una arquitectura de alto nivel que muestra cómo se crean las métricas y cómo se conservan. Flujos de métricas de CloudWatch y luego se consultan en otro momento para enviar notificaciones push a los usuarios.
Vamos a desglosarlo:
Paso 1: La “función Ingest” agrega la métrica mediante Powertools. Y como se describió anteriormente, cada métrica se contextualiza para el usuario al agregarle una dimensión que es específica para ese usuario/inquilino, específicamente su identificador de rancho (ranchid). A continuación, se muestra la notificación push que muestra dos métricas, la cantidad de imágenes cargadas y cuántas eran imágenes válidas.
Paso 2: CloudWatch tiene un servicio, CloudWatch Metric Stream , que puede enviar métricas a varios destinos, uno de los cuales es Kinesis Firehose.
Paso 3: Kinesis Firehose entrega los datos métricos a S3.
Paso 4: Se puede configurar un rastreador de Glue para indexar y catalogar los datos de métricas (ahora en S3) como una tabla en el catálogo de Glue. Esto le permite consultar estos datos desde una función lambda utilizando Athena. En efecto, me gusta pensar en esto como un "lago de métricas", porque tengo todas mis métricas disponibles como tablas en una base de datos de Glue y puedo realizar consultas con SQL. Esto permite casos de uso en los que puedo volver atrás y observar la actividad de un cliente a lo largo del tiempo, lo que podría usarse para realizar más campañas de Amazon Pinpoint .
Paso 5: Una vez que se completa el proceso de ingesta nocturna, se ejecuta otra función lambda que consulta la tabla Glue mediante Athena. Esta consulta recupera las métricas más recientes (las últimas 24 horas) y las divide por dimensión (ranchid). Esto ahora devuelve un conjunto de resultados de métricas por dimensión, que se puede utilizar para enviar las métricas a cada usuario.
Paso 6: Después de la consulta de Athena, la función “Consulta” envía las notificaciones push a través de Pinpoint. La notificación push es un “enlace profundo” que los lleva a la sección correspondiente de la aplicación donde pueden revisar las imágenes que cargaron y la calidad del modelo de reconocimiento de imágenes.
Retrospectiva: ¿Valió la pena enviar métricas a los usuarios de esta manera?
Probablemente valga la pena analizar por qué elegí utilizar las métricas de CloudWatch de esta manera y cuáles son, en mi opinión, las ventajas y desventajas de dicha implementación. Como dije anteriormente, quería generar interacción con mi aplicación y todos saben que las notificaciones push son una gran herramienta para lograrlo. A continuación, quería brindarles a los usuarios la capacidad de observar estos procesos que son fundamentales para que tengan éxito con la aplicación. CloudWatch Metrics y la implementación de flujos de métricas me parecieron intuitivas porque capturarían todas las estadísticas sobre cuándo ocurrió el evento, como parte del proceso de creación de la métrica. También me gustó que las métricas se conservarían para que yo pudiera hacer un análisis más sofisticado en una fecha posterior, según fuera necesario.
Las desventajas del enfoque elegido son que ahora tengo que asumir otros costos, a saber, los costos de Glue Crawler, Lambda y Pinpoint, además de los costos de CloudWatch Metric en los que ya estoy incurriendo. Sin embargo, al final, el valor de tener notificaciones push y la posible mayor interacción con el cliente superan las desventajas.
Resumen
Con suerte, esta publicación demuestra cómo se puede mejorar la interacción con la aplicación a través de las métricas de CloudWatch. Esto permite enviar métricas a los clientes/usuarios y, de ese modo, impulsar la interacción con la plataforma al brindarles información detallada sobre los procesos en los que cargan miles de imágenes en la aplicación. Con suerte, esta publicación también muestra lo fácil que es usar métricas al usar Powertools. Aprovecho cada oportunidad que tengo para contarles a las personas lo increíble que es Powertools.
Comments