пятница, 30 декабря 2011 г.

Как надо проектировать систему мониторинга

Решил под новый год поделится используемому мной подходу к проектированию систем управления. Итак ...

Проектировать систему мониторинга можно 2-я способами:
1. Расписать сколько серверов вы ставите, куда ставите агентов, накатить штатные шаблоны и оставить клиента с полученной спам-машиной один-на-один. Нехай мучается
2. Разработать инженерную модель управляемого объекта и настроить систему мониторинга в соответствии с полученными результатами.

Чем хорош первый вариант? Простотой! Думать не надо. Деньги зарабатываем на лицензиях.
Чем плох? У всех более менее крупных заказчиков этот фокус проворачивали пару раз как минимум. И очень большая конкуренция. И надо быть партнером вендора...

Чем плох второй вариант? Думать надо! Нужны спецы в предметной области. Нужно писать скрипты как минимум. Заказчик не готов за это платить или не хочет.
Чем хорош? Практически нет конкуренции. Нет капитальных и логистических затрат. Если вы влазите в проект и грамотного его делаете, то можно легко перейти на сопровождение и постоянный доход. Вас могут начать приглашать на аутсорс систем управлений.

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

Аннотация
В данном документе описывается формат и методика заполнения спецификации на системы управления. Состав и детализация данных в спецификации является достаточной для подготовки проектной документации и применима для всех проектов СУ.
Методика может также использоваться как основа для разработки спецификаций на СУ построенные на платформе HP Operation, так построенные на другой платформе (СОК ПУ КЦОИ, ССХД, АСУ СИО и тп).
Спецификация СУ предназначена для внутреннего документирования разрабатываемых систем и служит основным документом при взаимодействии групп разработки и проектирования. Группа разработки заполняет спецификацию СУ на основе разработанных решений, а группа проектирования на основе спецификации разрабатывает ТРП СУ.
Объем данных описываемых в спецификации является достаточным для решения следующих задач:
1.     Разработки ТЗ на СУ
2.     Разработки ТРП на СУ
3.     Обоснования и разработки сметных расчетов на создание СУ, разработку ТЗ и ТРП
4.     Разработки ПИТВ для СУ согласно требованиям Банка
 Заполнение спецификации СУ не требует от разработчиков знания ГОСТ34 и специфики разработки проектных и сметных документов.
Использование спецификации СУ преследует следующие цели:
·         сокращение коммуникационных издержек между группами проектирования и разработки
·         снижение стоимости разработки СУ за счет:
o    упрощения процесса «сборки» ТРП
o    снижения трудоемкости описания результатов разработки
o    снижение стоимости модификаций и клонирования СУ
·         повышения «лояльности» Заказчика за счет более прозрачного описания СУ




1      Модель объекта управления

1.1       Структурная схема модели объекта управления

Структурная схема модели объекта управления в СУ представлена на рисунке.
Модель включает следующие уровни:
·         Контур управления
·         Протокол информационно-технического взаимодействия (ПИТВ)
·         Ресурсно-сервисную модель (РСМ)
·         Технологические процессы обработки данных


1.2       Контур управления

Контур управления включает данные, описывающие состав контролируемых серверов и других технических средств которые входят в контур управления СУ.
Общая информация о контуре управления собирается в процессе подготовки ТЗ на СУ, и уточняется в процессе проведения настройки и ОЭ СУ.
Информация о контуре управления СУ включается в разделы «Описание объекта автоматизации» документов ТЗ, П2, ПД.
Контур управления содержит следующие спецификации:
·         Устройства
·         Параметры доступа к устройству

1.2.1         Устройства

Устройство – отдельное физическое устройство (сервер, коммутатор и тп) входящее в контур управления СУ. Спецификация устройства содержит идентификатор позволяющий его однозначно идентифицировать (например – hostname) и другую информацию при необходимости ее использования в проекте (физическое размещение, порт управления и тп).
Если в качестве источников данных об физическом устройстве выступает смежная СУ, то устройства входящие в контур управления также описываются, а спецификация взаимодействия СУ и смежной СУ описывается в соответствующем ПИТВ.
Если состав физических устройств является динамическим (определяемым СУ на основе задаваемых параметров, например – все сетевые коммутаторы подсети A.B.C.D) то для описания устройств используется динамический диапазон значений используемый СУ для их поиска. При этом диапазон выбирается таким образом, чтобы все устройства в диапазоне взаимодействовали с СУ по одному ПИТВ и использовали одинаковые параметры доступа.
Спецификация устройства включает состав (ссылки) соответствующих объектов контроля, которые оно содержит.

1.2.2         Параметры доступа к устройству

Параметры доступа к устройству включают:
·         спецификацию настраиваемых в СУ параметров доступа (логины) используемых СУ для получения данных и/или оказания управляющих воздействий для без агентского мониторинга
·         спецификацию настраиваемых специальных пользователей и/или используемых системных пользователей, используемых для запуска процессов агента мониторинга.
В спецификации параметров доступа описывается реально используемые СУ пользователи согласно решениям описанным в соответствующих ПИТВ (см ниже).
В спецификации не указываются пароли соответствующих пользователей.
Спецификация заполняется для каждого устройства или групп устройств одинаковых по используемым технологиям и системным пользователям на этапе настройки и ОЭ СУ.

1.3       ПИТВ

ПИТВ разделяется на 2-а типа:
·         ПИТВ источников данных
·         ПИТВ управления объектами
ПИТВ в терминах ГОСТ34 относится к информационному обеспечению и содержит описания входной информации (источники и состав данных, описывающие состав информации получаемой СУ как входные сигналы от объектов контроля ) и  описание интерфейсов взаимодействия.

1.3.1         ПИТВ источников данных

