Создание преобразования в Azure Monitor

Статья
12/19/2024

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

Примечание.

Если вы не знакомы с KQL или создаете запросы журналов для данных Azure Monitor, начните с обзора Log Analytics в Azure Monitor и запросах журналов в Azure Monitor.

Базовая структура запросов

Все запросы преобразования начинаются с source. Это виртуальная таблица, представляющая входной поток. Затем можно использовать любые поддерживаемые операторы KQL для фильтрации, изменения или добавления столбцов в данные, как и в любой другой таблице. Запрос применяется отдельно к каждой записи, отправляемой источником данных.

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

Вы можете опустить любые столбцы, которые не должны быть заполнены. Столбец будет пуст для записи в целевой таблице.
Не забудьте исключить любые столбцы, не включенные в выходную таблицу. Данные будут приняты без ошибок, но вы будете взиматься за прием дополнительных данных, даже если он не хранится.
Выходные данные каждого преобразования должны содержать допустимую метку времени в столбце, называемом TimeGenerated типом datetime. Если источник данных не включает это свойство, его можно добавить в преобразование с extend помощью или project.

Ниже приведен пример преобразования, выполняющего несколько функций:

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

source  
| where severity == "Critical" 
| extend Properties = parse_json(properties)
| project
    TimeGenerated = todatetime(["time"]),
    Category = category,
    StatusDescription = StatusDescription,
    EventName = name,
    EventId = tostring(Properties.EventId)

Примечание.

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

Создание запроса преобразования

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

Внимание

Преобразования не поддерживают все функции KQL. Поддерживаемые функции KQL см. в преобразованиях Azure Monitor для поддерживаемых функций и ограничений.

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

Syslog | where SeverityLevel != 'info'

Этот запрос можно вставить в DCR, а затем изменить имя sourceтаблицы на .

source | where SeverityLevel != 'info'

Используйте одну из следующих стратегий для использования данных для тестирования запроса.

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

Добавление преобразования в DCR

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

Примечание.

Некоторые источники данных предоставляют метод с помощью портал Azure для добавления преобразования в DCR. Например, сбор текста из виртуальной машины позволяет указать запрос преобразования в портал Azure. Большинство сценариев сбора данных, хотя в настоящее время требуют непосредственной работы с определением DCR для добавления преобразования. Это процесс, описанный в этом разделе.

Запрос преобразования указывается в свойстве transformKql в разделе Поток данных s DCR. Это раздел, который связывает источник данных с назначением. Преобразование применяется к входящему потоку потока данных перед отправкой в место назначения. Он будет применяться только к тому потоку данных, даже если тот же поток или назначение используется в других потоках данных.

transformKql Если свойство опущено или если его значение простоsource, преобразование не применяется, а входящие данные отправляются в место назначения без изменения.

Внимание

Запрос преобразования должен находиться в одной строке DCR. Если вы создаете преобразование в портал Azure, можно использовать несколько строк для удобочитаемости и \n включаться в запрос для каждой новой строки.

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

"dataFlows": [ 
    { 
        "streams": [ 
        "Microsoft-Syslog" 
        ], 
        "destinations": [ 
        "centralWorkspace" 
        ] 
    } 
]

В следующем примере имеется простой запросsource, transformKql поэтому входящие данные отправляются в место назначения без изменения. Его функциональные возможности идентичны предыдущему примеру.

"dataFlows": [ 
    { 
        "streams": [ 
        "Microsoft-Syslog" 
        ], 
        "transformKql": "source", 
        "destinations": [ 
        "centralWorkspace" 
        ] 
    } 
]

В следующем примере имеется запрос, transformKql который фильтрует данные, поэтому только сообщения об ошибках отправляются в место назначения.

"dataFlows": [ 
    { 
        "streams": [ 
        "Microsoft-Syslog" 
        ], 
        "transformKql": "source | where message has 'error'", 
        "destinations": [ 
        "centralWorkspace" 
        ] 
    } 
]

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

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

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

портале Azure
JSON

Преобразование рабочей области можно создать в портал Azure, добавив преобразование в поддерживаемую таблицу.

В меню рабочих областей Log Analytics в портал Azure выберите "Таблицы". Щелкните справа от нужной таблицы и выберите "Создать преобразование".
Если для этой рабочей области еще не было создано преобразование рабочей области, выберите параметр для создания. Если он уже создан, то этот DCR уже будет выбран. Каждая рабочая область может иметь только один DCR рабочей области.
Нажмите кнопку "Рядом", чтобы просмотреть примеры данных из таблицы. Щелкните редактор преобразования, чтобы определить запрос преобразования.
Затем можно изменить и запустить запрос преобразования, чтобы просмотреть результаты для фактических данных из таблицы. Продолжайте изменять и тестировать запрос, пока не получите нужные результаты.
Когда вы удовлетворены запросом, нажмите кнопку "Применить", а затем "Далее" и "Создать", чтобы сохранить DCR с новым преобразованием.

Контроллеры домена преобразования рабочей области в основном похожи на любой другой DCR. Они используют ту же структуру JSON для определения, и вы можете создать и изменить их с помощью одних и того же команды и стратегий, описанных в статье "Создание или изменение DCR с помощью JSON". Различия связаны с определением JSON:

Он должен включать kind параметр со значением WorkspaceTransforms.
Раздел dataSources должен быть пустым.
Этот destinations раздел должен содержать одно и только одно назначение рабочей области Log Analytics. Это рабочая область, в которой будет применено преобразование.
Раздел dataFlows должен содержать отдельный поток данных для каждой таблицы, которая будет иметь преобразование. Используйте предложение в запросе where , если необходимо преобразовать только определенные записи.

Ниже приведен пример определения JSON для преобразования рабочей области DCR.

{
    "kind": "WorkspaceTransforms",
    "location": "eastus",
    "properties": {
        "dataSources": {},
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/71b36fb6-4fe4-4664-9a7b-245dc62f2930/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
                    "name": "MyWorkspace"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Microsoft-Table-LAQueryLogs"
                ],
                "destinations": [
                    "MyWorkspace"
                ],
                "transformKql": "source | where QueryText !contains 'LAQueryLogs'"
            },
            {
                "streams": [
                    "Microsoft-Table-Event"
                ],
                "destinations": [
                    "MyWorkspace"
                ],
                "transformKql": "source | project-away ParameterXml"
            }
        ],
        "provisioningState": "Succeeded"
    }
}

Оптимизация и мониторинг преобразований

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

Внимание

Если преобразование занимает более 20 секунд, может возникнуть потеря данных.

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

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

Длительность преобразования журналов за минуту
Ошибки преобразования журналов за минуту

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

Руководство

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

сбор данных	Справочные материалы
API приема журналов	Отправка данных в журналы Azure Monitor с помощью REST API (портал Azure) Отправка данных в журналы Azure Monitor с помощью REST API (шаблоны Azure Resource Manager)
Виртуальная машина с агентом Azure Monitor	Добавление преобразования в журнал Azure Monitor
Кластер Kubernetes с аналитикой контейнеров	Преобразования данных в аналитике контейнеров
Центры событий Azure	Руководство. Прием событий из Центры событий Azure в журналы Azure Monitor (общедоступная предварительная версия)

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

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

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

Создание преобразования в Azure Monitor

Базовая структура запросов

Создание запроса преобразования

Добавление преобразования в DCR

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

Оптимизация и мониторинг преобразований

Руководство

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

Обратная связь

Дополнительные ресурсы