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

. К примеру, является ли сервер работоспособным в период, когда он не функционирует? В ситуации, когда он некорректно настроен? В случае нарушения его системы безопасности? Чем больше условий мы добавим к нашему определению работоспособного сервера, тем полезнее будет наша модель работоспособности при оценке состояния серверов. Создание модели работоспособности сервера чем-то напоминает работу над картиной, изображающей сервер, каким он должен быть: сначала мы делаем грубый набросок сервера, потом одну за другой прорабатываем детали, и наш набросок превращается в полноцветное полотно с изображением безупречного сервера. Кстати, на базе модели работоспособности мы можем отслеживать состояние не только серверов, но и настраиваемых приложений, сетевых устройств, а также многих других важных компонентов, составляющих предприятие. В основу модели работоспособности, реализованной в диспетчере Microsoft System Center Operations Manager 2007 R2, положены четыре области: степень доступности (availability), конфигурация (configuration), производительность (performance) и безопасность (security). Некоторые индикаторы KPI непосредственно определяют, насколько успешно функционирует тот или иной сервер; к их числу относятся индикаторы «процессор», «память», «диск» и «сеть» (Processor, Memory, Disk и Network). Эта модель работоспособности серверов реализована в продукте Windows Server Operating System Management Pack for Operations Manager 2007. Одно из средств отображения модели работоспособности — интерфейс анализатора работоспособности Health Explorer, показанный на экране 1. Данная модель работоспособности отличается исключительной детализированностью; в рамках настоящей статьи я предлагаю сосредоточить внимание на том, как диспетчер Operations Manager интегрирует различные индикаторы KPI.

 

Экран 1. Интерфейс Health Explorer

KPI «процессор»

Обычно перегрузка процессора определяется как ситуация, когда коэффициент использования сервера на протяжении заданного времени составляет свыше 80%. К сожалению, подобные проблемы с производительностью возникают довольно часто. Они могут генерировать значительное число тревожных оповещений, которые не всегда требуют принятия каких-либо мер со стороны сервера. Разработчики монитора Operations Manager (именуемого Total CPU Utilization Percentage) заметно усовершенствовали механизм мониторинга работы процессоров; теперь тревожное оповещение генерируется лишь в том случае, если выполняется сразу несколько условий. Для данного монитора предусмотрено два состояния работоспособности: объект может быть работоспособным (healthy) или находиться в критическом состоянии (critical) в зависимости от перечисленных ниже условий.

  • Критическое состояние констатируется, когда коэффициент использования процессора (Processor\% Processor Time\_Total) выходит за отметку в 95% на протяжении 6 минут (после трех повторений с двухминутным интервалом) и когда значение длины очереди процессора (System\Processor Queue Length) составляет более 15 на протяжении 4 минут (после двух повторений с двухминутным интервалом).
  • В ситуациях, когда пороговое значение снижается и устанавливается ниже уровней, заданных для критического состояния или состояния предупреждения, все рассматриваемые в данной статье мониторы перезагружаются и начинают отображать работоспособное состояние. При этом уровень шума (то есть число тревожных сообщений, не требующих принятия мер) сводится к минимуму: тревожное оповещение генерируется лишь в том случае, когда соответствующее условие, по всей видимости, представляет некое ограничение в работе сервера, а не временное изменение в диаграмме использования процессора. Описанный механизм может послужить хорошей основой для работы почти со всеми серверами, но некоторые из них выбиваются из общего ряда. Отдельные серверы постоянно испытывают более серьезные нагрузки на процессор (это относится, например, к серверам, на которых выполняются системы SQL Server или Exchange Server).

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

Для настройки тревожных оповещений с целью выявления пороговых значений для различных систем или их групп пользователи Operations Manager могут применять переопределения. Переопределение дает возможность изменять реализованные в правилах или мониторах и используемые по умолчанию способы реакции на события по отношению к системам, к которым данное переопределение применяется. Рассмотрим такой пример. Допустим, у вас имеется группа компьютеров, в которую входят все виртуальные серверы. Сведения об обнаружении серверов VMware и Hyper-V можно найти в статье «Virtual Machine Discovery MP for Operations Manager 2007» по адресу www.systemcentercentral.com/PackCatalog/PackCatalogDetails/tabid/145/IndexID/12572/Default.aspx. Так вот, вы можете изменить переопределение таким образом, чтобы пороговые значения для этой группы были изменены в сторону повышения или понижения. Для счетчиков процессоров обычно создаются переопределения, понижающие пороговые значения для систем, на которых с высокой вероятностью возникают проблемы с производительностью процессора, или повышающие пороговые значения для уровней прерывания типичных процессоров.

Диспетчер Operations Manager не ограничивает модель работоспособности возможностями монитора Total CPU Utilization. Мало того, этот счетчик дополнительно оснащается счетчиками Total Percentage Interrupt Time и Total DPC Time Percentage. Данные счетчики также могут выявлять влияющие на работу сервера ограничители производительности со стороны процессоров.

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

  • критическое состояние фиксируется, когда процент, отображаемый счетчиком Total Percentage Interrupt Time для 10 минут (после пяти повторений с двухминутным интервалом), превышает порог в 10%.

Счетчик Total DPC Time Percentage определяет, в течение какого времени процессор получает и обслуживает отложенные вызовы процедур, которые представляют собой прерывания, имеющие более низкий приоритет, нежели стандартные прерывания. Состояние работоспособности и критическое состояние определяются данным счетчиком следующим образом:

  • критическое состояние отмечается, когда счетчик Total DPC Time Percentage выдает значение более 95% в течение 10 минут (после пяти повторений с двухминутным интервалом).

В диспетчере Operations Manager данные о рабочих характеристиках хранятся в операционной базе данных (именуемой OperationsManager). Упомянутые сведения можно использовать при создании диаграмм для одной или нескольких систем. Так, на экране 2 показаны сведения о коэффициенте использования процессоров по нескольким серверам. Данное представление отображается в консоли Operations. Консоль считывает информацию непосредственно из базы данных OperationsManager и может отображать ее на протяжении принимаемого по умолчанию срока хранения, который составляет 7 дней.

 

Экран 2. Коэффициент использования процессоров для нескольких серверов

Кроме того, диспетчер Operations Manager сохраняет сведения о рабочих характеристиках в хранилище данных, которое можно использовать для отслеживания тенденций счетчиков производительности в течение того или иного периода. По умолчанию информация, агрегированная по часовым и по суточным отрезкам, находится в хранилище данных на протяжении 400 суток. Обращаясь к хранилищу данных, мы можем создавать отчеты, отображающие сведения о рабочих характеристиках на протяжении более длительных периодов времени, чем если бы мы обращались к базе данных OperationsManager.

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

Operations Manager может решать задачи диагностики, отыскивая сведения о событиях, имевших место в момент изменения работоспособности объекта, а также задачи восстановления, которые предполагают восстановление работоспособности. Задача для встроенной диагностики возникает в тот момент, когда процессор переходит из работоспособного состояния в критическое; список Top CPU Consuming Processes обеспечивает сбор полезных для диагностики сведений во время перехода процессора из работоспособного состояния в критическое. Эти сведения могут пригодиться при выяснении причин снижения производительности того или иного сервера. На экране 3 представлен пример подобного автоматического диагностирования.

 

Экран 3. Просмотр встроенного списка Top CPU Consuming Processes diagnostic

В диспетчере Operations Manager реализована надежная модель работоспособности, позволяющая описывать работоспособное состояние процессора. Проектировщики модели, допускающей настройку с учетом особенностей конкретного объекта, позаботились о том, чтобы она была полностью готова к работе. Оснащенный моделью работоспособности процессора и в то же время обладающий способностью генерировать отчеты о тенденциях в функционировании счетчиков производительности на протяжении определенного промежутка времени, диспетчер Operations Manager исключительно эффективно выполняет функции ключевого индикатора производительности «процессор».

KPI «память»

Принято считать, что ограничения производительности со стороны памяти имеют место в случаях, когда на обслуживание сервера расходуется свыше 80% имеющихся ресурсов памяти. Самое простое решение проблемы состоит в том, чтобы установить дополнительную память, но это решение часто нереализуемо, а иногда в нем просто нет необходимости. Operations Manager фиксирует, какая часть памяти выделена и какая — доступна; в случаях, когда объем выделенной памяти превышает 80%, диспетчер генерирует тревожное сообщение (по умолчанию).

