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 следующим образом:
В результате, в указанном каталоге будут сохранены журналы для всех экземпляров нашего приложения (в данном примере используется 4 экземпляра). Журналы сохраняются в текстовом виде и содержат точную копию информации, которая выводилась на экране эмулятора в ходе работы приложения. На следующем рисунке показано содержимое журнала, отображаемое утилитой Notepad. Как мы увидели выше, ошибки в коде можно «отлавливать» с помощью стандартных средств отладки, включенных в состав Visual Studio. Дополнительным инструментом для обнаружения ошибок связанных, например, с развертыванием приложений, является механизм IntelliTrace, доступный в Visual Studio 2010 Ultimate Edition. Использование IntelliTrace Механизм IntelliTrace поддерживается в Visual Studio 2010 Ultimate Edition. Он упрощает отладку кода, и позволят отображать события, которые происходили в приложении во время его выполнения именно в том контексте, в котором они происходили. Поддерживается список точек прерывания, которые были задействованы кодом отлаживаемого приложения, также полный контекст среды выполнения. Можно сконфигурировать события, которые будут записываться для каждой точки прерывания, сохранять дополнительные данные и значения, возвращаемые вызываемыми функциями. Для того, чтобы воспользоваться механизмом IntelliTrace для приложения, развернутого в Windows Azure, выполним следующие действия:
Используя механизм IntelliTrace, не забудьте включить отображение окон IntelliTrace Events и IntelliTrace Calls – для этого следует выполнить команду Debug | IntelliTrace. Окна отображаются в правой части экрана Visual Studio на вкладке IntelliTrace и позволяют просматривать списки событий (окно IntelliTrace Events) и вызовов функций (окно IntelliTrace Calls). Завершая наше знакомство с механизмом IntelliTrace отметим, что данный механизм должен использоваться только при отладке приложения или роли. Когда механизм IntelliTrace включен, приложение автоматически не перезапускается после сбоя. Это позволяет Windows Azure сохранять данные IntelliTrace, связанные со сбоем. В этом случае приложение или роль должны быть перезапущены вручную, через портал Windows Azure. Для практического освоения подходов к отладке Windows Azure-приложений можно выполнить виртуальную лабораторную работу – см. https://msdn.microsoft.com/en-us/gg712348. Удаленный доступ к виртуальной машине Мы уже рассматривали удаленный доступ к виртуальной машине, когда обсуждали процесс развертывания приложений (см. публикацию). С точки зрения отладки и нахождения ошибок удаленный доступ может быть полезен в тех случаях, когда нам нужно проверить версии компонентов приложения, запустить дополнительные диагностические механизмы, посмотреть содержимое дополнительных журналов и воспользоваться отладчиком WinDbg. Все перечисленные средства призваны помочь в тех случаях, когда возможности механизма IntelliTrace не позволяют однозначно понять причину сбоя и найти подходы к его исправлению. Итак, мы удаленно подключились к виртуальной машине, на которой выполняется один из экземпляров роли, включенной в состав нашего приложения. В отличие от механизма IntelliTrace, который позволяет собирать и получать данные от выбранного экземпляра роли и диагностической информации, собираемой и сохраняемой в Windows Azure Storage (см. материалы по диагностике и профилированию приложений), при удаленном подключении мы попадаем в один из экземпляров роли, «выбираемый» для нас средством балансировки нагрузки (load balancer) – т.е. у нас нет возможности подключиться к какому-то заранее определенному экземпляру. Виртуальная машина содержит три локальных диска:
Помимо изучения содержимого различных конфигурационных файлов, удаленный доступ к виртуальной машине позволяет использовать:
В данной публикации мы рассмотрели основные подходы к отладке Windows Azure-приложений – с помощью Visual Studio и локального эмулятора, с помощью механизма IntelliTrace и с помощью удаленного подключения к виртуальной машине. Комбинация этих подходов позволит эффективно отлаживать приложения и находить проблемы как при их развертывании, старте, так и при работе под управлением платформы Windows Azure. |