Mikrotik.moscow [тема: Пинг случайным образом и скрипт для мониторинга задержки...]

Пинг случайным образом и скрипт для мониторинга задержки...

Tue, 13 Aug 2013 21:47:00 -0400

Пинг случайным образом и скрипт для мониторинга задержки... RouterOS в форуме RouterOS.
Пинг-флуд с 1000 пакетами не обязателен, однако одиночные пинги в секунду не создают достаточную пропускную способность для корректного измерения ccq.
13.08.2013 21:47:00, wpeople.

Пинг случайным образом и скрипт для мониторинга задержки...

Tue, 13 Aug 2013 09:53:00 -0400

Пинг случайным образом и скрипт для мониторинга задержки... RouterOS в форуме RouterOS.
Как мы можем мониторить без использования flood ping, а с помощью обычного ping?
13.08.2013 09:53:00, angboontiong.

Пинг случайным образом и скрипт для мониторинга задержки...

Wed, 27 Apr 2011 06:51:00 -0400

Пинг случайным образом и скрипт для мониторинга задержки... RouterOS в форуме RouterOS.
Если вы хотите следить за качеством канала, почему бы не доверять значениям CCQ? (особенно если по каналу идет трафик) Думаю, через API несложно реализовать следующее:
if($link-traffic > 1 Мбит/с) {
получить значения CCQ
если ($ccq < 80%) — вывести предупреждение
} else {
провести нагрузочный ping
получить значения CCQ
если ($ccq < 80%) — вывести предупреждение
}
27.04.2011 06:51:00, wpeople.

Пинг случайным образом и скрипт для мониторинга задержки...

Tue, 26 Apr 2011 12:54:00 -0400

Пинг случайным образом и скрипт для мониторинга задержки... RouterOS в форуме RouterOS.
Ну, ты можешь настроить netwatch на определённое значение задержки, например, 10 мс. После того как 3 пакета не отвечают по тайм-ауту, netwatch запускает скрипт on-down. Это не значит, что ссылка упала, а лишь то, что все отправленные им ICMP-сообщения не уложились в заданные параметры. Если один из проколов удаётся, а статус был "даун", начинается смена статуса и запускается скрипт on-up. Это вообще не связано с фактическим состоянием канала, но если пакеты проходят в заданных пределах — вот именно это тебе и нужно.

Например, есть 3 роутера A<---->B<---->C, и ты хочешь мониторить C с A через netwatch. Можно ввести задержку на B больше 50 мс, а на A поставить тайм-аут netwatch в 10 мс — тогда он будет показывать state=down, хоть ссылка работает отлично, просто ICMP-запросы на B искусственно замедлены.
26.04.2011 12:54:00, janisk.

Пинг случайным образом и скрипт для мониторинга задержки...

Wed, 20 Apr 2011 11:39:00 -0400

Пинг случайным образом и скрипт для мониторинга задержки... RouterOS в форуме RouterOS.
Да, netwatch — идеальный вариант. Возможно, я что-то неправильно понял. Вот как я это вижу: netwatch предназначен для другого — чтобы отслеживать события поднятия и падения канала. Мне не нужно мониторить статус канала — я уже делаю это через dude. Меня интересует другое: хочу отследить, когда среднее значение RTT по каналу за последние 10 минут становится больше, скажем, 10 мс. Меня не волнуют случайные колебания и потеря пакетов. Опять же, я вижу это в dude, и клиент мне простит, если у него на 10 секунд случаются проблемы. Но мне реально нужно видеть, что канал постоянно имеет высокую задержку в течение достаточно долгого времени. Хочу получать уведомление на почту с текстом «Ссылка между A и B, похоже, уже 30 минут работает с высокой задержкой, посмотрите, пожалуйста». Это важно, потому что в это время у клиентов медленный интернет, даже если потери пакетов нет, а они терпеть не могут тормоза. Я могу сделать это с помощью серии команд netwatch с разными таймаутами, отдельными скриптами для каждой команды, считающими, сколько раз каждый скрипт был запущен, и каким-то математическим анализом после. Но зачем мне это, если я могу иметь те же данные напрямую, измеренные с помощью серии flood ping каждые 1–2 минуты? Снова повторю, что мне не нужны абсолютные значения, меня не волнуют случайные поднятия/падения и скачки именно в этот момент. Мне нужен средний показатель за минуты. Учитывая всё вышесказанное — всё ещё лучше делать это через netwatch? Что я упустил?
20.04.2011 11:39:00, yozhiks.

Пинг случайным образом и скрипт для мониторинга задержки...

Tue, 19 Apr 2011 12:39:00 -0400

Пинг случайным образом и скрипт для мониторинга задержки... RouterOS в форуме RouterOS.
netwatch — это идеальный инструмент, просто внимательно прочитайте документацию, не забудьте найти аргумент timeout и установите его в небольшое значение, например 10 мс, а скрипты для поднятия и сброса соединения настройте аккуратно. Например, при отключении — выключить; при включении — установить переменную с какой-то информацией, а скрипт для включения отправит письмо с информацией, сохранённой в переменной. (То есть я рассчитываю, что время простоя будет достаточно коротким.) Если письмо пустое — значит роутер был перезагружен между скриптами отключения и включения.
19.04.2011 12:39:00, janisk.

Пинг случайным образом и скрипт для мониторинга задержки...

Tue, 19 Apr 2011 11:02:00 -0400

