ГЛАВА 16 АРХИТЕКТУРА МОНИТОРИНГА

ГЛАВА 16

АРХИТЕКТУРА МОНИТОРИНГА

В дополнение к мониторингу вручную и возможностям анализа (см. главу 15) использование автоматических средств архитектуры мониторинга улучшит как качество, так и надежность деятельности по администрированию системы.

В расширяемой инфраструктуре специализированные программы сбора накапливают и сохраняют данные и ключевые значения для заранее определенных объектов в общей области памяти и в таблицах базы данных систем mySAP. Эти данные можно анализировать на основе различных критериев, используя продукты независимых поставщиков и монитор сигналов (Alert Monitor), интегрированный в Систему управления вычислительным центром (CCMS — Computing Center Management System). В дополнение к локальному анализу самих контролируемых систем можно также сконфигурировать центральную систему mySAP, где собираются все данные систем SAP и других систем. Общая инфраструктура имеет три слоя:

? Сбор данных

? Сохранение данных

? Администрирование данных и анализ

Взаимодействие этих слоев представлено на рис. 16.1.

16.1. Монитор сигналов

16.1.1. Основы

В дополнение к локальному мониторингу отдельных систем архитектура мониторинга централизованно контролирует несколько систем mySAP — их критические компоненты, статистику и производительность в системной инфраструктуре. Внешние, отличные от SAP системы также могут присоединяться и контролироваться. Монитор сигналов (см. раздел 16.1.2) выводит значения, которые собраны и проанализированы согласно различным критериям в архитектуре мониторинга. Системный администратор может задавать зависящие от системы пороговые значения для входящей информации. Когда входящая информация превышает эти пороговые значения или падает ниже них, можно отметить такую ситуацию как неправильное функционирование (или сигнал), изменяя цвет светофора в Мониторе сигналов (см. рис. 16.3). Можно также определить методы анализа и автоматического реагирования, присвоить эти методы элементам дерева для подробного анализа проблемы, информировать системного администратора и включить автоматические исправляющие действия.

Рис. 16.1. Архитектура мониторинга

Основное достоинство Монитора сигналов состоит в том, что он независимо уведомляет системных администраторов об отклонениях, не требуя выполнения явного запроса или регистрации в соответствующей системе. Системы mySQL обладают рядом инструментов анализа для своих разнообразных компонентов (см. главу 15); однако администраторы должны самостоятельно инициировать такой анализ. Кроме того, разработанный SAP Монитор сигналов может анализировать системную инфраструктуру независимо на основе выбранных параметров и специально заданных пороговых значений и порождать при необходимости сигналы. Системный администратор может затем использовать специальные инструменты, интегрированные в программное обеспечение mySAP для запуска подробного анализа на основе информации Монитора сигналов, или может немедленно начать исправлять указанную проблему.

SAP предоставляет мониторы сигналов с каждым программным продуктом семейства mySAP. Эти мониторы сигналов включают все критические области системы, базы данных и средства администрирования на уровне операционной системы, требуемые для работы программных компонентов.

Набор мониторов

Мониторы сигналов объединяются для специальных целевых групп в так называемые наборы мониторов и поставляются с настройками по умолчанию, которые позволяют начать использовать их базовые функции немедленно после установки системы. Заранее определенные мониторы (с незначительными, зависящими от версии различиями) расположены в CCMS в ?Alert Monitor:

? 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

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

? SAPCM3X

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

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

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

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

1. Загрузите текущую версию агента из SAP Service Marketplace.

2. Скопируйте агента в его рабочий каталог.

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

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

- Мониторинг файлов журналов

- Мониторинг определенных файловых систем или процессов

- Мониторинг клиентов или транзакций

5. Перезапустите агента. На этом шаге соединения RFC с агентом создаются автоматически в центральной системе мониторинга.

Все агенты обратно совместимы по отношению к версии SAP. Это означает, что агент CCMS может работать в любой системе SAP вместе с версией, которая меньше или равна его собственной версии. Поэтому всегда необходимо использовать самые последние доступные версии агентов CCMS. Поскольку создание экземпляров агентов зависит от операционной системы, то SAP Service Marketplace имеет соответствующих агентов для различных операционных систем и их версий. Обычно все доступные агенты SAPCCMSR, SAPCCM4X и SAPCM3X архивированы в общем файле CCMAGENT.SAR. Загрузите соответствующий архив для используемого аппаратного окружения из SAP Service Marketplace из раздела /patches или с хоста служб SAP sapserv3 (см. главу 3). Воспользуйтесь для распаковки архива инструментом SAPCAR, который доступен в каждой инсталляции SAP.

Агентам требуется рабочий каталог для хранения файлов конфигурации и журналов (см. таблицу 16.1).

Таблица 16.1. Рабочие каталоги агентов мониторинга

Введите следующие команды для установки и регистрации агентов:

? sapccmsr -r [ -f <имя_файла_установки> ]

[ pf=<путь_доступа_к_профилю> ]

sapccm4x -r [ -f <имя_файла_установки> ]

[ pf=<путь_доступа_к_профилю> ]

sapcm3x -r [ -f <имя_файла_установки> ]

[ pf=<путь_доступа_к_профилю> ]

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

Значение пути доступа к профилю различается для агентов. Необходимо определять этот путь доступа к профилю для SAPCCM4X; в этом случае используется профиль контролируемой инстанции SAP. Если используются два другие агента, то вы узнаете, что либо не существует инстанции SAP (SAPCCMSR), либо версия SAP не имеет архитектуры оперативного мониторинга (SAPCM3X). В этом случае (при желании) файл профиля можно использовать для контроля следующих настроек:

? Размер сегмента монитора в байтах общей памяти как alert/MONI_SEGM_SIZE (только SAPCCMSR)

? Рабочий каталог агента и локальной программы saposcol, DIR_PERF

? Полный путь доступа сборщика данных операционной системы, exe/saposcol

Файлы журналов агентов

При запуске агента создается файл журнала <имя_агента><IDпроцесса>.log, в рабочем каталоге этого агента. Этот файл используется для записи всех шагов инициализации и сообщений об ошибках, вызванных выполнением агента. Также записываются любые проблемы с конфигурационными или управляющими файлами.

Агенты выполняются как службы в системе Windows и как процессы в UNIX. Поэтому агенты запускаются и останавливаются вместе с операционной системой Windows. В UNIX используют следующие явные команды

? sapccmsr -DCCMS [ pf=<путь_доступа_к_профилю>]

sapccm4x -DCCMS [ pf<путь_доступа_к_профилю>]

sapcm3x -DCCMS [ pf<путь_доступа_к_профилю>]

для запуска агентов и те же самые команды с параметром -stop для останова агентов.

Как только агенты будут запущены, собранная ими информация появляется в наборе мониторов. Данные агента SAPCCMSR расположены в ?Alert Monitor в наборе мониторов SAP CCMS Technical Experts Monitors, в разделе System/All Monitoring Segments/All Monitoring Contexts как виртуальный узел SAP_CCMS_<имя_хоста>; контексты с именем SAP_CCMS_<имя_хоста>_local принадлежат агенту SAPCM3X. Контексты данных, поставляемых SAPCCM4X, расположены в том же месте; единственным различием является тип коммуникации с инстанциями SAP. Если поставка информации от агента прерывается, то можно вывести обзор всех сегментов памяти, которые сообщают центральной инстанции мониторинга, используя ?Monitoring: Properties and Methods • Technical Infrastructure • Overview of Segments (до Basis Release 4.6D) или ?Monitoring: Properties and Methods • Technical Infrastructure • Display Topology (в Basis Release 6.10 и позже). Segment type Agent перечисляет требуемые сегменты, которые можно проанализировать после двойного щелчка.

16.2. Настройка монитора сигналов

Монитор сигналов (Alert Monitor) служит для визуального указания на критические ситуации. Цвета МТЕ, выводимые в дереве мониторинга, изменяются с зеленого на желтый или красный в зависимости от определенных пороговых значений и их уровня опасности. Определение критической ситуации различается от системы к системе. Поэтому необходимо настроить используемые по умолчанию значения, которые предоставляет SAP с наборами мониторов.

16.2.1. Интегрирование удаленных систем

Определение соединений RFC

Чтобы осуществлять мониторинг нескольких компонентов из центральной системы SAP, необходимо зарегистрировать нелокальные компоненты, которые желательно контролировать как новые контексты в

? Monitoring: Properties and Methods. Прежде всего необходимо определить два соединения RFC (см. главу 13). Рекомендуется определять соединения эти RFC следующим образом:

? Извлечение данных

Должен быть возможен доступ для чтения к общим сегментам памяти, которые содержат данные, чтобы извлекать данные, собранные на удаленных системах. Для этого необходимо сконфигурировать пользователя с типом «CPIC» (до Basis Release 4.6D) или «Communication» (в Basis Release 6.10 и позже).

? Функции анализа

Поскольку требуются дальнейшие операции для выполнения функций анализа, когда будет получен сигнал, необходимо определить требуемое соединение RFC со своим собственным именем пользователя (о настройках для текущего пользователя см. в главе 13).

Затем можно добавить другую систему в Technical Infrastructure • Create Entry for Remote Monitoring.

16.2.2. Создание мониторов и наборов мониторов, зависимых от заказчика

Начиная со стандартных наборов мониторов, можно создавать собственные специальные наборы мониторов и определять в них специфические объединенные мониторы. Преимущество определения собственного монитора состоит в том, что он ориентирован на специфические требования заказчика и специфические аспекты лежащей ниже системной инфраструктуры. Можно использовать мониторы, предоставленные SAP, как шаблоны для копирования; однако невозможно изменить самостоятельно стандартные мониторы. Если администратор интерфейса хочет, например, ограничить представление системной инфраструктуры определенными интерфейсами, то понадобится определить специальный монитор для обеспечения такого функционирования.

Для создания собственного монитора с требуемыми МТЕ сделайте следующее:

1. Вызовите функцию обслуживания на экране ?Alert Monitor через Extras • Activate Maintenance Functions. В меню появятся функции активного изменения.

2. Выберите Monitor (Set) • Create.

3. Ведите имя для набора мониторов и определите, кому разрешено его обслуживать и просматривать. Обратите внимание на то, что имя не должно начинаться с «SAP».

4. Сохраните введенные данные; при этом создается пустой набор мониторов в качестве контейнера для специфических мониторов заказчика.

5. Чтобы создать статический монитор в этом новом наборе мониторов, снова выберите Monitor (Set) • Create в новом наборе мониторов; будут выведены все доступные МТЕ.

6. Выберите все МТЕ, которые желательно включить в монитор, и сохраните монитор с легко запоминающимся именем.

Внесение изменений

Выбранные МТЕ интегрированы теперь в новый монитор. Если желательно сделать изменения, выберите Monitor (Set) • Change. В частности, если желательно добавить новую систему и сделать ее видимой в центральном мониторе, необходимо добавить соответствующие параметры дополнительной системы (см. выше). Поэтому имеет смысл использовать в больших динамических системных инфраструктурах добавление существующих мониторов на основе правил. Сначала либо выберите существующий монитор, который будет обновлен с помощью правил, либо создайте новый монитор, как описано выше. Затем действуйте следующим образом:

1. В существующей структуре выберите узел, который расположен там, где желательно добавить динамические значения.

2. При выборе Edit • Create Node • Rule node выводятся доступные правила, которые можно использовать для динамического улучшения структуры монитора во время запуска.

На рис. 16.6 показано добавление монитора с правилом CCMS_GET_ MTEJBY_CLASS в отношении всех доступных систем и МТЕ класса CPU_ Utilization. Когда вызывается монитор, текущие данные по использованию ЦП выводятся для всех систем, которые зарегистрированы и доступны через RFC.

При необходимости можно перенести набор мониторов на другие системы. Это означает, что сначала можно создать собственные наборы мониторов в системе разработки, протестировать их, а затем распространить в системной инфраструктуре. Для переноса наборов мониторов на другие системы используйте функцию ?Alert Monitor • Monitor (Set) • Transport Monitor Set.

