Как мы Zabbix обновляли08.10.2019 13:48

image
За что мы любим Prometheus? У него есть конфиг — взглянул и всё понятно, программа делает то, что ей сказали. Можно автоматизировать настройку мониторинга, хранить в VCS, ревьюить командой. Смержили твой MR, отработал пайплайн, новый конфиг применился к прометею. В общем, IaC во всей красе.

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

Как и многие, кто мониторит давно и у кого есть «голое» железо, мы используем Zabbix, который, кстати, на том железе и располагается. Увы, на данный момент заббикс и IaC — вещи не связанные. Настраивать заббикс можно или вручную, или через API.


Предыстория

В октябре 2018-го вышел Zabbix-4.0 — новая LTS ветка. И в середине марта мы начали планировать обновление на него нашей инсталляции версии 3.4.

Особых проблем с 3.4 почти не было:


  • Иногда где-то не срабатывал какой-то LLD и случалось Невозможное, которое неясно как отлаживать на неподдерживаемой разработчиком версии
  • Постоянно текла память HTTP-пуллеров — в результате чего заботливо настроенный systemd прибивал мониторинг и запускал его заново. Проблема маскировалась приличным объёмом памяти сервера. Проблема известная, задокументированная.

А в 4.0 появились интересные фичи вроде родных HTTP-итемов и периодов обслуживания не на весь хост целиком.

Да и где же это видано, на неактуальной версии мониторинга сидеть, даже не на LTS? Надо идти в ногу со временем.

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


Обновление «в лоб»

Ничего особо сложного в обновлении заббикса сейчас нет. Закажи сервер, проведи его настройку, слей копию базы. Поставь пакеты мониторинга и укажи им базу, запусти заббикс — и он тебе сам всё обновит, накатит все миграции. Ну да, наверное, вы знаете, каким лёгким стал апгрейд заббикса.

В сумме миграции БД заняли около 15-ти минут и даже без особой ругани. И вроде бы всё хорошо. Да? Как бы не так! Несмотря на то, что IP нового сервера не прописан в белых листах агентов, и он собирает данные лишь с нескольких тестовых хостов, на нём по прежнему стабильно происходит Невоможное.

К чести разработчиков заббикса надо сказать, они своё слово держат — версия 4.2 на тот момент поддерживается. После общения в трекере проекта мы выясняем, что причина невозможного в том что не совпадает с ожидаемой структура одной из таблиц БД.

Закрадываются смутные сомнения. Тут нелишне будет напомнить, что исторически самые «толстые» таблицы БД заббикса у нас секционированы. Прежде всего, из соображений производительности, чтобы хоть как-то прикрыть любимую мозоль заббикса — удаление исторических данных в РСУБД. Сравниваем структуры всех подряд таблиц в свежеобновлённой базе и контрольной — созданной самим сервером с нуля. Опасения подтвердились. Кроме отсутствия некоторых констрейнтов в БД, во множестве таблиц многие цифровые колонки имеют неправильный тип.

То есть, по факту, мы имеем не поддерживаемую разработчиками схему базы, а свой собственный «форк». Другой тип данных колонок это, потенциально:


  • другая стоимость хранения метрик
  • другая точность цифр
  • другая скорость выборки/записи метрик

Думаете, в лучшую сторону? Сомнительно. По прошлому опыту работы с техподдержкой и разработчиками заббикса, тюнить СУБД они умеют.

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

И его есть у заббикса. Потому что в апреле 2019-го выходит zabbix-4.2


Второй подход к снаряду

Основная фича 4.2 для нас — поддержка секционирования «из коробки» посредством TimescaleDB. Пообщавшись с представителями заббикса и ознакомившись с результатами тестирования его техподдержкой этой возможности (перевод на хабре), мы решаем протестировать инсталляцию с timescaledb и по результатам принять решение о переходе. Более конкретно: некоторое время у нас все данные мониторинга параллельно будут писаться и в старую, и в новую версии. А потом мы просто переключим запись в DNS.

Конечно, такой подход не позволяет сохранить данные истории и трендов — новая БД наполняется с нуля. Но так ли уж они нужны? История имеет значение только здесь и сейчас, она довольно быстро накопится заново (посмотрите на тот же прометей). Остаётся только несомненная полезность трендов для планирования мощностей. В любом случае, архив с уже собранными данными у нас остаётся (забегая вперёд — некоторым клиентам он пригодился). Ещё одна особенность поддержки timescaledb в заббиксе — перестают действовать индивидуальные периоды хранения истории/трендов.

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

Итого, для миграции потребуется выполнить следующие шаги:


  1. Установить и настроить вторую инсталляцию мониторинга
  2. Завести в ней всё то же самое, что и в первой инсталляции
  3. Переключиться!

Звучит просто, не так ли? Действительно, первое не очень сложно, ведь во время предыдущего подхода мы написали роль для установки заббикс-сервера, достаточно просто налить конфигурацию. Третий пункт тоже выглядит просто — переключаем DNS и все заббикс-агенты, прокси, клиенты API и живые люди попадают на новую версию. Но как сделать второй пункт?

