Поделиться через

Расширение событий мониторинга состояния ASP.NET

  • Статья

Обновлен: Ноябрь 2007

Можно выполнить следующие задачи для расширения функций мониторинга состояния ASP.NET:

Буферизация событий мониторинга состояния ASP.NET

Можно настроить SQL и поставщики событий мониторинга состояния почты (SqlWebEventProvider, SimpleMailWebEventProvider и TemplatedMailWebEventProvider) для использования буферизации событий. Это помогает снизить эффект выполнения приложения при частой отправке сообщений электронной почты или частых вставках на сервере SQL. Буферизация событий мониторинга состояния также предотвращает долгую загрузку SMTP-сервера и сервера SQL, которая может быть вызвана большим объемом события.

Буферизация поставщика событий SQL

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

По умолчанию поставщик SqlWebEventProvider не настроен, чтобы использовать буферизацию. Каждый раз при вызове события соответствующие сведения немедленно помещаются в базу данных. Можно переопределить данную настройку по умолчанию, включив буферизацию в элементе providers файла Web.config, в котором указан поставщик SQL. Это реализуется с помощью задания атрибуту buffer элемента add значения true. Если настраивать собственный поставщик SQL (то есть если не используется SqlWebEventProvider) и не указывать значение для атрибута buffer, то значением по умолчанию является значение true.

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

В следующем примере показаны параметры настройки поставщика событий SQL с включенной буферизацией.

Bb907646.alert_note(ru-ru,VS.90).gifПримечание.

Элемент AnalysisbufferModes уже настроен в корневом файле Web.config, не обязательно объявлять этот элемент снова на уровне приложения в файле Web.config. Элемент SqlWebEventProviderproviders также настроен в корневом файле Web.config, однако атрибуту buffer задано значение false и атрибуту bufferMode задано значение Notification. Поэтому элемент providers, показанный в данном примере, должен быть объявлен на уровне приложения в файле Web.config. Также необходимо использовать элемент clear или remove, чтобы удалить настройку на более высоком уровне для поставщика SqlWebEventProvider.

В данном примере поставщик SQL настроен на использование режима буфера Analysis при включенной буферизации, что определено в элементе bufferModes. В данном режиме сведения о событиях удаляются поставщиком каждые 5 минут. За одно уведомление поставщиком очищается до 100 событий, и вносится до 1000 событий в случае непредвиденного увеличения частоты событий. В любом случае события не отправляются поставщиком более одного раза в минуту.

<healthMonitoring>
  <providers>
    <clear/>
    <add 
      ConnectionStringName="LocalSqlServer" 
      maxEventDetailsLength="1073741823"
      buffer="true" 
      bufferMode="Analysis" 
      name="SqlWebEventProvider"
      type="System.Web.Management.SqlWebEventProvider,System.Web, Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" 
    />
  </providers>
  <bufferModes>
    <add 
      name="Analysis" 
      maxBufferSize="1000" 
      maxFlushSize="100"
      urgentFlushThreshold="100" 
      regularFlushInterval="00:05:00"
      urgentFlushInterval="00:01:00" 
      maxBufferThreads="1"
    />
  </bufferModes>
</healthMonitoring>

Буферизация поставщика событий электронной почты

Если включить буферизацию для поставщиков событий электронной почты, поставщики будут помещать события в буфер в качестве уведомлений о событиях перед отправкой сообщений электронной почты. Если настроить поставщик событий электронной почты и не указать значение для атрибута buffer элемента add для поставщика событий электронной почты, то задается значение по умолчанию true. Можно отключить буферизацию с помощью задания атрибуту buffer значения false.

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

В следующем примере показаны параметры конфигурации для поставщиков событий электронной почты с отключенной буферизацией для класса SimpleMailWebEventProvider и включенной для класса TemplatedMailWebEventProvider. Поставщик TemplatedMailWebEventProvider настроен на использование режима буферизации CriticalNotification, который уже настроен в корневом файле Web.config. В режиме CriticalNotification поставщиком предпринимаются попытки очистить все сведения о событиях во время их получения. Однако попытки очистки буфера не завершаются чаще, чем раз в минуту, чтобы предотвратить долгую загрузку сервера почтовых сообщений. Сообщения имеют управляемый размер. Сведения предоставляются максимум о 20 событиях.