Счетчик Percentage of Committed Memory in Use изменяет состояние работоспособности сервера в зависимости от того, какая часть памяти системы выделена в данное время. Состояние работоспособности и критическое состояние определяются данным счетчиком следующим образом:

  • критическое состояние фиксируется, когда доля выделенной памяти превышает 80% в течение 6 минут (после трех семплов с двухминутным интервалом).

Наряду с этим Operations Manager отслеживает объем все еще доступной памяти, имеющейся на сервере. Счетчик Available Megabytes of Memory изменяет состояние работоспособности сервера в соответствии с числом мегабайтов памяти, доступных на данной системе. Состояние работоспособности и критическое состояние определяются данным счетчиком следующим образом:

  • критическое состояние констатируется, когда показатель доступных мегабайтов памяти устанавливается ниже порога 2,5 Мбайт на протяжении 6 минут (после трех повторений с двухминутным интервалом). По умолчанию это значение встречается лишь в тех случаях, когда возникает реальная угроза сбоя в работе системы из-за недостатка памяти. Иногда бывает нужно переопределять применяемое по умолчанию значение и задавать больший показатель — это зависит от конкретных потребностей сети. Экран 4 иллюстрирует процесс мониторинга производительности сервера с недостаточным ресурсом памяти. Еще немного — и нормальное функционирование сервера будет поставлено под угрозу, но до установленного по умолчанию порогового значения 2,5 Мбайт дело еще не дошло. Чтобы повысить эффективность данного монитора, целесообразно переопределить это пороговое значение. Пусть оно будет составлять не 2,5 Мбайт, а больше (с учетом общего объема памяти на сервере). Как указывается в подготовленной на TechNet статье «System Level Bottlenecks», опубликованной по адресу technet.microsoft.com/en-us/library/cc558658(BTS.10).aspx, если доля доступной памяти постоянно составляет менее 20–25% объема установленной оперативной памяти, значит, ресурс памяти является недостаточным.

 

Экран 4.Сервер с опасно низким ресурсом доступной памяти, объем которой пока не опустился до уровня 2,5 Мбайт

При определении ключевого индикатора производительности «память» диспетчер Operations Manager выполняет еще один аспект мониторинга памяти — отслеживает динамику разбиения памяти на страницы. В соответствии с терминологией разработчиков Windows Server 2008 Operating System Management Pack это правило именуется Memory Pages per Second 2008. Поскольку речь идет о правиле, а не о мониторе, Memory Pages per Second 2008 не оказывает влияния на модель работоспособности. Однако следует отметить, что Operations Manager собирает сведения о разбивке на страницы, что необходимо для анализа тенденций и выявления факторов, потенциально ухудшающих рабочие характеристики ОС.

Значения этих показателей, соответствующие состоянию работоспособности, могут быть различными — все зависит от типов приложений, установленных на сервере. Скажем, такие приложения, как SQL Server и Exchange, могут расширяться и использовать почти все ресурсы памяти, доступные в системе. В большинстве сетей администраторы создают переопределения, устанавливая для памяти пороговые значения в пределах от 95 до 99% от тех, что указываются для систем SQL Server и для серверов Exchange. Данную задачу можно решить с помощью групп SQL Computers или SQL 2008 Computers продукта SQL Server Management Pack, а также с помощью настройки Exchange 2007 Computer Group продукта Exchange Server Management Pack. Те, кто работает с системами SQL Server, могут применить политику, ограничивающую объем памяти, который может потреблять SQL Server; иначе говоря, пороговые значения можно определять на основе применяемой в организации политики управления памятью. В общем, если пороговое значение составляет 99%, это свидетельствует о наличии проблемы, поскольку в такой ситуации операционная система, скорее всего, испытывает острый недостаток в ресурсах памяти, востребованных приложениями.

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

 

Экран 5. Процент выделенной памяти для сервера на протяжении некоторого периода времени

Индикатор «диск»

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

