Примеры правил сбора данных (DCR) в Azure Monitor
В этой статье содержатся примеры правил сбора данных (DCR) для распространенных сценариев сбора данных в Azure Monitor. Эти определения DCR можно изменить в соответствии с требованиями среды и создать DCR с помощью инструкций в разделе "Создание или изменение правила сбора данных". Вы также можете использовать и объединить основные стратегии в этих примерах для создания контроллеров домена для других сценариев.
В этих примерах требуется знание структуры DCR, как описано в разделе "Структура правила сбора данных" в Azure Monitor. Некоторые могут быть настроены с помощью портал Azure без подробных знаний о структуре DCR. Используйте эти примеры, когда необходимо работать с определением DCR для выполнения более сложных конфигураций или автоматизации создания контроллеров домена.
Каждый из этих примеров фокусируется на определенном источнике данных, хотя можно объединить несколько источников данных разных типов в одном DCR. Включите поток данных для каждого из них для отправки данных в соответствующее место назначения. Нет функциональной разницы между объединением нескольких источников данных в одном DCR или создании отдельных контроллеров домена для каждого источника данных. Выбор зависит от ваших требований для управления и мониторинга сбора данных.
Примечание.
В этих примерах приведены в этой статье источник JSON, необходимый для создания DCR. После создания DCR будет иметь дополнительные свойства, как описано в разделе "Структура правила сбора данных" в Azure Monitor.
Контроллеры домена для агента Azure Monitor
Агент Azure Monitor выполняется на виртуальных машинах, масштабируемых наборах виртуальных машин и кластерах Kubernetes. Она поддерживает аналитику виртуальных машин и аналитику контейнеров и поддерживает различные сценарии сбора данных для виртуальных машин, описанных в коллекции данных агента Azure Monitor.
В следующих примерах показаны контроллеры домена для сбора различных типов данных с помощью агента Azure Monitor.
События Windows
Контроллеры домена для событий Windows используют windowsEventLogs источник данных с входящим потоком Microsoft-Event . Схема этого потока известна, поэтому ее не нужно определять в dataSources разделе. События, собираемые, указываются в свойстве xPathQueries . Дополнительные сведения об использовании XPaths см. в статье "Сбор событий Windows с помощью агента Azure Monitor" для фильтрации определенных данных, которые требуется собрать. Чтобы приступить к работе, вы можете использовать инструкции, приведенные в этой статье, чтобы создать DCR с помощью портал Azure, а затем проверить JSON с помощью инструкций по определению DCR.
Вы можете добавить преобразование в dataFlows свойство для вычисляемых столбцов и для дальнейшего фильтрации данных, но следует использовать XPaths для фильтрации данных на агенте как можно больше для повышения эффективности и предотвращения потенциальных расходов на прием.
В следующем примере DCR выполняются следующие действия:
- Собирает события приложения и системы Windows с уровнем ошибок предупреждения, ошибки или критического состояния.
- Отправляет данные в таблицу событий в рабочей области.
- Использует простое преобразование,
sourceкоторое не изменяет входящие данные.
{
"location": "eastus",
"properties": {
"dataSources": {
"windowsEventLogs": [
{
"name": "eventLogsDataSource",
"streams": [
"Microsoft-Event"
],
"xPathQueries": [
"System!*[System[(Level = 1 or Level = 2 or Level = 3)]]",
"Application!*[System[(Level = 1 or Level = 2 or Level = 3)]]"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "centralWorkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Event"
],
"destinations": [
"centralWorkspace"
],
"transformKql": "source",
"outputStream": "Microsoft-Event"
}
]
}
}
события системного журнала;
Контроллеры домена для событий системного журнала используют syslog источник данных с входящим Microsoft-Syslog потоком. Схема этого потока известна, поэтому ее не нужно определять в dataSources разделе. Собранные события указываются в свойствах facilityNames и logLevels свойствах. Дополнительные сведения см. в статье Сбор событий системного журнала с помощью агента Azure Monitor. Чтобы приступить к работе, вы можете использовать инструкции, приведенные в этой статье, чтобы создать DCR с помощью портал Azure, а затем проверить JSON с помощью инструкций по определению DCR.
Вы можете добавить преобразование в dataFlows свойство для дополнительных функциональных возможностей и для дальнейшего фильтрации данных, но следует использовать facilityNames и logLevels для фильтрации как можно больше для повышения эффективности, чтобы избежать потенциальных расходов на прием.
В следующем примере DCR выполняются следующие действия:
- Собирает все события из
cronобъекта. WarningСобирает и получает и более высокие события изsyslogиdaemonобъектов.- Отправляет данные в таблицу Системного журнала в рабочей области.
- Использует простое преобразование,
sourceкоторое не изменяет входящие данные.
{
"location": "eastus",
"properties": {
"dataSources": {
"syslog": [
{
"name": "cronSyslog",
"streams": [
"Microsoft-Syslog"
],
"facilityNames": [
"cron"
],
"logLevels": [
"Debug",
"Info",
"Notice",
"Warning",
"Error",
"Critical",
"Alert",
"Emergency"
]
},
{
"name": "syslogBase",
"streams": [
"Microsoft-Syslog"
],
"facilityNames": [
"daemon",
"syslog"
],
"logLevels": [
"Warning",
"Error",
"Critical",
"Alert",
"Emergency"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "centralWorkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Syslog"
],
"destinations": [
"centralWorkspace"
],
"transformKql": "source",
"outputStream": "Microsoft-Syslog"
}
]
}
}
Счетчики производительности
Контроллеры домена для данных производительности используют performanceCounters источник данных с входящими и Microsoft-Perf потокамиMicrosoft-InsightsMetrics. Microsoft-InsightsMetrics используется для отправки данных в метрики Azure Monitor, а Microsoft-Perf используется для отправки данных в рабочую область Log Analytics. Вы можете включить оба источника данных в DCR, если вы отправляете данные о производительности в оба назначения. Схемы этих потоков известны, поэтому их не нужно определять в dataSources разделе.
Счетчики производительности для сбора указываются в свойстве counterSpecifiers . Дополнительные сведения см. в статье Сбор счетчиков производительности с помощью агента Azure Monitor. Чтобы приступить к работе, вы можете использовать инструкции, приведенные в этой статье, чтобы создать DCR с помощью портал Azure, а затем проверить JSON с помощью инструкций по определению DCR.
Вы можете добавить преобразование в dataFlows свойство для Microsoft-Perf дополнительных функциональных возможностей и для дальнейшего фильтрации данных, но следует выбрать только счетчики, необходимые counterSpecifiers для повышения эффективности, чтобы избежать потенциальных расходов на прием.
В следующем примере DCR выполняются следующие действия:
- Собирает набор счетчиков производительности каждые 60 секунд, а другой набор каждые 30 секунд.
- Отправляет данные в метрики Azure Monitor и рабочую область Log Analytics.
- Использует простое преобразование,
sourceкоторое не изменяет входящие данные.
{
"location": "eastus",
"properties": {
"dataSources": {
"performanceCounters": [
{
"name": "perfCounterDataSource60",
"streams": [
"Microsoft-Perf",
"Microsoft-InsightsMetrics"
],
"samplingFrequencyInSeconds": 60,
"counterSpecifiers": [
"\\Processor(_Total)\\% Processor Time",
"\\Memory\\Committed Bytes",
"\\LogicalDisk(_Total)\\Free Megabytes",
"\\PhysicalDisk(_Total)\\Avg. Disk Queue Length"
]
},
{
"name": "perfCounterDataSource30",
"streams": [
"Microsoft-Perf"
],
"samplingFrequencyInSeconds": 30,
"counterSpecifiers": [
"\\Process(_Total)\\Thread Count"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "centralWorkspace"
}
],
"azureMonitorMetrics":
{
"name": "azureMonitorMetrics-default"
}
},
"dataFlows": [
{
"streams": [
"Microsoft-Perf"
],
"destinations": [
"centralWorkspace"
],
"transformKql": "source",
"outputStream": "Microsoft-Perf"
},
{
"streams": [
"Microsoft-Perf"
],
"destinations": [
"azureMonitorMetrics-default"
],
"outputStream": "Microsoft-InsightsMetrics"
}
]
}
}
Текстовые журналы
Контроллеры домена для текстовых журналов содержат logfiles источник данных, который содержит сведения о файлах журнала, которые должны собираться агентом. Сюда входит имя потока, который должен быть определен в streamDeclarations столбцах входящих данных. В настоящее время это список наборов, как описано в разделе "Сбор журналов из текстового файла с помощью агента Azure Monitor".
Добавьте преобразование в dataFlows свойство для фильтрации записей, которые вы не хотите собирать и отформатировать данные для сопоставления схемы целевой таблицы. Распространенный сценарий заключается в анализе файла журнала с разделителями в нескольких столбцах, как описано в файлах журналов с разделителями.
В следующем примере DCR выполняются следующие действия:
- Собирает записи из всех файлов с расширением
.txtвc:\logsпапке компьютера агента. - Использует преобразование для разделения входящих данных на столбцы на основе разделителя-запятой (
,). Это преобразование зависит от формата файла журнала и должно быть настроено для файлов журнала с другими форматами. - Отправляет собранные журналы в настраиваемую таблицу
MyTable_CL. Эта таблица уже должна существовать и иметь выходные данные столбцов путем преобразования. - Собирает и собирает текстовый
FilePathжурнал, как описано в разделе "Входящий поток".ComputerЭти столбцы также должны существовать в целевой таблице.
{
"location": "eastus",
"properties": {
"dataCollectionEndpointId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.Insights/dataCollectionEndpoints/my-dce",
"streamDeclarations": {
"Custom-MyLogFileFormat": {
"columns": [
{
"name": "TimeGenerated",
"type": "datetime"
},
{
"name": "RawData",
"type": "string"
},
{
"name": "FilePath",
"type": "string"
},
{
"name": "Computer",
"type": "string"
}
]
}
},
"dataSources": {
"logFiles": [
{
"streams": [
"Custom-MyLogFileFormat"
],
"filePatterns": [
"C:\\logs\\*.txt"
],
"format": "text",
"settings": {
"text": {
"recordStartTimestampFormat": "ISO 8601"
}
},
"name": "myLogFileFormat-Windows"
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "MyDestination"
}
]
},
"dataFlows": [
{
"streams": [
"Custom-MyLogFileFormat"
],
"destinations": [
"MyDestination"
],
"transformKql": "source | project d = split(RawData,\",\") | project TimeGenerated=todatetime(d[0]), Code=toint(d[1]), Severity=tostring(d[2]), Module=tostring(d[3]), Message=tostring(d[4])",
"outputStream": "Custom-MyTable_CL"
}
]
}
}
Журналы Json
В журналах DCR для json есть logfiles источник данных, который содержит сведения о файлах журнала, которые должны собираться агентом. Сюда входит имя потока, который должен быть определен в streamDeclarations столбцах входящих данных. Дополнительные сведения см. в статье Сбор журналов из JSON-файла с помощью агента Azure Monitor.
Добавьте преобразование в dataFlows свойство для фильтрации записей, которые вы не хотите собирать и отформатировать данные для сопоставления схемы целевой таблицы.
В следующем примере DCR выполняются следующие действия:
- Собирает записи из всех файлов с расширением
.jsonвc:\logsпапке компьютера агента. Файл должен быть отформатирован в формате JSON и содержать столбцы, перечисленные в объявлении потока. - Отправляет собранные журналы в настраиваемую таблицу
MyTable_CL. Эта таблица уже должна существовать и иметь те же столбцы, что и входящий поток. Если столбцы не совпадают, необходимо изменить преобразование вtransformKqlсвойстве, чтобы отформатировать данные для целевой таблицы.
{
"location": "eastus",
"properties": {
"dataCollectionEndpointId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.Insights/dataCollectionEndpoints/my-dce",
"streamDeclarations": {
"Custom-Json-stream": {
"columns": [
{
"name": "TimeGenerated",
"type": "datetime"
},
{
"name": "FilePath",
"type": "string"
},
{
"name": "Code",
"type": "int"
},
{
"name": "Module",
"type": "string"
},
{
"name": "Message",
"type": "string"
}
]
}
},
"dataSources": {
"logFiles": [
{
"streams": [
"Custom-Json-stream"
],
"filePatterns": [
"C:\\logs\\*.json"
],
"format": "json",
"name": "MyJsonFile"
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "MyDestination"
}
]
},
"dataFlows": [
{
"streams": [
"Custom-Json-stream"
],
"destinations": [
"MyDestination"
],
"transformKql": "source",
"outputStream": "Custom-MyTable_CL"
}
]
}
}
Отправка данных в Центры событий или хранилище
Контроллеры домена, отправляющие данные в центры событий или учетные записи хранения, используют те же источники данных, что и другие контроллеры домена, которые собирают данные с помощью агента Azure Monitor (AMA), но имеют одно или несколько следующих назначений. Дополнительные сведения см. в статье "Отправка данных в Центры событий" и хранилища (предварительная версия ).
eventHubsDirectstorageBlobsDirectstorageTablesDirect
Примечание.
Контроллеры домена, отправляющие данные в центры событий или учетные записи хранения, должны иметь "kind": "AgentDirectToStore"
В следующем примере DCR выполняются следующие действия:
- Собирает счетчики производительности и события Windows с компьютеров Windows с агентом Azure Monitor (AMA).
- Отправляет данные в концентратор событий, хранилище BLOB-объектов и хранилище таблиц.
{
"location": "eastus",
"kind": "AgentDirectToStore",
"properties": {
"dataSources": {
"performanceCounters": [
{
"streams": [
"Microsoft-Perf"
],
"samplingFrequencyInSeconds": 10,
"counterSpecifiers": [
"\\Process(_Total)\\Working Set - Private",
"\\Memory\\% Committed Bytes In Use",
"\\LogicalDisk(_Total)\\% Free Space",
"\\Network Interface(*)\\Bytes Total/sec"
],
"name": "perfCounterDataSource"
}
],
"windowsEventLogs": [
{
"streams": [
"Microsoft-Event"
],
"xPathQueries": [
"Application!*[System[(Level=2)]]",
"System!*[System[(Level=2)]]"
],
"name": "eventLogsDataSource"
}
]
},
"destinations": {
"eventHubsDirect": [
{
"eventHubResourceId": "/subscriptions/71b36fb6-4fe4-4664-9a7b-245dc62f2930/resourceGroups/my-resource-group/providers/Microsoft.EventHub/namespaces/my-eventhub-namespace/eventhubs/my-eventhub",
"name": "myEh"
}
],
"storageBlobsDirect": [
{
"storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
"containerName": "myperfblob",
"name": "PerfBlob"
},
{
"storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
"containerName": "myeventblob",
"name": "EventBlob"
}
],
"storageTablesDirect": [
{
"storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
"containerName": "myperftable",
"name": "PerfTable"
},
{
"storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
"containerName": "mymyeventtable",
"name": "EventTable"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Perf"
],
"destinations": [
"myEh",
"PerfBlob",
"PerfTable"
]
},
{
"streams": [
"Microsoft-Event"
],
"destinations": [
"myEh",
"EventBlob",
"EventTable"
]
},
]
}
}
API приема журналов
Контроллеры домена для API приема журналов должны определять схему входящего потока в streamDeclarations разделе определения DCR. Входящие данные должны быть отформатированы в формате JSON со схемой, соответствующей столбцам в этом определении. Преобразование не требуется, если эта схема соответствует схеме целевой таблицы. Если схемы не совпадают, необходимо добавить преобразование в dataFlows свойство для форматирования данных. Дополнительные сведения см . в API приема журналов в Azure Monitor .
В приведенном ниже примере DCR приведены следующие сведения:
- Отправляет данные в таблицу, которая
MyTable_CLназываетсяmy-workspaceрабочей областью. Перед установкой этого DCR необходимо создать таблицу со следующими столбцами:- TimeGenerated
- Компьютер
- AdditionalContext
- ExtendedColumn (определенный в преобразовании)
- Применяет преобразование к входящим данным для форматирования данных целевой таблицы.
Внимание
Этот пример не включает dataCollectionEndpointId свойство, так как это создается автоматически при создании DCR. Необходимо значение этого свойства, так как это URL-адрес, в который приложение будет отправлять данные. Для создания этого свойства необходимо создать kind:Direct DCR. Дополнительные сведения см. в разделе "Свойства ".
{
"location": "eastus",
"kind": "Direct",
"properties": {
"streamDeclarations": {
"Custom-MyTable": {
"columns": [
{
"name": "Time",
"type": "datetime"
},
{
"name": "Computer",
"type": "string"
},
{
"name": "AdditionalContext",
"type": "string"
}
]
}
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/cefingestion/providers/microsoft.operationalinsights/workspaces/my-workspace",
"name": "LogAnalyticsDest"
}
]
},
"dataFlows": [
{
"streams": [
"Custom-MyTable"
],
"destinations": [
"LogAnalyticsDest"
],
"transformKql": "source | extend jsonContext = parse_json(AdditionalContext) | project TimeGenerated = Time, Computer, AdditionalContext = jsonContext, ExtendedColumn=tostring(jsonContext.CounterName)",
"outputStream": "Custom-MyTable_CL"
}
]
}
}
DCR преобразования рабочей области
Контроллеры домена преобразования рабочей области имеют пустой datasources раздел, так как преобразования применяются к любым данным, отправленным в поддерживаемые таблицы в рабочей области. Он должен содержать одну и только запись workspaceResourceId dataFlows для каждой таблицы с преобразованием. Он также должен иметь "kind": "WorkspaceTransforms".
В приведенном ниже примере DCR приведены следующие сведения:
- Преобразование для
LAQueryLogsтаблицы, которая фильтрует запросы самой таблицы и добавляет столбец с именем рабочей области. - Преобразование для
Eventтаблицы, которая фильтруетParameterXmlсобытия сведений и удаляет столбец. Это будет применяться только к данным, поступающим из устаревшего агента Log Analytics, а не агента Azure Monitor, как описано в DCR преобразования рабочей области.
{
"kind": "WorkspaceTransforms",
"location": "eastus",
"properties": {
"dataSources": {},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "clv2ws1"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Table-LAQueryLogs"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | where QueryText !contains 'LAQueryLogs' | extend Context = parse_json(RequestContext) | extend Workspace_CF = tostring(Context['workspaces'][0]) | project-away RequestContext, Context"
},
{
"streams": [
"Microsoft-Table-Event"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | where EventLevelName in ('Error', 'Critical', 'Warning') | project-away ParameterXml"
}
]
}
}
Отправка данных в несколько таблиц
Существует несколько причин, по которым может потребоваться отправить данные из одного источника данных в несколько таблиц в одной рабочей области Log Analytics, включая следующие:
- Экономия затрат на прием путем отправки записей, используемых для случайного устранения неполадок в базовой таблице журналов.
- Отправка записей или столбцов с конфиденциальными данными в таблицу с разными разрешениями или параметрами хранения.
Чтобы отправить данные из одного источника данных в несколько таблиц, создайте несколько потоков данных в DCR с уникальным запросом преобразования и выходной таблицей, как показано на следующей схеме.
Внимание
В настоящее время таблицы в DCR должны находиться в той же рабочей области Log Analytics. Чтобы отправить в несколько рабочих областей из одного источника данных, используйте несколько контроллеров домена и настройте приложение для отправки данных каждому из них.
В следующем примере записей фильтров, отправленных в таблицу событий агентом Azure Monitor. В таблицу событий отправляются только предупреждения и события ошибок. Другие события отправляются в копию таблицы событий с именем Event_CL, настроенной для базовых журналов.
Примечание.
Для этого примера требуется копия таблицы событий, созданной в той же рабочей области с именем Event_CL.
{
"location": "eastus",
"properties": {
"dataSources": {
"windowsEventLogs": [
{
"name": "eventLogsDataSource",
"streams": [
"Microsoft-Event"
],
"xPathQueries": [
"System!*[System[(Level = 1 or Level = 2 or Level = 3)]]",
"Application!*[System[(Level = 1 or Level = 2 or Level = 3)]]"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "MyDestination"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Event"
],
"destinations": [
"MyDestination"
],
"transformKql": "source | where EventLevelName in ('Error', 'Warning')",
"outputStream": "Microsoft-Event"
},
{
"streams": [
"Microsoft-Event"
],
"destinations": [
"MyDestination"
],
"transformKql": "source | where EventLevelName !in ('Error', 'Warning')",
"outputStream": "Custom-Event_CL"
}
]
}
}