Незначительные значительные улучшения в Zabbix 8.0

В презентациях, посвященных Zabbix 8.0, много внимания уделяется APM, OpenTelemetry, ClickHouse и интеграциям через MCP. Но для администратора системы мониторинга не менее важны другие вопросы: как сервер переживает перезапуск, что происходит с накопленными данными прокси-сервера и как открыть доступ команде только к настройкам тех прокси, которые работают именно в их филиале.

Меня зовут Антон Касимов, я работаю в Gals Software, провожу тренинги по Zabbix и веду телеграм-канал Zabbix Recipes. В предыдущей статье я разобрал хранение истории в ClickHouse. Здесь посмотрим на менее заметные изменения: кэши, housekeeping, DNS, SNMPv3, права доступа к прокси и работу с секретами.

1. Ускорение запуска Zabbix Server

Сначала разделим два кэша, которые иногда путают.

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

При запуске Zabbix Server необходимо заполнить value cache данными из истории. Они нужны для вычисления функций триггеров вроде last(), min(), count() и nodata(). Раньше сервер загружал историю по отдельным элементам данных, что создавало большое количество обращений к БД. На инсталляциях с сотнями тысяч или миллионами элементов данных прогрев мог занимать значительное время.

В 8.0 появилась пакетная загрузка истории для нескольких элементов данных вместо отдельных обращений по каждому. Она ускоряет прогрев value cache после перезапуска. Опция precache у HistoryProvider включена по умолчанию. Для SQL-провайдера настройка выглядит так:

HistoryProvider=sql;precache=1

Практический эффект:

• быстрее стартует сервер;

• быстрее прогревается value cache;

• сокращается период после перезапуска, когда триггеры активно обращаются к БД;

• быстрее проходит переключение на резервный сервер в HA-конфигурации;

• уменьшается количество запросов к БД во время запуска.

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

2. Оптимизация очистки истории и связанных объектов

В Zabbix существует два процесса очистки ненужных данных:

1. Удаление истории и трендов по истечении срока хранения;

2. Удаление данных объектов, которые были удалены из конфигурации.

В Zabbix 8.0 оптимизирован второй сценарий. В новой версии создание таких заданий перенесено в триггеры базы данных. Когда удаляется элемент данных, правило LLD, триггер, сервис или правило сетевого обнаружения, необходимо удалить связанные записи из БД. Раньше задания для housekeeper создавались кодом Zabbix, а теперь их формируют триггеры базы данных, добавляя задания в таблицу housekeeper. Также удаляются и события, связанные с проблемами удалённых триггеров, события сетевого обнаружения для удалённых обнаруженных узлов и сервисов. Раньше часть таких событий дожидалась общего срока хранения. Подробности смотрите в описании процедуры housekeeping.

3. Ускоренная обработка count-функций

Оптимизирована внутренняя обработка функций, считающих значения или изменения:

• count();

• countunique();

• changecount();

• item_count();

• другие функции, основанные на подсчёте.

Например, выражение:

count(/Web server/http.response.time,5m,"gt",2)>10

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

А выражение с changecount() может обнаруживать частое переключение состояния:

changecount(/Server/service.state,10m)>5

Такие функции потенциально обрабатывают большое количество исторических значений. Особенно тяжёлыми становятся выражения с:

• большими временными окнами;

• коротким интервалом сбора;

• текстовыми и логовыми данными;

• регулярными выражениями;

• большим количеством одинаковых триггеров;

• массовыми прототипами LLD.

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

Практический эффект:

• меньше времени уходит на пересчёт триггеров;

• снижается задержка между получением значения и созданием события;

• тяжёлые выражения меньше нагружают history/value cache;

• лучше масштабируются шаблоны с большим количеством однотипных триггеров.

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

4. Кэширование DNS-запросов

Zabbix сервер, прокси и классический агент получили поддержку DNS-разрешения через c-ares. Для этого компонент должен быть собран с --with-ares, а для кэширования требуется c-ares не ниже 1.26.0.

Задача понятна: не выполнять одинаковую подготовительную работу при каждом обращении к одному имени. Это будет особенно полезно там, где много подключений по DNS-именам.

