Мониторим хостеров Рунета

Бывает чертовски обидно, когда любовно сконструированный и опубликованный на сервере хостера сайт оказывается недоступным для посетителей. Вот ведь незадача: хостинг-провайдер обещал максимум функциональности, взял за свои услуги хоть и небольшие, но деньги, а как наберешь в адресной строке браузера URL своего сайта, так вечная ошибка: «Сервер не найден». Обращаешься в службу поддержки хостера, а в ответ — либо тишина, либо заверения, что «трудности временные», что «в последний раз», что «у всех так». И эта история повторяется чуть ли не изо дня в день. Что в такой ситуации делать сайтостроителю? Ответ очевиден: срочно менять хостера. Кстати, большинство провайдеров обещает осуществлять так называемый moneyback, возврат денег, если качество предоставления услуг вас не устроило.

Но можно таких неприятностей избежать в принципе, еще на этапе выбора хостинг-провайдера для своего будущего сайта. Для этого в Сети существуют специальные сервисы мониторинга работоспособности серверов. В процессе написания статьи было опробовано несколько таких служб, в том числе Host’s Monitor, Internet Seer и UpTime. Наиболее благоприятные впечатления сложились о сервисе UpTime: русскоязычный, бесплатный, предлагающий массу полезной информации в наиболее удобном для пользователя виде. Поэтому опишем системы мониторинга именно на примере UpTime, а другие подобные службы предложим читателям протестировать самостоятельно.

итак, предварительно выбрав хостера для своего будущего сайта, сразу обратитесь к рейтингу провайдеров, поддерживаемому UpTime. Предположим, вы ознакомились с условиями провайдера .masterhost, и они показались вам вполне приемлемыми. Найдем этого провайдера в UpTime-рейтинге:

Здесь мы видим, что в среднем для всех серверов этого провайдера время ответа составляет 216 мс, а общее количество серверов — 14. Самым же главным показателем является коэффициент UpTime, который для данного провайдера равен 99,983%. О чем эта цифра говорит? О том, что с того момента, как серверы провайдера попали в список мониторинга, они оказывались доступными для посетителя практически постоянно, в течение почти 100% времени. Почему стопроцентный UpTime — редкость? Просто потому, что в работе любого сервера бывают сбои и вынужденные простои на время профилактических работ. Весь вопрос только в том, насколько часто бывают эти сбои, и ставит ли заблаговременно хостер своих клиентов в известность о предстоящей профилактике.

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

Здесь прописана информация о каждом сервере данного провайдера, известном системе мониторинга. Внимательный читатель сразу натолкнется на некие странности в этой статистике: имена некоторых серверов дублируются, при этом для одного и того же имени могут показываться различные данные о времени ответа и коэффициенте UpTime. Почему это происходит? Чтобы в этом разобраться, давайте ознакомимся с принципом работы системы мониторинга.

Любой интернет-пользователь после несложной регистрации может добавить в систему сайт для дальнейшего мониторинга. Система, обрабатывая данный запрос, вычислит, на каком узле (хосте) физически размещен данный сайт, узнает IP-адрес сервера. Так в базе данных UpTime скапливается информация о серверах, на которых хостятся веб-ресурсы. Каждые десять минут система генерирует небольшой (600 байт) запрос, который рассылает в адрес всех серверов, имеющихся в базе данных. Каждый сервер реагирует по-своему. Если сервер на запрос ответил, время его реакции на запрос вносится в базу как параметр «Время ответа». В случае же, если сервер в ответ на запрос «промолчал» в течение 70 секунд, регистрируется ошибка timeout, что говорит о недоступности. С этого момента запросы в адрес недоступного сервера продолжают отсылаться непрерывно, пока он не ответит. Если же сервер отказывается установить соединение, возвращает ошибку Connection Refused, это говорит о том, что сам сервер работает, но по протоколу HTTP общаться не желает. В этом случае повторные запросы генерируются и отправляются каждые 20 секунд, пока нормальная работоспособность сервера не восстановится. Кроме указанных ошибок, система обрабатывает еще несколько, а исходя из полученных на свои запросы ответов, система и рассчитывает UpTime-коэффициент.

Естественно, для выполнения мониторинга системе необходимо постоянно обращаться к DNS. Каждый сервер .masterhost «прописан» по двум IP-адресам. Так и получается, что UpTime, оперируя, в конечном счете, именно IP-адресами, собирает статистику по каждому серверу дважды. Кстати, по каждому хосту можно просмотреть отдельную подробную статистику с практически исчерпывающей информацией:

Неоценимым дополнительным удобством для сайтостроителя является возможность оформить подписку на текущее состояние интересующего его сервера. Обнаружив, что тот или иной сервер не отвечает на запросы, система автоматически вышлет предупреждающее сообщение о неисправности. Сайтовладельцу остается лишь дозвониться в службу поддержки и поинтересоваться, в чем проблема, как долго она будет устраняться, а если останов сервера запланирован, почему его никто не предупредил о готовящейся профилактике?

Одним словом, система проста, удобна и весьма полезна. Но вот вопрос: насколько она объективна? Главная проблема любого мониторинга — насколько проводящая его служба работоспособна сама по себе? Что происходит, когда случаются неизбежные падения серверов, на которых расположен сам сервис UpTime? А ничего неприятного не происходит по той простой причине, что UpTime — система распределенная, работающая по довольно сложной схеме. В различных точках Сети установлены так называемые чекеры (от английского check, проверять), которые производят рассылку запросов самостоятельно, а данные «складируют» в одной интегрированной базе данных.

Но ведь и интегрированная база данных размещена на каком-то серве
ре. Что произойдет, если он «упадет»? Это в первую очередь обнаружат все те же чекеры, которые и отметят у себя время простоя сервера базы данных системы. На этот промежуток времени всем мониторящимся хостам присваивается UpTime=100%, а сама система получает статус DownTime. Как только неработоспособность системы будет устранена, все вернется на круги своя, и мониторинг будет продолжен в обычном режиме.

О том, что создатели системы стремятся сохранять объективность, косвенно говорит следующий факт. Ядро UpTime физически расположено на серверах хостинг-провайдера NODEX. От необъективной системы следовало бы ждать, что именно этот провайдер будет постоянно находиться на первой строчке рейтинга хостеров. Как можно убедиться в любой момент, это не так.

Особенно приятно то, что команда создателей UpTime не собирается останавливаться на достигнутом, продолжает совершенствовать алгоритмы сбора и обработки статистики, расширяет базу данных, постоянно пополняет страницы своего сайта дополнительной оперативной и аналитической информацией. Вот, например, что сообщил руководитель проекта Кирилл Краснов: «… наша система не осуществляет сканирования Сети на предмет поиска сайтов и привязки их к конкретным хостам. Вся информация собирается только от клиентов, использующих наш сервис. Может быть, в будущем такая программа сканирования будет написана и добавлена в систему. Это было бы интересно — разложить весь Рунет по хостам и хостинг-провайдерам, но пока это не является первоочередной задачей нашей команды».

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