Herramientas para una mejor Observabilidad en Aplicaciones IoT Serverless de NodeJS

Muy bien, así que todos los que comienzan en el espacio de IoT piensan que así es como se ve el viaje de IoT. Sabes, todo es sol y mariposas, y trabajas con dispositivos y son muy geniales. Prototipas con dispositivos. Aprendes nuevos protocolos y así sucesivamente, por lo que piensas que se ve así.

Pero en realidad, no se ve así. Cuando pasas a producción con una solución de IoT, se parece más a esto. Así que constantemente estás apagando incendios de una forma u otra. Entonces, ¿qué está pasando realmente? Cuando trabajas en IoT, en realidad eres parte de un ecosistema. Estás trabajando en el lado del dispositivo, o estás trabajando con equipos que trabajan en el lado del dispositivo. Tienes backend en el lado de la nube. Estás trabajando con equipos de la nube. Estás trabajando con equipos de datos. Así que todo es realmente relativamente loco, y puede volverse aún más loco muy rápido. Así que es un laberinto.

De repente estás haciendo prototipos o pruebas con tus dispositivos en el laboratorio, y todo funciona, y todo está bien, todos están felices. Y luego pasas a producción, y de repente el 50% de tu flota está sin conexión de un día para otro. Y tratas de investigar por qué, y no sabes por qué. Luego tienes datos faltantes. Estás enviando datos. Estás usando MQTT. Has hecho todas las cosas correctas. Idealmente, has utilizado calidad de servicio uno. Idealmente, también has utilizado almacenamiento local en el borde, pero aún así los datos han desaparecido. Así que tu equipo de datos se queja. No sabes dónde está el problema. ¿Qué pasa con las alertas que construiste? Bueno, no estás viendo ninguna de ellas. ¿Las has construido realmente? Bueno, no lo sé. Sería una buena idea si lo hicieras. Los datos son inconsistentes. Tus usuarios básicamente se quejan de que cargar un panel de control para, no sé, 50 dispositivos como un agregado, para ver métricas agregadas, simplemente lleva demasiado tiempo.

Así que todo es una locura. Entonces, ¿qué haces con todo esto? Claramente, necesitas construir observabilidad en tu aplicación. Necesitas métricas. Necesitas registro. Necesitas trazado. Y, idealmente, necesitas todo esto de una manera estandarizada, para que un equipo de operaciones que realmente esté revisando estas cosas, revisando estos datos, pueda entender lo que está sucediendo. Así que veamos cómo podemos construir observabilidad en una aplicación de IoT.

Voy a asumir que el backend aquí es principalmente sin servidor. Así que me imagino una situación en la que tienes un dispositivo IoT que envía algunos datos a través de MQTT y tienes una regla de IoT, ya sabes, una regla de AWS IoT, que recoge estos datos y los envía a una función Lambda. Estás utilizando esta increíble y genial integración que AWS IoT tiene con el motor de reglas. Y piensas que todo es perfecto, ¿verdad? Si escaneas ese código QR, puedes ver el código de lo que voy a mostrarte. Puedes hacer eso. También lo tengo enlazado al final. Así que daré, como, dos segundos para que la gente lo vea.

Muy bien, lo que voy a mostrarte ahora es algo que quizás no esperes sobre la integración entre el motor de reglas y Lambda. Entonces, la función Lambda, omitamos esto por ahora. La función Lambda que estoy utilizando se ve un poco así, ¿verdad? Así que estás configurando, tienes una biblioteca de trazado. Te mostraré qué es la biblioteca de trazado y hablaré de ella más adelante. Pero en realidad, tu función Lambda simplemente hace algo y lanza una excepción, ¿verdad? Y eso es básicamente todo. Y si miras esto, ya sabes, si miras esta architecture aquí, esperarías ver la excepción de inmediato.

Bueno, lo curioso es que la forma en que el motor de reglas se integra con Lambda es de forma asíncrona, ¿verdad? Entonces, el motor de reglas envía el mensaje al servicio Lambda. El servicio Lambda dice, genial, lo tengo, 202. Y luego tu función Lambda se coloca en una cola y se ejecuta de forma asíncrona. Y solo entonces, cuando esa ejecución se completa, en algún lugar, idealmente en algún archivo de registro, verás el resultado de la ejecución de tu función Lambda, ¿verdad? Por eso, por supuesto, cuando esto sucede con un dispositivo, ya sabes, piensas, sí, lo tengo bajo control. Puedo ir al registro de la función Lambda y puedo mirar allí y puedo ver que en realidad la función Lambda falló. Pero idealmente, en realidad usarías algunas herramientas de trazado y, ya sabes, algunas herramientas que te permitan habilitar el registro y monitoreo en tus aplicaciones, para que puedas ver estas cosas relativamente fácilmente.

Y una de estas herramientas es Lambda Power Tools, y Lambda Power Tools es en realidad una biblioteca de código abierto. Está disponible para Typescript. También está disponible para otros lenguajes como Python, por ejemplo. Y lo que hace es proporcionarte un conjunto de utilidades que puedes integrar en tu aplicación de JavaScript, para que puedas crear fácilmente registro estructurado, puedes crear métricas, incluso puedes construir tus propias métricas, y también de alguna manera, ya sabes, ver las trazas en un servicio que se llama X-ray, ¿verdad? Entonces, quiero decir, por supuesto, esto funciona si estás integrando con servicios de AWS. Si estás integrando con otros tipos de servicios, es posible que desees identificar diferentes herramientas de observabilidad que puedes utilizar, ¿verdad?

La forma en que instalarías Lambda Power Tools es básicamente utilizando capas de Lambda o puedes usar NPM. Y puedes instrumentar usando MIDI, que es una biblioteca de middleware muy famosa para Lambda, o puedes hacerlo con decoradores o puedes hacerlo manualmente. Entonces, en realidad se ve bastante bien si miras el código de TypeScript, ¿verdad? Aquí solo estoy usando módulos de Node. No voy a entrar en detalles sobre eso. Pero luego puedes crear tu trazador y registrador, y luego simplemente puedes usar MIDI para literalmente inyectarlos en tu función Lambda. ¿Verdad? Entonces, con lo que tengo aquí, básicamente todas tus trazas van a ir desde la invocación de tu función Lambda hasta X-ray, ¿verdad? Veamos. Esto en realidad no se ve muy bien. Así que tal vez simplemente voy a cambiar y mostrártelo rápidamente. Todavía me quedan 56 minutos. Eso sería bueno. De acuerdo. Entonces, básicamente lo que he hecho aquí, he enviado un mensaje desde un simulador de dispositivo IoT, que está utilizando MQTT.js como biblioteca. Así que esta es mi aplicación cliente y esto es el... En este caso, es el motor de reglas, y este es el contexto de Lambda del servicio Lambda.

Y esto es en realidad la invocación de Lambda. Entonces, cuando lo ves a alto nivel, esto se ve realmente bien, ¿verdad? Entonces, en realidad no ves ningún error. Pero cuando miras aquí abajo, en realidad ves que el servicio Lambda aceptó la función Lambda, pero luego ves que en realidad la ejecutó o intentó ejecutarla dos veces. Así que eso es interesante. Y esa es la configuración predeterminada de AWS Lambda. Va a reintentar por defecto si es en modo asíncrono. Entonces, cuando usas SAM y creas tus funciones Lambda, el valor predeterminado siempre es dos veces. Así que piénsalo. Ya sabes, invocación asíncrona dos veces. Correcto.

Así es como se ve X-Ray, y aquí puedes ver el trazado y demás. Hoy no tenemos más tiempo, pero siempre puedes echar un vistazo a los repositorios de GitHub que he enlazado y aprender un poco más sobre las herramientas de potencia de Lambda y sobre X-Ray y demás. Muchas gracias. Esto fui yo.