КОМПЛЕКСНЫЕ  СРЕДСТВА  МОНИТОРИНГА  ВЕБ-УЗЛОВ

Игнатов  Юрий  Юрьевич

канд.  соц.  наук,  доцент  ССЭИ  РЭУ  им.  Г.В.  Плеханова,  РФ,  г.  Саратов

E-mail: 

COMPLEX  MONITORS  OF  WEBSITES

Ignatov  Yury

candidate  of  sociological  sciences,  associate  professor  of  the  Saratov  Social  and  Economic  Institute  of  the  Russian  Economic  University  of  a  name  of  G.V.  Plekhanov ,  Russia,  Saratov

АННОТАЦИЯ

В  статье  рассматривается  решение  актуальных  проблем  обеспечения  бесперебойной  работы  веб-узлов,  постоянной  доступности  сайтов  и  веб-сервисов.  Акцент  делается  на  работу  веб-сервера  компании  Microsoft  —  Internet  Information  Services  (IIS)  и  веб-приложений  .Net.  Автор  определяет  суть  комплексного  мониторинга  веб-узлов  и  конкретно  показывает  функциональность  и  работу  программного  инструмента,  при  помощи  которого  можно  реализовывать  полномасштабный  мониторинг  веб-решений  для  исключения  простоев.

ABSTRACT

In  article  the  solution  of  actual  problems  of  support  of  smooth  operation  of  websites,  constant  accessibility  of  sites  and  web  services  is  considered.  The  emphasis  is  placed  on  operation  of  a  Web  server  of  the  Microsoft  company  —  Internet  Information  Services  (IIS)  and  the  web  applications  .Net.  The  author  defines  an  essence  of  complex  monitoring  of  websites  and  specifically  shows  functionality  and  operation  of  the  software  tool  by  means  of  which  it  is  possible  to  implement  full-scale  monitoring  of  web  solutions  for  an  exception  of  idle  times.

Ключевые   слова:  IIS;  веб-узел;  сайт;  Microsoft  Operations  Manager;  сервер;  агент;  консоль;  ASP.Net;  DotNetNuke;  программный  код.

Keywords:   IIS;  website;  site;  Microsoft  Operations  Manager;  server;  agent;  console;  ASP.Net;  DotNetNuke;  program  code.

На  современном  этапе  развития  информационных  технологий  становится  уже  стандартом  ситуация  когда  многим  компаниям  необходимо  присутствие  в  глобальной  сети  Интернет.  Данное  присутствие  в  большинстве  случаев  выражается  в  создании,  поддержке  веб-решений  по  необходимым  направлениям,  к  которым  относятся  информационные  сайты,  порталы,  социальные  сети,  интернет-магазины,  новостные  системы,  блоги,  форумы,  многообразные  сервисы.  Для  компаний,  бизнес  которых  построен  в  сфере  Интернета  продуманные,  стабильные  и  развивающиеся  веб-решения  являются  гарантией  делового  успеха.  Цифры  в  только  подтверждают  приведенные  высказывания.  В  апреле  2014  г.  в  глобальной  сети  зарегистрировано  более  958  млн.  сайтов,  причем  рост  по  отношению  к  марту  составил  39  млн.  Ведущими  платформами  для  веб-решений  в  глобальной  сети  являются  Apache  и  Microsoft  IIS,  причем  в  апреле  2014  г.  на  них  приходилось  38  %  и  33  %  соответственно  всех  работающих  в  глобальной  паутине  сайтов. 

Наряду  с  этим,  необходимо  отметить  факт  того,  что  если  время  загрузки  веб-страницы  интернет-магазина  увеличивается  на  1  секунду,  это  может  привести  к  7  %-му  падению  конверсии.  Трудно  сказать,  что  та  или  иная  компания  может  спокойно  позволить  себе  падение  прибыли  на  7  %.  Если  сказать  о  недоступности  сайтов  крупных  интернет-магазинов,  то  например,  при  простое  в  течении  часа  Ozon.ru  возможные  финансовые  потери  могут  составить  1,3  млн.  руб. 

