Windows Azure. Диагностика и профилирование приложений. Часть 1

Приложения, работающие на платформе Windows Azure, состоят из набора экземпляров различных ролей представляющих собой сервисы, доступные в режиме 24х7. Возможность слежения за работой сервисов является важной задачей как с точки зрения мониторинга использования ресурсов (что является важным, учитывая модели оплаты ресурсов в Windows Azure), так и обнаружения ошибок и сбоев.

При работе под управлением платформы Microsoft Windows, приложениям доступны различные диагностические инструменты, которые отражают статические характеристики этой среды – известно местонахождение сервера, его характеристики и настройки, данные коммуникационных каналов и т.п. Сервер доступен как физически, так и удаленно. Использование классов, включенных в пространство имен System. Diagnostics, позволяет создавать т.н. «измеряемые» приложения, а, например, использование блока Logging Application Block из Microsoft Enterprise Library позволяет расширить как источники диагностических данных, так и способы их сбора. Собираемые данные хранятся либо на сервере, либо выгружаются для обработки на компьютеры специалистов по разработки и сопровождению. Базовый уровень собираемых данных всегда может быть расширен за счет изменения соответствующих настроек.

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

Хорошей новостью является то, что платформа Windows Azure предоставляет практически те же средства диагностики, что и Windows Server – журналы событий, счетчики производительности и т.п., позволяет агрегировать данные в хранилище Windows Azure Storage и анализировать их привычными средствами. Ниже мы познакомимся с этими средствами и научимся использовать их для слежения за приложениями и потребляемыми ими ресурсами.

Windows Azure Diagnostic Monitor

Специальный компонент платформы Microsoft Windows Azure – Diagnostic Monitor позволяет собирать и агрегировать диагностические данные из различных экземпляров ролей, составляющих наше приложение. Классы из пространства имен System. Diagnostics могут использоваться для протоколирования и измерения характеристик приложения в Windows Azure точно так же, как мы делали для приложений, выполняющихся под управлением клиентской и серверной версии операционной системы Windows.

Во время старта экземпляра роли в Windows Azure запускается специальный процесс монитора диагностики (MonAgentHost. exe), который отделен от процесса, в котором выполняется экземпляр роли. Данный процесс предоставляет программные интерфейсы, которые могут использоваться внутри роли для управления им. Класс DiagnosticMonitor из пространства имен Microsoft. WindowsAzure. Diagnostics (библиотека microsoft.windowsazure.diagnostics.dll) используется для доступа к этим программным интерфейсам и позволяет сконфигурировать и запустить монитор диагностики. Конфигурация определяет, данные из каких источников собирать и когда их передавать в хранилище. После старта процесса данные для каждого экземпляра роли собираются в локальном каталоге роли. По умолчанию, для диагностических данных отводится порядка 4 Гбайт, но это значение можно изменить с помощью свойства OverallQuotaInMB класса DiagnosticMonitor. Также можно управлять размерами отдельных буферов, в которых собираются данные – для этого служит свойство BufferQuotaInMB класса DiagnosticMonitor. Когда объем данных превышает заданный, «старые» данные замещаются новыми. Данные сохраняются только при работе экземпляра роли – в случае перезапуска экземпляра или завершения его работы собранные данные теряются. Для сохранения диагностических данных следует сконфигурировать монитор диагностики таким образом, чтобы данные сохранялись в Windows Azure Storage – либо с заданными интервалами, либо по запросу. Работа монитора диагностики показана на следующей иллюстрации.

Рис. Работа монитора диагностики

Класс DiagnosticMonitor содержит два важных метода – GetDefaultInitialConfiguration и Start. Монитор диагностики содержит конфигурацию по умолчанию, которая позволяет собирать данные из журналов Windows Azure, IIS 7.0 и Windows Azure Diagnostic. Для изменения конфигурации по умолчанию и сбора большего количества данных следует вызвать метод GetDefaultInitialConfiguration, который возвращает экземпляр класса DiagnosticMonitorConfiguration. Метод Start инициализирует и запускает монитор диагностики. Перегруженный метод Start позволяет указать новую конфигурацию, заменяющую конфигурацию по умолчанию. Если монитор диагностики уже запущен, вызов метода Start переконфигурирует процесс с использованием новой конфигурации. Данные, собранные в рамках предыдущей конфигурации, сохраняются в буфере и передаются в Windows Azure Storage при активации механизма передачи данных (по запросу или по расписанию).

Источники диагностических данных

