Экспорт (0) Печать
Развернуть все

Рекомендации по устранению неполадок при разработке приложений Azure

Обновлено: Ноябрь 2014 г.

Автор: Уильям Беллами (William Bellamy), главный специалист по эскалации запросов в Майкрософт

Соавторы:

  • Брайан Ламос (Bryan Lamos), старший руководитель программы Майкрософт по качеству продукции

  • Кевин Уильямсон (Kevin Williamson), старший специалист по эскалации запросов в Майкрософт, служба поддержки Azure

  • Пранай Доши (Pranay Doshi), старший руководитель программы Майкрософт, служба поддержки Azure

  • Том Кристиан (Tom Christian), старший специалист по эскалации запросов в Майкрософт, служба поддержки по Azure

Дата публикации: Январь 2012 г.

Основной приоритет корпорации Майкрософт — помочь клиентам Azure поддерживать работоспособность их приложений. Соглашения об уровне обслуживания Azure определяют доступность внешних соединений на уровне 99,95 % при развертывании двух или более экземпляров роли. Однако доступность внешних соединений означает, что пользователь может обращаться к приложению извне центров обработки данных Майкрософт, а не просто тот факт, что "сайт работает". У большей части служб Azure имеются зависимости: SQL Azure, Caching, сеть доставки содержимого, внутренние ресурсы (через Azure Connect) и т. д. Сбой в одном из зависимых компонентов может привести к неправильной работе службы Azure.

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

Этот документ предназначен для технических специалистов по программному обеспечению: разработчиков программного обеспечения, архитекторов, ИТ-специалистов, системных интеграторов, разработчиков и тестировщиков, занимающихся проектированием, построением и развертывание решений Azure.

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

Также подразумевается, что вы будете соблюдать базовые рекомендации по работе с Azure, касающиеся, например, использования последней версии Azure SDK и тестирования изменений кода перед их включением в рабочую версию.

Этот документ состоит из двух разделов.

  • Обзор диагностических ресурсов Azure

    • Ресурсы Azure

    • Сторонние ресурсы

  • Рекомендации по оптимизации проектирования, разработки и развертывания

    • Перед развертыванием приложения.

    • Проектирование и мониторинг без сбоев

    • Что делать, если возникла проблема.

Любой разработчик ожидает надлежащей работы своего продукта после его выпуска. Мы прилагаем все возможные усилия по тестированию кода на стадии разработки, чтобы обеспечить его безошибочную работу, одновременно работая уже над следующим проектом. К сожалению, в коде нередко обнаруживаются неполадки. В распределенной среде даже незначительные ошибки могут привести к катастрофическим последствиям из-за сложностей, связанных с разделением компонентов приложений. Именно поэтому с самого начала необходимо разрабатывать стратегию ведения журналов и отслеживания в приложении. В идеальном случае такая стратегия должна включать динамическую настройку без необходимости повторной сборки/развертывания типа и объема журналов на уровне компонентов. Больше объемы журналов не всегда гарантируют быстрое разрешение проблемы. Больше - не значит лучше. Большой объем данных требует больше времени на обработку и может снизить производительность приложения. Настраиваемое ведение журналов позволяет регулировать размер и стоимость хранения данных в журналах.

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

Чтобы получить максимальный объем сведений об ошибке, рекомендуется использовать отладочную сборку во время разработки. Программисты, как правило, добавляют отладочные операторы и некоторый способ записи ошибок в журнал. Проблема заключается в том, что такие отладочные операторы удаляются из рабочей сборки, поэтому при возникновении неполадки мы сталкиваемся с неприятностями. Клиентам, разумеется, вряд ли придется по вкусу необходимость повторного развертывания отладочной сборки для разрешения проблемы, возникшей в рабочем варианте. Майк Келли выделяет четыре типа диагностических выходных данных, которые должны настраиваться разработчиками.

  • Отладочные выходные данные — операторы Assert присутствуют только в отладочной сборке

  • Трассировка — отслеживает ход управления во время выполнения

  • Журналы событий — наиболее значимые события

  • Журналы ошибок — исключительная или опасная ситуация

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

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

Перед тем как обращаться к Azure, изучим действующие правила устранения неполадок при работе с приложениями Windows Server. Разработчики, как правило, просматривают журналы при возникновении проблемы в рабочей версии продукта. Журналы событий и журналы IIS включены по умолчанию и сохраняются при перезагрузке (если не произошел сбой жесткого диска).

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

Первоначальный Azure SDK 1.0 содержал функции сбора диагностических данных и их сохранения в хранилище Azure под общим названием Azure Diagnostics (WAD). Это программное обеспечение, основанное на структуре трассировки событий для Windows (ETW), отвечает двум требованиями проектирования, обусловленным архитектурой масштабирования Azure.

  1. Сохранение диагностических данных, которые могут быть утеряны при повторном развертывании образа экземпляра.

  2. Предоставление центрального репозитория данных диагностики из нескольких источников.

Пространство имен Microsoft.WindowsAzure.Diagnostic расширяет пространство имен System.Diagnostics, что позволяет использовать технологию ETW в приложении Azure.

Windows Azure — схема потока данных диагностики

После включения в роль средств диагностики Azure (ServiceConfiguration.cscfg и ServiceDefinition.csdef) WAD осуществляет сбор диагностических данных из всех экземпляров данной конкретной роли. Диагностические данные могут использоваться для отладки и устранения неполадок, измерения производительности, мониторинга использования ресурсов, анализа трафика, планирования емкости и аудита. Передача данных в учетную запись хранения Azure может быть запланированной или осуществляться при необходимости.

Azure Diagnostics вносит четыре важных изменения в правила работы с серверами.

  1. Средства диагностики должны быть включены во время создания приложения.

  2. Требуются определенные средства и шаги для визуализации результатов диагностики.

  3. Сбои системы приводят к потере данных диагностики, если они не были записаны в надежное хранилище (хранилище Azure, вместо хранения в каждом экземпляре).

  4. Хранилище диагностических данных требует ежемесячной оплаты, если данные располагаются в хранилище Azure.

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

  1. Убедитесь, что учетная запись хранения находится в том же центре обработки данных, что и ваше приложение. Если по некоторой причине они находятся в разных центрах обработки данных, выберите оптимальный интервал плановой передачи данных. Чем меньше интервал передачи данных, тем выше их релевантность, однако при этом также увеличивается требуемая пропускная способность и вычислительные ресурсы. По этой причине следует найти оптимальное соотношение.

  2. Периодически копируйте диагностические данные из хранилища Azure и после копирования удаляйте их из него. Диагностические данные будут проходить через хранилище Azure, но не будут без надобности в нем оставаться. Для реализации этого процесса существует ряд средств. System Center Monitoring Pack для Azure, Cerebrata Azure Diagnostics Manager и командлеты Azure PowerShell.

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

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

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

Хранилище Azure — это базовая функция для любого поддерживаемого приложения. В идеальном случае, данная функция должна быть настроена и активна в каждом приложении.

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

Ключом к написанию кода SQL Azure с возможностью поддержки является проверка кодов возврата и наличие надлежащего кода повтора для обработки сбоев.

Этот пакет мониторинга позволяет использовать Microsoft System Center Operations Manager для мониторинга доступности и производительности приложений Azure. Он предоставляет следующие возможности:

  • Обнаружение приложений Azure.

  • Отображает состояние каждого экземпляра роли.

  • Осуществляет сбор и мониторинг данных о производительности.

  • Осуществляет сбор и мониторинг событий Windows.

  • Осуществляет сбор и мониторинг трассировочных сообщений .NET Framework из каждого экземпляра роли.

  • Подготовка трассировочных данных производительности, событий и .NET Framework из учетной записи Azure.

  • Изменяет количество экземпляров роли.

Использование Microsoft System Center Operations Manager 2007 - самый лучший способ мониторинга состояния работоспособности приложения Azure.

На сегодняшний день Azure не предоставляет клиентам полноценное решение для мониторинга и управления размещенными службами. Сведения о сети можно получить на сайте speedtest.net, который измеряет время отклика, полосу пропускания и общее качество соединения. Задержки между различными информационными центрами Майкрософт могут быть определены с помощью средства Azure Statistics, разработанным Мэтью Розофф (Matthew Rosoff). При работе с Azure очень полезны определенные инструменты. Список, представленный ниже, не является одобрением или рекомендацией к использованию какого-либо стороннего средства.

Командлеты PowerShell Azure

Самый лучший способ удаленного управления диагностикой заключается в использовании командлетов PowerShell для Azure . Командлеты основаны на интерфейсах API управления и диагностики Azure, а полный исходный код, который можно получить из проекта CodePlex, позволяет получить подробное представление об этих API. В выпуске версии 2.0 можно настраивать/загружать/удалять все элементы диагностики Azure. В блоге Майкла Уошема (Michael Washam) приведены несколько интересных примеров сценариев.

Мониторинг сети: AlertBot, Gomez, Keynote, Pingdom

Compuware Gomez Application Performance Management, Keynote, Pingdom и AlertBot являются решениями для внешнего мониторинга приложения Azure. Они позволяют осуществлять мониторинг доступности приложения и оптимизировать производительность. Некоторые службы, такие как Pingdom, поддерживают уведомления по электронной почте, SMS или через средство уведомления на рабочем столе в случае возникновения ошибки. При таком мониторинге происходит моделирование того, какие действия совершает пользователь для успешного мониторинга, так как иногда веб-роль отображает домашнюю страницу, не будучи полностью функционирующей.

Azure Check

Apica AzureCheck представляет собой средство, осуществляющее мониторинг веб-приложения Azure "извне". Для использования этого средства необходимо загрузить его код и добавить его в развертывание в виде задачи запуска. Преимущество этого средства заключается в том, что оно не требует хранения журналов в учетной записи хранения, что снижает затраты на мониторинг.

Azure Diagnostics Manager

Cerebrata Azure Diagnostic Manager представляет собой клиент Windows для управления Azure Diagnostics. Он отображает или загружает журналы, собранные WAD. Вы также можете управлять конфигурацией WAD, а панель мониторинга позволяет отслеживать производительность в реальном времени.

Обозреватели хранилищ Azure

Существует несколько способов просмотра хранилища Azure. Группа разработчиков хранилища Azure сформировала список обозревателей хранилища. Любой из них позволяет просматривать файлы WAD и файлы аналитики хранения Azure. Cloudberry Lab Explorer для Blob-хранилища Azure представляет собой пользовательский интерфейс, позволяющий получать данные аналитики хранения непосредственно в приложении, нажав кнопку Параметры хранения.

IntelliTrace

Microsoft Visual Studio 2010 Ultimate содержит средство IntelliTrace, с помощью которого можно выполнять отладку приложений перед развертыванием в рабочей среде. IntelliTrace поддерживает ASP.NET и приложения WCF. Средство Intellitrace не поддерживается, если оно включено в рабочей службе, однако оно может использоваться для получения исключений приложения после развертывания в Azure. В блоге Джима Накашима (Jim Nakashima) описывается использование IntelliTrace для отладки облачных служб Azure.

AVIcode

Средство AVIcode было приобретено корпорацией Майкрософт и теперь является частью Microsoft System Center. AVIcode предоставляет возможности мониторинга производительности приложений .NET с полноценным набором функций мониторинга.

Fiddler

Fiddler — это средство интернет-отладки, регистрирующее весь трафик HTTP(S) между вашим компьютером и Интернетом. Fiddler позволяет проверять трафик, устанавливать точки останова и "исследовать" входящие и исходящие данные. Fiddler в особенности полезен для устранения неполадок хранилищ Azure.

Для использования Fiddler в локальной среде разработки следует применять ipv4.fiddler вместо 127.0.0.1.

  1. Запустите Fiddler.

  2. Запустите службу в среде разработки.

  3. Перейдите в http://ipv4.fiddler:/. Fiddler должен отследить запрос.

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

  1. Откройте файл ServiceConfiguration.cscfg и измените строку подключения следующим образом:

    Value=“UseDevelopmentStorage=true;DevelopmentStorageProxyUri=http://ipv4.fiddler”

  2. Запустите Fiddler.

  3. Запустите службу. Fiddler должен отслеживать любые запросы хранилища.

Профилирование производительности

Можно профилировать приложение Azure, когда оно работает в Azure, чтобы определить какие-либо проблемы с производительностью. При публикации приложения Azure из Visual Studio, можно решить профилировать приложение и выбрать нужные параметры профилирования.

Помощник ВМ Azure

Средство VM Assitant представляет собой проект CodePlex, ускоряющий диагностику проблем посредством сбора всех релевантных данных в одном месте при подключении к экземпляру через удаленный рабочий стол. Кнопка VM Health отображает текущее состояние экземпляра.

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

Фундаментальное отличие от традиционного серверного развертывания заключается в отсутствии доступа к оборудованию сервера. В Azure SDK 1.3 появилась возможность использования служб удаленного рабочего стола для доступа к ролям Azure. Эффективнее всего использовать самую последнюю версию SDK. Первым обязательным шагом при создании поддерживаемой службы Azure является включение удаленного рабочего стола. Этот шаг может быть выполнен только перед развертыванием.

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

При нажатии кнопки Настройка на портале с целью изменения любого из этих трех параметров, как правило, отображается следующая последовательность сообщений: "Обновление...", "Ожидание узла...", "Роль была успешно обновлена". "Ожидание узла...", "Готово". Это соответствует роли, получающей событие и затем обрабатывающей его. Клиенты могут подписаться на события RoleEnvironment, тогда при получении события RoleEnvironment.Changing: можно принять изменения и продолжить выполнение (по умолчанию) или перевести экземпляр в автономный режим, затем принять изменения и перейти в оперативный режим (e.Cancel = true).

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

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

Windows Azure — диалоговые окна подключения к удаленному рабочему столу

Устранение неполадок ВМ

Теперь, установив подключение к экземпляру, что следует искать? Если устранение неполадок происходит в отношении роли, которую не удается запустить, изучите эту статью MSDN. У Кевина Уильямсона (Kevin Williamson) есть очень интересная статья, в которой проводится обзор мест расположения файлов журнала и процессов отладки.

Вы также можете установить VM Assistant для просмотра файлов журнала и получения полезной информации об экземпляре. Вы также можете установить средства, такие как Network Monitor или Fiddler, чтобы выяснить, что происходит в сети. Один из простейших тестов заключается в запуске Internet Explorer на экземпляре и подключении к веб-сайту, так как при этом будут показаны сведения об исключении.

Отладка размещенного веб-ядра

Если вы используете роль размещенного веб-ядра, на виртуальной машине доступно только одно командное окно, поэтому необходимо открыть новое окно Cmd командой start из командной строки, в противном случае отобразится полноценный интерфейс Windows Server. Ниже приведены некоторые основные команды.

  • Start — открывает новое окно Cmd

  • explorer — открывает проводник Windows

  • eventvwr — открывает средство просмотра журнала событий

  • taskmgr — открывает диспетчер задач

  • start iexplore — запускает Internet Explorer

  • services.msc — открывает диспетчер служб

  • control — открывает панель управления

  • certmgr.msc — открывает оснастку диспетчера сертификатов

  • regedit — открывает редактор реестра

  • shutdown /r /t 0 — перезапуск экземпляра виртуальной машины

  • Start Task Manager — удобно использовать, если командная строка была закрыта и требуется открыть новую (в диспетчере задач откройте Файл > Выполнить > Cmd).

Удаленный рабочий стол — базовый компонент поддерживаемой службы Azure, однако для него действуют определенные ограничения при увеличении количества ролей и экземпляров. Например, как узнать, к какому экземпляру следует подключиться, если их 100 или более? Использование этого метода устранения неполадок может увеличить время, необходимое для архивации сайта, если вы не знаете, где искать и что именно искать.

Ниже перечисляются ключевые моменты.

  • Включите удаленный рабочий стол для каждой роли во время развертывания.

  • Установите надежный известный пароль и убедитесь, что срок действия ваших учетных данных не истек.

  • Проверьте доступ, чтобы убедиться в его работоспособности прежде, чем возникнет проблема.

  • Сохраните файл RDP для вашего подключения.

Существует четыре основных задачи при использовании средств диагностики Azure.

  1. Установка WAD

  2. Настройка коллекции данных

  3. Инструментирование кода

  4. Просмотр данных

Установка WAD

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

Одна из примечательных функций разработки в средствах Azure для Visual Studio версии 1.4 (август 2011 г.) и более поздних версиях — это возможность использования различных файлов конфигурации (ServiceConfiguration.cscfg) для локальной среды и облака. Как говорит Ник Харрис(Nick Harris) в своем блоге, существует несколько очень полезных приемов использования этой возможности. Конфигурации с несколькими службами полезны для диагностики, так как они позволяют бесплатно использовать эмулятор хранилища при локальном тестировании, одновременно обслуживая отдельный файл конфигурации для рабочей среды. Одна из наиболее частых причин невозможности запуска приложений при публикации в Windows Azure — когда строка подключения, содержащая UseDevelopmentStorage=true, не изменяется на false.

Visual Studio позволяет включить средства диагностики во время тестирования нажатием кнопки Использовать эмулятор хранилища Azure.

Windows Azure — диалоговые окна подключения к учетной записи хранения

После тестирования приложения и обеспечения его готовности к публикации необходимо подготовить учетную запись хранения для облака (ServiceConfiguration.Cloug.cscfg). Дэвид Макогон (David Makogon) в своем блоге указывает три причины наличия специальной учетной записи для диагностики, отдельной от хранилища данных приложения.

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

  2. Наличие нескольких учетных записей хранения не связано с дополнительными затратами, так как они оно определяется объемом данных.

  3. Производительность может быть повышена с помощью отдельной учетной записи.

Задайте следующую строку подключения.

<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="DefaultEndpointsProtocol=https;AccountName=<name>;AccountKey=<key>" />

Значения AccountName и AccountKey доступны на портале управления в разделе учетной записи хранения. AccountName — это первая часть URL-адреса конечных точек таблиц и Blob-хранилищ (часть перед ".table.core.windows.net"). AccountKey — это первичный ключ доступа в кодировке Base-64, предназначенный для учетной записи хранения.

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

Во-первых, необходимо определить, какой объем хранилища потребуется для данных, собранных средствами диагностики Azure. Это значение определяется емкостью диска в соответствии с размером экземпляра/виртуальной машины, а также свойством OverallQuotaInMB класса DiagnosticMonitorConfiguration. Например, если вы настроили модель службы на использование размера виртуальной машины ExtraSmall, то максимально доступная емкость локального хранилища составляет 20 Гб. По умолчанию, значение OverallQuotaInMB установлено на 4 Гб, поэтому суммарный объем локального хранилища составляет всего 16 Гб, чего может оказаться недостаточно для приложения и временных файлов. OverallQuotaInMB задает размер перезаписываемого буфера. С другой стороны, если у вашего сайта большой объем трафика и вы настроили большое количество счетчиков производительности, диагностические данные могут быть намеренно перезаписаны, если не осуществлять их регулярную передачу в постоянное хранилище.

