Миграция из System Center Operations Manager (SCOM) в Azure Monitor

  • Статья

В этой статье приводятся рекомендации для клиентов, которые в настоящее время используют System Center Operations Manager (SCOM) и планируют переход на облачный мониторинг с помощью Azure Monitor при переносе бизнес-приложений и других ресурсов в Azure.

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

Мониторинг гибридного облака

Большинство клиентов используют стратегию гибридного мониторинга облака, которая позволяет постепенно перейти в облако. Такой подход позволяет поддерживать существующие бизнес-процессы по мере того, как вы ознакомитесь с новой платформой. Отойти от функциональности SCOM можно только так, как его можно заменить Azure Monitor. Несколько средств мониторинга добавляют сложность, но это позволяет воспользоваться возможностью Azure Monitor отслеживать облачные рабочие нагрузки следующего поколения при сохранении возможности SCOM отслеживать серверное программное обеспечение и рабочие нагрузки сервера.

Ваша среда перед переносом компонентов в Azure включает виртуальные и физические компьютеры, размещенные локально или у поставщика управляемых служб. Она использует SCOM для мониторинга бизнес-приложений, серверного программного обеспечения и других компонентов инфраструктуры в вашей среде, таких как физические серверы и сети. Вы используете стандартные пакеты управления для серверного программного обеспечения, например IIS, SQL Server и программные продукты различных поставщиков, и настраиваете эти пакеты управления с учетом конкретных требований. Вы создаете пользовательские пакеты управления для бизнес-приложений и компонентов, которые нельзя отслеживать с помощью существующих пакетов управления, а также настраиваете SCOM для поддержки бизнес-процессов.

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

В течение этого периода перехода у вас есть два независимых средства мониторинга. Вы используете аналитические сведения и книги для анализа облачной телеметрии в портал Azure при использовании консоли управления для анализа данных, собранных SCOM. Так как каждая система имеет собственное оповещение, необходимо создать группы действий в Azure Monitor, эквивалентные группам уведомлений в SCOM.

В следующей таблице описаны различные функции и стратегии, доступные для гибридной среды мониторинга с помощью SCOM и Azure Monitor.

Метод Description
Агенты с двумя домами SCOM использует microsoft Management Agent (MMA), который совпадает с агентом Log Analytics, используемым Azure Monitor. Этот агент можно настроить для одновременного подключения одного компьютера к SCOM и Azure Monitor. Для этой конфигурации требуется, чтобы виртуальные машины Azure имели подключение к локальным серверам управления.

Агент Log Analytics был заменен агентомAzure Monitor, что обеспечивает значительные преимущества, включая более простое управление и более эффективное управление сбором данных. Два агента могут сосуществовать на одном компьютере, позволяя подключаться как к Azure Monitor, так и к SCOM. Эта конфигурация лучше, чем двойное указание устаревшего агента из-за значительных преимуществ агента Azure Monitor.
группа управления Подключение Подключение группу управления SCOM в Azure Monitor для пересылки данных, собранных агентами SCOM в Azure Monitor. Это аналогично использованию двухдоменных агентов, но не требует настройки каждого агента для подключения к Azure Monitor. Для этой стратегии требуется устаревший агент, поэтому невозможно указать мониторинг с правилами сбора данных. Вы также не можете использовать аналитику виртуальных машин, если вы не подключаете каждую виртуальную машину непосредственно к Azure Monitor.
Управляемый экземпляр SCOM (предварительная версия) Управляемый экземпляр SCOM (предварительная версия) — это полная реализация SCOM в Azure, которая позволяет продолжать работать с теми же пакетами управления, которые выполняются в локальной среде SCOM. Текущая интеграция данных и оповещений из SCOM и Azure Monitor отсутствует, и вы продолжаете использовать ту же консоль управления для анализа работоспособности и оповещений.

SCOM MI аналогичен поддержанию существующей среды SCOM и двухнаправленных агентов, хотя вы можете консолидировать конфигурацию мониторинга в Azure и удалить локальные компоненты, такие как базы данных и серверы управления. Агенты из виртуальных машин Azure могут подключаться к управляемому экземпляру SCOM в Azure, а не подключаться к серверам управления в собственном центре обработки данных.
Пакет управления Azure Пакет управления Azure позволяет системе Operations Manager обнаруживать ресурсы Azure и отслеживать их работоспособность на основе определенного набора сценариев мониторинга. Этот пакет управления требует дополнительной настройки для каждого ресурса в Azure. Это может быть полезно, хотя и обеспечить некоторую видимость ресурсов Azure в консоли управления, пока вы не будете развивать бизнес-процессы, чтобы сосредоточиться на Azure Monitor.

Мониторинг бизнес-приложений

