Что такое "правильный путь" для мониторинга сети?

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

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

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

Источник

3 ответа

Решение

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

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

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

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

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

Источник

Может быть, вы могли бы попытаться установить smoping и сделать некоторые проверки сервиса (tcp, http, http, ...). Это может сделать хорошие графики потери пакетов.

Источник

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

Примечание: это коммерческая услуга и стоит денег $.

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

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

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

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

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

Источник
Другие вопросы по тегам