Между 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-адреса сервера
- На всякий случай проверим еще раз, доступен ли 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 MSDInteresting ports on 192.168.1.1:PORT STATE SERVICE53/tcp open domain
Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds
- Попробуем получить NS запись для проверяемого домена.
webo@pulsar# nslookup -q=NS webo.inServer: 192.168.1.1Address: 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.5dns1.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.1Address: 192.168.1.1#53
Non-authoritative answer:www.webogroup.com canonical name = cs78.ngenix.net.
Authoritative answers can be found from:ngenix.netorigin = ns.ngenix.netmail addr = noc.ngenix.netserial = 1285244204refresh = 28800retry = 7200expire = 604800minimum = 86400
В этом случае доменное имя является синонимом другого имени. В качестве доменного имени теперь следует использовать cs78.ngenix.net, а в качестве nameserver — сервер ns.ngenix.net.
Если же ни одной NS или CNAME-записи получить не удалось, то проблема локализована. Скорее всего, домен не делегирован. В первую очередь нужно проверить сроки делегации домена и NS-записи для него.
- Если же проблема по-прежнему не локализована, попробуем определить IP-адреса обнаруженных NS-серверов.
webo@pulsar# nslookup ns.ngenix.net
Server: 192.168.1.1Address: 192.168.1.1#53
Non-authoritative answer:Name: ns.ngenix.netAddress: 93.93.93.93
Если на этом шаге не удается определить IP-адреса ни одного из NS-серверов, то проблема локализована.
- Последнее, что можно сделать — проверить доступность самих NS-серверов, убедиться, что на них доступен 53 порт и работает служба DNS. Разумеется, проверять это имеет смысл только для тех NS-серверов, для которых удалось определить IP-адрес.
webo@pulsar# traceroute -T -n -p 53 93.93.93.93traceroute to 93.93.93.93 (93.93.93.93), 30 hops max, 56 byte packets1 192.168.1.1 1.265 ms 2.230 ms 2.693 ms2 212.5.114.1 12.918 ms 13.080 ms 13.100 ms3 87.118.210.201 13.068 ms 14.752 ms 14.751 ms4 87.118.192.170 14.782 ms 14.806 ms 14.833 ms5 195.128.64.74 15.538 ms 15.570 ms 15.596 ms6 217.150.38.58 15.626 ms 15.596 ms 14.668 ms7 217.150.45.142 153.807 ms 143.696 ms 143.542 ms8 193.232.226.22 15.875 ms 15.867 ms 14.312 ms9 78.41.104.133 9.346 ms 9.324 ms 9.136 ms10 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 MSDInteresting ports on 93.93.93.93:PORT STATE SERVICE53/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.93Server: 93.93.93.93Address: 93.93.93.93#53
Name: cs78.ngenix.netAddress: 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. Это поможет быстрее понять, где именно возникла проблема, кто и как будет ее решать. В случае проблем на сервере работы прибавится администратору сервера, в случае проблем в датацентре нужно срочно связаться с техподдержкой, а в случае проблем у магистрального провайдера нужно успокоиться и подождать — от нас с вами в таких случаях мало что зависит.