Обычно для мониторинга бизнес-приложений с помощью SCOM требуются пользовательские пакеты управления с помощью агентов, установленных на каждой виртуальной машине. Приложение Аналитика в Azure Monitor отслеживает веб-приложения, будь то в Azure, других облаках или локальной среде. Его можно использовать для всех приложений независимо от того, были ли они перенесены в Azure.

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

  • Автоматическое обнаружение и мониторинг компонентов приложения.
  • Сбор подробных данных об использовании приложения и его производительности, таких как время отклика, частота сбоев и скорость выполнения запросов.
  • Сбор данных браузера, таких как просмотры страниц и производительность загрузки.
  • Обнаружение исключений и детализация трассировки стека и связанных запросов.
  • Расширенный анализ с помощью таких функций, как распределенная трассировка и интеллектуальное обнаружение.
  • Использование обозревателя метрик для интерактивного анализа данных о производительности.
  • Использование запросы к журналам для интерактивного анализа собранных данных телеметрии вместе с данными, собираемыми для служб Azure и VM Insights.

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

  • Для тестов доступности, которые позволяют отслеживать доступность и скорость реагирования приложений, а также получать соответствующие оповещения, требуются входящие запросы с IP-адресов агентов веб-тестов. Если политика не разрешает такой доступ, может потребоваться использовать мониторы доступности веб-приложений в SCOM.
  • В SCOM можно задать любой интервал опроса для тестов доступности, при этом многие клиенты проверка каждые 60–120 секунд. Приложение Аналитика имеет минимальный интервал опроса в течение пяти минут, который может быть слишком длинным для некоторых клиентов.
  • Значительное количество мониторинга в SCOM выполняется путем сбора событий, созданных приложениями и выполнением скриптов на локальном агенте. Эти функции не являются стандартными в Application Insights, поэтому для реализации соответствующих бизнес-требований может потребоваться дополнительная работа. В частности, может потребоваться создать собственные правила генерации оповещений на основе данные событий, которые хранятся в рабочей области Log Analytics, и с запуском скриптов на гостевой виртуальной машине с использованием гибридной рабочей роли runbook.
  • В зависимости от языка, на котором написано приложение, у вас могут быть ограничены возможности инструментирования, доступного для Application Insights.

Следуя базовой стратегии в других разделах этого руководства, продолжайте использовать SCOM для бизнес-приложений, но воспользуйтесь дополнительными функциями, предоставляемыми приложением Аналитика. По мере замены критически важных функций соответствующими возможностями Azure Monitor вы сможете постепенно отказываться от своих пользовательских пакетов управления.

Мониторинг виртуальных машин

Мониторинг программного обеспечения на виртуальных машинах в гибридной среде часто использует сочетание Azure Monitor и SCOM в зависимости от требований рабочих нагрузок, выполняемых на виртуальных машинах. Как только виртуальная машина создается в Azure, метрики платформы и журналы действий для узла виртуальной машины автоматически начинают собираться. Включите рекомендуемые оповещения, чтобы уведомить вас о распространенных ошибках узла виртуальной машины, таких как сервер вниз и высокая загрузка ЦП.

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

Продолжайте использовать пакеты управления для функциональных возможностей, которые не могут быть предоставлены другими функциями в Azure Monitor. Сюда относятся пакеты управления для критического важного серверного программного обеспечения, такого как IIS, SQL Server или Exchange. Кроме того, вы можете разрабатывать собственные пакеты управления для локальной инфраструктуры, которая недоступна для Azure Monitor. Кроме того, продолжайте использовать SCOM, если оно тесно интегрировано в операционные процессы, пока вы не сможете перейти к модернизации операций службы, где Azure Monitor и другие службы Azure могут расширить или заменить их.

Примечание.

Если вы включите Аналитика виртуальной машины с агентом Log Analytics вместо агента Azure Monitor, на виртуальной машине не нужно устанавливать дополнительный агент. Агент Azure Monitor рекомендуется, хотя и из-за его значительных улучшений в мониторинге виртуальной машины в облаке. Сложность обслуживания нескольких агентов смещается способностью определять мониторинг в правилах сбора данных, которые позволяют настроить различные коллекции данных для различных наборов виртуальных машин, аналогичных стратегии разработки пакетов управления.

Перенос логики пакета управления для рабочих нагрузок виртуальных машин

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

Пакеты управления в SCOM содержат правила и мониторы, которые объединяют сбор данных и результирующее оповещение в единый комплексный рабочий процесс. Данные, уже собранные SCOM, редко используются для оповещения. Azure Monitor отделяет сбор данных и оповещения в отдельных процессах. Правила генерации оповещений получают доступ к данным из журналов Azure Monitor и метрик Azure Monitor, которые уже были собраны из агентов. Кроме того, правила и мониторы обычно узко сосредоточены на конкретных данных, таких как определенное событие или счетчик производительности. Правила сбора данных в Azure Monitor обычно более широко собирают несколько наборов событий и счетчиков производительности в одном DCR.

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

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

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

select AlertName, COUNT(AlertName) as 'Total Alerts' from
Alert.vAlertResolutionState ars
inner join Alert.vAlertDetail adt on ars.AlertGuid = adt.AlertGuid
inner join Alert.vAlert alt on ars.AlertGuid = alt.AlertGuid
group by AlertName
order by 'Total Alerts' DESC

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

Искусственные транзакции

Пакеты управления часто используют искусственные транзакции, которые подключаются к приложению или службе, работающей на компьютере, для имитации подключения пользователя или фактического трафика пользователя. Если приложение доступно, можно предполагать, что компьютер работает корректно. Тесты доступности приложений Аналитика в Azure Monitor предоставляют эту функцию. Она работает только для приложений, доступных из Интернета. Для внутренних приложений необходимо внести изменения в настройки брандмауэра, чтобы разрешить доступ с конкретных URL-адресов Майкрософт, выполняющих тест. Кроме того, вы можете продолжать использовать существующий пакет управления.

Следующие шаги