После задания размера виртуальной машины вам может понадобиться сделать его больше, чем 4 Гб. Это можно сделать посредством добавления элемента <LocalStorage> для DiagnosticStore с атрибутом sizeInMB, установленным на новый размер, в файл ServiceDefinition.csdef и соответствующего изменения значения OverallQuotaInMB.

<LocalResources>
      <LocalStorage name="DiagnosticStore" sizeInMB="8192" cleanOnRoleRecycle="false" />
    </LocalResources>

Установив для атрибута cleanOnRoleRecycle значение "false", вы предотвратите удаление локального хранилища "DiagnosticStore" при перезап��ске роли. В разделе Приложение Г. ServiceDefinition.csdef представлен полный код ServiceDefinition.csdef. Этот параметр не гарантирует, что данные сохранятся при перемещении экземпляра (проблемы с оборудованием и т. д.). Помните, что параметры диагностики задаются для одной роли, поэтому необходимо добавить DiagnosticStore отдельно для каждой роли.

Вычисление суммарного размера собираемых данных диагностики имеет крайне важное значение, так как средства диагностики Azure перестанут работать, если это значение превысит OverallQuotaInMB. Единственный способ просмотреть эту ошибку - присоединить отладчик или добавить блок "try...catch" в метод OnStart. Вот что отображается в журнале событий приложения, если код "catch" записывает событие:

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

Так как же вычислить "сумму запрошенных веб-квот"? Каждый тип коллекции элементов (журналы событий, счетчики производительности и т. д.) имеет связанный буфер данных с нулевым значением по умолчанию. Свойство BufferQuotaInMB можно либо оставить с нулевым значением по умолчанию, меньшим, чем значение OverallQuotainMB, либо задать явным образом. Значение OverallQuotaInMB должно быть меньше суммы всех свойств BufferQuotaInMB.

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


// Set an overall quota of 8GB.
config.OverallQuotaInMB = 8192;

// Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
config.Logs.BufferQuotaInMB = 1024;
config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
 config.WindowsEventLog.BufferQuotaInMB = 1024;
config.PerformanceCounters.BufferQuotaInMB = 1024;
config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

Суб-квоты каталогов установлены на ноль, чтобы они могли использовать оставшуюся часть доступной квоты хранения. Если вы указываете конкретное значение, оно должно быть больше или равно другим квотам, так как оно должно быть достаточно большим, чтобы вмещать журналы IIS (веб-роль) и аварийные копии памяти (дампы). По умолчанию, для Directory.QuotaInMB установлено значение 1024 Мб, что означает, что если аварийная копия памяти превышает один гигабайт, запись аварийной копии не сможет быть осуществлена. Уменьшить размер дампов можно посредством использования мини-дампов.

Файлы полного дампа содержат память процесса (виртуальные байты) на момент сбоя. Так как используется 64-разрядная версия Windows, верхним пределом объема памяти является объем физической памяти компьютера. Это значение можно выяснить, обратившись к столбцу памяти в этой таблице размер экземпляра/виртуальной машины. Например, полный аварийный дамп памяти из экземпляра ExtraLarge может иметь размер до 14 Гб. Очевидно, крайне нежелательна ситуация, когда процесс использует всю свободную память, но что если вам действительно необходимо получить файл дампа?

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

Один из вариантов - не осуществлять сбор данных до тех пор, пока не будет выявлен факт возникновения проблемы. У этого варианта два недостатка.

  1. Как вы узнаете о том, что возникла проблема? Клиенты могут безошибочно сообщать о масштабных сбоях, но как быть с малозаметными неполадками, такими как утечка памяти?

  2. Каковы были показатели до выявления проблемы? Действительно ли приложение все время использует 80 % процессорного времени, или это признак проблемы?

Удивительно, но этот вариант является наиболее распространенным, так как он не требует затрат, планирования или действий. Без сомнения, это наихудший вариант.

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

Третий вариант заключается в задании значений свойств ScheduledTransferPeriod, достаточно малых, чтобы исключить перезапись диагностических данных экземпляра, но и достаточно больших, чтобы исключить отрицательное влияние на производительность приложения. Наименьший период передачи, который можно указать, - 1 минута. К счастью, любое внутреннее значение округляется до 1, поэтому сохранение не отключается. Таким образом, следует убедиться, что диагностические данные передаются до того момента, как они становятся непосредс��венно нужны.

Одна из распространенных проблем во многих примерах кода заключается в том, что значение ScheduledTransferPeriod устанавливается на 1 минуту, что негативно сказывается на производительность приложения в рабочей среде. Причиной использования минимальных значений в примерах кода является необходимость быстрой проверки его работоспособности. Разработчики, как правило, не могут ждать 30 минут для проверки передачи журналов. Это обстоятельство можно обойти двумя способами: систематически изменять конфигурацию WAD после развертывания с использованием одного из средств Другие полезные средства или добавить в файл ServiceConfiguration.cscfg код и параметр, реализовав возможность использования нескольких файлов конфигурации службы, упомянутую ранее в этом разделе. Параметр задается в файле ServiceConfiguration.Local.cscfg следующим образом.

<ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="1" />

Файл ServiceConfiguration.Cloud.cscfg выглядит так:

<ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="30" />

Код в методе OnStart и событии RoleEnvironmentChanging может выглядеть следующим образом:

// Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
config.Logs.ScheduledTransferPeriod = myTimeSpan;
config.Directories.ScheduledTransferPeriod = myTimeSpan;
config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

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

  • Critical

  • Ошибка

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

  • Сведения

  • Verbose

Уровень ведения журнала является кумулятивным, поэтому если для фильтра задано значение Предупреждение, то также будут переданы значения Ошибка и Critical. Вы можете использовать указанный выше метод для настройки определенных уровней LogLevelFilter для локальной и облачной конфигураций. ServiceConfiguration.Local.cscfg может выглядеть так:

<Setting name="LogLevelFilter" value="Information" />

ServiceConfiguration.Cloud.cscfg может выглядеть так:

      <Setting name="LogLevelFilter" value="Error" />

Код в методе OnStart и событии RoleEnvironmentChanging может выглядеть следующим образом:

// Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
var myLogLevel = LogLevel.Undefined;
switch (LogLevelFilter)
{
    case ("Information"):
        myLogLevel = LogLevel.Information;
        break;
    case ("Verbose"):
        myLogLevel = LogLevel.Verbose;
        break;
    case ("Warning"):
        myLogLevel = LogLevel.Warning;
        break;
    case ("Critical"):
        myLogLevel = LogLevel.Critical;
        break;
    case ("Error"):
        myLogLevel = LogLevel.Error;
        break;
    default:
        break;
} 

// Filter what will be sent to persistent storage.
config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

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

Использование файла конфигурации

В Azure SDK 1.3 появилась возможность записи конфигурации в XML-файл вместо написания кода. Дэвид Хардин (David Hardin) говорит, что это наиболее эффективный способ настройки средств диагностики для всех типов ролей Azure. Этот метод имеет множество преимуществ перед написанием кода.

  1. WAD запускается до выполнения OnStart, что позволяет фиксировать ошибки в задачах запуска.

  2. Все изменения, внесенные в конфигурацию во время выполнения, сохраняются после перезапуска.

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

  4. Это единственный способ получения данных диагностики из бета-версии роли виртуальной машины.

  5. Изменения конфигурации не требуют повторного построения кода

Образец diagnostics.wadcfg находится в Приложение Е. diagnostics.wadcfg. Файл конфигурации с именем diagnostics.wadcfg должен быть размещен в следующем расположении, и для параметра Копировать в каталог вывода должно быть задано значение Всегда копировать.

  • Для рабочих ролей файл конфигурации расположен в корневом каталоге роли.

  • Для веб-ролей файл конфигурации размещается в каталоге bin в корневой папке роли.

  • Для бета-версий ролей виртуальной машины файл конфигурации должен быть расположен в папке %ProgramFiles%\Azure Integration Components\<VersionNumber>\Diagnostics в образе сервера, который вы отправляете на портал управления Azure. <VersionNumber> — это номер версии Windows Azure SDK, который вы используете. В этой папке находится файл по умолчанию, который вы можете изменить или заменить собственным файлом.

Формат этого файла описывается в следующем документе MSDN. Файл .wadcfg игнорируется, если в контейнере wad-control-container blob-хранилища уже имеется XML-файл конфигурации. Вам также потребуется проверить правильность данных в файле, в противном случае данные диагностики собраны не будут.

Теперь все готово к принятию решения о том, какие сведения следует собирать.

Настройка коллекции данных

Если вы не хотите использовать файл конфигурации, то лучше всего начать диагностику в методе OnStart внутри блока "try/catch". Блок обеспечивает надлежащую обработку проблемы, что предотвратит постоянный перезапуск службы. Недостаток размещения кода в методе OnStart заключается в том, что если не обрабатываются все исключения, то начнется циклическая перезагрузка роли, что усложнит отладку. При использовании этого метода для экземпляра роли назначается состояние Busy, и экземпляр недоступен через подсистему балансировки нагрузки Azure. Если метод OnStart возвращает значение "false" или при возникновении исключения экземпляр роли немедленно останавливается. Если метод возвращает значение "true", Azure запускает роль, вызывая метод Run.

