zabbix-agentd - Потери метрик

[Kos]

Ну, вот, к примеру.

https://www.zabbix.com/forum/in-russian/45335-%D0%9F%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%BD%D1%8B%D0%B5-%D0%B0%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B5-%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8-%D0%B8-%D1%80%D0%BE%D1%81%D1%82-%D0%BE%D1%87%D0%B5%D1%80?p=267910#post267910

glebs ivanovskis из команды Zabbix, как я помню.

Так же, подтверждение или опровержение можно получить из исходных текстов Zabbix agent.

sadman, Глеб подтверждает лишь то, что сказано Вами в первом предложении, но нигде не говорит того, что сказано во втором предложении:

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

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

[sadman]

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

От какой версии были исходники? На тот момент я не нашёл в них намёков на очередь, а проверки просто не запускались. Повторно к анализу не возвращался.

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

Всё меняется, вероятно что уже есть и некоторая очередь =) У меня времени на анализ исходников гораздо меньше, чем у Zabbix SIA на их правку.

В любом случае - спасибо за уточнение.

[Kos]

От какой версии были исходники? На тот момент я не нашёл в них намёков на очередь, а проверки просто не запускались. Повторно к анализу не возвращался.

Я ковырялся в версии 3.0. Не думаю, что в данном отношении логика там сильно отличается.

[max.ch.88]

Ну, вот, к примеру.

https://www.zabbix.com/forum/in-russian/45335-%D0%9F%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%BD%D1%8B%D0%B5-%D0%B0%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B5-%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8-%D0%B8-%D1%80%D0%BE%D1%81%D1%82-%D0%BE%D1%87%D0%B5%D1%80?p=267910#post267910

glebs ivanovskis из команды Zabbix, как я помню.

Так же, подтверждение или опровержение можно получить из исходных текстов Zabbix agent.

Спасибо за информацию. Не знал.
Остается непонятным профит от активных проверок. Предположим на хосте 100 активных метрик с интервалом минута и каждая обрабатывается за секунду, таймаут агента 30 секунд. Если активный агент обрабатываает всё по очереди в один поток, то с 31й по 100ю метрики будут задержаны, поменяют статус на Not supported и по ним будет became not supported в логе сервера. Значения по метрикам приходить будут, но значительно реже установленного интервала. Сомнительная выгода от снижения нагрузки на сервер при замене пассивных проверок на активные.

[Semiadmin]

Есть нюанс - активные проверки не становятся Not supported. Разве что проверки логов при отсутствии указанного файла лога или доступа к нему.

[sadman]

Спасибо за информацию. Не знал.
Остается непонятным профит от активных проверок.

Очевидный профит проистекает из направления движения данных. Если агент сидит за натом и порт на него пробросить возможности нет, то активные проверки выручают просто отлично. В локалке всё не так очевидно, конечно.

Второй профит, которым я пользуюсь - короткие активные проверки (типа cpu.load и т.п.) разгружают сервер, так как на каждую не требуется открывать коннект, а все уже собранные значения метрик приходят на сервер пачкой. При этом вероятность их невыполнения/задержки стремится к нулю.

А вот долгие проверки на данном этапе развития Zabbix, полагаю, есть смысл перевести в пассивный режим, посадить на крон либо отфоркивать с последующим вызовом zabbix_sender для доставки значения в Item.

[Kos]

Остается непонятным профит от активных проверок. Предположим на хосте 100 активных метрик с интервалом минута и каждая обрабатывается за секунду, таймаут агента 30 секунд. Если активный агент обрабатываает всё по очереди в один поток, то с 31й по 100ю метрики будут задержаны, поменяют статус на Not supported и по ним будет became not supported в логе сервера. Значения по метрикам приходить будут, но значительно реже установленного интервала. Сомнительная выгода от снижения нагрузки на сервер при замене пассивных проверок на активные.

Выделенное синим неверно.

Если каждая из 100 активных проверок занимает секунду, то тайм-аут агента здесь не играет (каждая отдельная проверка в него укладывается), а за минуту таких проверок может быть обработано 60. Соответственно, оставшиеся 40 будут обработаны после них. Однако, к тому моменту уже будут требовать повторной проверки некоторые из первых 60, поэтому при таких начальных условиях какие-то проверки будут пропускаться. На сервер же будут передаваться все полученные результаты проверок; если они валидные - то статуса Not Supported возникать не будет. Но надо сказать, что большинство штатных проверок выполняются очень быстро (доли секунды), поэтому такой пример на практике весьма маловероятен (хотя и возможен).

Что же касается выгоды, то аргументов может быть несколько:

• некоторые метрики (log/logrt, eventlog) могут работать только в активном режиме;
• меньше нагружается сервер: слежением за расписанием проверок занят не он, а агент;
• если у нескольких проверок есть совпадающие или кратные интервалы, то результаты будут отсылаться на сервер сразу "пачкой" за одно соединение; в противоположность пассивному режиму, где на каждую проверку - своё соединение (меньше грузится и сервер, и агент, и сеть);
• какое-то количество результатов проверок может быть закэшировано агентом; в случае проблем с передачей на сервер (сеть недоступна, сервер перезагружается и т.п.) они будут отосланы после восстановления связи (в случае пассивного режима данные просто будут потеряны).
• как верно отметил sadman, в зависимости от конфигурации сети может оказаться проще пробросить нужные соединения (типичный пример - агент за NAT-ом).

[Kos]

Есть нюанс - активные проверки не становятся Not supported. Разве что проверки логов при отсутствии указанного файла лога или доступа к нему.

Я бы не был столь категоричен.

Во-первых, любой элемент данных (независимо от способа получения данных) может стать Not supported из-за несовпадения типов: например, если для типа "Numeric (unsigned)" придёт отрицательное число или для типа "Numeric (любой)" придёт не-число (скажем, пустая строка).

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

[Semiadmin]

Я бы не был столь категоричен.

Во-первых, любой элемент данных (независимо от способа получения данных) может стать Not supported из-за несовпадения типов: например, если для типа "Numeric (unsigned)" придёт отрицательное число или для типа "Numeric (любой)" придёт не-число (скажем, пустая строка).

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

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


.

[Semiadmin]

Проверил, был неправ. По таймауту активный тоже падает в Not supported.

[max.ch.88]

Ну, вобщем, что-то мы спорим не о том.

Активные проверки выполняются в один поток. Если одна из них выполняется достаточно долго, то запуски всех остальных, должные произойти в то же время, будут пропущены. До тех пор, пока Вы запускаете активную проверку каким угодно, но блокирующим способом, проблема принципиально не будет решаться, но может быть замаскирована. Единственный логично выглядящий выход - произвести запуск максимально быстро, снизив вероятность перекрытия временем выполнения текущей проверки момента запуска следующей. Т.е. отфоркнуть процесс с расчётом на то, что он сам вернёт результат в Zabbix server.

Пассивные проверки таким проблемам не подвержены, каждая из них запускается в своём потоке и на параллельные проверки практически не влияет.

В общем на данный момент я не знаю другого способа, кроме Timeout, на unix для ограничения времени выполнения команд. Помогает не уйти в not support для item и network error для хоста. И для активных и для пассивных item.