Одновременная работа активных и пассивн&

[Daria B.]

Есть zabbix-сервер, для него через web-интерфейс уже настроены несколько узлов сети, на каждом узле - по несколько элементов данных с типом "Zabbix агент", т.е. элементы данных собираются в пассивном режиме, с определенной периодичностью на основе запросов от сервера к хостам с установленным на них агентом. Данные собираются корректно.

Возникла необходимость на одном из таких хостов получать дополнительные данные путем вызова утилиты zabbix_sender.

Через web-интерфейс zabbix-а был настроен новый элемент данных с типом "Zabbix траппер". Если на машине, с которой требуется отправка этих данных, запустить утилиту zabbix_sender (zabbix_sender.exe -z <адрес сервера> -s <имя узла сети> -p <порт сервера> -k <ключ элемента данных> -o <значение элемента данных> -vv) - она отрабатывает только в то время, когда не выполняются ранее настроенные пассивные проверки от сервера к агенту.

Если же запустить sender в момент такой проверки - возвращается ошибка Connection timeout occured, после завершения проверки - sender снова отрабатывает, данные передаются на сервер корректно (их можно просмотреть через web-интерфейс zabbix-сервера, данные обновляются).

Полный текст ошибки, возвращаемой sender-ом в момент запуска пассивных проверок сервера к агенту: zabbix_sender.exe [6988]: DEBUG: send value error: cannot connect to [[X.X.X.X]:10051]: A connection timeout occurred. Sending failed.

