Как понять не работает

�� Обзор способов как проверить, работает или не работает сайт

Обзоры

Давайте разберемся, как проверить, что определенный сайт не работает для всех или только для вас.

Иногда пользователи могут не иметь доступа к сайту.

Но когда вы заходите на сайт самостоятельно, все работает нормально.

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

Посетители могут покинуть ваш сайт, если этот сбой будет продолжаться, что может повредить трафику и впечатлению от бренда.

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

Поступая таким образом, вы сможете диагностировать любые проблемы с сервером хостера.

Что означает простой веб-сайта?

Считается, что сайт не работает, если он полностью недоступен или не способен удовлетворить потребности посетителей.

Время простоя – это время, в течение которого продолжаются сбои в работе.

Причины сбоев в работе веб-сайтов и как их предотвратить

Вы должны знать о нескольких важнейших причинах сбоев в работе веб-сайта.

• Одновременный доступ слишком большого количества людей к веб-странице (перегрузка сервера)
• Ненадежный хостинг веб-сайта
• Неправильное обслуживание сервера
• DDoS-атаки и проблемы с DNS

Несмотря на то, что полностью предотвратить сбои в работе сайта невозможно, вы можете предпринять шаги для повышения стабильности вашего сайта.

• Активируйте автопродление, чтобы предотвратить истечение срока действия домена и хоста.
• Выберите надежного хостинг-провайдера
• Развертывайте только необходимые плагины
• Используйте сети доставки контента (CDN), чтобы распределить нагрузку сетевого трафика на несколько серверов.
• Чаще тестируйте функциональность вашего сайта.
• Используйте услуги мониторинга сайта, чтобы минимизировать время простоя и повысить функциональность сайта.

Здесь представлен список лучших онлайн-сервисов для мониторинга времени работы веб-сайта.

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

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

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

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

UpTrends

UpTrends – это мощный и удобный онлайн-инструмент, который поможет вам быстро определить, находится ли целевой веб-сайт в нерабочем или рабочем состоянии.

Введите имя хоста или IP-адрес сайта в поле ввода и нажмите на кнопку “Start test”, чтобы продолжить.

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

Этот веб-сервис предоставляет различные инструменты, включая средство проверки производительности CDN, калькулятор рентабельности инвестиций CloudCost, средство проверки DNS и т.д.

Site24x7

Инструмент Site24x7 довольно прост в использовании.

Просто введите URL-адрес или название сайта в поле ввода и нажмите кнопку “Test NOW”, чтобы начать.

С помощью более чем 60 серверов, расположенных по всему миру, вы можете оценить доступность веб-сайта.

Он также отображает время загрузки веб-сайта, время резолва DNS и общее время отклика.

Этот сайт также предоставляет различные инструменты системного администратора и сетевые инструменты, включая AWS designer, Traceroute generator, Timestamp convertor, Heartbleed & Ghostcat vulnerability checker и многие другие.

Down Inspector

Down Inspector – это еще один бесплатный и фантастический инструмент для проверки доступности веб-сайта.

Просто введите URL или название сайта, который вы хотите проверить, и нажмите кнопку “CHECK”.

По сравнению с другими простыми пинговыми сайтами, он предлагает больше возможностей.

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

Кроме того, посетители могут сообщить о проблемах с доступностью любого сайта в Интернете.

IsItdownRightNow

Одним из самых популярных онлайн-инструментов для проверки статуса доступности веб-сайта является IsItdownRightNow.

Просто введите URL сайта и нажмите на кнопку “Check”, чтобы выполнить проверку доступности сайта.

Он также предлагает некоторую дополнительную информацию.

Например, вы можете просмотреть список связанных веб-сайтов и рейтинг пользователей.

Кроме того, он предоставляет подробную историческую справку о времени работы сайта.

Doj.me

Doj.me – это веб-сервис и простой в использовании инструмент.

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

URL сайта необходимо ввести в отведенное место, а затем нажать кнопку “Check Now””, чтобы продолжить.

Команды в терминале

В качестве альтернативы вы можете использовать инструмент командной строки ping в терминале, чтобы проверить, работает ли веб-сайт правильно или нет.

Он доступен на Mac, Windows и во всех дистрибутивах Linux.

В терминале просто введите следующую команду.

Можно ввести URL-адрес веб-сайта или IP-адрес.

Менее чем через минуту появятся результаты пинга.

Если вы получите ответ, начинающийся со слов “Reply from…”, это означает, что веб-сайт работает.

Однако если вы увидите какие-либо ошибки типа “Destination Host Unreachable” или “Request timed out”, веб-сервер находится в автономном режиме.

Заключение

Я надеюсь, что эти инструменты помогут вам определить, работает или не работает целевой веб-сайт.

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

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

Итак, приступим.