16.2.3. Специальные настройки свойств

На следующем шаге настройки (Customization) необходимо настроить заранее заданные свойства объектов и атрибутов, чтобы отразить специальные системные требования. Оптимальным способом для этого является тонкая настройка собственных мониторов; если будут использоваться предоставленные стандартные мониторы, то также можно реализовать пользовательские настройки.

Properties в МТЕ делятся на следующие области, которые имеют различные значения в зависимости от типа используемого МТЕ.

Общие свойства

Можно определить следующие свойства в области General:

? Описание и вывод текста, который будет выводиться в мониторе, когда возникает сигнал, как комбинация класса сообщения и номера сообщения.

Рис. 16.6. Монитор на основе правил

? Видимость для групп пользователей в зависимости от полномочий пользователя (до Basis Release 4.6B).

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

? Настройки для свойств монитора

Эти настройки включают вес или важность настройки, максимальное число сигналов соответствующего типа для сохранения и ограничения для включения сигнала.

Методы

Каждому МТЕ можно присвоить до трех методов в области Methods. Функциональные модули, отчеты, URL или транзакции можно использовать в качестве методов. Также возможны команды на уровне операционной системы при условии, что они были определены как внешние команды (см. главу 9).

Определены следующие различные методы (см. рис. 16.7):

? Метод сбора данных

Метод сбора данных является инструментом, который поставляет значения контролируемым атрибутам, присвоенным в конечной инстанции. Необходимо различать активные и пассивные сборщики данных; только пассивные сборщики данных определяются и конфигурируются в архитектуре мониторинга. Наиболее важной спецификацией является частота, с которой собираются новые значения. Активные сборщики данных запускаются непосредственно контролируемыми приложениями и не контролируются Монитором сигналов (Alert Monitor). Данные сообщаются с нерегулярными интервалами, на которые невозможно влиять. Всем MTS уже присвоены по умолчанию методы сбора данных. Метод сбора данных <No Method> описывает активный сборщик данных, который невозможно модифицировать.

? Метод анализа

Метод анализа определяет, какое действие будет включаться для более подробного исследования проблемы, которая выводится в мониторе. Например, действие для МТЕ для мониторинга качества буфера R3BufferSpaceUsed, состоит в выводе анализа ?Buffer Load.

? Метод автоматического реагирования

Эти инструменты могут отвечать на включенный сигнал, например, посылая сообщение. В стандартных наборах мониторов не определены никакие методы автоматического реагирования. Если желательно использовать методы автоматического реагирования, необходимо определить их самостоятельно.

Прежде чем можно будет использовать отчет, функциональный модуль, URL или транзакцию в качестве метода, необходимо зарегистрировать соответствующий объект как метод и присвоить ему имя метода. Для этого запустите ?Monitoring: Properties and Methods и выберите Methods • Create New Method. Во время определения метода выясняют, какой тип метода вовлечен (сбор данных, анализ, автоматическое реагирование) и как он будет выполняться (вручную, в диалоговом или в фоновой режимах). Можно также присвоить параметры. Обзор Methods • Definitions содержит все доступные в системе методы, включая заранее сконфигурированные методы автоматического реагирования, которые можно использовать при необходимости. Например, шаблоны для отправки сообщений уже предоставлены SAP. Системный администратор может создавать новые инструменты и интегрировать их в системы mySAP в любое время. Можно написать программу АВАР, которая включает определенное действие в системе, когда возникает некоторая проблема.

Свойства производительности, статуса и журнала

Самый нижний уровень в дереве мониторинга содержит атрибуты мониторинга. Этим атрибутам мониторинга присвоены дополнительные пороговые значения (в наиболее широко понимаемом определении) в окне Properties. Определения пороговых значений различаются в зависимости от типа используемого свойства монитора:

? Атрибуты производительности