Подсистема диагностики в Windows Azure позволяет собирать данные из различных источников. Полный список источников зависит от типа роли (веб- или прикладная роль). Например, журналы IIS 7.0 не доступны в прикладных ролях, так как там нет IIS 7.0. В следующей таблице показаны различные источники данных, типы ролей, в которых они доступны и способы их хранения.

Ниже мы рассмотрим каждый источник данных более подробно. Начнем с журналов Windows Azure (Windows Azure Logs).

Журналы Windows Azure

Журналы Windows Azure содержат специфичную для приложения диагностическую информацию, создаваемую на основе трассировочных событий в приложении. Для того, чтобы инфраструктура Windows Azure могла получать данные от этих событий, приложение должно использовать соответствующие механизмы трассировки (trace listeners). Класс DiagnosticMonitorTraceListener в пространстве имен Microsoft. WindowsAzure. Diagnostics должен быть добавлен к списку механизмов трассировки в файле web. config (для веб-роли) или app. config (для прикладной роли). Ниже показано содержимое файла web. config с использованиемDiagnosticMonitorTraceListener:

Второй способ добавления источников данных к списку механизмов трассировки – это использование метода System. Diagnostics. Trace. Listeners. Add.

Когда приложение генерирует трассировочные данные, они обрабатываются соответствующим механизмом трассировки и попадают в буфер. По умолчанию, монитор диагностики собирает данные из журналов Windows Azure Logs. Тем не менее, для сохранения данных нужно добавить к приложению соответствующий код (об этом - ниже). Когда данные передаются из буфера, они сохраняются в таблице Windows Azure Storage, которая имеет название WADLogsTable. Эта таблица имеет следующие свойства:

• PartitionKey
• RowKey
• Timestamp
• EventTickCount
• DeploymentId
• Role
• RoleInstance
• Level
• EventId
• Pid
• Tid
• Message

Класс Trace из пространства имен System. Diagnostics содержит ряд методов, позволяющих записывать в механизм трассировки различные типы сообщений. К таким методам относятся методы Write, WriteIf, WriteLine и WriteLineIf. Значение, передаваемое этим методам, заносится в таблицу WADLogsTable в свойство Message. При записи, значение комбинируется с категорией сообщения. Например,

Trace.WriteLine(“”“Трассировочное сообщение”, “General”);

будет сохранено в таблице WADLogsTable как «General: Трассировочное сообщение». Группа трассировочных методов также включает методы TraceInformation, TraceWarning,TraceError и Fail. Эти методы позволяют указывать тип события – информация, предупреждение, ошибка сбой, а также уровень сообщения для каждого типа. В следующей таблице показано соответствие методов и типов событий.

Выше мы рассмотрели журналы Windows Azure (Windows Azure Logs). Следующий источник данных – журналы IIS 7.0.

Журналы IIS 7.0

Журналы IIS 7.0 представляют собой запросы к IIS, обрабатываемые соответствующим процессом. Файлы журналов сохраняются в каталоге %SystemDrive%\inetpub\logs\LogFiles на локальном диске каждого экземпляра роли. Для веб-ролей ведение журнала для IIS включено по умолчанию. Тем не менее, необходимо убедиться в том, что монитор диагностики сконфигурирован для того, чтобы собирать информацию в каталогах. Для того, чтобы это сделать, необходимо задать соответствующий интервал через свойство TimeSpan метода ScheduledTransferPeriod. Если интервал не задан, информацию можно передавать по запросу. Ниже показан пример установки значения свойства TimeSpan.

var conf = DiagnosticMonitor.GetDefaultInitialConfiguration();

conf.Directories.ScheduledTransferPeriod = TimeSpan.FromSeconds(10);

Когда Windows Azure передает журналы IIS, файлы загружаются в контейнер для хранения бинарных объектов wad-iis-logfiles. Для просмотра самих файлов следует использовать утилиты, позволяющие загружать и отображать бинарные объекты из хранилища Windows Azure Storage. Одной из таких утилит является утилита Blob Container Viewer, входящая в состав Windows Azure Tools for Microsoft Visual Studio.

Инфраструктурные журналы Windows Azure

Инфраструктурные журналы Windows Azure содержат диагностические данные, специфичные для Windows Azure, которые собираются автоматически. Эти данные хранятся в таблице WADDiagnosticInfrastructureLogsTable и представляют собой события (информация и ошибки), относящиеся к развертыванию приложений. Данные, хранимые в этом журнале, следует использовать при решении проблем, связанных с развертыванием приложений и нахождения ошибок, возникающих на уровне инфраструктуры.

Журналы запросов со сбоями

