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

Мониторинг услуг ИТ (IT Service Monitoring, ITSM) приобретает все большее значение. На это есть много причин. Конкурентная борьба на этом рынке разгорается нешуточная, причем подтверждение качества является составной частью предоставления услуги. Услуги ИТ должны быть разграничены; это достигается четким описанием качества. Любой сбой грозит провайдеру потерей клиентов, а клиенту — потерей бизнеса. В конце концов, все услуги, которые продаются и покупаются, должны быть измеримы, что, кроме того, может послужить индикатором при поиске ошибок: там, где измерительный инструмент покажет падение производительности до того, как его обнаружит пользователь, проблемы удастся исправить без эскалации конфликта.

Чаще всего провайдеры оценивают предоставляемые услуги путем конкатенации и суммирования элементов информации, а также выполняют тестирование при помощи синтетических агентов. Эти методы обязательны для внутренних процессов услуг, однако обнаруживают некоторые слабости в получении представления о них глазами пользователя. Первый вариант предполагает, что вся относящаяся к делу информация доступна, и сумма отдельных свойств составляет необходимое общее качество. Это не соответствует действительности. Второй вариант исходит из того, что инсталлированные провайдером синтетические агенты способны описать качество услуг на основании генерированных значений готовности и времени отклика (из конца в конец). Насколько это верно, во многом зависит от издержек на конфигурацию и администрирование, которые могут значительно вырасти. Так, используемые оконечные системы должны быть идентичны с пользовательскими устройствами, установлены в тех же филиалах и подключены к тем же провайдерам услуг глобальной сети, а частота транзакций должна быть столь же высока. Обе меры на практике могут предложить некоторую апроксимацию, но не точную характеристику действительно имевшего место качества услуг (Quality of Service, QoS) в каждой конкретный момент времени.

СБОР ДАННЫХ — ДЕЛО НЕПРОСТОЕ

Немалые трудности вызывает распределение информации о качестве: часто невозможно установить необходимые измерительные средства на всех маршрутах и компонентах. Кроме того, сумма измеряемого качества отслеживаемых компонентов не идентична с реальным качеством услуг. Часто данные с технического уровня элементов не передаются на метауровень услуг. Очень сложным представляется достижение актуальности, т. е. оптимального интервала между измерениями системы управления. Часто проблемы в сети появляются на короткое время (биение маршрутов и т. д.). Постоянно работающие системы это замечают, как и пользователь. Однако часто инструментарии SNMP или синтетические агенты не получают большую часть информации по причине ограниченной периодичности опроса (к примеру, каждые 5 мин). И наконец, система управления должна предоставлять информацию деловым процессам. Без этого никакая обработка в соответствии с приоритетами невозможна.

ТРЕБОВАНИЯ

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

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

В связи с этим возникает вопрос: почему та информация, которую можно извлечь из потоков TCP/IP, не переносится в организационные, относящиеся к бизнесу структуры? Если анализаторы пакетов распознают отдельные потоки и могут установить фазы процессов и время отклика, то после этого остается лишь организовать потоки и создать осмысленные оценочные матрицы и описания. Необходимо, к примеру, установить, чем конкретно определяется готовность услуги и как следует интерпретировать проблемные случаи, когда пользователь не получает ответа на запрос, или повторение передачи происходит слишком часто, или путь маршрутизации и время отклика изменяются.

МЕТРИКИ УСЛУГ ИТ

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

Как определяются производительность и доступность? Решения по управлению производительностью, как правило, подсчитывают такие параметры, как ошибки и т. д., поскольку не обладают прямой информацией о производительности. Однако многие данные становятся содержательными тогда, когда можно сделать определенные заключения о производительности с точки зрения пользователя. «100 процентов» нагрузки на канал может звучать обнадеживающе (канал справляется с передачей информации) или обескураживающе (рост невозможен). Лишь с учетом других переменных, таких, как отказы (потерянные пакеты данных) на интерфейсах, удастся оценить потери производительности. Для оценки качества, с точки зрения пользователя, понадобится следующая информация:

  • базовая информация - готовность приложения в зависимости от конфигурируемых переменных (временной фактор); количество отказов; не считающиеся отказами нарушения; длительность и причины отказов;
  • детальная информация - время транзакции и передачи данных. С точки зрения провайдера, важна информация о причинах:
  • синхронизация - общее время задержки, время задержки в сети, время отклика сервера, время отклика клиента, длительность обработки на отдельных стадиях (в глобальной сети, на брандмауэре, при балансировке нагрузки и т. д.), время соединения;
  • производительность - сквозная пропускная способность, полезная пропускная способность и т. д.;
  • TCP - соединения, попытки/отказы соединения, потеря пакетов, повторная передача ТСР, сбросы ТСР, тайм-ауты ТСР.

Специальные инструменты должны извлекать эту информацию из потоков.

МОНИТОРЫ НА БАЗЕ ПОТОКОВ

Мониторы на базе потоков (Flow-Based Monitor, FBM) — это устройства, которые подобно сетевому анализатору просматривают потоки ТСР. Администратор инсталлирует их в центре провайдерской или пользовательской сети. Они предназначены не для перехвата данных, а для анализа коммуникационных взаимосвязей и их влияния на деловые процессы на лету. FBM измеряют производительность напрямую и не нуждаются в отводе трафика. FBM сфокусированы на оценке данных о производительности и их предоставлении в отчетах и таблицах. Они должны:

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

Если данные организованы рационально — к примеру по регионам, клиентам, деловым целям и т. д., — то процессы ИТ можно отобразить для всего предприятия (см. Рисунок 1). Окно для регионов и деловых процессов предоставит по ссылке прямой доступ к детальной информации о приложениях, участвующих пользователях и серверах: данные приложений и клиентов организуются в виде информационных уровней с логическими связями между ними (см. Рисунок 2).

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

Реализация в сложных распределенных сетевых инфраструктурах требует централизованного анализа потоков ТСР по географически разнесенным каналам. Для этого администратор синхронизирует на мониторе параллельные интерфейсы при помощи функций зеркалирования портов и маршрутизации правил коммутаторов третьего уровня (см. Рисунок 3).

ЗАКЛЮЧЕНИЕ

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

Андреас Дидрих — независимый автор. С ним можно связаться по адресу: wg@lanline.awi.de.

? AWi Verlag

Считывание информации о потоках

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

Для наблюдения за статусом соединения протокол ТСР предоставляет множество параметров: таймеры, счетчики, теги и флаги функций. Современные системы мониторинга постоянно измеряют пакеты ТСР и регистрируют все ошибки. К наблюдаемым событиям относятся, к примеру, тайм-ауты (события, сигнализирующие о том, что процесс не выполнен за определенное время), ретрансмиссии (повторение передачи после периода ожидания), а также сброс (если соединение не было построено в соответствии с правилами). Кадры сброса информируют о такого рода аномальных состояниях и обрывах. Кроме того, счетчик транзитных узлов информирует о количестве маршрутизаторов, через которые прошел пакет. Если значение изменяется, то причиной снижения производительности может быть нестабильность в маршрутизируемой сети.