Сигнал включается, как только данные превышают сконфигурированное пороговое значение или падают ниже его. Пороговые значения активно используются при измерении производительности; в данном случае это понимается как мониторинг ResponseTime в МТЕ Dialog (см. рис. 16.8).

? Атрибуты статуса

Одним из примеров использования атрибута статуса для порождения сигнала является появление сообщения об ошибке в определенном компоненте, таком как задача обновления (см. рис. 16.9).

Рис. 16.7. Присвоение метода

? Атрибут журнала

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

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

Рис. 16.8. Определение порогового значения

Дополнительная информация

Последний человек, изменивший объект, записывается в свойстве Additional Information.

Можно сконфигурировать настройки обоих атрибутов самостоятельно и (более просто) их структур более высокого уровня. Чтобы изменить пороговое значение определенного атрибута, выполните следующее:

1. Выберите требуемый атрибут в ?Alert Monitor и выберите Properties.

2. Переключитесь из режима вывода в режим изменений и модифицируйте требуемые свойства.

3. Выберите Edit • Properties • Use for individual MTE, чтобы сохранить измененные свойства только для выбранного элемента.

Рис. 16.9. Свойство атрибута статуса

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

Классы МТЕ

Чтобы упростить администрирование, элементы дерева мониторинга с аналогичными физическими и логическими свойствами объединяются вместе в классы МТЕ. Класс МТЕ R3BufferHitRatio, например, объединяет все МТЕ, которые описывают качество буфера. Поэтому вместо присваивания метода анализа ?Buffer Load каждому МТЕ, можно выбрать атрибут класса для реализации изменения во всех МТЕ этого класса.

Группы атрибутов

Группы атрибутов характеризуют общие пороговые значения для генерации сигналов для выбранного типа объектов.

Варианты свойств

Может также оказаться полезным определить комбинацию присвоений методов, определений пороговых значений и общих свойств как вариант свойств. Например, системное поведение во время выполнения обновления или согласования отличается от нормального системного состояния, и может понадобиться реализовать различные процедуры автоматического реагирования для автоматического мониторинга ночью или днем. Можно создавать различные варианты свойств для различных ситуаций и активировать эти варианты вручную или автоматически (например, когда переключается операционный режим). Чтобы создать собственный новый вариант свойств, действуйте следующим образом:

1. Запустите ?Monitoring: Properties and Methods.

2. Выберите Properties • Variants • Create.

3. Можно выбрать существующий вариант в качестве порождающего варианта; свойства, которые не определены в порожденном варианте, копируются из порождающего варианта.

4. Введите имя варианта.

Можно также скопировать и изменить один из существующих вариантов:

1. Запустите ?Monitoring: Properties and Methods.

2. Выберите Properties • Variants • Create.

3. Будет выведена подборка свойств, которые можно скопировать.

4. Введите имя варианта.

Активируйте новый вариант, используя Variant • Activate. Новый вариант теперь сгенерирован и активирован. Все настройки Customizing, которые определяются в дальнейшем, будут автоматически присваиваться варианту свойств. Можно легко вернуться к значениям SAP по умолчанию, переключаясь на вариант свойств SAP-DEFAULT. Можно обслуживать несколько вариантов свойств, чтобы легко и быстро адаптировать мониторы к специальным ситуациям. Можно также переносить варианты свойств: если был создан и протестирован удовлетворительный вариант свойств в одной системе mySAP, то можно перенести этот вариант в любую другую систему mySAP. Для этого выберите ?Monitoring: Properties and Methods • Properties Variants • Variant Overview. Выберите необходимый вариант и выполните Variant • Transport.

Чтобы присвоить вариант свойств операционному режиму, выберите ?Maintain Operation Mode • Operation Mode • Change и введите вариант свойств.

16.3. Анализ мониторов сигналов

Чтобы обеспечить сохранение работоспособности системы mySAP и инфраструктуры необходимо обязательно анализировать сигналы. Существуют два представления событий мониторов. Начальный экран, вызываемый через Current Status, показывает все сигналы, действительные в данный момент. Можно нажать кнопку Open Alerts, чтобы перейти к представлению всех собранных сигналов. Дважды щелкните на МТЕ, чтобы вывести в виде таблицы соответствующие сигналы, которые хранятся по уровням опасности. Можно использовать кнопку Properties, чтобы определить, какие сигналы надо сохранить для каждого монитора: все, самые старые, самые новые или только те, что представляют текущий статус.