Посредством переноса кода OnStart в блок "try/catch" можно предотвратить циклическую перезагрузку роли (состояние на портале управления никогда не меняется на "Готово") в случае исключения. Искомый код может содержать вызов метода Trace.WriteLine (пример MSDN), либо в журнал могут быть занесены сведения об ошибке (блог по отладке ASP.NET). При занесении в журнал события становится проще выяснить причину отказа запуска роли. Немного измененный вариант этого кода, предложенный Томом Кристианом(Tom Christian), предназначен для занесения исключения в журнал событий приложения, например:

catch (Exception e)  
    {
            string sSource;
            string sEvent;
            sSource = "WaAppAgent";
            sEvent = "WorkerRole OnStart Event: " + e.Message;
            EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
    }

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

Теперь, когда средства диагностики Azure настроены, можно начинать сбор данных. Возможен сбор данных пяти типов:

  • Аварийные дампы

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

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

  • Журналы служб IIS

  • Журналы FREB

В таблице ниже приводятся сведения о том, какие данные собираются локально по умолчанию, и какие данные должны быть настроены явным образом

 

Источник данных Конфигурация по умолчанию Описание

DiagnosticInfrastructureLogs

Включена, хранится локально, передача в постоянное хранилище не предусмотрена. Передачи в таблицу хранилища WADDiagnosticInfrastructureLogsTable

Журналы, характерные для самой инфраструктуры диагностики. Как правило, они не очень полезны.

Журналы

Включена, хранится локально, передача в постоянное хранилище не предусмотрена. Передачи в таблицу хранилища WADLogsTable

Журналы System.Diagnostics.Trace, расположенные в коде приложения.

Каталоги

BLOB-объекты wad-iis-failedreqlogfiles, wad-iis-logfiles и wad-crash-dumps создаются автоматически по умолчанию, у каждого из них есть свойство DirectoryQuotaInMB, для которого задано значение 1024 МБ. Вы также можете задать дополнительные каталоги

Данные журналов будут передаваться через интервал передачи ScheduledTransferPeriod.

PerformanceCounters

Отключено. При их добавлении используется имя таблицы хранилища WADPerformanceCountersTable.

Счетчики производительности должны быть явным образом заданы

WindowsEventLog

Отключено. При их добавлении используется имя таблицы хранилища WADWindowsEventLogsTable.

Для журналов событий Windows не указаны источники данных.

CrashDumps

Минимальные аварийные дампы собираются локально. Могут быть включены полные дампы памяти. wad-crash-dumps — это имя, созданное в хранилище BLOB-объектов.

Вызовите метод EnableCollection(true) для получения полных аварийных дампов.

Данные трассировки неудавшегося запроса в IIS 7.0

Отключено. При их добавлении используется имя хранилища blob-объектов wad-iis-failedreqlogfiles.

Оно должно быть включено в файле Web.config

  • Аварийные дампы

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

    // Enable crash mini dump collection.
                    CrashDumps.EnableCollection(false);
    
    Код предназначен для сбора полных дампов, например:

                    // Enable full crash dump collection.
                    CrashDumps.EnableCollection(true);
    
    Как вы помните из обсуждения настройки Directory.QuotaInMB, если имеются полные дампы, для их сохранения вам потребуется выделить достаточное локальное пространство, а также достаточную общую емкость хранилища.

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

    Журналы событий - наиболее полезный способ нахождения ошибок приложений. Рассмотрим процесс добавления событий приложения и системы.

    // Add in configuration settings for Windows Event logs           config.WindowsEventLog.DataSources.Add("Application!*");
    config.WindowsEventLog.DataSources.Add("System!*");
    
    Осуществляется сбор только тех событий, которые произошли после начала диагностики Azure, что делает журналы событий бесполезными для диагностики проблем запуска, если не используется рекомендованный способ запуска и настройки диагностики.

    Также можно применять фильтр для выделения определенных событий. Стив Маркс (Steve Marx) в своем блоге объясняет, как создать запрос XPath для получения только той информации, которая несет какую-либо ценность. Например, с помощью следующего запроса XPath, использующего метод Add, осуществляется сбор только сообщений WaAppAgent.

    ("Application!*[System[Provider[@Name='WaAppAgent']]]")
    
  • Счетчики производительности

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

    [MonAgentHost] Error:  PdhExpandWildCardPath(\Process(_Total)) failed
    
    Интернет-роль и рабочая роль могут использовать несколько языков. Для всех типов ролей существуют базовые счетчики производительности, рекомендованные к использованию. Имя процесса в примере ниже (WaWorkerHost) следует изменить на "WallSHost" для интернет-роли. Код, характерный для рабочей роли, не имеющей кода .NET, можно найти в Приложение В. Пример кода рабочей роли.

    • @"\Process(WaWorkerHost)\% Processor Time "

    • @"\Process(WaWorkerHost)\Private Bytes "

    • @"\Process(WaWorkerHost)\Thread Count"

    • @"\Processor(_Total)\% Processor Time"

    • @"\Memory\Available Bytes"

    Существуют дополнительные счетчики для интернет-роли или рабочей роли, в которой выполняется код .NET. Эти счетчики также необходимо отслеживать. Опять-таки, имя процесса в примере ниже (w3wp) необходимо сменить на "WaWorkerHost", если это рабочая роль, или на WaIISHost, если используется интернет-роль в полном режиме IIS. Рекомендуемые счетчики для веб-роли, выполняющей код .NET, можно найти в Приложение Б. Пример кода интернет-роли.

    • @"\Process(w3wp)\% Processor Time "

    • @"\Process(w3wp)\Private Bytes "

    • @"\Process(w3wp)\Thread Count "

    • @"\Processor(_Total)\% Processor Time"

    • @"\Memory\Available Bytes"

    • @"\ASP.NET\Applications Running"

    • @"\.NET CLR Interop(_Global_)\# of marshalling"

    • @"\.NET CLR Jit(_Global_)\% Time in Jit"

    • @"\.NET CLR Loading(_Global_)\% Time Loading"

    • @"\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec"

    • @"\.NET CLR Memory(_Global_)\# Bytes in all Heaps"

    • @"\.NET CLR Networking(_Global_)\Connections Established"

    • @"\.NET CLR Remoting(_Global_)\Remote Calls/sec"

    Строку WaIISHost необходимо заменить на "w3wp", если полный режим IIS не используется. Как уже говорилось ранее, ScheduledTransferPeriod определяет, сохраняются ли счетчики в хранилище, и когда это происходит.

  • журналы IIS

    Интернет-роли Azure работают в IIS с включенным ведением журналов по умолчанию и написаны в формате W3C с кодировкой UTF-8 в папке ресурсов для применения вами (например, C:\Resources\directory\c5c31518818e46569fa68f0809b5a6aa.fm_WebRole.DiagnosticStore\LogFiles\Web) с параметром Log File Rollover, установленным на значение "каждый час". Для каждого сайта предусмотрен один файл журнала. Если вы удаленно подключитесь к одному из экземпляров и откроете Диспетчер IS, отобразятся следующие параметры:

    Windows Azure — диалоговое окно ведения журналов

    Параметры ведения журналов по умолчанию могут быть изменены для соответствия конкретным требованиям. Прием заключается в том, что все изменения включаются в задачу запуска, поэтому при каждом перезапуске экземпляра его параметры не теряются. Например, чтобы только заносить ошибки в журнал следует использовать Appcmd.exe, являющийся частью IIS 7 в задаче запуска, содержащей следующую команду.

    appcmd set config /section:httpLogging /dontLog:False /selectiveLogging:LogError
    
  • Трассировка неудачно завершенных запросов

    Если вы имеете дело с интернет-ролью, то вам, разумеется, необходимо осуществлять сбор данных журналов трассировки неудачных запросов (ранее известен как журнал FREB). Для этого в файле Web.config необходимо добавить следующие строки в разделе <system.webServer>:

    <tracing>
          <traceFailedRequests>
            <add path="*">
              <traceAreas>
                <add provider="ASP" verbosity="Verbose" />
                <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
                <add provider="WWW Server" areas="Authentication, Security, Filter, StaticFile, CGI, Compression, Cache, RequestNotifications,Module" verbosity="Verbose" />
              </traceAreas>
              <failureDefinitions timeTaken="00:00:20" statusCodes="400-599" />
            </add>
          </traceFailedRequests>
        </tracing>
    
    Это приведет к тому, что будет осуществляться занесение в журнал данных о любых запросах, время выполнения которых превышает 15 секунд или имеющих код состояния между 400 и 599 (элемент failureDefinitions). После создания журнала FREB он автоматически сохраняется в хранилище.

  • Другие каталоги

    Также может понадобиться сбор других файлов, записываемых в экземпляр, в частности, файлы гостевого агента. Эти файлы могут предоставить сведения о том, что происходит между гостевым агентом и контроллером структуры Azure. Для этого необходимо настроить каталог, который будет скопирован средствами диагностики Azure.

              // Add a custom directory transfer
              DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
              directoryConfiguration.Container = "wad-custom-logs";
              directoryConfiguration.DirectoryQuotaInMB = 0;
              directoryConfiguration.Path = @"c:\logs\WaAppAgent.log";
              config.Directories.DataSources.Add(directoryConfiguration);
    
    Здесь имеет место аналогичная проблема, связанная с возможностью сбоя в конфигурации. Чтобы протестировать эмулятор Compute, необходимо создать эту папку и убедиться, что этот код не выполняется несколькими ролями, в противном случае произойдет нарушение совместного доступа. Данная ошибка не произойдет в облачной конфигурации, так как каждый экземпляр является отдельным.

Устранение неполадок WAD

