Исходники.Ру - Программирование
Исходники
Статьи
Книги и учебники
Скрипты
Новости RSS
Магазин программиста

Главная » Статьи по программированию » .NET - Framework »

Обсудить на форуме Обсудить на форуме

Мониторинг в инфраструктуре распределенных приложений .NET
Windows Management Instrumentation (WMI) — основная технология мониторинга для платформы Windows. Эта статья представляет собой введение в WMI и рассказывает о процессе мониторинга применительно к .NET-приложениям.

Информация на смежную тематику:

Амитаб Сривастава (Amitabh Srivastava) и Эдвард Джезирски (Edward Jezierski)
Корпорация Microsoft

Август 2001 г.

Аннотация: Windows Management Instrumentation (WMI) - основная технология мониторинга для платформы Windows. Эта статья представляет собой введение в WMI и рассказывает о процессе мониторинга применительно к .NET-приложениям.

Содержание

Введение

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

Показатели мониторинга (instrumentation metrics) в равной мере нужны обеим группам. На их основе операторы могут планировать пропускную способность системы и контролировать работоспособность, а разработчики - проектировать, создавать и оптимизировать высокопроизводительные приложения.

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

Ведение журналов ошибок (error logging) тесно связано с мониторингом и в основном является задачей разработчиков. Еще на ранних этапах разработки следует предусмотреть адекватную стратегию обработки ошибок. Более подробную информацию о создании в приложениях систем обработки ошибок с применением технологий .NET см. в Exception Management in .NET. Разработчики должны информировать операторов о типах журналов ошибок, создаваемых каждым приложением. В свою очередь операторы должны предоставлять разработчикам информацию об имеющихся механизмах мониторинга ошибок. Совместно обе группы выбирают подходящие механизмы ведения журналов и в соответствии с принятым решением разрабатывают приложения и осуществляют их мониторинг.

В некоторых ситуациях разработчики отделены от эксплуатационной группы и не могут взаимодействовать с операторами, ведущими мониторинг приложения в производственной среде. Применение общей объектной модели (common object model) позволяет исследовать управляемые объекты без прямого взаимодействия между авторами и пользователями.

Windows Management Instrumentation (WMI) - основная технология мониторинга на платформе Microsoft Windows®. Поскольку WMI встроена в Windows (а следовательно, и в .NET Framework), многие передовые технологии мониторинга можно реализовывать за счет взаимодействия с объектной моделью WMI через классы Framework Class Library.

Подробнее о WMI см. в Windows Management Instrumentation (WMI) SDK.

Мониторинг приложений необходим по двум важнейшим причинам. Во-первых, он позволяет обеспечить их корректную работу; такой контроль называется мониторингом состояния (health monitoring). Во-вторых, мониторинг рабочих характеристик (производительности) серверов дает возможность выявить тенденции их использования и соответственно совершенствовать или оптимизировать приложения.

Мониторинг состояния

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

Возможно, вы уже контролируете события в журнале событий Microsoft® Windows NT® или других журналах, отслеживая фатальные ошибки или предупреждения, которые могут сигнализировать о надвигающейся проблеме. Вы можете использовать инструменты сторонних поставщиков для мониторинга событий и пороговых значений параметров производительности (например, на определенном компьютере уровень загруженности процессора превышает 95%). Такие инструменты инициируют события различной значимости, реагируя на которые администраторы принимают то или иное решение. Вы также можете создавать собственные диагностические процедуры и инструменты мониторинга.

Мониторинг производительности

Счетчики производительности (performance counters) Microsoft Windows® позволяют приложениям и компонентам получать и анализировать данные о производительности, предоставляемые приложениями, службами и драйверами. С помощью этой информации можно определять потенциально узкие места в системе и осуществлять тонкую настройку производительности системы и приложения.

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

Процесс мониторинга

Схема процесса мониторинга

На рис. 1 показан процесс оснащения приложения инструментами контроля и мониторинга приложения и указаны применяемые технологии.

Analysis - Анализ
Application - Приложение
Common Services - Стандартные службы
Development - Разработка
Management - Управление
Requirements - Требования
Instrumentation - Средства мониторинга
Management Common Services - Стандартные службы управления
Custom/Proprietary Development - Разработка собственных средств
Managed Code - Управляемый код
Managed Envtronment - Управляемая среда

Рис. 1. Схема процесса мониторинга

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

  • Анализ
    Разработчики и операторы (A) совместными усилиями должны определить сценарии поведения и пороговые значения показателей для контролируемых приложений и сформулировать соответствующие требования. Проработка установленного набора требований и глубокий анализ системы позволяют сформировать стратегию мониторинга приложения. Результаты первоначального планирования нередко требуют дальнейшего уточнения.
  • Средства мониторинга приложения
    Затем приложение оснащается средствами контроля (B), предоставляющими счетчики производительности или объекты, публикующие события для уведомления подписчиков об определенных условиях и изменении состояния приложения.
  • Стандартные службы
    Технология, которая упрощает оснащение средствами мониторинга и сам мониторинг, называется WMI (C). WMI основана на промышленных стандартах и используется многими приложениями Microsoft. Такие пакеты для управления приложениями, как Microsoft Operations Manager (MOM), Application Center Server (AC) и Systems Management Server (SMS) используют преимущества стандартных служб вроде WMI и включаются в инфраструктуру операционной системы.
  • Технологии разработки
    Собственный код (D) можно создавать при помощи многочисленных технологий, таких как WMI SDK (E), управляемый код (F) и Microsoft Visual Studio® .NET (G). Он предоставляет вспомогательные инструменты для оснащения и мониторинга приложений.
  • Управление
    Приложения, оснащенные инструментами контроля, и системы мониторинга требуют развертывания и управления (H). Провайдеры WMI выступают в роли посредников между WMI и одним или несколькими управляемыми объектами, например добавленными к приложению на этапе 2. Потребители получают события и информацию, предоставляемую провайдерами.

Разработчикам, использующим .NET, не обязательно создавать провайдер для публикации данных или событий. Технология .NET Framework позволяет просто помечать (annotate) классы приложения как доступные для управления, что устраняет необходимость в полнофункциональных провайдерах.

Введение в WMI

Технология Microsoft Windows Management Instrumentation (WMI) - это реализация Desktop Management Task Force (DMTF) Web-Based Enterprise Management (WBEM) и DMTF Common Information Model (CIM).

WMI скрывает сложности, связанные с контролируемой средой. Схема CIM, также являющаяся стандартом DMTF, создает целостное и унифицированное представление различных типов логических и физических объектов в среде, в том числе программных компонентов, служб и принтеров. Объекты управления представляются в виде классов. Эти классы включают свойства, описывающие данные, и методы, определяющие поведение (behavior).

WMI следует парадигме "публикация-подписка". Провайдеры WMI, абстрагирующие низкоуровневые детали управляемых объектов, публикуют события, а потребители WMI (WMI consumers) подписываются на выбранные события и получают уведомления при их публикации. Провайдеры также могут предоставлять данные по требованию (on-demand data), отдельные объекты или наборы отдельных объектов по запросу потребителя.

Компоненты технологии