Для начала, необходимо исключить из списка возможных неисправностей самые очевидные и легко диагностируемые: отсутствие подключения к Wi-Fi, проблемы на стороне интернет-провайдера или, например, отсутствие кабеля в розетке и аккумулятора в ноутбуке.

Предлагаю также опустить сложно решаемые проблемы и неисправности локального интернета или самого компьютера, которые требуют непосредственного вмешательства сисадмина. Это могут быть вирусы-трояны, проблемы с железом, браузером или операционной системой, MTU на роутере, неправильно настроенный DNS или сбои в работе DNS и ещё целый ряд проблем, которые выявить можно, но статья, в этом случае, превратится в книгу или даже в учебный курс.

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

Как найти причину?

1. Интернет — это огромное количество магистралей, ведущих от сервера к серверу, и бывают случаи, когда наш сервер работает и мы видим другие сайты, но вот путь пакетов от нас к нашему сайту оборван: сегментировалась сеть из-за сбоя роутинга или где-то произошел сбой в работе каналов провайдеров. Конечно же, в консоли команда traceroute (tracert в Windows) покажет, доступен ли сервер нашего сайта, через какие сервера идут пакеты и на каком месте они «стопорятся». Если же traceroute и ping не доходят до нашего сервера, но достигают сети хостера, то самое время звонить в техподдержку хостинга или сисадминам, так как, в этом случае, сложно будет что-то предпринять самостоятельно.

Traceroute и ping – несложные команды, в Википедии есть статьи на эту тему с вполне доступным описанием:
https://ru.wikipedia.org/wiki/Traceroute
https://ru.wikipedia.org/wiki/Ping

Если traceroute «залипает» где-то на магистральных каналах по дороге к сайту, то рекомендую обязательно проверить, как виден сервер / сайт с других серверов (компьютеров) мировой сети вне вашего провайдера. Они, с большой долей вероятности, используют другие магистрали и зачастую бывает видно, что traceroute через другие каналы успешно проходит к вашему серверу. Например,
http://network-tools.com/default.asp?prog=express&host=www.reg.ru

Если всё в порядке, то проблемы либо у вашего провайдера, либо у его провайдеров уровнем выше, но не возле вашего сервера и не на нём.
Теперь можно позвонить в техподдержку вашего локального провайдера и поинтересоваться: «какие там магистральные каналы лежат?» 😉

2. Скорость и стабильность интернет-канала — это скорость и стабильность самого медленного и плохого канала связи на пути от вас к серверу. Определить, есть ли проблемы с потерями пакетов «по дороге», большие задержки пакетов между разными провайдерами или между вами и провайдером, можно с помощью утилиты mtr, а результаты утилиты особенно показательны при большом размере пакета и его возможной сегментации (например, 1500 байт).

Mtr – это что-то вроде совмещённых ping (опрос каждого сервера по пути следования пакетов) и traceroute (определение всего пути следования пакетов), но имейте в виду, что из-за постоянного потока пакетов утилита съедает достаточно много трафика.

Запрос проверки к сайту yahoo.com:

Показательным для нас будет значение процента потерь пакетов (Loss%) нашего, финального в списке, сервера. Потери на промежуточных серверах, если они не сказываются на финальном, скорее всего, происходят из-за ограничения количества тестовых пакетов к ним (ICMP-траффика).

Обычно, если имеется 30 – 50 % потерь больших пакетов, то проблемы с подключением уже становятся ощутимыми (страница «залипает», подтормаживает из-за недогруженных элементов), и чем выше процент, тем сложнее пробиться.

Проблемы могут рождаться на каком-то промежуточном узле, например, на следующем магистральном Wi-Fi-линке от вашего офиса к провайдеру (если есть). К тому же, причиной могут стать проблемы в связи и роутинге пакетов между провайдерами.

С подробной статьей по использованию mtr для диагностики проблем с каналом (на английском) можно ознакомиться здесь или на Википедии.
Некое подобие утилиты mtr в Windows NT — pathping.

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

При работе с Chrome Developer Tools (Menu -> Tools -> Developer Tools), во вкладке «Сеть» (Network), обновляем страницу нашего сайта и получаем отчёт о том, как грузятся все ресурсы на ней:

При успешной загрузке (пусть и медленной) страницы сайта будет видно: когда загрузится основной контент страницы и она начнёт формироваться для отображения, когда начнут работать на сайте все вложенные java-скрипты, завязанные на работу с элементами страницы и ожидающие полной догрузки основного кода и необходимых неопределённых дополнительных вложенных элементов. Этот момент на картинке выше: синяя вертикальная линия – это событие DOMContentLoaded, а красная вертикальная линия – срабатывание windows.onLoad event (когда скрипты уже отработали и сформировалась вся страница с элементами, догружается содержимое картинок).

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

