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

2025-08-15

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

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

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

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

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

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

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

Процесс сбора данных 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.
Схема входящих данных.
Преобразования, применяемые к данным перед сохранением.
Назначение, в котором должны отправляться данные.

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

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

Замечание

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

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

Сопоставления правил сбора данных (DCRAs) используются для связывания DCR с отслеживаемым ресурсом. Это отношение "многие ко многим", где:

Один DCR может быть связан с несколькими ресурсами.
один ресурс может быть связан с до 30 контроллеров домена.

Это позволяет разработать стратегию для поддержания мониторинга между наборами ресурсов с различными требованиями.

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

Прямое прием

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

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

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

Конвейер Azure Monitor

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

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

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

Регионы DCR

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

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

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

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

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