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 если нет замечаний.

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

• группировка по типам объектов по папкам — полный список: https://gitlab.com/devopshq/zabbix-review-export#supported-objects
• один объект — один файл.

Теперь явно видим, какой тип объекта изменился, и понятно, какой объект изменился; на примере ниже изменился шаблон 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!