Теперь, настроив все необходимые параметры, можно протестировать их в эмуляторе Compute и выполнить развертывание в Azure. Данные диагностики не отобразились. Что произошло? Ниже приведены некоторые основные параметры, которые следует проверить.

  1. Проверьте BLOB-объекты в контейнере wad-control-container в учетной записи хранения диагностики. Нужно найти объект с именем <deploymentID>/<RoleName>/<RoleInstance> (т. е., 3981bcff0eb743ddb9b7574a8821e955/WebRole1/WebRole1_IN_0).

    1. Откройте XML-файл и убедитесь, что он настроен надлежащим образом. Если вы видите <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes> для данного источника данных, данные средства диагностики не настроены для передачи данных.

    2. Если имеется несколько экземпляров, и некоторые из них передают диагностические данные, а другие - нет, сравните XML-файлы, чтобы убедиться, что все они настроены правильно.

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

  2. Проверьте журналы в таблице WADDiagnosticInfrastructureLogsTable в учетной записи хранения диагностики. Необходимо выполнить фильтрацию по deploymentid (например, DeploymentId eq "bd9e149f76e8413aba8865c77326e449"). Ищите любые исключения или сообщения об ошибках, которые могут указывать на то, почему данные диагностики не передаются.

  3. Если сбор сведений Diagnostics.Trace не осуществляется, убедитесь, что в файле web.config или app.config настроен прослушиватель DiagnosticMonitorTraceListener. В облачных проектах он настроен по умолчанию, но иногда параметры могут измениться, из-за чего операторы trace не будут собираться средствами диагностики.

  4. Зачастую запросы к хранилищу диагностики неверны, поэтому результаты не возвращаются и предполагается, что данные диагностики не фиксируются. Отправляйте запросы к таблицам диагностики с фильтрацией по DeploymentID и проверьте, правильно ли передаются данные диагностики. Ниже приведены некоторые распространенные ошибки. отсутствует фильтрация по DeploymentID и отслеживание маркеров продолжения.

  5. Если после развертывания экземпляр не запускается, убедитесь, что для учетной записи хранения, настроенной в файле ServiceConfiguration.cscfg, не задано значение "UseDevelopmentStorage = true". Если вы используете версию инструментов Azure для Visual Studio 2011, выпущенную после августа 2011 г., вы увидите предупреждение. Если этого не произошло, вам следует подключиться к экземпляру через сеанс удаленного рабочего стола и проверить файл конфигурации роли, расположенный в папке C:\Config.

  6. При наличии подключения к экземпляру также следует убедиться, что запущены файлы DiagnosticsAgent.exe и MonAgentHost.exe. Подразумевая, что они запущены, можно установить и присоединить WinDBG, чтобы проверить наличие каких-либо исключений.

  7. Кроме того, можно проверить, что данные диагностики записываются локально.

    • В среде разработки файлы TSF записываются в следующую папку:

      c:\Users\<username>\AppData\Local\dftmp\Resources\<deploymentID>\directory\DiagnosticStore\Monitor\Tables

    • На работающем экземпляре файлы записываются в следующее расположение:

      c:\Resources\<deploymentID>.<role>\directory\DiagnosticStore\Monitor\Tables

    В данный момент для чтения этих файлов вам понадобится создать обращение за технической поддержкой и отправить его в Майкрософт.

  8. Если у вас несколько экземпляров и только некоторые из них не передают данные диагностики правильно, попробуйте переустановить образ роли с портала управления. Это крайнее средство, так как при этом теряется возможность определения основной причины возникновения проблемы.

Инструментирование кода

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

Структура ETW связывает TraceEventType с каждым событием:

 

TraceEventType Уровень Значение Назначение

Critical

1

0x0001

Неустранимая ошибка или сбой приложения

Ошибка

2

0x0002

Устранимая ошибка

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

3

0x0004

Некритическая ошибка - может указывать на возможность проявления других серьезных проблем.

Сведения

4

0x0008

Информационное сообщение.

Verbose

5

0x0010

Трассировка отладки (например, детальные сведения о ходе выполнения, параметрах и т. п.)

Начало

0x0100

Начало логической операции

Stop

0x0200

Остановка логической операции

После разработки плана инструментирования кода можно просто добавить пространство имен System.Diagnostics и затем добавить сообщения трассировки. На языке C# это выглядит так:

Trace.WriteLine("LoggingWorkerRole entry point called", "Information");

Так как Azure была запущена в Full IIS (SDK 1.3), код веб-приложения выполняется в другом домене приложения и процессе, нежели RoleEntryPoint. По этой причине сообщения трассировки не отображаются в эмуляторе Compute, пока в файл Web.Config в раздел Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener не будет добавлен дополнительный элемент прослушивания трассировки:

<add type="Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime.DevelopmentFabricTraceListener, Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="DevFabricListener">
    <filter type=""/>
</add>

При работе с более сложными приложениями методология EventId позволяет фильтровать журналы более эффективно и, следовательно, быстрее устранять проблемы. Если вы используете WriteLine C#, EventId всегда будет равен 0. Чтобы задать EventId, необходимо использовать метод TraceEvent, где traceType можно найти в таблице выше:

Trace.TraceEvent(traceType, eventId, message);

Сообщения трассировки сохраняются в таблице WADLogsTable. Azure автоматически связывает следующие сведения с каждым внесенным в журнал событием: отметка времени, счетчик тактов (который предоставляет более детальное время с величиной разбиения в 100 наносекунд) и сведения о развертывании роли и ее экземпляра. Это позволяет при работе с журналами определить конкретный экземпляр, на котором имеется эта проблема. Сообщение сохраняется в формате XML:


<Properties>
 <EventTickCount>634402131502204503</EventTickCount>
 <DeploymentId>deployment(28)</DeploymentId>
 <Role>WebRole1</Role>
 <RoleInstance>deployment(28).Sample.WebRole1.0</RoleInstance>
 <Level>3</Level>
 <EventId>20</EventId>
 <Pid>10796</Pid>
 <Tid>7172</Tid>
 <Message>trace message; TraceSource 'Data' event</Message> 
</Properties>

Уровень соответствует TraceEventType. В таблице выше видно, что уровень 3 соответствует Warning. Если не указан параметр TraceEventType или используется Trace.WriteLine, то будет задан уровень 5 (Verbose).

В большинстве случаев стандартных журналов достаточно. При более детальном ведении журналов можно создать настраиваемый прослушиватель трассировки:

Azure Table Query — это проект веб-ролей CodePlex, позволяющий запрашивать WADLogsTable с помощью запроса LINQ.

Просмотр данных

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

Все данные диагностики Azure хранятся в учетной записи хранения, указанной при запуске WAD. Для визуализации этих данных вы можете использовать Visual Studio Server Explorer или любое другое средство storage explorers.

Blob-объект wad-control-container содержит средства ведения журнала самой инфраструктуры диагностики. Именно здесь можно определить, передаются ли данные из некоторого экземпляра. Идентификатор blob-объекта имеет следующий вид:

0aef2b51ad1d49ef915dd41d3ca01f24/WorkerRole1/WorkerRole1_IN_0

Этот идентификатор разделен на 3 части:

  1. Значение типа long представляет собой идентификатор развертывания — 0aef2b51ad1d49ef915dd41d3ca01f24

  2. Имя роли — WorkerRole1

  3. Имя экземпляра — WorkerRole1_IN_0

Если имеется несколько экземпляров, то нулевой суффикс увеличивается, например, WorkerRole1_IN_1 - это второй экземпляр.

Ниже показана таблица, по которой можно определить, где записывается каждый из журналов

 

Тип журнала Формат хранилища Azure Примечания

Журналы Azure, сформированные на основе вашего кода

Таблица

В файл web.config или app.config должен быть добавлен прослушиватель трассировки. Файлы хранятся в таблице WADLogsTable.

Журналы IIS 7.0

Большой двоичный объект

Только интернет-роли. Хранится в blob-контейнере, путь: wad-iis-logfiles\<deployment ID>\<web role name>\<role instance>\W3SVC1.

Журналы инфраструктуры диагностики Windows

Таблица

Сведения о самой службе диагностики. Хранятся в таблице WADDiagnosticInfrastructureLogs.

Журналы неудачных запросов

Большой двоичный объект

Только интернет-роли. Чтобы включить ведение журналов, задайте параметры system.WebServer в файле web.config. Журналы хранятся в BLOB-контейнере по пути wad-iis-failedreqlogfiles\<код развертывания>\<имя веб-роли>\<экземпляр роли>\W3SVC1.

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

Таблица

Включается посредством изменения параметра DiagnosticMonitor Configuration.WindowsEventLog при настройке первоначальной конфигурации. Хранится в таблице WADWindowsEventLogs.

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

Таблица

Для активации измените параметр DiagnosticMonitor Configuration.PerformanceCounters, который хранится в таблице WADPerformanceCounters. Образец кода рабочей роли устанавливает счетчик производительности.

Аварийные дампы

Большой двоичный объект

Для активации вызовите CrashDumps.EnableCollection. Хранится в BLOB-контейнере по пути wad-crash-dumps. Так как ASP.NET обрабатывает большинство исключений, обычно это полезно только для рабочей роли.

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

Большой двоичный объект

Наглядный пример использования см. в блоге Нила Маккензи (Neil Mackenzie).

При передаче данных аварийного дампа в постоянное хранилище они сохраняются в blob-контейнере wad-crash-dumps. Журналы IIS передаются в blob-контейнер wad-iis-logfiles. Неудачные запросы сохраняются в blob-контейнере wad-iis-failedreqlogfiles.