Данный  краткий  статистический  обзор  указывает  на  актуальность  решений  для  мониторинга  состояния  работы  веб-узлов.  Причем  гетерогенная  среда  платформы  для  обеспечения  работы  веб-решений  предполагает  такой  инструмент  мониторинга,  который  мог  бы  контролировать  и  работу  Apache,  и  работу  IIS  из  одной  коробки.  Поскольку  на  работоспособность  сайта,  его  скорость  влияет  не  только  аппаратные  характеристики  сервера,  сетевого  оборудования,  но  и  широкий  спектр  программного  обеспечения,  начиная  от  операционной  системы  и  заканчивая  конкретным  пространством  имен  и  классами  в  программном  коде  веб-сайта,  актуален  именно  комплексный  мониторинг  веб-узлов.  В  рамках  данной  статьи  сузим  рассмотрение  мониторинга  до  уровня  компонентов  веб-сервера  Microsoft  IIS  7—8  и  классов  программного  кода  запущенного  на  данном  сервере  веб-приложения  на  платформе  ASP.Net. 

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

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

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

Для  реализации  изложенных  требований  подходит  разрабатываемый  программный  комплекс  корпорации  Microsoft  —  Operations  Manager.  Первая  промышленная  версия  продукта  появилась  в  2000  г.  и  носило  название  Microsoft  Operations  Manager  2000.  Последняя  версия  продукта  на  текущий  момент  —  System  Center  2012  R2  —  Operations  Manager  [3]. 

Главные  инфраструктурные  компоненты  Operations  Manager  —  сервер  управления,  агенты,  операционная  база  данных  и  хранилище.  Модель  и  компоненты  мониторинга  задаются  в  пакетах  управления,  разрабатываемые  для  того  или  иного  оборудования,  программного  обеспечения  различными  компаниями.  Перечисленные  компоненты  и  оборудование,  включенное  в  мониторинг,  называются  группой  управления.  Сервер  управления  является  ключевым  в  системе  мониторинга,  решает  задачи  администрирования  конфигурации  группы  управления  и  агентов,  взаимодействует  с  базами  данных. 

Пакеты  управления  подчиняются  правилу  иерархичности,  т.  е.  для  работоспособности  пакета  управления  IIS  8  необходимы  уже  импортированные  на  сервер  управления  пакеты  для  мониторинга  ОС  Windows  Server  2012.  Пакет  управления  для  IIS  8  содержит  следующие  контрольные  сценарии:  контроль  общей  работоспособности  сервера  и  состояния  служб  Web  management,  FTP,  SMTP,  WAS;  монитор  запуска  и  доступности  веб-сайта,  пула  приложений,  ftp  сайта,  виртуального  сервера  SMTP;  обнаружение  предупреждений  об  ошибках  конфигурации,  зарегистрированных  компонентами  IIS  8;  отслеживание  перезапуска  пула  приложений  для  выявления  пулов,  выполняющие  код,  который  может  генерировать  утечки  памяти  или  другие  проблемы  использования  памяти  с  последующим  изменением  состояния  работоспособности  пула.

Пакет  управления  IIS  задает  правила  сбора  данных  из  журналов  (логов)  работы,  включенных  на  стороне  веб-сервера.  Если  журналирование  не  активировано,  агент  будет  передавать  только  данные  о  состоянии  запущенных  служб.  Журналы  IIS  должны  быть  установлены  в  формате  расширенного  файла  журнала  W3C  для  каждого  сайта  и  виртуального  сервера  SMTP  и  NNTP.