ПИТВ источников данных описывает решения по взаимодействию СУ с объектами управления в части «сбора» данных, источников данных (data source). Под источниками данных подразумеваются существующие элементы, «из» которых СУ  «забирает» данные.
ПИТВ источников данных содержит спецификацию источников данных (data source), спецификацию используемых для контроля данных и спецификацию протоколов и параметров взаимодействия используемых для сбора данных.
ПИТВ источников данных специфицируется по следующим категориям:
·         Условное наименование источника данных
·         Список контролируемых параметров через данный источник и список Сервисов к которым относятся данные параметры
·         Список функциональных категорий серверов (их типов) управляемой АС, которые содержат данный источник данных
·         Протокол взаимодействия («сбора») данных
o    описание последовательности взаимодействия:
§   (UML - диаграмма взаимодействия) или ссылки на стандартный протокол взаимодействия
§  режима взаимодействия (по расписанию, по событию)
§  инициатора взаимодействия (СУ или объект управления)
§  последовательность взаимодействия  при сборе данных
§  используемые протоколы получения данных (ping, SNMP, WMI, SQL, API, application command tools, …)
o    требуемые порты межсетевого взаимодействия
o    требуемые параметры аутентификации/авторизации, которые включают описание пользователя и необходимых ему прав
o    формат считываемых данных для «нестандартных» данных (например, лог-файлов)
Если источник данных соответствует группе однотипных объектов (например – очереди MQ), состав которых СУ определяет автоматически, то в спецификации описывается группа целиком и в дополнение указывается механизм «дискаверинга группы» и принцип идентификации ее элементов (например – Имя очереди).

1.3.2         ПИТВ управления объектами

ПИТВ управления описывает решения по взаимодействию СУ с объектами управления в части «управления».
ПИТВ управления содержит спецификацию используемых СУ команд управления, состав передаваемых параметров и спецификацию протоколов и параметров взаимодействия.
ПИТВ управления специфицируется по следующим категориям:
·         Условное наименование канала управления
·         Список управляющих команд и их параметры
·         Список устройств, серверов (их типов) управляемой АС, к которым применим канал управления
·         Протокол взаимодействия («выполнения») команд
o    описание последовательности взаимодействия (UML - диаграмма взаимодействия) или ссылки на стандартный протокол взаимодействия
o    требуемые порты межсетевого взаимодействия
o    требуемые параметры аутентификации/авторизации, которые включают описание пользователя и необходимых ему прав
o    формат возвращаемых данных или кодов ошибок

1.4           РСМ

РСМ является выходной информацией, которая описывает данные которые «производятся» СУ, т.е. данные которые она предоставляет пользователю.
РСМ специфицируется на этапе проектирования системы или на этапе разработки СУ или СПО для СУ.
РСМ включается в проект как "Выходная информация" согласно ГОСТ34 в документы или разделы с решениями по информационному обеспечению П2, П5, «Описание постановки задачи», «Перечень выходных сигналов» по необходимости.
РСМ специфицируется по следующим категориям:
·         Объекты контроля (Сервисы)
·         Контролируемые параметры
·         Сообщения
·         Действия

1.4.1         Сервисы

Под сервисами (ИТ-сервисами) подразумевается либо внешнее представление в СУ объектов контроля (физический сервис), либо логическое представление некоего синтетического объекта характеризующего общие или групповые категории.
В общем случае сервис представляет собой имя, под которым объект управления или  их совокупность представлены в СУ.  
Разделение между физическими источниками данных указываемыми в ПИТВ и Сервисами обусловлено разделением входной и выходной информации в ГОСТ34.
Для HP Operations спецификация сервисов соответствует описанию узлов ресурсно-сервисной модели.
Дополнительно к таблице-описанию Сервисов приводят графическое представление Сервисов, согласно реализованному интерфейсу СУ (например: дерево РСМ для OVO, оперативная карта для СОК).

1.4.2         Контролируемые параметры

Спецификация контролируемых параметров описывает метрики, которые:
·          определяются на основании данных из объектов контроля,
·         рассчитываются на основе значений собираемых с соответствующих источников данных и/или других метрик.
Параметры контроля могут определятся опосредовано на основе математических\логических формул или более сложных алгоритмов.
Разделение между Контролируемыми параметрами и Составом данных в ПИТВ, обусловлено разделением входной и выходной информации в ГОСТ34, в которой все что «производится» системой является выходной информацией.
Спецификация контролируемых параметров ссылается на соответствующие алгоритмы расчета и содержит ссылки на данные на основании которых рассчитывается и которым соответствует.
В качестве рассчитываемых метрик можно привести следующие примеры:
·         статус Сервиса (для OVO – правила наследования и влияния статуса согласно РСМ)
·         время нахождения сообщения в MQ очереди.

1.4.3         Сообщения

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

1.4.4         Действия

Под действиями в СУ подразумеваются команды которые могут выполнятся автоматически, как реакция системы на сообщения, или вручную, оператором в контексте Сервиса.
Спецификация действий относится к разделу выходных сигналов (ГОСТ34) в части интерфейса пользователя.
Спецификация действий также ссылается на соответствующие этим действиям ПИТВ управления.
Спецификация действий СУ соответствует документу «Описание автоматизируемых функций», или соответствующим разделам ПД.

1.5       Технологические процессы обработки данных

Спецификация технологических процессов обработки данных описывает внутренние процедуры и функции используемые СУ для интерпретации собираемых данных, расчета интегральных показателей, генерации событий, изменения статусов и т.п.
Спецификация соответствует соответствующим разделам ПД, ПГ «Описание технологического процесса обработки данных».

1.5.1         Алгоритмы расчета

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


Комментариев нет:

Отправить комментарий