Технология WMI включает следующие компоненты.

  • Инфраструктура управления
    В нее входят диспетчер объектов CIM (CIM Object Manager, CIMOM) и репозитарий CIM, которые используются преимущественно для хранения определений схемы и связанной с провайдером информации (provider-binding information). Обычно данные принимаются динамически от провайдера по требованию.
  • Потребители WMI
    Компоненты и приложения-потребители следят за событиями WMI через CIMOM и позволяют вам выполнять действия в ответ на полученное событие.
  • Провайдеры WMI
    Выступают в роли посредников между CIMOM и нижележащими управляемыми объектами (включая ваши приложения и компоненты). Провайдеры взаимодействуют с объектной моделью WMI и предоставляют диспетчеру объектов CIM данные от управляемых объектов, обрабатывают запросы управляющих приложений и создают уведомления о событиях, сообщающие об изменении состояния управляемого объекта.

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

Events - События
Management Application (WMI Consumer) - Управляющее приложение (потребитель WMI)
CIM Object Manager (CIMOM) - Диспетчер объектов CIM (CIMOM)
CIM Repository - Репозитарий CIM
Providers - Провайдеры
Managed Object - Управляемый объект
Management Requests - Запросы управления

Рис. 2. Компоненты технологии WMI

Преимущества

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

  • вести мониторинг рабочего состояния приложения;
  • определять работоспособность системных компонентов;
  • измерять внутреннюю и общую производительность методом прямого опроса или через механизм уведомлений, оповещающий вас об изменениях;
  • настраивать параметры инициализации приложения, в том числе интервалы ожидания (таймауты), пороговые количества пользователей (user count thresholds) и строки подключения к базе данных;
  • группировать данные от подсистем управления, чтобы наглядно представить взаимосвязи между объектами.

Вот простой пример WMI-сценария на Microsoft Visual Basic® версии 6.0, который перечисляет устройства внешней памяти на локальном компьютере:

Set services = GetObject("winmgmts://localhost")
Set myenum = services.ExecQuery("select * from Win32_LogicalDisk")
´ Отображаем каждый диск в окне сообщения
For Each disk In myenum
  WScript.Echo (disk.DeviceID)
Next

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

Вот несколько примеров информации, хорошо подходящей для предоставления через WMI:

  • Информация о компонентах
    Включает названия производителей, номера версий и существующие обновления.
  • Статус компонентов
    Указывает, например, работает компонент, остановлен или отключен.
  • Информация о конфигурации
    Включает информацию, обычно хранящуюся в реестре Windows, или динамически изменяемые параметры периода выполнения.
  • Значимые события
    Например, отчеты об ошибках, неудачные попытки входа, существенные изменения состояния, записи NTEventLog, W2K Traces, события VISTA, трансляция SNMP MIB в события и т. д. Сюда же входят события изменения состояния объектов (внутренние события) и пользовательские события приложений и служб (внешние события).
  • Информация о производительности
    Включает показания счетчиков производительности и другие быстро изменяющиеся статистические данные.
  • Описание взаимосвязей между объектами
    Показывает, например, какие файлы используются базой данных, какие пользователи получают доступ к вашей службе или какой стек сетевых протоколов задействован вашим компонентом.

WMI применима и для настройки различных операций с приложением, например:

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

Архитектура

Рис. 3 иллюстрирует архитектуру WMI и дает примеры провайдеров и потребителей WMI. В верхней части схемы показаны примеры управляющих приложений (потребителей), которые могут представлять собой Web?приложения на основе браузеров (browser-based Web applications), оснастки Microsoft Management Console (MMC) или написанные вами Win32-приложения.

Database Application - Приложение, работающее с базой данных
Web Browser - Web-браузер
C/C++ Application - Приложение на C/C++
ODBC - ODBC
WMI Scripting API - WMI Scripting API
.NET API - .NET API
Management Infrastructure - Инфраструктура управления
COM/DCOM - COM/DCOM
CIM Object Manager (CIMOM) - Диспетчер объектов CIM (CIMOM)
CIMOM Repository - Репозитарий CIMOM
SNMP Provider - Провайдер SNMP
Win32 Provider - Провайдер Win32
Registry Provider - Провайдер реестра
WDM Provider - Провайдер WDM
.NET Instrumentation Provider - .NET-провайдер средств мониторинга
SNMP Instrumentation - SNMP-средства мониторинга
Registry Data - Данные реестра
WDM Driver - WDM-драйвер
Other Providers - Другие провайдеры
Miniport Driver - минипорт-драйвер
.NET Application - .NET-приложение
Win32 API - Win32 API

Рис. 3. Архитектура Windows Management Instrumentation

Внутренняя архитектура WMI включает диспетчер объектов CIM (CIMOM) и репозитарий объектов CIMOM, а также провайдеры WMI для среды Win32. Диспетчер объектов CIM управляет передачей информации между провайдерами и потребителями данных, такими как консоль SMS Administrator или приложение отчетов, вызывающее WMI Scripting API. Репозитарий объектов CIMOM хранит схемы CIM, используемые диспетчером объектов при обслуживании запросов приложений к объектам CIM.

Нестандартные Win32-приложения, как правило, обращаются напрямую к COM?интерфейсам для взаимодействия с диспетчером объектов CIM и создания управляющих запросов, тогда как другие приложения для своих запросов используют дополнительные способы доступа вроде Open Database Connectivity (ODBC), интерфейсы ADSI (Active Directory Service Interface) или WMI Scripting API (ранее известный как WBEM Scripting).

В нижней части схемы показаны примеры управляемых объектов и связанных с ними провайдеров; например, реестр Windows (Windows Registry) и сопоставленный с ним провайдер реестра (Registry Provider). Диспетчеры объектов CIM на локальном и удаленном компьютерах взаимодействуют через DCOM (Distributed Component Object Model). Более подробную информацию см. в WMI Architecture из Windows DDK.

Провайдеры и адаптеры

WMI SDK также включает встроенные провайдеры объектов и адаптеры приложений (application adapters). Управляющие приложения через встроенные провайдеры объектов могут получать доступ к данным и уведомлениям о событиях от различных источников, таких как системный реестр или устройства SNMP. При помощи адаптеров приложений управляющие приложения с разными программными интерфейсами могут получать доступ к репозитарию объектов CIMOM.

Встроенные провайдеры

Встроенные провайдеры предоставляют диспетчеру объектов CIM информацию из различных логических и физических источников, например, из системного реестра, от подсистемы Microsoft Win32® и устройства SNMP. Эти провайдеры включают:

  • провайдер Performance Monitor (Монитор производительности);
  • провайдер реестра;
  • провайдер событий реестра;
  • провайдер SNMP;
  • провайдер журнала событий Windows;
  • провайдер Win32;
  • провайдер WDM.

События

Любое управляющее приложение должно быть в основном событийно-управляемым. Это относится как к оперативному управлению (например, восстановление после сбоя), так и к превентивному управлению (например, упреждающее вмешательство, позволяющее избежать сбоя). События отражают значимые происшествия в управляемой среде. WMI поддерживает обнаружение событий и их доставку подписчикам.

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

  • Публикация
    Как узнать о произошедших событиях?
  • Подписка
    Как сообщить системе, что это событие мне интересно?
  • Доставка
    Как доставить событие подписчику?

В WMI клиентское приложение подписывается на событие, создавая запрос. Запросы - это естественный способ взаимодействия с классами, позволяющий сообщить WMI, какое событие (или события) вас интересует.