После  импортирования  пакета  IIS  на  сервер  управления  в  области  мониторинга  консоли  управления,  имеющая  интерфейс  по  структуре  и  подобию  проводника  Windows,  появляется  папка  “Microsoft  Windows  Internet  Information  Services”  с  представлениями,  или  приборной  панелью  (dashboards).  Такие  папки  появляются  после  импортирования  любого  целевого  пакета  управления.  Панели  следующие:  активные  предупреждения  (Active  Alerts),  все  данные  о  производительности  IIS,  состояние  пулов  приложений,  состояние  FTP  сайтов,  состояние  серверов  с  ролью  IIS,  состояние  ролей  IIS,  выполненные  задачи,  состояние  веб-сайтов.  Также  присутствуют  две  вложенные  папки  —  мониторинг  работоспособности  и  производительность.  После  того  как  агент  будет  развернут  на  веб-серверах,  на  обнаружение  всех  компонентов  IIS  и  оценку  их  работоспособности  может  потребоваться  около  4  часов. 

Состояние  серверов,  ролей,  сайтов  и  пулов  приложений  IIS  система  выражает  в  виде  пиктограмм  различного  цвета  и  состояния  (рис.  1).  Состояние  бывает  четырех  видов:  полностью  здоров  (работоспособен),  внимание,  критическое  состояние  и  нет  связи. 

Рисунок  1.  Часть  окна  консоли  Operations  Manager  с  отображением  состояния  пулов  приложений

По  состояниям  кроме  «работоспособен»  система  генерирует  «алерты»,  т.  е.  тревожные  предупреждения,  которые  появляются  в  разделе  «Активные  алерты»  (Active  Alerts).  В  предупреждении  описывается  источник,  время,  возникшая  проблема  и  инструкции  по  её  устранению.  В  пакете  управления  включено  более  100  правил,  по  которым,  в  случае  превышения  пороговых  значений  в  работе  компонентов  IIS,  Operation  Manager  генерирует  предупреждения.  Числовые  параметры  пороговых  значений  в  пакете  управления  могут  меняться  администраторами  системы  на  те,  которые  подходят  к  сложившимся  условиям  работы  инфраструктуры.  Замена  происходит  путем  переопределения  параметров  и  сохранения  их  в  специально  созданном  для  этого  пакете  управления.  При  таком  подходе  можно  всегда  вернуться  к  эталонным  значениям,  формируемые  с  учетом  лучших  практик  при  работе  с  веб-серверами.  Например,  в  правиле  «HTTP  сервер  не  смог  произвести  инициализацию  из-за  нехватки  допустимой  памяти»,  относящееся  к  типу  предупреждений,  можно  переопределить  следующие  значения:  активировать  (да/нет);  приоритет;  строгость  предупреждений.

Важной  особенностью  является  настройка  правил  работы  агента  Operations  Manager  при  контроле  веб-сервера  на  котором  работает  400  и  более  сайтов,  пулов  приложений.  По  умолчанию  агент  может  использовать  только  100  мб  памяти,  что  для  контроля  такого  количества  сайтов  не  достаточно.  Необходимо  переопределить  параметр  «Порог  допустимой  памяти  для  сервиса  работоспособности»  (Health  Service  Private  Bytes  Threshold)  до  значения  200  мб,  иначе  агент  будет  периодически  перезапускаться,  что  не  позволит  производить  качественный  мониторинг.

Система  имеет  функциональные  возможности  передавать  данные  предупреждения  по  различным  каналам  связи  -  электронная  почта,  мгновенные  сообщения,  SMS.  Также  есть  возможность  настроить  выполнение  определенных  команд,  например  перезапуск  служб  IIS  и  передавать  сообщения  в  другие  системы  через  коннекторы,  например  в  программу  Service  Manager,  предназначенную  для  службы  поддержки  по  работе  с  инцидентами.

Тем  не  менее,  для  однозначного  выявления  причин  в  замедлении  производительной  работы  сайта,  всестороннего  и  глубокого  мониторинга  одного  IIS  недостаточно.  Необходимо  видеть,  как  отрабатывает  запросы  программный  код  веб-приложения  [1].  Для  этих  целей  в  Operations  Manager  2012  R2  разработан  специальный  шаблон  для  мониторинга  производительности  .Net  приложений,  работающие  под  управлением  IIS.  Данный  шаблон  импортируется  в  систему  в  пакете  управления  "Microsoft.SystemCenter.Apm.Web.IIS7"  и  требует  уже  настроенного  мониторинга  IIS.

