Преобразования сбора данных в Azure Monitor
С помощью преобразований в Azure Monitor можно фильтровать или изменять входящие данные перед отправкой в рабочую область Log Analytics. В этой статье представлено базовое описание преобразований и их реализации. Он предоставляет ссылки на другое содержимое для создания преобразования.
Преобразования выполняются в конвейере приема данных в Azure Monitor после доставки данных источником данных и перед их отправкой в место назначения. Источник данных может выполнять собственную фильтрацию перед отправкой данных, но затем полагаться на преобразование для дальнейшей манипуляции перед отправкой в место назначения.
Преобразования определяются в правиле сбора данных (DCR) и используют инструкцию язык запросов Kusto (KQL), которая применяется отдельно к каждой записи в входящих данных. Инструкция должна определить формат входящих данных и создать выходные данные в структуре, ожидаемой местом назначения.
На следующей схеме показан процесс преобразования для входящих данных и показан пример запроса, который может использоваться. Сведения о создании запросов преобразования см. в разделе "Структура преобразования" в Azure Monitor .
Почему следует использовать преобразования
В следующей таблице описаны различные цели, которые можно достичь с помощью преобразований.
| Категория | Сведения |
|---|---|
| Удаление конфиденциальных данных | Возможно, у вас есть источник данных, который отправляет информацию, которую вы не хотите хранить по соображениям конфиденциальности или комплианности. Фильтрация конфиденциальных данных. Отфильтруйте все строки или определенные столбцы, содержащие конфиденциальную информацию. Маскирование конфиденциальной информации. Замените такие данные, как цифры в IP-адресе или номере телефона общим символом. Отправка в альтернативную таблицу. Отправка конфиденциальных записей в альтернативную таблицу с другой конфигурацией управления доступом на основе ролей. |
| Обогащение данных с помощью дополнительных или вычисляемых сведений | Используйте преобразование для добавления в данные информации, предоставляющей бизнес-контекст или упрощающей последующие запросы к данным. Добавьте столбец с дополнительными сведениями. Например, можно добавить столбец, определяющий, является ли IP-адрес в другом столбце внутренним или внешним. Добавьте сведения, относящиеся к бизнесу. Например, можно добавить столбец, указывающий подразделение компании на основании сведений о расположении в других столбцах. |
| Сокращение расходов на данные | Так как плата взимается за прием любых данных, отправленных в рабочую область Log Analytics, вы хотите отфильтровать любые данные, которые не требуются для снижения затрат. Удаление целых строк. Например, у вас может быть параметр диагностики для сбора журналов ресурсов из определенного ресурса, но не требует всех записей журнала, создаваемых им. Создайте преобразование, которое отбирает записи по определенным критериям. Удаление столбца из каждой строки. Например, данные могут содержать столбцы с избыточными или минимальными значениями. Создайте преобразование, отфильтровывающее ненужные столбцы. Анализ важных данных из столбца. У вас может быть таблица с ценными данными, похороненными в определенном столбце. Используйте преобразование для анализа ценных данных в новом столбце и удаления исходного столбца. Отправка определенных строк в базовые журналы. Отправляйте строки в данных, для которых требуются базовые возможности запроса, в базовые таблицы журналов для снижения затрат на прием. |
| Форматирование данных для назначения | У вас может быть источник данных, который отправляет данные в формате, который не соответствует структуре целевой таблицы. Используйте преобразование для переформатации данных в требуемую схему. |
Поддерживаемые таблицы
Сведения о таблицах, поддерживающих преобразования в журналах Azure Monitor, см. в списке таблиц, которые можно использовать с преобразованиями. Вы также можете использовать ссылку на данные Azure Monitor, в которой перечислены атрибуты для каждой таблицы, включая, поддерживает ли она преобразования. Помимо этих таблиц также поддерживаются любые пользовательские таблицы (суффикс _CL).
- Любая таблица Azure, указанная в таблицах, поддерживающих преобразования в журналах Azure Monitor. Вы также можете использовать ссылку на данные Azure Monitor, в которой перечислены атрибуты для каждой таблицы, включая, поддерживает ли она преобразования.
- Любая пользовательская таблица, созданная для агента Azure Monitor. (Пользовательская таблица MMA не может использовать преобразования)
Создание преобразования
Способы создания преобразований зависят от метода сбора данных. В следующей таблице приводятся рекомендации по различным способам создания преобразований.
| сбор данных | Справочные материалы |
|---|---|
| API приема журналов | Отправка данных в журналы Azure Monitor с помощью REST API (портал Azure) Отправка данных в журналы Azure Monitor с помощью REST API (шаблоны Azure Resource Manager) |
| Виртуальная машина с агентом Azure Monitor | Добавление преобразования в журнал Azure Monitor |
| Кластер Kubernetes с аналитикой контейнеров | Преобразования данных в аналитике контейнеров |
| Центры событий Azure | Руководство. Прием событий из Центры событий Azure в журналы Azure Monitor (общедоступная предварительная версия) |
Несколько назначений
С помощью преобразований можно отправлять данные в несколько назначений в рабочей области Log Analytics с помощью одного DCR. Вы предоставляете запрос KQL для каждого назначения, а результаты каждого запроса отправляются в соответствующее расположение. Вы можете отправлять разные наборы данных в разные таблицы или использовать несколько запросов для отправки разных наборов данных в одну таблицу.
Например, можно отправлять данные событий в Azure Monitor с помощью API приема журналов. Большинство событий должны отправляться в таблицу аналитики, в которой она может регулярно запрашиваться, а события аудита должны отправляться в настраиваемую таблицу, настроенную для базовых журналов, чтобы сократить затраты .
Чтобы использовать несколько назначений, необходимо вручную создать новый DCR или изменить существующий. В разделе "Примеры" приведены примеры контроллеров домена, использующих несколько назначений.
Внимание
В настоящее время таблицы в DCR должны находиться в той же рабочей области Log Analytics. Чтобы отправить в несколько рабочих областей из одного источника данных, используйте несколько контроллеров домена и настройте приложение для отправки данных каждому из них.
Мониторинг преобразований
Сведения о журналах и метрик, отслеживающих работоспособность и производительность преобразований, см. в статье "Мониторинг и устранение неполадок сбора данных DCR в Azure Monitor ". Это включает выявление ошибок, возникающих в KQL и метриках для отслеживания их продолжительности выполнения.
Затраты на преобразования
Хотя преобразования сами по себе не несут прямых затрат, следующие сценарии могут привести к дополнительным расходам:
- Если преобразование увеличивает размер входящих данных, например путем добавления вычисляемого столбца, вы будете взимать плату за стандартную скорость приема для дополнительных данных.
- Если преобразование уменьшает прием данных более чем на 50%, вы будете взиматься за объем отфильтрованных данных выше 50 %.
Чтобы вычислить плату за обработку данных, полученную из преобразований, используйте следующую формулу:
[ГБ, отфильтрованный по преобразованиям] — ([ГБ данных, принятых конвейером] / 2). В следующей таблице показаны примеры.
| Прием данных конвейером | Данные, удаленные путем преобразования | Прием данных в рабочей области Log Analytics | Плата за обработку данных | Плата за прием |
|---|---|---|---|---|
| 20 ГБ | 12 ГБ | 8 ГБ | 2 ГБ 1 | 8 ГБ |
| 20 ГБ | 8 ГБ | 12 ГБ | 0 ГБ | 12 ГБ |
1 Эта плата исключает плату за прием данных в рабочей области Log Analytics.
Чтобы избежать этой платы, перед применением преобразований следует фильтровать прием данных с помощью альтернативных методов. Таким образом, можно уменьшить объем данных, обработанных преобразованиями, и, следовательно, свести к минимуму дополнительные затраты.
Сведения о ценах на Azure Monitor для приема и хранения данных журнала в Azure Monitor см. в ценах на текущие расходы.
Внимание
Если Azure Sentinel включена для рабочей области Log Analytics, плата за прием не взимается независимо от объема данных фильтров преобразования.
Примеры
В следующих шаблонах Resource Manager показаны примеры контроллеров домена с различными шаблонами. Эти шаблоны можно использовать в качестве отправной точки для создания контроллеров домена с преобразованиями для собственных сценариев.
Одно назначение
Ниже приведен пример DCR для агента Azure Monitor, который отправляет данные в таблицу Syslog . В этом примере преобразование фильтрует данные для записей в error сообщении.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources" : [
{
"type": "Microsoft.Insights/dataCollectionRules",
"name": "singleDestinationDCR",
"apiVersion": "2021-09-01-preview",
"location": "eastus",
"properties": {
"dataSources": {
"syslog": [
{
"name": "sysLogsDataSource",
"streams": [
"Microsoft-Syslog"
],
"facilityNames": [
"auth",
"authpriv",
"cron",
"daemon",
"mark",
"kern",
"mail",
"news",
"syslog",
"user",
"uucp"
],
"logLevels": [
"Debug",
"Critical",
"Emergency"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "centralWorkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Syslog"
],
"transformKql": "source | where message has 'error'",
"destinations": [
"centralWorkspace"
]
}
]
}
}
]
}
Несколько таблиц Azure
Ниже приведен пример DCR для данных из API приема журналов, который отправляет данные как в таблицы, так и SecurityEvent в Syslog таблицы. Для этого DCR требуется отдельный dataFlow для каждого из них и transformKqlOutputStream для каждого из них. В этом примере все входящие данные отправляются Syslog в таблицу, а вредоносные данные также отправляются в таблицу SecurityEvent . Если вы не хотите реплика te вредоносных данных в обеих таблицах, можно добавить where инструкцию в первый запрос, чтобы удалить эти записи.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources" : [
{
"type": "Microsoft.Insights/dataCollectionRules",
"name": "multiDestinationDCR",
"location": "eastus",
"apiVersion": "2021-09-01-preview",
"properties": {
"dataCollectionEndpointId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers//Microsoft.Insights/dataCollectionEndpoints/my-dce",
"streamDeclarations": {
"Custom-MyTableRawData": {
"columns": [
{
"name": "Time",
"type": "datetime"
},
{
"name": "Computer",
"type": "string"
},
{
"name": "AdditionalContext",
"type": "string"
}
]
}
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "clv2ws1"
},
]
},
"dataFlows": [
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | project TimeGenerated = Time, Computer, Message = AdditionalContext",
"outputStream": "Microsoft-Syslog"
},
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | where (AdditionalContext has 'malicious traffic!' | project TimeGenerated = Time, Computer, Subject = AdditionalContext",
"outputStream": "Microsoft-SecurityEvent"
}
]
}
}
]
}
Сочетание таблиц Azure и пользовательских таблиц
Следующий пример — это DCR для данных из API приема журналов, который отправляет данные как в таблицу, так Syslog и в настраиваемую таблицу с данными в другом формате. Для этого DCR требуется отдельный dataFlow для каждого из них и transformKqlOutputStream для каждого из них. При использовании пользовательских таблиц важно убедиться, что схема назначения (настраиваемая таблица) содержит настраиваемые столбцы (практическое руководство по добавлению или удалению настраиваемых столбцов), которые соответствуют схеме отправляемых записей. Например, если запись имеет поле syslogMessage, но целевая настраиваемая таблица имеет только TimeGenerated и RawData, вы получите событие в настраиваемой таблице только с заполненным полем TimeGenerated, а поле RawData будет пустым. Поле SyslogMessage будет удалено, так как схема целевой таблицы не содержит строковое поле с именем SyslogMessage.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources" : [
{
"type": "Microsoft.Insights/dataCollectionRules",
"name": "multiDestinationDCR",
"location": "eastus",
"apiVersion": "2021-09-01-preview",
"properties": {
"dataCollectionEndpointId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers//Microsoft.Insights/dataCollectionEndpoints/my-dce",
"streamDeclarations": {
"Custom-MyTableRawData": {
"columns": [
{
"name": "Time",
"type": "datetime"
},
{
"name": "Computer",
"type": "string"
},
{
"name": "AdditionalContext",
"type": "string"
}
]
}
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "clv2ws1"
},
]
},
"dataFlows": [
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | project TimeGenerated = Time, Computer, SyslogMessage = AdditionalContext",
"outputStream": "Microsoft-Syslog"
},
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | extend jsonContext = parse_json(AdditionalContext) | project TimeGenerated = Time, Computer, AdditionalContext = jsonContext, ExtendedColumn=tostring(jsonContext.CounterName)",
"outputStream": "Custom-MyTable_CL"
}
]
}
}
]
}