Share via

Обзор компонентов диагностики Windows Azure 1.4

  • Article

Дата публикации исходной статьи: среда, 24 августа 2011 г.

Использованию компонентов диагностики в Windows Azure посвящено множество статей и публикаций. Когда мне понадобилось изучить доступные возможности, это стало достаточно серьезной проблемой. Мне удалось найти множество статей, посвященных различным версиям Azure, в связи с чем на выявление функций, работающих с последней версией Azure SDK (1.4), потребовалось много времени. Надеюсь, в этой публикации мне удастся объединить основные рекомендации по использованию функций диагностики Azure с версией 1.4 пакета SDK.

 

Во-первых, как многим из вас уже известно, в состав платформы Azure входит встроенный прослушиватель трассировки, который сохраняет в памяти команды Trace.* (например, Trace.Write, Trace.WriteLine, Trace.TraceInformation и т. д.). Тем не менее, необходимо выполнить определенные действия, чтобы извлечь их из памяти в место постоянного хранения. Для этого можно выполнить перенос данных вручную или настроить расписание переноса. Кроме того, также можно перенести данные из журналов событий, IIS и пользовательских журналов, а также регистрировать значения счетчиков производительности.

 

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

 

Чтобы настроить компоненты диагностики, в том числе частоту записи данных в хранилище, объем выделяемого места для хранения, регистрируемые счетчики системного монитора и другие параметры, чаще всего удобнее добавлять код в файл WebRole.cs, который входит в состав стандартного приложения веб-роли Azure. Мне кажется, большинство компонентов Azure, за исключением роли виртуальной машины, используют элементы, аналогичные классу WebRole, как, например, файл WorkerRole.cs с проектом рабочей роли. Прежде чем перейти к изучению кода, необходимо открыть проект роли Azure и установить на вкладке "Конфигурация" флажок "Укажите учетные данные хранилища для результатов диагностики". С помощью кнопки выбора укажите учетную запись хранилища в Azure. Не используйте локальное развертывание. После этого новая строка подключения сохраняется в проекте Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString.

 

Рассмотрим весь фрагмент кода в классе веб-роли, обращая внимание на некоторые детали:

 

public override bool OnStart()

{

   // Сведения об обработке изменений конфигурации

   // см. в соответствующей теме MSDN на странице https://go.microsoft.com/fwlink/?LinkId=166357.

 

   try

   {

       //инициализация структуры настроек

                Microsoft.WindowsAzure.CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>

       {

          configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));

       });

 

       //получение учетной записи хранилища с помощью строки подключения для диагностики по умолчанию

       CloudStorageAccount cs =

          CloudStorageAccount.FromConfigurationSetting(

          "Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString");

 

       //получение диспетчера диагностики

       RoleInstanceDiagnosticManager dm = cs.CreateRoleInstanceDiagnosticManager(

          RoleEnvironment.DeploymentId,

          RoleEnvironment.CurrentRoleInstance.Role.Name,

          RoleEnvironment.CurrentRoleInstance.Id);

 

       //получение текущей конфигурации

       DiagnosticMonitorConfiguration dc = dm.GetCurrentConfiguration();

 

       //в случае сбоя получение значений из файла конфигурации

       if (dc == null)

          dc = DiagnosticMonitor.GetDefaultInitialConfiguration();

 

       //журналы Windows Azure

       dc.Logs.BufferQuotaInMB = 10;

       dc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;

       dc.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(5);

 

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

       dc.WindowsEventLog.BufferQuotaInMB = 10;

       dc.WindowsEventLog.DataSources.Add("System!*");

       dc.WindowsEventLog.DataSources.Add("Application!*");

       dc.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromMinutes(15);

 

       //счетчики производительности

       dc.PerformanceCounters.BufferQuotaInMB = 10;

       PerformanceCounterConfiguration perfConfig =

          new PerformanceCounterConfiguration();

       perfConfig.CounterSpecifier = @"\Processor(_Total)\% Processor Time";

       perfConfig.SampleRate = System.TimeSpan.FromSeconds(60);

      dc.PerformanceCounters.DataSources.Add(perfConfig);

       dc.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromMinutes(10);

 

       //журналы неудачно завершенных запросов

       dc.Directories.BufferQuotaInMB = 10;

       dc.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(30);

 

       //журналы инфраструктуры

       dc.DiagnosticInfrastructureLogs.BufferQuotaInMB = 10;

       dc.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter =

          LogLevel.Verbose;

       dc.DiagnosticInfrastructureLogs.ScheduledTransferPeriod =

          TimeSpan.FromMinutes(60);

 

       //дампы сбоев

       CrashDumps.EnableCollection(true);

 

       //величина квоты; должна быть больше суммы всех элементов

       dc.OverallQuotaInMB = 5000;

 

       //сохранение конфигурации

       dm.SetCurrentConfiguration(dc);

   }

   catch (Exception ex)

   {

       System.Diagnostics.Trace.Write(ex.Message);

   }

 

   return base.OnStart();

}

 

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

 