С целью определения свободного дискового пространства диспетчер Operations Manager фиксирует число «свободных» мегабайтов, а также процент незанятого пространства на всех накопителях обслуживаемых им серверов. Для выявления степени работоспособности исследуемых дисков Operations Manager применяет счетчик Logical Disk Free Space. Как и в случае со счетчиком процессора, определение критической ситуации по имеющемуся свободному пространству осуществляется с использованием двух значений; в данном случае речь идет о процентной доле незанятого пространства на диске и об объеме свободного пространства в мегабайтах. Принимаемые по умолчанию значения могут быть различными. Это зависит от того, какая роль возлагается на накопители в данной системе. Для системных накопителей (томов, содержащих связанные с описанием аппаратных компонентов файлы, которые применяются для запуска Windows) предусмотрены одни пороговые значения, для несистемных накопителей — другие, ибо в большинстве случаев несистемные накопители по своим размерам превосходят системные.

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

  • состояние предупреждения констатируется в случаях, когда доля свободного пространства не достигает 10%, а фактический объем свободного пространства составляет менее 200 Мбайт;
  • состояние ошибки фиксируется в случаях, когда доля свободного пространства не достигает 5%, а фактический объем свободного пространства составляет менее 100 Мбайт.

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

  • состояние предупреждения констатируется в случаях, когда доля свободного пространства не достигает 10%, а фактический объем свободного пространства составляет менее 2000 Мбайт;
  • состояние ошибки констатируется в случаях, когда доля свободного пространства не достигает 5%, а фактический объем свободного пространства составляет менее 1000 Мбайт.

Наряду с этим Operations Manager отслеживает частоту обращений операционной системы к дискам для выполнения операций чтения и записи, а также длину дисковой очереди на данный момент. Кроме того, мониторинг работоспособности включает в себя отслеживание обмена данными с диском (измерение времени обращения к диску в секундах) и определение уровня фрагментированности накопителя. Функции мониторинга операций по считыванию с диска (среднее время считывания с диска в секундах) и по записи на диск (среднее время записи на диск в секундах) по умолчанию отключены, но их можно активировать с помощью переопределения.

Коэффициент использования диска определяется с помощью монитора Average Disk Seconds Per Transfer. Данный счетчик фиксирует состояния работоспособности, а также критические состояния в соответствии со следующим критерием:

  • критическое состояние фиксируется в ситуации, когда среднее время обращения к диску в секундах составляет более 50 в течение 5 минут (после пяти семплов по одноминутному графику).

Работоспособность по показателю фрагментированности определяется с помощью монитора Logical Disk Fragmentation Level. Для этого монитора состояния работоспособности и предупреждения определяются в соответствии со следующим критерием:

  • состояние предупреждения констатируется в случае, когда доля фрагментированных файлов превышает 10%. Проверка состояния работоспособности данным счетчиком осуществляется раз в неделю — по умолчанию в 3 часа утра в субботу.

Счетчик Logical Disk Fragmentation Level охватывает также задачу восстановления Logical Disk Defragmentation, которая по умолчанию отключена. Эта задача может запускать процесс дефрагментации в автоматическом режиме, если степень фрагментированности накопителя превышает пороговое значение, установленное для данного монитора. Дополнительные сведения об этом мониторе можно найти в статье «OpsMgr ReSearch This KB — Logical Disk Fragmentation Level is High» по адресу blogs.catapultsystems.com/cfuller/archive/2010/05/19/opsmgrresearch-this-kb-%E2%80%93-logicaldisk-fragmentation-level-is-high.aspx.

Наряду с этим диспетчер Operations Manager с помощью монитора Logical Disk Availability раз в 5 минут проверяет систему на наличие логических дисков. В случае если диск исчезает или становится недоступным с обслуживаемого диспетчером сервера, счетчик генерирует оповещение. В большинстве случаев данный счетчик функционирует нормально в соответствии с замыслом разработчиков. Однако мне приходилось сталкиваться с ситуацией, когда том для сервера был смонтирован и размонтирован по графику. Тогда мне пришлось отключать счетчик для соответствующего накопителя с помощью переопределения.

Ключевой индикатор производительности «диск» полностью вписывается в модель работоспособности Operations Manager. Он учитывает свободное пространство, а также доступность и определяет состояние работоспособности, включая объем передаваемых данных и даже степень фрагментированности накопителя.

KPI «сеть»

Диспетчер Operations Manager собирает информацию о производительности сетевых адаптеров с помощью следующих счетчиков:

  • Bytes Received/sec
  • Bytes Sent/sec
  • Bytes Total/sec

