Моя архитектура в AWS следующая:
Существует 2 идентичных агента zabbix (на основе zabbix / zabbix-agent: centos-4.0.11), каждый из которых работает на разных экземплярах EC2. Zabbix-сервер работает на третьем экземпляре (также dockerized с помощью dockbix, использующего версию 4.0), все три из них находятся внутри одного VPC.
Идея состоит в том, чтобы иметь балансировщик сетевой нагрузки, который прослушивает порт, который запущен обоими агентами (10050), и имеет эти 2 вышеупомянутых экземпляра, зарегистрированные в целевой группе. Затем DNS этого NLB будет предоставлен конфигурации хоста Zabbix в качестве интерфейса. Цель состоит в том, чтобы иметь несколько хостов zabbix, нацеленных на один и тот же NLB, и их запросы маршрутизируются в соответствии с нагрузкой трафика на разные агенты. На каждом хосте есть элемент агента zabbix, который вызывает UserParameter (скрипт python), который определен в каждом из двух файлов conf агента zabbix.
Моя проблема заключается в следующем: zabbix_get (и эквивалентный вызов, выполняемый автоматически в соответствии с интервалом, установленным в конфигурации хоста) время от времени истекает. Один раз я получаю успешный ответ
{"ответ": "успех", "информация": "обработано: 4; сбой: 0; всего: 4; затрачено секунд: 0,000106"}
(Используемый скрипт python работает довольно быстро, это занимает всего 1 секунду), а иногда я получаю ответ, например:
zabbix_get [4515]: Тайм-аут при выполнении операции.
Это происходит одно за другим. Итак, один успешно, следующий таймаут, затем следующий успешен и так далее.
Я попытался проверить соединение с помощью telnet, и он работает все время. Я даже пробовал использовать простой контейнер tcp echo, который также все время работал нормально.
Приветствуются любые идеи о том, что может быть не так :)
РЕДАКТИРОВАТЬ: Просто хотел отметить, что это поведение происходит не только с моим настраиваемым скриптом, определенным UserParameter, но также и со встроенными вызовами агентов, такими как agent.version или agent.ping или net.tcp.port[<serverIp>, 10051] и т.д
РЕДАКТИРОВАТЬ2: С участием tcpdump src <serverIp> запускать внутри экземпляров агента кажется, что есть аналогичный трафик с успешным и тайм-аутом ответа
Очевидно, мне нужно было включить балансировку нагрузки между зонами доступности для моего внутреннего nlb. Вот почему время ожидания каждого второго запроса истекало, поскольку все мои экземпляры находились в одном регионе доступности.