Короткий ответ

Растущая очередь — это нехватка сборщиков или упёрлись в БД, не «надо рестартнуть zabbix-server». Снимите: какой тип очереди (Zabbix agent, SNMP, trapper, proxy), busy% poller/trapper/history syncer, медленные item'ы (timeout), диск PostgreSQL. StartPollers=200 при мёртвом RAID на БД только усилит I/O. Сначала диагностический срез, потом точечное увеличение процессов. Рост таблиц: база растёт. Чистка: housekeeper. Данные застревают на proxy: proxy.

Сервер 10.0.20.50, UI zabbix.example, хост-пример WS-042.

Симптомы и как отличить

Типичная картина:

  • Queue overview: тысячи item'ов в «10 minutes»;
  • Latest data на WS-042 отстаёт от zabbix_get «сейчас»;
  • Dashboard Internal process busy;
  • UI тормозит, демон при этом running.

Отличия:

КартинаНе очередь сбораКуда
Демон не слушает 10051startserver не стартует
Только хосты одного proxyканал proxyproxy
NVPS ок, диск БД +10 ГБ/суткиretentionбаза
Тысячи LLD itemdiscoveryLLD

Возможные причины

  1. Мало pollers относительно числа пассивных item × (1/interval) × timeout.
  2. Мало trappers при массе active agents / proxy.
  3. Item'ы с Timeout 15–30s и недоступные SNMP тянут poller.
  4. History syncer / PostgreSQL checkpoint, диск на 100%.
  5. Value cache / history cache 100% (смотри internal items).
  6. После массового link template интервалы 10s на 5000 item.
  7. Редко: DNS timeout на каждом опросе по имени, один «чёрный» хост.

Диагностика

1. Срез очереди в UI

Zabbix 6.0 LTS: Administration → Queue.
Zabbix 7.0 LTS: Reports → Queue.

Зафиксируйте: тип items, «5–10 min» vs «10+ min», примеры хостов. Если 90% SNMP одного сегмента — не трогайте agent pollers.

2. Internal items сервера

На хосте zabbix.example должны быть items:

  • zabbix[process,poller,avg,busy]
  • zabbix[process,unreachable poller,avg,busy]
  • zabbix[process,trapper,avg,busy]
  • zabbix[process,history syncer,avg,busy]
  • zabbix[queue]
  • zabbix[wcache,history,pfree] / zabbix[wcache,values]

Busy poller ~100% и history syncer 20% — мало pollers или долгие item. History syncer 100% и диск 100% — БД, не StartPollers.

3. Конфиг процессов

sudo grep -E '^Start|^Timeout|^Cache|^History|^Value' /etc/zabbix/zabbix_server.conf
ss -lntp | grep 10051

Timeout= в server — потолок для poller. Глобальный 30s убивает очередь, если много dead hosts.

4. PostgreSQL

sudo -u postgres psql -d zabbix -c "SELECT state, count(*) FROM pg_stat_activity GROUP BY 1;"
iostat -x 1 5

iowait высокий, await диска десятки мс — узкое место storage. Добавление pollers ухудшит.

5. Медленные ключи

В логе при Debug не жить. Смотрите хосты в очереди: snmp timeout, system.run, SMART. С 10.0.20.50:

time zabbix_get -s 10.0.20.42 -p 10050 -k agent.ping \
  --tls-connect psk --tls-psk-identity psk-ws042 \
  --tls-psk-file /etc/zabbix/psk-ws042.psk

Если agent.ping 50ms, а в очереди smart.disk.* — интервал SMART и Timeout item.

Диагностика процессов runtime:

sudo zabbix_server -R diaginfo=historycache
sudo zabbix_server -R diaginfo=preprocessing

Снимайте вывод в файл заявки, не на экран «навсегда».

Решение

Сценарий A. Poller 100%, history syncer низкий

  1. Найдите unreachable хосты, вынесите в отдельный шаблон с редким интервалом.
  2. Снизьте Timeout item на SNMP dead.
  3. Увеличьте StartPollers умеренно (например +50% от текущего), не на порядок.
  4. Unreachable pollers отдельно (StartPingers / unreachable pollers — по вашей версии конфига).

После правки:

sudo -u zabbix zabbix_server -c /etc/zabbix/zabbix_server.conf -T
sudo systemctl restart zabbix-server

Рестарт — только после -T и понимания, что теряете in-memory очередь на секунды.

Сценарий B. Trapper 100%

Много active agents и proxy. Поднимите StartTrappers, проверьте MaxConcurrentChecksPerPoller не путать. Сеть 10051, ListenBacklog. Не закрывайте firewall так, чтобы SYN очередь росла.

Сценарий C. History syncer / диск БД

Индексы, autovacuum, диск, StartDBSyncers по документации (не 50 «на удачу»). Сократить NVPS: интервалы, ненужные LLD. Housekeeper в пике — отложите тяжёлую чистку, см. статью housekeeper.

Сценарий D. Кэши 100%

HistoryCacheSize, ValueCacheSize увеличить, если RAM есть. Смотрите график pfree кэша. Не раздувайте cache, маскируя плохой диск.

Сценарий E. DNS

В интерфейсах хостов IP, где возможно. Или локальный кэш DNS на 10.0.20.50.

Как проверить, что проблема устранена

Queue «10+ min» стремится к нулю в рабочий час (не сразу в секунду). Busy poller < 75% устойчиво. Latest data WS-042 совпадает с zabbix_get в пределах интервала item. NVPS стабилен. Наблюдайте сутки: пик бэкапа не должен снова забивать 10+.

Если не помогло

  • Очередь только после 03:00: housekeeper + backup БД, разведите расписание.
  • Только новые хосты: LLD взрыв.
  • После рестарта пусто, через час снова: вы не убрали медленные item, только сбросили очередь.
  • Proxy buffer: серверная очередь мала, данные старые — смотрите proxy.

Профилактика

  • Internal template на Zabbix server с триггерами busy и queue.
  • Бюджет NVPS при добавлении шаблона (калькулятор: hosts × items / interval).
  • Таймауты короткие, dead hosts в «quarantine» группе.
  • Диск БД с запасом IOPS, не «остатки на hypervisor».

FAQ

Рестарт сервера очищает очередь — это фикс?

Нет. Вы выбрасываете отложенные опросы. Через интервал всё вернётся.

Сколько StartPollers ставить?

Смотрите busy%, не таблицу из блога 2014 года. Растите шагами, меряйте.

Можно ли Timeout=1 глобально?

Сломаете SNMP и тяжёлые ключи. Timeout глобальный разумный (3–4s), длинные ключи — item-level.

7.0 быстрее 6.0 и очередь рассосётся сама?

Апгрейд не замена профилированию. Новые версии лучше препроцессинг, но NVPS вы задаёте шаблонами.

Queue из-за одного WS-042?

Да, если ключи timeout. Найдите хост в details очереди, отключите проблемный item, подтвердите падение очереди.

Нужен ли отдельный poller для agent vs SNMP?

В 6.0/7.0 есть типы процессов (poller, snmp poller в зависимости от версии/настроек). Смотрите StartSNMPPollers если параметр есть в вашей линии, не выдумывайте чужие директивы. Сверяйте zabbix_server --help / шаблон конфига пакета.