Какие шаги вы предпримете, если обнаружите, что веб-сайт IIS не отвечает?
Я мог бы попытаться сначала установить telnet на указанный порт, затем проверить привязку и аутентификацию веб-сайта и, наконец, перезапустить его.
Я думаю, что знать, что опытный администратор проверит, столкнувшись с такими проблемами, весьма полезно.
Фактически, я сам потратил больше получаса, пытаясь выяснить, в чем проблема, и ничего не показалось неправильным. Я просто перезапустил веб-сайт, и проблема все еще существовала, но после перезапуска службы IIS проблема была решена.
Если бы я знал лучшую трассировку или хотя бы полезную функцию ведения журнала, которая помогла бы мне решить эту проблему быстрее, это сэкономило бы мне более получаса.
{К вашему сведению, я использую IIS 7.5}
Я обнаружил, что следующее руководство очень хорошо работает в качестве общего руководства по сбору.
Определите симптомы
Постарайтесь (как можно быстрее) определить поверхность проблемы:
Связь? (Telnet - это хорошо; если вы получаете страницу с ошибкой, возвращаемую в браузере, очевидно, что что-то работает - сначала удалите соединение)
Общий сбой пула приложений, или специфично для типа контента? (Файлы ASPX работают / не работают, но работают .HTM? У вас есть файлы канареек для каждого приложения и типа контента?)
Конкретный сбой, зависание или сбой в приложении? (В основном это связано с зависаниями и сбоями приложений; сбои диктуют свою собственную методологию: получить аварийный дамп, отладить его)
Как правило, всегда записывайте это, поскольку вы можете иметь дело с несколькими симптомами, и возможность вернуться к своим записям о более раннем происшествии может быть неоценимым.
Собирать информацию
он же «Сбор временных данных» - у вас есть ограниченное окно для сбора определенных данных во время сбоя. Некоторые данные - например, память процесса - недолговечны и исчезнут, если вы сначала предпримете корректирующие действия. Для копирования других данных, например журналов, может потребоваться время, но вы можете легко получить их и после. Так что поймите, какие данные вам нужно собирать СЕЙЧАС, а не после восстановления.
Возьми что угодно срочные / своевременные данные вам нужно будет решить проблему позже. Не беспокойтесь о постоянных вещах - журналы событий и журналы IIS остаются, если вы не навязчиво разбираетесь, и в этом случае: прекрати это. (Те, у кого нет журнала событий прошлой недели, обречены его повторить)
Определить затронутый рабочий процесс (и сбросить его)
APPCMD LIST WP может помочь с этим, или Графический интерфейс рабочих процессов на Сервер уровень. Если вы используете графический интерфейс, не забудьте посмотреть текущие запросы, щелкнув правой кнопкой мыши рабочий процесс - если вы его получите, он покажет вам, в каком модуле (DLL) запросы застряли, что может помочь вам угадать вызвать рано.
Определить объем (т.е. только один пул приложений, несколько пулов приложений, два с зависимостями - это зависит от вашего приложения и макета веб-сайта)
Возьмите дамп памяти из рабочий процесс - как только вы определили, в каком пуле приложений возникла проблема, определите соответствующий рабочий процесс и используйте диспетчер задач для создания дампа памяти, щелкнув этот процесс правой кнопкой мыши. Запишите имя файла на будущее.
Восстановить Сервис
Теперь у вас есть вся информация на определенный момент времени, которая, по вашему мнению, вам нужна для диагностики, так что пришло время вернуть клиентов веб-сайта в бизнес.
Рециркулировать то минимальное количество рабочих процессов для восстановления обслуживания.
Не беспокойтесь о том, чтобы останавливать и запускать веб-сайты, обычно вам нужно обновить пул приложений, чтобы сайт снова заработал, и это то, что делает Recycle.
Переработки пула приложений достаточно в 9/10 раз.
Обратите внимание, что переработка, по-видимому, происходит при следующем поступающем запросе (даже если существующему WP было приказано уйти), поэтому рабочий процесс может нет немедленно появиться снова. Это не значит, что это не сработало, просто запросы не ждут.
IISReset обычно это инструмент, которым пользуются люди, не знающие лучшего. Не используйте это если вам не нужно все веб-сайты должны быть закрыты и перезапущены сразу. (Это похоже на попытку забить гвоздь в стену кирпичом. Это может сработать, но вы как бы выглядите как идиот, и в какой-то момент будет сопутствующий ущерб).
У вас могут быть другие зависимости приложений - пулы приложений, зависящие от других пулов приложений, баз данных или внешних систем ... То, что вам нужно сделать для восстановления службы, говорит вам кое-что о масштабах проблемы. Последней в списке идет полная перезагрузка, но если драйвер уровня ядра действительно не испортился, в этом обычно нет необходимости, просто вы не можете определить, что необходимо, и это полезный сборщик ...
Определить причину т.е. посмотрите и подумайте о собранных вами данных.
Настроить на следующий раз
Вы знаете, что исправили это? Если нет, и особенно если кажется, что ничего больше не изменилось, подумайте о том, что вы могли бы захватить, если вам лучше подготовиться, если это произойдет снова.
Не думайте, что это последний случай - разрабатывать план для что тебе нужно собрать в следующий раз, исходя из этого времени.
Например, если все запросы относятся к одному и тому же URL-адресу, внедрите некоторые дополнительные инструменты или ведение журнала или правило отслеживания неудачных запросов, которое поможет определить место на странице, где возникает проблема.
Журналы монитора производительности полезны (если сомневаетесь, также получите журнал perfmon).
Посмотрите другие инструменты, которые могут быть полезны - ProcDump, XPerf / WPT / WPR и так далее. Если все, что у вас есть, это молоток, все проблемы должен быть гвоздем…
Подумайте о том, допустимо ли «скрыть» проблему при поиске реальной первопричины - если сбой действительно серьезный, что-то вроде настройки параметров повторного использования для пула приложений может быть приемлемым, чтобы минимизировать вероятность или продолжительность (кроме случаев, когда это противоречит с возможностью его устранения) ...
Почему привязки или методы аутентификации (которые должны быть статическими) заставляют сайт не отвечать? Их не было бы в моем списке проверок, или, по крайней мере, они не были бы в верхней части моего списка.
Первым делом я бы проверил, загружается ли сайт с самого сервера. Если это не так, вы можете исключить почти все возможные проблемы с сетью или DNS как причину.