Windows Azure. Отладка приложений

В серии предыдущих публикаций мы познакомились с подходами к диагностике и профилированию приложений. Средства, предоставляемые Widows Azure для сбора и хранения диагностической информации, могут использоваться как при диагностике неисправностей и сбоев при работе приложений в среде Widows Azure, так и при их отладке. Средства профилирования следует использовать при настройке приложений – для поиска наиболее «дорогих» с точки зрения использования ресурсов участков кода, для оптимизации работы с памятью, процессами и т.п.

Собственно подходы к отладке Widows Azure-приложений можно разделить на три части – отладка приложения под локальным эмулятором, использование механизма IntelliTrace, доступного в Visual Studio 2010 Ultimate Edition для сбора отладочной и трассировочной информации от приложения, работающего уже в среде Widows Azure и удаленный доступ к виртуальной машине, на которой выполняется экземпляр роли. Начнем с отладки приложения под локальным эмулятором.

Отладка при работе под эмулятором

При использовании Visual Studio, походы к отладке Windows Azure-приложений в целом не отличаются от подходов к отладке традиционных приложений. Практически единственным отличием является то, что при локальной отладке приложений не следует использовать не методы Debug. WriteLine или Console. WriteLine для вывода отладочной информации. Вместо этого мы используем метод Trace. Write (или другие методы класса Trace) для записи информации через монитор диагностики (Diagnostic Monitor), представленный типом DiagnosticMonitorTraceListener. При создании «облачного» проекта Visual Studio автоматически добавляет конфигурационный файл для каждой роли. В нем, в частности, добавляется класс Diagnostic Monitor Trace Listener как это показано для веб-роли (файл Web.config) на следующем рисунке.

После того как класс Diagnostic Monitor Trace Listener описан и добавлен, мы можем использовать методы класса System. Diagnostics. Trace для отображения трассировочной и отладочной информации. Например, для отображения информации об идентификаторе запущенного экземпляра приложения мы можем вставить следующий код:

Результат работы данного кода, отображаемый в локальном эмуляторе Windows Azure, показан ниже.

Так как мы используем стандартные средства вывода трассировочной и отладочной информации, мы можем увидеть результат работы нашего кода и в окне Output в Visual Studio.

Как и для «традиционных» приложений нам доступны точки прерывания (break points), отображение стека вызова и другие отладочные инструменты.

Для сохранения информации из буферов монитора диагностики в локальном каталоге можно использовать утилиту csrun с опцией dumplogs. В качестве параметров указывается номер развертывания под локальным эмулятором и имя локального каталога, в котором будут сохранены данные (каталог должен существовать). Номер развертывания может быть получен в локальном эмуляторе – необходимо выбрать и раскрыть содержимое элемента «Service Deployments» и посмотреть номер, следующий за «deployment» - в нашем примере это номер 14.

Мы вызываем утилиту csrun следующим образом:

c:\>csrun /dumplogs:14;c:\wa_logs

В результате, в указанном каталоге будут сохранены журналы для всех экземпляров нашего приложения (в данном примере используется 4 экземпляра). Журналы сохраняются в текстовом виде и содержат точную копию информации, которая выводилась на экране эмулятора в ходе работы приложения.

На следующем рисунке показано содержимое журнала, отображаемое утилитой Notepad.

Как мы увидели выше, ошибки в коде можно «отлавливать» с помощью стандартных средств отладки, включенных в состав Visual Studio. Дополнительным инструментом для обнаружения ошибок связанных, например, с развертыванием приложений, является механизм IntelliTrace, доступный в Visual Studio 2010 Ultimate Edition.

Использование IntelliTrace

Механизм IntelliTrace поддерживается в Visual Studio 2010 Ultimate Edition. Он упрощает отладку кода, и позволят отображать события, которые происходили в приложении во время его выполнения именно в том контексте, в котором они происходили. Поддерживается список точек прерывания, которые были задействованы кодом отлаживаемого приложения, также полный контекст среды выполнения. Можно сконфигурировать события, которые будут записываться для каждой точки прерывания, сохранять дополнительные данные и значения, возвращаемые вызываемыми функциями. Для того, чтобы воспользоваться механизмом IntelliTrace для приложения, развернутого в Windows Azure, выполним следующие действия:

• После завершения создания и тестирования приложения под локальным эмулятором, выберем название проекта в Solution Explorer, нажмем правую кнопку «мыши» и выберем команду Publish

• В диалоговой панели Publish Windows Azure Application укажем данные, требуемые для развертывания приложения в Windows Azure
• В нижней части диалоговой панели, в группе Debug settings выберем опцию Enable IntelliTrace for . NET 4

• Нажмем ссылку Settings для настройки механизма IntelliTrace. Панель IntelliTrace Settings содержит ряд вкладок – General, Modules, Processes, IntelliTrace Events и Advanced.

• На вкладке General можно выбрать одну из следующих опций - “IntelliTrace events only” или “IntelliTrace events and call Information” – первая указывает на сбор информации только о событиях, вторая (включенная по умолчанию) – о событиях, стеке вызовов и значениях переменных.

• На вкладке Modules выбираем либо все модули за исключением перечисленных в списке, либо только модули, перечисленные в списке (плюс, возможно, добавленные нами модули). Информация будет собираться только для выбранных модулей

• На вкладке Processes выбираем либо все процессы за исключением перечисленных в списке, либо только процессы, перечисленные в списке (плюс, возможно, добавленные нами процессов). Информация будет собираться только для выбранных процессов

• На вкладке Events выбираем события, информация о которых будет собираться для нашего приложения. Поддерживается возможность как выбора или отмены группы событий, так и отдельных событий внутри группы

• На вкладке Advanced можно задать максимальный размер дискового пространства, который будет использоваться механизмом IntelliTrace. По умолчанию – это 250 Мбайт. Минимальное значение – 100 Мбайт, максимальное – 20 Гбайт. Есть опция для отмены ограничения. Выбираемый размер дискового пространства зависит от ряда факторов, например, от общего объема локального хранилища для экземпляра роли, других функций, использующих локальное хранилище и т.п.

• После этого закроем панель IntelliTrace Settings и нажмем кнопку Publish для публикации приложения в Windows Azure.
• После завершения развертывания и начала выполнения приложения, открываем Server Explorer, раскрываем элемент Windows Azure Compute для отображения доступных сервисов

• В списке сервисов в элементе Windows Azure Compute мы увидим слово IntelliTrace в именах сервисов, для которых был включен этот механизм. Если раскрыть элемент сервиса, мы увидим список ролей, а в нем - список экземпляров каждой роли. Иконка рядом с названием экземпляра показывает его состояние – выполняется, на паузе или остановлен
• Нажмем правую кнопку «мыши» на экземпляре сервиса, для которого включен механизм IntelliTrace и выберем команду View IntelliTrace Logs. Это приведет к загрузке данных и их отображению в окне Visual Studio

• Страница IntelliTrace Summary содержит список используемых потоков, список исключений, системную информацию и список загруженных модулей

• Нажатие кнопки Start Debugging (или двойной щелчок мышью по имени потока) приводит к открытию окна, в котором можно просматривать стек вызовов
• На вкладке Exception Data отображаются данные об исключениях – здесь также есть кнопка кнопки Start Debugging, отображающая соответствующие данные

• Вкладка System Info отображает различную системную информацию, полученную от виртуальной машины, в которой выполняется данный экземпляр роли
• Вкладка Modules показывает список загруженных модулей

Используя механизм IntelliTrace, не забудьте включить отображение окон IntelliTrace Events и IntelliTrace Calls – для этого следует выполнить команду Debug | IntelliTrace.

Окна отображаются в правой части экрана Visual Studio на вкладке IntelliTrace и позволяют просматривать списки событий (окно IntelliTrace Events) и вызовов функций (окно IntelliTrace Calls).