Как мы видим здесь, наш браузер ждал данные от сервера 68 миллисекунд (сервер формировал страницу на полученный от нас запрос) и 2 миллисекунды она принималась (что достаточно быстро).

Уже по этой информации иногда можно увидеть, что проблема состоит в медленной загрузке сайта — это, например, не миллисекундное, а 30-тисекундное формирование основного кода страницы. Такое бывает, когда перегружен запросами сервер или провайдер, используется неэффективный код (долго работает конкретно запрос этой страницы) или существуют какие-либо другие причины, которые уже впору анализировать сисадминам и программистам движка.

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

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

<script> document.write(‘<scr’+’ipt type=»text/javascript»‘+’ src text-align:center;»>

То есть, пока не подгрузится и не отработает блок <script…>, который в свою очередь ссылается на внешний ресурс, браузер будет ожидать от него результатов, зачастую не отображая содержимое страницы или отображая неправильно, хотя современные движки браузеров могут работать и на опережение.

Вот и на скриншоте выше работа скриптов на странице началась с задержкой в 135 мс из-за загрузки рекламного скрипта с admobi.ru (admobi.js). Бывают случаи, когда сервер раздачи кода рекламы и статистики доступен, но отвечает медленно, а браузер, успешно с ним соединившись, может ждать отклика десятки секунд.

4. Как и с traceroute (п.1), информацию по загрузке страницы через Developer Tools (п.3) можно и нужно проверить «чужим взглядом на свой сервер» с помощью подобных внешних сервисов-анализаторов, например:
http://www.uptrends.com/aspx/free-html-site-page-load-check-tool.aspx

Как это выглядит:

Обратите внимание на финал таблицы первого сервиса с временными итогами. И на начало таблицы второго, с ранжированием «как ваш сайт доступен по скорости, в сравнении с другими сайтами сети», а также количеством запросов (элементов), объёмом и временем загрузки всей информации страницы.

Такие отчёты и сравнения с таймлайнами загрузки в своём браузере покажут места, где загрузка сайта через вашего провайдера отличается от загрузки в этих двух сервисах и где происходит самая большая задержка. Даже, например, в HTTPS Handshake могут быть ощутимые лаги при проверке сертификатов от вас на сервера провайдера сертификатов.

Ещё одна «фишка» этих двух сервисов – это возможность выбрать сервер, с которого будет проводиться тестовый запрос, то есть сымитировать, как ваша страница грузится с сервера в Берлине, Нью-Йорке или Москве.

• Проблема с работой плагинов, которых в современных браузерах сейчас тонны:
  • Отключите все и сравните;
  • Или наоборот, включите (ищите!) плагины adblock и ghostery.
  • сервер-сбора-статистики.ru 127.0.0.1;
  • рекламный-сервер.com 127.0.0.1;
  • и другие сервера, скрипты из которых вызываются на странице.

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

  Как проверить, работает ли интернет

  Иногда бывает так: компьютер вроде подсоединён к сети, а интернета нет: сайты не грузятся, ютуб не работает, жизнь замерла. При этом значок соединения есть, но по факту ничего не работает. Рассказываем, как проверить, в чём дело, и что можно выяснить до звонка в техподдержку.

  Что будем делать

  В каждой операционной системе для компьютеров есть две команды, которые чаще всего используются для диагностики работы интернета. Наша задача — выяснить, может ли сама операционная система выходить в интернет или он ей тоже недоступен. Случается такое, что система может выходить в сеть, а программы (браузер, например) — нет. Это значит, что с интернетом всё в порядке, а причину надо искать в программах.

  Что понадобится

  Чтобы понять, есть ли интернет в принципе, используют две команды:

  1. ping
  2. tracert в Windows или traceroute в Linux и MacOS

  Это консольные команды, поэтому для работы с ними понадобится командная строка или терминал. Чтобы начать с ним работать в Windows, нажмите сочетание клавиш Win+R, в появившемся окошке напишите cmd и нажмите Enter. В MacOS делается по-другому: нажимаете ⌘+пробел, пишете terminal и нажимаете Enter.

  Запущенный терминал в MacOS. Сюда мы будем вводить те две команды

  Командой ping мы проверяем, может ли операционная система связаться с выбранным сервером или сайтом в интернете.

  1. Компьютер посылает запрос на выбранный сервер и засекает время.
  2. Как только пришёл ответ от сервера — выводим время, за которое запрос дошёл до места и вернулся обратно.
  3. Если ответа нет — будет сообщение, что превышено время ожидания.
  4. Так будет происходить раз за разом до тех пор, пока мы не нажмём Ctrl+С.

  Если мы всё время получаем сообщение, что превышено время, то, скорее всего, с интернетом что-то не так: запросы отправляются, но по каким-то причинам не возвращаются. Тут надо уже разбираться с провайдером.

  Давайте разберём, что здесь происходит, на примере такой строчки:

  64 bytes from 87.250.250.242: icmp_seq=4 ttl=247 time=15.995 ms

  

  64 — это размер нашего запроса в байтах. Его можно сделать больше или меньше для разных случаев.

  87.250.250.242 — адрес одного из серверов Яндекса, который отвечает за ya.ru.

  icmp_seq=4 — сейчас перед нами будет результат отправки пятого ICMP-пакета (потому что нумерация начинается с нуля).

  ttl=247 — время жизни пакета составляет 247 пересылок. Про время жизни поговорим чуть ниже.

  time=15.995 ms — запрос до сервера и обратно шёл почти 16 миллисекунд. Этого вполне хватит для обычного использования интернета, но может быть критично много для игр.

  В самом конце программа сообщает, что у нас 10 пакетов ушло, 10 пришло и 0% потерь, то есть соединение стабильное.

  Что такое TTL, или время жизни пакета

  Перед тем, как говорить о следующей команде, расскажем про TTL.

  Когда данные разделяются на части для отправки через сеть, это называется пакетом. Основное, что делают сетевое оборудование и служебные сервисы, — получают пакеты и пересылают их дальше. Но бывает так, что по разным причинам пакет начинает ходить по кругу: сервер1 → роутер → сервер 2 → роутер → сервер 1 и так далее. Если таких пакетов станет много, они забьют всю сеть и новые данные отправить не получится.

  Решение придумали такое: одним из параметров пакета сделали TTL, что расшифровывается как «Время жизни пакета» (time to live). Каждый раз, когда пакет пересылается от одного устройства к другому (такие пересылки называются «хопами»), это значение уменьшается на 1. Как только этот параметр у пакета станет равен нулю, маршрутизатор удаляет этот пакет.

  Tracert или traceroute

  В разных операционных системах эта команда пишется по-разному:

  • tracert — в Windows;
  • traceroute — в Linux и MacOS.

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

  С помощью этой команды сисадмины выясняют, на каком этапе сеть перестаёт работать как нужно и кто виноват: оборудование клиента, общедомовый роутер или сервер провайдера.

  Работает это так:

  1. Компьютер отправляет первый запрос на выбранный сервер и устанавливает ему TTL=1.
  2. Это значит, что пакет дойдёт только до следующего устройства, например домашнего роутера, и на этом его путь закончится.
  3. Компьютер показывает время прохода пакета до первого устройства.
  4. Затем компьютер отправляет второй запрос на выбранный сервер и устанавливает ему TTL=2. Теперь запрос может пройти два устройства — домашний роутер и, например, общедомовый.
  5. Компьютер показывает время прохождения пакета до второго устройства.
  6. Так, шаг за шагом, компьютер увеличивает TTL до тех пор, пока пакет не дойдёт до финального сервера.

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

  Теперь практика. Например, команда traceroute thecode.media покажет весь маршрут пакета до сайта «Кода»:

  

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

  • router.lan (192.168.88.1) — домашний роутер;
  • 192.168.55.1 — районный роутер провайдера;
  • * * * — какой-то сервер или маршрутизатор, который специально не отвечает на trace-запросы, поэтому адреса мы не видим;
  • lag-2-435.bgw01.bryansk.ertelecom.ru (109.194.8.18) — сервер городского провайдера в Брянске;
  • ertelecom.w-ix.ru (193.106.112.151) — сервер другого провайдера;
  • selectel.w-ix.ru и 92.53.93.57 — серверы Селектела, на которых размещается наш сайт;
  • 31.184.208.243 — адрес сервера, на котором работает «Код».

  А вот как выглядит трассировка до того же сайта, но при подключении через мобильный интернет:

  

  Шагов стало больше, и появилось больше узлов, которые не отвечают на trace-запросы, — это могут быть вышки сотовой связи и внутреннее магистральное оборудование провайдера. На восьмом запросе наш пакет дошёл до сервера 46.229.142.76 — это сетевой узел «Мегафона» в Нижнем Новгороде, через который запросы по скоростному магистральному каналу отправляются в интернет.

  Что дальше

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

  Отслеживаем работоспособность сайта или как вовремя узнать, что ваш сайт не работает.

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

  Чтобы отследить работоспособность сайтов достаточно использовать специальные сервисы мониторинга. Один из таких сервисов – это Host-tracker.

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

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

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

  И на последок небольшая подборка ссылок на сервисы мониторинга сайтов:

  Похожие публикации:

  1. Tork кто производитель страна
  2. Volkswagen polo как поменять предохранитель прикуривателя
  3. Как проверить клапан vvti
  4. Как снять заднее сиденье на хендай солярис