Доступ к управляющей информации WMI и API в .NET осуществляется через пространство имен System.Management.

WMI разделяет события на внутренние (intrinsic events), внешние (extrinsic events) и события таймера (timer events).

  • Внутренние события
    События, создаваемые WMI в ответ на внутренние изменения данных; например, на создание экземпляров класса, их модификацию или удаление. WMI получает информацию о внутренних событиях от репозитария CIM.
  • Внешние события
    Определяемые пользователем события, которые не описываются внутренними событиями.
  • События таймера
    События, возникающие в определенное время или через равные промежутки времени. В отличие от внутренних и внешних событий для возникновения события таймера приложение-потребитель должно объявить его явным образом.

Доставка событий

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

Сначала надо определить класс, моделирующий наблюдаемый объект, в данном случае - службу Win32. Просмотреть классы, их методы и свойства можно при помощи утилиты CIM Studio, поставляемой с WMI SDK. Просмотрев класс Win32_Service через CIM Studio, вы обнаружите свойство StartMode. В CIM Studio можно щелкнуть имя свойства правой кнопкой мыши и узнать допустимый диапазон значений этого свойства. Свойство StartMode может иметь значения Manual и Automatic. Имя службы содержится в свойстве Name, так что запрос на подписку будет выглядеть так:

Select TargetInstance.Name
From __InstanceModificationEvent
Within 10
Where TargetInstance isa ´Win32_Service´ and
    TargetInstance.StartMode = ´Manual´ and
    TargetInstance.Started = FALSE and
    PreviousInstance.Started = TRUE

Обратите внимание: в запросе используется значение PreviousInstance, чтобы определить, была ли служба запущена, а теперь остановлена. В запросе применяется блок Within, определяющий интервал, через который диспетчер объектов будет проверять появление события, и устанавливающий его равным 10 секундам. Чтобы различать события, предоставляемые провайдером событий, и события WinMgmt, можно запросить определенный набор данных и сравнить его с заданным запросом события.

Подписка на события

WMI предоставляет необходимую инфраструктуру для обнаружения событий и их доставки заинтересованным подписчикам. WMI содержит много стандартных подписчиков, на основе которых можно создавать сложнейшие обработчики событий. Так, WMI может использовать Microsoft Message Queuing (MSMQ) для надежной доставки событий. Она также включает стандартные подписчики, способные инициировать вызовы командной строки, которые, например, позволяют отправить сообщение по электронной почте при возникновении события.

Хотя WMI способна обнаруживать некоторые события самостоятельно, например изменения в репозитарии CIM, большинство событий распознаются провайдерами событий. Провайдеры событий (event providers) - это провайдеры WMI, следящие за источником событий и уведомляющие WMI при возникновении события. Примеры - провайдер ловушки SNMP (SNMP trap provider), провайдер журнала событий Windows (Windows Event Log provider) и провайдер событий реестра (Registry Event provider), уведомляющий WMI об изменении записей реестра.

Потребители WMI подписываются на выбранные события. В WMI предусмотрено два вида подписки на события: временная и постоянная.

  • Временная подписка
    Такие подписки создаются приложениями, подписывающимися на определенные события. Они существуют, пока выполняется приложение?потребитель. Так что временные подписки отменяются при закрытии подписавшегося приложения и удаляются при завершении работы потребителя.
  • Постоянная подписка
    Такие подписки создаются формирователями подписок (subscription builders) для выполнения некоего действия при каждом возникновении какого-либо события. Постоянные подписки в отличие от временных хранятся в репозитарии CIM и остаются активными до явного удаления формирователем подписок. Формирователь отменяет постоянную подписку, удаляя соответствующие объекты из репозитария CIM. Вы вправе создать постоянный подписчик, с тем чтобы при возникновении события WMI уведомила вас об этом через подписку. Например, можно оповещать оператора о каждой остановке определенной службы. В таком варианте постоянной подписки потребитель вызывается (загружается) WinMgmt при возникновении события (если к тому времени он еще не загружен).

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

Более подробную информацию см. в Windows Management Instrumentation (WMI) SDK.

Оснащение .NET-приложений средствами мониторинга

Оснащение средствами мониторинга (instrumentation) - это добавление в приложение событий управления (management events), счетчиков производительности (performance counters) и информации для трассировки (trace information), что позволяет инструментам мониторинга отслеживать текущее состояние и рабочие характеристики приложения. Также можно открывать доступ к классам, чтобы обеспечить возможность настройки приложения через WMI. Приложение оснащается средствами мониторинга для поддержки:

  • анализа производительности и профилирования исполняющей среды (runtime profiling);
  • диагностики;
  • конфигурирования приложения.

.NET предоставляет набор классов для оснащения приложения. Они еще больше абстрагируют вас от низкоуровневых деталей реализации WMI.

Добавление средств мониторинга в .NET-приложения

Пространство имен System.Management.Instrumentation позволяет сделать приложение управляемым через WMI с минимальными усилиями и помогает программно генерировать события WMI. Это пространство имен предоставляет типы для:

  • оснащения приложения;
  • предоставления событий приложения (на основе делегатов) как событий WMI;
  • создания управляемых объектов;
  • определения и использования взаимосвязей между управляемыми объектами.

Предоставление объектов приложения для управления должно быть интуитивно понятным .NET-программистам, поскольку схема WMI является объектно?ориентированной и имеет много общего с метаданными .NET. Поскольку объекты приложения могут быть напрямую сопоставлены объектам WMI, оснастить управляемый код средствами мониторинга довольно просто. Вы могли бы добавить в свое .NET-приложение средства мониторинга, например, для:

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

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

Поддержка базовых классов .NET

.NET Framework Class Library (FCL) содержит пространство имен System.Management.Instrumentation для оснащения .NET-приложений средствами мониторинга. Пространство имен System.Diagnostics позволяет создавать собственные счетчики производительности. Наконец, пространство имен System.Management содержит набор управляемых классов, через которые .NET-приложения могут легко получать доступ к управляющей информации и манипулировать ею. Подробнее об этих классах см. в разделе Мониторинг и поддержка .NET-приложений далее в статье.

На рис. 3 представлены три уровня архитектуры WMI. Эта иллюстрация также отражает, насколько легко и интуитивно понятно .NET-клиенты (вроде приложений Windows Forms и Web Forms) могут обращаться к средствам WMI через классы System.Management. Здесь же показано использование .NET-приложениями, оснащенными средствами мониторинга, классов пространства имен System.Management.Instrumentation для генерации событий и предоставления управляющих данных.

Monitoring Applications - Управляющие приложения
Win Form Apps - Приложения Windows Forms
Web Form Apps - Приложения Web Forms
Other - Другие
System.Management - System.Management
System.Management.Instrumentation - System.Management.Instrumentation
WMI Object Manager - Диспетчер объектов WMI
Class - Класс
WMI Repository - Репозитарий WMI
Instrumented .NET Apps - .NET-приложения, оснащенные средствами мониторинга
WMI Provider - Провайдер WMI

Рис. 4. Архитектура WMI в .NET

Использование .NET-атрибутов

