Zabbix пошел в разнос.

[Alex_UUU]

Коллеги, вот такая штука:
Заббикс обрабатывает порядка тысячи хостов, около 200 000 ЭД ну и т.д.
Основная масса ЭД - активные проверки.

И вот такая ситуация: отваливается элемент сети, т.е. половина серверов становится недоступна. Вроде штатная ситуация, но начинают расти пуллеры до 100%, соответственно растут алерты, начинает расти очередь, ну и через какое-то время сервер просто уходит "на покурить".
Ощущение, что логика сервера такая, что даже если он определил несетевую связность с узлом, он все равно пытается выдернуть все ЭД.
Это в настройках что-=то неправильно или уже не побороть?

Да, когда сетка восстанавливается, заббикс все равно в отрубе. Перезагрузка приводит к 100% загрузке синклеров, росту очереди предпроцессинга.
В логах вырастает кол-во
failed: first network error, wait for 15 seconds
temporarily disabling Zabbix agent checks on host "ХХХХХХХ": host unavailable

[Kos]

Либо у вас опечатка, либо всё действительно очень странно.

Поллеры не принимают участия во взаимодействии с активными проверками. При активных проверках сами агенты отсылают данные на сервер, и эти данные на стороне сервера принимаются процессами "траппер". Поллеры же, напротив, занимаются проверками агентов в пассивном режиме и опросом по SNMP. Насколько я понимаю, сообщения про network error в логе сервера отсылают, как раз, именно они, а не трапперы.

Хистори синкеры сохраняют полученные данные в базе, а кроме того - обрабатывают триггерные условия. При наличии большого количества хостов, которые мониторятся с помощью активных проверок либо через прокси - нормальная ситуация, что после рестарта сервера Zabbix первое время будет повышенная нагрузка за счёт того, что он будет обрабатывать накопившиеся (на активных агентах либо прокси-серверах) буферизированные данные и "разгребать" их, но эта повышенная нагрузка не должна длиться долго.

Ну и неплохо было бы указывать версию сервера Zabbix. В какие-то моменты у нас тоже были проблемы с "залипонами" алертеров (ещё в версии 2.х), но потом эту проблему починили и довольно давно уже этого эффекта не наблюдается.

[Alex_UUU]

Приветствую.
Основная масса ЭД - активные. Но не малая часть и пассивные. Как же без них.

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

26169 ? S 1:16 /usr/sbin/zabbix_server: configuration syncer [synced configuration in 5.428085 sec, idle 60 sec]
26204 ? S 0:21 /usr/sbin/zabbix_server: history syncer #1 [processed 17608 values, 10371 triggers in 14.430189 sec, syncing history]
26205 ? S 0:23 /usr/sbin/zabbix_server: history syncer #2 [processed 16592 values, 9294 triggers in 10.125575 sec, syncing history]
26206 ? S 0:20 /usr/sbin/zabbix_server: history syncer #3 [processed 14648 values, 8787 triggers in 10.858870 sec, syncing history]
26207 ? S 0:19 /usr/sbin/zabbix_server: history syncer #4 [processed 18637 values, 11012 triggers in 10.852382 sec, syncing history]
26534 ? S 0:49 /usr/sbin/zabbix_server: preprocessing manager #1 [queued 848510, processed 14924 values, idle 0.606995 sec during 5.835450 sec]
26548 ? S 0:00 /usr/sbin/zabbix_server: alert syncer [queued 0 alerts(s), flushed 0 result(s) in 0.000743 sec, idle 1 sec]

Версия 5,2,4

[Alex_UUU]

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

а логах агента:

18387:20210818:123052.652 active check data upload to [ХХХ:10051] is working again
18387:20210818:123122.802 active check data upload to [ХХХ:10051] started to fail ([recv] ZBX_TCP_READ() timed out)
18387:20210818:123137.865 active check data upload to [ХХХ:10051] is working again
18387:20210818:123225.358 active check data upload to [ХХХ:10051] started to fail ([connect] cannot connect to [[ХХХ:10051]: [4] Interrupted system call)
18387:20210818:124030.319 active check data upload to [ХХХ:10051] is working again

[Alex_UUU]

Непонятки продолжаются. Но решить проблему не можем, т.к. не можум искусственно повторить.

В общем так. Все работает стабильно и прекрасно. Но в какой-то момент происходят сетевые проблемы. Они кратковременные. Т.е. есть предположение, что в этот момент или сервер или агент соединение потеряли, но не знают об этом.
Данные на сервер не поступают и начинают срабатывать триггеры по отсутствию данных.
При этом агенты пытаются законнектиться, но (предположение), что сервер ставит их в очередь и они отваливаются по таймауту. И соответствено это начинает распространяться на всех агентов, в т.ч. и на тог, который находится на сервере с заббикс-сервером.
Соответственно падает "zabbix value cache hits" с 40 Kvps до 1, растет "Zabbix queue" с 2,5К до 90 и выше, падает "Value processed by Zabbix server per second" с 1,5К до 500.
В зависимости от агентов, которые "пошли в разнос" все может восстановиться за 10 минут, а может и через несколько часов.

Если я в штатном режиме пускаю одновременно десятки агентов на перезагрузку (ну как одновременно, скриптом последовательно), или вайрволом вырубаю подсетку и потом включаю. Или вырубаю прокси, то все проходит в штатном режиме.

[Alex_UUU]

Продолжаю наблюдение. А что еще остается?
Еще раз: забарахлила сетевая связность с удаленным агентом. Создалось ощущение, что он расконнектился, Законнектился, кинул запрос на активчек и отвалился, опять законнектился - запрос на активчек и отвалился. Ну барахлит сетка и барахлит.
В результате висит несколько сетевых коннектов. Через какое-то время срабатывают триггеры по "нет данных" на данном узле, все штатно.
Через установленное время другие агенты начинают запрашивать активчек (штатный режим) , но заббикс-сервер чем-то занят и поэтому не сразу дает коннект. Через какое-то время задержка вырастает и агенты отваливаются. И вот тут сервер идет в разнос. Агенты не цепляются, отваливаются по таймауту, очередь, соответственно растет (ситуация описана выше).
Из дополнения: сейчас по нетстату от 0 до 5 коннектов в режиме SYN-RECV, когда колбасит - более 50.

[Kos]

Еще раз: забарахлила сетевая связность с удаленным агентом. Создалось ощущение, что он расконнектился, Законнектился, кинул запрос на активчек и отвалился, опять законнектился - запрос на активчек и отвалился.

Просто для полноты картины: агенты Zabbix не держат с сервером постоянных соединений. Они именно так и работают. В пассивном режиме на каждый запрос устанавливается соединение со стороны сервера, по которому передаётся запрос, возвращается ответ, после чего соединение разрывается. В активном режиме с определённым интервалом (по умолчанию - 2 минуты) агент соединяется с сервером, чтобы забрать (и, возможно, обновить) список необходимых проверок (соединился - запросил - получил - разъединился). Плюс дополнительно к этому по мере необходимости соединяется с сервером, чтобы передать результаты своих проверок, причём за один раз можно переслать целую "стопку" собранных значений (тоже: соединился - переслал - разъединился). При любом раскладе постоянных соединений нет, как и понятия "расконнектился". Активный агент может при очередной попытке просто не достучаться до сервера, либо разъединиться преждевременно - в этом случае собранные значения остаются у него в кэше (в разумных пределах), а в лог на стороне агента пишется ругань.

Мне кажется, что в данном случае стОит проверить параметры операционной системы. Например, если сервер Linux "обрабатывает порядка тысячи хостов" непосредственно сам, без промежуточных Zabbix-proxy, то могут быть, как минимум, следующие вещи:

• если используется широкая подсеть (с маской не /24, а, например, /16), то (в зависимости от дистрибутива Linux) может оказаться недостаточным размер таблицы ARP, заданный по умолчанию. Смотреть файл /etc/sysctl.conf, выставить в нём параметры net.ipv4.neig.default.gc_thresh[123] (ссылка).
• может оказаться, что сервер упирается в ограничение на количество одновременных TCP-соединений (ссылка).
• может оказаться, что конкретный процесс сервера Zabbix упирается в ограничение на количество открытых файлов (поскольку каждое соединение - это тоже файл). Тут, в зависимости от способа запуска (инит-скриптом или через systemd) нужно проверить параметры fs.file-max в том же /etc/sysctl.conf, параметры в
  /etc/security/limits.conf (ссылка) либо параметры в юнит-файле для сервера (параметр LimitNOFILE=). Также полезная шпаргалка (ссылка).

[wins]

Апну тему. Есть ли новые наблюдения? Наступил в похожую аномалию: zabbix 5.4.7 отвалилась на пол-суток связь между одной из проксей и серваком. После восстановления связности zabbix configuration cache распух более чем 2 раза. Увеличил значение в параметре, но сижу как говорится "на измене"

[Alex_UUU]

Новых наблюдений нет. ПОрекомендациям из поста выше проверки проведены. На уровне ОС все, вроде бы в норме.
Об этом говорят также и логи агентов. Если есть лимит на ТСП соединение, то даже SYN не должен проходить. ОС шлет RST-SYN (вроде так), тут получается, что SYN проходит, а дальше затык...(да, надо посмотреть дампом это. Хотя фигово то, что получить ситуацию не получается).

[wins]

У вас вся эта куча хостов связана с сервером напрямую, без проксей?
В моем случае наложилась неисправность timescaledb: версия 2.5 работает коряво, помогает роллбек на 2.4.2.

[Alex_UUU]

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

[wins]

Если мне не изменяет память - рекомендация лучших заббиксоводов распределять такую нагрузку по проксям