Эти счетчики задействованы по умолчанию. Их можно отображать с помощью Operations Manager или же в отчетах. На экране 6 представлены счетчики производительности сетевого адаптера. Эти счетчики не «привязаны» к каким-либо мониторам, поэтому они не оказывают влияния на модель работоспособности сетевых адаптеров.

 

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

В диспетчере Operations Manager реализован счетчик Network Adapter Connection Health, который может изменить состояние работоспособности сетевого адаптера, если тот будет удален с сервера. По умолчанию данный счетчик отключен (возможно, с целью минимизации числа не требующих принятия мер тревожных сообщений, генерируемых серверами в сети с несколькими отключенными сетевыми адаптерами); его можно активировать при необходимости получения информации о доступности в рамках реализованной в диспетчере Operations Manager модели работоспособности серверов.

Подготовка отчетов

Диспетчер Operations Manager наделен функцией генерации отчетов на базе службы отчетов SQL Server (SSRS). В различные пакеты управления Operations Manager включены встроенные отчеты, создаваемые с помощью функций SSRS. На экране 7 отображен специализированный отчет, созданный всего лишь за несколько минут с использованием процессов, которые описываются в статье «Creating Useful Custom Reports in OpsMgr: Gathering Custom Performance Counters» (blogs.catapultsystems.com/cfuller/archive/2010/07/21/creating-usefulcustom-reports-in-opsmgr-gatheringcustom-performance-counters.aspx). В отчете представлен отдельный сервер с тремя различными счетчиками (процент процессорного времени, процент выделенных байтов и процент свободного пространства на логическом диске накопителя C).

 

Экран 7. Специализированный отчет с данными о работе трех различных счетчиков

Системы, не относящиеся к семейству Windows

С выходом в свет версии Operations Manager 2007 R2 диспетчер Operations Manager обрел возможность осуществлять мониторинг систем UNIX и Linux. Эту задачу решает построенный на базе открытого исходного кода агент, размещаемый в системе (или в системах). На экране 8 видно, как Operations Manager интегрирует компоненты системы UNIX в модель работоспособности таким же образом, как интегрируется сервер Windows. Обратите внимание на ключевые индикаторы производительности «процессор», «память» и «диск».

 

Экран 8. Интеграция Operations Manager с системой UNIX

Более подробные сведения о кросс-платформенной интеграции Opera­tions Manager 2007 R2 можно найти в книге «System Center Operations Manager (OpsMgr) 2007 R2 Unleashed» (издательство Sams, 2010 год). Информация о кросс-платформенной поддержке мониторинга процессоров приведена в статье «Understanding CPU Performance Counters on Cross Platform Monitors», опубликованной по адресу blogs.msdn.com/b/scxplat/archive/2010/02/04/understanding-cpuperformance-counters-on-cross-platformmonitors.aspx.

Общая картина

Реализованная в Operations Manager модель работоспособности дает нам возможность брать на вооружение базовые концепции, которые традиционно определяли работоспособность серверов (такие, как «функционирует ли процессор с нагрузкой более 80%?»), и строить на их основе всеобъемлющую и настраиваемую модель, позволяющую с большей эффективностью оценивать работоспособность серверов. Данная модель работоспособности дает представление о том, насколько эффективно функционируют серверы в контексте операционной системы, что является краеугольным камнем работоспособности серверов. Модель работоспособности сервера с позиций операционной системы в сочетании с моделью работоспособности приложения, а также других моделей дает гораздо более четкое представление о сервере, а следовательно, о сети в целом.

Диспетчер Operations Manager использует целый диапазон моделей работоспособности — от низшего уровня объекта, такого как диск или процессор, до гораздо более сложных структур, таких как распределенное приложение типа Exchange или Active Directory (AD). Полезно представить модели работоспособности в виде строительных блоков; используя такие блоки, Operations Manager создает более крупные структуры, например заказное географически рассредоточенное приложение.

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

Кэмерон Фаллер (cameron.fuller@catapultsystems.com) — главный консультант специализирующейся на консалтинге в сфере ИТ компании Catapult Systems. Имеет сертификат Microsoft Gold Certified Partner