Привет! Меня зовут Антон Касимов, я руководитель Gals Software, а еще сертифицированный тренер и эксперт по Zabbix. В общем, могу сказать, что знаю эту систему чуть больше уровня «видел пару раз интерфейс». Zabbix — одна из самых популярных в мире систем мониторинга. Наверное, не существует компаний с собственной инфраструктурой, у которых не было бы Zabbix. Не так давно мы запустили услугу аудита Zabbix и обнаружили некоторые закономерности, на которые я хотел бы обратить внимание в этой статье. В нашем телеграм-канале Zabbix Recipes мы регулрно делимся нашими находками и публикуем анонсы вебинаров (скоро и по этой теме тоже будет), поэтому приглашаю присоединиться. Я построю повествование так, чтобы вы могли пройтись по статье как по чек-листу и проверить свою инсталляцию на предмет возможных улучшений. Погнали!

Состояние отдельных компонентов

Zabbix — распределенная система, поэтому первое на что я смотрю, это версит отдельных компонентов: агентов и прокси. Частая проблема — это зоопарк версий агентов. Обычно, конечные серверы находятся под управлением администраторов отдельных систем и прямого доступа у администраторов Zabbix к ним нет, а следовательно, и возможности систематического применения обновлений. Ключ agent.version возвращает текущую версию агента. Зайдите в Latest data, настройте фильтр по этому ключу и посмотрите какие версии агентов присутствуют в вашем окружении. Вероятно, вы будете удивлены. Устаревшая версия агента может быть проблемой, если вы обновляете шаблоны вместе с обновлением Zabbix сервера: некоторые ключи могут не поддерживаться старыми версиями агентов. Например, параметр `HeartbeatFrequency`, который управляет периодичностью отправки heartbeat-сообщений на сервер появился только в версии 6.4. Балансировка нагрузки агентов между группами прокси появилась начиная с 7 версии. Не обновляя версии агентов вы лишаетесь возможности использования этого функционала.

Задержка с обновлением Zabbix-прокси более редкая проблема, однако, тоже встречается. Начиная с версии 6.4 обновления конфигурации начали выполняться 1 раз в 10 секунд и инкрементально. До этой версии обновления конфигурации происходили по умолчанию 1 раз в 1 минуту и полностью. Запрос конфигурации считается одним из самых тяжелых SQL-запросов в базу. А с 7 версии появился функционал отказоустойчивости и выскокой доступности прокси. Соответственно, обновившись, вы получаете и то и другое.

Отсутствие шифрования — еще один момент, на который я обращаю внимание. Между компонентами Zabbix часто передается чувствительная информация (логины/пароли) и шифрование лишним также не будет. То же самое касается и шифрования между фронтэндом, сервером и базой данных. Безопасники не приедут за вами на УАЗике, а вместо этого скажут вам спасибо.

Одна из частых ошибок настрок конфигурации агентов — параметр AllowKey=system.run[*]. Это критически небезопасная настройка, т.к. позволяет выполнять произвольные команды через агент. Если нужно выполнять какие-то скрипты через ключ system.run[*], разрешите выполнения конкретной команды.

Состояние базы данных

Многое зависит от того, какую СУБД вы используете. Например, с версии 7.2 в Zabbix пропала официальная поддержка Oracle. До этого вы могли обеспечить поддержку, собрав компоненты из исходников. Если же используете MySQL/MariaDB обратите внимание на то, что ваша СУБД имеет настройки партиционирования исторических таблиц (history, history_uint и остальных). В этом случае вы отключаете встроенных хаускипинг и удаляете старые партиции при помощи скрипта в кроне. Если используете PostgreSQL с TimescaleDB на борту, то хаускипинг нужно оставить включенным — удаление чанков поддерживается из коробки.

Для случая с PostgreSQL приведу небольшой разбор конфигурации, чтобы было понятно на что обратить внимание. Я не DBA, поэтому заранее прошу простить за возможную корявость формулировок.

