Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas (00:00)
Era un caos, o sea...
Yo miraba todo el tiempo mi bandeja de entrada y yo miraba los dashboards llenos de alertas y no me generaba ninguna preocupación y eso luego generó bastantes problemas y tomó un tiempo llegar a un punto óptimo y tomó un tiempo darse cuenta que ese era un error algo en lo que no estuve yo de acuerdo desde el inicio pero bueno la instrucción venía de arriba y cuento esta anécdota porque realmente
no podemos caer en ese punto en el que cae una alerta y sentirme que la puedo ignorar. estoy en esa situación actual, si alguien que no ve y no se escucha está en esa situación necesita hacer algo al respecto de manera urgente,
Hola a todos y bienvenidos a Dev and Ops, este espacio en el que como siempre hablamos de tecnología, desarrollo, DevOps y su cultura en general. Como siempre, en compañía de mi gran amigo y co-host Juan Ramos, a quien le doy como siempre la cordial bienvenida, Juan, ¿qué tal estás?
Juan (01:11)
Hola Douglas, me encuentro muy bien, gracias a Dios estoy muy bien el día de hoy con ganas de platicar mucho. no sé, irónicamente ha sido un día extraño el día de hoy. No pude ir a la barbería, no pude terminar unas cosas del trabajo, no sé, fue un día un poco caótico, pero creo que voy a poder cerrar el día con esta plática que vamos a tener que es... me interesa mucho, me interesa mucho.
Douglas (01:40)
hoy
fue uno de esos días entonces, uno de esos días en el cual como profesionales en tecnología a veces no salen las cosas y pues bueno, esperemos que cuando, que no vaya a ser que cuando ya estés acostado se te ocurra la solución al bug y te mantenga y te haga despertarte y levantar y terminar.
Juan (01:50)
Definitivamente fue uno de esos días.
Sí. Que de
hecho podría ser lo hoy en día Douglas. He estado haciendo, he estado utilizando, bueno, en mi grupo de trabajo estamos utilizando más AI. Entonces, te permite programar tareas con el AI, le decís, hace tal y tal cosa. Y queda haciéndolo en la nube. Y luego solo realizas el, haces un code review.
Douglas (02:13)
mmm
Sí, sí, sí, no,
tenés razón, hoy pasa más seguido eso, eso de, a mí me ha tocado muchas veces ya en la noche acostado a agarrar mi celular y platicar un ratito con la inteligencia artificial porque creo que tengo la solución a un problema.
Juan (02:29)
Mm-hmm.
Mm-hmm.
Douglas (02:40)
Pero
bueno, esa es la vida de las personas que trabajamos en tecnología. Creo que por suerte resulta entretenido, a pesar de lo cansado e incómodo que puede ser, nos resulta entretenido y son de esas cosas raras.
Juan (02:56)
Si, una paradoja.
Douglas (02:58)
Es una paradoja, sí, sí, muy de acuerdo.
Y hablando de cosas complicadas, creo yo que el tema de hoy va a ser muy interesante para las personas que nos ven y nos escuchan, porque hoy vamos a estar hablando de configurar alertas de forma efectiva. Y en este tema, Juan, me interesa mucho tu opinión, porque yo sé que como programador...
no necesariamente estás encargado de configurar alertas o no necesariamente sos la persona que está recibiendo alertas, pero estoy seguro que tenés un punto de vista al respecto y que también en algún momento te ha tocado colaborar con la gente de ESRI o con el sysadmin para configurar alertas, métricas, agregar logs en específico a las aplicaciones para poder tener estas alertas listas para los diferentes sistemas o para nuestras aplicaciones.
Y es que realmente que una alerta o las alertas mal configuradas pueden llegar a ser muy molestas, muy incómodas. Normalmente cuando recién lanzamos una aplicación o recién levantamos un nuevo servicio
Juan (03:53)
Sí.
Douglas (04:10)
toma cierto tiempo ajustar las alertas a que estén al punto necesario, al punto en el que ya están listas para nosotros reaccionar de forma efectiva también a ellas, ¿verdad? Y lo que queremos hacer hoy es compartir desde nuestra experiencia.
cómo configurar alertas efectivas, través de prueba y error, a través de situaciones un poco caóticas a veces, experiencias un poco caóticas e interesantes, y dar algunos consejos sobre este tema. Y tal vez me interesa comenzar preguntándote a vos como programador.
Juan (04:35)
mmm
Douglas (04:48)
qué tanto interés le pones a este tema de las alertas, qué tanto pensás en ello al momento en que te toca arquitectar una solución o al momento en que estás desarrollando una nueva funcionalidad.
Juan (05:00)
interesante porque
diría que depende. Idealmente, Es necesario tener una visión clara de qué está sucediendo con tu servicio, tu aplicación en general. Pero también sucede que a veces nos interesa más algunos aspectos de la aplicación que otros. Hay otras partes que digamos que no hay problemas si no tenemos todo la información. No me refiero a cuánto se tarda un request, cuánto se...
cuando utilizó de memoria o sea sabemos que hay ciertos puntos en la aplicación que a veces no le prestamos tanta atención entonces en ese caso Douglas de mi parte si le pongo atención pero lo hago más selectivamente claro también eso se ve reflejado por la manera en cómo está dividido mi grupo de trabajo donde estoy actualmente tenemos una responsabilidad más
compartida. Me refiero a que no tenemos como un departamento en específico que se encarga de crear y revisar todas estas alertas, así que los desarrolladores nos encargamos también de atender las alertas y revisarlas y todas estas cosas. que como tenemos que estar en muchas cosas a la vez, requiere que seleccione bien dónde voy a invertir ese esfuerzo.
y bueno claro a veces pasa que tal vez hubo algo que tuve que haberle puesto más atención y al momento de buggyar me doy cuenta que ok no no tuve ninguna alerta y hay un error que sucedió hace una semana entonces toca regresar y tratar de dejar eso listo para que no vuelva a pasar eso eso ha sido mi experiencia
Douglas (06:57)
Sí, me llama la atención bastante
y tu respuesta está bien cerca de lo que me imaginaba. No hemos hablado vos y yo antes mucho sobre este tema de alertas, pero pues muchas cosas tienen sentido. El programador no es responsable en la gran mayoría de los casos y situaciones de estar recibiendo las alertas. ⁓
y por ende su tiempo es invertido en otro lugar. No es necesariamente algo malo en lo absoluto porque no es la funcionalidad principal, pero también la intención de esta conversación hoy es que se pueda despertar esa curiosidad y ese interés y que las personas tanto del área de sistemas, infraestructura, aprendamos un poco cómo configurarla de manera efectiva, Y también las personas en desarrollo...
Juan (07:44)
No,
Douglas (07:48)
pueden mostrar un poquito de interés y le vean el beneficio. Ahorita dijiste algo interesante, Que es, te has topado con que ocurrió algo hace una semana, ¿por qué no me di cuenta antes? ¿Por qué me di cuenta hasta ahora, verdad? ¿Y cómo puedo hacer para darme cuenta más rápido de este tipo de problemas y evitar de repente situaciones más grandes? Entonces creo que estamos iniciando bien la conversación.
Juan (07:52)
Sí.
Mm-hmm.
y me llama
la atención que decís alertas efectivas uno creería que solo es de mandar una notificación y ya o podría ser ese nuestro primer pensamiento, que es bueno mando todo lo que una alerta de todo lo que pasa y ya, que cada quien decida que hacer con eso pero parece que hay una forma correcta de hacerlo
Douglas (08:33)
Sí, sí, de
hecho, eso que acabas de decir es como el primer error que se comente, el error más grande. Sólo porque encontramos la posibilidad de enviar alertas y luego queremos alertar todo. Queremos alertar todo y bueno, ahí vamos también, le voy a contar un par de anécdotas y experiencias personales al respecto.
Juan (08:47)
Sí.
Douglas (08:56)
Pero si te parece Juan, empezar quiero como dar una definición, esta es una definición mía que anoté acá, que está acertada, no necesariamente algo de libro, pero una alerta es básicamente una notificación o advertencia generada por un sistema que informa sobre un evento de riesgo que requiere acción o atención.
Juan (09:08)
Mm-hmm.
Douglas (09:22)
es un mensaje, una notificación de un evento que ocurrió y necesita acciones al respecto, que le preste atención. Entonces, desglosemos un poquito esa definición. De nuevo, es como una definición mía, pero no está alejada de la verdad. visto definiciones más elaboradas y son básicamente lo mismo. Pero desglosemos un poco esto.
Juan (09:30)
Ok.
Douglas (09:51)
Un sistema, según su tipo, genera muchas métricas. Según el tipo del sistema, porque puede ser un tipo de aplicación, puede ser un tipo de servicio, un sistema puede generar métricas de sus recursos. Métricas del CPU, la memoria, paginación, el espacio en disco.
y esos son los recursos que está utilizando dicho sistema. Tenemos ese tipo de métricas, le podemos llamar las métricas de recursos de tu sistema. También tenemos métricas de servicios. Servicios corriendo, puede ser el estado del servicio, si el servicio está corriendo...
o no está corriendo, es una métrica. ¿Cuánto tiempo estuvo corriendo un servicio? Es un tipo de métrica. Timeouts de un servicio en particular, esa es una métrica que nos está arrojando. El status code de un servicio, un llamado y se fue con éxito, el status code 200, si el archivo no se encuentra, un status 404, etcétera. son cada vez que ocurrió un evento de esos, eso es una métrica. También tenemos
diferentes logs de los servicios, si tenemos un servicio de base de datos, un servicio de correo electrónico, va a estar generando logs de errores, de eventos, eso es un tipo de métrica de servicio, verdad, entonces tenemos recursos, servicios y una más que yo agregaría acá.
serían como ya métricas de la aplicación como tal. La aplicación que alguien desarrolló, tu equipo de desarrollo, sí, ya de la funcionalidad de la aplicación como tal. Esto puede incluir cantidad de requests a un endpoint específico, o a cada endpoint, cuántos requests llegaron, en cuánto tiempo, cuál fue el estatus o el resultado de cada uno de esos requests, logs de la aplicación. De nuevo, la aplicación puede estar generando logs de...
Juan (11:27)
de la lógica.
Douglas (11:50)
su conexión a la base de datos, etcétera, tiempo de respuesta de la aplicación como tal, cuánto tardó de nuevo en conectarse a la base de datos, en conectarse al caché de la aplicación y entonces ese tiempo que tardó lo está guardando y esas son métricas de la aplicación y partimos con eso, con el punto base, verdad, para...
Juan (12:16)
Sí.
Douglas (12:17)
alertas tenemos métricas diferentes tipos de métricas que son valores son el resultado de una de una acción ya sea en tus servicios o en tu aplicación con estas métricas generalmente cuando ya vamos avanzando y tenemos aplicaciones más grandes y complejas generamos dashboard para visualizar de manera efectiva todo ⁓
Juan (12:42)
Sí.
Douglas (12:44)
Si alguien que nos ve y nos escucha donde están, no tienen ningún tipo de visualización para este tipo de métricas, ese sería el comienzo. Comenzar creando dashboards, se pueden usar desde servicios open source como Prometheus para colectar las métricas y Grafana para generar los dashboards o aplicaciones más enterprise. También dependiendo de la aplicación, pueden haber servicios como New Relic, como...
Datadoc, que nos generan dashboard donde tenemos diferentes tipos de métricas, pero tenemos la visualización de todas las métricas, eso es muy importante para nosotros y necesitamos esas métricas porque nos son útiles para tomar decisiones alrededor de la aplicación, ¿verdad?
Juan (13:30)
Sí,
Douglas (13:31)
definir recursos para
Juan (13:31)
bastante.
Douglas (13:32)
la aplicación porque tal vez vemos que no está aguantando la infraestructura actual y le queremos agregar recursos o encontramos áreas de mejoras, encontramos que si agregamos un caching en cierto lugar va a tener un mejor rendimiento o si agregamos un índice a ciertas tablas van a mejorar ciertos queries, etcétera. esas métricas nos sirven mucho, es importante.
Juan (13:58)
Sí.
Douglas (14:00)
y construimos bastante alrededor de ellos y esos son nuestros ojos dentro de la aplicación y los diferentes servicios. Ahora, habiendo dicho eso, no todas estas métricas necesitan enviar alertas.
Juan (14:09)
Mm-hmm.
Douglas (14:18)
y es ahí hacia donde vamos. Ahora, quiero pausar un poquito Juan y quiero preguntarte, en esto que mencioné ahorita, sentí vos que tal vez me hizo falta un tipo de métrica, yo mencioné de recursos, de servicios y de la aplicación.
Juan (14:20)
Sí.
Douglas (14:36)
¿Verdad? Sentís que tal vez me hizo falta un tipo de métrica que es importante mencionar, tal vez, no sé, del lado de la aplicación. O si no, con cuál de estas métricas vos has tenido experiencia, ya sea configurando o ya sea colaborando con la gente de sistemas para configurar.
Juan (14:54)
He configurado muy poco. Si al estar haciendo código de backend, algo en lo que le tomo mucha importancia es en dejar logs que sean relevantes a lo que está sucediendo. Obviamente los logs de cuando suceden errores siempre son bien importantes, pero a veces hay logs que solamente son informativos y son muy útiles a la hora de crear estos dashboards con herramientas como Grafana.
con Grafana me permite mí crear dashboards así que no los he configurado como tal de Prometheus y las interconexiones que hay entre estos servicios pero sí he creado pequeños dashboards en Grafana que me permiten visualizar cierta información en la que estoy interesado en cierto momento y eso sí lo he hecho, sí he estado obviamente he utilizado y he revisado las métricas que ya están dadas
los recursos es algo muy importante. Recuerdo en cierto momento teníamos unos problemas con unos servicios, microservicios que...
nos mostraban muchos mensajes de error, pero los mensajes de error eran como que muy... No tenían sentido, ¿no? Nos decía que no encontraba un archivo después de haberlo generado. No tenía sentido. Entonces, empezamos a revisar y resulta que por diferentes factores, ¿no? Las instancias donde estaba corriendo estos servicios, empezamos a ver los diferentes puntos, los spikes, una subida muy grande de uso de recursos, de RAM.
llegaba al punto donde Kubernetes mataba al servicio y como lo mataba a estos otros servicios empezaba a crear una cadena de errores y bueno al revisar las métricas empezás a anotar estos patrones al inicio es difícil más si no tenés mucha experiencia debugging o viendo o visualizando esta información podés ver los picos de uso pero como que no hace clic ⁓
Douglas (16:42)
y eso es lo que a hacer con el proyecto la organización de la universidad.
y se ha hacer. Y eso es lo es la pregunta.
Juan (17:04)
es necesario tener un acercamiento y empezar a revisar qué es cada cosa tener un entendimiento
Douglas (17:05)
Y eso lo que la pregunta. Y eso es lo que es la Y eso es lo pregunta. Y eso es lo que es la pregunta.
Juan (17:13)
de qué hace nuestra aplicación, obviamente pero bueno, parte del aprendizaje, claramente así que sí ahora, con tu pregunta, si me parece que hacía falta algo bueno, tenía más que todo como una contra pregunta porque cuando dijiste que eran métricas sobre el funcionamiento
pensé que ibas a mencionar algo como por ejemplo cuantas compras hemos tenido el día de hoy, cuantos usuarios hay que a veces esas son métricas que tenemos del sistema o no sé si esos entrarían en otra categoría de otro tipo que también pueden lanzar alertas dependiendo de lo que queremos pero no sé
Douglas (17:59)
No, sí son métricas, en efecto son métricas de la aplicación más orientadas al lado de negocios, verdad, pero definitivamente son métricas. Dí algunos ejemplos porque pues no los podemos mencionar todos, pero sí son métricas y mira, relacionado a la experiencia que...
Juan (18:07)
Ajá, sí.
Claro.
Douglas (18:21)
nos contaste de tu proceso de bugging y troubleshooting y cómo encontrás errores y cómo te topabas con que faltaba información, eso va de la mano con esto porque eso genera, la necesidad de primero ver y decir, hey, nos falta tener visibilidad en esta área, implementemos este tipo de métricas.
Juan (18:42)
Sí.
Douglas (18:44)
ya sea a nivel de recursos, ya sea a nivel de aplicación, implementemos este tipo de métricas y a medida continuas con el troubleshooting, luego te topás con que, hey, vimos que hay tantos usuarios conectados. A partir de X número de usuarios, se empieza a poner más lento. Entonces quiero tener una alerta cuando sobrepacemos ese número de usuarios conectados. Y eso lo que comienza a generar la necesidad de todas esas métricas.
Juan (18:59)
Sí.
Douglas (19:15)
de que es importante para el equipo o para una persona o para el de sistema o el de desarrollo, etcétera, darse cuenta y eso genera, ok, alertemos esto, ¿verdad? Entonces eso es parte del proceso, pero...
Juan (19:26)
Sí.
Douglas (19:30)
respondiendo a tu pregunta y que se vuelve un todo, respondiendo a tu pregunta, en efecto lo que vos decís de la visibilidad dentro de la aplicación son métricas, métricas de la aplicación más orientadas a la negocio, en base a eso se hacen dashboards, en este lugar donde vos y yo trabajamos juntos, habían bastantes dashboards que tenían que ver con la métrica de los negocios incluido ventas diarias, ¿verdad?
Y en base a eso se reaccionaba porque había incluso proyecciones de cuánto se vendió el año anterior, ese mismo día del año anterior, ese mismo día hace dos años, ese mismo día hace un mes y tenían estadísticas y cosas. Y eso generaba una proyección de más o menos cuánto se tendría que estar vendiendo cada día, acorde a diferentes patrones. Y si esos ⁓ objetivos de ventas no se estaban cumpliendo, se empezaban a investigar,
Juan (20:03)
Claro,
Douglas (20:25)
problemas en la aplicación y en muchas ocasiones en efecto eran problemas de la aplicación y por eso nos estaban cumpliendo esas métricas verdad pero pero eso para responder tu pregunta y en efecto me gusta tu respuesta también porque se vuelve un todo verdad ese tipo de situaciones son las que nos hacen darnos cuenta de qué cosas necesitamos alertar
Juan (20:42)
Mm-hmm.
Sí, tienes mucha razón porque estoy tratando de recordar como por ejemplo diferentes locks que yo suelo dejar que ya hoy en día se han vuelto como casi memoria muscular al hacer una función en cierta parte, cierto endpoint o lo que sea ya me acostumbré a dejar locks de diferentes tipos pero esto ha venido porque en el pasado he necesitado revisar esto, el tiempo de respuesta, está funcionando esto
realmente está haciendo lo que dice que está haciendo y ya con esto me da esa visibilidad que yo necesito y sí son como respuestas a cosas que han pasado anteriormente
Douglas (21:28)
Sí, sí, sí.
Bueno, me gusta. Se trata de no repetir errores del pasado. De eso se trata mejorar en lo que tiene que ver con programación, desarrollo, sistemas, configuraciones, etcétera. De la misma manera, yo me he topado con muchas cosas que yo dejo listas y configuradas, productos o errores del pasado y quererlos o evitar o estar preparado para colectar cierta información.
Ahora, habiendo aclarado las métricas que existen, de nuevo no podemos dar detalle para cada una de las métricas que existen, pero por tipo de métrica nos podemos hacer la idea y que en base a estas métricas es que generamos las alertas. Ahora me gustaría que definamos que una vez que generamos alertas, estas alertas, Juan, deben de ser accionables.
O sea, si cae una alerta es porque quien recibió la alerta tiene que hacer algo al respecto. Puede ser de manera inmediata, dependiendo de la severidad del problema, o puede esperar de repente minutos o a veces hasta horas, dependiendo de la alerta, lo que sí es cierto es que esta alerta debe generar una acción, ¿verdad?
Juan (22:34)
Ok.
Douglas (22:56)
No queremos que ocurra la típica historia del pastorcito de ovejas que mentía cuando llegaba el lobo.
y entonces todos se alertaban porque creían que el lobo estaba ahí y luego de dos, tres veces resultó que el lobo llegó de verdad y a nadie le quiso creer. sé que todos o la gran mayoría conocen esa historia. Cuando el lobo llegó de verdad no quisieron ayudarlo y pues bueno, él tuvo problemas. Entonces no queremos que eso nos pase con las alertas. Que nos cae la alerta y vamos a ver y no es nada.
Juan (23:14)
Sí.
mmm
Douglas (23:28)
y nos vuelve caer otra alerta, vamos a ver y no era nada. Y entonces llegamos al punto de ignorar la alerta, decir, ah, otra vez la alerta tal, ¿verdad? Cuando llegamos a un punto de ignorar una alerta, eso es peligroso. Eso es peligroso porque entonces cuando llegue el lobo de verdad, cuando de verdad tengamos un problema, vamos a ignorar la alerta.
Entonces, queremos realmente alertar únicamente eventos.
que sean accionables. Yo recuerdo, cuando en este trabajo donde vos y yo nos conocimos, porque ahí por el tiempo en que estuve y la época, logramos implementar muchísimas cosas, ⁓ diferentes conversaciones hemos hablado de diferentes tecnologías o mejoras que hemos hecho, pero una de las cosas en las que participé, de cierta manera, fue en la implementación de un departamento de APM.
Application Performance Monitoring, no, Management, Application Performance Management, creo que era el departamento, que era IPM, y era dedicado a monitoreo, porque antes de ese departamento, el equipo que éramos y satmin, que éramos mayormente dos personas, habían más, pero éramos mayormente dos personas, entre todo lo que hacíamos nos tocaba monitorear, y era pues bien complicado, sobre todo monitorear la parte de la aplicación.
Juan (24:30)
Sí.
Douglas (24:56)
Pero cuando empezó este departamento, pasó a mano de otro equipo y nosotros los sysadmin colaboramos con configurar métricas y otras cosas, alertas, etcétera. Al principio, el vicepresidente de tecnología nos pidió alertar todo. sea, todo, todo evento que ocurriera nos pidió alertar.
y llegó un punto en el que para mí el correo electrónico era inutilizable. Mi bandeja de entrada puso reglas para mover los correos a otro lado, de repente había una alerta nueva que no sabía, no estaba incluida en la alerta, era un caos. Era un caos, o sea...
Juan (25:27)
Sí.
Douglas (25:40)
Yo miraba todo el tiempo mi bandeja de entrada y yo miraba los dashboards llenos de alertas y no me generaba ninguna preocupación y eso luego generó bastantes problemas y tomó un tiempo llegar a un punto óptimo y tomó un tiempo darse cuenta que ese era un error algo en lo que no estuve yo de acuerdo desde el inicio pero bueno la instrucción venía de arriba y cuento esta anécdota porque realmente
no podemos caer en ese punto en el que cae una alerta y sentirme que la puedo ignorar. estoy en esa situación actual, si alguien que no ve y no se escucha está en esa situación necesita hacer algo al respecto de manera urgente,
de manera urgente.
Juan (26:29)
Sí.
Douglas (26:30)
No sé Juan, si te ha tocado experimentar algo similar con respecto a las alertas de estar en situaciones donde alguien, ya sea que no lo recibiste vos, tal vez lo recibió el project manager o alguien, alertados, alarmados por cosas, y resulta que no había necesidad de hacer nada, entonces casi que cada vez en el punto que cuando veas alerta o cuando ve que hay persona viene a decirte que tiene un problema, pues no le crees mucho porque normalmente no sido tan alerta como dicen.
Juan (26:58)
Me ha sucedido y de hecho me sucede en dos aspectos, uno es laboral y el otro es personal. A nivel laboral sí me han llegado, llegan de hecho alertas al Slack y son alertas recurrentes. Lo que sucede es que son alertas más como de una advertencia o como que, hey, está esto, podrías revisarlo. Es como algo puede pasar.
pero como ya sé cómo funciona, ya sé qué es está sucediendo ya la voy ignorando, ya la voy ignorando y sólo les pongo atención si llega a cierto nivel crítico, bueno, para dar un ejemplo más claro tenemos una alerta de cuando nuestro servicio de mensajería de CQRS, mensajes y todos estos eventos que se van disparando
cuando una cola tiene un nivel o un número de mensajes sin acknowledge sin que se hayan consumido nos manda una alerta tenemos un número ya definido nos manda una alerta sin embargo muchas veces llega la alerta y como ya sé qué está pasando la voy ignorando pero
pero bueno hay situaciones donde vemos que llegó la alerta y decía bueno hay 10.000 mensajes ok sé que están esos mensajes aquí porque hace el día de ayer se cayó el servicio pero pasaron las horas y ahora hay 12.000 mensajes 15.000 y vemos que en vez de bajar está subiendo entonces pero ya ya debería estar bien entonces ya ahí entró en acción y empezamos a revisar no pero pero sí pasa que hay otras alertas que
la voy ignorando y si, de hecho es algo que ya que lo mencionas, casualmente he estado estos días como casi casi meditando al respecto de ok que se puede hacer con estas alertas porque siento que las estoy ignorando y pues ese no es el objetivo, el objetivo es que si hay una alerta es por algo y actualmente no tengo una respuesta de qué vamos a hacer con eso pero está pasando y a nivel personal tengo
Douglas (29:10)
y que no que... que no hay que... que... que que... que que... que no que... que... que
Juan (29:21)
me llegan alertas, configure para que las cámaras de alrededor de la casa envíen correos, me envían un correo y también le enviaron un correo a mi esposa. A los dos días mi esposa me dijo estoy harta.
por todo me llega correo de las cámaras porque detectan el movimiento pasa un auto en frente se mueven las mascotas entonces ya ya no aguanto entonces me tocó estarlo configurando pero pues siempre están enviando bastantes correos y estoy tratando de ver cómo cómo llego a lo que mencionaba no a un punto óptimo donde es una alerta de una cámara y pues lo que uno quiere es que si te alerte de que algo
no entonces pero si lo empezamos a ignorar pues ya está perdiendo nuevamente el propósito de esto y pero y si definitivamente es algo bien complicado es algo bien difícil más cuando no tienes claro de cómo llegar a ese punto óptimo o cómo configurarlo directamente no cómo configurarlo bien es difícil
Douglas (30:30)
Sí,
fíjate que bien interesante tu perspectiva y también tus experiencias porque me hace resaltar varias cosas. Uno, y que lo vamos a hablar y discutir un poquito más adelante, que tal vez conoce la diferencia entre notificaciones y alertas, porque también las notificaciones son válidas y las vamos a discutir más adelante.
Juan (30:47)
Mm-hmm. Ok.
Douglas (30:54)
y también las alertas y lo que mencionaba es tanto en tu trabajo esta alerta en la cual no te representa acción
y no saben que hacer, muy probablemente la solución está en una de dos o quitar la alerta por completo porque entonces no es necesaria o ajustar el trigger de la alerta, el número que activa esa alerta a un valor más alto porque tal vez ese valor más bajo ya está ahí. Hay una tercera opción que la voy a mencionar ahorita porque no tenía pensado ahondar en ello y es configurar ese
Juan (31:18)
No
Douglas (31:34)
A veces sabemos que hay diferentes situaciones a ciertas horas. ejemplo, yo sé que de 10 a 11 de la noche corre el backup de la base de datos y eso va a generar un spike en el uso del CPU. Entonces, en mi sistema de monitoreo le digo que durante esa hora ese spike en CPU es normal y que no alerte.
Juan (31:35)
⁓ ok.
Douglas (31:59)
Entonces si tenés ciertos eventos, hace que para ellos los considere como un valor esperado en esa hora, en ese día, y entonces no alerta. Tenés esas tres opciones. La tercera es como que la más compleja, porque toca identificar todo ese tipo de situaciones, pero cuando algo es importante, toca dedicar ese tiempo. Y a nivel personal, lo que decís, yo creo que estás cayendo en esa situación, y nos ha pasado, me pasó a mí también.
Juan (32:09)
Ok.
Douglas (32:29)
no como la petición del vicepresidente de tecnología, el ejemplo que te conté de alertar todo, pero de emocionarme con la idea de que tengo la posibilidad de mandar alertas, ¿verdad? Y si le pones un poquito de mente, Juan, si realmente es algo crítico, el correo no es la mejor opción.
Juan (32:42)
Sí.
Mm-hmm.
Douglas (32:50)
Si realmente
está ocurriendo algo complejo, puede que tardes en ver el correo y ya no vas a poder reaccionar a tiempo. En realidad, te tocaría ajustar las alertas para que lo que realmente sea crítico, recibirlo por otra vía y no por correo electrónico. Pero bueno.
Juan (32:58)
bien punto
De hecho...
De
hecho tenía las dos y me llegaba duplicado o sea que ya era era un caos y así muy como como decís como que me emocioné a poder enviar alertas puedo configurarlo y y me gusta no estar configurando cosas de la casa así que lo puse y pues era un caos ya después le empecé a bajar como lo que mencionabas a ciertas horas en ciertas partes yo ya sé que por ejemplo sé que en mi casa en la parte de atrás
no necesito detectar que pase un vehículo porque por ahí es imposible entonces ya le voy quitando eso y voy configurando los valores de las horas y qué cosas detecta pero bueno aún estoy ajustándolo
Douglas (33:55)
Sí,
me pasó a mí, vos no sabes esto, pero en nuestro sitio, para quienes no saben, Devonops.show, corre en Kubernetes, y agregué ciertas alertas ahí de un controller que yo mismo creé, y me emocioné un poco, y entonces...
Juan (34:01)
Sí.
Douglas (34:14)
ha quedado mandando tantas alertas que ya estoy en el punto que las ignoro. Entonces necesito ajustar eso y ya lleva un par de meses, ha sido cuestión de tiempo. Pero lo menciono porque todos caemos en eso. Me emocioné mucho porque yo mismo creé el controlador en Kubernetes y ahora estoy en esa situación. Pero bien, Juan, si te parece para avanzar, entonces... ⁓
Juan (34:30)
Sí.
Mm-hmm.
Douglas (34:39)
quisiera que hablemos cómo podemos lograr eso, eso de que las alertas sean todas accionables, ¿verdad? Es para cómo lograr que si me cae una alerta, tener esa sensación de urgencia, acorde a la severidad, ¿no? Ya lo mencioné antes que a veces...
Juan (34:45)
Ok.
Douglas (34:56)
puede que necesite actuar inmediatamente o puede que necesite o puede que me deje esperar un tiempo, ¿no? Pero ¿cómo lograr eso? Que si cae una alerta, debo de prestar la atención y sentir ese sentido de urgencia y para ello es que las alertas deben de ser basadas en el comportamiento o eventos relevantes para la aplicación y sus servicios y no en métricas individuales. Te voy a dar un ejemplo, te voy a dar un ejemplo.
Juan (35:19)
No,
Ok.
Douglas (35:25)
si voy al doctor porque tengo... tengo tos, ¿verdad? Estoy con tos. Cuando yo llego le cuento todos los síntomas, los síntomas que creo que considero que son relevantes para mi problema.
Entonces le voy a decir, no, empecé hace tres días, estoy haciendo bastante, sentía como comezón en la garganta y entonces tal vez yo le puedo decir, ay sentía digamos picazón, comezón en el oído, ¿verdad? No sé, por si alguien aquí en nuestra región decimos picazón, pero tal vez si en alguna región también se le llama comezón, ¿verdad? En el oído, porque tal vez yo creo que es relevante, ¿verdad?
Juan (36:04)
Sí.
Douglas (36:10)
Pero entonces viene el doctor en base a su experiencia, lo que él está escuchando, va a hacer preguntas que considera relevante a lo que parece que va. De repente puede preguntarme, ⁓ porque yo no lo dije tal vez, él puede preguntarme, pero le dolía la garganta, ha tenido dolor de cabeza, etc. Y en base a eso él hace su diagnóstico.
Y tal vez resulta que la picazón o comensón del oído pues solo era que tenía que limpiarme bien los oídos y no era nada relacionado, pero yo sí lo creía. el doctor basado en los síntomas importantes, acorde a lo que podía tener, él preguntó y logró determinar qué es lo que tenía. Entonces, justo eso ocurre con nuestros sistemas.
momento de alertar. Tienen que ser cosas que sean síntomas importantes o relevantes para la aplicación y su funcionamiento y no cosas aisladas, verdad. Entonces en ese sentido tal vez como un par de ejemplos y tips para las personas que nos ven y nos escuchan, que puede ser mira uno en lugar de alertar
Juan (37:20)
Ok, ok, parece bien.
Douglas (37:25)
el uso de CPU, digamos que el CPU está arriba del 90 % el uso, ¿verdad? Podemos alertar el load average, que para quienes no sepan de manera sencilla, el load average te da la métrica de cuántos CPUs está utilizando tu servidor. Y si tenés un servidor con cuatro CPUs, entonces podés tener un load average de hasta cuatro.
y tu CPU está bien, está al máximo. Puede que no llegue a 4 y la forma en cómo el sistema calcula el uso total del CPU puede que tengas el load average en 2 pero que el uso total del CPU te parezca mucho más alto que el 50 % por cómo lo calcula. Al final del día el CPU está para ser utilizado.
siempre queremos mantener el CPU o cualquier recurso más o menos como a un 80 % de utilización darle un 20 % a los recursos para que pueda estirarse en caso de un spike, un incremento, una eventualidad, verdad, pero si el servidor utiliza el 100 % del CPU pues para eso está, no necesito alertar muchas veces eso, pero si el low average
Juan (38:40)
jajaja
Douglas (38:44)
pasa de cuatro, un ejemplo en el que tenga un servidor con cuatro CPUs, de repente ahí si quiero saberlo, si ya lleva dos, tres, cinco minutos ahí que me alerte. Lo mismo pasa con la memoria, ejemplo. En lugar de alertar que la memoria superó el 90%, podemos alertar si el servidor...
Juan (38:51)
Mhmm.
Douglas (39:05)
está comenzando a paginar para quienes no sepan pues ya sabemos que la memoria RAM es la memoria volátil que es donde el sistema operativo almacena información de manera temporal y la accesa ahí super rápido y eso vuelve que tu sistema se haga rápido pero cuando se queda sin memoria el sistema operativo comienza a comienza a escribir de manera temporal en el disco duro pero el disco duro está hecho para
a un almacenamiento más permanente entonces ahí el sistema se comienza a poner lento porque está comenzando a guardar en disco duro información que está destinada a estar en memoria RAM. Ahí es un problema. La partición swap, la partición swap en Linux, correcto. Entonces ahí comienza a ser un problema si mi sistema está paginando pero si por algún momento el sistema está en 95, 99 % o 100 % de memoria mientras no comience a paginar
Juan (39:43)
que es la partición swap en Linux
Douglas (40:02)
y mientras la aplicación está funcionando bien, no tengo por qué preocuparme. Si justo por eso le estamos dejando ese 20 % extra, ¿verdad? tratamos de darle recursos para que siempre use constantemente, no más de un 80%, pero ese otro 20 % justo para eso está. Entonces, ¿por qué se lo voy a dar ese 20 % extra, que son recursos que estás pagando, para que si lo supera, querer irme a conectar y reiniciar servicios o levantar más réplicas?
si para eso estaba, entonces una forma más efectiva sería de repente mejor monitorear la paginación porque si el sistema está paginando ahí si tengo que hacer algo al respecto, ahí si es una alerta accionable, verdad.
Juan (40:34)
Sí.
y me imagino
que también tiene que ver por cuanto tiempo está sucediendo porque igual requeriría revisarlo si está paginando pero si sólo sucedió por medio minuto o sea tuvo un spike grandísimo pero luego se tranquilizó pues no sería algo tan crítico probablemente sería más como una advertencia
Douglas (41:12)
Sí, por eso te decía
tal vez con el CPU, si está arriba del load average del número de CPUs, después de un tiempo. sea, vos definís, dependiendo de la aplicación que tenés y el servicio que corre, etcétera, si después de dos minutos, después de cinco minutos, después de diez minutos, mantiene el load average arriba, hay que alerte. En cuestión de la paginación...
Juan (41:20)
después de... ok
No,
Douglas (41:39)
Lo que yo he experimentado y otras personas que trabajan con infraestructura es que por alguna razón, sobre todo cuando es base de datos, cuando un servidor comienza a paginar, no quiere soltar la paginación, entonces toca como que reaccionar. En mi experiencia, si por un minuto el servidor está paginando, yo sueldo o alertar.
Juan (41:51)
Ok.
Douglas (42:00)
lo máximo que luego solo dejar son dos minutos, pero casi que una vez que empezó a paginar, ya se vuelve, entra como en un ciclo donde ya opera lento, entonces se mantiene como que retrasado siempre porque está escribiendo en disc, en lugar de escribir en como era RAM. Sí.
Juan (42:16)
entra en un ciclo vicioso, porque está paginando
se vuelve lento y porque está lento empieza a paginar
Douglas (42:22)
Ahí está, lo dijiste
es tal cual y mayormente con servidores de bases de datos que son los que mayormente entran a paginar. sí, es verdad, pero ya eso va un poquito más ligado a mi experiencia pero tenés razón en lo que decís, le das un tiempo y eso se define y lo vamos a hablar un poquito más a detalle adelante, pero se define en base a la aplicación, el tipo de servicio que estoy corriendo, cuando va a acceder eso.
Juan (42:50)
eso
es lo que te iba mencionar porque bueno ya que estaba mencionando que en teoría no hay problema si estamos utilizando el 80 % del CPU pero si yo ya sé que mi aplicación por ejemplo es muy simple es 3-4 endpoints y se conectan a la base de datos obtienen la información y la devuelven en teoría no debería utilizar tanto CPU así que si veo que está utilizando más es como no debería entonces ya ahí sí podríamos alertar para ese tipo de aplicaciones
específico.
Douglas (43:22)
Sí, ahí
se volvería una situación en la que o notificó en lugar de alertar, notificó para que quedó un registro o entonces, mira, le doy menos recursos. Si vos tenés un sistema, tenés un servidor, una instancia.
y normalmente esto pasa fuera de contenedores aunque puede ser un clóster de Kubernetes y que tenés nodos a x cantidad de CPU pero si vos tenés un servicio o algo corriendo y solo va a utilizar el 40 % del CPU aún en tráfico alto vos estás gastando dinero está gastando dinero no deberías de tener esa cantidad de recursos para un servicio que no está utilizando
y si vos te vas a alertar porque llegó al 80 % y si tu aplicación para eso es crítico, es válido, yo no estoy quitándole la validez a la aplicación que estarás manejando, pero eso lo estoy diciendo, deberíamos de buscar que la aplicación en un uso normal consuma un aproximado del 80 % de los recursos.
Esto va a variar por aplicación de nuevo, no es un número fijo. Si vos tenés una aplicación que tiene tráfico idealmente se configura autoscaling, tráfico alto en ciertas horas, perdón, idealmente se configura autoscaling, autoescalamiento, para que cuando venga el tráfico, agregue más instancias o más pods.
Juan (44:46)
jajaja
Douglas (44:54)
y no estés desperdiciando recursos, idealmente eso es, pero si no tenés esa posibilidad y solo tenés x cantidad de servidores que están ahí permanentes, si tenés horas altas o horas de mayor tráfico, vos buscas que esas horas altas consuman un aproximado del 80 % y tal vez la mitad del tiempo va estar en un 40, pero cuando llegan las horas altas llega un 80 y siempre tenés ese 20 % aproximado para un inesperado.
incremento en tráfico, un proceso que tal vez se puso más lento, se trabó y tomó más tiempo terminar, etc. Entonces esto es como lo que tomar en cuenta al momento de definir cuántos recursos va a usar tu servicio, tu aplicación. Entonces si vos tenés ese escenario...
Juan (45:41)
eso
perdón que te interrumpa Douglas pero creo que lo que estás hablando es muy interesante creo que nunca lo había visto desde ese punto de vista Douglas el hecho de ok acomodar los recursos de acuerdo a lo que necesita y bueno en general uno sabe que tiene que tener los recursos de acuerdo a lo que uno ocupa pero normalmente creo que yo he tenido la idea de ponerle
que no utilice tanto CPU, no utilice tanto RAM eso significaría que está bien que está bien configurado y se me viene a la mente como el tratar de utilizar una o ir a un hotel y alquilar una habitación con dos camas matrimoniales y un camarote y solo estoy yo es como para qué tanto si podría tener la otra habitación donde solo tengo una cama y estoy bien creo que eso está
⁓
creo que es algo que no se menciona mucho, al menos en mi caso te diré que creo que me has abierto los ojos en ese aspecto, me gusta mucho esa aclaración que acabas de dar.
Douglas (46:54)
Sí, y a veces Juan,
utilizar recursos, veces va, siguiendo el ejemplo que dices del hotel, a veces va fuera del cuarto, a veces gente no quiere reservar un hotel porque no tiene piscina y no tiene planes de usar la piscina.
¿por qué le van a afectar eso? A veces queremos que la aplicación corra en diferentes regiones y cosas así y pues no lo vamos a utilizar. Lo mismo aplica aquí. Si vos te preocupas porque tu código sea óptimo y ocupe la menor cantidad de recursos, eso es la mentalidad correcta. Pero eso se complementa entonces poniéndolo a correr en instancias con menos recursos.
Juan (47:17)
región ⁓
Sí.
Douglas (47:38)
de lo contrario el esfuerzo que le dedicaste a que tu aplicación sea óptima y consuma esos menos recursos termina quedando en nada porque van a seguir pagando por instancias más caras, verdad, no sé si me explico en ese sentido, entonces...
Juan (47:38)
Sí.
Sí.
Y en Kubernetes también te permite
ajustar esos valores de que este contenedor solo tiene tanto de RAM, tanto de CPU, ahí se va complementando.
Douglas (48:01)
Sí,
lo puedes hacer de esa manera, lo puedes hacer en base a la escalabilidad, ya sea de nodos o de las réplicas de los pods, también lo haces en Kubernetes. De hecho, actualmente nosotros, donde yo trabajo en Field, ahora llamado Field, antes llamado Tenop, estamos actualmente migrando los Cluster de Kubernetes de Cluster AeroScaler, que es un servicio que agrega más nodos.
cuando los vas utilizando, estamos migrando a un autoscaler que se llama Carpenter, que es más inteligente, te permite agregar Spot Instances en lugar de Instances on Demand, si así lo querés, y él está ajustando los nodos en base a recursos porque los node pools comunes en AWS, vos le decís qué tipo de instancias crees que agreguen y si son instancias de 8 GB de RAM...
si ocupas un giga de RAM más, él te va a agregar otra instancia de 8 y quedas con 7 gigas ahí haciendo nada. Carpenter, él le agarra un rango de instancias y él puede agregar solo una instancia con los recursos necesarios y es muchísimo más inteligente en ir agregando y quitando instancias que no están siendo utilizadas.
para ajustar el cluster mucho más inteligente que el cluster autoscaler que tiene AWS. Entonces justo para esto de la utilización de los servicios. Y me gusta que toque el tema porque si está relacionado con las alertas. Es lo que decíamos. Si estás preocupado por una alerta del CPU en 80 % ⁓
Juan (49:36)
Sí.
Douglas (49:42)
quiere decir que tenés mal asignado sus recursos. Si esa es tu solución momentánea mientras corregís los recursos, bien. crea la alerta porque la alerta te va servir. Va ser una alerta accionable para vos. Pero ahí tenés otro problema un poco más serio con recursos y que implica el bolsillo de tu equipo, de tu empresa o tuyo si es una aplicación tuya. Entonces, toca corregir los recursos. Recordemos que asignamos los recursos para que los pueda utilizar.
la aplicación, verdad, para eso lo asignamos si va a necesitar más y ya no va a poder escalar por sí sola, ese es el momento en que necesito yo saberlo, verdad, o también puede ser una forma que me abierta si está creciendo de manera alocada.
Juan (50:13)
Ok, sí.
Douglas (50:31)
verdad, si creció mucho, entonces tal vez hay un memory leak o algo que está generando que se cree en más instancias y también quiero saberlo, pero volviendo a los tips o a los consejos de cómo configurar alertas que sean accionables para mí, monitoreamos mejor la paginación y no la memoria.
Juan (50:37)
Sí.
Mm-hmm.
Douglas (50:55)
Y continuando en esa línea de consejos, otro puede ser, tal vez si tenemos un servidor de base de datos, los servidores de base de datos suelen ser altos en CPU, en utilización de CPU porque están escribiendo en disco duro. Y pues para que no tengan tanta experiencia con sistema operativo, lectura y escritura en disco duro, también trabaja el CPU.
si el CPU está alto es porque suele haber bastante lectura y escritura en el disco duro y a veces puede ser que necesitemos un disco duro más rápido y nos toca ver cómo están los filesystem y la lectura y escritura en el disco duro. Pero en un servidor de base de datos, justo por eso, en lugar de tal vez monitorear el CPU, la utilización del CPU, podemos monitorear la cantidad de conexiones a la base de datos y si esa cantidad de conexiones ha subido...
a X número, verdad, porque de nuevo el CPU está ahí para que lo use la base de datos, por eso se lo dimos, pero si tenemos, si nuestra aplicación está, no sé, tiene un promedio de 80 conexiones por minuto, digamos, 50 conexiones por minuto y de repente tenemos, si de 50, de repente tenemos 100, 120 y ya lleva tres minutos, cinco minutos así, ya eso es algo que me alerte, no es normal.
No es común que está pasando. Entonces ya eso es una alerta que sí tengo que accionar. Ya eso es atípico, eso no es común. Tengo que mínimo investigar porque aunque al final de la investigación vea y diga, no, es normal. Hicieron tal promoción, tal cosa, más tráfico. está bien, es normal. Pero como no es típico me lleva a investigar.
Pero si solo pongo alertas de CPU alto, cada vez que investigue, normalmente no voy a encontrar nada y puedo caer en el riesgo de ignorar alertas, ¿verdad? Pero de nuevo, si es un tráfico real, pero si de 50 conexiones por minuto pasa a 100-120, algo voy a encontrar, aunque sea normal, ¿verdad? Otro consejo que puedo dar ahí, Juan, es, tal vez en tu aplicación, en lugar de alertar si hubo un timeout,
Juan (53:04)
Sí.
Douglas (53:11)
alertemos si hubo x cantidad de timeouts en un rango de 5 o 10 minutos, verdad, y esto va a depender del SLO o Service Level Objective que yo define, verdad, y para quienes no recuerdan quién es un SLO, lo mencioné y lo expliqué en el episodio donde hablamos las funcionalidades de los SRE, verdad.
Pero un SLO, un Service Level Objective, es básicamente un valor esperado para una métrica en particular de la aplicación. ejemplo, un valor sería los timeouts de tu aplicación, tres timeouts en un minuto, aceptable.
normal entonces ese sería un SLO que el valor de la cantidad de tramos en un minuto 3 está bien o 5 está bien verdad y el SLA, Service Level Agreement es que qué valor ese valor puede ser tiempo por centaje etcétera pero qué valor puede exceder o puede estar en rojo esa métrica es el SLO. Sí o sea nosotros podemos decir que
Juan (54:18)
como una excepción.
Douglas (54:24)
5 timeouts por minuto es aceptable para tu aplicación para xnpoint, ese es un SLA, pero el SLA dice que puede haber 5 minutos con más de 5 timeouts por minuto y hasta ahí está bien, a partir del sexto minuto ya es que hay algo crítico.
Juan (54:47)
es como el threshold de lo que podés soportar.
Douglas (54:50)
es el threshold de lo que es aceptable para tu aplicación. Esos son los SLO y SLAs. Y por eso se habló bastante de eso. O se habló algo al respecto cuando discutimos lo de... Cuando hablé yo sobre las funcionalidades de SRE. Porque las alertas es parte de su funcionalidad y son basadas en ello. Entonces de nuevo, en lugar de alertar porque hay un timeout...
Juan (54:52)
ok
Douglas (55:14)
Entonces si hay un timeout y me conecto y miro, hay un timeout. Y cuando va a volver a haber otro, no hay ninguno. ¿Por qué fue ese timeout? No, sé. Tal vez estaba lento del lado del cliente o el cliente le dio click, pero luego cerró el navegador. O sea, pueden haber tantas cosas para un timeout, Pero si hay...
Juan (55:25)
Sí.
si no vale la pena investigar
tanto en ese momento. Sí, sí.
Douglas (55:36)
o nada, o nada por
un time out, pero si el SLO dice que 5 time outs por minuto está bien y estoy teniendo 20, estoy teniendo 30, ahí hay algo, ahí ya me toca investigar, me toca investigar qué está pasando, ahí si ya voy a algo voy a encontrar de nuevo, aunque lo que encuentre significa que hay un tráfico real, ¿verdad?
pero algo voy a encontrar. Normalmente va a ser algo no tan amigable. Tal vez como que tal un bot le está haciendo, está queriendo tocar tu sitio o en ese momento está haciendo un crawler Google o la inteligencia artificial, lo que sea. Pero algo vas a encontrar que toca accionar a ello, ¿verdad?
Juan (56:19)
O sea, que
capto entonces Douglas es es lo ideal, lo... ¿cómo decirlo? Es buena idea evitar enviar alertas por notificaciones o métricas puntuales, sino más bien crear escenarios y en base a esos escenarios hay que alertar algo, ¿no? No es alertar porque hubo un time out o dos time outs, sino definir qué escenario, qué situación en la que
amerita mandar esa alerta. Creo que tal vez ese podría ser como el consejo más genérico, el evitar enviar alertas así porque sí, sino definir un escenario.
Douglas (57:06)
Exacto,
eso tal vez comencé Juan con el ejemplo de cuando vas al médico y vos le contás las cosas que crees que son relevantes para lo que tenés, pero en la mayoría de los casos el dolor en los pies que has tenido no tiene nada que ver con la tos por la cual fuiste a consulta. Entonces, lo mismo, son escenarios, por eso es, la métrica tiene que ser en base a eventos relevantes para la aplicación y no métricas aisladas.
Juan (57:10)
Sí, sí,
Douglas (57:36)
muchas alertas pueden terminar siendo triggeriadas o activadas por una sola métrica, pero que es una métrica relevante para tu aplicación o tu servicio, verdad. Y de nuevo, tengo que ser inteligente, por eso no es el uso del CPU lo que más me importa en la gran mayoría de los casos.
porque para eso tengo el CPU, sino el load hours, una base de datos, la cantidad de conexiones, ¿verdad? No es el uso de la memoria en el web server, sino los timeouts, pero ¿cuántos timeouts? No un timeout, ¿verdad? Y tal vez aquí tengo un consejo más que sería, en lugar de alertar si un pod o un servicio se reinicia una vez,
alertamos si se reinicia x cantidad de veces en un lapso de 5 o 10 minutos de nuevo acorde al SLO y los SLAs porque una vez se puede reiniciar por cualquier situación, cualquier circunstancia pero si se reinicia varias veces ahí algo ocurre y entonces esa es una alerta de nuevo y eso es que hay tener en mente Juan que la alerta me tiene que llevar a accionar
idealmente a tiempo, verdad, o sea, vamos a tener alertas de cuando todo esté caído, hay que tener esas alertas de que si todo está caído que llame y que haga todo lo que tiene que hacer, pero tenés otras alertas accionables con la intención de evitarlo, con la intención de lograr llegar a tiempo y hacer algo, pero si empezamos a alertar...
Juan (59:03)
Sí.
Douglas (59:15)
el uso de memoria, el uso de CPU, que hubo un timeout, que hay más logs, si empezamos a alertar ese tipo de cosas nos vamos a topar con la situación de comenzar a ignorar alertas y esa es la métrica nuestra para ver si está bien, esa es nuestra métrica. Si hay alertas que me siento confiado de ignorar, algo no está bien, algo no está bien, ¿verdad?
Juan (59:42)
Sí.
Douglas (59:44)
tienen que ser síntomas que requieran nuestra atención.
Douglas (59:49)
entonces con esto en mente como vos ves esto? no sé si has tenido algunos ejemplos vos de tu lado de alertas
basadas de configurar alertas basadas en el comportamiento de la aplicación. Lo que nos compartías al inicio de esta experiencia tuya de troubleshooting situaciones y ver estos dashboard diferentes métricas y toparte con que te das cuenta que faltaba algo y ahora incluso hasta estás acostumbrado a por defecto dejar logs en la aplicación por cosas del pasado. Son es esto mismo que hemos hablado pero tal vez no
sin tenerlo en mente, la idea clara al respecto. Entonces, no sé si has tenido ejemplos o ideas o crees que hay algo más que agregar respecto a saber configurar la alerta basada en el comportamiento de la aplicación y no alertar por alertar cualquier evento.
Juan (1:00:49)
Bueno, te seré muy honesto, lamentablemente no he tenido tanta experiencia en configurar alertas, ¿no? Porque una alerta es algo que se envía ya sea a mí o a un grupo de personas, ¿no? En ese aspecto no, sin embargo sí trato de crear mucha, generar información que me permita en un dado caso lanzar estas alertas. Cuando tenés sistemas que están tan desagradables
se
han descentralizado con los microservicios y el procesamiento de ciertos datos no sucede en una sola instancia o en un solo servicio, sino que se distribuyen diferentes partes. Es muy importante tener diferentes, mínimo creo yo, diferentes dashboards que te permitan saber qué está pasando. A veces, y esto es lo que más me sucede a mi Douglas, no tanto con las alertas que de hecho es algo que lo he pensado.
y todavía no he accionado al respecto. refiero a... lo he pensado en agregar alertas ya sea por Slack o por correo, pero no lo he hecho todavía, sin embargo tengo diferentes dashboards que me ayudan a identificar lo que está sucediendo en la aplicación. Como para dar un ejemplo así muy por encima o para tener una idea más clara, tenemos ciertos procesos.
que inician en un contenedor, en un servicio, luego este servicio llama a otro, este otro a su vez llama a otra instancia de una base de datos, una base de datos de vectores y hace ciertas búsquedas, entonces ya en ese punto ya hemos tocado tres instancias diferentes de diferentes aplicaciones, así que es muy necesario tener una idea de
Ok, ¿cuánto se tardó la petición de este lado a este lado? ¿Cuánto se tardó de aquí para allá? Hay algunas peticiones que tardan mucho, pero ¿cuántas de esas es el average? Entonces tenemos dashboards donde me permite ver donde me permite ver que la mayoría está en un nivel aceptable, lo que mencionabas, Del SLO, SLA, que no tenía claro esos conceptos cuando...
empezamos a hacer esto pero pues fue más como por instinto creo el hecho de bueno tenemos varios request que están por arriba de los 60 segundos pero pues en el gran esquema la visualización total no son tantos así que tengo la información como para decidir en qué momentos lanzar los alertas sin embargo todavía me falta dar ese
paso o bueno nos falta como equipo de trabajo configurar esa parte todavía no la tenemos como lo que mencionaba no está dentro de mi responsabilidad sin embargo también creo que es importante que los developers tengamos una idea porque al final del día vamos a poner que se lanza una alerta y probablemente la primera persona que lo revisa o que está pendiente sea el sri
pero muchas veces quien tiene que revisar
específicamente la parte del código es el developer así que sería mejor que el developer también tenga claro qué alertas existen y cómo están configuradas para que sepamos no reaccionar a estas sin embargo me ha pasado que veo algunas alertas y aparece tiempo de respuesta tal y me da diferente información pero no sé qué me está alertando no está claro no así que me toca preguntar me toca saber
Douglas (1:04:47)
Mm-hmm.
Juan (1:04:51)
empezar como a indagar y esto porque está aquí
Así que si es necesario que uno como developer también se involucre en estas cosas. En el lado de backend como que sucede un poco más. No sé si estoy sesgado, creo que sucede más en backend, pero también puede también ese frontend se puede hacer, no es totalmente válido. Eso aplica para todos. Pero pero bueno, si mi mi acercamiento con configurar alertas aún ha sido muy poco, pero como te digo, siempre tengo en mente
Douglas (1:05:11)
Sí. Sí.
Juan (1:05:25)
el hecho de tratar de dejar la información necesaria para que se puedan generar estas alertas o notificaciones que todavía no me queda claro la distinción entre las entre las dos pero siempre trato de tener eso en mente ¿no? ¿qué partes de la aplicación, como te decía al inicio, hay partes de la aplicación que me importan un poco más que las otras hay información que me importa un poquito más en diferentes situaciones
también como developers, pues el tip que les puedo dar es el hecho de tener muy claro qué categoría de logs podemos dejar, ya que podemos dejar logs de diferentes niveles, de diferentes severidades, ya sea de error, de debug, de información, advertencia, warning. Hay diferentes niveles y eso nos ayuda a luego crear estos dashboards, tirar alertas, etcétera, etcétera.
Douglas (1:06:24)
Sí, sí, fíjate que bueno, con respecto a lo que dijiste de diferencia entre notificación y alerta, lo vamos a hablar un poquito más adelante y lo vamos a procurar aclarar. Con respecto a lo de las configuraciones de las alertas, y tal vez expresé mal mi pregunta, porque en efecto sé que no es común que un developer tenga que configurar alertas.
Juan (1:06:32)
Mmm, ok.
Douglas (1:06:45)
aunque se da, hay equipos que los SRE empoderan a los programadores a que configuren sus propias alertas y sus propios dashboards, lo que sí, la colaboración que es más común entre sistemas o SRE y desarrollo, es que los programadores generen las métricas de la aplicación para que luego se puedan, para que luego SRE o sysadmin...
puedan configurar estas alertas y en esa línea, no sé si alguna vez te han pedido el request de configurar métricas un poco raras, entre comillas, métricas raras para alertas raras, no sé si te ha tocado algo por el estilo.
Juan (1:07:30)
No se me viene una a la mente para ser honesto, no. O tal vez en su momento no lo vi raro, no sé. No recuerdo.
Douglas (1:07:35)
Sí, si no te dijeron por qué, fíjate
que yo he recibido tantas cosas, tantas peticiones raras, hubo, recuerdo cuando recién trabajábamos con contenedores y ahí trabajábamos, vos desarrollabas parte del código, cuando se hacía eso, una petición que me dieron para las alertas era incluir el nombre del contenedor porque corriamos en Dockers Farm, el nombre del contenedor que generó el error.
porque las personas que trabajaban en la parte de aplicación y esto no habían logrado, como se dice en inglés, su mente no había logrado abrazar el concepto de contenedores y para ellos estaba acostumbrado a trabajar con máquinas virtuales y pues se quería, con una máquina virtual se maneja un poquito más como el concepto de mascote y ganado, ¿verdad? De ver que, esta máquina virtual me está dando un error.
la voy a sacar del clúster y voy a ver qué está pasando. yo trate de explicar, sí, ese es un concepto de que de hecho con máquinas virtuales se aplica también. Nuestras máquinas virtuales deberían de ser manejadas como ganado y no como mascota. De manera que si la máquina virtual tiene un problema se destruye y tu sistema de AuroSkelling crearía una nueva.
Juan (1:08:35)
Encarnado. Sí.
Douglas (1:08:53)
con contenedores pasa lo mismo solo que es más rápido pero en efecto me pedían poner el nombre del contenedor en el error porque querían saber cuál contenedores y yo tratando de explicar bueno pero al momento que querrá ir al contenedor ya no va a estar
Juan (1:09:05)
Ok.
existen.
Douglas (1:09:10)
no
vas a hacer de que lo vas a sacar del clóset, el Docker Swarm va a crear un nuevo contenedor, los logs de la aplicación que ese contenedor creó, nosotros usábamos Splunk en ese momento, van a estar en Splunk, despreocupate. Entonces, yo sí he recibido peticiones raras de qué cosas alertar.
Juan (1:09:30)
recuerdo un poco ese tema del nombre de los contenedores sí pero pero pero bueno
Douglas (1:09:34)
¿Verdad que sí? Sí.
Juan (1:09:38)
era era entendible no como que estaban transicionando todo el mundo hacia eso en mi caso fue un poco más fácil transicionar como como cambiar mi mentalidad porque como que yo entré de un solo a ese en cambio los demás como que su mente estaba muy amoldada a lo otro a las máquinas virtuales y todo eso
Douglas (1:09:59)
Sí, sí estamos hablando,
claro, estamos hablando de un equipo, este es mismo equipo, Juan, que pidió alertar todo al principio, ¿verdad? Entonces, yo creo que por ahí, por ahí te puedo hacer la idea. Igual de mi parte, a medida iba creciendo, me topé con que yo mismo tenía conceptos erróneos alrededor de las alertas y a base de la experiencia ha ido mejorando.
Continuando en esa línea de cómo deben de configurarse alertas efectivas, otra cosa que me gustaría discutir, Juan, es que las alertas no deben de ser las mismas para todas las aplicaciones o servicios, como que la misma alerta para todos. No hay una misma vara que mide a todos los servidores o una misma vara que mide a todos los servicios.
Juan (1:10:38)
Mm-mm.
Douglas (1:10:48)
si tenemos un servicio que tiene digamos un par de llamados por minuto tiene que no sé si dos llamados por minuto algo así verdad entonces tener 10 timeouts en cinco minutos puede ser un síntoma serio porque si recibe un par de de recues por minuto y si en cinco minutos hay 10 quiere decir que casi que la mayoría de recues dieron timeout entonces ahí
Juan (1:10:59)
Sí, sí, sí.
de por sí recibe poquito
y las que recibe dan timeout.
Douglas (1:11:19)
esa
es la precisión que te haces, ahí hay algo. Pero si quiero aplicar lo mismo, digamos, a un endpoint de autenticación que recibe 50 llamados por minuto, ¿verdad? Y de esos 50 llamados por minuto, tengo 10 timeouts en 5 minutos, probablemente no sea relevante, la misma métrica no me sirve, ¿verdad?
10 de repente no es un porcentaje todavía que me haga preocuparme. Entonces no podemos solo venir y hacer lo mismo o venir y decir un servidor de base de datos, por ejemplo, va utilizar mucho más CPU que lo que va a usar un servidor que maneja un servicio de cache, por ejemplo, como Redis o Memcache. Entonces no puedo poner las mismas métricas de alertar en base a CPU en los dos o de alertar en base a memoria en los dos.
porque ya dijimos de que los recursos están para ser utilizados, pero como explique la lectura del disco duro genera mayor CPU, la misma vara no va a medir a estos dos tipos de servicios, no puedo salir con una idea de a todo servidor ponerle de nuevo de que la 80 % de CPU que alerte, de hecho fíjate que como las alertas se tienen que configurar de manera inteligente,
de manera personalizada para cada aplicación y servicio, nosotros tenemos ciertos sitios de WordPress que tienen algo que le llamamos un job server.
Juan (1:12:52)
Ajá.
Douglas (1:12:55)
que suele correr en un auto scaling group de una sola instancia y si la instancia cae el auto scaling group le va a crear otra instancia esto es para lo que corre fuera de Kubernetes este job server normalmente estamos hablando de editoriales que tienen 80, 90, 100, 120 sitios
diferentes sitios de sí, no es cierto, sitios obviamente de contenido, de noticias y algunos son de gaming, otros son de sports, de deportes, otros son de entretenimiento, otros son de celebridades, etcétera, entonces, pero hay cierto...
Juan (1:13:36)
por curiosidad
nada más, pertenecen al mismo dominio o son diferentes dominios? ⁓
Douglas (1:13:41)
diferentes dominios, diferentes dominios por
completo, pero WordPress tiene algo que corre como multi sitio, la misma instalación de WordPress corre con multi sitio y te permite usar el mismo tema, pero personalizado para cada uno de los sitios y trata en las partes en las que querés, todos los sitios le aplica lo mismo y en la parte que querés por sitio es personalizado, ¿verdad?
Juan (1:14:00)
Mm-hmm.
Ok
Douglas (1:14:10)
Pero una de esas cosas es que a veces el contenido, un post, una noticia puede aplicar a diferentes funcionalidades. Por ejemplo, tenés una noticia con Cristiano Ronaldo. Esa noticia encaja en las páginas de deportes, pero también encaja en las páginas de farándula.
Juan (1:14:26)
ok
Douglas (1:14:36)
porque ya Cristiano Ronaldo es una personalidad, una celebridad y si tal vez la noticia es de los NFT que lanzó Cristiano Ronaldo con Binance también te encaja en la parte de finanzas, la misma noticia o de cryptocurrencies, ¿verdad? el Bitcoin, sí, o los NFT que lanzó con Binance, Para los que sepan de...
Juan (1:14:37)
celebridades.
Sí.
bicho coin.
Sí.
Douglas (1:15:00)
de cualquier manera estoy ejemplificando. Entonces, ¿qué ocurre? Esa noticia la subió el que está encargado de la parte de deportes, pero le pone ciertas etiquetas que encajan todo esto que te dije. Entonces, ocurren procesos de sindicación de contenido que el contenido de ese sitio lo va a replicar a todos los sitios relacionados con deporte, a todos los sitios relacionados con farándula, a todos los sitios relacionados con finanzas,
era el de NFT, etcétera. esos job servers están constantemente sindicando, Entonces tenemos la misma situación que te mencioné antes. Normalmente están usando un 80 % de CPU, no que es la métrica más importante, pero mira como en este caso en particular si es importante. Cuando hay poquito tráfico y poquita cosa baja a un 60%.
Juan (1:15:32)
Ok
Douglas (1:15:59)
la utilización. Pero ¿qué ocurre? Tenemos una alerta que si la utilización está abajo del 50 % por más de cinco minutos
quiere decir que algo está ocurriendo porque ese servidor tiene que estar trabajando todo el tiempo son editoriales de 80 sitios para arriba y tiene que estar trabajando todo el tiempo porque va a estar utilizando menos del 50 % del CPU en ese caso en particular Juan la utilización del CPU se vuelve una métrica importante para el ecosistema y para las formas que funcionan las aplicaciones
Juan (1:16:27)
Sí.
Douglas (1:16:37)
pero de manera irónica probablemente se vuelve una métrica importante pero cuando es muy bajo en lugar de cuando es muy alto y el haber configurado esa alerta nos ha permitido encontrar errores antes de que se vuelvan grandes
porque tal vez hay algo que quedó pegado o tal vez se desconectó de la base de datos y no nos dimos cuenta y el ver que está trabajando poco nos hace verlo, ¿verdad? Pero esto es prueba, de que en la misma métrica no le sirve a todos.
Juan (1:17:09)
Sí, correcto.
Douglas (1:17:09)
no es la misma métrica
para todos y tenés que ser inteligente, tenés que ser creativo para configurar alertas acorde a lo que necesitas. Por eso no ignoramos por completo que exista una métrica de memoria, que existe una métrica de CPU, porque en algunos casos va ser importante y lo vas a poder...
utilizar pues,
Douglas (1:17:31)
Entonces, Juan, no sé si te ha tocado experimentar esto de tener las mismas métricas para diferentes tipos de aplicaciones. Vos nos mencionabas cómo te has acostumbrado ya sin pensarlo a dejar ciertos logs, ciertas métricas por experiencias del pasado. No sé si te has puesto a pensar y no sé si te pasa, pero por eso va la pregunta, Si en todo tipo de aplicación que estás haciendo es relevante esas métricas que estás dejando ahí o no.
Juan (1:17:49)
Sí.
Douglas (1:18:01)
o si te has topado en eso, te han pedido que se agregue una cierta métrica para una aplicación que parece que no tiene relevancia.
Juan (1:18:12)
Bueno, ha pasado que yo he pensado que ciertos logs me van a ayudar a algo, a algo...
y al final termino no utilizándolos así que lo que hago es que a veces los quito y a veces pues no pero bueno lo que mencionabas de a veces es revisar que si algo está utilizando menos recursos es una métrica también he tenido cierta experiencia con eso porque también tenemos unos servicios que como mencionabas están corriendo constantemente y lo ideal
que siempre estén procesando archivos de audio entonces los están procesando y pues son archivos de audio de 20 30 minutos cada uno y es uno detrás del otro así que siempre tiene que estar con mucho mucho tiempo de utilización y cuando vemos que no está haciendo nada es como ok un momento aquí algo no está mal no porque se espera que lo esté utilizando y bueno va de la mano no de entender que
de cómo funciona tu aplicación, saber qué es lo esperable y qué es lo que no. En base a eso vas viendo qué cosas son las que te sirven y qué cosas son las que no. Así que sí, podría decir que he tenido un poco de acercamiento de esa manera también. también creo que va de la mano con lo que mencionabas al inicio de que estas cosas vienen a raíz de haber experimentado
algo antes empezamos a dejar diferentes métricas dentro de nuestra aplicación porque al inicio a veces uno cree que aquí no va fallar aquí no voy a necesitar hacer nada o lo pasas por alto porque uno es como desarrollador te centras más en la lógica del negocio que todo funcione bien que los cálculos estén bien hechos y como que pasas por alto el tema de las métricas los logs y todo esto
y es cuando ya empezas a tener errores o que algo no funciona del todo bien es cuando empezas a notar ok sería muy bueno tener una métrica para ver qué está haciendo aquí o que me alertara directamente cuando algo está fallando entonces también estas son cosas que vienen de como mencionamos mencionábamos al inicio vienen a raíz de experiencias pasadas eso es lo que sucede
Douglas (1:20:45)
Sí, sí, sí, y eso justo es lo que nos lleva
a Juana a eventualmente comenzar a muchas veces configurar alertas para nuevas aplicaciones o servicios distintos y que no aplican.
Juan (1:21:01)
y que no aplican, si si si
Douglas (1:21:02)
y es ahí donde
comenzamos de nuevo el ciclo, lo que hemos hablado, recibir alertas a las cuales no les presto atención, comienzan a ignorarse, comienzan a volver molestas y en el momento que llega a un problema real ahí hay un conflicto serio.
Juan (1:21:17)
Normalmente,
creo que, bueno, si pienso en el tema de microservicios, se empiezan como a...
a categorizar microservicios. Tenemos microservicios que son REST APIs y literalmente eso lo reciben request, hacen un fetch de la base de datos y lo retornan. Esos tienen como un set de métricas. Luego tenemos otros microservicios que esos no están de cara hacia el exterior, son solamente internos, procesan la data, procesan mensajes de las colas
de mensajería, etcétera. Eso es debería entre también otro tipo de métrica. Nos interesa ver otro tipo de cosas. Y luego hay otra tercera categoría, podríamos decir, de microservicios que son más especializados. Estos son los servicios más específicos, como lo que te mencionaba. Procesan archivos de audio, procesan algún reporte, etcétera. O el ejemplo que nos dabas, ¿no? Que procesan los posts en diferentes categorías.
están en un plano...
por detrás, ¿no? Así que dependiendo de la categoría, o sea, creo que si hay métricas que aplican a varios microservicios, pueden aplicar a múltiples servicios, dependiendo si pertenecen a una misma categoría o mismo grupo, podríamos decir, que en teoría, un servicio que es solamente REST API y no procesa la información, solo obtiene y da respuestas, no debería...
aunque sean dos servicios diferentes, sea me refiero a devuelven información diferente pero en esencia hacen lo mismo entonces podrían tener una métrica similar sin embargo no los podríamos mezclar con las métricas que de los servicios que están corriendo en el background porque eso ya hacen otras cosas tal vez ahí podríamos simplificar nuestro trabajo verdad Douglas en el aspecto de bueno no tengo que hacer una métrica para cada uno de las
aplicaciones y servicios que tenemos en nuestra empresa, sino bien crear categorías de diferentes aplicaciones y así ya tenemos como templates, me imagino yo.
Douglas (1:23:35)
Sí, sí, yo creo que
justo eso es como la dirección correcta porque en tu caso como programador Juan, la métrica por categoría de aplicación, la métrica en particular me refiero a lo guiar esa métrica, a mandar esa métrica a algún lugar va a ser...
Juan (1:23:51)
Mm-hmm.
Douglas (1:23:54)
básicamente la misma por tipo de aplicación. sea vos vas a logear el tiempo que le tomó conectarse a la base de datos, el tiempo que tomó en conectarse al caché, el tiempo que tomó la base de datos en responder, vos vas a logear eso. Vos vas a logear el tiempo que tomó en devolver el cliente, etcétera. Porque la métrica como tal va a ser básicamente la misma para ese tipo de aplicación. Luego.
Juan (1:24:11)
Jajaja
Mm-hmm.
Douglas (1:24:18)
dependiendo porque aunque sea un tipo similar de aplicación, dependiendo del uso que va a tener y el tráfico que va a tener, con esas métricas se configura la aplicación a corte, que es lo que dijimos, ¿no? Un servicio con solo dos tres requests por minuto.
Juan (1:24:33)
Sí.
Douglas (1:24:35)
ocupas ver timeouts menores para que sea un problema, número menor de timeouts y si la aplicación tiene 50, 100 requests por minuto, el número de timeout tiene que ser un número más grande para que en realidad sea un problema. Pero la métrica guardada en tu parte de desarrollo va a ser la misma prácticamente. Pero sí, no queremos tener un servicio corriendo que quiera guardar métricas de caché, por ejemplo, en un servicio que no se está conectando a caché.
Entonces, qué? ¿Eso va a estar corriendo? ¿Para qué? Te estaría gastando espacio por poquito que sea, igual, mantenimiento, código que puede llegar a ser vulnerable por algo que no está realmente corriendo. Y esa es la intención, ese es el punto. De nuevo, las métricas tienen que ser personalizadas por servicio, por aplicación, y no es una métrica o un número, un valor que aplica a todos tus servicios.
Juan (1:25:05)
Correcto.
Douglas (1:25:32)
no funciona de esa manera, si hacemos eso vamos a terminar con alertas que queremos ignorar. Ahora, si te parece Juan, continuar, pasemos a discutir hoy si la diferencia entre notificaciones y alertas. Que yo hago una diferencia, al final una alerta es una notificación también, o sea, si te cae un mensaje a tu celular o si te cae una llamada, hay una notificación que te hace ir y contestar la llamada o ir y ver el mensaje.
Juan (1:25:46)
⁓ Ok.
Douglas (1:26:02)
Pero en este sentido, la notificación y la alerta tienen usos diferentes. Y es que, como ya hemos venido hablando, hay muchos eventos que ocurren en nuestra aplicación, en otros sistemas, que queremos saber de ellos. Queremos saber qué ocurrieron, pero no son accionables. Justo el ejemplo que vos daba, De esta, la cola que estaba en 10.000, pero vos sabés por qué es. sea, vos querés saber qué eso está ocurriendo.
Juan (1:26:28)
Jajaja
Douglas (1:26:31)
pero no es accionable. Al no ser accionable no merece la alerta. Pero si quieres darte cuenta, como mencionamos al inicio, conocer toda esta información es importante, es relevante para tomar decisiones de recursos, decisiones de mejoras, etc. Y también estos eventos pueden ser el inicio de algo grave, donde no es algo grave todavía, por ende no merece una alerta.
Juan (1:26:34)
Ok.
Douglas (1:27:00)
Pero, por ejemplo, uno de ellos puede ser que el disco duro solo le queda 20 % de espacio, por ejemplo. ¿Verdad? Eso es potencialmente un problema, porque si no haces algo al respecto, eventualmente se va a quedar sin espacio.
Juan (1:27:08)
Sí.
Douglas (1:27:15)
y vas a tener algo crítico. De repente no necesitabas una alerta, no me va a despertar en la madrugada una alerta de que todavía queda 20 % de espacio de disco porque lo primero que voy a hacer es decir, todavía hay 20 % de espacio, ¿por qué me voy a despertar a ver esto? Y hasta me voy a molestar y lo voy a ignorar. Pero quiero saberlo con tiempo, idealmente, para que eso eventualmente no se vuelva una alerta, ¿verdad? No se vuelva una alerta.
Juan (1:27:37)
para prepararte.
Douglas (1:27:42)
Entonces las notificaciones, Juan, son las que nos sirven en este tipo de casos. Notificaciones, ¿verdad? Aparte, ojo, aparte de que eso quede en logs, que eso quede guardado ahí en eventos, idealmente por meses o años, porque luego queremos volver a ellos. Pero este tipo de cosas es donde las notificaciones nos sirven. ¿Qué tipo de notificaciones? Aquí es donde estamos hablando, Juan, de correo electrónico, por ejemplo, un email.
Juan (1:27:53)
Claro, claro.
Douglas (1:28:09)
que no necesito, por eso te decía yo que de repente si es algo crítico
usar email para alertar la actividad de tus cámaras no necesariamente sea la opción más viable. yo el ejemplo que te puse al principio cuando empezamos en esta empresa, no nos conocimos, a implementar el departamento de monitoreo que para mí el correo se volvió inutilizable. sea, llegó un punto en el que ni le prestaba atención y se me pasaban por alto correos importantes porque en el correo es algo que lo voy a ver a mi tiempo. A veces me cae la alerta, pero yo sigo enfocado en lo mío y tengo lapsos en el día donde decimos
ir a ver el correo electrónico y aunque vos seas alguien o que nos ve y nos escucha sea alguien que revisa su correo constantemente una notificación puede ser por correo una notificación puede ser un mensaje de slack o cualquiera que sea tu mensajería interna a un canal donde hay varias personas que es un canal dedicado puede ser para monitoreo puede ser un canal solo para tu equipo pero puede ser un mensaje de slack
donde notifique el evento, ¿verdad?
Juan (1:29:14)
Si,
los mensajes de Slack son bien cómodos diría yo
Douglas (1:29:20)
Sí.
Juan (1:29:20)
te permite verlo al instante porque normalmente estás en Slack todo el te permite pues editar bien la información que vas a presentar y desde un punto de vista de implementación Slack te prevé los APIs de manera bien fácil entonces sí es una gran manera de hacerlo
Douglas (1:29:43)
Sí, yo prefiero Slack también,
sobre correo electrónico. De hecho, he trabajado en herramientas que alerten a Slack y no a correo electrónico. Sin embargo, el correo electrónico sigue siendo una opción muy viable, sobre todo cuando colaboras con equipo externo. A veces la mejor manera que tenés para enviarles una notificación es por correo, ¿verdad? Pero no es una alerta.
No es un tipo de alerta que te va a despertar en la madrugada. No es un tipo de alerta que a las siete de la noche estás con tu familia te va a llevar a moverte. Es una notificación para que cuando tengas el tiempo de verla, saber qué ocurrió el evento. Ahora, ¿qué tipo de eventos queremos notificar, Juan? Vos has mencionado varios. Yo voy a dar algunos ejemplos. Tal vez basados en algunos que ya di, pero poniéndolos en el contexto de notificación. Cuando el pod...
se reinicia o el servicio se reinicia de un sistema crítico. Ya dijimos que si eso se reinicia una vez, no es crítico. Por eso Kubernetes tiene su funcionalidad donde él va a levantar de nuevo el pod. O si tengo un servidor corriendo un servicio, normalmente voy a tratar de tener algo de self-healing o auto-healing. O sea que el servicio va a que curarse a sí mismo. Y entonces estos servicios lo manejan y va a volver a levantar y listo.
Juan (1:30:47)
Mm-hmm.
Douglas (1:31:04)
Entonces no necesito accionar para ello, no tiene que ser una alerta. Pero si quiero darme cuenta que eso pasó, ¿verdad? Entonces, ¿por qué? Cuando ver este tipo de notificación puede hacer de que un ingeniero cuando tenga tiempo entre y revise y ve por qué fue. Muchas veces pasa de que tenés lapsos en los que no tenés mucho que hacer.
o ya terminaste tus tickets antes de tiempo y pues te faltan cuatro horas en el día, ¿no? Y si te toca al final del día loguear ocho horas de trabajo, bueno, entonces es ahí donde uno se pone a buscar qué hacer y te bajas esas notificaciones. Ey, me he fijado que ya van cinco días que una vez al día se reinicia el pod de tal servicio, voy a ver qué es. Y ahí te metes a ver, a ver si encontrás.
Juan (1:31:52)
Sí,
Douglas (1:31:52)
y de paso
Juan (1:31:52)
sí, claro.
Douglas (1:31:53)
aprovechaste tu tiempo. Otra notificación puede ser lo que te decía, el disco dura al 80%. Y la idea aquí es evitar que eventualmente llegue al 95 % que al 90 o 95 % ya envía la alerta, dependiendo del servicio que es. Y ahí si ya alguien tiene que despertarse en la madrugada a hacerlo, entonces mejor si tengo un tiempo y digo, hey, aquí cayó esta alerta.
la voy a agregar en mi lista, en mi Tudu para hoy, en mi agenda de hoy y la pongo en cierto lugar en la agenda y cuando le llega el turno, hago eso hoy, ¿verdad? Entonces, para eso sirven las notificaciones. Otro puede hacer que la cantidad de warnings, ha incrementado, la cantidad de warnings en los logs ha incrementado en la última hora, ¿verdad? Hay, no sé, cien warnings en la última hora, ¿no? Un warning en los logs pues solo es una advertencia, puede ser.
puede ser cualquier cosa, ser una función que ya está tal vez a punto de no ser soportada en las nuevas versiones de Node.js o de Python o de PHP, lo que sea, ¿no? Pero ha incrementado bastante. Y entonces en base, y eso puede mandar una notificación. Hay tantos warnings en la última hora.
Juan (1:33:09)
pero ahí también depende del tipo de warning por ejemplo yo suelo utilizar mucho los warnings a nivel del código como tal de los logs que yo dejo digamos el usuario hace un request para obtener información de su cuenta pero eso se va a una tabla en específico que tiene información de cada uno de los usuarios pero para este usuario no lo encontró entonces retorna una respuesta vacía
el UI se le muestra una tablita en vacío, ¿no? Yo dejo logs de, este usuario intentó obtener esta información y no la encontró. Eso me sirve a mí como un warning de por qué. Y tal vez se supone que siempre tiene que tener una información inicial. Entonces, si no la encontró es por algo. Tal vez algo pasó en la conexión con la base de datos, algo pasó con...
data de este usuario en específico y si sucedió la data con este usuario en específico a cuántos usuarios les ha pasado entonces para mí los warnings claro tienen una una
un nivel de urgencia menor que una alerta crítica, los warnings definitivamente son un punto muy importante que nos avisa de esto hay que investigarlo un poquito y dependiendo de lo que está pasando tal vez hay que dedicarle aún más tiempo para prevenir, son más como preventivos los veo yo los warnings
Douglas (1:34:41)
Sí, es que justo por eso, bueno, aquí
juntamos todo lo que hemos venido hablando. por eso es una notificación y no una alerta. Por eso lo estoy incluyendo en la categoría de notificación y no alerta. Es una eventualidad que querés saber qué ocurrió. Demasiado warning en un lapso corto. ¿Por qué? ¿Verdad? Quieres saber qué eso ocurrió. Ahora, lo otro es, de nuevo.
recordemos que se configura acorde a la aplicación y si para alguien no es relevante, para una aplicación o servicio no es relevante la cantidad de warnings entonces no lo notificamos pero para algunas aplicaciones si hay mucho warning normalmente es algo extraño
Juan (1:35:13)
Sí.
Douglas (1:35:27)
no necesariamente crítico, pero extraño. De hecho, en Kubernetes, por ejemplo, en las alertas que vienen por defecto, ahí con instaladas Prometheus y Grafana para monitorear Kubernetes, hay una notificación, si quieres la puedes hacer alerta, pero es una notificación cuando hay un número bien alto de logs info. ¿Verdad? Porque es info, pero ¿por qué hay tanto?
Juan (1:35:48)
Ok.
Douglas (1:35:51)
sea, despierta la atención. Ahora, ¿por qué este tipo de alertas, Juan? Este tipo de alertas pueden llevar, por ejemplo, a un ticket. A que el proyecto manera un ticket y ese ticket, de nuevo, queda en la cola para que en algún momento el programador tiene tiempo y los va a ver. Y ahí se puede llegar a encontrar un problema futuro. Por eso te digo, de repente una función...
que ya no va a ser soportada en versiones nuevas, la aplicación es en Node.js, verdad? Y digamos que hacen el trabajo de actualizar Node.js, ese warning se va a volver en una alerta, verdad? Entonces es algo que tenés que lidiar con ello en algún momento, ¿no? Lo que no tenés que hacer es despertarte en la madrugada para lidiar con ello o dejar de hacer lo que estás haciendo ahorita para lidiar con ello.
Juan (1:36:31)
Sí.
Douglas (1:36:44)
pero es de prestar la atención, entonces es una notificación, ¿verdad? Entonces la idea de este tipo de notificaciones es eso, tener esta información y en la medida de lo posible evitar que eso se convierta en una alerta real, ¿verdad? Entonces no sé si a vos se te viene a la mente otro tipo de eventos que vos sintas que vale la pena notificar de nuevo, no alertar, pero si notificar.
Juan (1:37:13)
Sí, bueno, generalmente se me viene a la mente más como situaciones que tienen que ver con la aplicación en específico y ahí ya depende de cada una de las aplicaciones, de la lógica del negocio de cada aplicación. Pero sí, es importante tener notificaciones de...
por ejemplo cuando un usuario intenta, qué se yo, en mi caso por ejemplo donde estamos, los usuarios pueden como...
por decirlo así, revertir o eliminar su cuenta lo que se hace es que se elimina todo lo que ellos hayan subido a la cuenta entonces ellos pueden hacer una petición y se hacen así que ese es un evento que sucede y es como no es una alerta porque fue el usuario que lo decidió pero pues es algo que muchas personas quieren saber porque muchas de esas notificaciones a veces no sólo las miran las personas de
IT, las personas del área de tecnología también lo ven, project managers, product owners, todas estas personas que también están interesados en ciertas cosas más puntuales y bueno esas son como notificaciones que nosotros tenemos como te mencionaba también dependiendo de la aplicación hay aplicaciones que se conectan con RabbitMQ y la manera en cómo está configurado
algunos de ellos a veces pierden la conexión por algún motivo así que eso también muestro una notificación de bueno en este caso creo que sería más como una alerta bueno no creo que sería notificación si lo trato de categorizar como lo que ha estado explicando porque el contenedor lo que se hace es que entra en estado de self healing así que se destruye vuelve a levantarlo para que se vuelva a conectar pero de nuevo
queremos saber que esto pasó porque tal vez qué pasa si hay muchas notificaciones entonces ya podemos tomar cartas en el asunto y ver qué está pasando creo que tal vez aquí es un poco complicado porque va a depender de lo que está pasando dependiendo de la aplicación del negocio pero pues es importante identificar estas partes que yo lo veo así como que
Douglas (1:39:19)
Sí.
Juan (1:39:48)
las notificaciones nos ayudan a prevenir.
Retomando con lo que vos mencionabas, sería como para prevenir que algo suceda. Si es para una versión que amerita actualización, es una medida preventiva de no quedarnos y no generar deuda técnica. Así que todas estas acciones que puedan prevenirnos a futuro, entonces entran en una notificación que no está de más en Slack o en un correo. El correo es complejo.
Muchos clientes de correo te permiten crear folders y categorías como para limpiar la bandeja, iguales creo que recae la responsabilidad en nosotros al momento de revisar nuestro correo y darle la prioridad a cada uno de los mensajes que reciben. Por ejemplo, yo a veces recibo muchos...
En mi correo recibo mucha información de la empresa, pero no es información de a nivel laboral, sino como la empresa de cara al público.
y no he sabido cómo desuscribirme a eso y lo he dejado ahí lo que hace es que me llena la bandeja así que eso hace un poco difícil a veces revisar, me toca ir correo por correo ir viendo qué cosas necesitan mi atención pero bueno el punto es que el correo puede ser un arma de doble filo en ese aspecto porque a veces recibimos de todo y Slack puede ser creo que es una mejor opción Slack o Teams o lo que esté utilizando la empresa
Todas estas ofrecen APIs.
Douglas (1:41:31)
Sí, no, yo estoy de acuerdo con
vos en esa parte, 100 % de acuerdo. En lo personal, el correo electrónico hace años dejó de ser la opción viable para notificaciones, mucho menos alertas, por supuesto. Sin embargo, sigue siendo una opción, de nuevo, cuando un equipo externo con el cliente, a veces, pues, el correo electrónico es la única
Juan (1:41:45)
Mm-hmm.
Douglas (1:41:53)
forma. También se puede notificar como un reporte semanal de ciertos eventos en lugar de que estén cayendo a diario si no son eventos como que tan críticos puede ser un reporte semanal de eventos.
Juan (1:42:08)
como un recap.
Douglas (1:42:09)
sí, como
recap de la semana de ciertos eventos, de nuevo puede ser en Slag, en Teams, en Correo Electrónico, sí tenemos que cuidar y aquí quiero dar este consejo para cerrar con esta parte de las notificaciones versus alertas, también cuidar lo mismo con las alertas de no notificar todo, no notificar todo, ¿verdad? Hay que notificar...
es parte de configurar alertas de manera efectiva porque la intención es evitar alertas o evitar lo crítico, pero tampoco notifiquemos todo porque si caemos en lo mismo que donde están cayendo las notificaciones las voy a ignorar. La idea de la notificación es que cuando tenga el tiempo la voy a ir a ver. Accione o no accione, la mayoría de veces no voy a accionar, a veces sí, a veces no, pero que sí la mire.
Juan (1:42:40)
Mm-hmm.
Douglas (1:42:59)
que sí la mire cuando tenga tiempo. Entonces, si notificamos todo, va a pasar de nuevo que no vamos a ver las cosas. Igual, como te digo, mí me pasado tantas cosas, Recuerdo yo que hubo una época cuando ya estaban las alertas de notificaciones, en un estado ya más aceptable, este vicepresidente de tecnología que te menciono, había ocasiones en las que había pasado todo el día, era tipo tres de la tarde ya, y no había caído una sola notificación.
menos alertas y entonces él llamaba y decía no ha caído nada en ninguna alerta algo está malo revisen todo y yo te voy a decir Juan odiaba cuando no caían notificaciones porque eso nos iba a hacer buscar
absolutamente en todo sin saber qué está buscando porque él nos decía no busque y eso es lo peor estar buscando algo que no sabes qué es lo irónico es que la mitad del tiempo contrabamos algo y eso reforzaba su mentalidad de creer de que él había hecho bien en pedirnos que revisemos simplemente como dicen no el que busca encuentra a veces alguien encontraba algo y entonces son experiencias de vida pero fin juan espero que eso
Juan (1:43:50)
Sí, sí, sí, sí.
sin saber. Sí.
Douglas (1:44:16)
haya podido aclarar un poco de nuevo a que me refiero yo entre notificación contra alerta.
Juan (1:44:24)
Sí.
Douglas (1:44:25)
Y
ya para concluir, porque hemos hablado bastante, yo creo que el tema lo amerita. En lo personal, mí me parece un tema muy interesante porque creo que hay bastante desinformación afuera y le toca a la gente aprender en el camino cómo me pasó a mí o cómo te pasó a vos y cometemos mucho error. Entonces, por eso a mí me parece muy importante y espero que sea de mucho valor para las personas que nos ven y nos escuchan. Pero para concluir, ¿cómo debemos alertar?
Juan (1:44:43)
Sí.
Douglas (1:44:54)
según la severidad del problema, porque entonces ya sabemos que vamos a alertar cosas que sean accionables, pero entonces, como alerto, va de nuevo, según la severidad va a ser o responder de inmediato.
o puede ser que el alerta me deje esperar entre 10 y 30 minutos o a veces un par de horas, pero de que cuando me cae el alerta voy a tener que accionar algo, lo voy a tener que hacer. Entonces, idealmente, después de una de las severidades, Juan, la primera alerta puede ser un mensaje que emita un sonido, que me haga saber que llegó un mensaje. Eso puede ser un mensaje de Slack etiquetándome.
verdad cuando cuando te etiquetan hace un sonido va hace un sonido y te queda te queda la marca de que tenés una alerta un mensaje sin leer y que tenés que ir a leer y normalmente yo estoy enfocado en algo pero cuando el gente etiqueta me es la que me suena entonces en hora de trabajo el mensaje de es la con la etiqueta es una alerta para mí verdad o también puede ser un mensaje de texto al celular
que se va a meter un sonido y yo voy a ir ver y de nuevo hoy en día los mensajes de texto pues casi no se utilizan para para interactuar con familia o amigos, whatsapp o utilizar la mensajería del iphone de apple perdón que está en el iphone también entonces cuando cae un mensaje de texto yo voy y lo miro inmediatamente porque yo estoy pensando que es una alerta
o puede ser si tenés un sistema como VictorOps o cualquier otro sistema de notificaciones, tenés la aplicación móvil que te va a mandar una alerta, ¿verdad? Te manda la alerta. el primer mensaje es un, la primera alerta, perdón, es un mensaje con sonido. Que traigas mi atención y que me haga inmediatamente verlo, no necesariamente inmediatamente accionar.
Juan (1:46:41)
Sí, algo que atraiga tu atención.
Douglas (1:46:51)
de nuevo va a depender de la severidad, pero inmediatamente verlo. Ahora la alerta tiene que estar configurada de que si luego digamos de unos cinco minutos no la he visto, no la he tomado, no le he dado acknowledge, como se dice en inglés, no la he agarrado para mí, que en unos cinco minutos vuelva a enviarme la alerta, ¿verdad? Dependiendo de la severidad, que me vuelvan a enviar el texto por la misma vía, ¿verdad? Y si pasan otros cinco minutos y no lo he tomado,
Juan (1:47:06)
Mm-hmm, mm-hmm.
Douglas (1:47:18)
que me llame, que me haga una llamada al celular, verdad, de la alerta obviamente te va a responder una máquina diciendo que hay una alerta pero ya la llamada ya asignoras la llamada y si vos sos alguien que estás pendiente a recibir mensajes ya sea porque estás en un call o porque maneja una situación y tenés tu teléfono en silencio
entonces busca otro trabajo, está mal si no quieres estar on call, Juan es muy respetable para cada quien, si ese es el trabajo que tomaste, entonces ten el teléfono con sonido, si estás esperando llamadas, a ese punto es lo profesional y responsable hacer. También, Juan, puede ser que sea una alerta crítica.
Juan (1:47:56)
Sí.
Douglas (1:48:00)
a veces estas alertas le suelen decir alertas 9 11 o sea alertas porque ya es un sistema bien crítico y no puede haber un problema ahí, ahí se cae el mundo y ese tipo de alertas deben de de un solo llegar al nivel máximo de notificación que normalmente es una llamada.
Entonces, idealmente ese tipo de alertas deben de llamar de un solo a la persona o personas que deben recibir esa alerta y accionar para ella. Entonces, ese es como un proceso normal y esa es la forma efectiva de poder enviar la alerta. Y aparte de ello, es importante que exista un nivel de escalar la alerta. O sea, tenés como muchas veces puede haber como un
Juan (1:48:20)
Ok.
Douglas (1:48:49)
o un ingeniero de soporte o de primer nivel, o puede ser el programador encargado o el SRE encargado, aquí normalmente le llega la alerta. Pero si la persona después de una o dos veces no la recibió, la siguiente alerta le va caer al gerente o al jefe o a otro o a otro ingeniero que está pendiente a un nivel 2 para que la alerta escale. Y si puedes tener todavía un nivel 3 aún mejor.
Entonces va a una persona designada, quien va a intentar caerle, pero supone que esa persona se enfermó y nadie se dio cuenta. Es una situación dura, difícil a ese punto. La salud es más importante que cualquier sistema.
Juan (1:49:28)
Sí, sí claro.
Douglas (1:49:32)
No importa si ese sistema genera millones, la salud es más importante, ¿no? Y la persona debe de cuidar, pero el equipo como tal debería de poder prepararse para cualquier eventualidad. Entonces, si la persona no puede tomar uno, entonces que eventualmente escale. Y en tiempo y forma acorde a la severidad, ¿verdad? Al final, de nuevo, al final lo importante, Juan, es de que nos aseguremos de que no voy a pasar por alto la alerta, tanto.
escucharla para tomarla y recibirla como para luego accionar a ella. Entonces, en ese sentido, yo sé que en tu caso como programador va ser bien difícil que vos seas la persona que está recibiendo alertas, no notificaciones sino que alertas, pero no sé si tenés como algún pensamiento alrededor de ello.
Juan (1:50:23)
Si, bueno, tenés razón, la verdad es que no estoy muy familiarizado con ese tipo, osea si recibo alertas de Slack. Pero es más como una alerta a un grupo donde estamos varios y mencionan, no, ahi esta sucediendo esto, sucediendo lo otro. Pero de hecho desconocía lo de poder recibir llamadas por parte del sistema. Me imagino que debes tener algún mecanismo para indicar que ok, ya recibí la alerta, la estoy regulando.
para que no siga repitiendo. Si, definitivamente no estaba muy al tanto de esto, pero tiene sentido. Tiene sentido porque cuando estás a cargo de sistemas tan críticos, es necesario llamar de alguna manera. Creo que la forma de comunicación más inmediata o que atrae nuestra atención más rápido es una llamada. Así que me hace sentido. Pero bueno,
La verdad es que sí, sí te lo debo Douglas, no he tenido una experiencia de esa manera de tener que atender una alerta crítica. Gracias a Dios, hasta el momento no me ha tocado. Espero que siga así por mucho tiempo.
Pero sí me ha pasado donde las personas que reciben las alertas me notifican por Slack y ya me dicen, hey, está pasando tal cosa, lo estoy revisando, pero deberías también echarle un ojo. Entonces ahí sí, ya me levanto de la cama y enciendo la computadora y empiezo a investigar para apoyar al equipo, de eso se trata.
yo no recibí la alerta y si ya me notificaron pues lo ideal es empezar a aportar algo así que sí he recibido alertas pero más como como por medio de terceros de otras personas que supongo que ellos ya recibieron la llamada o recibieron estos mensajes
Douglas (1:52:25)
Sí, sí, bueno...
Ellos recibieron la llamada, Juan. Yo espero que
las personas que les ha tocado a Southern Call entiendan que vos sos desarrollador y no te ha tocado y no se sientan ofendidos porque, pues bueno, yo llevo más de una década con el privilegio de llamadas a medianoche por parte del sistema. Nosotros antes usábamos un servicio que se llamaba PagerDuty.
Juan (1:52:40)
Sí, sí, sí, sí.
Por el privilegio.
Douglas (1:52:56)
Pager como los, acá, aquí en, sí, pero los Pagers son lo que antes le decíamos aquí en Latinoamérica, los Vipers, ¿te acordás? Los Vipers porque así se leía en español, pero esos son, dispositivo se llaman Pagers, que eran esos unos, aquí estoy hablando, se llaman Pagers, Vipers es la marca, Viper.
Juan (1:52:56)
Ok
de paginación.
¿No se llaman beepers?
ok ok
Douglas (1:53:23)
y acá les decimos vipers y esos
pagers, el mensaje que se mandaba por eso se llamaba un page, yo usé eso desde que me tocó estar on call porque yo estaba pequeño, ni hablaba inglés, ya he contado esas experiencias, yo también les decía vipers, ¿verdad? Pero son pagers y se hicieron para tener una manera de contactar a personas no solo en ITE, en cualquier rubro que ocupara ser contactado a cualquier hora.
Juan (1:53:31)
Mm-hmm.
Sí, sí, sí.
eran como tweets porque eran cortitos, ¿no?
Douglas (1:53:53)
eran como, sí, eran mensajes de texto cortos, pues llamabas a una
operadora y decías el pager con el ID tal o el pager con el número tal, este es el mensaje que quiero mandar. Y ya, pipipipi, sonaba. Y ya te caía, ya lo agarrabas a y ya mirabas el page, mirabas el mensaje, ¿verdad? Entonces, de ahí se origina el contactar a gente de manera remota.
Juan (1:54:08)
Ajá, ajá.
Ok
Douglas (1:54:20)
cuando hay problemas, de nuevo, no solo en IT, pero en IT eran muy utilizados los Pagers. Entonces esta aplicación PagerDuty que ahora fue adquirida por otra empresa se llama VictorOps o es una variación que la que usamos ahora. Pero sí, en estas aplicaciones vos creas tu cuenta, en tu cuenta metes tu correo electrónico, tu número de teléfono y configurás a cómo quieres que lleguen las alertas y el punto más alto es que te hace una llamada.
Juan (1:54:25)
Sí.
Douglas (1:54:45)
Y te suena una máquina que hay una alerta, ⁓ Y si te toca que despiertes en la madrugada. Ahorita, donde trabajo en FIU, estamos en on call en horas de día, ¿verdad? Ya donde trabajamos, no nos conocimos, me tocaba estar toda una semana on call 24-7. Pero esas alertas van despertadas en la madrugada. Por eso eras bien molesto al principio cuando todo alertaba.
te despertaban en la madrugada mensajes los cuales no había que hacer nada pero te despertaban y por eso tanto el enfoque de mi parte en buscar llevar las alertas un punto en el que si cae una alerta es porque tengo que accionar verdad por eso por eso se vuelve tan importante entonces esa ha una práctica de recibir llamadas desde hace desde que existen los celulares desde hace mucho tiempo cuando cuando ahí
Juan (1:55:16)
Ok
Sí.
Douglas (1:55:41)
cuando hay alertas, entonces sí, es la vida de SISAMING o la vida de sistemas.
Juan (1:55:48)
Sí, sí, una vida interesante. Pensé que era con algo como el mismo Slack te podía mandar eso, pero existen entonces estos servicios. Interesante.
Douglas (1:55:51)
Sí, sí, interesante, digamos.
Sí, no, existen
servicios dedicados específicos a la gente que está en un call. Son diseñados para eso. Entonces, este servicio conectar las métricas de Prometheus, o métricas de, o los dashboard de Grafana, o lo que sea que genera alerta de tus AVICs, cualquiera que tengas alertando, ahí conectas a ese servicio y ese servicio es el que mandas las.
Juan (1:56:10)
Sí.
Douglas (1:56:25)
el que manda las alertas, sí. Pero bien, se me están viniendo como recuerdos de guerra, entonces quiero pasar a algo más, más relajante. Yo creo que hemos hablado bastante, de nuevo, yo creo que el tema lo amerita. Yo creo que mi intención con esto, espero yo que la gente pueda buscar educarse un poco más y entender mejor todo lo que es alrededor de las alertas.
cómo configurarlas, cómo tomarse el tiempo para irlas afinando hasta que estén en un punto en el que una alerta sea accionable y cómo no descansar hasta llegar a ese punto porque se puede y en realidad que toma tal vez algo de tiempo pero se puede y que no tengan que pasar por esa prueba y error.
Juan (1:57:07)
Uh-huh.
Douglas (1:57:13)
prueba y error que resulta molesto y a veces se invierten años en ello y no es agradable para nada. Entonces para mí ha sido importante invertir este tiempo y yo como mensaje final solo les voy a decir procuren ser inteligentes y diligentes al momento de configurar las alertas. Es un proceso que toma tiempo y hay que ser inteligente, que ser creativos. A veces estas alertas como la que les decía de configurar porque el CPU está por debajo de lo esperado.
les va a salvar un montón de tiempo a futuro, les va a prevenir una alerta grande a futuro, ¿verdad? Entonces, seamos inteligentes y diligentes al momento de configurar las alertas y realmente que si están en proceso de empezar o a mitad del proceso de implementar alertas efectivas, espero que algunos de estos tipos sirvan y les deseo muchísima suerte. Juan, no sé con qué palabras te gustaría cerrar.
Juan (1:58:08)
Bueno, me gustaría mencionar que obviamente...
hay mucho más que hablar sobre esto. Pareciera que es un tema que uno pasa por alto al inicio, pareciera que no amerita tanto, pero sí, requiere investigación. Así que los invito a que investiguen un poco más. Lo que hemos hablado aquí ha servido más como una introducción para que empiecen a saber qué es lo que hay por detrás, cómo se envían las alertas, cómo funciona esto, y como decía Douglas, ¿no? Hacer alertas efectivas.
pero de nuevo les invito a que investiguen mucho hay muchos artículos en internet que valen la pena hacer leídos y de esta manera pueden ir encontrando más información que les va a ayudar a hacer esto de manera más más fácil más simple porque de todas maneras se van a dar van a suceder errores y les va a tocar caerse y levantarse eso es inevitable pero al menos
al tener más información estas caídas van a ser un poco más controladas y vamos a saber un poco mejor cómo arreglar las cosas que están pasando así que eso es lo que yo les puedo decir y también desde un punto de vista para los que son desarrolladores y no tienen la responsabilidad por detrás de estar on call y hacer las alertas lo que les puedo recomendar es el hecho de visualizar qué es
lo que puede pasar con nuestra aplicación y qué partes requieren mayor cuidado. Así que en estas partes tener la...
el cuidado de dejar los logs necesarios, la información necesaria y configurar métricas que sean útiles. Así que se puede hacer y de esa manera pues trabajamos en equipo. Los desarrolladores dejan las métricas con toda la información necesaria y luego las personas que están en SRE, DevOps, pueden empezar a crearlas, configurar las métricas y los servicios.
Douglas (2:00:15)
Me gusta
bastante tu consejo, sobre todo el que diste a los programadores, tengamos toda esa orientación, trabajemos en equipo, programadores asegúrense de tener las métricas necesarias, los de Sysambing o SRE, asegurémonos de configurar las alertas de manera efectiva.
Dejamos la conversación hasta acá, con ganas de seguir hablando del tema, pero creo que hemos abarcado bastante y como siempre decíamos que haya sido de mucho valor para todos ustedes. Nos vemos en el próximo episodio.
Juan (2:00:46)
Sí.
ojalá que ellos activen
las notificaciones y las alertas para cuando salen los episodios de Deven Ops.
Douglas (2:00:56)
muy apropiado tu mensaje, sí, esperamos que activen
las alertas y que nos puedan escuchar en los futuros episodios. Gracias por su atención. Hasta la próxima.