.NET-атрибуты обеспечивают декларативный доступ к пользовательским событиям и классам, делая их управляемыми через WMI. Преимущество этого подхода в том, что он требует минимум дополнительного кода. Помечая класс через .NET-атрибуты как управляемый, вы создаете сопоставление со схемой WMI. Собственные классы событий можно наследовать от класса BaseEvent из пространства имен System.Management.Instrumentation.

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

Предоставление событий

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

  • Определить класс для события. Если управляемый класс вашего приложения уже содержит нужное событие (на основе модели делегатов) и это событие можно использовать и для администрирования, то нужно лишь пометить его для управления при помощи атрибута .NET Framework. В результате событию будет сопоставлен системный обработчик. Эта реализация обработчика инициирует событие WMI, отображая всю информацию, полученную от события приложения, на свойства события WMI.
  • Определить новый класс, производный от BaseEvent. Наследующий от BaseEvent класс содержит метод Fire, который можно использовать для инициации события. Если по каким-то причинам вы не хотите или не можете наследовать от этого базового класса, используйте вспомогательный класс Instrumentation, чтобы вызвать статический метод Fire и передать ему инициируемый объект.

В следующем коде на C# иллюстрируется второй подход и приводится пример определения нового класса, который представляет событие и инициирует его через класс Instrumentation:

using System;
using System.ComponentModel;
using System.Management.Instrumentation;
[assembly:Instrumented("root\\MyDemo")]

[System.ComponentModel.RunInstaller(true)]
public class MyProjectInstaller:DefaultManagementProjectInstaller
{
}

[InstrumentationClass(InstrumentationType.Event)]
// Классы событий управления наследуют от класса BaseEvent
public class MyBaseEvent : BaseEvent
{
   private string message;
   private int number;
   // Определяем свойства
   public string Message {
      get { return message; }
      set { message = value; }
   };
   public int Number {
      get { return number; }
      set { number = value; }
   }
}

public class TestWMI
{

   public static void Main()
   {
      MyBaseEvent ev = new MyBaseEvent();
      ev.Message = "This is a test event...";
      ev.Number = 12345;
// Инициируем событие статическим методом Fire
// системного класса Instrumentation
      ev.Fire();
   }
}

.NET предоставляет провайдеры для оснащения приложения и автоматически устанавливает их при запуске Installutil.exe после развертывания приложения (через пользовательскую установку по сценарию MSI или развертывание .NET Xcopy, требующее запуска EXE?файла вручную).

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

Схема приложения развертывается по сценарию MSI при запуске Installutil.exe или через Xcopy; в противном случае схема отсутствует, и события не инициируются и не потребляются.

В примере кода определяется класс управляемого кода MyBaseEvent, наследующий от BaseEvent. Метод Main класса TestWMI создает экземпляр события, устанавливает свойства и вызывает метод Fire класса Instrumentation для инициации события WMI. Этот класс можно динамически распознавать через схему приложения, а разработчик может управлять классом через обычные службы управления WMI. Кроме того, члены не обязательно должны быть свойствами: если они являются открытыми полями, они тоже будут сопоставлены объекту WMI.

Предоставление данных

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

Следующий пример кода на C# демонстрирует, как предоставлять классы .NET Framework в качестве данных мониторинга (instrumentation data) в среде .NET Framework.

using System.Management;
[assembly:Instrumented("root\\default")]