max_connections — важный параметр, определяющий максимальное количество подключений к БД. Кажется, что подключений много не бывает, но это не всегда так. Слишком высокий лимит часто ухудшает производительность из-за конкуренции за CPU, память и контекстных переключений. Если нет внешнего пула соединений, это может стать источником проблем. Рекомендую прикрутить PgBouncer в режиме transaction pooling в качестве внешнего пула для возможности снижения значения этого параметра.

shared_buffers — параметр конфигурации, который определяет объем памяти (RAM), выделяемый серверу для кэширования данных. Хорошая практика — 25% от общего объема RAM на сервере.

effective_cache_size — это сколько данных в сумме вы сможете удержать в памяти, если сложить shared_buffers и кэш операционной системы. Рекомендация — 50% – 75% от общего объема RAM.

Пример: если на сервере 16 ГБ RAM, то shared_buffers можно выставить в 4 ГБ, а effective_cache_size в 12 ГБ.

work_mem — память на одну операцию сортировки/хеша (не на сессию). Напрямую связан max_connections. Поэтому увеличивать безопасно этот параметр можно при условии снижения `max_connections` при условии подключения того же PgBouncer, к примеру.

Можно рассмотреть вариант добавление параметра архивирования WAL-сегментов archive_command = 'test ! -f /pgarchlog/%f && cp %p /pgarchlog/%f.part && mv /pgarchlog/%f.part /pgarchlog/%f', который сначала копирует WAL во временный файл, потом атомарно переименовывает. Использовать совместно с archive_mode = always.

autovacuum_max_workers и autovacuum_work_mem — количество воркеров автовакуума и память на autovacuum. Рекомендую обращать на эти параметры внимание.

wal_compression = on — настройка, которая сжимает full-page writes, что уменьшает интенсивность записи на диск.

Базу данных использует множество процессов Zabbix сервер, а также фронтэнд. Следовательно, важно постоянно отслеживать самочувствие СУБД. Один из наших клиентов столкнулся с проблемой периодической утилизации в 100% одного из DBSyncer, при этом остальные чувствовали себя хорошо. Оказалось, что один из коллег регулярно запрашивал через API большие объемы исторических данных. Удалось выяснить путем продвинутого логирования на nginx-сервере. Не забывайте, что вы можете повышать уровень логирования отдельных процессов Zabbix сервера для точечной диагностики.

И еще одно немаловажное замечание: сделайте отдельные учетки в БД для Zabbix сервер и фронтэнда. Когда-нибудь это поможет вам быстрее диагностировать проблему.

Рекомендации по снижению объема данных в БД

1. Включить троттлинг (throttling)

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

Где искать: в правилах препроцессинга.

В Zabbix возможна настройка троттлинга двух видов:

- Discard unchanged — игнор повторяющихся значений. В этом случае график будет пустым, если метрика не меняется.

- Discard unchanged with heartbeat — игнор повторяющихся значений, но с регулярной проверкой жива ли метрика. На графике будут значения. Этот параметр препроцессинга требует ввода периода проверки. Если данные собираются раз в секунду, а интервал задан одной минутой, то Zabbix превратит ежесекундный поток значений в ежеминутный поток.

2. Настроить переменное значение периода сбора данных

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

wd1-5h9 — каждый день с понедельника по пятницу в 9:00.

h9m/30;h11 — каждый день в 9:00, 9:30, 10:00, 10:30, 11:00.

h9-10m10-40/30 — каждый день в 9:10, 9:40, 10:10, 10:40.

md1wd1h9m30 — каждый первый день месяца в 9:30 если это понедельник.

Где искать: в настройках элементов данных (items), раздел пользовательский интервал (custom interval).

3. Удалять значение исходного элемента данных для зависимых элементов данных

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

Где искать: в настройках элементов данных, раздел период хранения истории. Установить значение в «не хранить».

Состояние Nginx

По возможности включайте http2. Т.е. вместо listen 443 ssl; нужно указывать listen 443 ssl http2;. Интерфейс Zabbix грузит CSS, JS, шрифты, изображения, а HTTP/2 обычно уменьшает задержки и улучшает загрузку страницы.

