Pull to refresh
0
ХостТрекер
Сервис мониторинга доступности сайтов

Мгновенная диагностика сайтов. Обзор сервиса ХостТрекер, часть 4

Reading time 3 min
Views 5.7K
Есть подозрения, что сайт ведет себя с вами по-особенному? Есть множество локальных и не очень причин, по которым сайт может открываться разработчиком, но быть недоступным клиентам. Или же наоборот. Обзор популярных причин, а также методы их диагностики с помощью бесплатных функций сервиса ХостТрекер — под катом.



«У меня все работает, ищите причину на своей стороне» — фраза, которая из-за своей банальности и вездесущности уже прочно прописалась в среде околоайтишных анекдотов и былин. Причин может быть много, но итог всегда раздражителен: как же так, вот исходник, все компилится, но по шапке все равно получаешь. Первой реакцией со стороны разработчика на такую ситуацию нередко бывает глубокое погружение в пучины кода, хотя причина далеко не всегда в нем. Поэтому для экономии сил и времени сперва строго рекомендуется все же локализировать причину. Помочь в этом могут сервисы удаленной проверки сайтов, например вот этот.



Эта публикация является продолжением серии, в которой подробно описываются функции сервиса ХостТрекер. Предыдущие части можно найти здесь: первая, вторая, третья.

Для кого же не работает мой сайт?


Очевидно, что первое, что нужно сделать при возникновении подозрений — найти, где эта проблема себя проявила. Для этого очень удобно иметь возможность провести проверку с распределенной сети:



Результаты проверки показывают, откуда сайт доступен, а откуда — нет. Также проверка показывает время определения DNS записей, загрузки страницы, а также проверяемый IP адрес — что помогает определить причину при использовании переадресации, CDN и некоторых других полезностей. Если сайт по HTTP недоступен — будет возвращена ошибка. Это может быть код ошибки HTTP — например, 404, 503 и другие. Или же ошибка соединения. Или таймаут. Для каждого типа ошибки нужно смотреть, откуда он замечен: если, например, сайт физически находится в Германии, и мы видим таймауты из Австралии и Южной Америки — значит, на сервере или в сети появились какие-то тормоза и запросы с большей физической задержкой обрабатываться уже не успевают. Если наблюдается ошибка сервера, но не отовсюду — возможно, превышен лимит одновременных соединений, или же сервер перегружен и не в состоянии обработать все запросы сразу. Можно также найти интересные «особенности местности» — некоторые хостинги или даже целые страны банят посещения с некоторых других регионов и стран. И это тоже будет отображено в результатах.

Впрочем, проверка по HTTP все еще не может предоставить полную информацию. Поэтому в наличии есть дополнительные проверки — ICMP (ping):



Показывает, все ли хорошо с доступом по сети. Также есть trace:



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

Еще есть возможность проверить любой порт, что может сильно упростить поиск проблем в случаях настройки файрвола руками не из плечей, ответить на вопросы — почему на сайт не вытягивается информация из базы/фтп сервера (тогда как из локально «все работает») и упростить множество других внештатных ситуаций.

Как показывает практика, умелое использование этого инструмента может сильно упростить жизнь. Убедившись, что сайт доступен со всего мира — можно не бежать откатываться к предыдущей версии из-за одного клиента, у которого, как потом выяснится, отключен javascript в браузере. Увидев ошибку сети, смело напрягать админов или поддержку датацентра, аргументируя свой ответ ссылкой на результаты этой проверки. А если все же проверка покажет ошибку сервера, можно быстренько лезть в логи и действовать по принципу «быстро поднятое не считается упавшим».

Профилактика — кому оно надо


Впрочем, технические проблемы самого сайта — не единственное, с чем может столкнуться ответственный сайтовод. Сайт может попасть в черные списки Роскомнадзора — для этого есть проверка RusRegBL. Или же в списки спамеров и злостных хакеров, даже не имея к этому никакого отношения — предлагается проверка DNSBL, подробнее можно почитать здесь. Также, к сайту постоянно подкрадываются проблемы, причинами которых есть баги или дыры в платформах или средствах разработки. Для решения этих проблем создана функция Health Check, которая проверяет сайт на актуальные и популярные уязвимости:



Ну и, наконец, есть функция WhoIs — чтобы посмотреть, кому принадлежит домен или сайт, не пользуясь лишний раз гуглом.

А что, если?


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

Как и всегда, мы будем благодарны за все пожелания и критику.
Tags:
Hubs:
+5
Comments 0
Comments Leave a comment

Articles

Information

Website
www.host-tracker.com
Registered
Founded
Employees
2–10 employees
Location
Украина