Comments 19
протестируйте еще и на стенде с glaber.io но только 1 сервер используйте и без проксей, и без жестких оптимизаций субд
Спасибо за отсылку к Glaber, обязательно попробуем! ClickHouse конечно обеспечит высокую производительность, давно шли разговоры про поддержку ClickHouse для Zabbix. В недалёком будущем может и сам Zabbix станет поддерживать ClickHouse. А может в 12 версии PostgreSQL появится поддержка внешних подключаемых источников данных, в числе которых тоже окажется ClickHouse. Поживём — увидим) Сейчас учёка в Glaber хранится тоже в ClickHouse? Нет ли сильных расхождений по документации с Zabbix?
http://t.me/glaber_group
задайте вопрос в нашей группе и тегните http://t.me/makurov
Конечно так и должно быть, просто сам Zabbix заявляет, что они ещё не в полной мере подружили TimescaleDB со внутренним механизмом формирования SQL запросов сервера Zabbix, обещают в версии 4.4 окончательно задействовать весь потенциал tsdb. В tsdb и так уже есть партиционирование — деление гипертаблиц на чанки. Обязательно разверну тот же самый мониторинг, но с tsdb и сравню эти подходы. На момент написания этой статьи была только версия Zabbix 4.0 без поддержки tsdb — дело было весной, просто только сейчас дошли руки систематизировать материал и поделиться с общественностью. Ведь в основном статья про способы оптимизации БД PostgreSQL — то, что может пригодиться большинству новичков и даже некоторым бывалым DBA.
Если вы имеете ввиду обновление чисто БД без обновления версии самого Zabbix, то алгоритм примерно такой:
- удаляете старые индексы на таблицах данных мониторинга и создаёте новые индексы нужного типа, как описано в статье (можно не весь скрипт разом, а по одной таблице — посмотрите как пойдёт процесс по скорости, постройте пару выборок до и после чтобы сравнить)
- настраиваете партиционирование так же по одной таблице, в статье описаны нужные функции
- отключаете удаление истории в админке через hausekeeper
- регистрируете хранимую функцию автоудаления устаревших партиций delete_old_partitions и регистрируете специальный элемент данных для хоста zabbix сервера типа "Мониторинг БД" с параметрами, как описаны в статье.
Сам сервер Zabbix при этом не должен ничего почувствовать — все изменения происходят только в БД и для него работа с партиционированными таблицами будет происходить как раньше, т.е. с теми же именами таблиц родителей (history, hostory_uint, trends, trends_uint и т.д.). Но нужно учитывать вашу нагрузку по данным мониторинга, если у вас она экстримальная, то возможно стоит делать обновление более "нежным" и в другом порядке: удалить индексы, выполнить партиционирование, добавить новые индексы (только при этом новые индексы придётся создавать руками для каждой партиции — поэтому я бы всё таки сначала поменял индексы, а уже потом выполнил партиционирование). В любом случае лучше делать это в часы наименьшей нагрузки, например, в 2 часа звёздной субботней ночью :D
Тогда это больше вопрос по самому Zabbix — в документации есть общая инструкция для обновления компонентов между версиями:
https://www.zabbix.com/documentation/devel/ru/manual/installation/upgrade/sources
Версия 4.4 ещё в разработке) Я бы посоветовал вам сравнить файлы разметки БД для версии с которой собираетесь обновляться и версию, на которую собираетесь переходить. Внимательно изучите разделы "Что нового" между этими версиями. В версиях 4.х БД PostgreSQL вряд ли меняется — единственное нововведение, это появление расширения TimescaleDB, но и его установка вообще дело добровольное.
Вы вынелси каталог БД на отдельный диск. Далее можно и wal-файлы складывать на отдельный диск. Даже обычного SATA должно хватить на много т.к. производится последовательная запись.
Здравствуйте! Можете примерно ввести в курс дела понимания термина экстримальные нагрузки. К примеру у нас вертетится zabbix 4.2 на bl460 схд vnx5300 кажется на виртуалки vmware 2ядра 8gb. Сколько для него узлов сети (snmp) и агентских (winserver) будут критической нагрузкой. Сейчас просто подключено далеко не всё, процентов(!) 10 всех желаемых хостов железяк на мониторинг. Передэодически вылазит уже предупреждение овер75% CPU in use.
P.s. ставил готовый appliance там вроде MySQL.
Не очень разбираюсь во всех этих кишках БД, уж извините.
Экстремальные нагрузки по моему ИМХО — от 10к параметров в секунду. Наш тест держит 3333 в секунду и это для него не предел. У вас виртуалка — сразу потеря мощности, видимо развернули образ с Ubuntu с сайта Zabbix, он только «чтобы посмотреть». Разверните нормальный CentOS или Debian, сразу разница будет. Как опрашиваете хосты — активный опрос тоже минус к скорости. Хороший вариант — почти все параметры хостов пассивные, приходят от активного прокси, прокси уже активно спрашивает параметры хостов (если есть активные агенты — ещё лучше, тем более если NAT). Сейчас для хорошей производительности Zabbix нужно либо настраивать PostgreSQL + tsdb, либо разворачивать glaber.io с ClickHouse, как написал товарищ denaspireone в первом комментарии, который кстати является разработчиком) Мы с Zabbix разобрались не за один день, причём до сих пор поверхностно, так что дерзайте! Стратегии разворачивания, успешные кейсы и практики — известны и описаны в сети, моя статья больше про PostgreSQL, на самом деле :)
А где параметры запросов в секунду увидеть?
За идею с проксями спс. Natа нет.
В очередях всегда по нулями.
Насчёт того, что centos прям полетит по сравнению с Ubuntu server терзают сомнения.
Нельзя указать фильтр по имени диска (например я хочу мониторить только sd* диски, а не все подряд)
Также у меня iostat выводит «Devices», не «Devices:» (sysstat 12.0.6)
— system.run для lsblk с выводом в json (zabbix 4.2 и шифрование до агента/прокси)
— нативная поддержка в zabbix 4.4
Все остальные поделки с userparameter и zabbix_sender должны быть списаны в утиль.
Всё ИМХО, конечно же.
Улучшение производительности Zabbix + PostgreSQL при помощи партиционирования и индексирования