Code review — инженерная практика в терминах гибкой методологии разработки. Это анализ (инспекция) кода с целью выявления ошибок, недочетов, расхождения в стиле написания кода и понимания, решает ли код поставленную задачу.
Сегодня расскажу о том, как мы организовали процесс review для конфигурации мониторинга в Zabbix. Статья будет полезна тем, кто работает с системой мониторинга Zabbix, как в большой команде, так в одиночку, даже если у вас «десять хостов, что там ревьюить».
Какие проблемы решаем
Для мониторинга наших внутренних сервисов и сборочной инфраструктуры мы используем Zabbix. У нас есть договоренности по именованию — name convention (используем ролевую модель с выделением Role, Profile шаблонов для мониторинга), но нет выделенной команды мониторинга (есть старшие инженеры, которые «собаку съели» в делах мониторинга), есть инженеры и младшие инженеры, ~500 хостов, ~150 шаблонов (небольшая, но очень динамичная инфраструктура).
Данная инфраструктура используется для поддержки и автоматизации процессов разработки в компании, помимо ее поддержки мы также разрабатываем инструменты автоматизации и интеграции, поэтому имеем небольшой опыт и понимание процессов разработки изнутри.
С ростом числа сотрудников и вводимых в систему мониторинга изменений все чаще стали встречаться типовые ошибки, которые было сложно отследить:
- Привязка item, trigger напрямую к хостам, вне шаблонов (и часть хостов остается без мониторинга).
- Неверные значение триггеров (вроде договорились о доступном месте в 3 ГБ, но опечатка, получаем никогда не работающий триггер в 34 ГБ).
- Несоблюдение name convention — и получаем непонятное имя триггера Script failed (хотя это означает, что не работает система доставки обновлений) или шаблона — Gitlab Templates (мониторинг чего, сервера или агента?).
- Отключение триггера, временное, для тестов. В итоге пропустили предупреждение на инфраструктуре и встали.
В мире программистов все эти проблемы решаются довольно просто: линтеры, с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 (или посмотрите на скриншоте). Сложно понять, какое состояние первоначальное, какое текущее, какие изменения были за неделю. Ситуация усложняется, когда у нас десятки изменений за неделю.
Хочется механизма, который позволит:
- Раз в неделю или после выполнения задачи по изменению логики мониторинга сделать слепок состояния системы.
- Сравнить текущий слепок конфигурации с прошлым слепком (diff).
- Автоматически проверить name convention.
- Проверить качество выполнения задачи, дать рекомендации, советы, обсуждать решения.
- Проверить, что изменения легитимные — все сделаны в соответствии с поставленной задачей.
- Использовать привычные инструменты для разработчиков — git, diff, mergerequest.
- Откатиться до какого-то состояния системы, но не потерять данные (поэтому бэкап не подходит).
- Контролировать сущности Zabbix — host, templates, action, macros, screen, map.
Теперь поговорим о том, как мы реализовали механизм и чем он может быть полезен вам для вашей инфраструктуры Zabbix.
Делаем Zabbix configuration review
Для хранения Zabbix-конфигурации используем следующие форматы:
- Оригинальные XML — экспортируются с помощью оригинального Zabbix Export. Используем для объектов host, template, screen. Есть особенности:
- в XML сложно читать и просматривать изменения;
- содержат все поля, в том числе незаполненные;
- содержат поле date — дата экспорта, его мы выпиливаем.
- Сырой JSON — некоторые типы объектов Zabbix не умеет экспортировать (actions, mediatypes), но они важны и хочется просматривать изменения, поэтому берем сырые данные из ZabbixAPI и сохраняем их в JSON.
- Читаемый YAML — обрабатываем экспортированный XML и сырой JSON и сохраняем в человекочитаемый, удобный, ванильный YAML. С ним легко глазами обрабатывать большие объемы изменений. Добавляем туда небольшие обработки:
- Удаляем поля без значений — спорный момент, так можем пропустить незаполненное поле, хотя оно должно быть заполненным, например поле с описанием проблемы у триггера (trigger.description). После обсуждения решили, что лучше будем убирать пустые поля, их слишком много. При желании можно поставить исключение на какие-то пустые поля и их не удалять.
- Удаляем даты — изменяются каждый раз и при мердж-реквестах показываются как изменения у каждого хоста.
- Можно по желанию добавить другие операции по наполнению информацией — в action пишутся userid вместо пользователей, к примеру.
Выделяем три git-репозитория (мы для хранения используем gitlab, но подойдут любые VCS):
- zabbix-review-export — тут будет храниться код для экспорта (Python-скрипты) и параметры для gitlab-ci jobs.
- zabbix-xml — храним XML+JSON, все в одной ветке. Ревьюить это дело тяжело и занимает много времени. Используется для восстановления состояния конфигурации Zabbix на определенное время.
- zabbix-yaml — наш основной репозиторий, тут делаем мердж-реквесты, смотрим изменения, обсуждаем принятые решения, мерджим в master если нет замечаний.
В эти репозитории сохраняем данные конфигурации, правила там следующие:
- группировка по типам объектов по папкам — полный список: https://gitlab.com/devopshq/zabbix-review-export#supported-objects
- один объект — один файл.
Теперь явно видим, какой тип объекта изменился, и понятно, какой объект изменился; на примере ниже изменился шаблон Profile. ScmDev. FlusContinuousTest.
Покажем на примерах
Для просмотра изменений используем механизм merge-request в gitlab.
Изменили шаблон Profile. DevOps. Test — поменяли выражение триггера. Шаблон, так как находится в папке templates:
Поменяли выражение в триггере и приоритет:
Прилинковали к одному шаблону другой:
Поменяли action — добавили в конец текста по умолчанию новую строку:
Пример обсуждений в мердж-реквестах (все как у программистов!) — видно, что подключили стандартный шаблон напрямую к хосту, но стоит выделить отдельную роль, на будущее. Скриншот со старого ревью, тогда еще использование XML-представление конфигурации.
В целом все просто:
- Добавили новый хост или другой объект — создался новый файл.
- Изменили хост или другой объект — посмотрели diff.
- Удалили — файл удалился.
Допустим, вы выполнили задачу и хотите попросить коллегу посмотреть, ничего ли не забыли. Запрашиваем ревью: для этого в репозитории zabbix-review-export запускаем gitlab-ci job с ручным запуском.
Назначаем мердж-реквест на коллегу, который смотрит, обсуждаете и правите код инфраструктуру мониторинга.
Раз в неделю запускается новое ревью, чтобы отслеживать небольшие изменения, для этого по расписанию (Schedule) делается экспорт и сохранение конфигурации в git-репозиторий (новым коммитом), и гуру мониторинга просматривает изменения.
Мягко стелешь, но надо попробовать
Теперь расскажем, как настроить данную систему ревью Zabbix-конфигурации (мы любим open source и стараемся делиться наработками с сообществом).
Возможны два варианта использования:
- Просто запускать скрипт экспорта руками — запустить скрипт, посмотреть изменения, сделать
git add * && git commit && git push. Такой вариант подходит для редких изменений или когда вы работаете с системой мониторинга один. - Использовать для автоматизации 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!
