Video Summary and Transcription
La charla aborda los desafíos del desarrollo de IoT, incluyendo problemas con flotas sin conexión, datos faltantes, alertas que no funcionan, datos inconsistentes y paneles de control de carga lenta. Explora cómo construir observabilidad en aplicaciones IoT utilizando métricas, registro y trazado. Se explica la integración entre el motor de reglas y Lambda, destacando el uso de herramientas como Lambda Power Tools y X-Ray para el registro, monitoreo y trazado. También se menciona el proceso de invocación de Lambda y las capacidades de trazado de X-Ray.
1. Introducción a los desafíos de IoT
Todo el mundo comienza en el espacio de IoT pensando que todo es sol y mariposas, pero cuando pasas a producción, se convierte en un laberinto. La prototipación y las pruebas en el laboratorio pueden ir bien, pero luego surgen problemas. Flota sin conexión, datos faltantes, alertas que no funcionan, datos inconsistentes y paneles de control que cargan lentamente.
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.
2. Construyendo Observabilidad en IoT
Para construir observabilidad en una aplicación de IoT, necesitas métricas, registro y trazado de una manera estandarizada. Vamos a explorar cómo lograr esto en un escenario de backend sin servidor, donde un dispositivo IoT envía datos a través de MQTT, recogidos por una regla de AWS IoT y enviados a una función Lambda.
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.
3. Integración entre el Motor de Reglas y Lambda
La integración entre el motor de reglas y Lambda funciona de forma asíncrona, con la función Lambda siendo colocada en una cola y ejecutándose de forma asíncrona. Para habilitar el registro y monitoreo en tus aplicaciones, puedes utilizar herramientas como Lambda Power Tools, una biblioteca de código abierto que proporciona utilidades para el registro estructurado, métricas y trazado. Lambda Power Tools se puede instalar utilizando capas de Lambda o NPM, y se puede instrumentar utilizando bibliotecas de middleware como MIDI. Al inyectar el trazador y el registrador en tu función Lambda, puedes enviar trazas a X-ray para la observabilidad. En este caso, un simulador de dispositivo IoT envía un mensaje al motor de reglas, que interactúa con la función Lambda a través del servicio Lambda.
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.
4. Invocación de Lambda y X-Ray
Esta es la invocación de Lambda. El servicio Lambda aceptó la función pero la ejecutó dos veces debido a la configuración de reintento predeterminada en AWS Lambda. X-Ray proporciona capacidades de trazado. Consulta los repositorios de GitHub para obtener más información sobre las herramientas de potencia de Lambda y X-Ray.
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.
Comments