Журналы событий передаются в таблицу WADWindowsEventLogs для постоянного хранения. Счетчики производительности передаются в таблицу WADPerformanceCounters через заданный временной интервал. WADDiagnosticInfrastructureLogs содержит журналы с данными об инфраструктуре диагностики. Прослушиватели трассировки находятся в таблице WADLogsTable.

Еще один способ просмотра данных диагностики заключается в использовании средства LINQPad, которое можно проверить на примере AzureLogsWithLINQPad Джейсона Хейли (Jason Haley).

Управление диагностикой

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

С помощью командлетов PowerShell Azure можно настраивать различные параметры работающих у вас служб Azure, включая диагностику. Они запускаются с локального компьютера и подключаются к вашей службе по Интернету с помощью API управления и диагностики Azure, предоставляя сведения и регулируя параметры.

Windows PowerShell устанавливается вместе с Windows 7 и является дальнейшим развитием системы командлетов для управления службой, устанавливаемых со средством управления Azure (MMC). Ниже представлен список наиболее полезных командлетов.

  • Get-DiagnosticConfiguration — получает конфигурацию буфера для указанного имени буфера (Logs, Directories, PerformanceCounters, WindowsEventLogs или DiagnosticInfrastructureLogs).

  • Чтобы изменить конфигурацию роли, используйте командлет Set-DiagnosticConfiguration.

  • Start-OnDemandTransfer — запускает передачу по требованию указанного буфера данных. Это действие приводит к перемещению данных в хранилище Azure (в хранилище таблиц или BLOB-объектов).

В блоге Дэвида Эйкена (David Aiken) есть скрипт для очистки некоторых файлов журнала (файлы журнала IIS и XML-файлы wad-control-container). Командлет Clear-Container должен вызываться для каждого контейнера. Кроме того, следует убедиться, что назначенные операции передачи данных не будут пересекаться с удалением. Также следует выработать стратегию хранения журналов в таблицах (счетчики производительности, журналы событий, и т. д.). Некоторые пользователи загружают все данные из хранилища Azure и помещают их в базу данных SQL Server, чтобы избежать дальнейшей платы за хранение и получить возможность выполнять более сложные запросы данных.

Изучив ресурсы диагностики Azure, разработчики могут создавать поддерживаемые приложения, используя указанные ниже рекомендации по проектированию.

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

Следующий шаг - понимание того, как следует поддерживать работоспособность Главным условием работоспособности приложения является своевременная оплата счета за Azure. Неоплаченная подписка с течением времени приводит к все более серьезным последствиям, что, в конечном счете, заканчивается удалением приложения.

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

Windows Azure — уровни работоспособности

Например, в экземпляре может произойти сбой из-за неполадки оборудования, или он может быть перезапущен вследствие обновления программного обеспечения. Это не приведет к возникновению сбоя роли, если имеется только один экземпляр. Аналогичным образом, каждая размещенная служба расположена в определенном регионе (например, в центральных штатах юга США). Эта важная информация определяет, будет ли ваше приложение подвержено влиянию такого события как прерывание работы службы (простою). Сбой на более низком уровне может вызвать неполадки на уровне размещенной службы, если в проекте приложения не предусмотрена избыточность.

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

Windows Azure — пример архитектуры

Распределенная природа приложения обуславливает несколько потенциальных точек сбоев. Документирование этих точек повышает эффективность устранения неполадок. Например, как проводить тестирование в соответствии с указанной выше схемой, если сбой произошел в системе контроля доступа?

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

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

  • Бизнес-процессы. Аудит, необходимый для обеспечения безопасности, учет изменений, обеспечение соответствия требованиям.

  • Стабильность системы. Производительность, масштабируемость, пропускная способность, задержки.

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

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

Необходимо выделять подходы, ускоряющие устранение неполадок при возникновении проблемы. Уверенность в том, что приложение разрабатывалось с учетом скорейшего восстановления после сбоев, позволяет избежать глубокого стресса при возникновении проблемы и сократить время восстановления. Анализ потенциальных затрат позволяет определить, в каком объеме в вашей системе будут реализованы принципы отказоустойчивости. Например, стоит ли тратить дополнительные средства на реализацию "горячей" архивации с помощью Traffic Manager, чтобы сократить время простоя?

Azure Traffic Manager позволяет управлять трафиком размещенных служб Windows Azure и распределять его независимо от их размещения (в одном центре обработки данных или в разных местах по всему миру). Это средство предоставляет возможность настройки службы отказоустойчивости, которая в случае сбоя основной службы передает трафик на следующую доступную службу. Стороннее программное обеспечение, такое как Akamai и Limelight также предоставляет возможности балансировки нагрузки.

Ниже представлен план из пяти шагов, позволяющий ускорить разрешение проблем.

Первый шаг плана - узнать о проблеме как можно скорее. Чем быстрее вы узнаете о том, что возникла проблема, тем быстрее вы сможете начать применение плана восстановления. Именно для этого нужен мониторинг.

Второй шаг — определение источника проблемы: платформы Azure или приложения. Первым делом следует открыть панель мониторинга службы Azure. Для работы с этим сайтом необходимо знать все службы, используемые вашим приложением, а также то, в каком центре обработки данных оно развернуто. Нарушение лишь одной службы может отрицательно сказаться на работе приложения.

Один из способов мониторинга платформы Azure — подписка на все каналы RSS для вашего приложения. Например, если бы ваше приложение было размещено в центре обработки данных, расположенном в центральной части северного региона США, следовало бы подписаться на этот канал RSS.

Хранилище Azure использует домены сбоя (стойка, сетевой коммутатор, питание) для ограничения влияния сбоев оборудования. Одно из распространенных заблуждений касательно хранилища Azure заключается в том, что для реплик данных вне единого расположения (например, центральной части южного региона США) автоматически выполняется отработка отказов. Если в хранилище возникает проблема в данном расположении, это повлияет на доступность данных. Группа специалистов по хранению данных освещает в своем блоге все детали новой возможности географической репликации.

Третий шаг - локализация проблемы. Возможно, это самый сложный шаг, если речь идет о комплексных приложениях, в которых используется множество служб Azure. Создание службы без учета состояния позволит изолировать различные части приложения. Если все зависимые службы работают нормально, необходимо определить состояние вычислительных служб. Это можно сделать на портале управления, открыв раздел Размещенные службы, учетные записи хранен��я и CDN и выбрав нужное развертывание. В окне свойств будет примерно следующее содержимое:

Windows Azure — свойства развертывания

В этом случае, по всей видимости, последние восемь дней данное развертывание работало нормально, судя по разнице временного интервала между временем завершения последней операции и временем последнего обновления. Если, однако, вы видите, что недавно ваше развертывание прерывало работу или было перезапущено, это может помочь определить, откуда начинать поиск неполадок. Если оказалось, что это событие службы повлияло на все ваши развертывания в рассматриваемом центре обработки данных, немедленно свяжитесь с Майкрософт: (866) 676-6546.

Четвертый шаг заключается в выполнении стандартных шагов по устранению неполадок, таких как проверка файлов журналов, журналов событий, использование отладчика или таких средств как Procmon или Network Monitor с целью обнаружения признаков проблемы. В развертывании размещенной службы Azure первым делом следует обратиться к журналу событий приложения. Убедитесь, что в приложении не были вызваны исключения. Это действие может показаться необязательным, так как в настоящее время поддержка предоставляется бесплатно. Дело в том, что вы зачастую можете найти и исправить проблемы быстрее, чем высококвалифицированный специалист службы поддержки Майкрософт, у которого нет подробных сведений о структуре приложения. Если приоритетом является работоспособность сайта, то в первую очередь необходимо найти подходящую альтернативу.

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

Производительность похожа на красоту: она в глазах смотрящего. Как определить, что производительность стала неприемлемой? Когда истекает период ожидания загрузки страницы? Даже если оценить максимальное время загрузки, это не гарантирует, что страницы будут загружаться у всех ваших клиентов. Двумя ключевыми факторами, определяющими время загрузки страницы, являются маршрут DNS и надежность сети. Например, у нас был клиент в Мемфисе, шт. Теннесси, провайдер которого отправил трафик, предназначенный для Сан-Антонио, шт. Техас, сначала в Чикаго. Microsoft Online Services предоставляет средство тестирования производительности, измеряющее время отклика, полосу пропускания и среднее качество соединения. Чтобы определить задержку между различными центрами обработки данных Майкрософт, можно воспользоваться средством Azure Statistics от Мэтью Розоффа (Matthew Rosoff).

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

Платформа Azure предоставляет соглашения об уровне обслуживания (SLA), определяющие уровни доступности/возможность соединения для различных служб. Каковы ваши SLA? Однажды мой интернет-провайдер сообщил мне, что я не должен использовать свое подключение для работы, так как мой пакет услуг не включает SLA. Характеристика "надежность" похожа на "производительность" тем, что она во многом зависит от сети клиента, и также является очень относительным понятием. Указанные выше ссылки позволят вам определить производительность вашего сетевого подключения.

Зачастую ошибочно полагают, что соглашения SLA для платформы Azure автоматически гарантируют такие же SLA для вашего приложения. Во-первых, не читайте вторую фразу. Ее смысл таков:

по части вычислительных операций, мы гарантируем, что при развертывании вами двух или более экземпляров роли в различных доменах отказа и обновления, для ваших ролей, граничащих с Интернетом, будет обеспечено работоспособное внешнее соединение в течение 99,95 % времени.

