{"id":31864,"date":"2019-10-31T21:43:33","date_gmt":"2019-10-31T18:43:33","guid":{"rendered":"https:\/\/prohoster.info\/blog\/monitoring-myortv-da-zdravstvuet-monitoring\/"},"modified":"2019-10-31T21:43:33","modified_gmt":"2019-10-31T18:43:33","slug":"monitoring-myortv-da-zdravstvuet-monitoring","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring","title":{"rendered":"\u00bfLa monitorizaci\u00f3n ha muerto? \u2014 Viva la monitorizaci\u00f3n","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u00bfLa
\n
\nNuestra empresa se dedica desde 2008 principalmente a la gesti\u00f3n de infraestructuras y al soporte t\u00e9cnico 24\/7 de proyectos web: tenemos m\u00e1s de 400 clientes, alrededor del 15% del comercio electr\u00f3nico en Rusia. Por lo tanto, el soporte implica una arquitectura muy diversa. Si algo falla, tenemos la obligaci\u00f3n de repararlo en 15 minutos. Pero para entender que ha ocurrido una aver\u00eda, es necesario monitorear el proyecto y reaccionar ante los incidentes. \u00bfY c\u00f3mo se hace esto? <\/p>\n

Considero que en la organizaci\u00f3n de un sistema de monitoreo adecuado se producen problemas. Si no hubiera problemas, entonces mi discurso consistir\u00eda en un solo punto: \u00abPor favor, instalen Prometheus + Grafana y los complementos 1, 2, 3\u00bb. Desafortunadamente, ahora no funciona as\u00ed. Y el principal problema es que todos siguen creyendo en algo que exist\u00eda en 2008, desde el punto de vista de los componentes de software. <\/p>\n

En relaci\u00f3n con la organizaci\u00f3n del sistema de monitoreo, me atrever\u00eda a decir que... no existen proyectos con un monitoreo adecuado. La situaci\u00f3n es tan mala que si algo cae, existe el riesgo de que pase desapercibido; todos creen que \u00abtodo est\u00e1 siendo monitoreado\u00bb.
\nPuede que todo est\u00e9 siendo monitoreado. Pero, \u00bfc\u00f3mo? <\/p>\n

Todos hemos enfrentado una historia similar a la siguiente: trabaja un devops, un admin, y llega el equipo de desarrolladores y dice: \u00abHemos lanzado, ahora monitores\u00bb. \u00bfQu\u00e9 monitorar? \u00bfC\u00f3mo funciona esto?<\/p>\n

Est\u00e1 bien. Monitorizamos a la antigua. Pero ya ha cambiado y resulta que estabas monitoreando el servicio A, que se convirti\u00f3 en el servicio B, que interact\u00faa con el servicio C. Pero el equipo de desarrolladores te dice: \u00abInstala el software, \u00a1se supone que debe monitorearlo todo!\u00bb<\/p>\n

\u00bfEntonces, qu\u00e9 ha cambiado? \u2014 \u00a1Todo ha cambiado!
\n<\/a><\/noindex><\/p>\n

A\u00f1o 2008. Todo es perfecto.<\/h4>\n

\nHay un par de desarrolladores, un servidor, un servidor de base de datos. Todo comienza aqu\u00ed. Tenemos cierta informaci\u00f3n, instalamos zabbix, Nagios, cacti. Y luego configuramos alertas claras para la CPU, el funcionamiento de los discos, el espacio en los discos. Tambi\u00e9n hacemos un par de comprobaciones manuales para asegurarnos de que el sitio responde, que los pedidos llegan a la base de datos. Y eso es todo: estamos m\u00e1s o menos protegidos. <\/p>\n

Si comparamos la cantidad de trabajo que hac\u00eda el administrador para asegurar el monitoreo, el 98% era autom\u00e1tico: la persona encargada del monitoreo debe entender c\u00f3mo instalar Zabbix, configurarlo y ajustar las alertas. Y el 2% son verificaciones externas: que el sitio responde y hace consultas a la base de datos, que han llegado nuevos pedidos.<\/p>\n

\"\u00bfLa
\n <\/p>\n

A\u00f1o 2010. Aumenta la carga<\/h4>\n

\nComenzamos a escalar los webs, agregamos un motor de b\u00fasqueda. Queremos estar seguros de que el cat\u00e1logo de productos incluye todos los art\u00edculos. Y que la b\u00fasqueda de productos funciona. Que la base de datos est\u00e1 operativa, que se est\u00e1n realizando pedidos, que el sitio responde externamente y responde desde dos servidores<\/a> y el usuario no es expulsado del sitio mientras se rebalancea en otro servidor, etc. Las entidades est\u00e1n aumentando. <\/p>\n

Y la entidad relacionada con la infraestructura sigue siendo la m\u00e1s importante en la mente del gerente. A\u00fan persiste la idea de que la persona encargada del monitoreo es quien instala Zabbix y puede configurarlo.<\/p>\n

Sin embargo, surgen tareas relacionadas con la realizaci\u00f3n de verificaciones externas, la creaci\u00f3n de un conjunto de scripts para las consultas del indexador de b\u00fasqueda, un conjunto de scripts para verificar que la b\u00fasqueda cambia durante el proceso de indexaci\u00f3n, un conjunto de scripts que comprueban que los productos se entregan al servicio, etc.<\/p>\n

\"\u00bfLa
\n
\nNota: he escrito \"conjunto de scripts\" tres veces. Es decir, la persona responsable del monitoreo ya no es solo quien instala Zabbix. Es alguien que comienza a programar. Pero en la mente del equipo, nada a\u00fan ha cambiado. <\/p>\n

Sin embargo, el mundo cambia, volvi\u00e9ndose cada vez m\u00e1s complejo. Se agrega una capa de virtualizaci\u00f3n, varios nuevos sistemas. Comienzan a interactuar entre s\u00ed. \u00bfQui\u00e9n dijo \"huele a microservicios?\" Pero cada servicio, a\u00fan por separado, se ve como un sitio. Podemos acceder a \u00e9l y entender que proporciona la informaci\u00f3n necesaria y funciona por s\u00ed mismo. Y si eres un administrador que ha estado trabajando en un proyecto que ha evolucionado 5-7-10 a\u00f1os, este conocimiento se acumula: aparece un nuevo nivel, lo asimilas, aparece otro nivel, lo asimilas\u2026 <\/p>\n

\"\u00bfLa
\n
\nPero rara vez alguien mantiene un proyecto durante 10 a\u00f1os.<\/p>\n

Resumen del monitor de sistema<\/h3>\n

\nSupongamos que llegaste a una nueva startup que r\u00e1pidamente reuni\u00f3 a 20 desarrolladores y escribi\u00f3 15 microservicios, y t\u00fa eres el administrador al que le dicen: \"Construye CI\/CD. Por favor\". Construiste CI\/CD y de repente oyes: \"Es dif\u00edcil trabajar con producci\u00f3n en el 'cubo', sin entender c\u00f3mo funcionar\u00e1 la aplicaci\u00f3n all\u00ed. Haznos una sandbox en este mismo 'cubo'.
\n Creas una sandbox en este cubo. Te dicen de inmediato: \"Queremos una base de datos de staging que se actualice todos los d\u00edas desde producci\u00f3n, para entender que funciona en esa base de datos, pero sin estropear la base de datos de producci\u00f3n\".<\/p>\n

Vives en todo esto. Quedan 2 semanas para el lanzamiento y te dicen: \"Ahora debemos monitorear todo esto\u2026\" Es decir, monitorear la infraestructura en cl\u00faster, monitorear la arquitectura de microservicios, monitorear la interacci\u00f3n con servicios externos\u2026 <\/p>\n

Y los colegas sacan de la cabeza un esquema familiar y dicen: \"\u00a1Pero aqu\u00ed todo es claro! Instala un programa que lo monitoree todo\". S\u00ed, s\u00ed: Prometheus + Grafana + plugins.
\nY a\u00f1aden: \"Tienes un par de semanas, haz que todo sea confiable\".<\/p>\n

En un mont\u00f3n de proyectos que vemos, se asigna a una persona para el monitoreo. Imagina que queremos contratar a alguien por 2 semanas para que se ocupe del monitoreo, y le estamos armando su curr\u00edculum. \u00bfQu\u00e9 habilidades deber\u00eda tener esta persona, considerando todo lo que hemos dicho antes?<\/p>\n