Database schema zabbix postgresql

Как мигрировать Zabbix с MySQL на PostgreSQL с минимальным downtime

В свете того, что Zabbix с некоторых пор поддерживает TimescaleDB, а тут еще и вышел новый LTS релиз Zabbix, то наверняка многие заинтересовались, как осуществить миграцию с MySQL на PostgreSQL.

Несмотря на текст на картинке, вполне можно просто так взять и мигрировать Zabbix с MySQL на PostgreSQL. В интернете есть немало рецептов такой миграции, например:

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

Ниже я опишу свое решение данной проблемы и те подводные камни, которые пришлось обходить по пути.

Важно упомянуть, что я до сих использую Zabbix 4.0. Возможно, в новых версиях схема БД поменялась и поэтапная миграция, описанная ниже, там невозможна.

Основная идея

Как известно, основной объем базы данных Zabbix сервера занимают исторические данные: таблицы истории и трендов (далее для краткости я буду называть эти данные историей). При этом сам Zabbix сервер способен без проблем запуститься и без этих данных. Сразу же возникает мысль: а что если при миграции для начала проигнорировать историю, запустить мониторинг, а уже затем разобраться с историей?

Подготовка

Я не буду по ходу статьи описывать все команды, например, как установить PostgreSQL. Думаю, в этой статье оно ни к чему, да и каждый сам может с этим справиться.

Установим нужное ПО:

  • PostgreSQL, в моем случае версию 12.
  • PgLoader 3.6.2. На версии 3.6.1 я мигрировать не смог из-за возникающих проблем.

Необходимо настроить PostgreSQL сервер и операционную систему, на которой он установлен.
Я также не буду подробно останавливаться на этой теме, так как пост не о тюнинге производительности, скажу лишь:

  • Очень рекомендую доклад Ильи Космодемьянского для общего понимания, в какую сторону тюнить PostgreSQL и ОС: https://habr.com/ru/post/505108/
  • Посмотрите, что рекомендует этот сервис: https://pgtune.leopard.in.ua/
  • Посмотрите описание параметров в документации: https://postgrespro.ru/docs/postgrespro/12/index.html

Также нужно до начала миграции настроить мониторинг PostgreSQL.
Так как я еще не переехал с версии Zabbix 4.0, то новеньким официальным шаблоном воспользоваться не могу, но мне отлично подошел вот этот:
https://github.com/lesovsky/zabbix-extensions/tree/master/files/postgresql

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

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

Последний момент подготовки перед миграцией — останавливаем Zabbix server:

Первый шаг миграции

Для начала, как и в любом другом мануале по миграции Zabbix, разделим файл schema.sql, расположенный в директории database/postgresql исходников zabbix, на 2 части:
в одной у нас будут CREATE, в другой ALTER.

Читайте также:  Как разбирать принтер kyocera

На выходе имеем 2 файла: create.sql, alter.sql

Применим файл create.sql к нашей БД:

Подготовим файл для pgloader — zabbix.load.config

Обратите внимание на строку

с ее помощью мы пропускаем таблицы истории

Ждем буквально минуту, проверяем, что ошибок при миграции нет (символ галки во втором столбце):

Применим файл alter.sql к нашей БД:

Полагаю, важно, что в файле alter.sql нет никаких упоминаний таблиц trend и history. По крайней мере в версии 4.0 именно так обстоят дела. Наверное, при ином раскладе были бы проблемы, т.к. в существующих в сети мануалах по миграции данные сначала загружаются в БД, а потом применяется alter.sql

Удалим пакеты Zabbix, связанные с MySQL и заменим их теми, что нужны для PostgreSQL. На этот раз я приведу примеры для CentOS 7, чтобы было понятно, какие пакеты нам нужны:

Сбросим настройки Web интерфейса Zabbix, чтобы заново пройти его настройку:

Укажем часовой пояс в файле:

Настроим новый zabbix_server.conf: укажем нужные значения в директивах DBHost, DBPort, DBUser, DBName, DBPassword.

Настала пора запустить наш Zabbix Server!

