Структура правила сбора данных в Azure Monitor
Правила сбора данных (DCR) — это наборы инструкций, определяющих способ сбора и обработки данных телеметрии, отправляемых в Azure Monitor. Некоторые контроллеры домена будут созданы и управляются Azure Monitor. В этой статье описывается структура КОНТРОЛЛЕРОВ домена JSON для создания и редактирования их в тех случаях, когда необходимо напрямую работать с ними.
- Дополнительные сведения о работе с json, описанной здесь, см. в статье "Создание и изменение правил сбора данных (DCR) в Azure Monitor .
- Примеры правил сбора данных (DCR) в Azure Monitor см. в примерах контроллеров домена для различных сценариев.
Свойства
В следующей таблице описываются свойства на верхнем уровне DCR.
Свойство | Description |
---|---|
description |
Необязательное описание правила сбора данных, определенного пользователем. |
dataCollectionEndpointId |
Идентификатор ресурса конечной точки сбора данных (DCE), используемой DCR, если вы указали его при создании DCR. Это свойство отсутствует в контроллерах домена, которые не используют DCE. |
endpoints 1 |
Содержит logsIngestion и metricsIngestion URL-адрес конечных точек для DCR. Этот раздел и его свойства автоматически создаются при создании DCR только в том случае, если kind атрибут в DCR имеет значение Direct . |
immutableId |
Уникальный идентификатор правила сбора данных. Это свойство и его значение автоматически создаются при создании DCR. |
kind |
Указывает сценарий сбора данных, для который используется DCR. Этот параметр описан ниже. |
1Это свойство не было создано для контроллеров домена, созданных до 31 марта 2024 г. Контроллеры домена, созданные до этой даты, требуют конечной точки сбора данных (DCE) и указанного dataCollectionEndpointId
свойства. Если вы хотите использовать эти внедренные контроллеры домена, необходимо создать новый DCR.
Вид
Свойство kind
в DCR указывает тип коллекции, для которую используется DCR. Каждый тип DCR имеет другую структуру и свойства.
В следующей таблице перечислены различные типы контроллеров домена и их подробные сведения.
Вид | Description |
---|---|
Direct |
Прямое прием с помощью API приема журналов. Конечные точки создаются для DCR только в том случае, если используется это значение типа. |
AgentDirectToStore |
Отправка собранных данных в служба хранилища Azure и Центры событий. |
AgentSettings |
Настройка параметров агента Azure Monitor. |
Linux |
Сбор событий и данных о производительности с компьютеров Linux. |
PlatformTelemetry |
Экспорт метрик платформы. |
Windows |
Сбор событий и данных о производительности с компьютеров Windows. |
WorkspaceTransforms |
DCR преобразования рабочей области. Этот DCR не включает входной поток. |
Обзор потока данных DCR
Базовый поток DCR показан на следующей схеме. Каждый из компонентов описан в следующих разделах.
Входные потоки
В разделе входного потока DCR определяются входящие данные, собираемые. В зависимости от конкретного сценария сбора данных существует два типа входящего потока. Большинство сценариев сбора данных используют один из входных потоков, а некоторые могут использовать оба.
Примечание.
Контроллеры домена для преобразования рабочей области не имеют входного потока.
Входной поток | Description |
---|---|
dataSources |
Известный тип данных. Это часто данные обрабатываются агентом Azure Monitor и передаются в Azure Monitor с помощью известного типа данных. |
streamDeclarations |
Пользовательские данные, которые необходимо определить в DCR. |
Данные, отправленные из API приема журналов, используют streamDeclaration
схему входящих данных. Это связано с тем, что API отправляет пользовательские данные, которые могут иметь любую схему.
Текстовые журналы из AMA — это пример сбора данных, требующего обоих dataSources
и streamDeclarations
. Источник данных включает конфигурацию
Источники данных
Источники данных — это уникальные источники данных мониторинга, каждый из которых имеет собственный формат и метод предоставления своих данных. Каждый тип источника данных имеет уникальный набор параметров, которые должны быть настроены для каждого источника данных. Данные, возвращаемые источником данных, обычно являются известным типом, поэтому схема не должна быть определена в DCR.
Например, события и данные о производительности, собранные с виртуальной машины с агентом Azure Monitor (AMA), используют такие источники данных, как windowsEventLogs
и performanceCounters
. Вы указываете критерии для событий и счетчиков производительности, которые требуется собрать, но не нужно определять структуру самих данных, так как это известная схема для потенциальных входящих данных.
Общие параметры
Все типы источников данных используют следующие общие параметры.
Параметр | Описание |
---|---|
name |
Имя для идентификации источника данных в DCR. |
streams |
Список потоков, которые будет собирать источник данных. Если это стандартный тип данных, например событие Windows, поток будет находиться в форме Microsoft-<TableName> . Если это пользовательский тип, он будет находиться в форме Custom-<TableName> |
Допустимые типы источников данных
Типы источников данных, доступные в настоящее время, перечислены в следующей таблице.
Тип источника данных | Description | Потоки | Параметры |
---|---|---|---|
eventHub |
Данные из Центры событий Azure. | Пользовательский1 | consumerGroup — группа потребителей концентратора событий для сбора данных. |
iisLogs |
Журналы IIS с компьютеров Windows | Microsoft-W3CIISLog |
logDirectories — каталог, в котором журналы IIS хранятся на клиенте. |
logFiles |
Текстовый или json-журнал на виртуальной машине | Пользовательский1 | filePatterns — Шаблон папки и файла для сбора файлов журналов от клиента.format - json или text |
performanceCounters |
Счетчики производительности для виртуальных машин Windows и Linux | Microsoft-Perf Microsoft-InsightsMetrics |
samplingFrequencyInSeconds — частота выборки данных о производительности.counterSpecifiers — Объекты и счетчики, которые следует собирать. |
prometheusForwarder |
Данные Prometheus, собранные из кластера Kubernetes. | Microsoft-PrometheusMetrics |
streams — потоки для сбораlabelIncludeFilter — Список фильтров включения меток в виде пар "имя-значение". В настоящее время поддерживается только microsoft_metrics_include_label. |
syslog |
События системного журнала на виртуальных машинах Linux | Microsoft-Syslog |
facilityNames - Средства для сбораlogLevels — уровни журнала для сбора |
windowsEventLogs |
Журнал событий Windows на виртуальных машинах | Microsoft-Event |
xPathQueries — XPaths, указывающий критерии для событий, которые должны быть собраны. |
extension |
Источник данных на основе расширений, используемый агентом Azure Monitor. | Зависит от расширения | extensionName — имя расширенияextensionSettings — Значения для каждого параметра, требуемого расширением |
1 Эти источники данных используют как источник данных, так и объявление потока, так как схема собираемых данных может отличаться. Поток, используемый в источнике данных, должен быть пользовательским потоком, определенным в объявлении потока.
Объявления потоков
Объявление различных типов данных, отправленных в рабочую область Log Analytics. Каждый поток — это объект, ключ которого представляет имя потока, которое должно начинаться с custom-. Поток содержит полный список свойств верхнего уровня, содержащихся в данных JSON, которые будут отправлены. Форма данных, отправляемых в конечную точку, не должна соответствовать форме целевой таблицы. Вместо этого выходные данные преобразования, примененного на вершине входных данных, должны соответствовать целевой фигуре.
Типы данных
Возможные типы данных, которые можно назначить свойствам:
string
int
long
real
boolean
dynamic
datetime
.
Назначения
В destinations
разделе содержится запись для каждого назначения, в котором будут отправляться данные. Эти назначения соответствуют входным потокам в dataFlows
разделе.
Общие параметры
Параметры | Description |
---|---|
name |
Имя для идентификации назначения в dataSources разделе. |
Допустимые назначения
Доступные в настоящее время назначения перечислены в следующей таблице.
Назначение | Description | Обязательные параметры |
---|---|---|
logAnalytics |
Рабочая область Log Analytics | workspaceResourceId — идентификатор ресурса рабочей области.workspaceID — идентификатор рабочей областиЭто указывает только рабочую область, а не таблицу, в которой будут отправляться данные. Если это известное назначение, таблица не должна быть указана. Для пользовательских таблиц таблица указывается в источнике данных. |
azureMonitorMetrics |
Метрики Azure Monitor | Конфигурация не требуется, так как для подписки существует только одно хранилище метрик. |
storageTablesDirect |
Хранилище таблиц Azure | storageAccountResourceId — идентификатор ресурса учетной записи храненияtableName — Имя таблицы |
storageBlobsDirect |
Хранилище BLOB-объектов Azure | storageAccountResourceId — идентификатор ресурса учетной записи храненияcontainerName — Имя контейнера BLOB-объектов |
eventHubsDirect |
Event Hubs | eventHubsDirect — идентификатор ресурса концентратора событий. |
Внимание
Один поток может отправляться только в одну рабочую область Log Analytics в DCR. Вы можете использовать несколько dataFlow
записей для одного потока, если они используют разные таблицы в одной рабочей области. Если необходимо отправить данные в несколько рабочих областей Log Analytics из одного потока, создайте отдельный DCR для каждой рабочей области.
Потоки данных
Потоки данных соответствуют входным потокам с назначениями. Каждый источник данных может дополнительно указать преобразование, и в некоторых случаях укажите определенную таблицу в рабочей области Log Analytics.
Свойства потока данных
Раздел | Описание |
---|---|
streams |
Один или несколько потоков, определенных в разделе входных потоков. Вы можете включить несколько потоков в один поток данных, если вы хотите отправить несколько источников данных в одно место назначения. Используйте только один поток, хотя если поток данных включает преобразование. Один поток также можно использовать несколькими потоками данных, если требуется отправить определенный источник данных в несколько таблиц в одной рабочей области Log Analytics. |
destinations |
Одно или несколько назначений из приведенного destinations выше раздела. Для сценариев с несколькими адресами разрешено несколько назначений. |
transformKql |
Необязательное преобразование , применяемое к входящего потока. Преобразование должно понимать схему входящих данных и выходных данных в схеме целевой таблицы. При использовании преобразования поток данных должен использовать только один поток. |
outputStream |
Описывает таблицу в рабочей области, указанной в свойстве destination , в которую будут отправляться данные. Значение outputStream имеет формат Microsoft-[tableName] при приеме данных в стандартную таблицу или Custom-[tableName] при приеме данных в настраиваемую таблицу. Для каждого потока допускается только одно назначение.Это свойство не используется для известных источников данных из Azure Monitor, таких как события и данные о производительности, так как они отправляются в предопределенные таблицы. |
Следующие шаги
Общие сведения о правилах и методах сбора данных для их создания