► SAP CCMS Monitor Templates
Мониторы для регулярного администрирования системой SAP
► SAP CCMS Technical Experts Monitors
Мониторы для выявления неисправностей и для управления самой архитектурой мониторинга
► SAP CCMS Monitors for Optional Components
Мониторы для наблюдения за специальными компонентами, такими как распределение нагрузки регистрации, выбранные транзакции или клиенты и заранее определенные файлы журналов
На основе этих наборов мониторов (см. рис. 16.2) заказчики могут создать свои собственные мониторы со специальными представлениями выбранных областей, определяя собственных сборщиков данных и объекты для создания дополнительных сигналов (см. раздел 16.13), и изменить
Рис. 16.2. Заранее определенные наборы мониторов (Версия 6.20)
стандартные настройки. Можно также интегрировать внешние инструменты. Специальные требования заказчика определяют пределы, в которых необходимы и желательны изменения в настройках по умолчанию и наборах мониторов. В более простых системных инфраструктурах и во время фазы реализации системы обычно бывает достаточно предоставленных SAP мониторов, только с незначительными зависящими от заказчика модификациями. Анализ монитора сигналов является относительно простым и не требующим пояснений. Значительно более трудным являются определение мониторов пользовательских сигналов и интеграция пользовательских сигналов. Поэтому в следующих разделах описаны только основы.
16.1.2. КомпонентыНабор мониторов является логическим объединением любого числа мониторов; сами мониторы организованы в древовидную структуру.
Элементы дерева мониторинга
Узлы ветвей в дереве мониторинга называются элементами дерева мониторинга (МТЕ — monitoring tree elements). МТЕ логически объединяет лежащие ниже узлы или другие МТЕ. Они называются также итоговыми узлами мониторов (monitor summary nodes) или просто узлами.
Атрибуты мониторинга
Листья дерева мониторинга формируются через атрибуты мониторинга, описывающие тип информации отдельных элементов системы mySAP, которые находятся под наблюдением. Атрибут мониторинга относится к одной характеристике объекта мониторинга. Определены следующие типы атрибутов мониторинга:
► Атрибуты производительности
Атрибут производительности определяет меру для размера или частоты события. Если определенные пороговые значения превышаются, то цвет соответствующей записи в дереве мониторинга изменяется.
► Атрибуты статуса
Появление одного определенного сообщения включает сигнал.
► Атрибуты журнала
Сообщения в файле журнала просматриваются в процессе поиска определенных заранее комбинаций. Если появляется одна из этих строк, то включается сигнал.
► Деятельность
Наблюдается деятельность определенных элементов системы, таких как R/3 Services. Если контролируемые элементы отказывают, включается сигнал.
► Текстовые атрибуты
В противоположность другим атрибутам мониторинга, текстовые атрибуты используются для описания значений определенных МТЕ. Они предоставляют только информацию; они не включают сигналы.
Рис. 16.3. Элементы монитора
Объект мониторинга
Все атрибуты мониторинга, которые относятся к общему объекту или ситуации, объединяются в логическую единицу — объект мониторинга. Входящие данные для объекта монитора хранятся физически в сегменте монитора в области памяти. Примерами объектов монитора являются:
► Dialog, включающий атрибуты мониторинга ResponseTime, ProgramErrors и UsersLoggedIn
► R3Syslog, включающий атрибуты мониторинга BasisSystem, Database и Applications
► Server Configuration, включающий атрибуты мониторинга R/3 Kernel Release, Machine Type и Host
Объект монитора является также МТЕ, наименьшим итоговым узлом монитора. Несколько МТЕ можно объединить, чтобы сформировать другой МТЕ для улучшения обозримости вывода. Если сигнал порождается атрибутом мониторинга (например, потому что входящие данные превышают сконфигурированное пороговое значение или падают ниже его), соответствующий атрибут и все узлы более высокого уровня выделяются на изображении красным цветом. Следовательно, взгляд на узел верхнего уровня показывает администратору, когда возникла проблема, по крайней мере, с одним из подчиненных атрибутов в дереве иерархии. Желтый фон указывает на предупреждение; зеленый — на нормальный статус системы (см. рис. 16.4).
Рис. 16.4. Вывод статуса узла с помощью цветовых сигналов
Реальные и виртуальные МТЕ
Если данные для МТЕ сохраняются в отдельном сегменте монитора, то этот МТЕ реальный. МТЕ, которые только улучшают вид изображения и не имеют своих собственных сегментов монитора, называются виртуальными. Различные пиктограммы могут помочь визуализировать и лучше понимать значения узлов монитора и их соответствующих атрибутов. Самый верхний итоговый узел монитора формирует контекст монитора.
16.1.3. Техническая реализацияЧтобы обеспечить вывод текущих значений и (если необходимо) сигналов, соответствующие характеристики должны регулярно собираться и становиться доступными.
Сборщики данных
Эти задачи выполняют сборщики данных (см. рис. 16.1). Эти программы, написанные на C, АВАР или Java, собирают требуемые данные и сохраняют их в определенных сегментах памяти (сегментах монитора) на сервере. Кроме собранных данных, в сегменте памяти также сохраняются определенные пользователями пороговые значения. Просто анализируя память, система может обнаружить отклонения от пороговых значений. Можно добавлять свои собственные сборщики данных, если требуется собирать и контролировать дополнительные данные. Эти сборщики можно интегрировать в архитектуру мониторинга с помощью определенных программных интерфейсов.
Одним из примеров важного сборщика является сборщик данных операционной системы saposcol (см. главу 15). saposcol является независимой программой, которая выполняется на каждом сервере независимо от инстанции SAP и определяет подходящие данные операционной системы. Примеры включают:
► Использование памяти (виртуальной и физической)
► Загрузку ЦП, деленную в процентном отношении на время системы, время пользователя и время простоя
► Использование физического дискового пространства и файловых систем
► Использование ресурсов текущими процессами
Данные, которые собираются каждые десять секунд согласно конфигурации по умолчанию, находятся в определенной общей области памяти на сервере, saposcol использует эту область также для хранения средних значений, вычисляемых каждый час для многих объектов мониторинга. Эти данные переносятся из общего сегмента памяти в таблицы базы данных для дальнейшего анализа.
Поскольку деятельность saposcol зависит от системы, то для каждой операционной системы определяются слегка разнящиеся данные.
Примерами других сборщиков данных являются отчет RSDSLAN1, который собирает данные в ЛВС для метода CCMS_OSJLAN, и модуль функций RDDS_BP_CLASSAWP, который подсчитывает число фоновых процессов, зарезервированных для запросов класса A для метода CCMS_BP_ CLASSA_WR.
Агенты
Компоненты SAP без ядра R/3 или внешних систем играют особую роль. SAP предоставляет так называемых агентов для этих компонентов. Агентов устанавливают на соответствующих серверах и контролируют требуемые компоненты. Агенты имеют собственные сегменты памяти на сервере, где они хранят собранные данные. Оттуда данные можно переслать назначенной центральной контролирующей инстанции через интерфейс вызова удаленной функции (REC).
Рис. 16.5. Использование агентов
SAP предоставляет следующих агентов для различных систем:
► SAPCCMSR
Этот агент работает вместе со сборщиком данных операционной системы saposcol. Агент управляет этими данными в соответствующей общей области памяти и посылает их выбранной инстанции R/3. Эта техника может использоваться для любого компонента SAP, а также для систем, отличных от SAP. Кроме анализа данных в ►Alert Monitor можно также оценить их из ►OS System Configuration.
► SAPCCM4X