В этом предложении не хватает важного уточнения: "двух и более экземпляров для каждой роли". Иными словами, наличие интернет-роли и рабочей роли, по одному экземпляру у каждой, подразумевает, что ваше приложение не будет доступно в течение всего времени, если выполняется обновление несущей операционной системы или проводятся некоторые профилактические работы в системе. Среда Azure Compute использует домены сбоя для обеспечения соответствия SLA.

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

Чтобы обеспечить максимальную надежность, необходимо осуществлять мониторинг сайта как изнутри с помощью данных Windows Azure Diagnostic, так и извне с помощью средства Apica AzureCheck, Compuware Gomez или Pingdom. Кроме того, необходимо обеспечить установку самых последних исправлений системы безопасности и разработать план проверки изменений в коде.

При создании нового приложения в Visual Studio происходит выбор версии гостевой операционной системы в файле ServiceConfiguration.cscfg:

osFamily="1" osVersion="*"

Это благоприятный момент, так как вы будете получать автоматические обновления, что является одним из ключевых преимуществ PaaS. Такой подход не является оптимальным, так как не используется последняя версия операционной системы. Чтобы использовать последнюю версию ОС (Windows Server 2008 R2) параметры следует настроить следующим образом:

osFamily="2" osVersion="*"

К сожалению, многие клиенты предпочитают использовать только конкретную версию операционной системы с целью минимизировать время простоя, исключив обновления гостевой ОС. Эта стратегия является обоснованной только для корпоративных клиентов, которые систематически тестируют каждое обновление и затем назначают операцию VIP Swap в отношении ключевого приложения, функционирующего в рабочей среде. Во всех остальных случаях, когда тестирование каждого обновления гостевой ОС не выполняется, отказ от автоматического обновления влечет за собой повышенные риски для приложения Azure.

Как действовать в случае, если требуется обновить службу, в особенности при возникновении нештатной ситуации? От этого шага, который зачастую игнорируется. может зависеть, как будут развиваться события: сайт станет неработоспособным, или возникнет лишь незначительная промежуточная неполадка. Основная часть работы выполняется при первоначальном планировании и выпуске приложения Azure, однако во многих случаях подразумевается, что нет необходимости в проведении расширенного тестирования, так как значимость исправления изменения ниже, чем для всего продукта в целом. Недостатки можно быстро исправить. Однако они также могут легко привести к катастрофическому сбою.

Любое изменение в рабочей версии приложения должно тестироваться перед окончательным развертыванием в рабочей среде. Потраченное на это дополнительное время легко окупается, если принять во внимание возможные последствия сбоя. Дополнительные сведения см. в обзоре обновления службы Azure.

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

  • Том Кристиан (Christian, Tom) "Help with Azure role stuck in Initializing/Busy/Stopped state" Блог (на английском языке), 25 февраля 2011 г.

  • Энди Кросс (Cross, Andy) "Tracing to Azure Compute Emulator SDK V1.3" Блог (на английском языке), 22 января 2011 г.

  • Джейсон Хейли (Haley, Jason) "How To: Query Azure Log Tables with LINQPad", Блог (на английском языке), 28 января 2010 г. 15:09.

  • Дэвид Хардин (Hardin, David) "Configuring WAD via the diagnostics.wadcfg Config File", Блог (на английском языке), 29 марта 2011 г.

  • Майк Келли (Kelly, Mike) "Take Control of Logging and Tracing in Azure", MSDN Magazine (на английском языке), июнь 2010 г.

  • Нил Маккензи (Mackenzie, Neil) "Custom Diagnostics in Azure", Блог (на английском языке), 8 декабря 2009 г.

  • Дэвид Макогон (Makogon, David) "Azure Tip of the Day: Separate Diagnostic Storage Account", Блог (на английском языке), 15 августа 2010 г.

  • Стив Маркс (Marx, Steve) "Capturing Filtered Windows Events with Azure Diagnostics", Блог (на английском языке), 21 апреля 2010 г.

  • Тодди Младенов (Mladenov, Toddy) "Collecting Event Logs in Azure", Блог (на английском языке), 2 мая 2010 г.

  • Уолтер Майерс (Myers, Walter) "Setting Up Performance Counters In Your Azure Web and Worker Roles", Блог (на английском языке), 31 января 2011 г.

  • Джим Накашима (Nakashima, Jim) "Using IntelliTrace to debug Azure Cloud Services", Блог (на английском языке), 7 июня 2010 г.

  • Джим О'Нил (O’Neil, Jim) "500 and Other Errors in Azure Deployments Blog", Блог (на английском языке), 11 апреля 2011 г. 16:47 (4:47 AM).

  • Майкл Стифел (Stiefel, Michael) "Why Did My Azure Application Crash? Using the Azure Diagnostics API to Find Code Problems", Блог (на английском языке), 8 сентября 2011 г.

  • Майкл Уошем (Washam, Michael) "Managing Log Files with Azure PowerShell Cmdlets 2.0", Блог (на английском языке), 20 сентября 2011 г.

  • Кевин Уильямсон (Williamson, Kevin) " Azure Role Architecture", Блог (на английском языке), 5 мая 2011 г.

  • Портал управления Azure http://manage.windowsazure.com.

  • Учебный курс по платформе Azure — Упражнение 3. Мониторинг приложений в Azure.

  • Портал Azure http://www.microsoft.com/windowsazure/

 

Фабрика

Логические кластеры компьютеров, формирующие среду выполнения ролей внутри виртуальной машины.

FREB

Сокр. от Failed Request Tracing (трассировка неудачных запросов, ранее - буферизация неудачных запросов)

Портал управления

Портал управления Azure представляет собой административный портал, предназначенный для развертывания и мониторинга служб Azure и управления ими. Портал управления доступен по адресу http://manage.windowsazure.com.

REST

Сокр. от Representational State Transfer (передача репрезентативного состояния). Структура программного обеспечения с архитектурой "клиент-сервер" без учета состояния, в которой веб-службы просматриваются как ресурсы и могут идентифицироваться по их URL-адресам.

Соглашение об уровне обслуживания

Service Level Agreement (соглашение об уровне обслуживания)

Виртуальная машина

Программная эмуляция компьютера, работающего в изолированном разделе реального компьютера.

WAD

Диагностика Azure

Веб-роль

Интернет-роль - это роль, предназначенная для разработки веб-приложений и поддерживаемая в IIS 7 и ASP.NET.

Рабочая роль

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

В этом приложении рассматривается код, необходимый для настройки Azure Diagnostics. Метод RoleEntryPoint.OnStart вызывается с тем, чтобы настроить запуск экземпляра роли. Вы можете создать свою собственную реализацию метода OnStart для выполнения кода, необходимого для настройки WAD вашей роли.

public override bool OnStart()
{
    string sSource = "WaAppAgent";
    string sEvent = null;

    try
    {
        DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();

        // Set an overall quota of 8GB.
        config.OverallQuotaInMB = 8192;

        // Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
        config.Logs.BufferQuotaInMB = 1024;
        config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
        config.WindowsEventLog.BufferQuotaInMB = 1024;
        config.PerformanceCounters.BufferQuotaInMB = 1024;
        config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

        // Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
        var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
        TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
        config.Logs.ScheduledTransferPeriod = myTimeSpan;
        config.Directories.ScheduledTransferPeriod = myTimeSpan;
        config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
        config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
        config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

        // Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
        var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
        var myLogLevel = LogLevel.Undefined;
        switch (LogLevelFilter)
        {
            case ("Information"):
                myLogLevel = LogLevel.Information;
                break;
            case ("Verbose"):
                myLogLevel = LogLevel.Verbose;
                break;
            case ("Warning"):
                myLogLevel = LogLevel.Warning;
                break;
            case ("Critical"):
                myLogLevel = LogLevel.Critical;
                break;
            case ("Error"):
                myLogLevel = LogLevel.Error;
                break;
            default:
                break;
        } 

        // Filter what will be sent to persistent storage.
        config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

        // Add in configuration settings for Windows Event logs
        config.WindowsEventLog.DataSources.Add("Application!*");
        config.WindowsEventLog.DataSources.Add("System!*");

        // Add a custom directory transfer
        DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
        directoryConfiguration.Container = "wad-custom-logs";
        directoryConfiguration.DirectoryQuotaInMB = 0;
        directoryConfiguration.Path = @"c:\logs";
        config.Directories.DataSources.Add(directoryConfiguration);
 

        // Enable full crash dump collection.
        CrashDumps.EnableCollection(true);

        // Use 30 seconds for the perf counter sample rate.
        TimeSpan perfSampleRate = TimeSpan.FromSeconds(30D);

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Memory\Available Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Processor(_Total)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\Private Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\Thread Count",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Interop(_Global_)\# of marshalling",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
             CounterSpecifier = @"\.NET CLR Jit(_Global_)\% Time in Jit",
             SampleRate = perfSampleRate
         });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Loading(_Global_)\% Time Loading",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Memory(_Global_)\# Bytes in all Heaps",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Networking(_Global_)\Connections Established",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Remoting(_Global_)\Remote Calls/sec",
            SampleRate = perfSampleRate
        });

        // Apply the updated configuration to the diagnostic monitor.
        // The first parameter is for the connection string configuration setting.
        DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);

        sEvent = "Management OnStart called diagnostics";
        EventLog.WriteEntry(sSource, sEvent, EventLogEntryType. Information, 0);
    }
    catch (Exception e)
    {
        sEvent = "Management OnStart Event: " + e.Message;
        EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
    }

    return base.OnStart();
}