Чтобы удалить известные сигналы из вывода, щелкните на Complete • Alerts на этом изображении (или прямо из монитора сигналов). Выбранные значения сохраняются в базе данных сигналов, но не используются для оценки текущей ситуации; используются только новые значения. Отметим, что эту функцию необходимо применять только после анализа, если вы исключили причину проблемы или смогли диагностировать ее как не критическую. Щелкните на Show Alert History, чтобы вывести историю всех включенных до сих пор сигналов. Это позволяет оценить уровень опасности текущей ситуации относительно прошлых ситуаций. Выберите Goto • Display Details, чтобы вывести данные выбранного атрибута монитора. Если требуется более точный анализ проблемы, можно щелкнуть на значке Start Analysis Method или дважды щелкнуть на МТЕ, чтобы перейти прямо к транзакции, которая была определена как метод анализа.

Закрытие сигнала удаляет его из списка активных сигналов и сегмента монитора, однако он сохраняется в базе данных. Поэтому необходимо также периодически удалять эти записи из базы данных. Это можно сделать с помощью метода анализа для объекта мониторинга AlertsInDB в Monitor CCMS Self-monitoring совокупности SAP CCMS Technical Experts Monitor или конфигурируя автоматическую реорганизацию, которая удаляет сигналы из базы данных, когда сегмент монитора достигает определенного уровня заполнения или после определенного числа дней. Это делается с помощью изменения значения параметров CMPL_ALERT_AFTER_DAY и CMPL_ALERT_IF_QUOTA для метода CCMS_Segment_Space_Collect с помощью ?Monitoring: Properties and Methods • Methods • Definitions.

16.4. Примеры настройки

Мониторы сигналов доступны для всех системных компонентов SAP. Начальная основная задача для системного администратора состоит в настройке пороговых значений и обслуживании методов реагирования. Можно также сконфигурировать агентов (см. раздел 16.1.3), что предоставит дополнительные возможности мониторинга.

16.4.1. Анализ файла журнала

Можно использовать агентов SAPCCMSR, SAPCCM4X или SAPCM3X для анализа содержимого любых текстовых файлов. Агент ищет в файлах определенные текстовые строки и выводит результаты в монитор сигналов. Чтобы сконфигурировать адаптер журнала, выполните следующие действия:

? Определите файлы журналов для поиска

Записи Logfile в конфигурационном файле sapccmsr.ini

? Определите целевую текстовую строку

Запись Pattern в соответствующем управляющем файле для файла журнала

? Сконфигурируйте появление сигнала в центральном мониторе сигналов

Записи в соответствующем управляющем файле для файла журнала.

Конфигурационный файл sapccmsr.ini

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

Таблица 16.2. Конфигурационные записи в файле sapccmsr.ini

В листинге 16.1 показан пример конфигурационного файла. Файл c:saplocPRF-CLOGsapccmsrccmsini.ini был определен как управляющий файл для анализа файла журнала.

Листинг 16.1. Конфигурационный файл для агентов CCMS

### Конфигурационный файл для агентов CCMS SAPCCMSR,

### SAPCM3X и SAPCCM4X

###

### Формат записей для подключаемых модулей:

# Plugin <полный путь доступа общей библиотеки для загрузки>

###

### Формат записей для мониторинга файла журнала:

Logfile с:saplocPRFCLOGsapccms rccmsini.ini

###

### Формат записей для возможности удаления деревьев, если

### не существует соответствующего файла журнала:

### Этот параметр необязателен. Если он не определен, то

### дерево продолжает оставаться

# LogFileParam DelTree

###

### Формат записей для механизма фильтрации

### Значения SAPOSCOL:

# OsColFile <полный путь доступа шаблона oscolfile>

#

Листинг 16.2. Управляющий файл ccmsini.ini (Мониторинг файла журнала БД SAP)

LOGFILE_TEMPLATE

DIRECTORY="c:sapdbLVCdb"

FILENAME="knldiag"

MTE_CLASS="SAPDB_LOG"

SHOWNEWLINES=1

MONITOR_FILESIZE_KB=5

PATTERN_0="cannot"

VALUE_0=RED

SEVERITY_0=51

MESSAGEID_0="RT-013"

Настройки в этом управляющем файле означают, что файл knldiag в каталоге c:sapdbLVCdb анализируется автоматически. Все мониторы, которые агент сможет сгенерировать для контроля файла, присваиваются классу дерева мониторинга SAPDB_LOG (параметр MTE_CLASS). Преимущество такого подхода состоит в том, что все настройки и изменения в общих свойствах и методах влияют на этот класс МТЕ в общем.

SHOWNEWLINES заставляет выводиться в мониторе новые записи, которые были добавлены в этот файл в последнюю минуту. Размер файла также будет контролироваться. Если размер файла превышает определенное значение в 5 Кбайт, то будет включаться сигнал (параметр MONITOR_FILESIZE_KB). Можно использовать PATTERN_<x> для определения строк символов, которые будут включать сигнал. В предыдущем примере красный сигнал включается, когда будет найдено слово «cannot» (VALUE_<x>). Степень опасности сигнала (SEVERITY<x>) задана как 51. Сообщение 013 класса сообщений RT (MESSAGEID_<x>) является выводом. В этом месте при анализе данного файла можно использовать все сообщения, которые были определены в ?Message Maintenance и доступны. RT-013 означает «Подробное описание отсутствует». Управляющий файл завершается точкой «.» на последней строке файла.

16.4.2. Метод автоматического реагирования: Отправка почты

Одним из важных решений, которое будет неотделимо от конфигурирования монитора, является тип метода автоматического реагирования. Обычно в качестве метода автоматического реагирования можно использовать любой функциональный модуль и отчет. Автоматическое реагирование может включать также отправку e-mail, однако сначала необходимо будет сконфигурировать SAPconnect, чтобы система SAP могла послать e-mail (см. главу 13).

Затем необходимо присвоить соответствующий метод автоматического реагирования для отправки e-mail в случае красного сигнала. Стандартная система уже содержит соответствующий метод автоматического реагирования, который называется CCMS_OnAlert_Email.

1. Запустите ?Monitoring: Properties and Methods на клиенте 000 системы.

2. Выберите Methods • Definitions.

3. Сделайте двойной щелчок, чтобы выбрать метод CCMS_OnAlert_Email.

4. Настройте свойства метода, особенно параметры (Parameters). Можно определить отправителя как существующего пользователя

SAP на клиенте 000 или любого пользователя SAP с обозначением <SID>:<клиент>:<имя>, начиная с версии Basis Release 6.10. Определенный пользователь записывается как отправитель сигнализирующей почты, генерируемой монитором. Необходимо выбрать действительный адрес e-mail в качестве получателя (Recipient). Параметр Recipient Type определяет тип адреса. «U» обозначает e-mail Интернета. Генерируемые сообщения e-mail посылаются по этому адресу. Можно также использовать список распространения. Методы автоматического реагирования присваивают либо с помощью ?Monitoring: Properties and Methods • Properties • Assigned MTE Classes, Properties • Single MTEs, либо непосредственно в ? Alert Monitor.

Если желательно отправлять сообщения e-mail различным пользователям для каждого монитора сигналов, скопируйте метод CCMS_OnAlert_Email под другим именем и настройте параметры соответствующим образом.

16.4.3. Фильтрация системных журналов

