Ключевое понятие

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

   

С течением времени в Solution Manager появляются все новые возможности, в том числе — для мониторинга различных приложений множеством способов. Однако это неизбежно ведет к тому, что решать проблемы становится все сложнее, особенно если вы не занимаетесь администрированием Solution Manager на ежедневной основе. Эта статья призвана помочь в процессе поиска и устранения неполадок в функциональности технического мониторинга.

Технический мониторинг — исключительно многофункциональный инструмент в рамках SAP Solution Manager 7.1. Помимо стандартных операций, которые использует большинство, он позволяет выполнять мониторинг практически любого объекта. В версии Solution Manager 7.1 SP12 функциональность технического мониторинга подразделяется на пять типов:

1. Системный мониторинг
2. Самодиагностика Solution Manager
3. Мониторинг работы приложений у конечных пользователей (end-user experience monitoring)
4. Мониторинг интерфейсов и механизмов управления процессами (interface and process orchestration monitoring)
5. Мониторинг SAP BW и фоновых заданий

Прежде всего, автор статьи разбирает основы, позволяющие предотвратить возникновение проблем в принципе. Затем описываются инструменты анализа инфраструктуры мониторинга и уведомлений (Monitoring and Alerting Infrastructure, MAI), проверки провайдера данных (Data Provider Check) и устранения неисправностей показателей (Metric Troubleshoot). Будет показано, как инфраструктуры экстракторов/системы оповещений, администрирование агентов диагностики, E2e-MAI Servlet и инструменты Alerting Directory Browser позволяют обнаружить первопричину возникновения проблемы. Эти инструменты используются для поиска и устранения неполадок в основных компонентах Solution Manager, предназначенных для сбора данных в системах SAP.

Примечание

Эта статья написана для администраторов SAP с опытом настройки и управления функциональностью технического мониторинга (на базе версии Solution Manager 7.1 SP12). Если вы не знакомы с некоторыми понятиями, рассматриваемыми здесь, обратитесь к статье автора «Технический мониторинг в Solution Manager 7.1 в подробностях». Необходимо понимать, как происходит сбор данных, чтобы использовать рассматриваемые инструменты для поиска и устранения причин сбоя при их сборе.

      

Основы поиска и устранения неполадок: решение проблем до их возникновения

Первое, что необходимо усвоить относительно поиска и устранения неполадок в функциональности технического мониторинга — начинать с источника данных. В восьмидесяти процентах случаев проблема со сбором данных относится непосредственно к источнику. Либо инструмент, собирающий данные, нуждается в патче, либо он не функционирует должным образом. Приступая к новому проекту технического мониторинга в Solution Manager, автор всегда перепроверяет самые основы.

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

Важнейший момент — составная SAP-нота для Solution Manager (т.н. composite note). Она представляет собой совокупность всех SAP-нот, необходимых для успешного функционирования Solution Manager. Нота регулярно обновляется со стороны SAP. Автор проверяет корректную установку последней версии в системе.

Еще одна актуальная и регулярно обновляемая SAP-нота касается рекомендованных корректировок («Recommended Corrections»). В нее включены все компоненты, для которых должны быть применены патчи и последние обновления версий, в особенности некоторые Java-компоненты SAP NetWeaver, в том числе два наиболее важных: LM-Service и Wily-агенты. Как вы знаете, LM-Service (также известный как SOLMANDIAG) — основной компонент агентов диагностики. При установке патча на LM-Service в Solution Manager новый патч автоматически «раскатывается» на всех агентах диагностики. То же применимо для Wily-агентов. Эти агенты «раскатываются» во время выполнения конфигурации управляемых систем.

Следующий этап — проверить, что все шаги конфигурации управляемых систем выполнены корректно. Первый шаг — проверка актуальности информации по управляемым системам в базе данных управления ландшафтом (Landscape Management Database, LMDB). Необходимо убедиться, что Solution Manager «знает» обо всех компонентах, установленных в управляемой системе.

