Guardianes de las Aplicaciones: Conquistando la Monitorización de Aplicaciones Node.JS

¿Qué sucede cuando tus aplicaciones se bloquean conscientemente? ¿Las cortas mientras los ingresos se desploman? Nos sentimos impotentes.

Hola, soy Martin Tomician, un gerente de pensamiento senior aquí en NippoBip, y hoy voy a compartir contigo los métodos de pruebas y monitorización del modelo que pueden ayudarte a prevenir desastres. Permíteme presentarme primero. Tengo 30 años y tengo una sordera del 55% en ambos oídos. Y en mis siete años en NippoBip, he dominado habilidades como Infraestructura Web, React, Webpack, Microcontenido, Automatización, Monitorización, Mejora de la Experiencia y mucho más. Pero hey, no soy solo un programador, y no estoy en conferencias ni en mentorías. Si me encuentras explorando el mundo, tomando fotografías excepcionales y también coleccionando patitos de goma y imanes cada semana, agárrate porque todo estará bien.

Sabes cuando Netflix deja de funcionar y los clientes se enfadan rápidamente, y tienes un mal día, los conductores violan a los clientes y el autobús. Por eso es importante que los equipos monitoricen los sistemas. Juegan de detectives para poder detectar errores antes de que los notes.

Y sabes que capturar y detectar problemas temprano mantiene a los clientes listos. Así que vamos a explorar los conceptos importantes de la monitorización y la observabilidad. Y pongamos un ejemplo. El pequeño Pedro cayó fuerte y se raspó la rodilla. Su pequeño asistente monitorizó cómo cojeaba y limpiaba los patrones en su herida. El robot investigó por qué se cayó y se dio cuenta de que tenía los zapatos desatados. Y juntos cuidaron de la herida y previnieron la próxima. La monitorización aquí y la observabilidad trabajan juntas. Y la monitorización es básicamente como un pequeño asistente. Sigue adelante y trabaja para ver si las cosas funcionan correctamente. Y verifica métricas como si ve si la rueda cojea y sabe de inmediato que algo está mal. El registro aquí ayuda a la monitorización al verificar y registrar información que puede ser útil más adelante. Pero la monitorización solo te alerta sobre problemas. La monitorización puede sentirse como vagar en la oscuridad. No estás seguro de lo que está sucediendo. No estás seguro de la causa raíz. Tu capacidad es como si encendieras un interruptor de luz. Sabes que iluminas todo y puedes ver los registros, métricas y trazas claramente. Y de inmediato sabes por qué Pedro se cayó. Porque tenía los cordones desatados.

Y otro ejemplo más es el testigo intermitente del motor dentro de la línea del coche. Porque te advierte sobre los problemas, pero no sobre la causa. Cuando tienes mecánicos y confían en el diagnóstico para poder reparar tu coche con precisión, la durabilidad es básicamente algo muy similar. Porque mira bajo el capó del software, señala el problema para que pueda ser reparado.

Y la monitorización aquí, por ejemplo, nos dice que algo está mal, pero no cómo retener a nuestros usuarios. Y sabes que con las herramientas de monitorización, nuestras aplicaciones tienen superpoderes. Como héroes, las aplicaciones pueden parecer invencibles, pero dependen del talento detrás de escena para ayudar a detectar errores temprano. En InfoPip, por ejemplo, utilizamos Greylock para el registro, Grafana para los paneles de control, Prometheus para las métricas, Obgeni para las alertas y Sensory para los problemas que enfrentan los usuarios. Y voy a mostrarte algunas historias de trabajo reales de monitorización y usar ejemplos prácticos. Debido al tiempo limitado, no me voy a enfocar tanto en demostraciones aburridas de herramientas. Así que empecemos.

El filósofo griego Platón dijo una vez que una buena decisión se basa en el conocimiento y no en los números. Y nuestras decisiones afectan a la empresa, las aplicaciones y la confiabilidad. Por lo tanto, es importante ver cómo las malas elecciones pueden afectar esto y causar inestabilidad. Y es importante entender cómo funciona nuestra aplicación, cuál es el comportamiento correcto y cuál es su performance actual para que podamos hacer un registro, monitorización y solución de problemas adecuados, y para que podamos tomar decisiones acertadas. Y el primer ejemplo es ShopPass. Su sistema comenzó a fallar tan pronto como su trampa de compras se activó y los gerentes estaban en pánico. Ahora simplemente comenzaron a comprar esta, esta, esta, esta herramienta de monitorización sin ninguna estrategia, todo estaba desarticulado, todos estaban confundidos y no tenían ningún enfoque sistemático. Lo que quiero decir, ya sabes, todos hemos intentado apagar incendios sin ver realmente el cuadro completo. Y este es el patrón anti-grasa, que se llama obsesión por la herramienta. Cuando nos obsesionamos tanto con ciertas herramientas que perdemos la perspectiva, porque es tan fácil pensar que la última herramienta será la súper bala y terminar distrayéndonos de entregar valor real. No sé, no deberíamos poner toda nuestra fe en las herramientas, porque pueden hacer que los equipos piensen que son una varita mágica que conduce al éxito. Porque recuerda, la boda de Cenicienta y su madre incluso le advirtió que llamara hechizos para Rerop a medianoche. Y lo mismo ocurre aquí, porque nada puede reemplazar el trabajo duro.

Entonces, ¿cuál es el problema para ShopPass? La monitorización los llevó a estar completamente confundidos y frustrados porque la red estaba tan verde, pero los usuarios aún se quejaban, perdieron tiempo tratando de descifrar esas contradicciones y errores, y realmente no tenían ninguna idea sobre esos procesos críticos del backend. Así que tuvieron que cambiar y mejorar. Y eso es exactamente lo que hicieron, porque observaron de cerca los signos vitales y las métricas, vieron qué es importante, qué los mantiene saludables y en el camino correcto, y se aseguraron de cubrir eso y simplificaron las herramientas para que solo puedan enfocarse en lo más importante. Y crearon un plan de juego enfocado, lo que les permitió detectar temprano y celebrar el progreso y asegurarse de que los productos sean más estables. Y el segundo ejemplo es, imaginemos a Tom. Él verifica el sitio web de Tickethype, como su médico, asegurándose de que todo esté bien, verifica servidores, velocidades, bases de datos y especialmente errores.

Y si algo está mal, él llama a Tim, hey, hey, ¿puedes arreglarlo? O actualizando las herramientas de monitorización, y Tom ayuda a mantener la web en buen estado. Entonces, ¿cuál es el problema aquí, en realidad? Leer y monitorear, como un molesto detector de humo, sigue posponiendo. Porque con uno o dos bomberos, ya es suficiente para manejar a todos solos. Necesitas tener a Tim, escuchando la alarma, listo para agarrar la manguera juntos. Porque ignorar solo a uno puede quemar a nuestros clientes.

Y necesitamos trabajar juntos, porque la monitorización funciona mejor como un esfuerzo de equipo. Porque todos nosotros, desarrolladores, operaciones, red, SRE, todos pensamos de manera diferente, y nuestras perspectivas ayudan a detectar problemas más rápido. Y en la mentalidad de DevOps, también se trata de combinar fuerzas para monitorear sistemas, ya sabes, porque podremos mantener las cosas funcionando de manera más fluida. Entonces, ¿cuál es el problema? Mamá monitoreaba las cosas sola. Pero ya sabes, solo podía abarcar tanto, y la comunicación era un problema, y tenía que esperar a que se resolviera la alerta. Y todo eso aumentaba su estrés, y era propenso a cometer errores.

Pero la empresa se dio cuenta de que la monitorización es demasiado crítica para una sola persona, por lo que necesitaban trabajo en equipo. Y eso hicieron, y llevaron a todos a bordo para solucionar sus problemas. Capacitaron al equipo de IT en las mejores prácticas, y lograron que no haya puntos ciegos, y que todo el equipo trabajara junto. Y automatizaron todo lo posible para agilizar las cosas, y para que todo funcione de manera bastante fluida. Y tenemos a Shopvac, por ejemplo, que decía monitorización, pero eso es demasiado rápido, como glulululu, solo usando informes. Y luego obtuvieron camisetas, y todas esas alertas apresuradas les salieron mal.

Porque todos estamos apurados de alguna manera para cumplir con un plazo, y solo para que las cosas exploten más tarde por esas esquinas de gato. Y Shopvac aprendió de la manera difícil que deberían tener una monitorización personalizada, que puede ayudar a prevenir peligros cuando tienen problemas. Y este es mi panel anti-favorito, y se llama monitorización de casillas de verificación, donde configuras la monitorización solo para ver que la tienes. Y eso no te da problemas ni soluciones, porque puedes tener datos en su mayoría poco confiables.

Por ejemplo, tuvimos problemas, mi equipo, con alertas innecesarias, porque perjudican la productividad. Imagina recibir una alerta a la 1 a.m., como, hey, la camiseta caducó hace solo un mes, por favor reemplázala cuando ya lo has hecho. Y frustrantemente, por ejemplo, no pudimos desactivar esas interrupciones inútiles, y sabes, solo estaban perturbando nuestro sueño, básicamente. ¿Y cuál es el problema? A los equipos de TI les encantaban sus sistemas de monitorización al principio, pero luego se volvieron locos de abrumados, porque recibían alertas constantes e irrelevantes, básicamente las estaban ahogando. Básicamente estaban ahogando la confianza real. Perdieron algunos problemas de aplicación realmente críticos, y creían que tenían una buena protección confiable, pero un gran problema pasó desapercibido. Y también tuvieron un gran problema cuando tuvieron incidentes, porque no tenían idea de qué sucedió según las métricas.

Entonces, ¿qué hicieron? Lucharon con la monitorización. Así que tomaron tres pasos. Primero, adaptaron sus métricas para que se ajustaran a sus necesidades. Establecieron el proceso de revisión de contactos para mejorar sus métricas y mejoraron la comunicación para que todos puedan capacitarse en cómo hacer las cosas correctamente, para que puedan hacerlo mejor.

Y compartiré un ejemplo contigo. Tenemos un panel de control Grafana de código abierto con HAProxy que usamos, y puedes acceder a él a través de este código QR o enlace si quieres. Pero sabes, por ejemplo, no copiamos y pegamos esto. Elegimos cuidadosamente lo que necesitábamos exactamente y nos aseguramos de que funcionara para lo que necesitábamos exactamente. Y está funcionando. Se ve así, por ejemplo. Lo monitoreamos regularmente y lo adaptamos según nuestras necesidades. Y sabes, realmente nos ayudó. Logramos detectar problemas e incluso creamos algunas alertas basadas en las métricas clave. Y también quiero mostrarte otro consejo. Cuando ocurren las alertas, es útil tener una lista de los pasos para investigar o solucionar problemas, como qué panel de control Grafana y qué reloj Greylock verificar, porque esto realmente ayuda mucho. Puedes recibir alertas en el teléfono. Genial. Pero si también puedes conectar tus alertas a Slack, puede facilitarte verificar las alertas completas. Puedes ver el fragmento aquí, pero compartiré más ejemplos en mi publicación del blog.

El siguiente ejemplo que quiero mostrarte es Shopbit ahora. Venden productos en línea, supervisan de cerca su sitio web, pero confían demasiado en la monitorización y no aprovechan realmente el cambio para mejorar. Y esto es similar a tener tuberías con fugas y pisos chirriantes, y en lugar de abordar los problemas fundamentales, lo único que haces es poner mantas y cinta adhesiva y llamarlo monitorización. Porque eso también sucede con los sistemas. Esto significa que no se solucionan realmente los problemas principales y la monitorización puede proporcionar un alivio temporal, pero las dudas técnicas seguirán acumulándose. Necesitamos soluciones sostenibles en lugar de soluciones temporales.

El problema era que confiaban demasiado en la monitorización, se sentían demasiado cómodos con esas alertas para solucionar un problema, por lo que seguían teniendo los mismos problemas una y otra vez. Por ejemplo, sus sitios web se sobrecargaban de tráfico. Pero en lugar de investigar esos problemas fundamentales, simplemente aplicaban soluciones rápidas. Por lo tanto, los mismos problemas seguían volviendo. ¿Qué hicieron entonces? En realidad, se preguntaron por qué sucedía esto, vamos a llegar al fondo de esto y luego organizaron un equipo para reforzar proactivamente esos puntos débiles. Y ahora las herramientas de monitorización también se centran más en mejorar la confiabilidad en lugar de simplemente reaccionar a las cosas.

Luego tenemos a Subdev, por ejemplo. Son una empresa de desarrollo que está creciendo rápidamente y ahora tienen cientos de servidores. El equipo de TI está luchando por configurar la monitorización para cada servidor manualmente. Y esto se vuelve cada vez más difícil. Y amigos, las herramientas de monitorización y la configuración manual desperdician mucho tiempo y somos propensos a cometer errores. Así que hablemos de una forma más inteligente de hacer esto. Porque para Subdev, el problema era que las cosas se volvieron más complejas, era difícil mantenerse al día, y simplemente se les escapaban cosas, la comunicación era un problema, no podían mantenerla. Y se dieron cuenta de que tratar de solucionar los problemas a medida que ocurren simplemente no funcionaba en absoluto, ya sabes. Así que necesitaban hacer algo. Y tomaron varios pasos. Primero, tomaron la monitorización, que es matemática estándar, y aplicaron una configuración estandarizada para que esté alineada en todas partes. En segundo lugar, están utilizando control de origen para tener una única fuente de verdad para todo y mejorar el trabajo en equipo. Y tercero, crearon una plantilla para poder reutilizarla y ahorrar tiempo y garantizar la calidad.

Y solo te mostraré un ejemplo interesante de lo que hicimos. Automatizamos el panel de control Kapana. Solo queremos una entrada codificada, que es el nombre del propietario del equipo. Todo lo demás se calcula completamente mediante consultas primitivas. Y lo tenemos en el panel de control de esta manera. Seguimos el estado de nuestras máquinas virtuales y de nuestros servidores. Y nos ayuda a mostrar los estados muy rápidamente. Y también logramos detectar varios problemas que han aparecido.

El panel de control fue una idea realmente buena y fue extremadamente útil para nosotros para monitorear el rendimiento. Pero tenemos otros dos ejemplos. La monitorización para Nest Hub era como padres helicóptero, ya sabes, una monitorización constante de fatiga que sucedía porque recibían notificaciones sobre cortes de papel en lugar de solo sobre emergencias reales como huesos rotos. Y, ya sabes, una buena monitorización nos dice cuando nuestro sitio está realmente enfermo, no cuando solo tiene un resfriado. Necesitamos brindar a nuestros ingenieros información útil que no los abrume, pero que les permita centrarse en esos problemas críticos.

Porque creo que este antipersonal es bastante autoexplicativo. No deberíamos estar llamando a las 3 de la mañana diciendo: `Oye, la televisión caducó hace tres meses. Por favor, reemplázala`. Porque las notificaciones humanas solo nos enseñarán a ignorar esas alertas, ya sabes. Y todos hemos estado allí, ya sabes. Pero el punto es que necesitamos que nuestra tecnología nos impulse, nos ayude, no nos vuelva locos. Y sabes, simplemente puede llevarnos también a nuestros dispositivos en busca de ayuda y eso no es bueno. Y sabes, siendo humanos, somos humanos. Y siempre cometemos errores. Pero solo necesitamos asegurarnos de mejorar. Ahora debemos hacer que nuestra tecnología funcione para nosotros, no en nuestra contra.

Y el problema de Nest Shop fue que simplemente tenían demasiadas alertas y no podían distinguir las emergencias reales de las menos importantes. Se perdieron muchos problemas graves que se encontraban entre las alertas menos urgentes. Y con tantos contactos entrantes, no podían utilizar los recursos adecuadamente. Eso fue un problema para ellos. También tomaron varios pasos. En realidad, priorizaron las alertas críticas para que puedan ser clasificadas lo más rápido posible, especialmente cuando más importan.

Han cambiado el umbral para tener menos falsos positivos. Han conectado las alertas a los ingresos y a lo que realmente puede afectarlos. Y han optimizado el proceso para que las personas adecuadas puedan abordar los problemas adecuados y esto también les ayudó a aumentar la eficiencia.

Otra idea creativa para las alertas no urgentes es, por ejemplo, tener la alerta de que un certificado caducará en un mes y medio, y quieres ser notificado pero no a las 2 de la mañana. Puedes configurar tu alerta para que te notifique solo durante el horario laboral o durante algunos días específicos. Y esto puede ayudarte a utilizar las consultas de Nature de una manera realmente creativa. Y es bueno hacer cosas así, ya sabes.

