Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Агент Azure Monitor (AMA) заменяет агент Log Analytics, также известный как Microsoft Monitor Agent (MMA) и OMS, для компьютеров Windows и Linux, в Azure и средах, отличных от Azure, локальных и других облаков. Агент представляет упрощенный гибкий метод настройки сбора данных с помощью правил сбора данных (DCR). В этой статье описано, как реализовать успешную миграцию агента Log Analytics в агент Azure Monitor.
Миграция — это сложная задача. Начните планирование миграции на Azure Monitor Agent с помощью сведений в этой статье в качестве руководства.
Внимание
Агент Log Analytics был прекращен 31 августа 2024 года. Это не относится к агенту MMA, подключенном исключительно к локальной установке SCOM.
Вы можете ожидать следующее при использовании агента MMA или OMS после 31 августа 2024 г.
- Отправка данных: Облачные службы приема постепенно сокращают поддержку агентов MMA, что приведет к утрате поддержки приема и потенциальным проблемам совместимости для агентов MMA со временем. Возможности отправки не будут развернуты в новых регионах
- Установка. Возможность установки устаревших агентов будет удалена с портала Azure, а политики установки для устаревших агентов будут удалены. Вы все еще можете установить расширение MMA-агентов и выполнить автономные установки.
- Поддержка клиентов: вы не сможете получить поддержку для проблем со старыми версиями агентов.
- Поддержка ОС: Поддержка новых дистрибутивов Linux или Windows, включая пакеты обновления, не будет доступна после отмены устаревших агентов.
- Агент Log Analytics может сосуществовать с агентом Azure Monitor. Ожидается, что будут отображаться повторяющиеся данные, если оба агента собирают одни и те же данные.
Перед началом
Просмотрите предварительные требования для установки агента Azure Monitor. Чтобы отслеживать серверы вне Azure и локальные серверы, необходимо установить агент Azure Arc. Агент Arc делает локальные серверы видимыми в Azure в качестве ресурса, который он может нацеливать. Вы не несете никаких дополнительных затрат на установку агента Azure Arc.
Убедитесь, что агент Azure Monitor может решать все ваши потребности. Агент Azure Monitor находится в стадии общей доступности для сбора данных и используется для сбора данных различными функциями Azure Monitor и другими службами Azure.
Убедитесь, что у вас есть необходимые разрешения для установки агента Azure Monitor. У вас должны быть необходимые разрешения для установки агента на компьютерах, которые вы хотите отслеживать. Дополнительные сведения см. в разделе "Разрешения", необходимые для установки агента Azure Monitor.
Руководство высокого уровня
Используйте следующие рекомендации для планирования и выполнения миграции.
- Поймите своих агентов и сколько их нужно перенести.
- Узнайте, как вы используете рабочие области.
- Узнайте, какие решения, аналитические сведения и коллекции данных настроены.
- Настройте коллекции данных и проверьте коллекции.
- Ознакомьтесь с дополнительными зависимостями и службами.
- Удалите устаревшие агенты.
Книга помощника по миграции агента Azure Monitor — это решение Azure Monitor, построенное на базе рабочей книги, которое может помочь вам на каждом из шагов, описанных выше. Это руководство ссылается на рабочую тетрадь и другие инструменты на каждом этапе процесса миграции. Для получения дополнительной информации, см. рабочую книгу помощника по миграции агента Azure Monitor.
Поймите своих агентов
Используйте генератор DCR для автоматического преобразования конфигурации устаревшего агента в правила сбора данных.1. Чтобы понять агенты, ознакомьтесь со следующими вопросами:
| Вопрос | Действия |
|---|---|
| Сколько агентов нужно перенести? | Поймите, сколько агентов нужно перенести. |
|
У вас есть агенты, развернутые за пределами Azure? Развертываются ли эти агенты в собственном центре обработки данных или в другой облачной среде? |
Для серверов, которые находятся за пределами Azure, необходимо сначала развернуть агент подключенного компьютера Azure ARC. Дополнительные сведения см. в разделе "Обзор агента подключенного компьютера Azure". |
|
Вы используете System Center Operations Manager (SCOM) ? Каков ваш план по SCOM на будущее? |
Если вы планируете продолжать использовать SCOM, начните оценивать управляемый экземпляр SCOM. Для получения дополнительной информации см. раздел SCOM Managed Instance. |
| Как вы разворачиваете ваших агентов сегодня? | Если вы используете автоматизированные методы для развертывания устаревшего агента, рассмотрите возможность, когда нужно остановить эти автоматизированные развертывания для новых серверов и начните сосредотачиваться на развертывании нового агента. Остановка автоматического развертывания для новых серверов помогает убедиться, что вы не увеличиваете усилия по миграции, и позволяет сосредоточиться на существующем инвентаре агентов для миграции. |
Книга помощника по миграции агента Azure Monitor поможет вам понять, сколько агентов требуется перенести. Дополнительную информацию см. в вспомогательной программе миграции агента Azure Monitor - Справочник по агентам.
Поймите свои рабочие области, решения, аналитические данные и коллекции данных
Перед миграцией вы узнаете, как используются рабочие области Log Analytics. Проверьте, используются ли они и какие агенты отправляют данные телеметрии в рабочие области. Многие рабочие области создаются со временем и могут стать неясными, какие рабочие области фактически используются, какие рабочие области используются для сбора данных телеметрии и с каких серверов. Миграция — это хорошая возможность для очистки и консолидации рабочих областей.
При просмотре рабочих областей обратите внимание, какие решения настроены. Эта информация важна для понимания того, какие данные вы собираете и как вы используете.
Книга помощника по миграции агента Azure Monitor поможет вам понять, какие рабочие области у вас есть, и решения, реализованные в каждой рабочей области, и когда вы последний раз использовали решение. Каждое решение имеет рекомендацию по миграции. Дополнительные сведения см. в помощнике по миграции агента Azure Monitor для Рабочих областей.
Вы также можете использовать книгу аудита рабочей области Azure Monitor для понимания рабочих областей. Чтобы использовать книгу аудита рабочей области Azure Monitor, скопируйте книгу из репозитория GitHub и импортируйте ее в рабочую область Log Analytics.
Эта книга собирает все рабочие области Log Analytics и отображает следующие сведения для каждой рабочей области:
- Все источники данных, отправляющие данные в рабочую область.
- Агенты, отправляющие пульс в рабочую область.
- Ресурсы, отправляющие данные в рабочую область.
- Все ресурсы Application Insights, отправляющие данные в рабочую область.
Для получения дополнительной информации см. рабочую книгу "Аудит рабочего пространства Azure Monitor".
Настройка коллекций данных и проверка коллекций
При настройке коллекций данных рассмотрите следующие действия.
Определите пилотную группу серверов, которые можно использовать для этого процесса. Используйте пилотные серверы для проверки данных перед развертыванием в масштабе.
Используйте DCR Config Generator для преобразования коллекций данных, настроенных в рабочей области, и их развертывания в качестве правил сбора данных обратно в вашу среду. Дополнительные сведения о генераторе конфигурации DCR см. в разделе "Генератор конфигурации DCR".
Перенос аналитики виртуальных машин и Azure Monitor для виртуальных машин в агент Azure Monitor. Проверьте перенесенные коллекции данных для пилотной группы серверов по сравнению с тем, что было собрано до миграции. Чтобы избежать двойного приема данных, вы можете отключить сбор данных из устаревших агентов на этапе тестирования без удаления агентов, удалив конфигурации рабочей области для устаревших агентов. Дополнительные сведения см. в статье "Источники данных агента Log Analytics" в Azure Monitor
Проверьте новые данные, чтобы убедиться, что нет пробелов. Сравните данные, принятые устаревшими данными агента, с агентом Azure Monitor. Используйте KQL для сравнения эквивалентных данных каждого агента на основе типа агента.
Планирование масштабного развертывания, используя политику Azure. Используйте встроенные политики для развертывания расширений и сопоставлений DCR в масштабе. Использование политики также гарантирует автоматическое развертывание расширений и ассоциаций DCR для новых компьютеров. Дополнительные сведения о развертывании в масштабе см. в статье "Управление агентом Azure Monitor— использование политик Azure".
Общие сведения о дополнительных зависимостях и службах
До миграции важно понять, как это влияет на ваши другие службы.
| Сервис | Воздействие |
|---|---|
| Управление обновлениями | Если вы используете управление обновлениями в службе автоматизации Azure, необходимо перейти на Диспетчер обновлений Azure. Диспетчер обновлений Azure имеет свой собственный агент и отделен от агента Azure Monitor. Управление обновлениями будет выведено из эксплуатации в конце августа 2024 года. Рекомендуется выполнить миграцию в Диспетчер обновлений Azure. Для получения дополнительной информации см. Переход от управления обновлениями автоматизации к Диспетчеру обновлений Azure. В рабочей книге помощника по миграции AMA показано, какие из ваших компьютеров используют решение для управления обновлениями и как их перенести. Дополнительные сведения см. в вспомогательной книге по миграции агента Azure Monitor - Управление обновлениями. |
| Отслеживание изменений и инвентаризация | Если вы используете отслеживание изменений и инвентаризацию, необходимо выполнить миграцию в службу автоматизации Azure. Отслеживание изменений и инвентаризация также являются частью служба автоматизации Azure. Хотя агент Azure Monitor имеет решение для отслеживания изменений и инвентаризации, необходимо создать правило сбора данных. Дополнительные сведения см. в статье "Управление отслеживанием изменений и инвентаризацией" с помощью агента мониторинга Azure. |
| Defender для облака | Если вы используете Defender для облака для службы или Defender для серверов, а P2 включен или планируете включить P2 для серверов, измените развертывание агента в Defender для облака с развертывания устаревшего агента на сканирование без агента. Если вы используете Defender для облака для сбора событий безопасности, создайте настраиваемое правило сбора данных для сбора этих событий. |
| Microsoft Sentinel | Если вы используете Microsoft Sentinel, решения, использующие устаревший агент, были преобразованы в решения на основе агента Azure Monitor и могут быть обновлены. |
Удаление устаревших агентов
В рамках планирования миграции планируется удалить устаревший агент после завершения миграции, чтобы избежать дублирования сбора данных.
Если на компьютерах не требуется хранить MMA, используйте средство обнаружения и удаления MMA для удаления агента в большом масштабе. Дополнительные сведения о средстве обнаружения и удаления MMA см . в средстве обнаружения и удаления MMA.
Если, однако, вы используете System Center Operations Manager (SCOM), сохраните агент MMA, развернутый на тех компьютерах, которыми вы продолжите управлять с помощью System Center Operations Manager.
Существует пакет управления администратора SCOM и может помочь удалить конфигурации рабочей области в большом масштабе при сохранении конфигурации группы управления SCOM. Дополнительные сведения о пакете управления администраторами SCOM см. в разделе SCOM Admin Management Pack.
Известные проблемы миграции
- Журналы IIS. Если включена коллекция журналов IIS, AMA может не заполнять
sSiteNameстолбецW3CIISLogтаблицы. Это поле собирается по умолчанию, когда коллекция журналов IIS включена для устаревшего агента. Если необходимо собрать полеsSiteNameс помощью AMA, активируйте полеService Name (s-sitename)в журнале W3C IIS. Инструкции по активации этого поля можно найти в разделе «Выбор W3C полей для журнала». - Решение для оценки SQL: теперь это часть оценки лучших практик SQL. Для политик развертывания требуется одна рабочая область Log Analytics для каждой подписки, которая не рекомендуется для команды AMA.