SAP R/3 Системное администрирование

► Текстовые атрибуты

В противоположность другим атрибутам мониторинга, текстовые атрибуты используются для описания значений определенных МТЕ. Они предоставляют только информацию; они не включают сигналы.

Рис. 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

Агент SAPCCM4X улучшает соединение между системой SAP с 4.x Basis и центральной системой мониторинга с Release 4.6C или более поздней версией. Для переноса собранных данных не требуется никакого диалогового рабочего процесса па центральном сервере.

► SAPCM3X

Необходимо установить агента SAPCM3X для мониторинга систем mySAP с версией Basis Release 3.x. Этот агент создает независимый общий сегмент памяти для управления данными.

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

Установка и регистрация агентов

Если желательно использовать агентов для дополнения системы мониторинга, поступите следующим образом: