Привет!

Я Олег, системный администратор в команде Timeweb, и в этой статье я расскажу, как мы перешли на актуальную версию Zabbix с минимальным простоем без потери функциональности. Здесь будет описан наш опыт — опыт избавления инфраструктуры от неактуального ПО и последствий хардкода.

Обновить Zabbix или сохранить наработки? Вот в чем вопрос

Так уж сложилось, что сотрудники, ответственные за оперативное реагирование на проблемы, для наблюдения использовали один экран Zabbix с дополнительными самописными виджетами, захардкоженными в Zabbix GUI на PHP. Как, когда и почему это началось, история умалчивает… Часть данных запрашивалась из API Zabbix, часть — из сторонних систем. Всё это отображалось в виде таблицы. Кроме этого, существовала и вручную созданная таблица в базе Zabbix для хранения данных одного из виджетов.

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


Как это правило может быть реализовано? Хочешь красивые графики / дополнительную информацию — используй возможности Grafana.

Не менее важное условие — минимизация простоя сервиса наблюдения за инфраструктурой. На большом парке оборудования всегда что-то происходит. Своевременное реагирование на проблему уровня Warning позволяет нам избежать нелюбимых всеми ночных марш-бросков на рабочем месте.

Я опущу здесь этапы установки и настройки ПО. Если вам требуются инструкции, можно посмотреть документацию на официальном сайте.

Что было на старте:

• версия: Zabbix 2.2.2 и Zabbix-agent 3.0.12
• NVPS (New Values Per Second): 3600
• хранилище: 2x PostgreSQL 11
• количество хостов: 1450
• хардкод в GUI
• нативная авторизация

К чему хотели прийти:

• версия: Zabbix 5.0 LTS и Zabbix-agent 5.0
• без хардкода
• увеличение срока хранения показаний (30 дней истории, 90 дней тренды)
• перенос визуализации на внешние инструменты (Grafana)
• LDAP-авторизация
• оптимизация собираемых показаний

Муки выбора ПО

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

Для интеграции Zabbix + Grafana используем незаменимый плагин от Alexander Zobnin. Встроенный в него набор инструментов позволит организовать работу ответственных за наблюдение без существенных изменений в логике взаимодействия с GUI.

Да, использование Grafana в качестве базы для создания дашборда было доступно и в Zabbix 2.2.2, но не применялось: нужно было время на обучение команды и переход. В этот раз мы приняли для себя волевое решение — переключить работу сотрудников на новый инструмент, объединив переход на Grafana с обновлением Zabbix. Одновременно решаем сразу две задачи!

В качестве баз данных мы выбрали актуальную на момент работ версию PostgreSQL 12.4. Для увеличения интервала хранения решили использовать плагин TimescaleDB 1.7.4.

Тестирование

До начала работ мы провели синтетический нагрузочный тест связки Zabbix 5 + PostgreSQL 12.4 (+ TimescaleDB 1.7.4). Версии ПО выбирались по принципу актуальности из stable-релизов.

Для тестирования использовали проект Zabbix Server Stress Test. Количество метрик (NVPS) мы удвоили по сравнению со старым Zabbix, чтобы оценить, как повлияет увеличение числа наблюдаемых хостов в будущем. Под такой нагрузкой тестовая среда была оставлена на месяц.

Помимо проверки самого zabbix-server, это также позволило нам оценить работу плагина TimescaleDB. Глобально мы установили значения для истории значений и трендов, чтобы привести к единому порядку, а также включили сжатие.

Коэффициент сжатия на самой объемной таблице: 20 (20 ГБ сжаты до 1 ГБ). Средний коэффициент сжатия по всем таблицам: 19.

Определившись с решением, мы наметили для себя 2 плана действий: подготовительный план и план миграции. Они пригодятся, если вы тоже готовитесь к подобным изменениям.

План подготовительный

1. Поднять и настроить два экземпляра PostgreSQL с репликацией master-standby
2. Установить и настроить Zabbix 5 на работу с новым PostgreSQL
3. Перенести: регулярные выражения, value mappings, группы хостов, правила авторегистрации
4. Экспортировать / импортировать шаблоны:

— оформить в в виде примечания “В качестве инструмента работы из командой строки использовалась утилита https://github.com/unioslo/zabbix-cli”;
— так как формат экспортируемых ресурсов между релизами 2.2.2 и 5.0 претерпел изменения, необходимо было поправить XML, чтобы их принял новый Zabbix;
— переходить дальше не следует, пока все шаблоны не будут внесены в новый Zabbix, так как успешность импорта хостов зависит от наличия привязанных к ним шаблонов.

5. Добавить в конфигурацию zabbix-agent дополнительный сервер Zabbix

С этого момента данные начнут поступать в оба Zabbix (за исключением trapper-сообщений).

6. Экспорт / импорт хостов

Этот шаг нужен для того, чтобы получить базу для построения дашбордов средствами Grafana. Возможности авторегистрации не подходят из-за наличия персонально настроенных макросов на части серверов, которые нужны для корректной работы триггеров и сбора данных.

7. Создать дашборды на базе Grafana

Настраиваем источник данных на работу с новым Zabbix. Воспроизводим основной экран старого Zabbix средствами Grafana (+ плагин).

8. Анализ работы нового Zabbix

Оцениваем, как сервер справляется с нагрузкой:

• проверяем показания в разделе Очередей;
• проверяем показания из готового шаблона Template App Zabbix Server;
• использование дискового пространства на серверах с PostgreSQL;
• заглядываем в основной лог zabbix-сервера.

9. Тюнинг параметров zabbix-server и GUI, postgresql

Для подбора параметров PostgreSQL использовалась утилита timescaledb-tune. Параметры работы zabbix-server и GUI не претерпели серьезных изменений, лишь немного увеличены размеры кэшей и количество обработчиков.

10. Предварительная модификация скриптов, взаимодействующих с Zabbix API

К уже имевшимся скриптам добавился небольшой скрипт-обертка для синхронизации LDAP-списков с участниками Zabbix-групп. В остальных скриптах достаточно было изменить реквизиты подключения, проверить, что новый API корректно отдает нужные данные.

План миграции

1. Вводим мораторий на любые изменения в старом Zabbix
2. Очистка от ранее перенесенных хостов Zabbix

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

3. Если с момента подготовительных работ появились новые — переносим в свежую инсталляцию: регулярные выражения, value mappings, группы хостов

4. Создаем группы пользователей. Воспроизводим права доступа на группы хостов

5. Экспорт / импорт шаблонов

6. Экспорт / импорт хостов

7. Перенос веб-проверки, правила авторегистрации

В 2.2.2 не поддерживается экспорт данных элементов.

8. Проверка поступающих данных

На данном этапе оцениваем, что после миграции триггеры продолжают работать, как и ожидалось. Сравниваем возникающие события в обоих Zabbix.

9. Поменять местами серверы в конфигурации zabbix-agent

С этого момента основным инструментом наблюдения становится новый Zabbix.

10. Переключение скриптов, обращающихся к API Zabbix, на новый сервер


Схема взаимодействия компонентов мониторинга

Оптимизация

После завершения миграции мы решили проанализировать получаемые значения и оптимизировать их.

Для обнаружения маунтов и сетевых адаптеров мы использовали встроенный ключ, а невозможность фильтровать по нескольким макросам приводила к созданию лишних item’ов, с которых не требовалось собирать показания. Например:

• с нод KVM-виртуализации, где каждой виртуальной машине соответствует один сетевой адаптер;
• с клиентских серверов, где смонтированы резервные копии;
• с сервисных серверов, где краткосрочно запускается множество контейнеров;
• и другие, специфичные для нашей инфраструктуры.

Благодаря фильтрации обнаруживаемых item’ов удалось сократить NVPS c 3600 до 2500.

Похожего результата можно добиться и на старом zabbix: например, использовав собственные правила обнаружения.

Плюшки

На “Хабре” меня заинтересовала эта статья по применению Git для хранения ресурсов Zabbix, поэтому мы написали упрощенный вариант того, что предлагалось в работе «Zabbix Review: как организовать code review для конфигурации мониторинга».

Заключение

В заключении я хотел бы сказать, что работа по “миграции” на новый мониторинг не ограничивается исключительно техническими операциями, — существует набор регламентов по обработке событий, реакции на них. Конечно, команде потребуется некоторое время, чтобы привыкнуть к изменившимся инструментам анализа данных. Не забудьте рассказать коллегам об изменениях в инструментах заранее, до внедрения. Это поспособствует адаптации и подсветит важные вопросы.

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