В своем приложении я проверяю связь с сервером и жду ответа. Я использую это, чтобы определить, доступен ли сервер и реагирует ли он или нет.
Это надежный способ определения доступности? Я предполагаю, что межсетевой экран может фильтровать трафик icmp ... Есть ли другие недостатки? Есть ли более надежный способ?
Лучший способ узнать, активна ли какая-либо удаленная служба, - это попросить ее обработать запрос так, как он предназначен - фактически, это единственный способ действительно узнать, что что-то работает правильно.
В качестве примера я всегда получаю свои балансировщики нагрузки для получения фактического ответа «головы» от наших веб-серверов. Вы можете сделать то же самое для небольшого выбора в блоке БД, если хотите, или независимо от того, что обслуживает ваш фактический сервер. В качестве совета вы можете создать 'online.txt' (или любое другое имя, которое вы хотите дать ему) на своих веб-серверах, пусть ваши LB попытаются получить этот файл, и если он не удастся, он удалит сервер из VIP, это хороший способ вручную удалить отдельные серверы из ваших VIP, просто переименовав один файл.
Ping только проверяет способность отвечать на запросы ping, так что это базовая ОС, части IP-стека и физические ссылки - но это все, все остальное может быть отключено, и вы не узнаете.
Я знаю, что об этом упоминается ниже, но это стоит повторять снова и снова.
Эхо-запросы ICMP (также известные как «пинги») (также известные как ICMP типа 8) встроены в спецификацию IP-стека, да, но их не требуется ни реализовывать, ни использовать. Фактически, существует большое количество интернет-провайдеров, которые отказываются пересылать их и молча отбрасывают эти запросы, поскольку они являются формой сетевой атаки (называемой pingflood).
Как упоминалось выше, это обрабатывается ОС (в частности, на уровне сетевого стека), и поэтому конфигурация ОС должна отвечать на них или нет. Если он отключен (из соображений безопасности?), Вы ничего не сможете сделать с получением ответов ping с другого конца. Вот почему это ненадежно.
Однако в большинстве случаев да:
некоторые серверы блокируют запросы ping
просто потому, что сервер отвечает не означает автоматически веб-сайт (или любой другой сервис, который вы собираетесь использовать) работает, вы также должны проверить, соответствует ли ответ ожидаемому содержанию.
Это правда, что во многих случаях трафик ICMP отфильтровывается, поэтому он может быть ненадежным ...
Возможно, лучший способ - установить telnet-сервер на интересующий вас сервисный порт.
то есть telnet 127.0.0.1 8080
Если от сервера требуется только отвечать на эхо-запросы, это хороший метод определения его доступности. Если требуется, например, для предоставления веб-службы, вам следует выполнить какую-либо форму тестирования, чтобы увидеть, работает ли она аналогично для файловых служб и т. Д.
У ping есть 2 недостатка:
Лучшее решение - проверить ваш порт 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 для определения доступности сервера похоже на то, как врач скорой помощи проверяет, дышит ли пациент. Да, это хорошее место для начала, но могут быть и другие проблемы.
Мы используем ping чтобы сделать предварительную проверку, что хост включен и доступен, прежде чем запускать нашу службу systemd, которая пытается установить с ним ssh-соединение. Это экономит время на отладку, так как systemctl start команда сразу же выйдет из строя, вместо того, чтобы молча потерпеть неудачу и заблудиться в джунглях journalctl.
Обратите внимание, что ping не является «надежным» в том же смысле, что и TCP. Если у вас плохое соединение (или плохой сетевой стек, спасибо Intel mpss) и пакеты отбрасываются, проверка связи одного пакета может завершиться ошибкой. С другой стороны, TCP-соединение надежно против отброшенных пакетов. По иронии судьбы, ssh-соединение может работай сразу после сингла ping неудача. Поэтому, если вы используете ping для проверки работоспособности, обязательно допустите ошибку.
Всего два цента: у нас есть устаревшее приложение, использующее этот метод, и его пришлось обслуживать, потому что пинг был не достаточно для определения доступности услуги.
Ping просто показывает, что сервер может прослушивать, но в нашем случае служба не смогла запуститься без вмешательства человека.
В результате устройства, которые наивно предполагали, что сервер доступен, пытались подключиться, и время ожидания истекло. Вместо отображения нашего сообщения «Сервер недоступен».
-
Наше текущее приложение, которое обменивается данными с веб-сервером через XMLHTTPRequests, отправляет сформированное сообщение, на которое сервер ответит кодом состояния. Код состояния вычисляется сервером, выполняющим ряд проверок, чтобы убедиться, что различные подсистемы находятся в сети (база данных, необходимые каталоги доступны для записи и т. Д.)
Если при нормальных обстоятельствах ваш сервер отвечает на эхо-запрос, полезно пинговать его с интервалом в одну минуту, чтобы проверить, отвечает ли он. Это, конечно, говорит вам только о том, что на этом IP-адресе есть сервер и что существует сетевой путь от источника эхо-запроса до места назначения. Установка порогового значения времени отклика может также позволить вам контролировать состояние сети. Если вы проверяете связь с сервером в Интернете, вы мало что можете сделать для исправления сети, но если клиент позвонит с жалобой, вы уже будете знать о проблеме. Также полезно пинговать google.com. Если вы и Google не работаете, что-то происходит.
Как уже упоминали другие, важно следить за тем, чтобы предоставляемая вами услуга реагировала и ее производительность была в порядке. Т.е. вы можете проверить, почему веб-сайт, который обычно отвечает за секунду, теперь отвечает, я 10 секунд.
Таким образом, знание того, что служба не отвечает и не работает ping, дает вам гораздо больше информации, чем просто один подход. Кроме того, если вы также отслеживаете процессы, зная, что ping отвечает, служба не отвечает, и веб-сервер не имеет правильного количества процессов, указывающих вам, где искать в первую очередь.
Вы можете сходить с ума от мониторинга, поэтому просто отслеживайте достаточно, чтобы сказать вам, когда что-то случилось или становится опасным. Т.е. слишком много подкачки,> 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
Сначала он предложит, что он доступен - это коробка опускается. Тогда вы получите много «таймаутов запросов». Когда вы начнете получать ответы, окно поднимется.