За что мы любим 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 в заббиксе — перестают действовать индивидуальные периоды хранения истории/трендов.
У нас есть клиенты, которые настаивают на «вечном» хранений всех собранных данных любой ценой. Им мы можем предложить рассмотреть установку/поддержку отдельной инсталляции мониторинга со специфическими настройками. Наша основная задача — обеспечивать стабильную работу проектов/серверов клиентов при сохранений приемлемой стоимости услуг, в которую входит в том числе и мониторинг.
Итого, для миграции потребуется выполнить следующие шаги:
- Установить и настроить вторую инсталляцию мониторинга
- Завести в ней всё то же самое, что и в первой инсталляции
- Переключиться!
Звучит просто, не так ли? Действительно, первое не очень сложно, ведь во время предыдущего подхода мы написали роль для установки заббикс-сервера, достаточно просто налить конфигурацию. Третий пункт тоже выглядит просто — переключаем 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 авторы не думали, решая свои задачи. Спустя десятилетие продукт возмужал и расцвёл. Оборотной стороной успеха стала набранная масса клиентов компании, у которых мониторинг решает их задачи. И которым не очень-то симпатичны революции. В современных условиях они, с одной стороны, против того, чтобы всё ломать и начинать с нуля. С другой стороны, они же местами испытывают недостаток возможностей мониторинга и смотрят «на сторону», не забывая озвучивать хотелки разработчикам заббикса. Рисковать ими компания не собирается, несмотря на любые симпатии к новому, удобному, модному, молодёжному.
Нового, правильного прометея из заббикса мы в ближайшее время не увидим. Как ни хотелось бы. Но работа явно идёт — и если вы, как и заббикс, основательны и терпеливы, будущее вас также ожидает безоблачное.
Использованные источники:
- https://gitlab.com/devopshq/zabbix-review-export
- https://habr.com/ru/company/pt/blog/433126/
- https://habr.com/ru/company/zabbix/blog/458530/
Автор: Терешков Евгений
