Zabbix proxy(active) уходит в тайм-аут на 600 сек

[AntonFender]

Добрый день!
Столкнулся с одной проблемой, которую не могу решить уже месяц.
Как я написал в заголовке, проблема такая:
"Zabbix proxy(active) уходит в тайм-аут на 600 секунд пытаясь отправить данные на zabbix server.
После того, как 10 минут проходит, прокси сервер снова работает нормально как ни в чем не бывало.
Причем может так получится , что одновременно две прокси уходят в тайм-аут на 600 секунд.
Проблема возникает 1-2 раза в сутки в рандомное время. Бывает, что даже и через день проблема появляется. В общем тут нет какой-то закономерности.

Что имеем:
Zabbix server и zabbix proxy у меня версией 7.0.30.
Операционная система на сервере и прокси серверах Oracle Linux 8 (full upgrade).
У меня 22 активные zabbix прокси на текущий момент.

Когда возникла проблема:
Проблема появилась после добавления дополнительных 5 прокси серверов. Т.е было 17, а после добавления стало 22. Причем данные прокси малонагруженны. Менее 100 nvps.


Наблюдения:
1) tcpdump на стороне прокси и сервера показывает наличие ретрансмитов.
2) На zabbix сервере наблюдается увеличение счетчика ListenDrops в момент возникновения проблемы.
3) Тюнинг сетевого стека ОС и попытка даже очень сильно увеличить некоторые параметры не дают никакого результата.
4) Полное обновление ОС вместе с ядром на всех прокси серверах и самого сервера не дали никакого результата.
5) В конфиге zabbix server увеличение параметра ListenBacklog не дает результата.
6) В логах zabbix server не видно каких либо проблем
7) В логах прокси сервера видно, что прокси установил соединение и пытается отправить данные . И на этом месте прокси уходит в ожидание на 600 секунд.
8) Процессы на стороне zabbix сервера не утилизируются.
9) На стороне zabbix proxy утилизируется процесс data sender.



Скорей всего проблема даже не на стороне zabbix.Но проблема как то связана с увеличением количества прокси серверов. Прошу помочь, подсказать куда можно еще капнуть и что посмотреть.

[Kos]

Я правильно понимаю, что проблема возникает не с одним конкретным прокси, а с различными? Тогда, мне кажется, более вероятно, что проблема не на стороне прокси-серверов, а на стороне Zabbix-сервера.
Не может ли быть такого, что на Zabbix-сервере перестаёт хватать дескрипторов открытых файлов на процесс? Если сервер запускается через systemd, то проверить в unit-файле наличие параметра "LimitNOFILE".
Приёмом данных от активных проксей занимается процесс trapper, а последующим запихиванием данных в базу (попутно обсчитывая триггеры) - процесс history syncer. Что видно в проблемные моменты на графиках загруженности этих процессов (см. стандартный шаблон для мониторинга сервера Zabbix)?
Ещё вариант - возможно, тормозит обращение к базе данных при сохранении того, что пришло от прокси (нередко бывает в случаях, когда база данных используется с настройками по умолчанию и не тюнилась вообще). Что за СУБД используется, не ли каких сообщений в её логах?

[Kos]

Я правильно понимаю, что проблема возникает не с одним конкретным прокси, а с различными? Тогда, мне кажется, более вероятно, что проблема не на стороне прокси-серверов, а на стороне Zabbix-сервера.
Не может ли быть такого, что на Zabbix-сервере перестаёт хватать дескрипторов открытых файлов на процесс? Если сервер запускается через systemd, то проверить в unit-файле наличие параметра "LimitNOFILE".
Приёмом данных от активных проксей занимается процесс trapper, а последующим запихиванием данных в базу (попутно обсчитывая триггеры) - процесс history syncer. Что видно в проблемные моменты на графиках загруженности этих процессов (см. стандартный шаблон для мониторинга сервера Zabbix)?
Ещё вариант - возможно, тормозит обращение к базе данных при сохранении того, что пришло от прокси (нередко бывает в случаях, когда база данных используется с настройками по умолчанию и не тюнилась вообще). Что за СУБД используется, не ли каких сообщений в её логах?

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

[AntonFender]

Я правильно понимаю, что проблема возникает не с одним конкретным прокси, а с различными? Тогда, мне кажется, более вероятно, что проблема не на стороне прокси-серверов, а на стороне Zabbix-сервера.
Не может ли быть такого, что на Zabbix-сервере перестаёт хватать дескрипторов открытых файлов на процесс? Если сервер запускается через systemd, то проверить в unit-файле наличие параметра "LimitNOFILE".
Приёмом данных от активных проксей занимается процесс trapper, а последующим запихиванием данных в базу (попутно обсчитывая триггеры) - процесс history syncer. Что видно в проблемные моменты на графиках загруженности этих процессов (см. стандартный шаблон для мониторинга сервера Zabbix)?
Ещё вариант - возможно, тормозит обращение к базе данных при сохранении того, что пришло от прокси (нередко бывает в случаях, когда база данных используется с настройками по умолчанию и не тюнилась вообще). Что за СУБД используется, не ли каких сообщений в её логах?

Спасибо за наводки. Я вроде как это все проверял, но решил перепроверить.

1) На счет прокси в момент проблемы есть интересная особенность.
Вот эти 5 прокси, которые были добавлены, они находяться в разных локациях и нужны для мелких задач. Установили мы их в тех же подсетях, что и нагруженные прокси в этих локациях.
Очень часто бывает так, что проблема появляется одновременно на двух прокси из одной и той же локации. Причем эти прокси никак друг с другом не связаны, они живут на разных ВМ, но на одном ESX хосте.
IP адреса у них допустим такие: 10.149.60.5, 10.149.60.6

