icmppingloss создает очередь

[tuban]

zabbix 2.0.9. Хочу мониторить процент потерянных пакетов при пинге.
Создаю элемент данных:

icmppingloss[<цель>,10,100,64,1000]
Время 1 секунда

10 пакетов, через 100мс в секунду.

Либо:

icmppingloss[<цель>,10,1000,64,1000]
Время 10 секунда

10 пакетов, через 1 секунду в 10 секунд.

Казалось бы, все хорошо, потери мониторятся с шагом в 10%, но возникает очередь, около 10 секунд, доходит и до минуты. Причем poller icmp загружен менее чем на 10%.

Когда использую icmppingloss с дефольтным значением, все хорошо, но, по умолчанию там всего 3 пакета. Как только я меню какой-либо параметр, возникает очередь.

[Jimson]

По умолчанию интервал между успешными реквестами нулевой, следовательно тест из 10 icmp запросов может занять меньше секунды, в вашем же случае минимальное время тестирования 10 * 0.1s = 1s в первом случае и 10 * 1s = 10s во втором случае. Это при условии НУЛЕВОГО RTT.

Предположим у вас RTT 50ms, тогда в первом вашем примере при 0% loss время теста будет 10 * (0.1 + 0.05) = 1.5s, при 10% loss тест будет длиться 9 * (0.1 + 0.05) + 1 = 2.35s. А во втором примере минимальное время теста составит 10.5 секунд.

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

[tuban]

Хорошо, если оборудование в соседней комнате, задержка 5ms, а если это спутниковый канал - задержка 800. То есть, если я правильно понимаю, мне нужно брать по максимуму, допустим rtt 1000:

icmppingloss[<цель>,10,100,64,1000]
Время 11 секунда
10 * (0.1 + 1)=11

Если в вашем случае, при 50 ms, то:

icmppingloss[<цель>,10,100,64,50]
Время 9.15 секунда
1* (0.1 + 0.05)+9=9.15

Я правильно понимаю?

[Jimson]

Ну во первых, если спутник и с средний RTT ~700ms, то ожидание ставить 1000 нельзя, RTT может запросто до 1500 и выше подниматься.

Во вторых, если вы считаете исходя из 1000ms RTT, то у вас получается 1000ms ожидание ответа на icmp + 100ms интервал между успешными icmp. Вот проверьте, а то я засомневался на счет этого интервала, это минимальное время между успешными пакетами или это принудительный интервал между успешными пакетами, сделайте тестовый элемент с интервалом скажем 2000 и посмотрите с какой периодичностью icmp будут отсылаться.

Короче, при 1000 RTT у вас 10 пакетов минимум 10 секунд будут слаться. На очередь в районе минуты можете внимания не обращать, особенно когда имеете дело с спутниковыми каналами.

Допустим вы делаете SNMP check через спутниковый линк, он не прошел, таймаут, запускается механизм UnreachablePeriod/UnreachableDelay, там по умолчанию вроде 15 секунд задержка, по истечении задержки check повторяется, в это время у вас этот итем в "очереди" показывается как опаздывающий уже секунд на 30 минимум.

P.S. вы сами оператор спутникового пд или вы клиент? аккуратнее с мониторингом через спутниковые каналы, обратный канал TDM и как следствие частыми чеками можно очень сильно ресурс скушать

[tuban]

Скорее, как пользователь услуги.
Согласно документации - это минимальное время между успешными пакетами.
RTT 1500, даже для спутника, это уже неприемлемо. Так что, считаю что 1000 ms более чем достаточно.

В общем, сделал, как писал в предыдущем посте:

icmppingloss[<цель>,10,100,64,1000]
Время 11 секунда
10 * (0.1 + 1)=11

Очереди нет. Иногда проскакивает 5-20 элементов в 5 секунд. Потери отображаются корректно, с шагом в 10%. Возможно, стоит поставит 11,5 или даже 12 секунд?..

Конечно, подросло value per second, где-то на 10. И трафик килобит на 200. Но, в принципе - пойдет. Я не думаю, что пингом с размером пакета 64 можно перегрузить спутниковый канал.

[Jimson]

RTT 1500, даже для спутника, это уже неприемлемо. Так что, считаю что 1000 ms более чем достаточно.

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

И трафик килобит на 200. Но, в принципе - пойдет. Я не думаю, что пингом с размером пакета 64 можно перегрузить спутниковый канал.

Еще раз говорю, вы работаете с TDM каналом, нельзя расчет вести от размера IP пакета, надо считать вашими TDM ячейками. Например, на хабах Gilat в обратных каналах обычно фрейм это 4ATM ячейки (192 байта если вам так угодно), т.о. ваши 200kb уже превращаются в 600kb. Учитывая что в обратных каналах используется относительно надежная модуляция/fec (передающая сторона VSAT, следовательно передатчик и размер зеркала напрямую влияет на стоимость инсталляции), что бы получить информационную скорость в 600kb нужно примерно 0.8Mhz. Стоимость мегагерца в Ku диапазоне где то в районе 3000-5000 зеленых президентов в месяц. Это мы еще не считали прямой канал, хоть он и заметно эффективнее. Пингуйте на здоровье

[tuban]

Подниму старую тему. Забудем о спутниковых каналах, теперь все каналы наземные. Предположим, что задержка да 200 ms. В мониторинге около 400 устройств.
Простая проверка icmppingloss [,10,500.64.1000] раз в 90 секунд. То есть, раз в 90 секунд zabbix посылает 10 пакетов с интервалом 500, размером 64 и ждет ответа 1 секунду. Очереди нет. Я увеличиваю количество пакетов до 20, появляется очередь 5-10 секунд, в район 60 шт. Казалось бы, 90 секунд более чем достаточно, в чем может быть дело?
Спасибо.

[Jimson]

Еще раз, "задерживается" в очереди это время между началом пулинга и временем получения ответа. В вашем случае при 500ms между ICMP реквестами для получения значения icmpping*[] из 20 ICMP пакетов нужно 10 секунд. Таким образом у вас на "5-10 секунд опаздывают" все ЭД, а не только "60 штук", просто они уходят из очереди как только дожидаются значения.

P.S. интервал опроса - 90 секунд - тут вообще никаким боком не участвует, он используется только при постановке ЭД в очередь пулера и для построений графиков

[tuban]

Еще раз, "задерживается" в очереди это время между началом пулинга и временем получения ответа. В вашем случае при 500ms между icmp реквестами для получения значения icmpping*[] из 20 icmp пакетов нужно 10 секунд. Таким образом у вас на "5-10 секунд опаздывают" все ЭД, а не только "60 штук", просто они уходят из очереди как только дожидаются значения.

P.s. интервал опроса - 90 секунд - тут вообще никаким боком не участвует, он используется только при постановке ЭД в очередь пулера и для построений графиков

Спасибо за ответ. Как-то можно избежать образования очереди, в таком случае? Почему такого нет при 10 пакетах? Ведь, картина должна быть похожей.

[Jimson]

Потому что 10 пакетов это как раз 5 секунд при 500ms интервале между ICMP реквестами. Открой detail очереди и увидишь все что находится в пуле опроса. Что значит "избежать"? Пуллинг происходит через очередь.