Мониторинг инфраструктурыТребования к современным

инструментальным панелям

От контроля сообщений к контролю

услуг: сложности и варианты решений

Коломиец Сергей – IBM,Технический специалист

Sergey.Kolomiets@ru.ibm.com30 октября 2013

Мониторинг инфраструктуры:наука, практика или производство?

• Прикладная наука = Разработка ПО

мониторинга. Всегда модульное.

• Производство = Внедрение ПО мониторинга

на конкретной инфраструктуре

• Заказчик (и интегратор) выбирает способ

• Универсального «правильного» ответа нет

• Есть примеры удачных внедрений

Два источника и две составные части мониторинга

• точечный мониторинг исправности узлов

• мониторинг с точки зрения конечного пользователя

• Три способа получения

– на проходе на первой линии Web сервера

– на ПК клиента, который работает с услугой

– на ПК, но робот вместо клиента

• Результат – метрики и сообщения при нарушениях, раскладка

транзакции

ОБРАБОТКА СООБЩЕНИЙ АРХИВНОЕХРАНЕНИЕ

КАТАЛОГ УСЛУГ, CMDB

ОБОГАЩЕНИЕ СООБЩ.АВТОМАТИЗАЦИЯ

ВНЕШНИЕ СИСТЕМЫHELPDESK

HR

УПРАВЛЕНИЕУСЛУГАМИ

SLA

МОНИТОРИНГРЕСУРСОВ

МОНИТОРИНГ СЕТИ

ВИЗУАЛИЗАЦИЯ

ОТЧЁТНОСТЬ

МОНИТОРИНГТРАНЗАКЦИЙ ДРУГИЕ СУ

АНАЛИТИКА

Текстовое сообщение как основа мониторинга

• информативный формат

• компактный

• полезность варьируется в

зависимости от качества обработки и

обогащения

• кросс-доменный

• коррелируемый

• простой в навигации

• отображает текущую ситуацию

• исторические отчёты

Особенности мониторинга сообщений

• Относится и к оборудованию и к ПО

• Результат – текстовое сообщение, часто с числовыми

значениями.

• Внутренний и дистанционный мониторинг

• Логика – сообщение «есть/нет»

• часто отвечает на вопрос, что именно неисправно

• Технологии стандартизованы (Агенты, SNMP, CORBA …)

• Невозможно контролировать всё

• Сложно оценить ситуацию в условиях резервирования

связей и узлов

• Трудоёмкая настройка передающих объектов и правил

обработки на входе

• В многоуровневых схемах много симптоматических

сообщений

• X in Y

Сбор, агрегация и отображение метрик

• ситуация в развитии

• основа проактивного управления

• вдумчиво выставлять пороговые

значения и критичность сообщений

• база для прогнозирования и

обнаружения аномальных

отклонений

• сбор метрик часто совмещается со

сбором сообщений

• удваивает информативность инстр.

панели

Идентифицировать проблему в потоке сообщений

Добыть и сопоставить данные из устройств и различных OSS/BSS систем

Выполнить установленный рабочий сценарий(workflow)

Обогащение Дополнить

поля

сообщения

важными для

оператора

данными

(место-

нахождение

объекта,

контактные

данные

ответствен-

ного, данные

о клиенте,

SLA и т.д.)

КорреляцияПровести

логический

анализ

множества

сообщений

выявить

первопричину и

отсеять

симптомы

Объединение данныхСобрать

данные из

разных систем

и представить в

объединённом

окне

(OperatorView)

Запросы информациис объектовКнопкой в

OperatorView

запустить

преднастроен-

ную команду.

Увидеть ответ

объекта

(command

response)

Автоматическое выполнение рабочего сценария.Выполнить

заранее

настроенную

последователь-

ность действий,

при наступлении

определённых

условий и без

участия человека.

Исполнение рабочего сценария по команде оператораВыполнить

установленную

последовательность

действий, избавляя

оператора от ручных

рутинных операций.

Рабочий сценарий

по правому щелчку

мыши на сообщении

или объекте на

карте.

Типовые задачи оператора службы эксплуатации

Сокращение времени поиска и устранения неисправностей

Информационное обеспечение процесса принятия решений и повышение

эффективности работы операторов

Повышение производительности труда персонала

Задачи Netcool/Impact и результат его применения

Ошибки в строительстве модели услуг

• Попытка копировать физическую

топологию

• Чрезмерная глубина, детализация.

(нужно использовать

информативность сообщений)

• Ставка только на влияние сообщений

от узлов

• Не используются имеющиеся

механизмы автоматического

создания и поддержания модели

услуг (включая интегр. с CMDB)

• Много точек схождения в нижней

части модели

Проблема выбора степени влияния от узлов и от

мониторинга с точки зрения конечного пользователя

• Повышенный весовой коэффициент

влияния сообщений (метрик)

снимаемых ПО мониторинга с точки

зрения пользователя позволяет

снизить вероятность ложных

срабатываний

• Передачу статуса снизу нужно

оставлять, но с меньшим весом, это

сохранит контекстную привязку

сообщений от узлов снизу к услуге

верхнего уровня и визуальный RCA

Технические SLA и последующие разбирательства

• Time Window Analyzer – «плоттер» изменения состояний и метрик во

времени. Инструмент сравнения.

• Tivoli Common Reporting. Готовые отчёты.

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

• Живут под влиянием изменений и

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

• Создаются из GUI

• Большой набор готовых

индикаторов (спидометры,

термометры, блоки данных (1-

6шт) и т.д.

Dashboard Application Services Hub (DASH)

• Интеграционная среда для продуктов

IBM Tivoli и не только…

– Объединение на уровне данных

приложений

– Общая среда интерфейсов конечных

пользователей систем

• Использует открытые стандарты: Linked

Data, OSLC и др.

• Всё, что уже доступно (лицензировано)

для Netcool/Impact – доступно в DASH

бесплатно.

Требования к современным инструментальным панелям 1/2

• Поддержка разнородных источников данных, не только RDBS,но и приложений

• Развитые возможности представления оперативной

информации

– индикаторы с цифровыми значениями

– спидометры, термометры

– таблицы (вкл. аварийные сообщения)

– графики

– диаграммы

– карты (географические + топология, модели услуг)

• Самообновление всех элементов дашборда

• Доступность самостоятельной настройки

• Отображение через Web интерфейс

• Поддержка мобильных устройств (iOS, Android)

Требования к современным инструментальным панелям 2/2

• Контекстные изменения соседних визуальных элементов

• Поддержка функции поиска

• Контекстные переходы во внешние приложения–поставщики

данных для получения более детальной информации

• Контекстный запуск отчётов

• Инструментальные панели операционной работы службы

эксплуатации должны иметь возможности воздействия на

объекты мониторинга.

Основные продукты построения инструментальных панелей

мониторинга

• Dashboard Application Services Hub (DASH) – Jazz for Services

Management

• Tivoli Business Services Manager (TBSM) в TIP

• OMNIbus (Self Services Dashboard) в TIP

• Tivoli Network Manager в TIP

• Tivoli Netcool Performance Manager (ITNPM)

• Netcool/Impact (Operator View)

• Tivoli Common Reporting (вкл. Cognos)