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

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. Это поможет быстрее понять, где именно возникла проблема, кто и как будет ее решать. В случае проблем на сервере работы прибавится администратору сервера, в случае проблем в датацентре нужно срочно связаться с техподдержкой, а в случае проблем у магистрального провайдера нужно успокоиться и подождать — от нас с вами в таких случаях мало что зависит.