fping

Спасибо!

А стандартным ping не получится?

Честно говоря, не в курсе.

mtr

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

при пинге «в реальном времени»

И с mtr удобно смотреть именно глазами.

сам просил «в реальном времени»

Я имел в виду что-то вроде

пакет 1 - ОК пакет 2 - ОК пакет 3 - не ОК пакет 4 - ОК

ping $HOST 2>/dev/null | awk '/icmp_req/ {split($6,a,"="); c=a[2]-p; if(c>1) {printf "\nLost %d packets\n", c} else {printf "."}; p=a[2]; fflush()}'

на хорошие пакеты печатает точку, на потерянные Lost N packets

Интересует способ мониторинга потерянных пакетов при пинге «в реальном времени», а не в статистике. а городить костыли в виде пинга по одному пакету циклично мне не очень хочется.

У тебя противоречивые требования. Хочешь в реальном времени, в виде «пакет 1 - ОК пакет 2 - ОК пакет 3 - не ОК пакет 4 - ОК», но не «по одному пакету циклично»

Сам понимаешь что сказал? В общем иди-ка ты пиши себе все сам, чудак.

=) Спасибо тебе за помощь. Но мне нужно что-то вроде

while :; do result=`ping -c 1 127.0.0.1 | grep loss | awk '{print ($
7)}'`;date +%H:%M:%S | tr -s "\n" "-"; echo "$result"|sed '{s/0\%/OK/}'|sed '{s/
100%/FAIL/}'; sleep 1; done  

Но это те самые костыли, которые я не хочу использовать, но получается нужный мне вывод:

06:40:33-OK                                                                     
06:40:34-OK                                                                     
06:40:35-OK

Не самый подходящий вариант

./ping_perl 8.8.8.8
icmp ping requires root privilege at ./ping_perl line 5

А то что обычный ping root-SUID'ный тебя устраивает?

А если выполнять на машине без рутовых прав.

а если ... , а если ...,

надоело за ручку школоту водить.

Спасибо за внимание!

Толстовато. И, да, не стыдно не знать. Я не только про себя.

man ping:

       -f     Flood  ping.  For  every  ECHO_REQUEST  sent  a  period  ``."  is  printed, while for ever
              ECHO_REPLY received a backspace is printed.  This provides a  rapid  display  of  how  many
              packets  are being dropped.  If interval is not given, it sets interval to zero and outputs
              packets as fast as they come back or one hundred times per second, whichever is more.  Only
              the super-user may use this option with zero interval.

       -i interval
              Wait  interval  seconds between sending each packet.  The default is to wait for one second
              between each packet normally, or not to wait in flood mode. Only super-user may set  inter‐
              val to values less 0.2 seconds.

Как ТС написал PING - показ потерянных пакетов (комментарий) ему нужен вывод с тайм-штампами. Стандарнтый ping такой функционал не обеспечивает, а root'овых прав у ТС нет.

ему нужен вывод с тайм-штампами

вот это на самом деле самый интересный момент во всей этой сантабарбаре.
99 из 100, что оно ему на самом деле не нужно, и товарищ просто не с того бока к задаче подошёл

06:13 Ok
06:14 Fail Пакет ID xxxx - перелом контрольной суммы
06:21 Fail Пакеты ID yyyy..zzzz - не вернулись из боя

:)

Нужно. Например, для статистики.

Вы работаете на большом андронном коллайдере, что статистика на уровне отдельного ICMP пакета кому-то интересна?
Давайте высокоуровневое описание задачи

Давайте низкоуровневое: падает, например, Интернет. Я замечаю, что сеть отваливалась, но время проверить не могу (дома меня нет). А это требуется моему провайдеру. Не обязательно слать пакеты каждую секунду. С другой стороны, если мой скрипт видит, что пакеты теряются, он может трассировать маршрут. Или мне смс кинуть, чтоб я звонил в саппорт прова и уже по факту заявлял о проблеме.

опять какой то сумбур. тебе нужно видеть в котором часу не пинговался хост?

дык ping -D

Нет такого ключа. Есть

 -d     Set the SO_DEBUG option on the socket being used.  Essentially, this socket option is not used by Linux kernel.

тебе нужно видеть в котором часу не пинговался хост?

Мне нужно видеть потерянные пакеты. Действие на это событие можно любое повесить. Провайдер просто для примера.

Система мониторинга? Nagios.

То есть fping не подходит - нужно что-то дефолтное, скрипт на перле - потому что рута нужно, а вот развернуть систему мониторинга-это ОК.