[InstrumentationClass(InstrumentationType.Class]
public class Product
{
  public String Name;
  public int InstallDate;
  public int Version;
  public String Vendor;
}

Здесь определяется класс Product, свойства которого определяют поля Name, InstallDate, Version и Vendor для описания установленных в компании приложений. При помощи атрибутов WMI открывает доступ к объекту, следовательно, любой разработчик может создавать его экземпляры и использовать встроенные сервисы WMI, такие как распознавание (discovery), опрос (querying) и фильтрация (filtering).

При создании экземпляра класса он не появляется в WMI до публикации. Это позволяет вам самостоятельно решать, когда экземпляр готов к публикации. Как правило, публикация - последнее действие в конструкторе класса (после всех операций по инициализации). Если вы создаете потомок от базового класса "Instance", то можете опубликовать свой экземпляр, установив свойство Published этого базового класса в TRUE. Если вы не наследуете от базового класса, вызывайте Instrumentation.Publish.

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

Счетчики производительности (performance counters) - механизм, посредством которого Windows собирает данные о работе различных системных ресурсов. Такой счетчик отслеживает объекты производительности (performance objects) на компьютере. К ним относятся физические компоненты (вроде процессоров, дисков и памяти), системные объекты (например, процессы и потоки), а также показатели, специфичные для приложения, такие как время транзакции, связанной с размещением заказа. Windows содержит предопределенный набор счетчиков производительности, с которыми можно взаимодействовать; некоторые из них есть на любом компьютере с Windows 2000, другие нужны лишь конкретным приложениям и поэтому могут отсутствовать на каких-то компьютерах. Счетчики группируются по отслеживаемым объектам (процессору, памяти, сети и т. д.) и показывают, например, каков процент загруженности процессора, как используется память или сколько байтов получено по сетевому соединению.

Счетчики производительности записывают значения различных параметров системы. Эта информация сохраняется до тех пор, пока соответствующий сервис присутствует в памяти. Процесс получения данных от счетчика производительности называется выборкой (sampling). При выборке вы получаете либо исходное, либо вычисленное значение счетчика.

В .NET встроено много счетчиков производительности, в том числе относящихся к общеязыковой исполняющей среде (Common Language Runtime, CLR) и к ASP.NET-приложениям.

Профилирование ASP.NET

ASP.NET предоставляет набор глобальных счетчиков производительности через ASP.NET-объект System. Эти счетчики накапливают данные о производительности для всех приложений ASP.NET, выполняемых на Web?сервере или Web?ферме. Информация, предоставляемая этими счетчиками, включает:

  • число приложений, выполняемых на Web?сервере;
  • среднее время ожидания запроса;
  • число активных сеансов;
  • число перезапусков приложения.

Кроме того, ASP.NET предоставляет счетчики, собирающие данные о производительности конкретного экземпляра приложения ASP.NET. Это может быть приложение Web Forms или Web?сервис. Информация, предоставляемая этими счетчиками, включает:

  • число полученных анонимных запросов;
  • число полученных аутентифицированных запросов;
  • информацию о кэше, например, соотношение попаданий и промахов кэша;
  • число компиляций (например, для файлов .aspx или .asmx);
  • число запросов, обрабатываемых в секунду;
  • статистику сеансов, например, общее число сеансов и число сеансов, завершенных из-за таймаута.

Утилита Web Application Stress (WAS) позволяет имитировать множество HTTP-запросов к Web?серверу. Ее можно скачать с Web-сайта WAS.

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

В пространстве имен System.Diagnostics есть классы для создания собственных счетчиков производительности. Например, такой счетчик можно использовать для измерения времени полного обмена данными в приложении (application round-trip). Это время, необходимое для обслуживания клиентского запроса и выполнения транзакции от имени клиента. Возможно, вы захотите измерить производительность отдельных операций, например время проверки подлинности кредитной карты.

Пространство имен System.Diagnostics содержит следующие типы, относящиеся к мониторингу производительности:

  • Класс PerformanceCounter
    Управляет системными и нестандартными счетчиками производительности.
  • Класс PerformanceCounterCategory
    Представляет категорию счетчиков производительности.
  • Класс PerformanceCounterInstaller
    Указывает установщик для компонента счетчика производительности.
  • Класс PerformanceCounterManager
    Подготавливает счетчики производительности для анализа.
  • Перечислимое PerformanceCounterType
    Идентифицирует тип счетчика производительности, например, измеряет он среднее значение какого-то показателя, сообщает суммарное значение или замеряет истекшее время.

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

Вот несколько способов организации доступа к счетчикам производительности:

  • через Windows-приложения или собственные приложения;
  • через интерфейсы WMI и сценарии;
  • программно через COM?интерфейсы, определенные в Platform SDK.

Более подробную информацию о мониторинге счетчиков производительности см. в разделе Мониторинг и поддержка .NET-приложений этой статьи.

Трассировка

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

Пространство имен System.Diagnostics включает классы, поддерживающие трассировку. Классы Trace и Debug из этого пространства имен содержат статические методы, на основе которых можно дополнить приложение средствами трассировки и собирать информацию о ходе выполнении программы. Трассировку можно использовать и для сбора статистики по производительности. Чтобы задействовать эти классы, определите символ TRACE или DEBUG в коде (при помощи #define) либо через параметры командной строки компилятора.

По умолчанию вывод трассировки направляется в консоль. Классы позволяют легко перенаправить эту информацию в журнал событий Windows. Можно также создать свой слушатель трасссировки (trace listener), перенаправляющий вывод в другое место.

Трассировка ASP.NET

ASP.NET поддерживает множество функций трассировки. Данные о производительности и пользовательские трассировочные сообщения можно присоединять в формате HTML к возвращаемому потоку HTML.

Для работы с трассировочной информацией ASP предоставляет класс TraceContext. В ее состав входят сведения о времени различных фаз жизненного цикла страницы и пользовательские сообщения. Класс TraceContext доступен через свойство Trace класса Page. Трассировкой страницы можно управлять через атрибут Trace директивы @Page, а трассировкой приложения - через параметры файла Web.config. Так, следующие параметры включают сбор информации трассировки не более чем для 20 запросов и позволяют отображать в браузере операторы трассировки, написанные с использованием Trace.Write:

<configuration>
 <system.web>
  <trace enabled="true" requestLimit="20" pageOutput="true"/>
 </system.web>
</configuration>

Трассировка событий в WMI

WMI также поддерживает трассировку событий. Объем и тип данных, а также место их хранения динамически контролируются WMI. Для использования механизмов трассировки WMI необходимо описать классы трассировки событий в репозитарии CIM, а затем использовать API трассировки событий WMI. Более подробную информацию о трассировке событий в WMI см. в документации WMI SDK.

Применение счетчиков производительности в сочетании с трассировкой событий

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

WMI предоставляет целостную инфраструктуру для оснащения приложений средствами мониторинга и трассировки. Ниже описывается базовая схема оснащения приложений этими средствами.

  1. Определите требования.
  2. Проверьте, не реализованы ли они кем-то другим. Если так, ваша работа закончена.
  3. Четко определите, откуда поступает информация, и составьте список отдельных элементов данных.
  4. Сгруппируйте элементы так, чтобы каждая группа целиком зависела от одного из элементов группы; такой элемент называется ключом (key).
  5. Проверьте, нет ли какой-либо из созданных групп в существующей схеме.
  6. Проверьте, нельзя ли разбить класс на подклассы.
  7. Создайте собственную схему.
  8. Определите, какие части схемы будут представляться как данные, а какие - как события. Следующие варианты не являются взаимоисключающими.
    • Провайдер экземпляров (instance provider). Если есть динамические экземпляры, которые создаются и удаляются с течением времени, применяйте провайдер экземпляров.
    • Провайдер событий (event provider). Если вам нужна эффективная реализация обработки событий, применяйте провайдер событий.
  9. Определите .NET-классы для этих объектов и событий и пометьте их соответствующими атрибутами. В нужных местах приложения создавайте и публикуйте экземпляры объектов данных и инициируйте события.
  10. Протестируйте и разверните приложение, оснащенное средствами мониторинга и трассировки.

Примеры

// Определение класса предоставляется в виде метаданных управления (схемы)
using System.Management
[assembly:Instrumented("root\cimv2")]

[InstrumentationClass(InstrumentationType.Event)]
class Class PowerMgmtEvent : BaseEvent
{
         string ComputerName; // компьютер, на котором произошел сбой
         datetime Time;    // время сбоя
         int Type;   // приостановка и продолжение
         // продолжение автоматическое при изменении состояния питания
};


// Событие инициируется из приложения

PowerMgmtEvent p = new PowerMgmtEvent();
ComputerName = "\\Mycomputer";    
      // Компьютер, на котором произошел сбой
Time = "";          // время сбоя
Type = 3;         // приостановка и продолжение
            // продолжение автоматическое при изменении состояния питания
Fire();

Безопасность

Провайдеры потребуется загрузить в подсистему провайдеров (provider subsystem) с учетной записью NetworkService. Эта учетная запись предназначена для служб, которым не нужны особые привилегии, но которые должны удаленно взаимодействовать с другими системами. Применение этой учетной записи устраняет риск захвата контроля над компьютером (или доменом, в случае контроллера домена) поврежденным или скомпрометированным провайдером. Это также предотвращает возможность передачи привилегированной информации пользователю в случае, если провайдер неверно олицетворяет клиентский контекст. Размещение провайдеров вне процесса гарантирует, что сбой одного из них отразится только на провайдерах того же хоста и не затронет критический процесс WinMgmt. Жизненный цикл хоста провайдеров полностью контролируется WinMgmt, который автоматически перезапускает хост, если тот по какой-то причине прекращает работу. Это увеличивает отказоустойчивость WMI для приложений, зависящих от ключевых сервисов, предоставляемых WMI.

Поскольку провайдер оснащения .NET выполняется в процессе оснащенного приложения, он использует новую технологию WMI, которая называется "отсоединенный провайдер" (decoupled provider). Это особый тип провайдеров, чей срок жизни контролируется не WMI, а приложением. Кроме того, есть различия в контексте защиты (security context), используемом этим провайдером. Классические провайдеры, загружаемые и выгружаемые WinMgmt и выполняемые на контролируемом хосте, могут и должны олицетворять вызывающего клиента при получении информации для него. В случае с отсоединенными провайдерами (поскольку они размещаются в приложении, которое может быть запущено любым пользователем) олицетворение не допускается и поддерживается только подключение с идентификацией (identify-level connection). Провайдер действует лишь в контексте пользователя, запустившего приложение, и выполняет проверку доступа для идентификации вызывающего клиента перед отправкой запрошенной информации управления. В механизме регистрации отсоединенный провайдер предоставляет дескриптор защиты (security descriptor) для определения пользователей, имеющих право предоставлять информацию этому приложению.

Средства мониторинга и многоуровневые приложения

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

Например, такая ситуация может возникнуть в средах, расположенных в пограничной сети [которую еще называют DMZ - демилитаризованной зоной или экранированной подсетью (screened subnet)], где Web?серверы расположены перед брандмауэром. Эти серверы могут собирать и хранить управляющую информацию, а затем отправлять ее периодически (не в режиме реального времени). Это делается для повышения безопасности и снижения трафика через брандмауэр.

Управление кэшем подразумевает возможность определения источники данных и опроса их (тем или иным способом) для заполнения кэша.

Вот некоторые действия, которые могут быть связаны с управлением кэшем:

  • Получение снимка (snapshot)
    Вероятно, лучшим решением будет создание "несфокусированного" снимка ("fuzzy" snapshot) системы, в котором содержится вся информация о состоянии системы и всех изменениях этого состояния за период снятия снимка; после формирования снимка к нему применяются все изменения, чтобы привести его в соответствие с текущим состоянием.
  • Опрос
    Данные в кэше можно актуализировать (приводить в соответствие с текущим состоянием) путем опроса (polling). Система управления кэшем периодически опрашивает источники данных и получает информацию об изменениях с момента последнего запроса, принимая данные от источника только в том случае, если с момента внесения данных в кэш в источнике произошли изменения.
  • Использование событий
    Актуальность данных в кэше можно поддерживать, зарегистрировавшись на получение любых значимых событий источника данных. Если источники данных поддерживают WMI и эффективное использование событий, этот способ предпочтительнее опроса. Он требует надежной доставки событий (например, через очередь сообщений), иначе снимок может потерять синхронизацию, и в отсутствие периодических обновлений данные станут ненадежными.
  • Опрос и события
    Также имеет смысл совмещать опрос и события, используя события источников данных для получения значительных изменений в среде, а обновления - для периодического сбора информации о расхождении значений. Одна из крупнейших проблем с периодическим опросом в том, что такой опрос серьезно влияет на производительность источника данных при сборе информации, поскольку в этот момент нужно проверить состояние большой части системы. Преимущество использования событий - нагрузка распределяется на большой период времени и опрашивается только та часть системы, где действительно произошли изменения. Сами события должны быть реализованы эффективно и не полагаться на опрос.

Для эффективного масштабирования системы в целом любое крупномасштабное распределенное приложение также должно поддерживать агрегацию и фильтрацию на каждом уровне системы. WMI предоставляет механизмы для выражения агрегатных отношений (aggregated relationships) через использование провайдеров и постоянных потребителей событий (permanent event consumers). При этом вы должны планировать эффективную длительность, частоту и детализацию управляющих данных.

Мониторинг и поддержка .NET-приложений

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

  • получать события;
  • получать (или обновлять) данные.

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

  • регистрируясь на получение событий;
  • запрашивая конкретный набор экземпляров объектов;
  • перечисляя экземпляры или классы;
  • получая определенные экземпляры;
  • запуская методы.

Потребитель полностью отделен от источника данных. Он может быть написан на любом языке (C#, Managed C++, Visual Basic .NET, C/C++, языках Windows Script Host) и реализован в виде приложения Windows Forms, Web Forms или Web?сервиса.

Потребление управляющей информации

Потребление такой информации упрощается благодаря классам из пространства имен System.Management. На рис. 3 показаны приложения Windows Forms и Web Forms, выступающие в роли потребителей WMI. Как потребитель WMI, клиент Windows Forms или Web Forms может следить за состоянием приложения, ходом его работы и конфигурацией. Эти возможности поддерживаются набором многофункциональных инструментов WMI, встроенных в среду разработки Microsoft® Visual Studio® .NET.

Пространство имен System.Management

Пространство имен System.Management предоставляет различные типы для поддержки операций WMI:

  • ManagementObject или ManagementClass
    Отдельный объект или класс управления соответственно.
  • ManagementObjectSearcher
    Используется для получения набора ManagementObjects или ManagementClasses на основе определенного запроса или перечислимого.
  • ManagementEventWatcher
    Используется для подписки на уведомления о событиях от WMI.
  • ManagementQuery
    Используется как основа для всех классов запросов.

Для доступа к информации о компьютерах или приложениях .NET-разработчики могут использовать имеющиеся знания, поскольку WMI везде, где это возможно, опирается на стандартную базовую инфраструктуру. Принципы кодирования на основе классов System.Management являются естественными для среды .NET.

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

В следующем коде на C# набор классов System.Management применяется для перечисления служб на компьютере. В данном случае используются некоторые настройки по умолчанию, так что на локальном компьютере задействуется пространство имен WMI root\cimv2. Пример возвращает набор всех объектов указанного класса (Win32_Service). После получения набора клиентский код перебирает его в цикле foreach и отображает имя и состояние каждой службы из набора - для этого достаточно всего двух строк кода.

using System;
using System.Management;
using System.IO;

class WMI_Service_Example
{
   public void EnumerateServices
   {
Console.WriteLine("List services and their state");

// Запрашиваем набор служб
ManagementObjectSearcher s = new
ManagementObjectSearcher(new SelectQuery("Win32_Service"));   
   // Перебираем набор
   foreach (ManagementObject service in s.Get())
      Console.WriteLine("Service: "+service["Name"]+" is
      "+service["State"]);

   return;
    }
}

Обработка событий WMI

При создании подписки на события WMI подписчик должен сообщить следующую информацию:

  • какие события его интересуют;
  • что должна делать WMI при возникновении этих событий.

Лицо или приложение, создающее подписку, называется формирователем подписки (subscription builder), а код, получающий событие, - потребителем события (event consumer).

Обрабатывая события WMI, можно выполнять определенные действия при изменениях в управляемой среде. Например, в подписке можно связать потребителя X с событиями A и B. Тогда этот потребитель будет получать уведомления о каждом событии A и о каждом событии B. События A и B могут быть не связаны между собой. Ниже приводится список некоторых сценариев мониторинга.

  • Сценарии статистического анализа
    В сценариях статистического анализа (statistical analysis scenarios) накапливаются и хранятся совокупные данные о бизнес-операциях. Так, для Интернет?портала ведение журнала для всех возникающих событий может оказаться слишком накладным. Однако в этом случае имеет смысл записывать статистические данные, например, о ежедневном использовании Web, ежедневную статистику по использованию каждого URL и каждой ссылки.
  • Сценарии контроля состояния
    В сценариях контроля состояния (health-monitoring scenarios) некоторые события не представляют проблемы, пока частота их возникновения не превышает определенный порог. Например, несколько ошибок в час на сетевом устройстве не считаются проблемой. Однако, если их число превышает 100 в час, об этом уведомляются сетевые администраторы. В других сценариях контроля состояния используется мониторинг пороговых значений показателей и тенденций (threshold and trend monitoring).
  • Сценарии срабатывания политики
    Сценарии срабатывания политики (policy condition scenarios) вводят в действие соответствующую политику, когда в системе возникают некие условия. Так, для кластера из двух компьютеров может быть определена политика, предписывающая в случае сбоя одного из компьютеров автоматически переносить нагрузку на второй компьютер и уведомлять об этом системного администратора.

Создание временного потребителя событий

Следующий фрагмент кода на C# иллюстрирует несколько временных потребителей событий.

Мониторинг журнала событий NT

// Этот код демонстрирует, как отслеживать в журнале событий NT
// появление новых событий
using System.Management;

WQLEventQuery q = new WQLEventQuery("InstanceCreationEvent",  
                         "TargetInstance ISA ´Win32_NTLogEvent´")

// Следим за событиями NT в NTEventLog
ManagementEventWatcher w = new ManagementEventWatcher(q);
w.EventArrived += h.EventArrived;
w.Start();
…
w.Stop();

// Определяем обработчик события
public void EventArrived(Object sender, EventArrivedEventArgs e)
{
   // Получаем объект Event и отображаем его
   Console.WriteLine("NTEvent "+e.Event["Message"]");
}

Мониторинг уровня загруженности процессора

// Этот код демонстрирует, как отслеживать процессы, загружающие
// процессор более чем на 80%, и принудительно завершать их
ManagementEventWatcher w = new ManagementEventWatcher("SELECT * FROM 
__InstanceDeletionEvent WITHIN 4 WHERE TargetInstance ISA Win32_Process");
w.EventArrived += h.EventArrived;
w.Start();
…
w.Stop();

// Определяем обработчик события
public void EventArrived(Object sender, EventArrivedEventArgs e)
{
// Получаем объект Event и отображаем его
   Console.WriteLine("Process " + e.Event["Message"] + 
             has terminated");

Мониторинг дискового пространства

WQLEventQuery q = new 
WQLEventQuery("__InstanceModificationEvent", "600", 
      "TargetInstance ISA ´Win32_LogicalDisk´ AND 
      PreviousInstance.FreeSpace    >= 5000000 AND 
      TargetInstance.FreeSpace < 5000000")

// Следим за событиями NT в NTEventLog
ManagementEventWatcher w = new ManagementEventWatcher(q);
w.EventArrived += h.EventArrived;
w.Start();
…
w.Stop();

// Определяем обработчик события
public void EventArrived(Object sender, EventArrivedEventArgs e)
{
       // Получаем объект Event и отображаем его
       Console.WriteLine("Disk " + e.Event["Name"] + 
                          is below 5MB of free space ");
}

Использование Performance Monitor (PerfMon)

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

Использование прикладных пакетов для мониторинга

Пакеты управляющих приложений типа Microsoft Operations Manager (MOM) способны вести мониторинг ошибок и автоматически реагировать на них вызовом методов уведомлений. Важно заранее продумать, будет ли использоваться один из таких инструментов для мониторинга ваших распределенных приложений. Если такие пакеты у вас есть, примите во внимание, что большинство из них:

  • накапливает информацию об индивидуальных серверах в общесистемных агрегациях (system-wide aggregations);
  • отображает журналы событий и информацию о производительности от нескольких серверов на одном экране;
  • основано на WMI, или же они предоставляют собственные агенты управления.

Microsoft создает архитектуру следующего поколения управляющих сервисов для Windows?систем и .NET Enterprise Servers. Сервисы будут опираться на существующие инструменты управления в Windows 2000, Systems Management Server и Microsoft Operations Manager (MOM). Эти инструменты позволят вам ускорить вывод ваших продуктов на рынок, сократить потребность в дополнительном административном программном обеспечении и упростят работу с Windows?приложениями.

Microsoft Application Center (AC)

Microsoft Application Center - это инструмент для развертывания и управления Web?приложениями для Windows. С его помощью можно легко устанавливать и управлять Web?приложениями в кластерах серверов, включая Web?серверы. Он позволяет этим приложениям достигать требуемых показателей масштабируемости и доступности за счет программного масштабирования, уменьшая сложность их эксплуатации и затраты на нее. Application Center дает возможность управлять группой серверов так же просто, как отдельным сервером.

Более подробную информацию см. по ссылке Microsoft Application Center.

Microsoft Application Center поддерживает WMI. Он потребляет и инициирует события WMI, облегчая интеграцию с другими приложениями и средствами системного администрирования, поддерживающими WMI. Application Center включает Health Monitor со следующими предустановленными средствами мониторинга производительности системы.

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

Application Center с помощью Health Monitor может собирать информацию о системе, применять к ней определенные правила и выполнять различные действия (вроде отправки сообщений по электронной почте, программных операций и генерации событий) при нарушении этих правил.

Application Center и WMI

Возможны следующие варианты совместной работы Application Center и WMI.

  • Приложения могут предоставлять события WMI, интегрируемые с Application Center.
  • Провайдеры WMI в Application Center:
    • счетчики производительности;
    • журнал событий;
    • службы/процессы;
    • COM+-приложения;
    • HTTP- и FTP-запросы;
    • ICMP, SMTP …

Microsoft Operations Manager (MOM)

Microsoft Operations Manager - управляющее приложение, которое использует сервисы WMI. MOM обеспечивает централизованное управление приложениями и мониторинг системы.

Более подробную информацию см. на Web?сайте Microsoft Operations Manager.

Microsoft Operations Manager применим для:

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

Microsoft Operations Manger поддерживает ответы на события (event responses). Например, MOM может обновить переменную состояния (state variable), запустить командный или пакетный файл, выполнить сценарий. Кроме ответов на события, Microsoft Operations Manger может генерировать оповещения (alerts). Вот примеры таких оповещений:

  • отправка сообщения по электронной почте;
  • отправка сообщения на пейджер;
  • срабатывание ловушки SNMP (SNMP trap).

Microsoft Operations Manager и WMI

Несколько примеров запросов событий WMI (WMI Event Queries), используемых в Microsoft Operations Manger:

События изменения состояния (State Change Events)

  • В следующем примере через каждые 10 минут проверяется, не упал ли объем свободного пространства на каком-либо логическом диске ниже 10 Мб:
    Select * from __instancemodificationevent WITHIN 600 
    WHERE TargetInstance ISA ´Win32_LogicalDisk´ AND 
    TargetInstance.FreeSpace < 10000000 AND 
    PreviousInstance.FreeSpace > 10000000
    
  • Опрос. События инициируются изменениями в данных экземпляра.

Системные события (System Events)

  • В следующем примере генерируется событие при возникновении в системе события, связанного с управлением питанием:
    Select * from Win32_PowerManagementEvent
    

    Получаемое событие является объектом Win32_PowerManagementEvent. Опрос не требуется; событие инициируется уведомлением.

Simple Network Management Protocol (SNMP)

  • Ловушки SNMP интегрируются с MOM через WMI. WMI?провайдер SNMP преобразует данные SNMP в WMI. События инициируются ловушками SNMP или опросом SNMP-данных. Из следующих примеров видно, что регистрация событий в MOM осуществляется так же, как в WMI.
  • Ловушка:
    Select * from SnmpLinkDownNotification
    
  • SNMP-данные:
    Select * from __instancecreationevent WITHIN 60 WHERE 
    TargetInstance ISA ´SNMP_RFC1213_MIB_ipRouteTable´
    
  • Если вам необходимы стандартные RFC MIB, то WMI SDK уже содержит почти 40 MIB, преобразованных в MOF. Если вам нужен корпоративный MIB или такой, которого нет в SDK, преобразуйте MIB в MOF при помощи утилиты SMI2SMIR, поставляемой с провайдером SNMP. Затем выполните следующие действия:
    • загрузите MOF в WMI при помощи MOFCOMP;
    • настройте адрес целевого устройства, строку сообщества (community string) и т. д. (согласно WMI SDK);
    • настройте MOM на прием ловушек и изменений состояния как событий WMI (см. предыдущий раздел).

Managed Object Format (MOF)

MOF - компилируемый язык для определения статических или динамических классов и экземпляров классов. Эти определения размещаются в текстовом файле, который обрабатывается MOF?компилятором, Mofcomp.exe. Компилятор MOF анализирует файл и добавляет определенные в нем классы и экземпляры в репозитарий CIM. Более подробную информацию см. в разделе Managed Object Format (MOF) документации Platform SDK.

Microsoft Systems Management Server (SMS)

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

Более подробную информацию см. на Web?сайте Microsoft Systems Management Server.

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

  • инвентаризацию аппаратного обеспечения на основе WBEM;
  • дистрибуцию и установку программного обеспечения;
  • удаленный анализ производительности и устранение неисправностей;
  • утилиту Network Tracing Topology (NetTrace);
  • утилиту Network Monitor (NetMon).

SMS и WMI

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

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

Сторонние инструменты управления

Microsoft продолжит расширение спектра служб управления Windows и разработки собственных решений по управлению, основанных на этих службах, в ключевых для заказчиков областях. Как уже говорилось в данном документе, это лишь малая часть решений по управлению для удовлетворения всех потребностей IT?администраторов.

Открытость служб управления Windows позволит выйти на новые уровни интеграции систем управления. Благодаря этому удастся не только интегрировать операционные инструменты (operations-based tools), но и объединить их с программным обеспечением уровня служб и управления бизнес-логикой (service-level and business management tools), а также с популярными платформами администрирования. Это в свою очередь позволит создать истинно корпоративные решения в области управления.

В прошлом сторонним разработчикам приходилось тратить массу времени на создание низкоуровневой инфраструктуры для поддержки собственных средств управления. Это не только отнимало время, которое можно было бы потратить на создание дополнительных функций самих средств управления, но и ограничивало степень возможной интеграции различных средств даже при использовании решений в зонтичном стиле (umbrella-style management solutions). Теперь, используя службы управления Windows, разработчики решений могут сосредоточиться на создании функций управления и не тратить время на низкоуровневую инфраструктуру, поскольку вся необходимая функциональность уже есть в самой операционной системе.

Visual Studio .NET

Новые возможности Visual Studio .NET превращают ее в полнофункциональную среду разработки приложений Microsoft .NET Framework. Она включает такие инструменты, как Visual Studio Analyzer и Server Explorer, при помощи которых можно вести мониторинг .NET-приложений.

Visual Studio .NET Server Explorer

Server Explorer - это инструмент Visual Studio .NET, позволяющий просматривать управляющие объекты и манипулировать ими. Он также служит для создания кода в контексте дизайнеров Windows Forms и Web Forms. В интегрированной среде разработки (IDE) Visual Studio узлы Server Explorer взаимодействуют с браузером свойств (Property Browser) и дизайнером компонентов (component designer). Этот инструмент предназначен для просмотра классов и экземпляров, изменения значений свойств, запуска методов и генерации управляемого кода (методом drag-and-drop). В отличие от CIM Studio проектирование схем не поддерживается, и изменение сигнатуры методов WMI не допускается.

Стандартные узлы в окне Server Explorer не используют WMI. Однако добавление узлов Management Data и Management Events, предоставляющих доступ к данным WMI и позволяющим подписываться на события, расширяет стандартную функциональность. Это расширение появится в будущих обновлениях Visual Studio .NET. Оно необходимо для поддержки функциональности WMI.

Взаимодействие Server Explorer с дизайнером компонентов осуществляется через операции drag-and-drop (простым перетаскиванием элементов). Некоторые узлы можно перетащить в дизайнер формы. При этом в форме генерируется код, ссылающийся на компонент. В дополнение к создаваемому в форме коду существует так называемый генератор кода объектов со строгим контролем типов (strongly-typed objects code generator). Эту функциональность можно использовать программно через API в System.Management.ManagementClass, через утилиту командной строки mgmtclassgen.exe из .NET SDK или методом drag-and-drop в Server Explorer. Она создает класс управляемого кода со строгим контролем типов для заданного класса WMI.

Например, при вызове WMI-класса Win32_LogicalDisk генерируется класс управляемого кода LogicalDisk, содержащий все свойства и методы WMI-класса. Сгенерированный код включается в проект приложения, и теперь пользователь может писать код со строгим контролем типов для объекта WMI, задействовав все преимущества вспомогательных средств разработки в Visual Studio, таких как автозавершение выражений (statement completion). Например, вместо кода System.Management с поздним связыванием (late-bound):

ManagementObject o = new ManagementObject("Win32_LogicalDisk=´C:´");
Console.WriteLine(o["FreeSpace"]);

Или вызова метода:

O.InvokeMethod("MethodFoo");

Теперь можно написать:

LogicalDisk d = new LogicalDisk("C:");
Console.WriteLine(d.FreeSpace);

И вызвать метод так:

d.MethodFoo();

Поддержка SNMP

SNMP (Simple Network Management Protocol) - протокол управления, используемый для взаимодействия между станциями и агентами управления. Управляющая информация хранится в базе данных Management Information Base (MIB).

Windows Management Instrumentation SDK включает следующие компоненты для поддержки SNMP:

  • провайдеры классов, экземпляров и событий;
  • SNMP Information Module Compiler.

При помощи провайдеров SNMP, включенных в Windows Management Instrumentation SDK, клиентские приложения могут получать доступ к статической и динамической информации SNMP через диспетчер объектов CIM. Провайдеры классов и экземпляров SNMP интегрируют в WMI средства моделирования и обработки информации SNMP.

  • Эти провайдеры SNMP отображают наборы значений объектов на значения свойств экземпляров классов CIM.
  • Они генерируют события WMI на основе уведомлений и ловушек SNMP. Провайдеры сообщают о тех же типах событий, но в разных форматах.

ActiveX-элементы

Windows Management Instrumentation SDK включает набор ActiveX?элементов (ActiveX controls), использующих WMI API для выполнения логически связанных функций. С помощью ActiveX?элементов можно предоставлять функциональность графического пользовательского интерфейса в клиентских приложениях WMI.

Более подробную информацию см. в разделе Windows Management Instrumentation документации SDK.

Заключение

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

Благодарности

Выражаем глубокую признательность следующим участникам и рецензентам:

Travis Muhlestein, Corina Feuerstein, Michael Matson, Steve Busby, Kenny Jones, Jeff Kercher, Chris Brooks, David Keogh, Bart Robertson, Ann Chung, Edward Jezierski, Alex Mackman (Content Master), David Bernstein (Sapient), Bernard Chen (Sapient).

Вопросы? Комментарии? Предложения? С любыми вопросами по этой статьи, пожалуйста, обращайтесь по адресу devfdbck@microsoft.com.

Чтобы лучше освоить передовой опыт применения .NET, вы можете обратиться к экспертам по технологиям в Центре технологий Microsoft в вашем регионе. За более подробной информацией, пожалуйста, обращайтесь на Web-страницу Microsoft Technology Centers.


Может пригодится:


Автор: Amitabh Srivastava
Прочитано: 11007
Рейтинг:
Оценить: 1 2 3 4 5

Комментарии: (0)

Добавить комментарий
Ваше имя*:
Ваш email:
URL Вашего сайта:
Ваш комментарий*:
Код безопастности*:

Рассылка новостей
Рейтинги
© 2007, Программирование Исходники.Ру