В журналах Windows Azure сохраняются все вызовы команд Trace.*. Я настроил хранение в таблице до 10 МБ данных с записью в хранилище всех элементов с уровнем ведения журнала "Подробный" и выше каждые 5 минут. Кстати, список таблиц и запросов, которые используются на платформе Windows Azure для хранения данных журналов, см. в статье https://msdn.microsoft.com/en-us/library/hh180875.aspx  и на странице https://msdn.microsoft.com/en-us/library/microsoft.windowsazure.diagnostics.diagnosticmonitorconfiguration.aspx. Журналы инфраструктуры и диагностики практически идентичны друг другу.

 

Для записей средства просмотра событий мне необходимо добавить каждый журнал, который требуется вести, в список DataSources класса WindowsEventLog. Поддерживаемые значения: Application!* , System!* и UserData!* . Другие свойства аналогичны описываемым для журналов Windows Azure.

 

Для счетчиков системного монитора необходимо описать счетчики, значения которых требуется регистрировать, а также частоту выборки данных. В приведенном выше примере добавлен счетчик загрузки ЦП с выборкой данных каждые 60 с.

 

Наконец, я включил дамп сбоев, изменил величину квоты для данных журналов до 5 ГБ и сохранил изменения. Крайне важно увеличить значение квоты, иначе будет возникать исключение, свидетельствующее о нехватке места для внесения описываемых выше изменений. В моем сценарии 5 ГБ будет достаточно, однако вы можете задавать собственные значения.

 

Итак, мы закончили настройку, и приложение готово к публикации. При публикации приложения из Visual Studio следует обратить внимание на пару моментов:

 

 

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

 

 

Здесь необходимо обратить внимание на следующие моменты:

  1. Вы можете использовать любой сертификат с PFX-файлом. Обратите внимание, что перед публикацией приложения ОБЯЗАТЕЛЬНО нужно загрузить этот сертификат в размещаемую службу.
  2. В поле "Имя пользователя" можно указывать любое имя. Будет создана локальная учетная запись с предоставленными именем и паролем.

 

Итак, вы завершили настройку в обоих диалоговых окнах и опубликовали приложение. Запустите приложение, чтобы проверить его работоспособность и правильность выполнения кода веб-роли. После этого в параметрах диагностики вы сможете убедиться, что ваши настройки применяются и отображаются. Примечание. Для управления платформой Azure я использую бесплатный набор средств CodePlex, который можно загрузить с сайта https://wapmmc.codeplex.com/):

 

 

После выполнения кода, когда наступает следующий запланированный период переноса журналов Windows Azure, вызовы Trace.* отображаются в таблице WADLogsTable, как показано ниже:

 

 

Кроме того, поскольку я настроил для приложения поддержку протокола удаленных рабочих столов, при выборе веб-роли для установления подключения удаленных рабочих столов она отображается в панели инструментов на портале разработчика Azure:

 

 

Итак, теперь мне доступны все журналы и трассировки моего приложения, а также возможность устанавливать подключения удаленных рабочих столов с серверами, которые требуется дополнительно исследовать. Также я включил полезную функцию IntelliSense. В этой статье я не буду описывать технологию IntelliSense. Более подробно вы можете ознакомиться с ней в следующей статье https://blogs.msdn.com/b/jnak/archive/2010/06/07/using-intellitrace-to-debug-windows-azure-cloud-services.aspx и на странице https://blogs.msdn.com/b/ianhu/archive/2010/03/16/intellitrace-what-we-collect.aspx. Если технология IntelliTrace включена, соответствующее уведомление отображается при просмотре моей размещаемой службы в обозревателе сервера Visual Studio:

 

 

Я могу щелкнуть экземпляр в приложении правой кнопкой мыши и выбрать команду меню "Просмотр журналов IntelliTrace". В этом случае журналы IntelliTrace загружаются из платформы Azure и открываются в Visual Studio следующим образом:

 

 

Как видно из этого рисунка, в журнале доступны сведения об используемых потоках, возникших исключениях, системе, загруженных модулях и т. д. Чтобы проверить ведение журнала, я смоделировал исключение, задав объем для хранения диагностических данных приложения равным 5 МБ. Как вы помните, я упоминал, что для хранения таких данных требуется около 5 ГБ. Внеся это изменение, я опубликовал приложение и через несколько минут загрузил журналы IntelliTrace. Вполне ожидаемо, на второй странице журналов я нашел соответствующую ошибку:

 

 

В этой статье приводится обзор компонентов диагностики в Windows Azure 1.4. Мы можем регистрировать события трассировки, журналы событий, значения счетчиков производительности, журналы IIS, дампы сбоев и любые другие настраиваемые журналы диагностики. При необходимости можно устанавливать подключение удаленного рабочего стола к серверу для расширенного устранения неполадок. Также я могу загрузить журналы IntelliTrace из приложения и выполнить отладку (возможности ограничены) в локальном экземпляре Visual Studio 2010.

Это локализованная запись блога. Исходная статья находится по адресу Windows Azure 1.4 Diagnostics All Up Overview