Переход на 8.0 не означает, что конкретный бинарник использует нужную библиотеку. Проверять нужно сборку пакета, а затем реальное поведение. Для динамически связанного Linux-бинарника такой проверкой может быть:

ldd /usr/sbin/zabbix_server | grep -i cares

Этот функционал нельзя автоматически переносить на Agent 2: у него собственная реализация на Go.

Практический эффект:

• кэширование результатов DNS-запросов внутри процессов Zabbix;

• меньше повторных обращений к DNS-серверам;

• более эффективную работу при большом количестве DNS-интерфейсов;

• переключение между DNS-resolver’ами при отказе одного из них;

• снижение задержек при временных проблемах DNS.

5. Кэширование SNMPv3 EngineID

При мониторинге по протоколу SNMPv3 одного IP-адреса недостаточно. Устройство имеет уникальный EngineID, участвующий в аутентификации и вычислении локализованных ключей.

До выполнения SNMPv3-запроса Zabbix может потребоваться определить соответствие:

IP-адрес → SNMPv3 EngineID

Если на устройстве много элементов данных типа SNMP, повторные EngineID probes создают лишний сетевой обмен и увеличивают время опроса. Zabbix 8.0 кэширует соответствие EngineID и IP-адреса и повторно использует его для следующих проверок:

192.168.10.1 → 80001f8880...

Практический эффект:

• меньше служебных SNMPv3-запросов;

• быстрее выполняются проверки;

• снижается нагрузка на SNMP pollers;

• уменьшается нагрузка на сетевое оборудование;

• повышается производительность при мониторинге большого числа SNMPv3-устройств.

6. Восстановление history cache и ограничение прокси

Снова вернемся к history cache. Напомню, что это буфер в памяти Zabbix сервер, куда поступают собранные значения до записи в БД.

Размер задаётся параметром конфигурации Zabbix сервера:

HistoryCacheSize=256M

Если БД не успевает записывать данные, кэш истории начинает заполняться. Причинами могут быть:

• медленные диски под БД;

• блокировки в БД;

• недостаточное количество синхронизаторов истории;

• тяжёлые запросы;

• резкий поток данных после восстановления прокси;

• одновременное подключение нескольких прокси с накопленным буфером.

Троттлинг (защита от переполнения) работает следующим образом:

В Zabbix 8.0 переработан механизм троттлинга. Раньше после частичного освобождения кэша несколько прокси могли сразу отправить большие куски данных и кэш истории снова быстро заполнялся, и сервер возвращался в throttling. Получались колебания показателя:

zabbix[wcache,history,pused]

Теперь восстановление происходит постепенно. Это снижает вероятность повторного переполнения и помогает серверу стабилизироваться. Механизм throttling Proxy.

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

• history cache заполнен больше чем на 60%;

• прокси сообщает, что после текущего пакета у него есть ещё данные для отправки.

Если оба условия выполняются, сервер временно не разрешает обработку исторических данных этого прокси. Признак оставшихся данных передаётся полем more. В обработчике активного прокси сервер читает more=1 и передаёт результат в функцию проверки кэша.

Допустим:

• history cache заполнен на 65%;

• глобальный режим ожидания ещё не включён;

• список ограничиваемых прокси пуст;

• Proxy A догружает несколько часов истории и присылает more=1;

• Proxy B отправляет небольшой текущий пакет, после которого у него ничего не осталось — more=0.

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

Напоследок, небольшая рекомендация. Если cache регулярно доходит до 80%, простое увеличение HistoryCacheSize может только отсрочить проблему. Нужно также проверить:

• производительность БД;

• latency и IOPS дисков;

• загрузку синхронизаторов истории;

• размеры пакетов прокси;

• накопленный данные в прокси;

• скорость поступления значений.

7. Управление доступом к прокси и серверу

Доступ к прокси

В настройках группы пользователей появилась вкладка Proxy access list.

Можно выбрать:

• отдельные прокси;

• группы прокси;

• режим Allow list;

• режим Deny list.

Правила при членстве пользователя в нескольких группах:

• Deny имеет приоритет над Allow;

• несколько Allow list объединяются;

• Прокси внутри группы прокси управляется через права на группу, а не отдельно.

Ограничения учитываются не только в интерфейсе, но и в API — например, proxy.get вернёт только доступные пользователю прокси.

