Мои рабочие серверы хранятся на восточном побережье США, а некоторые из поддерживающих приложений хранятся в Амстердаме в Европе. На восточном побережье США также работает экземпляр Nagios, который выполняет несколько проверок портов и несколько проверок через ssh.
Проблема в том, что почти каждый день я наблюдаю отбрасывание пакетов с использованием mtr (комбинация traceroute и ping), а также незначительные проблемы с обслуживанием, которые длится около 1 минуты. Я показал эти выходные данные mtr нашему провайдеру услуг в Амстердаме, но он отрицал какие-либо проблемы, говоря, что ICMP (используемый mtr) не является надежным способом измерения потерь, поскольку ICMP имеет самый низкий приоритет на маршрутизаторах. Таким образом, маршрутизаторы могут отказаться от ICMP, но для TCP их вполне подойдет.
Как мне доказать поставщику услуг, что проблема с его услугой действительно существует, и он должен ее исправить? Какие инструменты и методы подходят для этого?
Возможно, вы могли бы попробовать установить Smokeping и выполнить некоторые проверки служб (tcp, http, http, ...). Он может делать красивые графики потери пакетов.
Трудно окончательно доказать потерю пакетов.
Если это ваша цель, я рекомендую следующую стратегию:
iptables
правило на каждом хосте для подсчета количества входящих / исходящих пакетов iperf
выполнить тест TCP в течение определенного периода, например 300 секундiptables
на обоих хостах и сравните количество пакетовАльтернатива использованию iptables
- посмотреть количество пакетов tx / rx вашего интерфейса на обоих хостах (например, ifconfig eth0
) - сделайте пометку в начале вашего теста, проведите тест передачи (например, используя SCP или FTP) - а затем вычислите, равны ли пакеты, отправленные с одного хоста, пакетам, полученным на другом хосте.
Любая другая техника даст вам ложную информацию. Это правда, что хосты и промежуточные маршрутизаторы будут лечить ICMP
с низким приоритетом или может вообще не отвечать на него. Часто UDP
пакеты также рассматриваются как имеющие более низкий приоритет, поэтому iperf
Тест с использованием потока UDP может дать ложные результаты. И TCP
Тест без фактического подсчета отправленных и полученных пакетов никогда не покажет много, поскольку основная операционная система обрабатывает потерю пакетов.
На моем рабочем месте мы используем стороннюю службу мониторинга сети под названием Червячный.
Мы используем его в основном для того, чтобы убедиться, что веб-сайты работают, но мы также можем проверять определенные порты и т. Д.
Вы можете получить базовую учетную запись и настроить некоторые датчики для проверки TCP-соединений, если ICMP является проблемой.
Он будет создавать для вас графики, которые вы можете показать своему провайдеру.
Тесты проводятся на нескольких башнях по всему миру, и вы можете попросить службу поддержки сделать одну конкретную башню основной. (мы используем сидней, чтобы графики отображали более реалистичный пинг для нашего региона)
Вы даже можете указать определенный текст или шаблон регулярного выражения, который должен присутствовать в ответе TCP, что довольно круто.