По данному вопросу уже проведена большая аналитическая работа (подробности можно посмотреть в http://stackoverflow.com/questions/4...o-not-work-sim), но, к сожалению, решения найти не удалось.

Порт 10051 на сервере открыт, firewall нет. Ошибка происходит только при включенных пассивных проверках. Допустим, есть хотя бы одна пассивная проверка и она настроена на запуск каждые 5 минут. В 15-05 следующий запуск, в 15-04 еще sender возвращает данные, с 15-05 по 15-06 - уже нет (видим ошибку). Воспроизводится это не всегда - в среднем одна ошибка на 2-3 успешных запуска (возможно, в эти моменты просто пассивные проверки отрабатывают быстрее). Если в момент ошибки на хосте запустить netstat - будет видно, что хост активно пытается установить соединение с 10051 портом сервера (находится в статусе SYN_SENT), но ответа не получает. Как только пассивная проверка отключается - каждый запуск sender становится успешным, потерь нет.

И еще одна особенность - пробовали настроить активные проверки (для элементов данных с типом "Zabbix агент (активный)") - они одновременно с пассивными проверками работают, но в логе при получения списка активных итемов с сервера периодически появляется все та же ошибка: " 3736:20170117:161538.336 active check configuration update from [X.X.X.X:10051] started to fail (cannot connect to [[X.X.X.X]:10051]: A connection timeout occurred.)
3736:20170117:161808.145 active check configuration update from [X.X.X.X:10051] is working again
3736:20170117:161931.076 active check data upload to [X.X.X.X:10051] started to fail ([connect] cannot connect to [[X.X.X.X]:10051]: A connection timeout occurred.)
3736:20170117:162015.178 active check data upload to [X.X.X.X:10051] is working again".

Вопрос: возможна ли одновременная работа активных и пассивных проверок на одном хосте и, если возможна, что для этого необходимо предпринять? И в чем может быть причина возникающей у нас ошибки? Заранее спасибо.

[Kos]

Используем и активные (преимущественно), и пассивные проверки. Описываемого эффекта не замечали. Я даже затрудняюсь предположить, отчего он может возникать - как-то слишком неправдоподобно звучит.
А с какой версией сервера и агентов вы работаете?

[Daria B.]

Хост с агентом - Windows Server 2008 R2 Enterprise
Сервер - CentOS Linux release 7.2.1511 (Core)
Версия zabbix-сервера - 3.0.4

Эта проблема зафиксирована не только на одном хосте, а уже на двух разных. Другие пока не проверяли, но, вполне вероятно, будет и на них.

[Kos]

Я имел в виду версию агента Zabbix, а не только операционки.

Если же запустить sender в момент такой проверки - возвращается ошибка Connection timeout occured

Я, честно говоря, не очень понимаю, как вы оцениваете одновременность - у вас что, пассивные проверки идут несколько секунд, что можно точно сказать, что вот этот запуск zabbix_sender-а было именно во время пассивной проверки?

Но даже если так - то возникает ли проблема в случае, если во время пассивной проверки данного агента запустить zabbix_sender с теми же параметрами (в том числе -s <имя узла сети>) с физически другой машины (например, с самого сервера Zabbix)? Только убедиться, что в настройках элемента данных не запрещён приём с другого IP.

[Daria B.]

Версия агента - zabbix_agentd Win64 (service) (Zabbix) 3.0.4
Revision 61174 15 July 2016, compilation time: Jul 22 2016 15:31:49

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

И я не случайно упомянула лог по активным проверкам с той же ошибкой. Оставляли на длительный срок выполнение только активных проверок - ни одной ошибки в логе, как только включаются пассивные проверки - регулярно появляется ошибка "A coonection timeout occured.".

С другого хоста вызвать sender не пробовали, попробуем.

[Kos]

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

Т.е. пассивная проверка сама по себе отрабатывает быстро, но ещё на протяжении целой минуты после этого zabbix_sender отрабатывает с ошибкой тайм-аута?

Честно говоря, похоже на "глюк" операционки там, где крутится агент. У вас на этой Windows-машине нет ли каких наворотов, которые могут контролировать сетевой трафик (Windows firewall, продвинутые антивирусы и т.п.)?

В любом случае, очень любопытен результат эксперимента с запуском zabbix_sender-а с другого хоста.

[sadman]

Честно говоря, похоже на "глюк" операционки там, где крутится агент. У вас на этой Windows-машине нет ли какиъх наворотов, которые могут контролировать сетевой трафик (Windows firewall, продвинутые антивирусы и т.п.)?

Или selinux на Centos...

[Kos]

Или selinux на Centos...

Да, не исключено.

Собственно, эксперимент с запуском zabbix_sender-а с другой машины и должен помочь это локализовать.

Хотя... если проблема в операционке (хоть на сервере, хоть на агенте), то с большой вероятностью эксперимент завершится успешной работой zabbix_sender-а (запрос-то на сервер придёт с другого IP).

[Daria B.]

На хосте с агентом есть Windows FireWall, но в нем для zabbix_agentd и zabbix_sender разрешены все порты.

Попробовали с другого хоста (условно Хост2). Запускали с него zabbix_sender, который реально отправлял данные для элемента данных "zabbix-траппер", настроенного для первого хоста (Хост1) (-s Хост1 использовали в команде). Проверяли во время пассивной проверки на Хосте1. Работает. Видела такую вещь даже - на Хосте1 sender "висит", в это же время с Хоста2 удалось отправить успешно два значения.

Но - в самый первый раз при запуске с Хоста2 была зафиксирована ошибка - к сожалению, случайно убрала опцию -vv и не было видно текста ошибки, только "fail: 1". Сейчас настроила автоматический вызов sender с Хоста2 одновременно с запуском пассивной проверки на Хосте1 - последим в течение длительного времени, будут ли ошибки и какие.

[Daria B.]

Последняя статистика. За практически 2 часа проверок с Хоста2 не было обнаружено ошибок в работе zabbix_sender, при этом с Хоста1 ошибки возникают и причем во время таких ошибок с Хоста2 ошибка не фиксируется.

На обоих хостах есть FireWall и антивирус Kaspersky.

Но для Хоста2 в пассивном режиме сейчас ничего не собирается.

Кроме этого, ранее мы проверяли этот же Хост2 - настраивая для него пассивную проверку и запуская одновременно с ней sender (только естественно именно для его элементов данных-трапперов, а не как сейчас для другого хоста) - ошибка фиксировалась.

[Daria B.]

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

И еще момент. Я все думаю про то, что вы написали, как обрабатываются активные проверки (в рамках одного потока). Дело в том, что у нас есть несколько юниксовых серверов, где в конфигурационном файле агента остался заполнен ServerActive, хотя реально для них активные проверки никогда не использовались. Но при наличии этого параметра раз в 2 минуты агенты же запрашивают сервер на предмет обновления активных итемов, т.е. с агента шлются регулярно запросы вида "request":"active checks". Не может быть так, что в определенные моменты из-за большого числа таких запросов перестают восприниматься прочие запросы для активных проверок, в том числе с sender-а ? Но тогда почему при отключении пассивных проверок все стабилизируется на хосте, хотя в это время запросы "request":"active checks" все так же продолжают идти ?

[Daria B.]

И последняя интересная информация. На Хосте2 sender работал сегодня успешно на протяжении 4 часов (отправлял данные для итема-траппера Хоста1, как вы помните). Для эксперимента добавила на Хост2 пассивную проверку - и сразу же стала возникать периодически наша ошибка.

И теперь, наконец, поняла, откуда была самая первая ошибка, о которой я писала (где не видно было текста полного из-за пропущенного ключа -vv). Странно, что произошла одна ошибка, а потом 4 часа ни одной, да? Дело в том, что на Хосте2 работала пассивная проверка, я ее отключила прежде чем настроить sender, но при первом запуске минута, наверно, не прошла с последнего запуска пассивной - и ошибка появилась.

Вывод - связь с пассивными проверками очевидна.

[pzabortsev]

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

Можно поподробнее: сколько и какие элементы данных собираются? Все стандартные проверки или есть кастомные (UserParameters)? Проблема воспроизводится при уменьшении числа элементов с пассивной проверкой?

[sadman]

И последняя интересная информация. На Хосте2 sender работал сегодня успешно на протяжении 4 часов (отправлял данные для итема-траппера Хоста1, как вы помните).

Что во время ошибок происходит в очереди опроса? Может определенные элементы затыкаются?

Ну и до кучи - на графиках Zabbix data "Gathering process busy %" намекающих на что-нибудь цифер нет?

[Daria B.]

Можно поподробнее: сколько и какие элементы данных собираются? Все стандартные проверки или есть кастомные (UserParameters)? Проблема воспроизводится при уменьшении числа элементов с пассивной проверкой?

Сейчас порядка 300 узлов, порядка 2000 элементов данных на них и порядка 1500 триггеров. Элементы данных до этого абсолютно все были с типом "Zabbix агент" (пассивные проверки). Практически все стандартные.

Уменьшать не пробовали.

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

Что во время ошибок происходит в очереди опроса? Может определенные элементы затыкаются?

Очередь проверяли в момент ошибки - ничего необычного не происходит. Вообще, если смотреть на встроенную внутреннюю проверку Zabbix queue - у нас хорошая статистика, иногда только до единицы поднимается, но вчера за время проверок все время было на 0. У нас до этого до 500 поднималось периодически, но после увеличения в конфиге сервера числа StartPollers до 25 все нормализовалось.

Ну и до кучи - на графиках Zabbix data "Gathering process busy %" намекающих на что-нибудь цифер нет?

Что-то такой внутренней проверки не вижу. Вы имеете в виду: "Zabbix busy poller processes, in %"? На этом графике никаких скачков именно во время ошибок не наблюдали. У нас эта цифра в районе 30-40%, сейчас после ввода дополнительных узлов очень редко до 50% поднимается, до этого до 90% было, но увеличение StartPollers помогло.