Если система мониторинга состояния получает сведения о событиях в объеме большем, чем максимально допустимый, то самые старые события удаляются при поступлении новых событий. В системе мониторинга состояния предпринимаются попытки избежать пропуска событий. Это достигается более частой очисткой заполненного буфера. Однако если события пропускаются, то не предпринимаются попытки по отправке сведений для данных событий. (Тем не менее уведомления о пропуске событий включаются в следующий цикл очистки.) Более новые события будут задержаны максимум на пять минут при большой загрузке поставщика. Предполагается, что данные события не пропущены из-за полного буфера.

<healthMonitoring>
  <providers>
    <!-- mail provider with attributes that are always relevant -->
    <add 
      name="SimpleMailWebEventProvider" 
      type="System.Web.Management.SimpleMailWebEventProvider"
      to="SystemAdministrator@contoso.com"
      from="HealthMonitoring@contoso.com"
      buffer="false" 
    />
    <!-- mail provider with attributes that are relevant only 
         when buffering is enabled -->
    <add 
      name="SampleTemplatedMailWebEventProvider" 
      type="System.Web.Management.TemplatedMailWebEventProvider"
      to="SystemAdministrator@contoso.com" 
      from="HealthMonitoring@contoso.com" 
      buffer="true" 
      bufferMode="Critical Notification"
      template="Template.aspx" />
  </providers>
  <bufferModes>
    <add 
      name="Critical Notification" 
      maxBufferSize="100" maxFlushSize="20"
      urgentFlushThreshold="1" 
      regularFlushInterval="Infinite" 
      urgentFlushInterval="00:01:00"
      maxBufferThreads="1"
    />
  </bufferModes> 
</healthMonitoring>

Для выполнения данного примера необходимо настроить SMTP-сервер в файле конфигурации, как показано в следующем примере:

<system.net>
  <mailSettings>
    <smtp deliveryMethod="Network">
      <network 
        defaultCredentials="true" 
        host="127.0.0.1" 
        port="25" 
        username="username" 
        password="password" />
    </smtp>
  </mailSettings>
</system.net>

Дополнительные сведения см. в разделе Элемент <mailSettings> (параметры сети).

Bb907646.alert_note(ru-ru,VS.90).gifПримечание.

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

Параметры режима буферизации

Можно задать следующие атрибуты элемента add в элементе bufferModes, чтобы указать поведение буфера:

  • regularFlushInterval (интервал очистки сведений о регулярных событиях).

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

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

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

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

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

Использование инструментария WMI для отслеживания событий мониторинга состояния ASP.NET

Одним из способов мониторинга событий состояния ASP.NET является использование инструментария поставщика событий Windows Management Instrumentation (WMI) — класса WmiWebEventProvider. С помощью данного поставщика выполняется преобразование веб-событий мониторинга состояния (веб-событий) в события WMI. WMI предоставляет стандартную объектную модель, в которой сущности, для которых необходимо выполнить мониторинг, представляются как объекты. Этими сущностями могут быть компьютеры, сетевые карты, принтеры, приложения и т. д. Эти сущности сопоставляются в объектную модель WMI, так что мониторинг может быть выполнен пользовательскими приложениями. На следующей иллюстрации показаны отношения между веб-событиями ASP.NET, WMI и пользовательским событием, отслеживающим события WMI.

Отношения между ASP.NET и WMI
Архитектура WMI

Связь между событиями состояния и WMI

Мониторинг состояния ASP.NET предоставляет инфраструктуру для связи между событиями состояния и WMI. Это реализовано с помощью сопоставления этих элементов в классы WMI так, чтобы эти классы обрабатывались как объекты WMI. Также предоставлена поддержка обработки событий состояния и перенаправление этих событий в систему WMI. Подробные сведения о сопоставлении событий ASP.NET в WMI см. в разделе Пошаговое руководство. Прослушивание WMI-событий в мониторинге работоспособности ASP.NET. Дополнительные сведения об инструментарии WMI см. в разделе Windows Management Instrumentation веб-узла MSDN.

