У нас есть веб-сервер, который находится в нашей DMZ и обслуживает веб-приложение ASP.NET. Приложение работает около 2 месяцев и отлично работает, но мы периодически получаем электронные письма от пользователей, в которых говорится, что они не могут получить доступ к сайту, потому что у них тайм-аут, или ссылка не работает, или страница не найдена и т.
Моя первая мысль заключается в том, что это что-то с их стороны, поскольку у нас были люди, тестирующие сайт буквально со всего мира без каких-либо проблем, и не было известных простоев. Моя проблема в том, что я не хочу просто говорить пользователю: «Проблема на вашей стороне, разберитесь». Я хотел бы иметь способ доказать им это или, может быть, несколько шагов, чтобы они доказали это себе.
Есть предложения для меня или пользователя, у которого возникли проблемы?
Изменить: чтобы уточнить немного больше, проблема заключается в том, что одни и те же пользователи снова и снова (например, всего 5), и они вообще не могут получить доступ к сайту. Так что это не проблема конкретной страницы. На данный момент есть несколько отличных ответов. Я хотел бы отметить более одного ответа, поскольку все они хороши.
Спасибо и за быстрый поворот. Здесь было быстрее спросить и получить ответ, чем связаться с моей серверной / сетевой группой в доме :)
Вы можете использовать этот сайт, чтобы убедиться, что ваш сайт работает "извне"
Если пользователь более сообразителен и готов сделать за вас дополнительную работу, попросите его загрузить плагин YSlow в Firefox, а затем посетить ваш сайт. Это поможет выявить узкие места в производительности, неработающие ссылки и т. Д.
Я столкнулся с этой проблемой в своей последней компании. Я бы подключился к своей машине дома и заглянул на сайт. При этом возникла одна проблема: я был на том же интернет-провайдере, что и наши серверы, поэтому это не было настоящей проверкой извне, только за пределами нашего брандмауэра.
Теперь для проверки я использую downforeveryoneorjustme.com в дополнение к своему пульту дистанционного управления.
Также, если у вашей компании несколько сайтов, вы можете использовать Nagios или даже PowerShell, чтобы проверять веб-сайты и предупреждать вас, если они выходят из строя. Просто убедитесь, что в чеке указан ваш публичный адрес.
Используйте службу удаленного мониторинга из нескольких мест. Website Pulse - хороший, дешевый и простой в настройке. Это может дать вам представление о том, как ваш сайт работает в разных частях мира и в разных сетях.
Они могут отправлять вам электронные письма и ловушки SNMP, чтобы вы знали, когда ваш сайт работает медленно или не отвечает.
Существует множество сервисов, которые протестируют ваш сайт из разных мест и предоставят вам отчет о времени ответа из каждого из них. Один из таких сайтов mon.itor.us
Вы также можете проверить свой настройки и логи сервера. Возможно, вы исчерпываете свои допустимое количество подключений, или пропускная способность, объем памяти или Мощность процессора?
Я использовал Pingdom с большим успехом. Вы можете создавать проверки, которые проверяют подключение к DNS, ICMP, HTTP, а также методы HTTP Get и Post, чтобы убедиться, что ваш сайт возвращает действительный ответ и что скрипты / формы работают правильно.
Разумная цена и чеки отправляются из 5 или 30 мест (базовый или бизнес-аккаунт соответственно). Они также отслеживают время отклика из разных мест, чтобы вы могли понять, как работает ваш сайт по всему миру.
Если это временная проблема, то она может быть вызвана временными проблемами сети в любом месте или проблемами производительности сервера. Количество возможных причин ОГРОМНОЕ! Вам необходимо устранить сервер как причину проблемы. Проверьте журналы событий ОС, журналы ошибок IIS и т. Д., Попробуйте попросить кого-нибудь немедленно связаться с вами, когда возникнет проблема. Попросите их выполнить трассировку или путь к серверу для диагностики сетевых проблем. И пока возникает проблема, проверьте сервер на предмет высокой нагрузки.
Для более окончательного ответа нам потребуется дополнительная информация.
Конечно, существует «нормальное» время простоя для веб-сайтов ... вы можете попробовать самостоятельно наблюдать за сайтом извне и проверять его работоспособность. Пока оно выше ваших 4 или 5 девяток в соответствии с вашим SLA, иногда это все, что имеет значение.
Если у вас уже есть люди со всего мира, использующие сайт, вы должны указать пользователям, у которых есть проблема, что-то вроде http://downforeveryoneorjustme.com/. Это должно доказать им, что в чем бы ни заключалась проблема, это не вы. Вам также следует настроить какой-то внутренний мониторинг, который фактически загружает веб-страницы. Мониторинг веб-сайта - это не просто получение сообщения 200 OK. Вам нужно решение для мониторинга, которое действительно ищет что-то на нужной странице. Если есть какое-либо внутреннее соединение (SQL DB, авторизация ADAM), решение для мониторинга также должно иметь возможность загружать страницу, используя его.
Доказать это так или иначе сложно, поскольку интернет-маршрутизация может быть интересной, как и DNS.
Помните, что проблема может быть не в вас или у них, это может быть часть интернета между вами. Например, DNS вашего интернет-провайдера. Или маршрутизация провайдера интернет-провайдера. Или префикс вашего веб-сервера может быть заблокирован чужой AS, рекламируя слишком широкую сетевую маску (это случилось в Google!)
Чтобы окончательно узнать, что вам необходимо выполнить nslookup-тест вашего сайта с их местоположения, в идеале начиная с корневых серверов имен, например. a.root-servers.net. и работает. Вы хотите попробовать все DNS-серверы на пути между корнем и аутентичным DNS-сервером имени хоста вашего веб-сервера, поскольку иногда случается, что один из авторитетных серверов будет fubar, но другой в порядке, поэтому он работает, скажем, для вас, но не для них .
Предполагая, что с DNS все в порядке, им нужно посмотреть, могут ли пакеты добраться до вас. Т.е. пинг в первую очередь. И вы должны быть уверены, что ваши пакеты могут вернуться. Отправьте им ответ. Предполагая, что все в порядке, вы, вероятно, захотите, чтобы они выполняли wget, curl или telnet для вашего веб-сервера и выполняли GET вручную (для устранения кешей браузера). Тогда, вероятно, будет разумно сказать, что ваша позиция достижима - если это так. А если нет, то у вас будет разумное представление о том, в чем проблема.
Как видите, дело нетривиальное.
Как предполагали другие, могут помочь некоторые коммерческие серверы, а также размещение ваших собственных серверов в нескольких местах в нескольких сетях и проверка друг друга.
Если вам нужна довольно совершенная служба мониторинга, я бы порекомендовал посмотреть что-нибудь вроде Keynote или Гомес.
Вам нужна внешняя служба, чтобы проверить ее, если вы размещаете веб-сервер, или вы можете самостоятельно разместить службу мониторинга, если веб-сервер является внешним.
В любом случае, ну, за исключением, возможно, вашего случая, но в любом случае - обычно вам нужно делать больше, чем просто проверять ответ ...
Настройте проверки определенного содержимого в ответах, чтобы вы, например, не допустили, чтобы успешный ответ, который представляет собой просто страницу с ошибкой или какой-либо другой сбой сайта, проскочил как зеленый свет - ходите вокруг, думая, что все в порядке, хотя на самом деле это не так ^^
Мониторинг любой услуги не так прост, как кажется, и именно поэтому действительно полезные костюмы часто чрезвычайно сложны и / или дороги. Конечно, простые методы могут охватывать основы, особенно, возможно, в этом конкретном случае.
Мне повезло с Keynote (не могу добавить ссылку, так как я новый пользователь). Вы можете настроить мониторы с разных точек, указать интервалы тестирования и т. Д.
Раньше я использовал основные и гомезные сети, но сначала я должен спросить, откуда вы знаете, что это не проблема для вашего сайта?
В предыдущей работе у нас однажды были жалобы на то, что наш сервис недоступен, и мы обнаружили, что только через трассировку пакетов, которые пользователь подключались, и возвращали нулевые байты.
Ничего не отображается в журналах доступа, и никаких других следов того, что пошло не так, не осталось в наших системах.
Оказалось, что это какая-то ошибка в модуле apache, из-за которой он запаниковал вместо того, чтобы выдать ошибку любого рода.