Перед  началом  настройки  шаблона  необходимо  создать  группу  для  включения  веб-серверов  с  работающими  целевыми  веб-сайтами,  например,  на  основе  CMS  DotNetNuke  [2].  Также  нужно  создать  пользовательский  пакет  управления,  название  которого  указывает  на  контролируемое  приложение.  Созданные  объекты  затем  добавляются  в  конфигурацию  монитора  приложений.

Монитор  приложений  имеет  сложную  структуру  настроек,  несколько  сценариев  работы  и  возможность  добавление  транзакций  для  разных  типов  объектов  —  веб-страница,  веб-сервис,  MVC-страница,  WCF  метод,  функция.  Транзакции  используются  для  контроля  отдельной  страницы  более  конкретно,  чем  родительское  приложение,  по  другим  параметрах  пороговых  значений  или  в  той  ситуации,  когда  для  родительского  приложения  отключены  предупреждения.  Компонент  приложения  продолжает  контролировать  страницу,  определенную  в  транзакции  при  помощи  порога  производительности,  который  установлен  для  компонента  приложения.  Этот  порог  используется  в  качестве  второго  значения  на  той  же  странице  в  компоненте  приложения.  Если  этот  порог  установлен  выше,  чем  порог  компонента  приложения,  то  генерируется  единственное  событие,  но  можно  получить  два  предупреждения  производительности  для  транзакции,  когда  порог  нарушен  —  один  от  компонента  приложения  и  один  от  транзакции,  в  зависимости  от  параметров  настройки  предупреждения.

Часть  данных,  собираемые  монитором  производительности  приложений  отображаются  в  подкаталоге  .Net  Monitoring  каталога  «Мониторинг  приложений»  в  главной  консоли  управления  Operations  Manager  2012  R2.  Здесь  концентрируется  информация  именно  о  состоянии  приложений  и  данные  счетчиков.  Каталоги  создаются  для  каждого  настроенного  шаблона  APM,  в  который  вложена  панель  для  отображения  состояния  всех  приложений  в  шаблоне,  плюс  подпапки  для  каждого  контролируемого  приложения  или  веб-сайта.  Состояние  компонентов  представляется  аналогично  контролю  веб-  сервера  —  пиктограммами  различного  цвета.  Для  каждого  приложения  в  панели  состояния  отображается  работоспособность  ASP.Net  компонентов,  веб-сервисов,  WCF  веб-служб,  Windows  служб,  компонентов  мониторинга  по  сценарию  на  стороне  клиента. 

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

В  шаблоне  настраивается  ряд  параметров  сбора  данных.  Для  событий  исключений  есть  варианты  выбора  —  собирать  только  предупреждения,  связанные  с  безопасностью  в  работе  приложения,  предупреждения  при  подключениях  к  сайту,  предупреждения  при  возникновении  ошибок  в  работе  веб-приложения,  либо  только  критические  события  или  все  сразу.  Опция  "Отслеживание  исключений"  позволяет  добавить  пространство  имен  программного  кода  или  классы,  где  необходимо  собрать  дополнительную  информацию  о  возникающих  событиях  исключений,  превышающий  пороговый  показатель  относительно  других  классов.  В  опции  «Критические  исключения»  есть  возможность  добавить  элементы  к  списку  обработчиков  исключений,  которые  отлавливают  критические  события  в  приложении.

Для  монитора  событий  производительности  указывается  дополнительные  параметры  —  «Порог  события  производительности  (ms)»,  при  превышении  которого  происходит  регистрация  в  базе  классов,  отработка  которых  на  веб-сервере  превысила  указанный  порог.  Т.  е.  это  указывает  на  то,  что  события  производительности  генерируются  для  методов,  выполнение  которых  превысило  указанный  порог.  Параметр  «Порог  чувствительности  (ms)»,  указывает  время  отработки,  меньше  которого  не  производится  захват  методов  для  анализа  времени  выполнения  по  первому  параметру.  Это  фильтр  для  быстрых  методов,  уменьшающий  стек  анализа,  соответственно  снижающий  нагрузку  на  базу  данных  Operations  Manager.  По  умолчанию  события  производительности  обрабатываются  для  всех  пространств  имен  и  методов  веб-приложений,  включенные  в  шаблон,  но  также  можно  настроить  фильтр  на  анализ  конкретного  пространства  имен  или  метода,  также  указав  его  как  точку  входа.

