Revisión de código: práctica de ingeniería en términos de una metodología de desarrollo flexible. Este es un análisis (inspección) del código con el fin de identificar errores, deficiencias, discrepancias en el estilo de escribir el código y comprender si el código resuelve la tarea.
Hoy hablaré sobre cómo organizamos el proceso de revisión para monitorear la configuración en Zabbix. El artículo será útil para aquellos que trabajan con el sistema de monitoreo Zabbix, tanto en un equipo grande como solo, incluso si tiene "diez anfitriones, qué hay para revisar".
¿Qué problemas resolvemos?
Para monitorear nuestros servicios internos y construir infraestructura, usamos Zabbix. Tenemos convenciones de nomenclatura: convención de nombres ( utilizamos un modelo a seguir con resaltado de roles, plantillas de perfil para monitoreo), pero no hay un equipo de monitoreo dedicado (hay ingenieros superiores que “se comieron al perro” en asuntos de monitoreo), hay ingenieros e ingenieros junior, ~ 500 hosts, ~ 150 plantillas (infraestructura pequeña pero muy dinámica).
Esta infraestructura se utiliza para soportar y automatizar procesos de desarrollo en la empresa , además de su soporte, también desarrollamos herramientas de automatización e integración, por lo tanto, tenemos poca experiencia y comprensión de los procesos de desarrollo desde el interior.
Con el aumento en el número de empleados y los cambios introducidos en el sistema de monitoreo, comenzaron a ocurrir más y más errores típicos que eran difíciles de rastrear:
- Elemento de enlace, se dispara directamente a los hosts, fuera de las plantillas (y algunos hosts permanecen sin supervisión).
- Valor incorrecto de los activadores (más o menos acordado en un espacio disponible de 3 GB, pero un error tipográfico, obtenemos un activador que nunca funciona de 34 GB).
- Incumplimiento de la convención de nombres , y obtenemos el nombre incomprensible del desencadenador fallido del script (aunque esto significa que el sistema de entrega de actualizaciones no funciona) o la plantilla de plantillas de Gitlab (¿monitoreo de qué servidor o agente?).
- Deshabilitar un disparador, temporal, para pruebas. Como resultado, perdimos la advertencia sobre la infraestructura y nos pusimos de pie.
En el mundo de los programadores, todos estos problemas se resuelven de manera bastante simple: linter, codereview. Entonces, ¿por qué no tomar estas mejores prácticas para una revisión de configuración de Zabbix? ¡Tómalo!
Ya escribimos anteriormente sobre los pros y ejemplos de revisión de código: Implementación de inspecciones de código en el proceso de desarrollo , Un ejemplo práctico de implementación de inspección de código, Inspección de código . Resumen
Por qué podría necesitar una revisión de las configuraciones de Zabbix:
- Verifique que los hosts y las plantillas se nombren como aceptados en el comando ( convención de nombres ).
- Capacite a los nuevos empleados y verifique que hicieron la tarea como se discutió.
- Transfiera conocimiento entre empleados experimentados.
- El aviso se dispara accidentalmente o se apaga temporalmente.
- Observe los valores incorrectos en el elemento o activador: último (0) en lugar de mínimo (5 m) .
Agregue sus problemas en los comentarios, intente descubrir juntos cómo resolverlos con una revisión.
Como Zabbix con seguimiento de cambios
Zabbix tiene un subsistema de auditoría , con su ayuda observamos quién realizó cambios en la configuración. Su inconveniente importante es la gran cantidad de eventos guardados, ya que guarda cada evento de usuario.
Imagina que cualquier cambio en el código permanece en el historial de git, intentaste elegir el nombre de la variable durante una hora, intentaste 40 opciones y ahora todas se guardan, cada cambio es una confirmación por separado y luego envías el historial de estas confirmaciones a la revisión, sin la posibilidad de comparar el inicio y el final versión Horrible, ¿verdad?
Y en Zabbix Audit, eso es correcto. Se puede utilizar para realizar un seguimiento de los cambios, pero no le permite ver rápidamente la diferencia (diff) entre los dos estados del sistema (al comienzo de la semana y al final). Además, todas sus acciones están divididas por tipo: agregar, cambiar, eliminar deben verse en diferentes ventanas. Puede encontrar un ejemplo en su Zabbix en la pestaña Auditoría (o mire la captura de pantalla). Es difícil entender qué estado es inicial, qué es actual, qué cambios fueron durante la semana. La situación se complica cuando tenemos docenas de cambios por semana.
Quiero un mecanismo que permita:
- Una vez a la semana o después de completar la tarea de cambiar la lógica de monitoreo, haga un reparto del estado del sistema.
- Compare el nugget de configuración actual con el nugget anterior (diff).
- Verifique automáticamente la convención de nombres.
- Verifique la calidad de la tarea, brinde recomendaciones, consejos, discuta soluciones.
- Compruebe que los cambios son legítimos: todos se realizan de acuerdo con la tarea.
- Utilice herramientas familiares para desarrolladores: git, diff, mergerequest.
- Regrese a algún estado del sistema, pero no pierda datos (por lo tanto, la copia de seguridad no es adecuada).
- Controle las entidades de Zabbix: host, plantillas, acción, macros, pantalla, mapa.
Ahora hablemos sobre cómo implementamos el mecanismo y cómo puede serle útil para su infraestructura de Zabbix.
Hacer una revisión de configuración de Zabbix
Para almacenar la configuración de Zabbix, utilizamos los siguientes formatos:
- XML original: exportado utilizando la exportación original de Zabbix . Uso para host, plantilla, objetos de pantalla. Hay características:
- XML es difícil de leer y ver los cambios;
- contener todos los campos, incluidos los vacíos;
- contiene la fecha del campo - fecha de exportación, la recortamos.
- Raw JSON : algunos tipos de objetos que Zabbix no sabe cómo exportar (acciones, tipos de medios), pero son importantes y quiero ver los cambios, por lo que tomamos los datos sin procesar de ZabbixAPI y los guardamos en JSON.
- YAML legible: procesamos el XML exportado y JSON sin procesar y lo guardamos en YAML de vainilla, conveniente y legible para humanos. Con él, es fácil manejar grandes volúmenes de cambio con los ojos. Agregue un pequeño procesamiento allí:
- Eliminar campos sin valores es un punto discutible, por lo que podemos omitir un campo vacío, aunque debería rellenarse, por ejemplo, un campo con una descripción del problema en el desencadenante (trigger.description). Después de la discusión, se decidió que sería mejor eliminar los campos vacíos, ya que hay demasiados. Si lo desea, puede poner una excepción en algunos campos vacíos y no eliminarlos.
- Eliminamos las fechas: cambian cada vez y cuando las solicitudes de combinación se muestran como cambios para cada host.
- Opcionalmente, puede agregar otras operaciones para completar la información: el ID de usuario se escribe en acción en lugar de usuarios, por ejemplo.
Distinguimos tres repositorios de git (utilizamos gitlab para el almacenamiento, pero cualquier VCS servirá):
- zabbix-review-export : esto almacenará el código de exportación (scripts de Python) y los parámetros para trabajos gitlab-ci.
- zabbix-xml : almacenamos XML + JSON, todo en una sola rama. Revisar este negocio es difícil y lleva mucho tiempo. Se usa para restaurar el estado de configuración de Zabbix durante un tiempo específico.
- zabbix-yaml es nuestro repositorio principal, aquí fusionamos solicitudes, vemos los cambios, discutimos las decisiones tomadas, fusionamos en master si no hay comentarios.
En estos repositorios guardamos los datos de configuración, las reglas son las siguientes:
Ahora vemos claramente qué tipo de objeto ha cambiado, y está claro qué objeto ha cambiado; En el ejemplo a continuación, la plantilla de Perfil ha cambiado . Scmdev. FlusContinuousTest .
Mostrar en ejemplos
Para ver los cambios, utilizamos el mecanismo de solicitud de fusión en gitlab.
Cambió la plantilla de perfil. DevOps. Prueba : cambió la expresión de activación. Plantilla, como está en la carpeta de plantillas :
Cambió la expresión en el disparador y la prioridad:
Enlace a una plantilla a otra:
Cambió la acción: agregó una nueva línea al final del texto de forma predeterminada:
Un ejemplo de discusiones en las solicitudes de fusión (¡al igual que los programadores!): Se puede ver que conectaron la plantilla estándar directamente al host, pero vale la pena destacar un papel separado para el futuro. Captura de pantalla de la revisión anterior, y luego sigue utilizando la representación XML de la configuración.
En general, todo es simple:
- Se agregó un nuevo host u otro objeto: se creó un nuevo archivo.
- Cambió el host u otro objeto - parecía diff.
- Eliminado: el archivo fue eliminado.
Suponga que completó una tarea y desea pedirle a un colega que vea si ha olvidado algo. Solicitamos una revisión: para esto, en el repositorio zabbix-review-export , ejecute el trabajo gitlab-ci con un inicio manual.
Asignamos una solicitud de fusión a un colega que busca, discute y corrige la infraestructura de monitoreo de código.
Una vez a la semana, se inicia una nueva revisión para rastrear pequeños cambios, para esto, de acuerdo con el cronograma ( Schedule ), la configuración se exporta y se guarda en el repositorio git (con un nuevo commit), y el gurú de monitoreo revisa los cambios.
Te extiendes suavemente, pero tienes que intentar
Ahora le diremos cómo configurar este sistema para la revisión de configuración de Zabbix ( nos encanta el código abierto e intentamos compartir nuestras mejores prácticas con la comunidad).
Hay dos usos posibles:
- Simplemente ejecute el script de exportación a mano: ejecute el script, vea los cambios, haga que
git add * && git commit && git push . Esta opción es adecuada para cambios raros o cuando está trabajando solo con un sistema de monitoreo. - Use gitlab-ci para la automatización, entonces solo necesita hacer clic en el botón de inicio (vea la captura de pantalla anterior). La opción es más adecuada para grandes
perezoso equipos o con cambios frecuentes.
Ambas opciones se describen en el repositorio https://gitlab.com/devopshq/zabbix-review-export , todo lo que necesita está almacenado allí: scripts, configuración de gitlab-ci y README.md, cómo instalar su infraestructura.
Primero, pruebe la primera opción (o si no tiene la infraestructura gitlab-ci): use el modo manual: ejecute el script zabbix-export.py para exportar (hacer una copia de seguridad) de la configuración, git add * && git commit && git push en su máquina de trabajo. Cuando se canse, vaya a la segunda opción: ¡automatizar la automatización!
Problemas y posibles mejoras
Ahora los cambios están despersonalizados y para averiguar quién realizó los cambios, debe utilizar el sistema de auditoría , que causa dolor y sufrimiento. Pero no todo es tan aterrador y rara vez se necesita una auditoría, por lo general, un mensaje en el chat del equipo es suficiente para encontrar al empleado adecuado.
Otro problema: cuando un host o elemento cambia en un host, no está contenido en XML. Es decir, podemos desactivar todos los disparadores en un host específico o cambiar su prioridad a una más baja, ¡y nadie lo sabrá y nos corregirá! Estamos esperando una solución a esto en https://support.zabbix.com/browse/ZBX-15175
Hasta que se les ocurrió un mecanismo para la recuperación automática. Supongamos que una plantilla o un host cambian mucho, entendemos que los cambios son incorrectos y debe devolver todo tal como estaba. Ahora estamos buscando el XML necesario para el host correspondiente, importándolo manualmente a la interfaz de usuario, pero solo nos gustaría hacer clic en el botón "Revertir la plantilla TemplateName al estado commit-hash commit".
Puede implementar la sincronización bidireccional: cuando se realizan cambios en la configuración de Zabbix cuando se realizan cambios en YAML, no tiene que ir a la interfaz web del sistema Zabbix. En github conocimos un proyecto similar, pero de alguna manera se desvaneció rápidamente y la comunidad no aceptó la idea; aparentemente, no es tan fácil implementar en YAML lo que puede hacer clic con el mouse en la interfaz web. Por lo tanto, nos decidimos por la interacción unidireccional.
La opción ideal es integrar este sistema para guardar la configuración como código, incluso en formato XML, en Zabbix. Cómo se hace esto en el servidor de TeamCity CI : las configuraciones configuradas a través de la interfaz de usuario realizan confirmaciones en nombre del usuario que cambió la configuración. Resulta una herramienta muy conveniente para ver los cambios, y también elimina el problema de despersonalizar los cambios.
Prueba
Comience a exportar su configuración de Zabbix, comprométase con un repositorio (lo suficientemente local), espere una semana y vuelva a ejecutar. ¡Ahora los cambios están bajo tu control! https://gitlab.com/devopshq/zabbix-review-export
¿Quién estaría interesado en esta funcionalidad en el cuadro de Zabbix? Por favor vote por el tema https://support.zabbix.com/browse/ZBXNEXT-4862
¡Todo 100% de tiempo de actividad!