Назад | Перейти на главную страницу

Каков «правильный способ» мониторинга сети?

Мои рабочие серверы хранятся на восточном побережье США, а некоторые из поддерживающих приложений хранятся в Амстердаме в Европе. На восточном побережье США также работает экземпляр Nagios, который выполняет несколько проверок портов и несколько проверок через ssh.

Проблема в том, что почти каждый день я наблюдаю отбрасывание пакетов с использованием mtr (комбинация traceroute и ping), а также незначительные проблемы с обслуживанием, которые длится около 1 минуты. Я показал эти выходные данные mtr нашему провайдеру услуг в Амстердаме, но он отрицал какие-либо проблемы, говоря, что ICMP (используемый mtr) не является надежным способом измерения потерь, поскольку ICMP имеет самый низкий приоритет на маршрутизаторах. Таким образом, маршрутизаторы могут отказаться от ICMP, но для TCP их вполне подойдет.

Как мне доказать поставщику услуг, что проблема с его услугой действительно существует, и он должен ее исправить? Какие инструменты и методы подходят для этого?

Возможно, вы могли бы попробовать установить Smokeping и выполнить некоторые проверки служб (tcp, http, http, ...). Он может делать красивые графики потери пакетов.

Трудно окончательно доказать потерю пакетов.

Если это ваша цель, я рекомендую следующую стратегию:

  • настроить хост A и хост B для тестирования сети между
  • воплощать в жизнь iptables правило на каждом хосте для подсчета количества входящих / исходящих пакетов
    • это означает НЕТ правила отслеживания с отслеживанием состояния
  • использовать iperf выполнить тест TCP в течение определенного периода, например 300 секунд
  • сбросить iptables на обоих хостах и ​​сравните количество пакетов

Альтернатива использованию iptables - посмотреть количество пакетов tx / rx вашего интерфейса на обоих хостах (например, ifconfig eth0) - сделайте пометку в начале вашего теста, проведите тест передачи (например, используя SCP или FTP) - а затем вычислите, равны ли пакеты, отправленные с одного хоста, пакетам, полученным на другом хосте.

Любая другая техника даст вам ложную информацию. Это правда, что хосты и промежуточные маршрутизаторы будут лечить ICMP с низким приоритетом или может вообще не отвечать на него. Часто UDP пакеты также рассматриваются как имеющие более низкий приоритет, поэтому iperf Тест с использованием потока UDP может дать ложные результаты. И TCP Тест без фактического подсчета отправленных и полученных пакетов никогда не покажет много, поскольку основная операционная система обрабатывает потерю пакетов.

Рекомендация продукта:

Примечание. Это коммерческая услуга, которая стоит денег в долларах.

На моем рабочем месте мы используем стороннюю службу мониторинга сети под названием Червячный.

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

Вы можете получить базовую учетную запись и настроить некоторые датчики для проверки TCP-соединений, если ICMP является проблемой.
Он будет создавать для вас графики, которые вы можете показать своему провайдеру.

Тесты проводятся на нескольких башнях по всему миру, и вы можете попросить службу поддержки сделать одну конкретную башню основной. (мы используем сидней, чтобы графики отображали более реалистичный пинг для нашего региона)

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