И, если еще не включили, можно активировать сжатие путем добавления gzip on;.

Общие рекомендации по настройке параметров Zabbix сервера

Zabbix состоит и внушительного набора процессов и кэшей. Важно не выкручивать эти параметры сильно с запасом, а действовать последовательно. Общая рекомендация — повышать, когда утилизация достигает 60-70%. В процессе аудита мы обычно смотрим на текущую утилизацию каждого компонента и на общий тренд. Общего совета по количеству или объему нет, все сугубо индивидуально.

Еще бы стоило обратить внимание на обновления в минорных версиях. Не стоит их недооценивать. Например, начиная с версий 7.0.17 / 7.4.2 предобработка изменилась настолько, что теперь элементы, которым не требуется предобработка не помещаются в очередь этой самой предобработки. Ранее они туда помещались и просто пролетали без изменений. Да и вообще, хорошая практика иногда заглядывать в заметки к релизам. Вдруг, что-то интересное найдете.

Рекомендация по обновлению шаблонов (классика). Каскад обновлений с версии на версию может привести к тому, что в системе остаются связанные шаблоны. Это наследие предыдущих версий Zabbix, которое сам Zabbix полностью выпилил начиная с 7 версии. Больше никаких связанных шаблонов. Зависимости добавляют сложностей при обновлении шаблонов, а также при обновлении настроек при условии, что данный шаблон может быть привязан к другим шаблонам. Общая рекомендация — избавиться от зависимых шаблонов и сделать структуру плоской.

Еще одна рекомендация — отслеживать количество неподдерживаемых элементов, чтобы оно как минимум не росло, а как максимум постоянно снижалось.

Проверьте интервалы выполнения правил LLD. Для большинства правил выполнение даже 1 раз в час, чересчур избыточно. Бывает, правила обновляются 1 раз в 1 минуту. Вряд вы настолько часто подключаете новые файловые системы к серверу. Правила обнаружения генерируют дополнительную нагрузку, чрезмерно частое их выполнение не рекомендуется. Для определения часто выполняющихся LLD-правил, выполните SQL-запрос, который вернет список правил с указанием интервалов их выполнения.

Критичная и большая проблема с шумящими триггерами. Загляните в отчет `Top 100 triggers`, где, возможно, вы обнаружите множественные срабатывания, по которым нет реакции пользователей (никто эти события не принимал и по ним не было оповещений). Рекомендация — отключить триггеры, на которые не предполагается реакция пользователя. Также рекомендую проводить регулярный аудит событий в Zabbix на предмет поиска событий без реакции пользователей. 1 раза в месяц будет достаточно.

Еще одна частая ошибка настроек триггеров — отсутствие условий восстановления. Отсутствие Recovery Expression приводит к флаппингу триггеров — частому переходу из одного состояния в другое. Для часто срабатывающих триггеров рекомендуется выполнить эту настройку. Общий принцип настройки: событие по триггеру закрывается в момент, когда поведение метрики стабилизировалось на стабильно неаварийном значении.

Обращайте внимание на правила оповещений, которые ссылаются на удаленные объекты (триггеры, хосты, элементы данных). В версиях Zabbix до 7.0.10 происходила автоматическая деактивация таких действий. Начиная с 7.0.10 такие действия не отключаются, а вместо этого около них появляется оранжевая иконка с предупреждением, что действие ссылается на удаленные объекты.

Мы рассмотрели основные моменты, на которые нужно обращать внимание, но основную фактуру вы сможете получить, просмотрев графики производительности компонентов Zabbix. Вот список шаблонов, которые должны обязательно присутствовать в настроенном состоянии в вашей инсталляции Zabbix: Zabbix server health, Zabbix proxy health, PostgreSQL by Zabbix agent 2 или MySQL by Zabbix agent 2, Nginx by HTTP или Apache by HTTP, PHP-FPM by HTTP, Linux by Zabbix agent или Linux by Zabbix agent active.

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