Проблемные активные проверки и рост очер

[sadman]

Относительно недавно, используя UserParameter с PowerShell, что конечно не характеризует меня с лучшей стороны, я столкнулся с необъяснимым на тот момент ростом очереди.

Необъяснимость заключалась в том, что активные проверки - Zabbix agent (active) примененные в шаблоне для облегчения, как мне казалось, жизни заббиксу, всё только осложняли. Казалось бы, что всё очень логично - агент должен дергать скрипты, собирать что нужно, пачкой слать серверу, тот просто раскладывать значения по базе и не напрягаться. Однако очередь росла, графики пожирали лангольеры... Вобщем, что-то вроде этого: https://www.zabbix.com/forum/showpos...0&postcount=64

Диагностику и решение проблемы я начал классически - с анализа графиков нагрузок и кручения всяких там параметров типа размера буфера, подстройки SQL... Все было бесполезно. Но, решив взяться за дело серьёзно, я специально установил Zabbix Server на одной виртуалке, Zabbix Agent на другой, т.е. отсек нагрузку полностью. Дал им по несколько процессоров, тонны памяти. Применил шаблон, который обеспечил мне порядка 400 элементов данных, снимаемых в активном режиме со средним интервалом в 70 сек, подвесил на UserParameter простецкий скрипт - "sleep 1 && echo 1". И что же в итоге? Получил очередь в 330 элементов. Быстродействие - 1,5 элемента/сек.

Далее я провел эксперимент, подсовывая агенту разные варианты скрипта (в перловой обертке, в bash), выполняющиеся за разные периоды времени. Получилась такая картина:



Зеленые всплески и красные провалы (11:40) - установка sleep в 0.
Красный всплеск и зеленый горб (11:46) - установка sleep в 1.
Спад зеленого горба (11:50) - установка sleep в 3.

При этом atop никакой нагрузки не показывал ни на агентской, ни на серверной виртуалке. Т.е. все указывало на утерю данных агентом или отсутствие их сбора. Пришлось чертить пентаграмму и устанавливать DebugLevel в 4.

...и что? И ничего. Сервер принимает всё, что ему дают, агент отправляет всё, что насобирал, failed items отсутствуют. Агентский Buffersize выставил в 1000, Timeout в 30 - эффекта никакого,

Единственное, что нашел в логе, так это сообщение "active checks #1 [idle 1 sec]". Только #1, никогда #2. В один тред выполняются активные проверки. И этот тред умудряется их терять, если просрочен момент времени запуска (рабочая гипотеза).

А теперь вопрос: Кто-нибудь знает, что с этим попытаться сделать или, может, уже сделал? Или же я заслоупочил в каком-либо месте?

[fafhrd]

пробовал в конфиге zabbix_server.conf увеличивать параметр?
StartDiscoverers=
совет из разряда пальцем в небо...

[sadman]

пробовал в конфиге zabbix_server.conf увеличивать параметр?
StartDiscoverers=
совет из разряда пальцем в небо...

Это точно... Какая может быть связь между Discover-процессами на сервере и тем, что агент просто не запускает проверки - расскажите...

[glebs.ivanovskis]

Да, активные проверки выполняются в один поток (на каждый ServerActive), а не распределяются между listener'ами как пассивные. И у агента есть свой собственный таймаут (грубо говоря, сколько времени он может потратить на выполнение проверки). Поэтому в случае долгоиграющих скриптов целесообразно инициировать их выполнение пассивной проверкой, а результат ожидать в траппере, куда сам скрипт должен его забросить zabbix_sender'ом.

[sadman]

Траппер неплохо выглядит для некоторого одиночного примера, который можно показать в презентации.

Однако мне не совсем понятно, как в рабочих средах скрестить LLD и Zabbix Trapper - каким образом дать скрипту понять, что раз в 38 секунд необходимо слать размер базы данных, имя которой подпадает под условие, описываемое фильтром (к примеру)?

Единственный вариант, который я могу представить:

UserParameter=CheckSomething[*], cs.sh -p1 $1 .. -p9 $9 -zbxcmd "CheckSomething[$0]"

Но для этого необходимо, чтобы тип элемента данных Zabbix Agent одновременно мог выступать и траппером. В документации я такой возможности не встретил. Такое всё же возможно или нет?

