Рейтинг доступности сайтов

В середине декабря закончилась подготовка к запуску еженедельному рейтингу доступности популярных сайтов Рунета. Мы постарались охватить все сайты, с одной стороны, наиболее посещаемые и, с другой стороны, разной тематики. На данный момент охвачено порядка 20% всех посещений Рунета. И при еженедельных подтвержденных потерях в 2-3 млн. посетителей мы можем с уверенностью говоорить о ежедневных потерях в 1,5-2 млн. посетителей для всего Рунета.

Рейтинг доступности веб-сайтов был построен при помощи WEBO Pulsar, универсального инструмента для отслеживания технического состояния сайта. Согласно ему только за прошедшую неделю odnoklassniki.ru потеряли почти полмиллиона посетителей из-за трехчасовой недоступности. А lib.ru - почти двести тысяч.

Техническое состояние веб-сайтов анализируется раз в минуту сетью независимых точек проверки. Только на основании данных всей сети делается вывод о недоступности конкретного веб-сайта. Посещаемость большинства веб-сайтов Рунета может быть получена либо из рейтинга Liveinternet, либо с помощью данных Alexa.

Проверки FTP, DNS, Ping и другие новые возможности

За прошедшие несколько недель в WEBO Pulsar появилось еще больше возможностей для проверки ваших сервисов.

Новые типы проверок

Теперь вы можете проверять ваш файл-сервер по протоколам FTP или FTPS, проверять DNS-сервер, контролируя его записи A, MX, CNAME, SOA а также проверять время отклика сервера с помощью команды Ping. Для всех новых типов проверок традиционно строятся удобные графики времени отклика, помимо этого, возможно создание детальных логов в случае недоступности проверок.

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

Если вы хотите проверять DNS, нужно выбрать соответствующий тип проверки (A, MX, CNAME, SOA) и указать контролируемый DNS-сервер, а для проверок записей A и CNAME еще и ожидаемый ответ, соответственно IP-адрес или каноническое имя сервера. Если по какой-то причине DNS-сервер будет отвечать на запросы неверно, вы сразу же об этом узнаете.

Ping — один из самых простых типов проверок, который, однако, позволяет контролировать процент потерянных пакетов. Если заданный порог будет превышен, проверка будет считаться недоступной.

Доступ к статистике ваших проверок и редактирование сайта

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

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

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

Другие запланированные нововведения

Мы в WEBO Software неустанно трудимся для вас, и к Новому Году планируем еще несколько полезных возможностей. Совсем скоро в WEBO Pulsar вы сможете:

• создавать проверки по почтовым протоколам SMTP, POP3, IMAP,
• получать по электронной почте подробные еженедельные или ежемесячные отчеты о результатах всех ваших проверок,
• доставлять уведомления о недоступности проверок любым людям из вашей адресной книги.

Следите за новостями. И конечно, мы всегда рады любым вашим отзывам о нашем сервисе.

Диагностика проблем с доступностью

WEBO Pulsar может не только сообщать о проблемах с веб-ресурсом, но и давать дополнительную информацию, которая поможет диагностировать и быстрее устранить эти проблемы.

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

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

Уровни, на которых могут возникать проблемы

На 5, 6 и 7 уровнях модели OSI диагностические возможности удаленного сервера довольно ограничены. Тем не менее, если соединение с проверяемым ресурсом по соответствующему протоколу было установлено, но по каким-то причинам ответ веб-ресурса отличается от ожидаемого, то можно с уверенностью сказать, что проблема находится на самом проверяемом сервере, и что она возникает на верхних уровнях модели OSI. Дополнительная информация, которую может получить удаленный сервер, будет зависеть от конкретного используемого протокола. Например, для протокола HTTP это будут переданные HTTP заголовки.

Для диагностики ошибок на 1-4 уровнях (а также диагностики ошибок DNS, хотя это и 7й уровень модели OSI) в первую очередь удаленный сервер должен определить, не возникли ли проблемы у него самого. Например, может быть недоступен его DNS-сервер или отключен коммутатор в дата-центре.

Самодиагностика WEBO Pulsar