Pero también, por ejemplo, podemos tener News Hub. Millones de noticias y solo les importa cargar el contenido más rápido, digamos, cuando están creciendo y tienen más popularidad. Pero, ya sabes, solo cubrir los archivos cargados no es suficiente porque el software complejo, no podemos producirlo con una única métrica simple. La línea web en declive puede ignorar puntos de dolor reales. Y por ejemplo, obtener medicamentos es como si rastreáramos a un paciente y solo rastreáramos el peso y la altura, pero no rastreáramos los análisis de sangre para diagnosticar problemas. Y este patrón final interesante se llama la gran métrica general. Y puedes imaginar que, por ejemplo, tienes un 95% de los encuestados en 180 milisegundos. No sé cómo nos ayuda, ¿qué nos dice? Las métricas deben ser útiles. Deben proporcionarnos información que realmente pueda ayudarnos, de la que realmente podamos beneficiarnos. Esto no nos ayuda en absoluto, ya sabes, es inútil.

Y por ejemplo, si tenemos un tiempo de respuesta para absolutamente todo, como una única métrica, o mostrar solo la parte superior de la vista sin ningún otro detalle. No nos da ninguna información. No podemos hacer nada con eso, ya sabes. Y News Hub se dio cuenta de que una única medida de rendimiento era demasiado básica, no podía diferenciar realmente entre cosas importantes. Así que lo cambiaron para solucionar problemas realmente importantes y malinterpretaron los problemas reales, como la velocidad de la aplicación, y pasaron por alto todo eso. Y no salió muy bien. Así que necesitaban mejorarlo. Así que tomaron tres medidas. Realizaron un seguimiento de las métricas de rendimiento, necesitaban poner diagnósticos de tamaño, luego configuraron la monitorización de herramientas que pueden ayudarles, y solo están utilizando esas específicamente. Y en tercer lugar, están revisando constantemente las métricas para mejorarlas.

Y solo para mencionarlo brevemente, también mejoraron la velocidad y la confiabilidad, pero, no hay problema, también puede haber demasiados paneles de control. Porque puedes ponerlo en roaming, no sabes dónde buscar, te lleva demasiado tiempo solucionarlo. Así que debemos simplificar y enfocar los paneles de control para que puedan responder a las preguntas clave sin desorden y de manera precisa y rápida.

De todos modos, para resumir, la idea principal es que la supervisión es crucial, pero es compleja, y debes poder hacerlo correctamente. Debes comprender cuál es el comportamiento correcto para cada servicio, porque siempre habrá problemas. Por eso supervisamos. Saber que algo está mal no es suficiente. También debes poder actuar rápidamente, y por eso es importante conocer tus servicios.

Además, debes tener en cuenta que la supervisión es un proceso constante. Debes trabajar constantemente en mejorar tus servicios, porque debes poder mantener la vigilancia y estar alerta para poder react rápidamente si es necesario. Y ya sabes, es difícil cubrir todo en 20 minutos, y si quieres aprender más sobre este tema, he preparado un pequeño artículo en Hashnode que proporciona un poco más de información. Pero también escribiré una serie de artículos en colaboración con InfoBeep DevRel y los desarrolladores de InfoBeep, que se publicarán en los próximos meses.

Entonces, si quieres estar en contacto y ver esos artículos, no dudes en seguirme en Hashnode, y también puedo recomendarte de inmediato un libro de reuniones que brinda información realmente excelente sobre confiabilidad y supervisión. Esos son Radical Monitoring de Mike Julian y publicados por Michael D. Nygart. Pero también puedes conectarte conmigo en las redes sociales, porque compartiré todos los enlaces y todos los artículos allí también para cualquier persona que esté interesada. Y ya sabes, puedes conectarte conmigo a través de este enlace que tiene todos mis enlaces de redes sociales. También puedes encontrarme en Twitter, que ahora se llama Axe, o en LinkedIn, donde seguramente encontrarás esos enlaces.

Y ya sabes, también puedes simplemente escribir el enlace de Bitly si quieres llegar más rápido. Quiero agradecerte por escucharme. Espero que mi sesión te haya proporcionado información útil, y espero escuchar todas tus preguntas que puedas tener. ¡Gracias y nos vemos pronto! ¡Gracias! ¡Adiós!