Завершая наше знакомство с механизмом IntelliTrace отметим, что данный механизм должен использоваться только при отладке приложения или роли. Когда механизм IntelliTrace включен, приложение автоматически не перезапускается после сбоя. Это позволяет Windows Azure сохранять данные IntelliTrace, связанные со сбоем. В этом случае приложение или роль должны быть перезапущены вручную, через портал Windows Azure.

Для практического освоения подходов к отладке Windows Azure-приложений можно выполнить виртуальную лабораторную работу – см. http://msdn.microsoft.com/en-us/gg712348.

Удаленный доступ к виртуальной машине

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

Итак, мы удаленно подключились к виртуальной машине, на которой выполняется один из экземпляров роли, включенной в состав нашего приложения. В отличие от механизма IntelliTrace, который позволяет собирать и получать данные от выбранного экземпляра роли и диагностической информации, собираемой и сохраняемой в Windows Azure Storage (см. материалы по диагностике и профилированию приложений), при удаленном подключении мы попадаем в один из экземпляров роли, «выбираемый» для нас средством балансировки нагрузки (load balancer) – т.е. у нас нет возможности подключиться к какому-то заранее определенному экземпляру.

Виртуальная машина содержит три локальных диска:

• На диске C: располагаются файлы журналов и папки LocalResource
  • КаталогC:\ Config – информация о конфигурации сервиса. Содержит два файла:
    • Файл <GUID>.WebRole1_IN_0.xml
    • Важная информация:
      • Имя развертывания (Deployment name)
      • Имя сервиса (Service Name)
      • Данные из cscfg-файла (Application Settings)
      • Ссылки на локальные ресурсы (Resource References)
      • IP-адреса, адреса точек входа, порты и т.п.
    • Файл <GUID>.ccf – идентификатор контейнера развертывания
  • Каталог C:\ Logs – журналы агента Windows Azure
    • Файл AppAgentRuntime
      • Протокол запуска агента
    • Файл WaAppAgent
      • Протокол настроек – IPConfig, роутеры и т.п.
  • Каталог C:\Resources
    • Directory\<GUID>.RoleName
      • Дампы сбоев (папка CrashDumps)
      • Конфигурация монитора диагностики и содержимое журналов диагностики
    • Temp\<GUID>.RoleName\RoleTemp
      • Протокол запуска хост-приложения
        • WaHostBootstrapper – для прикладной роли
        • WaHostBootstrapper, IISConfigurator и WaIISHost для веб-роли
• На диске D: находится операционная система (% SystemRoot% , % SystemDrive% и т.п.), а также журналы монитора диагностики
• На диске E: располагается распакованный пакет развертывания, представляющий приложение, выполняющееся на данной виртуальной машине
  • Файл _ entrypoint. txt – название точки входа для вызова из хост-процесса
  • Файл < GUID>. csman – манифест пакета развертывания со списком всех файлов, входящих в пакет
  • Каталог E:\ Approot содержит код приложения
  • Каталог E:\ Base\ x64 содержит хост-процесс, который выполняет пользовательское приложение

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

• Отладчик
  • WinDbg и его вспомогательные отладчики, используемые в зависимости от сценария отладки
• Средство просмотра событий (eventvwr)
  • Можно изучать системные события, возникающие в процессе работы приложения
• Средство измерения производительности (perfmon)
  • Поддерживается создание новых счетчиков
• При необходимости, можно перезапустить роль, принудительно завершив работу хост-процесса (WaWebHost. exe для веб-роли и WaWorkerHost. exe для прикладной роли)
• Для обнаружения проблем при старте роли можно подключиться к соответствующему хост-процессу в отладчике и перезапустить процесс
• Локальное подключение к экземпляру роли через Internet Explorer с указанием «реального» адреса, полученного после изучения конфигурационных файлов, позволит увидеть ошибки на уровне ASP и ASP.NET, исключить проблемы, связанные с коммуникационным каналом и т.п.

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

/АФ