Поделиться через

Диагностика приложений

  • Статья

AppFabric предоставляет возможности для управления размещенными в IIS службами WCF и WF на основе Платформа .NET Framework версии 4. Эти возможности включают механизмы обеспечения надежности для размещения устойчивых служб рабочих процессов, упрощенную конфигурацию приложений и средства наблюдения за работоспособностью служб WCF и WF на основе Платформа .NET Framework 4. В этом разделе описано, как использовать средства наблюдения для устранения неполадок, связанных со службами.

Используйте панель мониторинга для начала устранения неполадок, связанных со службами WCF и WF. Щелкните значок Панель мониторинга в группе AppFabric диспетчера IIS для отображения страницы Панель мониторинга. Эта составная страница содержит сводное представление о работоспособности приложений, развернутых в определенной области IIS, а также ссылки для детализации диагностических сведений. Если метрики, отображаемые на панели мониторинга и на соответствующих страницах, не предоставляют тех подробных сведений, которые необходимы для устранения неполадки, можно использовать средства AppFabric для включения трассировки System.Diagnostics с целью устранения неполадок, связанных с приложением WCF или WF.

Устранение неполадок с использованием панели мониторинга

Для распределенных приложений точное определение неполадки отнюдь не сводится к анализу одного счетчика или использованию отдельного инструмента. Устранение неполадок в среде распределенных служб, как правило, подразумевает сопоставление данных, полученных из различных средств и счетчиков, что позволяет получить достоверную картину настоящих причин проблемы. Панель мониторинга состоит из трех мини-приложений: Материализованные экземпляры WF, Журнал вызовов WCF и Журнал экземпляров WF, которые можно использовать для соотнесения сведений при устранении неполадок, связанных с приложениями. Два последних мини-приложения являются историческими метриками. Это означает, что отображаемые данные зависят от времени, указанного в параметре Период времени в верхней части панели мониторинга (Последняя минута, Последние 24 часа и так далее).

При первом открытии или просмотре любого из трех мини-приложений будет отображено высокоуровневое сводное представление состояния метрик. Можно быстро оценить, видна ли неполадка на этом уровне. Например, мини-приложение Материализованные экземпляры WF изначально отображает состояние активных экземпляров устойчивых рабочих процессов, состояние которых было сохранено в хранилище сохраняемости. Здесь предоставляется сводка по ряду материализованных экземпляров, которые находятся в состоянии "Активный", "Бездействие" и "Приостановка". Это позволит быстро узнать о проблеме на уровне материализованных рабочих процессов. Ссылки на странице сводки можно щелкать для получения дополнительных сведений об определенном счетчике сводки.

Использование метрик материализованных экземпляров WF

Мини-приложение Материализованные экземпляры WF отображает состояние активных экземпляров устойчивых рабочих процессов, состояние которых было сохранено в хранилище сохраняемости. Здесь показано количество материализованных экземпляров, находящихся в состоянии "Активный", "Бездействие" и "Приостановка". Каждый заголовок и сам счетчик сводки является ссылкой на страницу Материализованные экземпляры WF, содержащую необработанные данные.

Чтобы лучше понять проблему при устранении неполадок, связанных с приостановленными экземплярами, щелкните ссылку Приостановленные экземпляры на панели мониторинга. На странице Материализованные экземпляры WF показаны все приостановленные экземпляры. Выбор одного из экземпляров приводит к заполнению панели сведений в нижней части экрана сводными данными о приостановленном экземпляре. На вкладке Ошибки показана причина приостановки экземпляра. Если необходимы дополнительные сведения, можно щелкнуть правой кнопкой мыши экземпляр и выбрать параметр Просмотр отслеживаемых событий. Это действие приведет к открытию страницы Отслеживаемые события, на которой отображаются все отслеживаемые события для приостановленного экземпляра рабочего процесса. По умолчанию события упорядочиваются так, что самые новые события размещаются сверху.

Использование метрик журнала вызовов WCF

Мини-приложение Журнал вызовов WCF служит для отображения ряда вызовов WCF, которые были получены и записаны в хранилище данных наблюдения. В заголовке отображается сводное количество выполненных вызовов, возникших исключений или количество срабатываний регулирования. В первом столбце показаны первые пять служб с наибольшим числом выполненных вызовов. Во втором столбце содержится разбивка ошибок WCF, сгруппированных по типу. В третьем столбце показаны первые пять служб с наибольшим количеством исключений. Каждая метрика ссылается на страницу Отслеживаемые события, на которой можно просмотреть необработанные данные, сведенные на панели мониторинга.

Например, чтобы получить дополнительные сведения о неудачном вызове, щелкните счетчик сводки Неудачные вызовы и перейдите на страницу Отслеживаемые события. На этой странице приведены последние неудачные вызовы WCF для выбранной области в иерархии IIS. Выбор одного из этих событий приводит к заполнению панели сведений в нижней части экрана. На вкладке Ошибки содержатся сведения об исключениях, относящихся к неполадке. Если нужно ознакомиться с расширенным контекстом неудачного вызова, можно щелкнуть событие правой кнопкой мыши и выбрать команду Просмотр всех связанных событий. Это приведет к обновлению страницы Отслеживаемые события и заполнению ее всеми событиями, относящимися к первому.

Примечание

Чтобы можно было использовать команду Просмотр всех связанных событий, уровень наблюдения для приложения должен быть не ниже, чем Сквозное наблюдение. Этот уровень требует от инфраструктуры наблюдения собирать события передачи, сопоставляющие один идентификатор сквозного действия (E2EActivityId) с другим.

Использование метрик журнала экземпляров WF

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

Устранение неполадок с использованием сведений из мини-приложения Журнал экземпляров WF аналогично использованию мини-приложения Материализованные экземпляры WF. Щелкните один из заголовков, чтобы перейти на страницу Отслеживаемые экземпляры WF, где можно будет посмотреть сведения об экземпляре рабочего процесса. Тем не менее, поскольку мини-приложение Журнал экземпляров WF отображает экземпляры рабочих процессов, которые уже могут быть выполнены, здесь не будут отображаться действия управления экземплярами, аналогичные действиям на странице Материализованные экземпляры WF. На странице Отслеживаемые экземпляры WF можно щелкнуть правой кнопкой мыши экземпляр и просмотреть его отслеживаемые события для оценки низкоуровневых данных отслеживания этого экземпляра.

Устранение неполадок с помощью трассировки System.Diagnostics

AppFabric использует улучшения в трассировке WCF и отслеживании WF, представленные в Платформа .NET Framework 4, которые передают события подсистеме трассировки событий Windows. Средство трассировки событий Windows представляет собой быструю инфраструктуру трассировки событий. Однако в некоторых сценариях может понадобиться просмотреть все доступные сведения диагностики. В AppFabric можно включить трассировку System.Diagnostics на уровне приложения или сайта. Эти сведения трассировки записываются в файлы на диске, которые потом можно просмотреть в средстве просмотра трассировки служб.

Предупреждение

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

Диагностика распределенного приложения ASP.NET

Идентификатор действия можно использовать (как упоминалось в предыдущем разделе Использование метрик журнала вызовов WCF) для поиска идентификатора устойчивого экземпляра и диагностики приложения ASP.NET, которое взаимодействует со службами WCF через несколько серверов AppFabric. Для этого должен быть задан уровень наблюдения не ниже "Сквозное наблюдение", чтобы настроить трассировку действий. Рассмотрим пример того, как это можно выполнить.

При отслеживании веб-приложения с помощью средств наблюдения ASP и IIS администратор замечает увеличение числа ошибок, связанных с истечением времени ожидания, при взаимодействии приложения ASP.NET с сервером. После проверки ошибок администратор получает идентификатор действия, которое активно во время возникновения ошибки. С помощью панели мониторинга AppFabric администратор создает и выполняет запрос для этого идентификатора действия. Возвращается одно событие — событие получения в экземпляре Y службы X. Администратор просматривает поток связанных с этим событием сообщений и замечает событие "Превышено максимальное количество одновременных вызовов регулирования". При просмотре страниц общих сведений о службе администратор замечает, что для параметра "Срабатывания регулирования WCF" задано значение 20. Он также просматривает вызовы за последние 24 часа и видит превышение пиковых значений за последние 30 минут. Он просматривает другие дни и замечает, что такая же ситуация повторяется в одно и то же время каждый день. Он приходит к выводу, что нагрузка возрастает в это время каждый день и значение параметра максимального количества одновременных вызовов регулирования следует увеличить до 25. Присмотревшись внимательнее, администратор замечает, что частота событий регулирования существенно уменьшается, что характерно для ошибок, связанных с истечением времени ожидания, при вызове приложением ASP.NET служб WCF.

Задания службы Windows агента SQL Server

Служба Windows агента SQL Server отслеживает операции SQL Server, автоматизирует определенные административные задачи, при необходимости создает предупреждения, а также планирует и выполняет задания. Задание SQL Server является определенной последовательностью различных операций, связанных с базами данных, которые последовательно выполняются агентом SQL Server. Если для AppFabric настроено использование SQL Server, агент SQL Server используется для импорта событий в хранилище данных наблюдения и регулярной очистки старых данных из хранилища.

Если агент SQL Server не запущен, запланированные задания AppFabric не смогут запуститься на сервере SQL Server. Ниже приведен ряд действий, которые позволят гарантировать запуск этих заданий по расписанию с помощью службы Windows агента SQL Server:

  1. Проверьте состояние службы Windows агента SQL Server и убедитесь, что она запущена. Щелкните пункт Администрирование, выберите оснастку Службы, затем выберите пункт Агент SQL Server (MSSQLSVR) и убедитесь, что в поле Состояние указано значение Работает. Если это не так, запустите службу.

  2. При инициализации хранилища создается четыре задания SQL Server:

    • Microsoft_ApplicationServer_Monitoring_AutoPurge_<имя_БД_наблюдения>

    • Microsoft_ApplicationServer_Monitoring_ImportWfEvents_<имя_БД_наблюдения>

    • Microsoft_ApplicationServer_Monitoring_ImportWcfEvents_<имя_БД_наблюдения>

    • Microsoft_ApplicationServer_Monitoring_ImportTransferEvents_<имя_БД_наблюдения>

    Если служба Windows агента SQL Server запущена, однако задания AppFabric не выполняются, проверьте наличие ошибок при последнем запуске задания.

  3. Если экземпляры задания были успешно выполнены, однако в таблицах отсутствуют события, просмотрите таблицу ASFailedStagingTable в хранилище данных наблюдения. В этой таблице содержатся определенные столбцы, такие как ErrorNumber и ErrorMessage, которые помогут выяснить причину неполадки. Если ошибок не было, эта таблица будет пустой.

Удостоверение Windows (владелец), в контексте которого выполняется задание агента SQL Server для AppFabric, не должно принадлежать пользователю, выполнившему вход в систему. Лучше запускать задание в контексте удостоверения предварительно настроенной учетной записи безопасности Windows AS_MonitoringDbJobsAdmin. В идеале эта учетная запись должна быть доменной. Ей предоставляются необходимые разрешения в хранилище данных наблюдения при запуске командлета Initialize-ASMonitoringDatabase после установки.