2) На графике наблюдается рост(Снимаю счетчики через netstat):
ListenDrops
TCPSynRetrans
TCPTimeouts

3) В момент проблемы алерты такие:
Zabbix agent is unreachable for 5m minutes
Zabbix proxy: Utilization of data sender processes over 75%

4) Кэш и процессы в момент проблемы не утилизируется(см. скрины)

5) По файловым дискрипторам тоже проблем не выявил(см. скрины). В службе прописано так:
LimitNOFILE=65536:1048576

6) БД не нагружена в этот момент, каких-то подозрительных лог сообщений от самой БД я не заметил.
Касаемо БД. У нас стоит Postgresql 17 + TimescaleDB

[Kos]

2) На графике наблюдается рост(Снимаю счетчики через netstat):
ListenDrops
TCPSynRetrans
TCPTimeouts

Вот, честно говоря, исходя из этого - похоже, что есть проблемы на сетевом уровне. Особенно с учётом того, что одновременно "отваливаются" независимые друго от друга прокси-серверы на той же площадке, а сам сервер Zabbix (да и его СУБД) в это время высокой нагрузки не имеют. Тут вот чуть подробнее (ссылка).

Грубо говоря, активный прокси устанавливает очередное соединение к серверу, не получает начального ответа SYN/ACK (либо по какой-то причине считает, что он его не получил) и пересылает начальный SYN-пакет повторно - и так несколько раз, пока, наконец, не получает ответ, после чего успешно работает. Но непонятно, из-за чего подобные потери пакетов происходят. Может, между ними есть какой фаервол, который чудит? Например, считает, что происходит слишком много новых соединений в единицу времени, после чего просто блокирует "нарушителя" на 10 минут?

[AntonFender]

Вот, честно говоря, исходя из этого - похоже, что есть проблемы на сетевом уровне. Особенно с учётом того, что одновременно "отваливаются" независимые друго от друга прокси-серверы на той же площадке, а сам сервер Zabbix (да и его СУБД) в это время высокой нагрузки не имеют. Тут вот чуть подробнее (ссылка).

Грубо говоря, активный прокси устанавливает очередное соединение к серверу, не получает начального ответа SYN/ACK (либо по какой-то причине считает, что он его не получил) и пересылает начальный SYN-пакет повторно - и так несколько раз, пока, наконец, не получает ответ, после чего успешно работает. Но непонятно, из-за чего подобные потери пакетов происходят. Может, между ними есть какой фаервол, который чудит? Например, считает, что происходит слишком много новых соединений в единицу времени, после чего просто блокирует "нарушителя" на 10 минут?

Таймаут 10 минут не из-за блокировки(ну и справедливости ради все файрволы в сети я проверил, там нет блокировок каких-либо). Дело в том, что этот таймаут зашит в код proxy сервера.
Прокси, судя по логу, просто ждет 10 минут и ничего не делает. Почему такое поведение, я честно не понимаю.
А если посмотреть дамп, то мы увидим, что попытки достучаться до сервера были, но потом эти попытки прекратились и наступило 10-минутное ожидание.
Прикладываю кусок лога от zabbix-proxy (IP заменил на 1.1.1.1).
Также приложил скрины с дампом сервера и прокси в момент проблемы.

14:23:51.742 515622:20260901:142350.950 In proxy_data_sender()
14:23:51.742 515622:20260901:142350.950 query [txnlev:0] [select t.taskid,t.type,t.clock,t.ttl,r.status,r.parent_ta skid,r.info,tr.status,tr.parent_taskid,tr.info,d.d ata,d.parent_taskid,d.type from task t left join task_remote_command_result r on t.taskid=r.taskid left join task_result tr on t.taskid=tr.taskid left join task_data d on t.taskid=d.taskid where t.status=1 and t.type in (3,8,9) order by t.taskid]
14:23:51.742 515622:20260901:142350.951 In zbx_connect_to_server() [1.1.1.1]:10051 [timeout:600, connection timeout:30]
14:23:51.742 515622:20260901:142350.951 In zbx_is_ip4() ip:'1.1.1.1'
14:23:51.742 515622:20260901:142350.952 End of zbx_is_ip4():SUCCEED
14:24:16.746 515622:20260901:142407.895 In zbx_is_ip4() ip:'1.1.1.1'
14:24:16.749 515622:20260901:142407.895 End of zbx_is_ip4():SUCCEED
14:24:16.750 515622:20260901:142407.896 In zbx_recv_response()
14:24:16.750 515622:20260901:142407.896 End of zbx_connect_to_server():SUCCEED
14:24:16.750 515622:20260901:142407.896 In zbx_put_data_to_server() datalen:127
14:34:12.599 515622:20260901:143408.465 End of zbx_recv_response():FAIL
14:34:12.602 515622:20260901:143408.466 End of zbx_put_data_to_server():FAIL
14:34:12.603 515622:20260901:143409.472 In zbx_connect_to_server() [1.1.1.1]:10051 [timeout:600, connection timeout:30]
14:34:12.603 515622:20260901:143408.466 cannot send proxy data to server at "1.1.1.1": read timeout
14:34:12.603 515622:20260901:143408.466 End of proxy_data_sender():FAIL more:0 flags:0x8000
14:34:12.603 515622:20260901:143408.467 zbx_setproctitle() title:'data sender [sent 0 values in 617.517461 sec, idle 1 sec]'
14:34:12.603 515622:20260901:143408.467 In zbx_ipc_async_socket_recv() timeout:1
14:34:12.603 515622:20260901:143409.469 End of zbx_ipc_async_socket_recv():0
14:34:12.603 515622:20260901:143409.470 zbx_setproctitle() title:'data sender [sent 0 values in 617.517461 sec, sending data]'