Поначалу мы попробовали наивный подход. Импортировали из текущего мониторинга пару-тройку самых часто используемых шаблонов. Посредством уже написанных скриптов для работы с API завели в новом мониторинге те же самые проекты, что и в текущем, через системы SCM разлили по машинам правки, добавляющие IP новой машины в пакетный фильтр и в директивы Server/ServerActive агентов. Это даже сработало — множество хостов стали регистрироваться в двух мониторингах сразу, новый назначил им шаблоны и начал собирать данные параллельно с текущим.

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

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

На счастье, у заббикса есть встроенный функционал по экспорту/импорту объектов — доступный в том числе и через API. Увы, он покрывает не более половины всех существующих объектов. И код для его использования ещё и написать нужно. В общем, нельзя просто взять и импортировать конфигурацию одного заббикса в другой.


Или можно?

Тут мозг услужливо вспоминает задачу из бэклога о том, что неплохо было бы организовать хранение истории конфигурации мониторинга внешними средствами. Увы, это больное место заббикса. Со ссылкой на статью на хабре и репозиторий с кодом. Но есть нюансы:


  • код экспортирует в человекочитаемые YAML-файлы не все объекты мониторинга (в частности, не все нужным нам)
  • код не поддерживает импорта объектов

На удачу, есть люди немного знающие язык проекта (python) и имеющие опыт работы с заббикс API. Всего делов-то — сделать импорт объектов из готовых YAML-дампов. Долго ли, коротко ли, но после трёх недель работы и полутора сотен коммитов получился вполне годный для наших целей форк. Собственно, ради чьего представления и пишется вся статья:

https://github.com/centosadmin/zabbix-review-export-import

Что сделано:


  • Добавлена поддержка множества новых объектов
  • Изменён формат YAML-экспорта большей части существующих объектов так, чтобы их можно было импортировать
  • Добавлена возможность импорта большей части экспортированных объектов
  • Добавлена ограниченная функциональность по конвертации объектов между разными версиями заббикса (как в нашем случае)

Импорт поддерживается почти исключительно созданием новых объектов. Если объект существует, он не будет изменён. Это позволило удержать сложность кода хоть в каких-то рамках, сэкономить время и здорово увеличить скорость работы — при импорте тысяч объектов. Использовать импорт очень просто: 

./zabbix-import.py /path/to/file.yaml

(предполагается, что параметры целевого мониторинга указаны в переменных среды, подробнее в выводе --help)

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

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


Continuous monitoring deployment и сама миграция

В итоге мы пришли к тому, что гитлаб по расписанию запускает пайплайн на репозитории нового мониторинга, который шаг за шагом иерархически импортирует из старого мониторинга один тип объектов за другим. Это позволило импортировать подавляющее большинство объектов и дать нашим командам администраторов время спокойно починить вылезшие проблемы —, а их не так уж мало накопилось за годы. «Лишние» объекты не удалялись.

Вопрос с паролями пользователей — они тоже экспортируются/импортируются, но при создании назначается случайный пароль — удалось решить преобразованием SQL-дампа таблицы с учётными данными текущего мониторинга в SQL-операторы для установки правильных паролей в новом мониторинге.

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

Таким образом, переключение прошло довольно легко и свелось к следующим пунктам:


  • удалить все хосты в новом мониторинге (для этого написаны пара скриптов над API)
  • дёрнуть SCM-ы чтобы обновили версию zabbix-proxy и переключили прокси на новый сервер
  • дождаться импорта хостов из дампа старого мониторинга
  • переключить DNS-записи

(план сокращён в целях упрощения)


Что дальше?

Конечно, код не идеален и не особо красив. Он импортирует не всё, в частности, есть проблемы с некоторыми шаблонами — ищите FIXME в коде. Но для нас этого хватило. Возможно, этот форк пригодится кому-то ещё. Логичным продолжением видится развитие в сторону подобную работе утилиты Terraform, когда целевой мониторинг полностью приводится к виду, заданному, например, каталогом с YAML-дампами. В том числе и с приведением существующих объектов к нужному виду.

Это позволит спокойно дождаться «родной» поддержки HA в zabbix, имея два сервера, синхронизация настроек между которыми происходит автоматически. Сейчас приходится держать реплику, прокси и писать скрипты.


Камо грядеши?

После изучения материалов конференций и митапов, официального роадмапа, трекера ошибок и (скромного) опыта личного общения с разработчиками заббикса складывается впечатление, что они отлично понимают ситуацию, в которой сейчас оказались. Когда начинался заббикс, ни о каком IaC авторы не думали, решая свои задачи. Спустя десятилетие продукт возмужал и расцвёл. Оборотной стороной успеха стала набранная масса клиентов компании, у которых мониторинг решает их задачи. И которым не очень-то симпатичны революции. В современных условиях они, с одной стороны, против того, чтобы всё ломать и начинать с нуля. С другой стороны, они же местами испытывают недостаток возможностей мониторинга и смотрят «на сторону», не забывая озвучивать хотелки разработчикам заббикса. Рисковать ими компания не собирается, несмотря на любые симпатии к новому, удобному, модному, молодёжному.

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


Использованные источники:


  1. https://gitlab.com/devopshq/zabbix-review-export
  2. https://habr.com/ru/company/pt/blog/433126/
  3. https://habr.com/ru/company/zabbix/blog/458530/

© Habrahabr.ru