Для самодиагностики сервис WEBO Pulsar использует набор контрольных точек, среди которых и сервера WEBO Software и просто общедоступные ресурсы с высоким процентом доступности. Недоступность одной из контрольных точек и доступность всех остальных еще не является поводом для поиска проблем на самом сервере WEBO Pulsar. Но недоступность нескольких контрольных точек уже является серьезным поводом для беспокойства. Разумеется, контрольные точки должны быть размещены в различных сетях, а еще лучше в разных странах. Кроме того контрольные точки желательно задавать с использованием доменного имени, а не IP-адреса. Это позволит одновременно убедиться и в том, что DNS-сервер доступен и работает корректно.

Если контрольные точки доступны, то искать проблему нужно в другом месте.

Диагностика проблем с определением IP-адреса сервера

1. На всякий случай проверим еще раз, доступен ли DNS-сервер с помощью telnet, nmap, ping или любой другой подходящей утилиты.
   
   
   webo@pulsar# nmap -p 53 192.168.1.1
   
   
   Starting Nmap 5.00 ( http://nmap.org ) at 2010-09-29 15:27 MSD
   Interesting ports on 192.168.1.1:
   PORT   STATE SERVICE
   53/tcp open  domain
   
   
   Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds
   
   
2. Попробуем получить NS запись для проверяемого домена.
   
   
   webo@pulsar# nslookup -q=NS webo.in
   Server:                   192.168.1.1
   Address:               192.168.1.1#53
   
   
   Non-authoritative answer:
   webo.in  nameserver = dns1.webdrive.ru.
   webo.in  nameserver = dns2.webdrive.ru.
   
   
   Authoritative answers can be found from:
   dns2.webdrive.ru internet address = 212.158.162.5
   dns1.webdrive.ru internet address = 213.189.213.54
   
   Здесь мы видим две NS-записи для проверяемого домена: dns1.webdrive.ru и dns2.webdrive.ru. Дальше будем диагностировать уже их. Но возможен и другой вариант.
   
   
   webo@pulsar# nslookup -q=NS www.webogroup.com
   
   
   Server:                   192.168.1.1
   Address:               192.168.1.1#53
   
   
   Non-authoritative answer:
   www.webogroup.com        canonical name = cs78.ngenix.net.
   
   
   Authoritative answers can be found from:
   ngenix.net
                   origin = ns.ngenix.net
                   mail addr = noc.ngenix.net
                   serial = 1285244204
                   refresh = 28800
                   retry = 7200
                   expire = 604800
                   minimum = 86400
   
   В этом случае доменное имя является синонимом другого имени. В качестве доменного имени теперь следует использовать cs78.ngenix.net, а в качестве nameserver — сервер ns.ngenix.net.
   
   Если же ни одной NS или CNAME-записи получить не удалось, то проблема локализована. Скорее всего, домен не делегирован. В первую очередь нужно проверить сроки делегации домена и NS-записи для него.
   
   
3. Если же проблема по-прежнему не локализована, попробуем определить IP-адреса обнаруженных NS-серверов.
   
   
   webo@pulsar# nslookup ns.ngenix.net
   
   
   Server:                   192.168.1.1
   Address:               192.168.1.1#53
   
   
   Non-authoritative answer:
   Name:     ns.ngenix.net
   Address: 93.93.93.93
   
   Если на этом шаге не удается определить IP-адреса ни одного из NS-серверов, то проблема локализована.
   
   
4. Последнее, что можно сделать — проверить доступность самих NS-серверов, убедиться, что на них доступен 53 порт и работает служба DNS. Разумеется, проверять это имеет смысл только для тех NS-серверов, для которых удалось определить IP-адрес.
   
   
   webo@pulsar# traceroute -T -n -p 53 93.93.93.93
   traceroute to 93.93.93.93 (93.93.93.93), 30 hops max, 56 byte packets
    1  192.168.1.1  1.265 ms  2.230 ms  2.693 ms
    2  212.5.114.1  12.918 ms  13.080 ms  13.100 ms
    3  87.118.210.201  13.068 ms  14.752 ms  14.751 ms
    4  87.118.192.170  14.782 ms  14.806 ms  14.833 ms
    5  195.128.64.74  15.538 ms  15.570 ms  15.596 ms
    6  217.150.38.58  15.626 ms  15.596 ms  14.668 ms
    7  217.150.45.142  153.807 ms  143.696 ms  143.542 ms
    8  193.232.226.22  15.875 ms  15.867 ms  14.312 ms
    9  78.41.104.133  9.346 ms  9.324 ms  9.136 ms
   10  93.93.93.93  9.743 ms  9.424 ms  9.389 ms
   
   
   webo@pulsar# nmap -n --max-retries 4 -PS53 -p53 -PN 93.93.93.93
   
   
   Starting Nmap 5.00 ( http://nmap.org ) at 2010-09-29 16:51 MSD
   Interesting ports on 93.93.93.93:
   PORT   STATE SERVICE
   53/tcp open  domain
   
   
   Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
   
   
   webo@pulsar# nslookup cs78.ngenix.net 93.93.93.93
   Server:                   93.93.93.93
   Address:               93.93.93.93#53
   
   
   Name:     cs78.ngenix.net
   Address: 78.41.104.43
   
   Таким образом, мы можем понять, на каком этапе определения IP-адреса возникают проблемы. Конечно же, никто не гарантирует, что проблема только в определении IP-адреса. Одновременно с этим сам сервер может быть отключен или вообще уничтожен. Но это уже другая проблема.
   

Определяем проблемы на промежуточных узлах

Для нижних уровней модели OSI все несколько сложнее.  Эти проблемы проявляются в виде ошибок libcurl, таких как CURLE_COULDNT_CONNECT (7), CURLE_OPERATION_TIMEDOUT (28), CURLE_SEND_ERROR (55) и CURLE_RECV_ERROR (56).

Часто тут можно определить лишь проблемный узел, но не уровень, на котором возникли проблемы. Для удаленного сервера поврежденный кабель между маршрутизаторами и неправильная маршрутизационная таблица могут выглядеть одинаково. Так что в этом случае остается только одно — провести трассировку маршрута с помощью утилиты traceroute. Желательно это сделать в двух режимах: ICMP и TCP/UDP.

webo@pulsar# traceroute -I -n -w 1 90.156.236.74

traceroute to 90.156.236.74 (90.156.236.74), 30 hops max, 60 byte packets

 1  192.168.1.1  1.223 ms  2.218 ms  2.670 ms

 2  212.5.114.1  12.247 ms  12.409 ms  12.439 ms

 3  87.118.210.201  12.476 ms  12.461 ms  12.479 ms

 4  87.118.192.170  20.665 ms  21.333 ms  21.265 ms

 5  195.128.64.74  12.982 ms  13.013 ms  13.039 ms

 6  213.248.78.137  13.099 ms  13.054 ms  12.191 ms

 7  80.239.147.162  22.916 ms  16.435 ms  16.386 ms

 8  80.91.246.236  39.007 ms  39.109 ms  39.393 ms

 9  80.91.249.12  55.362 ms  54.684 ms  55.056 ms

10  80.91.248.210  64.924 ms 80.91.245.183  65.895 ms 80.91.250.134  67.018 ms

11  80.91.253.169  64.177 ms  60.169 ms  59.514 ms

12  80.91.248.246  60.393 ms  59.764 ms  58.733 ms

13  213.248.88.198  58.672 ms *  59.229 ms

14  85.17.100.206  60.203 ms * *

15  * * *

16  * * *

17  * * *

webo@pulsar# traceroute -T -n -w 1 -p 80 90.156.236.74

traceroute to 90.156.236.74 (90.156.236.74), 30 hops max, 56 byte packets

 1  192.168.1.1  1.467 ms  2.219 ms  2.751 ms

 2  212.5.114.1  12.093 ms  12.144 ms  12.137 ms

 3  87.118.210.201  12.413 ms  12.425 ms  12.455 ms

 4  87.118.192.170  14.811 ms  14.738 ms  14.756 ms

 5  195.128.64.74  14.761 ms  14.779 ms  14.808 ms

 6  213.248.78.137  17.571 ms  17.310 ms  16.583 ms

 7  80.239.147.157  35.097 ms  29.924 ms 80.239.147.162  17.601 ms

 8  80.91.245.51  42.147 ms 80.91.246.236  40.269 ms 80.91.245.51  43.361 ms

 9  80.239.147.170  56.170 ms  55.182 ms *

10  * * 80.91.253.169  49.680 ms

11  80.91.253.167  60.822 ms *  60.067 ms

12  * 213.248.88.198  46.373 ms  45.933 ms

13  213.248.88.198  56.737 ms 85.17.100.206  46.183 ms  48.199 ms

14  85.17.100.206  59.943 ms 95.211.18.1  49.014 ms 85.17.100.206  56.945 ms

15  90.156.236.74  45.956 ms 95.211.18.1  56.781 ms  57.720 ms

Как видно, трассировки ICMP пакетами было бы недостаточно, т.к. на ICMP пакеты сервер не отвечает. Дополнительная трассировка с помощью TCP пакетов на 80 порт помогла установить, что сервер все-таки доступен.

Подводим итоги

Итак, диагностика проблем подразделяется на 3 основных вида: диагностика проблем с DNS, диагностика проблем на верхних уровнях модели OSI и трассировка маршрута к серверу. В зависимости от результата проверки WEBO Pulsar выбирает подходящий вариант и автоматически проводит дополнительные исследования (если включена опция «Создавать детальный лог при недоступности»). Результаты можно увидеть в личном кабинете или в уведомлении по e-mail. Это поможет быстрее понять, где именно возникла проблема, кто и как будет ее решать. В случае проблем на сервере работы прибавится администратору сервера, в случае проблем в датацентре нужно срочно связаться с техподдержкой, а в случае проблем у магистрального провайдера нужно успокоиться и подождать — от нас с вами в таких случаях мало что зависит.

Проблемы доступности сайта

Доступность сайта - вещь весьма непредсказуемая. Иногда из дома (или с работы) сайт открывается, а у ваших друзей - нет. Иногда сайт то открывается, то не открывается. Или открывается очень медленно. Установить проблему в каждом конкретном случае бывает сложно, но давайте рассмотрим основные типы этих проблем:

1. Недоступность крупного сегмента сети. В этом случае пользователи из одного сегмента сети не могут получить доступ к сайтам другого сегмента (например, из-за ошибок маршрутизации). Это достаточно легко установить специальными утилитами, но поделать в этом случае обычно ничего нельзя. И проблемы такого уровня (глобального) обычно затрагивают десятки и сотни тысяч сайтов, и решают их очень быстро.

   Здесь остается только сидеть и ждать. И надеяться, что ваши пользователи оказались в той же лодке (в том же сегменте), что и ваш сайт.

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

   Здесь необходимо при любом простое больше 10-30 минут писать в техническую поддержку вашего провайдера: может быть, они и не знают, что что-то отвалилось?

3. Большое время ожидания. В этом случае, по факту, сайт работает. И открывается для всех пользователей. Но не все пользователи могут его дождаться :)

   Это тоже можно проверить (серверное время ожидания с помощью WEBO Pulsar, а общее время загрузки - webo.in. Если время создания страниц сайта слишком велико, то стоит применить оптимизационные мероприятия. Иначе будут большие потери среди целевых пользователей.

4. HTTP-ошибки на сайте. Достаточно часто бывает так, что из-за большой нагрузки (или сбоя оборудования хостера) сайт начинает выдавать ошибку (500, 502, 503 или подобную). Отследить такие моменты и вовремя перевести сайт или целевых пользователей тоже можно, но это уже потребует особого внимания.

   Для этой цели (когда, какое время, и с какой частотой) лучше всего подойдет именно WEBO Pulsar. С его помощью вся неказистая «кухня» провайдера выйдет наружу, и вы будете четко знать, что происходит с вашим сайтом.

5. Сбой в работе сайта. Иногда с сайтом (в силу аппаратного сбоя или изменения сетевой конфигурации хостинг-провайдера) происходят незначительные происшествия, которые на доступность прямым образом не сказываются, но часть функционала сайта оказывается нерабочей. Например, перестают обрабатываться запросы к базе данных. Или начинают выводиться отладочные сообщения.

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

Сбой в работе WEBO Pulsar

Сервису WEBO Pulsar скоро два месяца с момента официального релиза. Если же считать от первого закрытого бета-теста, то уже больше трех месяцев. И вот на прошедших выходных случилась первая серьезная проблема.

Из-за аппаратного сбоя, произошедшего в нашем дата-центре, вся статистика WEBO Pulsar с 15 часов 9 октября до 9 часов утра 10 октября стала недоступна. Мы среагировали на эту проблему настолько быстро, насколько это можно было сделать субботним вечером, но последствия оказались достаточно серьезными: данные о произведенных за этот период проверках восстановить не удалось.

Какие были приняты меры для того, чтобы подобной ситуации не повториться в будущем? Мы развернули два резервных сервера для контроля работы WEBO Pulsar и оперативного реагирования на аналогичные аппаратные проблемы. Кроме этого до конца текущего года в плановом порядке мы введем в эксплуатацию несколько новых точек проверки в разных городах России и, возможно, Европы. Это позволит непрерывно контролировать веб-ресурсы из разных географических точек, причем даже если один или несколько серверов выйдут на какое-то время из строя. Об этом мы обязательно сообщим отдельно.

Хочется также заметить, что всем, у кого на момент сбоя были активные проверки в WEBO Pulsar мы компенсировали утраченные средства в двойном объеме. Спасибо за ваше понимание.

Все о дополнительных проверках

Вы наверняка обратили внимание на возможность задания дополнительных проверок для разных типов уведомлений. Сегодня мы расскажем о том как применять их наиболее эффективно.

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

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

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

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

Если рассматривать случай, приведенный на скриншоте, то точная хронология событий для проверки может выглядеть следующим образом (пусть это будет проверка HTTPS/POST, раз в 10 минут):
...
16:25 — время ответа превышено (следующая проверка запланирована на 16:35)
16:26 — производится первая дополнительная проверка, проблема подтверждается, отправляется уведомление по e-mail
16:27 — производится вторая дополнительная проверка, проблема подтверждается
16:28 — производится третья дополнительная проверка, проблема не подтверждается (проблема носила краткосрочный характер, не требует срочного вмешательства, а значит и лишнего расхода на срочную отправку СМС)
16:35 — производится очередная плановая проверка
...

Считаете, что пяти дополнительных проверок недостаточно? Есть какие-то предложения о том, как улучшить концепцию использования таких проверок? Мы с радостью примем ваши комментарии и предложения.

Знакомство с WEBO Pulsar

В этом блоге мы будем рассказывать о нашем новом сервисе WEBO Pulsar. Отсюда вы узнаете об особенностях его работы, о новых и только запланированных возможностях и многом другом. Но для начала пара о самом сервисе. Итак, какие возможности предоставляет наш сервис? Какие проблемы он помогает решить?

Основная задача WEBO Pulsar — контроль за доступностью ваших сайтов и веб-сервисов. Он выполняет проверки заданных URL с определенной вами частотой (от одной проверки в минуту до одной проверки в сутки) по протоколам HTTP, HTTPS. В ближайшем будущем появится поддержка протоколов SMTP, IMAP, MySQL и ряда других. Поддерживаются проверки методами HEAD, GET и POST. Последняя дает возможность контролировать результат отправки формы, т.е. например, результат добавления товара в корзину или входа в персональный аккаунт.

Но мало толку от проверки сайта, если об обнаруженных проблемах нельзя своевременно узнать. Мы выделяем несколько типичных проблем: недоступность веб-ресурса, превышение времени ответа, отсутствие указанного текста в ответе. При возникновении любой из перечисленных проблем сервис может рассылать уведомления по e-mail, sms, jabber (к этому списку скоро добавятся уведомления через twitter). WEBO Pulsar бережно хранит всю собранную статистику и позволяет получить эту статистику за любой день, за весь период проверок. С точностью до каждой единичной проверки. Статистика отображается на масштабируемых графиках, а также может быть в один клик выгружена в форматах CSV или HTML.

Одним из наших приоритетов при создании сервиса было обеспечение минимальной стоимости проверок, для того, чтобы найти применение сервису могли все, от студентов до крупных организаций. И с этой задачей мы пока справляемся, взгляните на наши цены. Вы можете быть уверенным в доступности своего интернет-магазина всего за 12 рублей в месяц. Это при регулярных проверках с частотой раз в десять минут. За такие деньги вы не везде бутерброд купите. Если же вам требуется контроль целого парка веб-сайтов, у нас тоже есть для вас решение. Мы заключаем договора на обслуживание компаний, предоставляем нотариально заверенные подтверждения доступности (и недоступности тоже).

Если у вас еще нет аккаунта WEBO Pulsar, зарегистрируйтесь прямо сейчас и вы беслатно получите на счет средств, в размере достаточном для нескольких недель проверок.

Возникла необходимость в новой фиче? Не удобен интерфейс? Есть вопросы по поводу ваших проверок? Присылайте ваши вопросы и предложения почтой, в комментарии или через сервис Реформал (вы ведь наверняка уже заметили кнопку Оставьте ваш отзыв, в самом сервисе?). Мы всегда рады вашему участию.