Второй шаг — проверка того, что в управляемой системе установлены последние версии плагинов ST-PI (Solution Tools Plug-in) и ST-A/PI (Service Tools for Applications Plug-in). Третий шаг — проверка наличия актуальных ролей безопасности в управляемой системе у всех пользователей системы Solution Manager, в том числе RFC-пользователей SM_<SID>, SMTM<SID>, SMB_<SID>, SM_ADMIN_<SID>, SM_COLL_<SID> и SMDAGENT_<SID>.

Четвертый шаг — проверка того, что на всех хостах в управляемой системе установлены агенты диагностики. Очень важный аспект (который упускается в 50 % случаев) — агенты хоста. Эти агенты необходимо обновить до последней версии.

Пятый шаг — проверка корректного подключения базы данных. Наконец, убедитесь, что все автоматические шаги были успешно выполнены. Необходимо, чтобы все они были завершены, чтобы гарантировать успешный сбор данных из каждой управляемой системы в Solution Manager.

Как узнать о наличии проблемы и откуда начинать поиск для ее устранения?

Узнать о проблеме с показателем или уведомлением можно, проверив статус показателя. Основной симптом сбоя в работе показателя — серый статус. У всех показателей может быть четыре статуса: зеленый, желтый, красный и серый. Первые три свидетельствуют о том, что данные, по крайней мере, были собраны. Серый статус появляется в результате неработающего или неправильно сконфигурированного показателя. Посмотреть статус показателей (в первую очередь серых) можно на панели системного мониторинга, доступной из рабочего места «Технический мониторинг» (рис. 1).

Рис. 1. Панель системного мониторинга 

На панели системного мониторинга также есть чрезвычайно полезный инструмент поиска и устранения неполадок для проверки сбора данных (Check Data Collection) (рис. 2). При запуске он проходит по всем шагам, необходимым для конкретного показателя, и сообщает, на каком шаге происходит сбой. Это отличная отправная точка для процесса поиска первопричины возникновения ошибки. Нажмите на стрелку рядом с серым показателем для отображения выпадающего списка и выбора пункта «Check Data Collection».

Рис. 2. Инструмент проверки сбора данных

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

Рис. 3. Проверка результатов сбора данных

Инструменты анализа MAI

Совокупность инструментов анализа MAI позволяет выполнять поиск и устранение неисправностей в уведомлениях во всех областях функциональности технического мониторинга. Отсюда же можно получить доступ к конфигурации и связанным областям MAI. Доступ к этим инструментам осуществляется из транзакции MAI_TOOLS (рис. 4). Для выполнения транзакции требуется роль SAP_SM_TECH_MON_TOOL. Инструменты разделены на пять категорий: анализ, журналы и трассировки, конфигурация, моделирование и ссылки по теме.

Рис. 4. Категории инструментов MAI

Раздел анализа, в свою очередь, разделен на пять категорий: общие инструменты (General), каталог системы предупреждений (Alerting Directory), коннектор провайдера данных (Data Provider Connector), программа вычисления событий (Event Calculation Engine) и отчетность (Reporting) (рис. 5). В каждом разделе расположены свои инструменты, специально разработанные для конкретных областей MAI. В статье будут рассмотрены четыре инструмента, которые автор считает наиболее полезными.

Рис. 5. Инструменты, доступные в разделе анализа

Инструмент Alerting Directory Browser

Инструмент Alerting Directory Browser — это, по существу, полный список всех оповещений, активированных в функциональности технического мониторинга (рис. 6). Инструмент особенно полезен по двум причинам. Во-первых, он позволяет быстро проанализировать, для каких систем активирован мониторинг и как настроены оповещения. Во-вторых, с его помощью можно получить все технические требования, необходимые для использования инструмента Metric Troubleshoot и некоторых других инструментов MAI, в том числе идентификаторы показателей и управляемых объектов, необходимые для запуска Metric Troubleshoot.