В этом приложении рассматривается код, необходимый для настройки Azure Diagnostics в рабочей роли.

public override bool OnStart()
{
    // Set the maximum number of concurrent connections 
    ServicePointManager.DefaultConnectionLimit = 12;
    string sSource = "WaAppAgent";
    string sEvent = "WorkerRole OnStart Event: ";

    try
    {
        // For information on handling configuration changes
        // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.

        DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();

        // Set an overall quota of 8GB.
        config.OverallQuotaInMB = 8192;
        // Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
        config.Logs.BufferQuotaInMB = 1024;
        config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
        config.WindowsEventLog.BufferQuotaInMB = 1024;
        config.PerformanceCounters.BufferQuotaInMB = 1024;
        config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

        // Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
        var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
        TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
        config.Logs.ScheduledTransferPeriod = myTimeSpan;
        config.Directories.ScheduledTransferPeriod = myTimeSpan;
        config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
        config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
        config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

        // Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
        var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
        var myLogLevel = LogLevel.Undefined;
        switch (LogLevelFilter)
        {
            case ("Information"):
                myLogLevel = LogLevel.Information;
                break;
            case ("Verbose"):
                myLogLevel = LogLevel.Verbose;
                break;
            case ("Warning"):
                myLogLevel = LogLevel.Warning;
                break;
            case ("Critical"):
                myLogLevel = LogLevel.Critical;
                break;
            case ("Error"):
                myLogLevel = LogLevel.Error;
                break;
            default:
                break;
        }

        // Filter what will be sent to persistent storage.
        config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

        // Add in configuration settings for Windows Event logs
        config.WindowsEventLog.DataSources.Add("Application!*");
        config.WindowsEventLog.DataSources.Add("System!*");

        // Add a custom directory transfer
        DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
        directoryConfiguration.Container = "wad-custom-logs";
        directoryConfiguration.DirectoryQuotaInMB = 0;
        directoryConfiguration.Path = @"c:\logs";
        config.Directories.DataSources.Add(directoryConfiguration);

        // Enable full crash dump collection.
        CrashDumps.EnableCollection(true);

        // Use 30 seconds for the perf counter sample rate.
        TimeSpan perfSampleRate = TimeSpan.FromSeconds(30D);

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Memory\Available Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Processor(_Total)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\Private Bytes",
            SampleRate = perfSampleRate
        }); 
                
        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\Thread Count",
            SampleRate = perfSampleRate
        });

        // Apply the updated configuration to the diagnostic monitor.
        // The first parameter is for the connection string configuration setting.
        DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);

    }
    catch (Exception e)  
        {
                sEvent += e.Message;
                EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
        } 
            
    return base.OnStart();   
}

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="Windows_Azure_Full_Diagnostics" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole1">
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="8080" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
      <Import moduleName="RemoteForwarder" />
    </Imports>
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" />
      <Setting name="LogLevelFilter" />
    </ConfigurationSettings>
    <LocalResources>
      <LocalStorage name="DiagnosticStore" cleanOnRoleRecycle="false" sizeInMB="8192" />
    </LocalResources>
  </WebRole>
  <WorkerRole name="WorkerRole1" vmsize="Small">
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
    </Imports>
    <LocalResources>
      <LocalStorage name="DiagnosticStore" sizeInMB="8192" cleanOnRoleRecycle="false" />
    </LocalResources>
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" />
      <Setting name="LogLevelFilter" />
    </ConfigurationSettings>
  </WorkerRole>
</ServiceDefinition>

noteПримечание
Этот файл конфигурации предназначен для локального использования с эмулятором Compute.

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="Windows_Azure_Full_Diagnostics" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="2" osVersion="*">
  <Role name="WebRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="1" />
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="LogLevelFilter" value="Verbose" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="me" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="MIIBnQYJKoZIhvcNAQcDoIIBjjCCAYoCAQAxggFOMIIBSgIBADAyMB4xHDAaBgNVBAMME1dpbmRvd3MgQXp1cmUgVG9vbHMCEDra5x6UQkuIRHdUChkiglEwDQYJKoZIhvcNAQEBBQAEggEAp8ADE0ov0pKTFo6V1AI94NmsUr8YcQ/dl4M63zbBQkrjSvqqzgofMcMwxYVO8gTwmr3eXawTNp2fbPdN68ZynNgRwEHBm67QP3y6lcAFvx8Amxvp8GZ6qxpAYGE8LhpqBNzoel55mot6IZg0I3qfXtl6SHyfLcyGuPv3nDEzhuYGuPSFR+UF82G2ZK0omLzSuI3KQcbFyTxaUYDIu/fSNOkHVOWwgpNND3SIvg+nSHfS38w+nskAA7bo7oN06LnC+3lLNRrpoKsPBaqogqfyhTkivc3+AJoQ6UAHIyyAJU6kfp4iP7gMl0ZU1mLVeqX5oDwmywf9FGRf7vSn2uEfiTAzBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECAw305eQdOSogBA6i8i7rTruZOxAadm1g545" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2011-12-31T23:59:59.0000000-05:00" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteForwarder.Enabled" value="true" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="D91092F38C839BE56787A0528591E49510FCC711" thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
  <Role name="WorkerRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="ScheduledTransferPeriod" value="1" />
      <Setting name="LogLevelFilter" value="Verbose" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="me" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="MIIBnQYJKoZIhvcNAQcDoIIBjjCCAYoCAQAxggFOMIIBSgIBADAyMB4xHDAaBgNVBAMME1dpbmRvd3MgQXp1cmUgVG9vbHMCEDra5x6UQkuIRHdUChkiglEwDQYJKoZIhvcNAQEBBQAEggEAp8ADE0ov0pKTFo6V1AI94NmsUr8YcQ/dl4M63zbBQkrjSvqqzgofMcMwxYVO8gTwmr3eXawTNp2fbPdN68ZynNgRwEHBm67QP3y6lcAFvx8Amxvp8GZ6qxpAYGE8LhpqBNzoel55mot6IZg0I3qfXtl6SHyfLcyGuPv3nDEzhuYGuPSFR+UF82G2ZK0omLzSuI3KQcbFyTxaUYDIu/fSNOkHVOWwgpNND3SIvg+nSHfS38w+nskAA7bo7oN06LnC+3lLNRrpoKsPBaqogqfyhTkivc3+AJoQ6UAHIyyAJU6kfp4iP7gMl0ZU1mLVeqX5oDwmywf9FGRf7vSn2uEfiTAzBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECAw305eQdOSogBA6i8i7rTruZOxAadm1g545" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2011-12-31T23:59:59.0000000-05:00" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="D91092F38C839BE56787A0528591E49510FCC711" thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
</ServiceConfiguration>

Это пример файла diagnostics.wadcfg для веб-роли.

<?xml version="1.0" encoding="utf-8" ?>
<DiagnosticMonitorConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration"
      configurationChangePollInterval="PT1M"
      overallQuotaInMB="4096">
  <DiagnosticInfrastructureLogs bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M" />
  <Logs bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M" />
  <Directories bufferQuotaInMB="0"
     scheduledTransferPeriod="PT1M">

    <!-- These three elements specify the special directories 
           that are set up for the log types -->
    <CrashDumps container="wad-crash-dumps" directoryQuotaInMB="0" />
    <FailedRequestLogs container="wad-frq" directoryQuotaInMB="0" />
    <IISLogs container="wad-iis" directoryQuotaInMB="0" />
  </Directories>

  <PerformanceCounters bufferQuotaInMB="0" scheduledTransferPeriod="PT1M">
    <!-- The counter specifier is in the same format as the imperative 
           diagnostics configuration API -->
    <PerformanceCounterConfiguration counterSpecifier="\Memory\Available Bytes" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\% Processor Time" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\Private Bytes" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\Thread Count" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Interop(_Global_)\# of marshalling" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Loading(_Global_)\% Time Loading" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Memory(_Global_)\# Bytes in all Heaps" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Networking(_Global_)\Connections Established" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Remoting(_Global_)\Remote Calls/sec" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Jit(_Global_)\% Time in Jit" sampleRate="PT30S" />
  </PerformanceCounters>
  <WindowsEventLog bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M">
    <!-- The event log name is in the same format as the imperative 
           diagnostics configuration API -->
    <DataSource name="Application!*" />
    <DataSource name="System!*" />
  </WindowsEventLog>
</DiagnosticMonitorConfiguration>

Это конфигурация по умолчанию, записанная в blob-контейнер wad-control-container.

<?xml version="1.0"?>
<ConfigRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <DataSources>
    <OverallQuotaInMB>4080</OverallQuotaInMB>
    <Logs>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </Logs>
    <DiagnosticInfrastructureLogs>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </DiagnosticInfrastructureLogs>
    <PerformanceCounters>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions />
    </PerformanceCounters>
    <WindowsEventLog>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions />
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </WindowsEventLog>
    <Directories>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\FailedReqLogFiles</Path>
          <Container>wad-iis-failedreqlogfiles</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\LogFiles</Path>
          <Container>wad-iis-logfiles</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\CrashDumps</Path>
          <Container>wad-crash-dumps</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
      </Subscriptions>
    </Directories>
  </DataSources>
  <IsDefault>true</IsDefault>
</ConfigRequest>

Корпорация Майкрософт проводит интернет-опрос, чтобы выяснить ваше мнение о веб-сайте MSDN. Если вы желаете принять участие в этом интернет-опросе, он будет отображен при закрытии веб-сайта MSDN.

Вы хотите принять участие?
Показ:
© 2014 Microsoft