Доступ к Zabbix серверу

В роли пользователя появился параметр: Select “Server” for monitoring and discovery

Если его отключить, пользователь не сможет:

• создать хост, который мониторится непосредственно Zabbix сервером;

• выбрать Server в поле Monitored by;

• создать правило сетевого обнаружения, выполняемое сервером;

• тестировать элемент данных через сервер.

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

Это полезно для:

• разделения администраторов по филиалам;

• MSP и мультитенантных инсталляций;

• защиты центрального сервера от произвольных проверок;

• ограничения доступа региональных команд к центральной инфраструктуре.

8. HashiCorp Vault AppRole

Раньше Zabbix обычно подключался к HashiCorp Vault с заранее созданным токеном:

VaultToken=hvs.xxxxxxxxx

Проблема статического токена — необходимость безопасно создать, передать, хранить и периодически менять его.

В Zabbix 8.0 добавлена аутентификация через AppRole:

Vault=HashiCorp
VaultURL=https://vault.example.com:8200
VaultAppRoleID=6f1567f1-...
VaultAppSecretID=89dac8b1-...
VaultDBPath=secret/zabbix/database

Логика работы:

Zabbix Server
  │
  ├─ RoleID
  ├─ SecretID
  ▼
HashiCorp Vault AppRole login
  │
  ▼
Vault выдаёт токен согласно политике AppRole
  │
  ▼
Zabbix читает разрешённые секреты

Преимущества:

• не нужно вручную выдавать Zabbix постоянный Vault token;

• права задаются политикой AppRole;

• SecretID можно ограничить по сроку и числу использований;

• можно создать разные роли для Zabbix сервера, прокси и фронтэнда;

• проще реализовать ротацию доступа;

• снижается риск использования одного общего токена несколькими компонентами.

VaultAppRoleID нельзя использовать одновременно с VaultToken.

При использовании VaultDBPath параметры DBUser и DBPassword в конфигурации не задаются.

AppRole поддерживается в:

• Zabbix Server;

• Zabbix Proxy;

• Zabbix frontend.

Для frontend используются параметры:

$DB['VAULT_APP_ROLE_ID'] = '...';
$DB['VAULT_APP_SECRET_ID'] = '...';

RoleID обычно не считается полноценным секретом, но SecretID необходимо защищать как пароль: ограничить права на конфигурационный файл и настроить его ротацию. Параметры Vault в Zabbix Server.

9. AllowKeyRegexp и DenyKeyRegexp

У агента уже была возможность использования AllowKey и DenyKey с маской типа *. В 8.0 добавлены варианты с регулярными выражениями для Agent и Agent 2. Они сопоставляют полный ключ с его параметрами, а не только имя исполняемого файла.

Например, разрешим только две команды без дополнительных аргументов, с необязательным режимом wait или nowait:

AllowKeyRegexp=^system\.run\[/usr/bin/(uptime|whoami)(,(wait|nowait))?\]$
DenyKey=system.run[*]

При отсутствии более ранних перекрывающих правил эта конфигурация разрешит system.run[/usr/bin/uptime] и system.run[/usr/bin/whoami,nowait], но не system.run[/usr/bin/uptime;id].

Последняя запрещающая строка здесь избыточна: прочие system.run[] запрещены по умолчанию. Я оставил её, чтобы показать приоритет правил. Проверка идёт сверху вниз до первого совпадения; общего принципа «любой Deny всегда побеждает» здесь нет.

Синтаксис и ограничения приведены в документации.

Остальные семейства ключей данный пример не закрывает: это не allowlist всех возможностей агента. Политику нужно проверять целиком, включая Include, Alias и уже имеющиеся правила. Также учитывайте различия regex-синтаксиса Agent и Agent 2.

На стенде с агентом 8.0 можно проверить разрешённый ключ с явным указанием конфигурации:

zabbix_agent2 -c /etc/zabbix/zabbix_agent2.conf \
  -t 'system.run[/usr/bin/uptime]'

-t выполняет разрешённую проверку. Для экспериментов используйте безвредные команды и отдельно тестируйте запрещённые варианты. Сама regex-политика не заменяет минимальные права ОС, защиту скриптов от изменения и безопасную обработку аргументов.

Заключение

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