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

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

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

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

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

Сбор данных в Azure Monitor

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

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

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

Просмотр правил сбора данных

Существует несколько способов просмотра контроллеров домена в подписке.

Чтобы просмотреть контроллеры домена в портал Azure, выберите "Правила сбора данных" в разделе Параметрыв меню "Монитор".

Снимок экрана: контроллеры домена в портал Azure.

Выберите DCR, чтобы просмотреть его сведения. Для контроллеров домена, поддерживающих виртуальные машины, можно просматривать и изменять их связи и собираемые данные. Для других контроллеров домена используйте представление JSON для просмотра сведений о DCR. Дополнительные сведения о том, как их изменить, см. в статье "Создание и изменение правил сбора данных (DCR) в Azure Monitor .

Примечание.

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

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

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

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

Сценарии сбора данных

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

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

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

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

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

См . API приема журналов в Azure Monitor.
Центры событий Azure Отправка данных в рабочую область Log Analytics из Центры событий Azure. DCR определяет входящий поток и определяет преобразование для форматирования данных для целевой рабочей области и таблицы.

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

См . раздел DCR преобразования рабочей области в Azure Monitor.

Поддерживаемые регионы

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

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

Устойчивость данных и высокий уровень доступности

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

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

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