Zabbix Review: как организовать code review для конфигурации мониторинга

    Code review — инженерная практика в терминах гибкой методологии разработки. Это анализ (инспекция) кода с целью выявления ошибок, недочетов, расхождения в стиле написания кода и понимания, решает ли код поставленную задачу.



    Сегодня расскажу о том, как мы организовали процесс review для конфигурации мониторинга в Zabbix. Статья будет полезна тем, кто работает с системой мониторинга Zabbix, как в большой команде, так в одиночку, даже если у вас «десять хостов, что там ревьюить».


    Какие проблемы решаем


    Для мониторинга наших внутренних сервисов и сборочной инфраструктуры мы используем Zabbix. У нас есть договоренности по именованию — name convention (используем ролевую модель с выделением Role, Profile шаблонов для мониторинга), но нет выделенной команды мониторинга (есть старшие инженеры, которые «собаку съели» в делах мониторинга), есть инженеры и младшие инженеры, ~500 хостов, ~150 шаблонов (небольшая, но очень динамичная инфраструктура).


    Данная инфраструктура используется для поддержки и автоматизации процессов разработки в компании, помимо ее поддержки мы также разрабатываем инструменты автоматизации и интеграции, поэтому имеем небольшой опыт и понимание процессов разработки изнутри.


    С ростом числа сотрудников и вводимых в систему мониторинга изменений все чаще стали встречаться типовые ошибки, которые было сложно отследить:


    1. Привязка item, trigger напрямую к хостам, вне шаблонов (и часть хостов остается без мониторинга).
    2. Неверные значение триггеров (вроде договорились о доступном месте в 3 ГБ, но опечатка, получаем никогда не работающий триггер в 34 ГБ).
    3. Несоблюдение name convention — и получаем непонятное имя триггера Script failed (хотя это означает, что не работает система доставки обновлений) или шаблона — Gitlab Templates (мониторинг чего, сервера или агента?).
    4. Отключение триггера, временное, для тестов. В итоге пропустили предупреждение на инфраструктуре и встали.

    В мире программистов все эти проблемы решаются довольно просто: линтеры, сodereview. Так почему бы не взять эти bestpractices и для ревью конфигурации Zabbix? Берем!



    Мы уже писали ранее о плюсах и примерах code review: Внедрение инспекций кода в процесс разработки, Практический пример внедрения инспекции кода, Инспекция кода. Итоги


    Зачем может понадобиться review Zabbix-конфигурации:


    • Проверить, что хосты и шаблоны названы так, как это принято в команде ( name convention).
    • Обучать новых сотрудников и проверить, что они сделали задачу так, как обговорили.
    • Передавать знания между опытными сотрудниками.
    • Заметить случайно или временно выключенные триггеры.
    • Заметить неправильные значения в item или trigger — last (0) вместо min (5m).

    Дополните своими проблемами в комментариях, попробуем вместе разобраться, как решить их с помощью review.


    Как у Zabbix с отслеживанием изменений


    Zabbix имеет подсистему Audit, с ее помощью мы смотрим, кто сделал изменения в конфигурации. Ее существенный недостаток — большое количество сохраненных событий, так как она сохраняет каждое событие пользователя.


    Представьте, что любое изменение кода остается в истории git, вы пытались в течение часа подобрать имя переменной, попробовали 40 вариантов и все они теперь сохранены, каждое изменение отдельным коммитом, — и потом отдаете на ревью историю этих коммитов, без возможности сравнить начальную и конечную версии. Ужасно, правда?


    А в Zabbix Audit именно так. С ее помощью можно отследить изменения, но она не позволяет быстро увидеть разницу (diff) между двумя состояниями системы (в начале недели и в конце). Кроме того, у нее все действия разделены по типам: добавление, изменение, удаление нужно смотреть в разных окнах. Пример можно найти в своем Zabbix на вкладке Audit (или посмотрите на скриншоте). Сложно понять, какое состояние первоначальное, какое текущее, какие изменения были за неделю. Ситуация усложняется, когда у нас десятки изменений за неделю.



    Хочется механизма, который позволит:


    1. Раз в неделю или после выполнения задачи по изменению логики мониторинга сделать слепок состояния системы.
    2. Сравнить текущий слепок конфигурации с прошлым слепком (diff).
    3. Автоматически проверить name convention.
    4. Проверить качество выполнения задачи, дать рекомендации, советы, обсуждать решения.
    5. Проверить, что изменения легитимные — все сделаны в соответствии с поставленной задачей.
    6. Использовать привычные инструменты для разработчиков — git, diff, mergerequest.
    7. Откатиться до какого-то состояния системы, но не потерять данные (поэтому бэкап не подходит).
    8. Контролировать сущности Zabbix — host, templates, action, macros, screen, map.

    Теперь поговорим о том, как мы реализовали механизм и чем он может быть полезен вам для вашей инфраструктуры Zabbix.


    Делаем Zabbix configuration review


    Для хранения Zabbix-конфигурации используем следующие форматы:


    1. Оригинальные XML — экспортируются с помощью оригинального Zabbix Export. Используем для объектов host, template, screen. Есть особенности:
      • в XML сложно читать и просматривать изменения;
      • содержат все поля, в том числе незаполненные;
      • содержат поле date — дата экспорта, его мы выпиливаем.
    2. Сырой JSON — некоторые типы объектов Zabbix не умеет экспортировать (actions, mediatypes), но они важны и хочется просматривать изменения, поэтому берем сырые данные из ZabbixAPI и сохраняем их в JSON.
    3. Читаемый YAML — обрабатываем экспортированный XML и сырой JSON и сохраняем в человекочитаемый, удобный, ванильный YAML. С ним легко глазами обрабатывать большие объемы изменений. Добавляем туда небольшие обработки:
      • Удаляем поля без значений — спорный момент, так можем пропустить незаполненное поле, хотя оно должно быть заполненным, например поле с описанием проблемы у триггера (trigger.description). После обсуждения решили, что лучше будем убирать пустые поля, их слишком много. При желании можно поставить исключение на какие-то пустые поля и их не удалять.
      • Удаляем даты — изменяются каждый раз и при мердж-реквестах показываются как изменения у каждого хоста.
      • Можно по желанию добавить другие операции по наполнению информацией — в action пишутся userid вместо пользователей, к примеру.

    Выделяем три git-репозитория (мы для хранения используем gitlab, но подойдут любые VCS):


    1. zabbix-review-export — тут будет храниться код для экспорта (Python-скрипты) и параметры для gitlab-ci jobs.
    2. zabbix-xml — храним XML+JSON, все в одной ветке. Ревьюить это дело тяжело и занимает много времени. Используется для восстановления состояния конфигурации Zabbix на определенное время.
    3. zabbix-yaml — наш основной репозиторий, тут делаем мердж-реквесты, смотрим изменения, обсуждаем принятые решения, мерджим в master если нет замечаний.

    В эти репозитории сохраняем данные конфигурации, правила там следующие:



    Теперь явно видим, какой тип объекта изменился, и понятно, какой объект изменился; на примере ниже изменился шаблон Profile. ScmDev. FlusContinuousTest.



    Покажем на примерах


    Для просмотра изменений используем механизм merge-request в gitlab.


    Изменили шаблон Profile. DevOps. Test — поменяли выражение триггера. Шаблон, так как находится в папке templates:


    Поменяли выражение в триггере и приоритет:


    Прилинковали к одному шаблону другой:


    Поменяли action — добавили в конец текста по умолчанию новую строку:


    Пример обсуждений в мердж-реквестах (все как у программистов!) — видно, что подключили стандартный шаблон напрямую к хосту, но стоит выделить отдельную роль, на будущее. Скриншот со старого ревью, тогда еще использование XML-представление конфигурации.


    В целом все просто:


    1. Добавили новый хост или другой объект — создался новый файл.
    2. Изменили хост или другой объект — посмотрели diff.
    3. Удалили — файл удалился.

    Допустим, вы выполнили задачу и хотите попросить коллегу посмотреть, ничего ли не забыли. Запрашиваем ревью: для этого в репозитории zabbix-review-export запускаем gitlab-ci job с ручным запуском.


    Назначаем мердж-реквест на коллегу, который смотрит, обсуждаете и правите код инфраструктуру мониторинга.


    Раз в неделю запускается новое ревью, чтобы отслеживать небольшие изменения, для этого по расписанию (Schedule) делается экспорт и сохранение конфигурации в git-репозиторий (новым коммитом), и гуру мониторинга просматривает изменения.


    Мягко стелешь, но надо попробовать


    Теперь расскажем, как настроить данную систему ревью Zabbix-конфигурации (мы любим open source и стараемся делиться наработками с сообществом).


    Возможны два варианта использования:


    1. Просто запускать скрипт экспорта руками — запустить скрипт, посмотреть изменения, сделать git add * && git commit && git push. Такой вариант подходит для редких изменений или когда вы работаете с системой мониторинга один.
    2. Использовать для автоматизации gitlab-ci — тогда вам лишь нужно кликнуть на кнопку запуска (смотрите выше скриншот). Вариант больше подходит для больших ленивых команд или при частых изменениях.

    Оба варианта описаны в репозитории https://gitlab.com/devopshq/zabbix-review-export, там хранится все необходимое — скрипты, настройки gitlab-ci и README.md, как поставить в свою инфраструктуру.


    Для начала попробуйте первый вариант (или если у вас нет инфраструктуры gitlab-ci): используйте ручной режим — запускайте скрипт zabbix-export.py для экспорта (бэкапа) конфигурации, git add * && git commit && git push делайте на своей рабочей машине. Когда надоест, переходите ко второму варианту — автоматизируйте автоматизацию!


    Проблемы и возможные улучшения


    Сейчас изменения обезличены и чтобы узнать, кто вносил изменения, нужно пользоваться системой Audit, что вызывает боль и страдания. Но не все так страшно, и Audit редко нужен, обычно достаточно сообщения в командном чате, чтобы найти нужного сотрудника.


    Еще одна проблема: при изменении в хосте item или trigger оно не содержится в XML. То есть мы можем выключить все триггеры на конкретном хосте или поменять им приоритет на более низкий — и никто об этом не узнает и не поправит нас! Мы ждем исправления этого в https://support.zabbix.com/browse/ZBX-15175


    Пока не придумали механизм автоматического восстановления. Допустим, шаблон или хост сильно изменен, поняли, что изменения неверны и нужно вернуть все как было. Сейчас мы ищем нужную XML для соответствующего хоста, импортируем вручную в UI, а хотелось бы просто нажать кнопку «Откатить шаблон TemplateName до состояния коммита commit-hash».


    Можно реализовать двухстороннюю синхронизацию — когда при изменениях в YAML создаются изменения в Zabbix-конфигурации, тогда не придется и заходить в веб-интерфейс системы Zabbix. На github встречали подобный проект, но он как-то быстро угас и сообщество не восприняло идею; видимо, не так просто реализовывать в YAML то, что можно накликать мышкой в веб-интерфейсе. Поэтому остановились на взаимодействии в одну сторону.


    Идеальный вариант — встроить данную систему сохранения конфигурации как код, хотя бы просто XML-формата, в Zabbix. Как это сделано в CI-сервере TeamCity: конфигурации, настроенные через UI, делают коммиты от имени пользователя, который изменил конфигурацию. Получается очень удобный инструмент для просмотра изменений, а также устраняется проблема с обезличиванием изменений.


    Попробуйте


    Запустите экспорт вашей конфигурации Zabbix, закоммитьте в репозиторий (достаточно локального), подождите неделю и запустите снова. Теперь изменения у вас под контролем! https://gitlab.com/devopshq/zabbix-review-export


    Кому была бы интересна данная функциональность в коробке Zabbix — прошу голосовать за issue https://support.zabbix.com/browse/ZBXNEXT-4862


    Всем 100% uptime!

    • +12
    • 4,5k
    • 5
    Positive Technologies
    242,00
    Компания
    Поделиться публикацией

    Комментарии 5

      0
      Интересный подход.
        0
        Вся конфигурация лежит в базе данных. Зачем дублировать это еще и в XML?
        Запросы к БД решают всё. В том числе — к событиям аудита.
        Уж если и просить новую фичу — то API к событиям аудита, а не «configuration as code».
        Ваш подход напоминает велосипедостроение — без обид.
          0
          Дублируем в XML и YAML. XML для возможности импорта (отката) обратно, YAML для удобства чтения и ревью.
          Запрос к API к событиями аудита и выставление данных в той форме, которая необходима для ревью (возможность комментировать, диффать, быстро понимать какие изменения произошли) сложнее реализовать чем предложенный выше подход.
          За спрос денег не берут, мы попросили что кажется важнее для нас, т.к. мы с таким подходом работали и понимаем насколько он удобен.
          Если комбинацию из уже существующих инструментов принято называть велосипедом — то да, это велосипед, но он отлично едет.
          0
          allburov Спасибо за статью. Скажите задумывались ли вы над темой Zabbix как Код или полное управление Zabbix только через скрипты/API?
            0
            Задумывались, смотрели готовые решения Zabbix as Code, есть интересное (https://github.com/adubkov/zabbixcli), но видимо не взлетело, изменения были 4 года назад. Реализовывать и поддерживать такую систему сложно, поэтому решили не делать, не те объемы работ с заббиксом.

            Управление через API хорошо идет с software configuration management, когда у тебя создаются VM, на них накатываются определенные роли, и автоматом создаётся и хост в заббикс и прикрепляются шаблоны. Но наполнение профилей\ролей идет по прежнему в ручную, через UI. К такому решению идем, но пока не реализовали. Готовые модули есть и для ansible и для salt, можно брать и использовать.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое