
¿Por qué amamos a Prometeo ? Él tiene una configuración: miró y todo está claro, el programa hace lo que le dijeron. Puede automatizar la configuración de monitoreo, almacenarla en VCS y revisar el comando. Restringió su MR , canalización trabajada, una nueva configuración aplicada a prometheus. En general, IaC en todo su esplendor.
Hablando de prometeo. ¿Lo usas para tu infraestructura de hierro? Entonces no lo usamos.
Al igual que muchos que han estado monitoreando durante mucho tiempo y que tienen hardware "desnudo", utilizamos Zabbix , que, por cierto, se encuentra en ese hardware. Por desgracia, en este momento, Zabbix e IaC son cosas no relacionadas. Zabbix se puede configurar manualmente o mediante la API.
Antecedentes
En octubre de 2018, se lanzó Zabbix-4.0, una nueva sucursal de LTS . Y a mediados de marzo, comenzamos a planear actualizar nuestra instalación de la versión 3.4.
Casi no hubo problemas especiales con 3.4:
- A veces, algunos LLD no funcionaban en algún lugar y sucedía lo Imposible , que no está claro cómo depurar en una versión no compatible con el desarrollador
- La memoria de los extractores HTTP fluía constantemente, como resultado de lo cual un systemd cuidadosamente configurado bloqueó la supervisión y la inició nuevamente. El problema estaba enmascarado por una cantidad decente de memoria del servidor. El problema es bien conocido, documentado .
Y en 4.0 había características interesantes como elementos HTTP nativos y períodos de servicio no para todo el host.
¿Y dónde se ve, sentado en una versión irrelevante de monitoreo, ni siquiera en LTS? Debemos mantenernos al día.
Además, al planificar la actualización, se descubrió un detalle interesante: el progreso no se detiene, puede tomar autos más rápidos a un precio más bajo. Y en el camino, encontré una manera de ahorrar en el ya innecesario servicio de alojamiento en varios proyectos de colegas. Como dicen, lo ingresamos con éxito.
Actualización de frente
No hay nada particularmente complicado en actualizar el zabbix ahora. Solicite un servidor, configúrelo, combine una copia de la base de datos. Coloque paquetes de monitoreo y muéstreles la base, ejecute zabbiks, y él actualizará todo por usted mismo, realizará todas las migraciones. Bueno, sí, probablemente sabes lo fácil que se ha vuelto la actualización de Zabbix.
En total, la migración de la base de datos tomó aproximadamente 15 minutos, e incluso sin muchos abusos. Y todo parece estar bien. ¿Eh? ¡No importa cómo! A pesar de que la IP del nuevo servidor no figura en las listas blancas de agentes, y recopila datos de solo unos pocos hosts de prueba, lo imposible todavía está sucediendo en él.
Para crédito de los desarrolladores de Zabbix, debo decir que mantienen su palabra: la versión 4.2 es compatible en ese momento. Después de hablar en el rastreador de proyectos, descubrimos que la razón de lo imposible es que no coincide con la estructura esperada de una de las tablas de la base de datos.
Vagas dudas entran sigilosamente. Será útil recordar que históricamente las tablas de base de datos Zabbix "más gruesas" han sido particionadas. En primer lugar, por razones de rendimiento, para cubrir de alguna manera su callo zabbix favorito, eliminando datos históricos en el RDBMS . Comparamos las estructuras de todas las tablas seguidas en una base de datos recién actualizada y una de control, creada por el servidor desde cero. Los temores fueron confirmados. Además de la falta de algunas constantes en la base de datos, en muchas tablas, muchas columnas digitales son del tipo incorrecto.
Es decir, de hecho, no tenemos un esquema base respaldado por los desarrolladores, sino nuestro propio "fork". Otro tipo de datos de columna es, potencialmente:
- otro costo de almacenamiento métrico
- diferente precisión de los números
- diferente velocidad de muestreo / grabación de métricas
¿Pensar para mejor? Es dudoso De acuerdo con la experiencia pasada con soporte técnico y desarrolladores de zabbix, pueden ajustar los DBMS.
Y este tipo de datos de columna es posible, pero difícil y largo de cambiar. Y es imposible sin una larga monitorización del tiempo de inactividad. Sin garantías de éxito, sin el apoyo del desarrollador en el futuro. Necesito otra forma.
Y Zabbix lo tiene. Porque en abril de 2019, saldrá zabbix-4.2
El segundo acercamiento al proyectil
La característica principal de 4.2 para nosotros es el soporte para la partición fuera de la caja usando TimescaleDB . Después de hablar con los representantes de Zabbix y familiarizarnos con los resultados de probar su soporte técnico para esta función ( traducción en el hub), decidimos probar la instalación con timecaledb y, en función de los resultados, tomar una decisión sobre la transición. Más específicamente: durante algún tiempo, todos los datos de monitoreo se escribirán en paralelo tanto a la versión anterior como a la nueva. Y luego simplemente cambiamos la entrada DNS.
Por supuesto, este enfoque no le permite guardar datos históricos y tendencias: la nueva base de datos se rellena desde cero. ¿Pero son realmente necesarios? La historia solo importa aquí y ahora, se acumulará bastante rápido de nuevo (mira el mismo prometeo). Solo queda la indudable utilidad de las tendencias para la planificación de la capacidad. En cualquier caso, el archivo con los datos ya recopilados permanece con nosotros (mirando hacia el futuro, fue útil para algunos clientes). Otra característica del soporte de timecaledb en zabbix es que los períodos individuales de almacenamiento de historial / tendencias ya no son válidos.
Tenemos clientes que insisten en el almacenamiento "eterno" de todos los datos recopilados a toda costa. Podemos ofrecerles que consideren la instalación / soporte de una instalación de monitoreo separada con configuraciones específicas. Nuestra tarea principal es garantizar el funcionamiento estable de los proyectos / servidores de los clientes, manteniendo un costo aceptable de los servicios, que también incluye el monitoreo.
En total, los siguientes pasos serán necesarios para la migración:
- Instalar y configurar una segunda instalación de monitoreo
- Obtenga todo lo mismo que en la primera instalación
- Switch!
Suena fácil, ¿verdad? De hecho, el primero no es muy difícil, porque durante el enfoque anterior escribimos un rol para instalar un servidor zabbix, es suficiente solo cargar la configuración. El tercer elemento también parece simple: cambiar DNS y todos los agentes zabbiks, proxies, clientes API y personas en vivo llegan a la nueva versión. Pero, ¿cómo hacer el segundo punto?
Al principio probamos un enfoque ingenuo. Importado desde el monitoreo actual, un par de las plantillas más utilizadas. Usando los scripts ya escritos para trabajar con la API, comenzamos los mismos proyectos en el nuevo monitoreo que en el actual, empujamos las ediciones a través de los sistemas SCM , agregando la IP de la nueva máquina al filtro de paquetes y a las directivas de los agentes Server / ServerActive . Incluso funcionó: muchos hosts comenzaron a registrarse en dos monitoreos a la vez, el nuevo les asignó plantillas y comenzó a recopilar datos en paralelo con el actual.
Por desgracia, este es precisamente el enfoque ingenuo de la migración, adecuado solo para la prueba. La carga resultante (en nvps ) no se pudo comparar con la instalación actual, siendo menor en órdenes de magnitud. Es entendible. En nuestro caso, el monitoreo es literalmente los años de trabajo de muchas personas y scripts, la quinta esencia de la experiencia en la operación de proyectos heterogéneos.
Por ejemplo, ¿qué pasa con los usuarios de forma manual y sus contraseñas, que se generan de forma aleatoria al crear proyectos, monitorear plantillas colgadas en hosts (con sus valores de macro personalizados), elementos creados manualmente, pantallas complejas, gráficos, paneles, períodos de servicio, proxies? Todo esto y mucho más necesita ser transferido para una migración sin problemas.
Afortunadamente, el zabbix tiene una funcionalidad incorporada para exportar / importar objetos, también disponible a través de la API. Por desgracia, cubre no más de la mitad de todas las instalaciones existentes. Y el código para usarlo también necesita ser escrito. En general, no puede simplemente tomar e importar la configuración de un zabbiks a otro.
¿O es posible?
Aquí, el cerebro recuerda útilmente la tarea del trabajo atrasado de que sería bueno organizar el almacenamiento del historial de configuración de monitoreo por medios externos. Por desgracia, este es un punto dolorido de Zabbix. Con referencia al artículo sobre el concentrador y el repositorio con código. Pero hay matices:
- el código no exporta todos los objetos de monitoreo a archivos YAML legibles por humanos (en particular, no todo lo que necesitamos)
- el código no admite la importación de objetos
Afortunadamente, hay personas que conocen un poco el lenguaje del proyecto (python) y tienen experiencia con la API de Zabbix. El único negocio es importar objetos de volcados YAML listos para usar. Por cuánto tiempo, por poco tiempo, pero después de tres semanas de trabajo y un centenar y medio de compromisos, un tenedor era bastante adecuado para nuestros propósitos. En realidad, por el bien de cuya presentación está escrito todo el artículo:
https://github.com/centosadmin/zabbix-review-export-import
Lo que se ha hecho:
- Se agregó soporte para muchos objetos nuevos
- Se ha cambiado el formato de exportación YAML de la mayoría de los objetos existentes para que puedan importarse
- Se agregó la capacidad de importar la mayoría de los objetos exportados
- Se agregó funcionalidad limitada para convertir objetos entre diferentes versiones de zabbix (como en nuestro caso)
La importación es soportada casi exclusivamente por la creación de nuevos objetos. Si existe un objeto, no se modificará. Esto nos permitió mantener la complejidad del código al menos en algunos marcos, ahorrar tiempo y aumentar la velocidad de trabajo de forma fría, al importar miles de objetos. Usar importación es muy simple:
./zabbix-import.py /path/to/file.yaml
(se supone que los parámetros de monitoreo objetivo se especifican en las variables de entorno, para más detalles, vea la salida --help )
En general, puede especificar cualquier número de archivos YAML de entrada, y todos ellos serán procesados. Pero teniendo en cuenta que existen muchas dependencias entre los objetos, tiene más sentido importar objetos tipo por tipo, comenzando por los más simples y básicos. Además, si importa un objeto de un archivo, puede tener sentido especificar explícitamente su tipo para acelerar un poco la importación: no se cargan todas las memorias caché, sino solo las necesarias.
Por lo tanto, dos repositorios aparecieron en nuestro hitlab con volcados YAML actualizados periódicamente de dos versiones de monitoreo, la actual y la nueva. Y, por supuesto, la capacidad de restaurar casi cualquier objeto de monitoreo en cualquier momento.
Implementación de monitoreo continuo y migración en sí
Como resultado, llegamos a la conclusión de que el gitlab según lo programado lanza una tubería en el repositorio del nuevo monitoreo, que, paso a paso, importa jerárquicamente un tipo de objetos tras otro del monitoreo anterior. Esto nos permitió importar la gran mayoría de los objetos y dar tiempo a nuestros equipos de administradores para solucionar con calma los problemas que surgieron, y no se han acumulado tanto a lo largo de los años. Los objetos "extra" no se eliminaron.
El problema con las contraseñas de usuario (también se exportan / importan, pero se asigna una contraseña aleatoria durante la creación) podría resolverse convirtiendo el volcado de SQL de la tabla con las credenciales de la supervisión actual en instrucciones SQL para establecer las contraseñas correctas en la nueva supervisión.
Para no recibir una doble porción de tareas durante la operación en paralelo, todas las acciones en la nueva supervisión se desactivaron inmediatamente y ya no se eliminaron.
Por lo tanto, el cambio fue bastante fácil y se redujo a los siguientes puntos:
- eliminar todos los hosts en la nueva supervisión (para esto se escriben un par de scripts sobre la API)
- extraiga SCM para actualizar la versión del proxy zabbix y cambiar los proxies a un nuevo servidor
- esperar la importación de hosts desde el volcado de la supervisión anterior
- cambiar registros DNS
(plan acortado para simplificar)
Que sigue
Por supuesto, el código no es perfecto ni particularmente bello. No importa todo, en particular, hay problemas con algunas plantillas: busque FIXME en el código. Pero eso fue suficiente para nosotros. Quizás este tenedor sea útil para alguien más. Una extensión lógica es el desarrollo de una operación similar de la utilidad Terraform , cuando la supervisión de destino se reduce completamente a la forma especificada, por ejemplo, por un directorio con volcados YAML. Incluyendo con la reducción de las instalaciones existentes a la forma deseada.
Esto le permitirá esperar tranquilamente el soporte HA "nativo" en zabbix, que tiene dos servidores, la configuración se sincroniza entre ellos automáticamente. Ahora debe conservar una réplica, servidores proxy y escribir scripts.
Camo viene?
Después de estudiar los materiales de las conferencias y reuniones, la hoja de ruta oficial, el rastreador de errores y la (modesta) experiencia de comunicación personal con los desarrolladores del zabbix, parece que comprenden perfectamente la situación en la que se encuentran ahora. Cuando comenzó el zabbix, los autores no pensaron en ningún IaC mientras resolvían sus problemas. Una década después, el producto maduró y floreció. La otra cara del éxito fue la gran cantidad de clientes de la empresa, cuyo monitoreo resuelve sus problemas. Y a quién no le gusta realmente la revolución. En las condiciones modernas, ellos, por un lado, están en contra de romper todo y comenzar desde cero. Por otro lado, a veces carecen de capacidades de monitoreo y miran "a un lado", sin olvidar expresar la lista de deseos a los desarrolladores de Zabbix. La compañía no los va a arriesgar, a pesar de cualquier simpatía por la juventud nueva, conveniente y de moda.
No veremos un nuevo prometeo correcto de Zabbix en el futuro cercano. No importa cómo me gustaría. Pero el trabajo está claramente sucediendo, y si usted, como el zabbix, es minucioso y paciente, el futuro también espera un futuro sin nubes.
Fuentes utilizadas:
- https://gitlab.com/devopshq/zabbix-review-export
- https://habr.com/en/company/pt/blog/433126/
- https://habr.com/en/company/zabbix/blog/458530/