Журналы запросов со сбоями (Failed Request Logs) не заполняются по умолчанию и должны быть включены путем указания соответствующих опций трассировки в файле web. config приложения. Журналы запросов со сбоями сохраняются в контейнере для хранения бинарных объектов wad- iis- failedreqlogfiles. Создание трассировки для запросов со сбоями является функцией IIS 7, позволяющей буферизовать трассировочные события для запросов. Если запрос завершился с ошибкой, информация об этом сохраняется в журнале невыполненных запросов. Поддерживается возможность конфигурации сохраняемых данных. Например, можно задать диапазон кодов статуса HTTP (HTTP Status Code), которые означают запрос со сбоем, например, 400-599. Любой запрос, отвечающий заданному критерию, будет считаться запросом со сбоем и информация о нем будет занесена в соответствующий журнал. Также можно задать длительность времени, по истечении которой необработанный запрос будет считаться сбоем. Ниже показан пример конфигурации, активизирующей сбор информации о запросах со сбоями – в данном примере сбоями считаются запросы, не обработанные в течение 10 сек., а также запросы с кодами статуса в диапазоне от 400 до 599.

Журнал событий Windows

В Windows Azure поддерживается возможность создания и ведения журнала событий Windows. События Windows содержат важную информацию о состоянии приложения и самой системы. Это означает, что можно сконфигурировать приложение таким образом, что будут собираться данные не только о самом приложении, но и об экземпляре, в котором оно работает. События Windows должны использоваться для записи важных событий на уровне приложения. Если требуется сбор информации о выполнении каких-то этапов приложения, методов и т.п. следует использовать события группы Trace и журнал Windows Azure. Для того, чтобы активизировать журнал событий Windows, следует соответствующим образом сконфигурировать монитор диагностики. Ниже показано, как это сделать.

var conf = DiagnosticMonitor.GetDefaultInitialConfiguration();

conf.WindowsEventLog.DataSources.Add(“Application!*[System [Provider [@Name=’WebRole’]]] ”);

conf.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromSeconds(10);

conf.WindowsEventLog.ScheduledTransferLogLevelFilter = LogLevel.Undefined;

В приведенном выше примере монитор диагностики конфигурируется таким образом, чтобы собирать данные из канала Application для провайдера WebRole. Наиболее простой способ для создания строки, требуемой для метода Add (с указанием канала, провайдера, XPath-запроса и т.п.) – это использование Windows Event Viewer ( %windir%\system32\eventvwr.msc /s). В этой системной утилите мы выбираем режим Create Custom View (панель Actions) и копируем строку из XML-представления (вкладка XML). Как это сделать показано на двух следующих иллюстрациях.

Журнал счетчиков производительности

Windows Azure поддерживаются счетчики производительности. Они не активированы по умолчанию и требуется указать, какие счетчики следует использовать для сбора данных. Счетчики следует использовать для сбора информации о производительности приложения, использовании ресурсов и т.п. Можно сконфигурировать монитор диагностики для сбора данных как от стандартных счетчиков Windows, так и от собственных счетчиков производительности. Ниже показано, как сконфигурировать монитор производительности, чтобы собирать данные от счетчика Process % Time.

configuration.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration

{

  CounterSpecifier = @”\Processor (_Total)\% Processor Time”,

  SampleRate = TimeSpace.FromSeconds(30)

}

);

conf.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromSeconds(60);

Для создания собственного счетчика необходимо написать приложение (или скрипт на PowerShell), создающее такой счетчик и использовать стартовые задачи для задания приложению необходимых привилегий для регистрации счетчика.

Дампы сбоев

Для включения сбора дампов сбоев следует использовать метод CrashDumps. EnableCollection с параметром true, который позволяет собирать либо мини-, либо полные дампы сбоев. Файлы могут сохраняться либо по расписанию, либо по запросу. Для открытия файлов с дампами сбоев следует использовать специализированные утилиты, например, отладчик WinDbg.

Пользовательские журналы

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

В следующем примере показано, как сконфигурировать файлы внутри локального хранилища CustomLogs таким образом, чтобы они включались в список мест, из которых Windows Azure собирает и выгружает данные.

var res = RoleEnvironment.GetLocalResource(“CustomLogs”);

var dirConf = new DirectoryConfiguration

{

  Container = “wad-customlogs-container”,

  DirectoryQuotaInMB = res.MaximumSizeInMegabytes,

  Path = res.RootPath

};

conf.Directories.DataSources.Add(dirConf);

В следующей части мы обсудим использование монитора диагностики, способы изменения настроек, настройку передачи данных и подходы к обработке диагностических данных.

/АФ