Идем по адресу web-интерфейса zabbix (http(s)://ip/zabbix), проходим по шагам мастера.

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

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

Второй шаг миграции

Теперь надо просто запустить миграцию истории, но чтобы этот процесс не сильно нагружал СУБД.

Так думал я, но все оказалось интереснее.

Перед вторым шагом миграции я решил создать в моем тестовом окружении нагрузку на Zabbix сервер. В тестовом окружении отсутствовали Zabbix прокси (это логично, так как мои основные прокси с тестовым сервером работать не намерены), так что нагрузку я решил создавать на самом сервере. Для этого с помощью API я создал около 200 хостов и попросил Zabbix сервер совершать проверки icmp и web checks к этим хостам каждую секунду. Получил около 1000 NVPS.

Очереди не росли, Zabbix server и PostgreSQL легко справлялись с такой нагрузкой.

Пора мигрировать историю.

Подготовим файл zabbix.load.data для pgloader:

Обратите внимание на строки:

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

говорит о том, что мигрировать в этот раз будут только таблицы истории.

Миграция истории началась, процесс этот может быть долгим. В моем случае при размере базы около 150 Гб и не самом сильном железе миграция истории занимает 4-5 часов.

Поначалу все шло хорошо. Потом я обнаружил, что загрузка CPU на PostgreSQL сервере растет линейно, и со временем ресурсов для нормальной работы уже не хватало (на графике load average на 1 ядро):

В логи Zabbix сервера сплошным полотном начали сыпаться медленные запросы SELECT. Как я понял, для того, чтобы совершить web check, нужно для начала сделать SELECT.

Я попробовал снизить интенсивность миграции. Для этого изменил следующие параметры в файле zabbix.load.data:

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

Читайте также:  Как делать прочистку головки на принтере

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

А также с количеством tuples, которые возвращала PostgreSQL клиентам в ответ на их запросы:

Идем в интернет, ищем информацию о том, как ведет себя PostgreSQL при длинных транзакциях. И находим вот такой замечательный доклад с конференции HighLoad:
https://www.youtube.com/watch?v=3h48iowNbwo

Советую посмотреть доклад, но если вкратце, то при наличии длинной транзакции в PostgreSQL не срабатывает механизм внутристраничной очистки (single-page cleanup). И это приводит к росту тех самых возвращаемых tuple. СУБД приходится разбираться, какой tuple ей нужен, что ведет к росту загрузки CPU.

Я проверил мою ситуацию — действительно, достаточно открыть транзакцию, создать в ней таблицу, а затем НЕ закрыть транзакцию:

У спустя некоторое время видим рост загрузки CPU:

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

Но это не всё. У меня все таки получилось сделать так, чтобы эта особенность PostgreSQL не мешала.

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

Я вынес все задачи сбора данных на прокси в тестовой инсталляции, сильно снизив нагрузку на Zabbix Server и PostgreSQL. И оказалось, что это помогло! После этого никакая длинная транзакция не создавала сверхвысокой нагрузки на CPU, не мешала мониторингу нормально работать. Ну либо по какой-то причине внутристраничная очистка PostgreSQL при таком сценарии заработала. Может быть знатоки PostgreSQL подскажут?

Заключение

Как оказалось, произвести миграцию Zabbix с MySQL на PostgreSQL с минимизацией downtime лишь немного сложнее стандартной миграции. Делайте тестовую инсталяцию, экспериментируйте, и все получится.

Спасибо всем, кто дочитал пост до конца. Надеюсь, он кому-то поможет спланировать и оттестировать миграцию.

Ну и конечно жду feedback, может быть более опытные коллеги укажут на недочеты.

Источник

Установка и первоначальная настройка ZABBIX

Перед установкой Zabbix, у Вас должен быть настроен и запущен сервер PostgreSQL или MySQL, с созданным пользователем zabbix и созданной базой zabbix.

Для управления системой мониторинга и чтения данных используется веб-интерфейс, написанный на PHP, соответственно должен быть настроен и запущен веб-сервер (Apache, Nginx).

Содержание

Установка Zabbix сервера [ править ]

Создание базы данных [ править ]

В процессе установки Zabbix сервера должна быть создана база данных Zabbix.

PostgreSQL [ править ]

В репозитории p10 на данный момент поддерживается несколько версий PostgreSQL. В данной статье мы будем использовать версию postgresql 13.

Установить PostgreSQL, Zabbix сервер и дополнительную утилиту fping :

Подготовить к запуску и настроить службы PostgreSQL:

    создать системные базы данных:

Создать базу данных Zabbix:

    создать пользователя zabbix (пароль необходимо запомнить) и базу данных zabbix (под правами root):

MySQL/MariaDB [ править ]

Установить сервер MySQL или MariaDB (в данном случае MariaDB), Zabbix сервер и дополнительную утилиту fping :

Включить по умолчанию и запустить службу mysqld:

Создать базу данных Zabbix:

    создать пользователя zabbix и базу данных zabbix (пароль необходимо запомнить):

Установка Apache2 [ править ]

Установить необходимые пакеты:

Добавить в автозапуск и запустить apache2:

Читайте также:  Hp designjet t790 замена картриджа

Установка PHP [ править ]

Все пакеты php можно устанавливать и эксплуатировать в одной системе одновременно, за исключением пакетов apache2-mod_php — они не умеют работать в одном адресном пространстве.

В данной статье для p10 используется версия php8.1.

Установить необходимые пакеты:

    если Zabbix устанавливается с PostgreSQL:

Изменить некоторые опции php в файле /etc/php/8.1/apache2-mod_php/php.ini (версия PHP может быть другой):

Настройка и запуск Zabbix сервера [ править ]

Внести изменения в конфигурационный файл /etc/zabbix/zabbix_server.conf :

В параметре DBPassword используйте пароль от MySQL базы данных Zabbix; пароль пользователя PosgreSQL для PosgreSQL.

Добавить Zabbix server в автозапуск и запустить его:

    если Zabbix устанавливается с PostgreSQL:

Установка веб-интерфейса Zabbix [ править ]

Включить аддоны в apache2:

Изменить права доступа к конфигурационному каталогу веб-интерфейса, чтобы веб-установщик мог записать конфигурационный файл:

В браузере перейти на страницу установки Zabbix сервера:

При первом заходе на страницу запустится мастер, который шаг за шагом проверит возможности веб-сервера, интерпретатора PHP и сконфигурирует подключение к базе данных.

Для начала установки необходимо нажать кнопку «Далее» («Next Step»), что осуществит переход на страницу проверки предварительных условий:

Необходимо доустановить то, что требуется и перейти на следующую страницу.

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

Если база в PostgreSQL, по умолчанию в качестве Database schema необходимо указать «public»:

На следующей странице можно задать имя сервера:

После окончания установки на экране будет отображаться форма входа в интерфейс управления системой мониторинга. Параметры доступа по умолчанию:

Войдя в систему, нужно сменить пароль пользователя ( Administration ▷ Users ), завести других пользователей и можно начать настраивать Zabbix.

Обновление с Zabbix4 до Zabbix5 [ править ]

После обновления необходимо изменить права доступа к новой директории с zabbix и изменить путь в конфигурационном файле:

Для того, чтобы из System information убрать предупреждение Database history tables upgraded: No необходимо остановить zabbix и обновить базу данных:

В файл /var/www/webapps/zabbix/ui/conf/zabbix.conf.php добавить параметр $DB[‘DOUBLE_IEEE754’] = ‘true’; и запустить zabbix:

Установка и первоначальная настройка клиента Zabbix [ править ]

Установить необходимый пакет:

Если Zabbix-агент устанавливается не на сам сервер мониторинга, то в файле конфигурации агента /etc/zabbix/zabbix_agentd.conf нужно задать следующие параметры:

где freeipa.example.test — имя узла мониторинга, которое будет указано на сервере Zabbix;

— адрес сервера, которому разрешено обращаться к агенту.

Добавить Zabbix-агент в автозапуск и запустить его:

Мониторинг CEPH [ править ]

Настройка ноды [ править ]

Установить на ноду CEPH необходимые пакеты:

Загрузить необходимые файлы:

Создать директорию и скопировать файлы:

Изменить путь расположения скрипта в файле zabbix_agent_ceph_plugin.conf :

Добавить скрипту права на запуск:

Настройка Zabbix сервера [ править ]

В веб-интерфейсе сервера необходимо перейти на вкладку Configuration ▷ Templates , нажать кнопку Import.

Импортировать файлы zbx_ceph_mon_template.xml zbx_ceph_osd_template.xml zbx_ceph_cluster_template.xml zbx_ceph_mds_template.xml из директории zabbix_templates , которая находится в склонированной раннее директории.

После импорта шаблонов необходимо их прикрепить к нужному хосту.

Возможные проблемы [ править ]

Не работает обнаружение при помощи ICMP Ping [ править ]

В журнале /var/log/zabbix/zabbix_server.log присутствуют различные ошибки касающиеся команд fping , fping6 :

    failed: /usr/sbin/fping6: can’t create raw socket (must run as root?) : Permission denied Для разрешения проблемы необходимо обеспечить запуск программ fping и fping6 с повышением привилегий. Так как сервер запускается от пользователя zabbix входящего в группу zabbix, то

Вы всегда можете проверить корректность работы команд fping и fping6 из терминала авторизовавшись пользователем zabbix:

Разрешения выполнения команды fping , управляемой control:

Источник

Поделиться с друзьями
КомпСовет
Adblock
detector