Является ли Ping надежным способом проверки доступности сервера?

В моем приложении я проверяю связь с сервером и жду ответа. Я использую это, чтобы определить, доступен ли сервер и отвечает или нет.

Это надежный способ определения доступности? Я предполагаю, что брандмауэр может фильтровать трафик icmp ... Есть ли другие недостатки? Есть ли более надежный метод?

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

В качестве примера, я всегда получаю, чтобы мои балансировщики нагрузки получали реальный ответ «голова» от наших веб-серверов, вы можете сделать то же самое для небольшого выбора в блоке БД, если хотите, или любого другого действующего сервера. В качестве подсказки вы можете создать «online.txt» (или любое другое имя, которое вы хотите дать ему) на своих веб-серверах, чтобы ваши LB пытались получить этот файл, а в случае неудачи он удаляет сервер из VIP, это отличный способ вручную вывести отдельные серверы из ваших VIP-пользователей, просто переименовав один файл.

Ping только проверяет способность реагировать на пинги, так что это базовая ОС, части стека IP и физические ссылки - но это все, все остальное может быть недоступно, и вы не будете знать.

Я знаю, что это упомянуто ниже, но это повторяется снова и снова.

Эхо-запросы ICMP (также называемые «Pings») (иначе ICMP Type 8) встроены в спецификацию стека IP, да, но их не нужно ни внедрять, ни использовать. На самом деле, существует большое количество интернет-провайдеров, которые отказываются переадресовывать их и молча отбрасывают эти запросы, так как они являются формой сетевой атаки (называемой pingflood).

Как упомянуто выше, это обрабатывается ОС (в частности, на уровне сетевого стека) и, таким образом, зависит от конфигурации ОС, реагировать на них или нет. Если это отключено (мера безопасности?), Вы ничего не можете сделать с получением ответов ping с другого конца. Вот почему это не надежно.

В большинстве случаев, да, однако:

• некоторые серверы блокируют запросы ping

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

Это правда, что во многих случаях ICMP-трафик отфильтровывается, поэтому он может быть ненадежным ...

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

т.е. телнет 127.0.0.1 8080

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

Пинг имеет 2 недостатка:

• ping отправляет icmp, который может быть отфильтрован брандмауэром
• порт tcp или udp, используемый вашим приложением, может быть занят или не открыт - ping не проверяет,

Лучшее решение - проверить порт udp / tcp напрямую, чтобы убедиться, что сервис все еще доступен ... :-)

Существуют специальные инструменты для тестирования и мониторинга, такие как Nagios / Icinga .
С помощью этих инструментов вы можете (конечно) выполнять проверки с помощью различных ping-тестов, а также проверять свои сервисы.

Все проверки могут использовать возвращаемое значение для классификации результата как «хороший», «предупреждение» и «критический» и могут быть написаны практически на любом языке программирования.

Конечно, не прост в настройке (например, навести и щелкнуть), но настраиваем, надежен и расширяем. Хорошо работает на различных дистрибутивах Linux и Unix.

Протестируйте сервисы, которые вы ищете, просто пропингуйте сервер не означает, что сервисы работают.

Например:

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

Сценарий сделать следующее ->

<?php
    $website1 = "http://www.mywebsite.com/";
    $myWebsite = file_get_contents($website1);
    $message = 'My website' . $website1 . ' is DOWN at the moment.';
    if (empty($myWebsite)) mail('mail@server.com', 'Website is DOWN', $message);
?>

Использование ping для определения доступности сервера похоже на то, как врач ER проверяет, дышит ли пациент. Да, это хорошее место для начала, но могут быть и другие проблемы.

Мы используем pingдля предварительной проверки, что хост включен и доступен, прежде чем запускать наш сервис systemd, который пытается подключиться к нему через ssh. Это экономит некоторое время на отладку, так как systemctl startкоманда немедленно потерпит неудачу, вместо того, чтобы молча потерпеть неудачу и потеряться в джунглях journalctl.

Обратите внимание, что ping не является «надежным» в том же смысле, что и TCP. Если у вас плохое соединение (или дрянной сетевой стек, спасибо Intel mpss ) и пакеты отбрасываются, может пропустить проверку связи с одним пакетом. С другой стороны, TCP-соединение надежно защищает от пропущенных пакетов. По иронии судьбы, ssh-соединение может работать сразу после одного ping сбоя . Поэтому, если вы используете ping для проверки работоспособности, обязательно допустите некоторый сбой.

Просто мои два цента: у нас есть устаревшее приложение, которое использует этот метод, и нам пришлось обслуживать его, потому что ping не было достаточно для определения доступности сервиса.

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

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

-

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

Если в обычных условиях ваш сервер отвечает на команду ping, полезно проверять его с интервалом в одну минуту, чтобы проверить, отвечает ли он. Это, конечно, только говорит о том, что на этом IP-адресе есть сервер и что существует сетевой путь от источника пинга к месту назначения. Установка порога для времени отклика может также позволить вам контролировать состояние сети. Если вы пингуете сервер в Интернете, вы можете мало что сделать, чтобы починить сеть, но если клиент позвонит с жалобой, вы уже будете в курсе этой проблемы. Пинг google.com также полезен. Если вы и Google не работаете, что-то происходит.

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

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

Вы можете сходить с ума от мониторинга, поэтому просто следите за тем, чтобы сообщить, когда что-то плохое произошло или становится опасным. Т.е. слишком много подкачки,> 90% использования диска, высокая загрузка диска, 100% ЦП в течение длительных периодов и помните, что мониторинг - это просто атака типа «отказ в обслуживании», проводимая очень медленно.

Ping (Packet Internet Groper) сообщает вам, взаимодействует ли ваша система с системой, с которой вы хотите установить соединение по сети. Это даже пингует, не означает, что служба, например, служба RemoteRegistry работает.

Однако, чтобы исправить любую проблему, пинг необходим. Вы можете удаленно исправить любую проблему. Следовательно, пинг имеет свое значение.

Лучший способ, которым я использую в своих скриптах

#rsh servername.com "date"
Mon Sep 19 04:42:20 PDT 2011

вместо rsh могут использоваться альтернативы, такие как remsh. Это гарантирует, что ваша удаленная система полностью загружена, и вы можете запускать на ней команды. Простого пинга недостаточно, так как во время загрузки, когда сетевые службы запускаются, система начинает отвечать на пинг.

Когда я перезагружаю сервер Windows, я открываю окно командной строки и ввожу

ping <box> -t

Сначала он будет предполагать, что это доступно - это коробка, идущая вниз. Тогда вы получите много «времени ожидания запроса». Когда вы начнете получать ответы, ящик вверх.