Вот как агент SQL Server обрабатывает различных владельцев предоставленного сервером AppFabric задания:

  • Если владелец задания агента SQL является доменной учетной записью, SQL Server обращается к контроллеру домена для проверки действительности этой учетной записи. В случае положительного ответа задание выполняется от имени доменной учетной записи. В противном случае выполняется попытка запуска задания от имени локальной учетной записи.

  • Если владельцем задания агента SQL Server является локальная учетная запись системного администратора, агент SQL Server правильно воспримет удостоверение запуска от имени для шага задания и выполнит команду "Execute user as AS_MonitoringDbJobsAdmin". Это означает, что задание будет выполняться от имени учетной записи AS_MonitoringDbJobsAdmin.

    Примечание

    Чтобы просмотреть удостоверение запуска от имени в среде SQL Server Management Studio, щелкните правой кнопкой мыши задание, выберите пункт Свойства, затем перейдите на вкладку Дополнительно. Это значение должно являться учетной записью AS_MonitoringDbJobsAdmin.

  • Если владельцем задания агента SQL Server является локальная учетная запись, не являющаяся системным администратором, удостоверение запуска от имени, предоставленное на этапе задания, игнорируется. В этом случае служба агента SQL Server выполняет задания от имени локального владельца.

  • Если в случае отключения от домена (например, при использовании переносного компьютера) удостоверением задания наблюдения SQL Server является доменный пользователь, агент SQL Server пытается проверить учетную запись на контроллере домена. Если компьютер, на котором выполняется задание агента SQL Server, отключен от домена, такая проверка завершается сбоем. Для устранения подобного поведения можно пойти двумя путями:

    1. Первый и самый простой путь состоит в том, чтобы настроить задание (то есть выполнить командлет Initialize-ASMonitoringDatabase) с использованием локальной учетной записи пользователя.

    2. Второй путь следует использовать в том случае, если задание уже настроено владельцем с использованием доменной учетной записи. В этом случае пользователь может изменить владельца задания позже, указав учетную запись локального пользователя и используя для этого хранимую процедуру sp_update_job на сервере SQL Server.

Рекомендуется настроить службу Windows агента SQL Server для работы в контексте локальной учетной записи. Это позволит службе работать на компьютере AppFabric даже в случае разрыва сетевого подключения. Если эта служба выполняется от имени доменной учетной записи и домен недоступен, служба Windows агента SQL Server не сможет получить учетные данные. Это означает, чтобы события наблюдения не смогут быть правильно перемещены в целевые таблицы. В результате новые данные на панели мониторинга отображаться не будут.

Задания экспресс-выпуска SQL Server

Несмотря на то, что действия по диагностике причины сбоя задания во многом аналогичны действиям в SQL Server, в экспресс-выпуске SQL Server необходимо также просматривать таблицу ASJobsTable. Эта таблица используется только в экспресс-выпуске SQL Server и отсутствует в обычной установке. В этой таблице необходимо просмотреть значения в столбцах LastRunOn и LastRunSuccess по строке определенного задания, чтобы определить, было ли задание выполнено успешно или со сбоем.

Экспресс-выпуск SQL Server не использует службу Windows агента SQL Server. Вместо нее применяется посредник SQL Service Broker. В компоненте Service Broker имеется значение времени ожидания, равное интервалу выполнения, установленному для задания Microsoft_ApplicationServer_Monitoring_AutoPurge_<имя_БД_наблюдения>. При истечении этого времени в очередь заданий SQL Server отправляется сообщение. Оно активирует хранимую процедуру, которая запускается в рамках задания Microsoft_ApplicationServer_Monitoring_AutoPurge_<имя_БД_наблюдения>. В свою очередь это приводит к запуску функции автоматической очистки хранилища экспресс-выпуска SQL Server.

Ниже приведены некоторые запросы T-SQL, которые можно выполнить для отслеживания выполнения функции автоматической очистки хранилища.

  • Служит для показа запланированных в настоящее время заданий: SELECT * FROM ASJobsTable

  • Просматривает столбец dialog_timer (формат UTC), чтобы узнать время следующего запуска задания: SELECT * FROM sys.conversation_endpoints

  • Служит для отображения количества выполняемых в настоящее время процедур активации: SELECT * FROM sys.dm_broker_activated_tasks

  • Служит для обнаружения количества сообщений, находящихся в настоящее время в очереди. При отсутствии заданий возвращается значение 0: SELECT * FROM ASScheduledJobQueue

См. также

Другие ресурсы

Dashboard Page
Persisted WF Instances Page
Tracked WF Instances Page
Tracked Events Page

  2012-03-05