Пинг случайным образом и скрипт для мониторинга задержки... RouterOS в форуме RouterOS.
WirelessRudy, спасибо за информацию, надо было поглубже изучить документацию. Это решение может быть хорошим выходом. Хотя оно и не дает реального времени RTT, зато позволяет получить приближенные значения, которые можно использовать для оценки RTT в пределах некоторых порогов. Думаю, на основе этого можно построить то, что мне нужно. Правда, выглядит это сложнее и менее точно, чем метод, который предложил bburley.

psamsig и bburley, огромное спасибо, именно это я и собираюсь попробовать. Похоже, это как раз то, что мне нужно!
19.04.2011 11:02:00, yozhiks.

Пинг случайным образом и скрипт для мониторинга задержки...

Tue, 19 Apr 2011 07:33:00 -0400

Пинг случайным образом и скрипт для мониторинга задержки... RouterOS в форуме RouterOS.
Я поигрался со скриптом от psamsig и добавил проверку потери пакетов:

local avgRtt;
local pin
local pout

/tool flood-ping 1.1.1.1 count=10 do={
if ($sent = 10) do={
set avgRtt $"avg-rtt"
set pout $sent
set pin $received
}
}

local ploss (100 - (($pin * 100) / $pout))
local logmsg ("Средний пинг до 1.1.1.1 - ".[:tostr $avgRtt]."мс - потеря пакетов: ".[:tostr $ploss]."%")
log info $logmsg
19.04.2011 07:33:00, bburley.

Пинг случайным образом и скрипт для мониторинга задержки...

Mon, 18 Apr 2011 19:48:00 -0400

Пинг случайным образом и скрипт для мониторинга задержки... RouterOS в форуме RouterOS.
Netwatch может делать всё, что хочешь. /tool netwatch
add comment="" disabled=no down-script="" host=10.50.51.1 interval=1m timeout=1s up-script=""
add comment="" disabled=no down-script="" host=10.50.51.1 interval=1m timeout=500ms up-script=""
add comment="" disabled=no down-script="" host=10.50.51.1 interval=1m timeout=50ms up-script=""
add comment="" disabled=no down-script="" host=10.50.51.1 interval=1m timeout=5ms up-script=""

Можно выставлять интервал, задавать таймаут и писать любые скрипты на свой вкус. Теперь тебе решать, когда считать ссылку недоступной, плохой, средней или быстрой.
18.04.2011 19:48:00, WirelessRudy.

Пинг случайным образом и скрипт для мониторинга задержки...

Mon, 18 Apr 2011 19:45:00 -0400

Пинг случайным образом и скрипт для мониторинга задержки... RouterOS в форуме RouterOS.
Кто-то недавно обратил моё внимание на вот эту милую штучку:
{
:local avgRtt;
/tool flood-ping 1.1.1.1 count=10 do={
:if ($sent = 10) do={
:set avgRtt $"avg-rtt"
}
}
:put $avgRtt;
}

Можно получить минимальное время (min-rtt), максимальное (max-rtt) или среднее (используется в примере), а также количество потерянных пакетов (принятые минус отправленные). Поиграйте с этим и посмотрите, что лучше всего показывает проблемы с соединением.
18.04.2011 19:45:00, psamsig.

Пинг случайным образом и скрипт для мониторинга задержки...

Mon, 18 Apr 2011 15:52:00 -0400

Пинг случайным образом и скрипт для мониторинга задержки... RouterOS в форуме RouterOS.
По беспроводным каналам действительно проблема — получить уведомление, когда связь начинает ухудшаться. Дело в том, что связь иногда становится плохой задолго до полного обрыва. Она всё ещё работает, пакеты не теряются, но скорость ужасная, пинги на ptp-связи 20-50 мс. Нам нужно получать уведомление (например, по электронной почте), когда это происходит. Инструмент netwatch здесь не поможет, так как пакеты не теряются, они всё ещё передаются, просто слишком медленно, чтобы устроить клиента. Разные статистики беспроводного интерфейса слишком нестабильны, чтобы выставлять какие-то пороговые значения. Мне кажется, что единственное надёжное решение — это когда средний пинг за 2-3 минуты превышает заранее заданное значение для этой связи. Обычно проблема возникает, когда пинг на ptp-связях достигает 10-20 мс. Это делает пинг в dude бесполезным, так как разрешение по времени там около 10 мс. То есть все значения пинга в dude — 0, 10, 20 … мс, и это не годится для усреднения. Вопрос такой: есть ли способ получить реальные значения пинга (или любого другого времени кругового обхода) каким-то образом между двумя маршрутизаторами Mikrotik — через скрипт, dude или иначе (snmp?), чтобы их можно было собрать, усреднить и сравнить с порогом?
18.04.2011 15:52:00, yozhiks.

Пинг случайным образом и скрипт для мониторинга задержки...

Wed, 31 Mar 2010 17:25:00 -0400

Пинг случайным образом и скрипт для мониторинга задержки... RouterOS в форуме RouterOS.
Буду благодарен, если кто-то поделится скриптом для пинга и мониторинга задержки. Вот что я ожидаю от него... RouterBoard будет случайным образом пинговать другой конец в течение дня, скажем, по одному разу каждый час. Он будет проверять порог задержки, и если она превысит, например, 30 мс, то зафиксирует это и отправит результат по электронной почте тому, кто должен получить информацию.
31.03.2010 17:25:00, angboontiong.