Ниже описаны шаги, которые необходимы для мониторинга событий состояния с помощью инструментария WMI:

  1. Определите соответствие между классами веб-событий и объектами WMI. Этот шаг уже выполнен для каждого стандартного класса веб-события. Эти соответствия содержатся в MOF-файле для ASP.NET (файл «%SystemRoot%\Microsoft.NET\Framework\<version>\aspnet.mof»).

    Bb907646.alert_note(ru-ru,VS.90).gifПримечание.

    Все пользовательские события сопоставлены типу базового события в WMI. Невозможно сопоставить пользовательское событие мониторинга состояния ASP.NET произвольному событию WMI.

    Например, в следующем коде показано определение класса WMI, который сопоставлен типу WebHeartbeatEvent:

    class HeartbeatEvent : ManagementEvent {
    /*
     * ProcessStatistics    
     */
    DATETIME    ProcessStartTime;
    sint32      ThreadCount;
    sint64      WorkingSet;
    sint64      PeakWorkingSet;
    sint64      ManagedHeapSize;
    sint32      AppdomainCount;    
    sint32      RequestsExecuting;
    sint32      RequestsQueued;
    sint32      RequestsRejected;
};

    Дополнительные сведения о MOF-файлах см. в разделе Managed Object Format раздела WMI SDK справки MSDN.

  2. Определите поставщика мониторинга состояния ASP.NET, который будет обрабатывать данные события.

    Стандартный поставщик является классом WmiWebEventProvider. По умолчанию этот поставщик уже настроен в разделе healthMonitoring корневого файла Web.config с помощью следующих элементов:

    <providers>
  <add 
    name="WmiWebEventProvider" 
    type="System.Web.Management.WmiWebEventProvider,System.Web, Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" 
  />
</providers>

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

    По умолчанию поставщик событий WMI не получает веб-событий. Можно использовать следующие элементы на уровне приложения в файле Web.config, чтобы подписать поставщик событий WMI на все веб-события.По умолчанию тип события All Events настроен в элементе eventMappings в корневом файле Web.config. Этот тип сопоставлен классу WebBaseEvent.

    <rules>
  <add 
    name="Testing Wmi"
    eventName="All Events" 
    provider="WmiWebEventProvider" 
    profile="Critical"
  />
</rules>

  4. Создайте приложение для отслеживания веб-событий или использования сторонних приложений.

    В примере кода в разделе Пошаговое руководство. Прослушивание WMI-событий в мониторинге работоспособности ASP.NET создается консольное приложение, которое выводит сведения о событиях всякий раз при вызове веб-события.

Настройка инфраструктуры событий состояния WMI

При возникновении веб-события с помощью мониторинга состояния ASP.NET это событие отправляется объекту WmiWebEventProvider. Объект поставщика обрабатывает и заполняет событие соответствующими данными в соответствии со связанным определением класса MOF. Затем поставщик отправляет эти данные системе WMI с помощью вызова неуправляемого кода.

Единственная возможность для отправки веб-событий в WMI — создание пользовательского приложения для приема событий мониторинга состояния ASP.NET после их выдачи событиям WMI. В этом случае необходимо внести только одно изменение в конфигурацию — настроить новый элемент rules так, как показано ранее. Приложение будет отслеживать события состояния ASP.NET в форме событий WMI так, как они выдаются операционной системой. Дополнительные сведения см. в разделе Пошаговое руководство. Прослушивание WMI-событий в мониторинге работоспособности ASP.NET.

Bb907646.alert_note(ru-ru,VS.90).gifПримечание.

Нельзя расширить класс WmiWebEventProvider. Классы поставщика события, которые можно расширить, — это WebEventProvider и BufferedWebEventProvider.

Реализация пользовательских событий мониторинга состояния ASP.NET и поставщиков

По умолчанию некоторые события уже перехвачены в счетчики безопасности, в журнал событий или оправлены в систему трассировки ASP.NET. Можно включить другие события, поставив в соответствие эти события существующим поставщикам. Дополнительные сведения см. в разделе «Consuming Web Events Using Event Providers» раздела Общие сведения о мониторинге работоспособности системы ASP.NET.

Если нет существующих веб-событий и поставщиков класса, которые соответствуют требованиям, можно расширить эти классы. В следующей таблице перечислены способы, с помощью которых можно настроить мониторинг состояния ASP.NET:

Задача

Реализация

Пример

Создание пользовательского класса веб-события.

Создание класса, производного от класса WebBaseEvent и реализующего виртуальный метод Raise. Чтобы добавить пользовательские данные в пользовательское событие, переопределите метод FormatCustomEventDetails.

Практическое руководство. Реализация и вызов пользовательских событий мониторинга состояния ASP.NET

Создание пользовательского поставщика событий для обработки встроенного пользовательского веб-события.

Создание класса, производного от класса WebEventProvider (или одного из наследованных классов). Если поставщик выполняет запись в журнал, необходимо также осуществить наследование от класса WebEventFormatter.

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

См. также

Задачи

Пошаговое руководство. Отключение параметров конфигурации ASP.NET

Основные понятия

Общие сведения о мониторинге работоспособности системы ASP.NET

Общие сведения о конфигурационном ASP.NET

Ссылки

Элемент bufferModes для элемента healthMonitoring (схема параметров ASP.NET)

Элемент providers для элемента healthMonitoring (схема параметров ASP.NET)