Структура правила сбора данных (DCR) в Azure Monitor

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

• Дополнительные сведения о работе с JSON, описанной в этой статье, см. в разделе "Создание и изменение контроллеров домена".
• Примеры различных сценариев см. в разделе Sample DCR в Azure Monitor.

Свойства

В следующей таблице описываются свойства на верхнем уровне DCR.

¹ Это свойство не было создано для DCR, созданных до 31 марта 2024 г. Запросы на изменение данных, созданные до этой даты, требовали указания конечной точки сбора данных (DCE) и dataCollectionEndpointId свойства. Если вы хотите использовать эти внедренные контроллеры домена, необходимо создать новый DCR.

Добрый

Свойство kind в DCR указывает тип коллекции, для которую используется DCR. Каждый тип DCR имеет другую структуру и свойства.

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

Обзор потока данных DCR

Базовый поток DCR показан на следующей схеме. Каждый из компонентов описан в следующих разделах.

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

При многоэтапных преобразованиях раздел transformations добавляет конвейеры процессора, которые применяются на этапе источника данных (на стороне клиента) или на этапе потока данных (на стороне приема) в зависимости от того, где ссылается именованное преобразование.

Входные потоки

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

Данные, отправленные из API приема журналов, используют streamDeclaration схему входящих данных, так как API отправляет пользовательские данные.

Текстовые журналы агента Azure Monitor (AMA) являются примером сбора данных, для которых требуется как dataSources, так и streamDeclarations. Источник данных включает конфигурацию для подключения к источнику данных и streamDeclarations определяет схему входящих данных.

Источники данных

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

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

Общие параметры источника данных

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

Допустимые типы источников данных

В следующей таблице перечислены доступные в настоящее время типы источников данных.

¹ Эти источники данных используют как источник данных, так и объявление потока, так как схема собираемых данных может отличаться. Поток, используемый в источнике данных, должен быть пользовательским потоком, определенным в объявлении потока.

Объявления потоков

Объявите различные типы данных, которые вы отправляете в рабочую область Log Analytics. Каждый поток — это объект, ключ которого представляет имя потока, которое должно начинаться с custom-. Поток содержит полный список свойств верхнего уровня, содержащихся в отправляемых данных JSON. Форма данных, отправляемых в конечную точку, не должна соответствовать форме целевой таблицы. Вместо этого выходные данные преобразования, примененного поверх входных данных, должны соответствовать целевой форме.

Типы данных

Назначьте следующие типы данных свойствам:

• string
• int
• long
• real
• boolean
• dynamic
• datetime

Тип guid недоступен в объявлениях потоков. Если исходные данные содержат значения GUID, объявите эти столбцы как string. API таблиц поддерживает guid тип, но значения фактически хранятся и запрашиваются в виде строк. Дополнительные сведения см. в разделе Column типов данных в журналах Azure Monitor.

Назначения

Включите запись для каждого места назначения, в котором вы отправляете данные в destinations разделе. Сопоставляйте эти назначения с входными потоками в dataFlows разделе.

Общие параметры назначения

Допустимые назначения

В следующей таблице перечислены доступные назначения.

Потоки данных

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

Свойства потока данных

Transformations

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

"transformations": [
    {
        "name": "my_transform",
        "headerProcessor": {
            "processor": "header.Syslog",
            "configuration": { }
        },
        "processors": [
            {
                "processor": "filter.Basic",
                "configuration": {
                    "any": [
                        {
                            "all": [
                                {
                                    "columnName": "Facility",
                                    "operator": "==",
                                    "value": "auth"
                                }
                            ]
                        }
                    ]
                }
            }
        ]
    }
]

Свойства объекта преобразования

Объект Обработчика

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

{
    "processor": "{family}.{Name}",
    "configuration": { }
}

Типы процессоров

В следующей таблице показано, какие процессоры доступны на стороне клиента и на стороне приема.

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

Процессоры заголовков

Обработчики заголовков получают необработанные данные и преобразуют его в известный табличный формат схемы. Обработчик заголовков должен быть первым процессором в любом преобразовании.

Заголовка. Syslog

Заголовок на стороне клиента для источников данных системного журнала.

Заголовка. WindowsEvents

Заголовок на стороне клиента для источников данных журнала событий Windows.

Заголовка. WindowsPerformanceCounters

Заголовок на стороне клиента для источников данных счетчика производительности Windows.

Заголовка. LinuxPerformanceCounters

Заголовок на стороне клиента для источников данных счетчика производительности Linux.

Заголовка. TextLog

Заголовок на стороне клиента для пользовательских файлов текстового журнала.

Заголовка. IISLog

Заголовок на стороне клиента для источников данных журнала IIS.

Заголовка. WindowsFirewallLog

Заголовок на стороне клиента для источников данных журнала брандмауэра Windows.

Заголовка. StandardStream

Используется, если входные данные являются стандартным потоком, например Microsoft-Syslog или Microsoft-Event.

{
    "processor": "header.StandardStream",
    "configuration": {
        "streamId": "Microsoft-Syslog"
    }
}

Схема вывода: аналогичная стандартной схеме таблицы Log Analytics. См. справочник по таблицам Log Analytics схемы по типу ресурса.

