Не могу найти причину очереди от прокси.

[Griboed0ff]

Коллеги, доброго времени суток.
Досталась мне по наследству от прошлых админов система мониторинга: zabbix 5.0.2, база Postgresql 11 с TimescaleDB примерно 650Gb размером. Всего ранее было три виртуальных машины: основной сервер заббикса, веб-сервер, сервер базы. Я добавил еще три машины прокси, их поднимал той же версии, что и сам заббикс, на базе Postgresql 14 Oracle Linux Server 7.9., 16 GB озу, 156GB SSD, 4 cpu. И начал переносить туда хосты из другой системы мониторинга, получается просто подключал как новые для данной системы. А именно на первый прокси я решил поместить все хосты, которые не имеют заббикс агента, зоопарк: cisco и mikrotik маршрутизаторы, принтеры, видеорегистраторы и прочие устройства, которые умеют snmp и отвечать на пинги. Подключил на первый прокси: 10500 хостов, 161000 элементов данных, 650 знач.\чек. и начала появляться очередь, держится на уровне 3000-5000 больше 10 минут. Я сначала подумал, что может поллеров не хватает или ресурсов у железа, посмотрел данные по загрузке разных поллеров и добавил где нагрузка превышала 80%, сейчас по всем параметрам не превышает и 50%, по нагрузке на железо прокси, базы или сервера все в порядке, почти все параметры не превышают 60% нагруженности (cpu, озу, диск на запись\чтение), так же по параметрам самой базы сервера тоже все метрики в порядке. После я проверил данные в очереди и там оказались элементы данных, которые не существуют для некоторых хостов, такие повесил на lld, еще часть очереди ушла. В итоге у меня в очереди snmp меткрики, которые при желании снимаются легко и без препятствий, т.е. заходишь в элементы данных узла, отмечаешь нужные и жмешь выполнить, они сразу же исчезают из очереди. Заметил, что чаще всего в очереди элементы данных, которые добавлены через lld ну и сами обнаружения lld. Пробовал играть с частотой опроса, результата не дало, одни и те же метрики будут висеть сутками в очереди, но если принудительно запросить данные то легко снимаются. Так же играл с таймаутом в конфиге, 30 секунд показали самые лучшие результаты. Создал элемент данных очереди на стороне прокси, ее там нет, то есть прокси все данные отдал и ничего не копит у себя в базе. В общем мои идеи кончились..Буду благодарен, если опытные коллеги дадут подсказку, которая поможет решить проблему.

[Griboed0ff]

Смог добиться большого сокращения очереди snmp элементов данных, поменяв HeartbeatFrequency со значения по умолчанию на 2 секунды. Я до сих порт не понимаю, как этот параметр может влиять на очередь. Но даже так очередь все равно есть, теперь больше состоит из простых проверок, а именно icmppingsec[,10], при этом пингеры и поллеры не заняты и на 50%. Все еще ищу решение.

[Hamardaban]

Не "загоняйтесь" сильно с очередями - это понятие виртуальное, не реальное.
Чаще всего возникает когда данные запрошены, но не получены. Висеть будут до следующего опроса\времени посыла.
Конечно очередь показывает что в системе что-то не так - но всё равно это "отражение" проблем, а не их корни.
Тот факт что "таймаут 30s показал лучшие результаты" может означать что хосты не успевают отдавать данные... (например при SNMP устройство перегружено запросами при неиспользовании bulk )

Совет: используйте для прокси sqlite - на порядок проще в обслуживании, пересоздается при удалении автоматом, производительности хватает на SSD и т.п.

Ну и конечно переходите на 6 версию ! там много ошибок исправлено (и добавлено других) :-)

[Griboed0ff]

данные запрошены, но не получены

В этом и есть проблема, в другой моей системе мониторинга тоже есть очередь, но там она продвигается. А в данной ситуации данные не получены сутками и более, пока не сбросишь очередь. Соответственно не выстроить триггеры, так как есть ложные срабатывания. Меня больше беспокоит, что я еще не израсходовал ресурс машины и возможности конфига прокси, а уже встретился с проблемой, на которую не обращать внимания не получается. Пока там 10500 хостов, а я хотел бы ~20000 повесить на один прокси.

SNMP устройство перегружено запросами при неиспользовании bulk

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

используйте для прокси sqlite

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

переходите на 6 версию !

В данный момент у меня две системы мониторинга 4.2 и 5.0.2, после того как я их объединю, тогда уже смогу апнуться до мажорных версий.

[Kos]

В данный момент у меня две системы мониторинга 4.2 и 5.0.2, после того как я их объединю, тогда уже смогу апнуться до мажорных версий.

Просто замечание в сторонку: пока не апнулись да мажорных версий, ничто не мешает апнуться до минорных.
Так, текущий релиз для версии 5.0.х - это 5.0.30, вышедший две недели назад (в то время как 5.0.2 - два с половиной года назад).
Обновление в рамках минорной версии происходит достаточно быстро (поскольку не меняется структура внутренней базы данных, а лишь заменяются бинарники) и, как правило, безболезненно; причём сервер и прокси необязательно обновлять одновременно. А если что - всегда можно таким же образом откатиться обратно (просто вернув прежние бинарники).
Насколько я помню, именно в версии 5.0.х было довольно много доработок по части протокола SNMP (скажем, только в релизе 5.0.5 - 5 исправлений).

[Griboed0ff]

ничто не мешает апнуться до минорных

Решение не мое, я лишь исполнитель. Решил, что пока попробую 5.0.30-1, только что поставил на одну прокси, посмотрим возможно будет положительный результат.

[Griboed0ff]

текущий релиз для версии 5.0.х - это 5.0.30, вышедший две недели назад (в то время как 5.0.2 - два с половиной года назад).

Не знаю насколько это связано, но после перехода прокси на 5.0.30-1, проблема очереди бесконечно висящими там snmp эл ушла. Теперь остались только простые проверки, но в очереди обновляются 5, 10, 30 секунд, что приемлемо. Но все же я буду и далее искать причину очереди. Так как мне не ясно почему она вообще есть, если все ресурсы в норме и очереди вообще не должно быть в любой момент времени. Пока очередь останавливает меня от добавления на этот прокси еще 10к+ хостов.