Во, это почти то, что надо. Осталось к этому прикрутить звонок в техподдержку провайдера и другие организации. :-)

Нет такого ключа. Есть

это что за линупс такой? андроид чтоле?

   -D     Print timestamp (unix time + microseconds as in gettimeofday) before each line.
   AVAILABILITY
       ping is part of iputils package and the latest versions are  available in source form at http://www.skbuff.net/iputils/iputils-current.tar.bz2.

    iputils-100418 

Ну да, похоже что линуксовый пинг не умеет выводить сообщения как на виндовом пинге например. Придется изобретать велосипед. Я бы сделал не пинг, а через socket.connect (дабы не требовать рутовых прав)

>>> from socket import socket
>>> s = socket()
>>> s.settimeout(3)
>>> s.connect(("ya.ru", 80))
>>> # тоесть какбы сокет подключился и все ок

>>> s = socket()
>>> s.settimeout(3)
>>> s.connect(("ya.ru", 81))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
socket.timeout: timed out

а вот такое бывает в случае таймаута

Потеря одого пакета вобще ничего не означает, это норма в больших сетях.

Если по потери нескольких пакетов подряд нужно делать какое-то действие («смс кинуть»), то и дописывайте свой скрипт, который постоянно вызывает ping. Запустили ping, посмотрели exit-code, выполнили действия. Это проще и понятнее, чем непрерывно парсить вывод команды и по строкам «timeout» делать действия.

1. Пингуем, при этом на вывод идет только инфа о потерях. 2. Считаем каким-нибудь wc потеряные пакеты. 3. Набираем определенное количество потерянных пакетов - алярм.

Странная у вас версия. Вроде, должно быть 20100418. А старые версии ping (до 20100214) не знают этой опции. В RHEL и ubuntu 10.04LTS именно они.

Я проверял сейчас на

$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.5 (Tikanga)

Дома Debian Squeeze стоит, может там пойдет.

-D вам даст вывод тайм-штампа, но не сообщения о потери пакета.

Вот такой вариант запуска ping -f будет выводить FAIL на каждый потеряный пакет, что подойдёт для счётчика, но без тайм-штампа:

ping X.X.X.X -f -i 1 | while read -n1 A ; do [ . = "$A" -a . = "$PA" ] && echo FAIL ; PA="$A";  done

Хотя если просто суммировать потерянные пакеты без ограничения интервала времени, то рано или поздно любое число насуммируется.

падает, например, Интернет. Я замечаю, что сеть отваливалась

такие тесты есть в любой системе мониторинга

как вариант: заводите dummy интерфейс, ставите его вторым маршрутом в Интернет с большой метрикой. Как только в него попёр трафик - значит основный канал имеет большие проблемы.

кстати данные можно снимать и с основного канала: как только входящий поток минимален и в логах прут ошибки DNS - канал лежит.

snmpd и средства мониторинга (nagios к примеру).

Мне не нужен мониторинг. Я об этом уже говорил.

Он тебе не нужен, но делаешь ты именно его.

скрипт на перле - потому что рута нужно

Тебе осталось доустановить perl-suid и радоваться на серверах без рутового доступа.

А учитывая, что на перле можно легко дописать любую логику, это самое оно будет для расширения функциональности.

Я хочу пинговать 1 узел, зачем мне мониторинг? Может мне еще БД разворачивать чтоб 1 номер телефона записать?

То есть для установки мне рутовый доступ не нужен? Расширение мне тоже не требуется. Спасибо!

А тебе и на серваках без рута делать нечего, игры в песочнице :-)

Независимо от того, как ты к этому относишься, тот велосипед, который ты изобретаешь, называется именно система мониторинга.

Я хочу пинговать 1 узел, зачем мне мониторинг?

так что-же вы хотите на самом деле ? знать работает-ли конкретный ваш канал, работает ли этот самый отдельный узел, или собрать статистику по направлению сервер-узел ??

ЗЫ. наличие/пропадение/отсутствие пинга одного узла ничего не говорит о работоспособности канала провайдера. (искл.-единственный шлюз).

ЗЫЫ. Готовых, подчас неплохих, скриптов проверки работы шлюза в разделе Admin - по паре штук в месяц (как правило связанны с переключением шлюзов/маршрутов). Ищите и обрящите :)

Интересует способ мониторинга потерянных пакетов при пинге «в реальном времени», а не в статистике.

Всем спасибо. Тему закрываю.