Введение в System Center Operations Manager 2012 (часть 5) — установка и настройка агента

Введение

Добро пожаловать обратно! До сих пор в этой серии вы узнали о многих новых функциях, которые появятся в System Center Operations Manager 2012, а также узнали о некоторых ключевых предпосылках, которые необходимо выполнить, прежде чем вы сможете приступить к установке этой инфраструктуры мониторинга технологий и системы.

В этой части 2 вы выполнили полную установку продукта и к концу статьи получили работающую систему.

В части 3 вы получили представление о структуре OpsMgr.

В части 4 вы узнали, как управлять агентами, которые играют ключевую роль в работе OpsMgr.

В этой части этой серии вы узнаете, как дополнительно управлять OpsMgr 2012.

Диспетчер операций

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

Однако есть много других частей головоломки, которые важно понять, прежде чем вы сможете углубиться в OpsMgr. По общему признанию, действительно заманчиво просто начать щелкать по консоли и устанавливать десятки пакетов управления, чтобы вы могли просто запустить и запустить все. Исходя из личного опыта, я могу гарантировать вам, что при использовании OpsMgr лучше придерживаться более методичного подхода. Каждый пакет управления и каждый элемент в пакете управления можно настраивать, и для них устанавливаются значения по умолчанию, которые, по мнению Microsoft, являются подходящими. Хотя это может быть верно для подавляющего большинства параметров, почти наверняка будут элементы, которые вы хотели бы отслеживать не так, как рекомендует Microsoft, или вы можете вообще пропустить мониторинг определенного компонента.

Вот простое эмпирическое правило, когда дело доходит до принятия решения о том, что контролировать: если конкретный контролируемый элемент выходит за рамки норм, собираетесь ли вы действовать в соответствии с ним? Пакеты управления OpsMgr могут отслеживать десятки, сотни или тысячи различных элементов. Вас, например, действительно волнует, работает ли сетевая карта, которую вы используете в выделенной резервной сети, с максимальным использованием в течение 2 часов каждую ночь? Возможно нет. Ведь это хорошо ! Чем выше загрузка, тем меньше времени потребуется для резервного копирования вашего сервера.

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

Со словами «медленно и методично» в качестве начального приказа убедитесь, что вы внимательно прочитали часть 3 этой серии, поскольку она содержит важную информацию о том, что содержится в пакетах управления. Я не собираюсь повторять здесь элементы, из которых состоят пакеты управления, но хочу повторить два важных момента. Во-первых, большинство пакетов управления, которые вы загружаете и устанавливаете , запечатаны. Запечатанный пакет управления на самом деле представляет собой двоичный файл с расширением.mp, и вы не можете редактировать этот файл напрямую. В некоторых случаях вы можете столкнуться с незапечатанным пакетом управления или создать его самостоятельно. Незапечатанные пакеты управления легко идентифицировать, потому что это обычные XML-файлы, которые вы можете редактировать по своему усмотрению. На рис. 1 вы можете увидеть некоторые файлы.mp, доступные в структуре каталогов.

Рисунок 1: файлы.mp в файловой системе

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

Что дает?

Именно здесь становятся очевидными реальная мощь и гибкость OpsMgr. С помощью так называемого переопределения вы можете изменить стандартное поведение запечатанного пакета управления и заставить OpsMgr выполнять ваши распоряжения. Довольно аккуратно, да?

Вот объяснение переопределения: Предположим, вы отслеживаете доступное дисковое пространство, и пакет управления по умолчанию хочет предупредить вас, когда у вас остается менее 20% доступного пространства. Создав переопределение для отдельного монитора, вы можете изменить поведение монитора, чтобы, например, предупреждать вас, когда у вас остается 5 % или меньше места на диске вместо 20 % по умолчанию. Вы создаете это переопределяющее правило в консоли OpsMgr, а затем сохраняете его в отдельном, но связанном незапечатанном пакете управления. Таким образом, вы вообще не изменяете исходный пакет управления. Скорее вы создаете правило, которое указывает OpsMgr переопределить поведение исходного пакета управления на основе правила, которое вы создаете в связанном пакете управления.

Прохладный!

Посмотрим, что там

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

Для начала посмотрим на узел Monitoring и перейдем к Active Alerts, показанному ниже на рисунке 2.