Заголовка. CustomStream

Используется, когда входные данные — это пользовательский поток, определенный в streamDeclarations.

{
    "processor": "header.CustomStream",
    "configuration": {
        "streamId": "Custom-MyStream"
    }
}

После процессоров заголовков

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

Фильтр. Основные

Удаляет все записи на основе оценки условия. Условия структурированы как группы OR и группы AND.

{
    "processor": "filter.Basic",
    "configuration": {
        "any": [
            {
                "all": [
                    {
                        "columnName": "Facility",
                        "operator": "==",
                        "value": "auth"
                    }
                ]
            }
        ]
    }
}

Каждая группа AND имеет all свойство, содержащее массив объектов условий:

Схема вывода: то же, что и входные данные. Записи удаляются, а не столбцы.

Карта. Переименовать

Переименовывает столбец и при необходимости изменяет его тип.

{
    "processor": "map.Rename",
    "configuration": {
        "all": [
            {
                "columnName": "OldName",
                "nameAs": "NewName",
                "typeAs": "string"
            }
        ]
    }
}

Схема вывода: то же, что и входные данные, за исключением переименованных столбцов и столбцов с измененными типами.

Карта. Падение

Удаляет один или несколько столбцов из данных.

{
    "processor": "map.Drop",
    "configuration": {
        "columnNames": ["Column1", "Column2"]
    }
}

Схема вывода: то же, что и входные данные, за исключением удаленных столбцов.

Анализа. JsonPath

Анализирует строку в формате JSON в столбце и извлекает указанные ключи в новые столбцы.

{
    "processor": "parse.JsonPath",
    "configuration": {
        "columnName": "EventData",
        "all": [
            {
                "path": "$.user.name",
                "nameAs": "UserName",
                "typeAs": "string"
            }
        ]
    }
}

Свойства объекта извлечения:

Схема вывода: то же, что и входные данные, а также новые столбцы для каждого извлеченного ключа.

Анализа. XmlPath

Анализирует xml-форматированную строку в столбце и извлекает указанные элементы в новые столбцы.

{
    "processor": "parse.XmlPath",
    "configuration": {
        "columnName": "RawXml",
        "all": [
            {
                "path": "/Event/System/EventID",
                "nameAs": "EventID",
                "typeAs": "int"
            }
        ]
    }
}

Свойства конфигурации совпадают parse.JsonPath, за исключением path синтаксиса XPath (например, /Event/System/EventID или /Event/EventData/Data[@Name='SubjectUserName']).

Схема вывода: то же, что и входные данные, а также новые столбцы для каждого извлеченного элемента.

Анализа. CEFAttribute

Анализирует данные CEF (общий формат событий) в столбце и извлекает указанные поля в новые столбцы.

{
    "processor": "parse.CEFAttribute",
    "configuration": {
        "columnName": "Message",
        "all": [
            {
                "path": "deviceAction",
                "nameAs": "Action",
                "typeAs": "string"
            }
        ]
    }
}

Свойства конфигурации соответствуют parse.JsonPath, за исключением path указания имени ключа CEF.

Схема вывода: то же, что и входные данные, а также новые столбцы для каждого извлеченного поля.

Агрегат. Основные

Суммирует записи с помощью операторов агрегирования с измерениями группировки.

{
    "processor": "aggregate.Basic",
    "configuration": {
        "batchingSettings": {
            "timeWindow": "5m",
            "maxBatchRows": 1000
        },
        "aggregates": [
            {
                "columnName": "CounterValue",
                "operator": "avg",
                "nameAs": "AvgValue"
            },
            {
                "operator": "count",
                "nameAs": "RecordCount"
            }
        ],
        "dimensionColumns": ["Host", "CounterName"]
    }
}

Свойства статистической записи:

Схема вывода: агрегирование полностью изменяет выходную схему. Выходные данные содержат только агрегатные столбцы и столбцы измерений. Маршрутизация агрегированных данных в отдельную пользовательскую таблицу.

Обогатить. DNSLookup

Ищет IP-адрес в столбце и добавляет столбец DNS-имени.

{
    "processor": "enrich.DNSLookup",
    "configuration": {
        "columnName": "IPAddress",
        "nameAs": "DNSName"
    }
}

Схема вывода: то же, что и входные данные, а также новый столбец для разрешенного DNS-имени. Разрешение DNS — это лучшие усилия. Если поиск завершается ошибкой, выходной столбец содержит null.

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

Применяет настраиваемое выражение KQL для расширенных сценариев. Этот процессор используется только на стороне приема и обеспечивает ограниченную проверку KQL. Существующие контроллеры домена, используемые transformKql в потоках данных, имеют простой путь миграции с этим процессором.

{
    "processor": "transform.KQL",
    "configuration": {
        "expression": "source | where SeverityNumber >= 4 | extend EnrichedMsg = strcat(Host, ': ', Message)"
    }
}

Схема вывода: определяется KQL и не может быть статически проверена.

Связанный контент

• Общие сведения о правилах и методах сбора данных для их создания
• Создание и изменение правил сбора данных (DCR) в Azure Monitor
• преобразования Multi-stage в Azure Monitor
• Создайте преобразование в Azure Monitor
• Сбор данных из клиентов виртуальных машин