В качестве другого примера использования мониторов сигналов в этом разделе показано, как фильтровать специфические сообщения из системного журнала системы SAP и отвечать на них. Можно, например, послать e-mail, когда возникает критическая ошибка базы данных. Отдельный набор мониторов предоставляется для анализа системных журналов инстанций mySAP. Эти мониторы расположены в ?Alert Monitor в разделе SAP CCMS Technical Expert Monitors • System /All Monitoring Segments / All Monitoring Context. Для каждой инстанции определяется узел, который посылает отчет системе SAP и имеет следующую структуру имени: <имя_хоста>_<SID>_<номер_инстанции>. Узел R3Syslog появляется ниже узла инстанции. Системный журнал дифференцируется дальше в зависимости от функции системы. Все мониторы в узле R3Syslog поставляются активными сборщиками (см. раздел 16.2.3); это означает, что их невозможно сконфигурировать непосредственно в архитектуре мониторинга.

Сообщения можно неявно фильтровать в системном журнале, переопределяя критичность сообщения. Обычно стандартные сообщения в системном журнале ранжируются с максимальной критичностью, равной 50, однако можно задать для критичности любое значение от 0 до 250.

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

Поскольку все мониторы системного журнала читают один и тот же сегмент мониторинга и обеспечиваются одним и тем же сборщиком данных ядра SAP, то изменения в одном мониторе системного журнала влияют на все другие мониторы системного журнала.

Выберите монитор системного журнала, такой как BasisSystem. Перейдите в область Properties и измените настройки сигнала в разделе Log Attribute. Задайте пороговое значение для красного сигнала больше 50. Затем увеличьте критичность выбранных сообщений (до значения больше 50). В дальнейшем только эти значения будут превышать пороговое значение красного сигнала. Существуют два способа настройки критичности сообщений.

Рис. 16.10. Методы в мониторах системного журнала

Обслуживание сообщений системного журнала

Выберите ?System Log Messages • Edit • List All Numbers, чтобы вывести список всех доступных в системе сообщений системного журнала. Выберите требуемое число, такое как BY2 - Database error 8с6 occurred at8c3. Вы автоматически перейдете на начальный экран ?System Log Messages; выбранный номер сообщения является заданным заранее. Выберите Edit • Maintain. Кроме определения категории, где сообщение системного журнала выводится в дереве монитора сигналов, можно также настроить критичность сообщения (см. рис. 16.11). Поэтому можно фильтровать сообщения выбранного системного журнала и включать для них специальные действия, увеличивая их критичность. В примере выше увеличение критичности для сообщения BY2 будет включать красный сигнал в случае ошибок базы данных.

Модификация монитора сигналов

Можно также изменить критичность сообщений системного журнала через монитор свойств в узле R2Syslog. Помните, что любые изменения в одном из мониторов будут влиять на все мониторы в узле R3Syslog. Изменения в мониторе сигналов будут переопределять все существующие определения, сконфигурированные при обслуживании системного журнала. Чтобы переконфигурировать критичность сообщения системного журнала, выберите Filters в свойствах монитора.

Такой подход позволяет отслеживать все изменения, сделанные в сообщениях в соответствующем мониторе. Однако не требуется знать номера сообщений.

Рис. 16.11. Обслуживание системного журнала

16.5. Советы

? Использование saposcol в диалоговом режиме

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

? saposcol -d

запускает диалоговый интерфейс. Можно ввести

? Collector> dump <parameter> <option>

чтобы вывести данные, которые saposcol записал в свой общий сегмент памяти. Введите quit или exit, чтобы выйти из диалогового режима.

? Активация мониторинга процесса с помощью saposcol

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

? $PROC

<имя_процесса> <имя_пользователя>

<имя_процесса> <имя_пользователя>

…

$

Можно заменить сегменты имен на «*». Необходимо перезапустить saposcol, чтобы активировать новую конфигурацию.

? Исключение из мониторинга файловых систем/дисковых областей

Можно исключить дисковые области и файловые системы из процесса мониторинга, например, если непрерывно поступают сигналы об известной ситуации, которая оценена как некритическая (например, если статическая дисковая область имеет уровень заполнения около 100%). Для этого включите в файл dev_filter в рабочем каталоге saposcol список файловых систем и дисковых областей, которые желательно исключить:

? $DISK

<имя_диска>

…

$FSYS

<имя_файловой_системы>

…

? Сокрытие данных в сегменте мониторинга

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

? Сортировка сигналов в списке сигналов