В  сценарии  «Мониторинг  на  стороне  клиента»  присутствует  ряд  дополнительных  параметров  контроля.  Во-первых,  по  умолчанию  производится  мониторинг  работы  браузера  только  на  локальном  сервере.  Шаблон  предоставляет  возможность  добавлять  конкретные  IP  адреса  клиентов  или  диапазоны  адресов  для  контроля  или  для  исключения  из  мониторинга.  Фильтр  сориентирован  на  метод  исключения,  т.  е.  если  необходимо  добавить  адреса  клиента  для  мониторинга,  то  прописывается  IP  адрес,  маска  подсети  и  устанавливается  запрещающий  тип  «Не  в  этой  подсети».  Таким  образом,  система  исключает  из  мониторинге  все  адреса,  кроме  указанного  в  форме. 

Во-вторых,  в  области  конфигураций,  относящейся  к  сбору  данных  о  производительности,  устанавливается  временной  порог  уже  для  загрузки  только  веб-страниц.  На  стороне  сервера,  как  мы  сказали,  это  были  методы,  классы,  пространства  имён.  Отдельно  выделяется  сбор  данных  о  времени  инициализации  страницы  Ajax  и  Windows  Communication  Foundation  (WCF)  компонентов,  регулируемый  параметром  порога  в  миллисекундах.  Причем  объем  входящих  запросов,  попадающих  под  контроль  можно  указывать  в  диапазоне  от  0  %  до  100  %  (значит  все  запросы),  тем  самым  регулируя  выборку  мониторинга.

В-третьих,  можно  настраивать  сбор  данных  о  содержании  контента,  переданного  клиенту,  видеть  объем  графических  объектов,  скриптов,  каскадных  таблиц  стилей,  глобальных  переменных,  стек  исключений.  На  рисунке  показана  часть  отчета  в  консоли  “Application  Diagnostic”  о  работе  CMS  DotNetNuke,  где  видна  структура  контента  по  объему  и  в  процентном  соотношении,  время  загрузки  (рис.  2).  Также  реализованы  отчеты  по  событию  производительности,  где  отображен  стек  выполнения  страницы  на  стороне  сервера  со  временем  отработки  каждого  метода  класса. 

Система  Operations  Manager  2012  R2,  как  комплексное  средство  мониторинга,  имеет  обширный  функционал  по  контролю  и  анализу  работы  веб-узлов,  включая  веб-приложения.  В  рамках  статьи  мы  рассмотрели  часть  возможностей  для  IIS  7-8,  ASP.Net  сайтов,  но  система  также  позволяет  контролировать  и  веб-сервера  приложений  TomCat,  JBoss,  WebLogic,  WebSphere  и  код  JAVA  на  nix  платформе.

Рисунок   2.  Часть  отчета  Operations  Manager  в  консоли  “Application  Diagnostic”

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

Список  литературы:

1.Гусятников  В.Н.,  Безруков  А.И.  Стандартизация  и  разработка  программных  систем.  М.:  Финансы  и  статистика,  2010.  —  288  с.

2.Игнатов  Ю.Ю.  Анализ  asp.net  систем  управления  контентом  в  веб-представительствах  компаний  //  Междисциплинарные  исследования  в  области  компьютерного  моделирования  и  информатики:  материалы  3-й  научно-практической  конференции.  (Тольятти,  20—21  фев.  2014  г.).  Ульяновск,  2014.  —  С.  400—405.

3.Chris  Amaris,  Rand  Morimoto,  Pete  Handley,  David  E.  Ross.  Microsoft  System  Center  2012  Unleashed.  Person  Education,  Inc,  2012.  —  1011  c.