Рисунок 2. OpsMgr выдал предупреждение

Прежде всего, давайте определимся с терминологией. Когда OpsMgr с помощью правила в пакете управления определяет, что что-то пошло не так в отслеживаемом элементе, выдается предупреждение. Это то, что вы видите на рис. 2. В этой среде есть одно идентифицированное оповещение. Здесь вы можете увидеть детали предупреждения. В этом случае сценарий PowerShell не удалось запустить на самом сервере OpsMgr. Вы также можете увидеть, какое правило вызвало срабатывание предупреждения. Здесь действует правило «Предупреждение о неудачных сценариях Power Shell».

Если вы нажмете синий текст с надписью «Предупреждение о неудачных сценариях Power Shell», у вас будет возможность просмотреть фактическую конфигурацию правила, которая также может включать некоторые инструкции по смягчению последствий. На рисунке 3 взгляните на общую информацию об этом правиле. Вы можете увидеть, в каком пакете управления находится правило (System Center Core Monitoring). Если вы перейдете на вкладку «Информация о продукте» (показанная на рис. 4), вы увидите список возможных причин, а также рекомендации по их устранению. Хотя это верно не для каждого правила, приятно иметь точку отсчета.

Рисунок 3: Правило

Рисунок 4:
Знание продукта о правиле

Теперь давайте взглянем на потенциально более интересную информацию, которую можно почерпнуть из вашей установки OpsMgr. До этого момента мы рассматривали такие обыденные вещи, как оповещения. Но OpsMgr — это гораздо больше, чем просто система оповещения. Он также хранит подробную статистику производительности, которую вы можете использовать для отслеживания производительности на очень детальном уровне. Например, предположим, что вы хотите убедиться, что сам агент OpsMgr не является основной причиной проблем с производительностью клиента. Легкий! Взгляните на экран на рисунке 5.

Рис. 5. Производительность агента OpsMgr

Здесь вы видите производительность агента Opsmgr для двух отслеживаемых серверов в течение двенадцати часов. Как видите, производительность no time просто зашкаливала. Прошу прощения за размер графика. Мне приходится поддерживать низкое разрешение монитора на моем сервере OpsMgr, когда я работаю удаленно.

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

На рисунке 6 ниже вы увидите, что агент OpsMgr исправен на обоих моих наблюдаемых серверах. Но я хочу еще немного углубиться. Итак, я щелкнул правой кнопкой мыши EX1 и проследовал по дереву контекстного меню до Health Explorer для EX1.globomantics.com.

Рисунок 6: Статус главного агента

Health Explorer (показан на рис. 7) отображает информацию в четырех ключевых областях:

• Доступность
• Конфигурация
• Производительность
• Безопасность

Внутри каждого из этих компонентов вы можете иметь правила, относящиеся к этой области. Ранее мы рассмотрели график, показывающий использование процессов для выбранного агента OpsMgr. Итак, на рисунке 7 показано, почему эта информация захвачена. Существует правило, которое прямо предписывает агенту OpsMgr отслеживать эту информацию и сообщать о ней обратно в OpsMgr. Как вы можете видеть на рисунке 7, метрика в настоящее время имеет зеленую галочку, означающую, что все работает в пределах ожидаемых параметров.

Рисунок 7. Обозреватель работоспособности в действии

С учетом сказанного, что это за параметры? Что ж, давайте узнаем. Просто щелкните правой кнопкой мыши использование процессора агента и в контекстном меню выберите «Свойства монитора» (рис. 8). (Совет: во многих случаях вы также можете увидеть пороговые значения на экране, показанном на рис. 7 — взгляните на информацию на вкладке «Знания»).

Рисунок 8: Откройте свойства монитора

Когда вы попадете на страницу свойств, перейдите на вкладку «Конфигурация». Вы получите некоторый XML-код, подобный тому, что вы видите на рис. 9. Немного расшифровав, вы увидите, что порог загрузки процессора для агента OpsMgr составляет 25%. После 6 последовательных отчетов от системы о том, что агент OpsMgr работает за пределами 25% процессора, монитор будет переведен в критическое состояние. После того, как проблема будет устранена, потребуется 3 «хороших» результата, прежде чем состояние монитора станет зеленым.

Рисунок 9: Конфигурация монитора

Резюме

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