Вычисление Jitter'a

[ZeeD]

Привет всем,

подскажите пожалуйста, как считать Jitter силами Zabbix'а?
На форуме ответа не нашел, штатных средств нету

[ugh]

ключ - icmppingsec

[ZeeD]

Спасибо за очень подробный и развёрнутый ответ!

Jitter вычисляется по формуле, упомянутой в RFC 3550, кто-нибудь реализовывал подобное в Zabbix'е?

[dima_dm]

Если хотите готовое сертифицированное решение, то вам сюда (есть модуль к Zabbix)

http://www.net-probe.ru/index.php?option=com_content&view=article&id=49&Itemid=59&lang=ru

Если хотите сделать сами, то пишите скрипт который проводит тест и вычисляет Jitter и запускаете скрипт через Zabbix Agent и UserParameter.

[ugh]

оценить и контролировать время прохождения пакетов можно с помощью вышеуказанного элемента данных
вероятно, это не совсем верно, использовать icmp протокол
в рфц не вчитывался, но нужные размеры пакетов и интервалы между ними можно подогнать:

icmppingsec[<цель>,<пакеты>,<интервал>,<размер>,<таймаут>,<реж им>] Возвращает время ответа на ICMP ping
цель - IP адрес или DNS имя хоста
пакеты - количество пакетов
интервал - время между успешными пакетами в миллисекундах
размер - размер пакета в байтах
таймаут - время ожидани в миллисекундах
режим - один из min, max, avg (по умолчанию) Количество секунд

и опять же, всегда можно воспользоваться скриптами внешних проверок, с использованием различного по

[dima_dm]

и опять же, всегда можно воспользоваться скриптами внешних проверок, с использованием различного по

Тут проблема даже не в этом. Такие параметры нужно вычислять сенсорами установленными как можно ближе к тестируемому каналу. А icmppingsec и внешние проверки работают с Zabbix Server.
Поэтому задачу нужно решать с помощью Zabbix Agent и UserParameter. И ставить машину с Zabbix Agent как можно ближе к тестируемому каналу.

[ugh]

логично)))
все дело в точности, которой нужно добиться)))

[ZeeD]

Так, спасибо за наводки
Теперь ближе к делу.
Схема такая: zabbix-switch-<ISP cloud>-router
ISP гарантирует "круговой" jitter на этом канале, вот мне его и надо мониторить.
Задержкой "zabbix-switch" можно принебречь, она в районе 1-2ms.

Теперь вопрос, ради которого и был открыт этот тред:
можно ли данные, полученные из ответа icmppingsec скармливать скрипту в Заббиксе (встроенного/готового нет я так понимаю)?
Или надо внешними скриптами дёргать из базы данные собранные Заббиксом и с ними уже отдельно работать?

Сильно не пинайте, расскажите как можно подробнее пожалуйста, а то я с Заббиксом пару дней только дружу, есть опыт с OpenNMS & HP OV NNM, но Заббикс немного другой

[ugh]

что-то вы усложняете все
по вашей схеме можно нафантазировать например офисы с объединением через isp
в простейшем случае время ответа icmpping и есть "круговой джиттер"
меня терзают смутные сомнения что провайдер врятли сам что-то другое под этим подразумевает, и как-то особенным способом меряет
да, если я в корне ошибаюсь, то вопрос: каким образом вы хотите работать с данными?

можно ли данные, полученные из ответа icmppingsec скармливать скрипту в Заббиксе

Или надо внешними скриптами дёргать из базы данные собранные Заббиксом и с ними уже отдельно работать?

[ZeeD]

Да не, не усложняю, простейшая схема, помоему проще быть не может
Больше офисов не будет, будем рассматривать только эту схему.
Провайдер может считать по своему, но мне надо будет, при нарушении догора с его стороны, предъявить ему это нарушение и обосновать.

Мне надо посчитать джиттер, но по формуле из RFC (я так думаю на данный момент).
Вот и пытаюсь понять как этот обсчет реализовать, средствами Заббиска или сторонними скриптами.
icmpping одтаёт данные по задержке, Заббикс кладёт их в базу.
Как дальше с ними работать?
Скриптами Заббикса или сторонними, т.к. средаствами Заббикса этого не получится?

Я не силён в Заббиксе пока, отсюда и вопросы, т.е. пытаюсь понять в каком направлении начать работать, что бы зря время не терять

[ugh]

а можно полюбопытствовать насчет формулы?)

[ZeeD]

Формула тут http://www.ietf.org/rfc/rfc3550.txt
Только там надо вчитываться в документ

Есть ещё ITU-T o.91 с кучей информации про джиттер.