[Kos]

Однако мне не совсем понятно, как в рабочих средах скрестить LLD и Zabbix Trapper - каким образом дать скрипту понять, что раз в 38 секунд необходимо слать размер базы данных, имя которой подпадает под условие, описываемое фильтром (к примеру)?

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

Пример
На AIX-ах нам надо мониторить производительность дисковой подсистемы.
Командой iostat -adt можно получить список адаптеров, но нас интересуют только те из них, которые работают по оптике (FC, их имена начинаются с "fcs"). Аналогично, список дисковых устройств можно получить командой iostat -d, но нас интересуют только реальные дисковые устройства (имена начинаются с "hdisk").
В то же время, команда iostat достаточно "тяжёлая", для получения статистики производительности запускать её по разу для каждого адаптера и каждого диска будет чересчур расточительно.
Поэтому делаем следущим образом:

• определяем через UserParameter несколько скриптов;
• один скрипт возвращает JSON со списком адаптеров;
• другой срипт возвращает JSON со списком дисковых устройств;
• третий скрипт дважды вызывает команды iostat (один раз - для сбора статистики по адаптерам, другой - по дискам), после чего всю собранную по интересующим устройствам статистику разом засылает на сервер через zabbix_sender. Сам, в свою очередь, возвращает ReturnCode zabbix_sender-а.

Item-ы для всех этих трёх скриптов имеют тип "Zabbix Agent (active)", при этом реальные данные отсылаются в Item-ы, созданные через механизм LLD и имеющие тип "Trapper".
Если интересно, могу приложить сами скрипты (там всего-то несколько строк, правда, довольно длинных).

[sadman]

Командой iostat -adt можно получить список адаптеров, но нас интересуют только те из них, которые работают по оптике (fc, их имена начинаются с "fcs"). Аналогично, список дисковых устройств можно получить командой iostat -d, но нас интересуют только реальные дисковые устройства (имена начинаются с "hdisk").

Т.е.:
1) Фильтрация и ее настройка производится на стороне агента либо серверу отдаётся вообще всё, что можно вытащить из iostat, а он уже принимает или реджектит в зависимости от наличия элемента данных;
2) Все элементы данных де-факто имеют один и тот же период обновления без всяких там гибких интервалов, периодов обслуживания и пр.

Я правильно понял?

[Kos]

Т.е.:
1) Фильтрация и ее настройка производится на стороне агента либо серверу отдаётся вообще всё, что можно вытащить из iostat, а он уже принимает или реджектит в зависимости от наличия элемента данных;
2) Все элементы данных де-факто имеют один и тот же период обновления без всяких там гибких интервалов, периодов обслуживания и пр.

Я правильно понял?

По первому вопросу - ответ "да"
Т.е. серверу отдаётся всё, что мы считаем полезным (вся интересующая нас статистика). При этом что-то из этого сервер может не принять (фактически - принять и отправить в /dev/null) при условии, если ещё не отработал дискаверинг для, например, нового диска.

По второму вопросу - ответ тоже "да". Т.е. интервал обновления, фактически, задаётся тем, когда у нас опрашивается Item, привязанный к третьему скрипту. В моём случае он имеет тип "Zabbix agent (active)", но с тем же успехом можно использовать пассивные проверки - тогда будут доступны гибкие интервалы. Период обслуживания задаётся для хоста, а не для item-а. Но в любом случае Вы правы в том, что для всех item-ов эти данные собираются одновременно. Один хрен, для их получения надо запускать iostat; поэтому раз уж запустили - то и получите. Как-то так

[sadman]

Этим путем я уже ходил и он мне не понравился.

Несколько точек администрирования; нагромождение костылей для подправления фильтров в случае со множеством контролируемых узлов; необходимость формировать/трансформировать/вычислять и пересылать тонны элементов данных, из которых для определенного узла нужны, может быть, штуки две; бессмысленная бомбардировка Zabbix-сервера каждый минимальный цикл опроса...

В качестве статичного решения, пользователем которого являешься только ты сам - такой способ допустим. Но как только помещаешь это в Zabbix Share - объяснить зачем пошёл кружным путем или помочь разобраться с тем, почему это не работает там, а работает здесь, становится сложновато, как минимум.

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

В идеале, конечно, одновременное отфоркивание активных проверок.