Поделиться через


Правила сбора данных (DCR) в Azure Monitor

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

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

К конкретным преимуществам сбора данных на основе DCR относятся:

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

Просмотр контроллеров домена

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

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

Снимок экрана, показывающий правила сбора данных в портале Azure.

Заменены устаревшие методы сбора данных

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

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

Процесс сбора данных

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

  • Данные для сбора и отправки в Azure Monitor.
  • Схема входящих данных.
  • Преобразования, применяемые к данным перед сохранением.
  • Назначение, в котором должны отправляться данные.

Схема, показывющая поток данных для конвейера Azure Monitor.

Связи правил сбора данных (DCRAs)

Ассоциации с правилами сбора данных (DCRA) создаются между ресурсом и DCR, чтобы активировать определённые сценарии сбора данных. Это связь "многие ко многим", при которой один DCR может быть связан с несколькими ресурсами, а один ресурс может быть связан с максимум 30 DCR. Это позволяет разработать стратегию для поддержания мониторинга между наборами ресурсов с различными требованиями.

Использование DCR

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

Scenario Метод
Агент Azure Monitor (AMA) Ассоциация правил сбора данных (DCRA)
Центры событий Ассоциация правил сбора данных (DCRA)
Метрики платформы (предварительная версия) Ассоциация правил сбора данных (DCRA)
Прямое прием DCR, указанный в вызове API, который отправляет данные в Azure Monitor.
Трансформация рабочей области DCR DCR активен для рабочей области сразу после его создания.

Сценарии

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

Агент Azure Monitor (AMA)

Агент Azure Monitor (AMA) используется для сбора данных из виртуальных машин и кластеров Kubernetes. На следующей схеме показана сбор данных для AMA, работающей на виртуальной машине. Когда агент установлен, он подключается к Azure Monitor, чтобы получить все контроллеры домена, связанные с ним. В этом сценарии правила сбора данных указывают события и данные о производительности, которые необходимо собирать. Для кластера Kubernetes это также будет включать метрики Prometheus. Агент использует эти сведения для определения данных, собираемых с компьютера, и отправки в Azure Monitor. После доставки данных все преобразования , указанные в DCR, выполняются для фильтрации и изменения данных, а затем отправляют данные в указанную рабочую область и таблицу.

Дополнительные сведения см. в статье Сбор данных из клиента виртуальной машины с помощью Azure Monitor и включение мониторинга для кластеров Kubernetes .

Схема, показывающая базовую операцию агента Azure Monitor с помощью DCR.

Центры событий (предварительная версия)

На следующей схеме показано, как данные поступают в рабочую область Log Analytics непосредственно из Центров событий. Когда данные получены узлом событий, они отправляются в Azure Monitor, а затем преобразуются и направляются в любые пункты назначения, указанные в любых правилах сбора данных, связанных с ними.

Дополнительные сведения см. в разделе "Прием событий" из Центров событий Azure в журналы Azure Monitor (предварительная версия).

Схема, показывающая базовую операцию для данных концентратора событий, отправляемых в Azure Monitor.

Метрики платформы (предварительная версия)

Метрики платформы автоматически собираются из ресурсов Azure и отправляются в Azure Monitor Metrics. На следующей схеме показан процесс использования DCR для отправки этих данных в рабочую область Log Analytics для анализа с помощью запросов журналов. Это заменяет текущий метод использования параметров диагностики для выполнения этой функции.

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

Дополнительные сведения см. в разделе "Метрики", экспортируемые с помощью правил сбора данных .

Схема, показывающая базовую операцию для сбора метрик платформы DCR.

Прямое прием

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

Дополнительные сведения см. в API приема журналов .

Схема, показывающая базовую операцию для DCR с помощью API приема журналов.

DCR трансформация рабочей области

Преобразователи рабочей области предоставляют преобразования для сбора данных, которые не используют правила сбора данных (DCR). Они применяются непосредственно к рабочей области Log Analytics и автоматически активируются при их создании.

Дополнительные сведения см. в разделе "Преобразование рабочей области".

Схема, демонстрирующая базовую операцию преобразования рабочей области DCR.

Преобразования

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

Схема, демонстрирующая базовую концепцию преобразования.

Конвейер Azure Monitor

Конвейер Azure Monitor расширяет процесс сбора данных в собственный центр обработки данных. Он обеспечивает масштабируемую коллекцию и маршрутизацию данных телеметрии перед доставкой в облако.

Конкретные варианты использования конвейера Azure Monitor:

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

Схема, показывающая поток данных для пограничного конвейера Azure Monitor.

Регионы DCR

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

Размещение данных в одном регионе — это предварительная версия функции, которая позволяет хранить данные клиентов в одном регионе, и в настоящее время доступна только в регионе Юго-Восточная Азия (Сингапур) в Гео Азиатско-Тихоокеанского региона и в регионе Бразилия Южная (штат Сан-Паулу) в Гео Бразилия. По умолчанию в этих регионах включена однорегионная резиденция.

Дальнейшие действия

Для получения дополнительной информации о работе с DCR см. следующий раздел: