Примеры правил сбора данных (DCR) в Azure Monitor

Эта статья содержит примеры правил сбора данных (DCR) для распространенных сценариев сбора данных в Azure Monitor. Вы можете изменять эти определения DCR в соответствии с вашими требованиями и создавать DCR, следуя рекомендациям в разделе Создать или изменить правило сбора данных. Вы также можете использовать и комбинировать базовые стратегии в этих примерах для создания DCR для других сценариев.

Эти примеры требуют знания структуры DCR, как описано в структуре правила сбора данных в Azure Monitor. Несколько объектов могут быть настроены с использованием портала Azure без необходимости детального знания структуры DCR. Используйте эти примеры в качестве отправной точки, если вы хотите управлять DCR с помощью методов вне портала Azure, таких как ARM, CLI и PowerShell. Возможно, вам потребуется использовать эти методы для редактирования существующих DCR, чтобы реализовать расширенные функции, такие как преобразования.

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

Соберите данные клиента виртуальной машины

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

События Windows

DCR для событий Windows используют источник данных windowsEventLogs с входящим потоком Microsoft-Event. Схема этого потока известна, поэтому её не нужно определять в разделе dataSources. События, которые нужно собрать, указаны в свойстве xPathQueries. См. Сбор событий Windows с помощью агента мониторинга Azure для получения дополнительных сведений об использовании XPath для фильтрации конкретных данных, которые вы хотите собрать. Чтобы начать, вы можете воспользоваться рекомендациями в этой статье, чтобы создать DCR, используя портал Azure, а затем просмотреть JSON, следуя указаниям в разделе DCR definition.

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

Пример следующего DCR выполняет следующие действия:

• Сбор событий приложений и системных событий Windows с уровнями ошибок Предупреждение, Ошибка или Критическая.
• Отправляет данные в таблицу Event в рабочем пространстве.
• Использует простую трансформацию 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 definition.

Вы можете добавить преобразование к свойству dataFlows для дополнительных возможностей и дополнительной фильтрации данных, но вы должны максимально использовать facilityNames и logLevels для фильтрации, чтобы повысить эффективность и избежать потенциальных расходов на прием.

Пример следующего DCR выполняет следующие действия:

• Собирает все события из cron объекта.
• Собирает Warning и более высокие события из объектов syslog и daemon.
• Отправляет данные в таблицу Syslog в рабочей области.
• Использует простую трансформацию 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"
        }
      ]
    }
  }

Счетчики производительности

DCR для данных производительности используют источник данных performanceCounters вместе с входящими потоками Microsoft-InsightsMetrics и Microsoft-Perf. Microsoft-InsightsMetrics используется для отправки данных в метрики Azure Monitor, а Microsoft-Perf используется для отправки данных в рабочую область Log Analytics. Вы можете включить оба источника данных в DCR, если отправляете данные о производительности по обоим направлениям. Схемы этих потоков известны, поэтому их не нужно определять в dataSources разделе.

Счетчики производительности, которые необходимо собрать, указаны в свойстве counterSpecifiers. См. Сбор производственных счетчиков с агентом Azure Monitor для получения подробной информации. Чтобы начать, вы можете воспользоваться рекомендациями в этой статье, чтобы создать DCR, используя портал Azure, а затем просмотреть JSON, следуя указаниям в разделе DCR definition.

Вы можете добавить преобразование к свойству dataFlows для Microsoft-Perf для получения дополнительных возможностей и для дальнейшей фильтрации данных, но следует выбрать только те счетчики, которые действительно необходимы в counterSpecifiers для повышения эффективности, чтобы избежать потенциальных затрат на обработку данных.

Пример следующего DCR выполняет следующие действия:

• Собирает набор счетчиков производительности каждые 60 секунд и другой набор каждые 30 секунд.
• Передает данные в раздел Azure Monitor Metrics и рабочую область 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"
        }
      ]
    }
}

Текстовые журналы

DCR для текстовых журналов имеют источник данных 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"
            }
        ]
    }
}

API загрузки журналов

DCR для API загрузки журналов должен определить схему входящего потока в разделе streamDeclarations определения DCR. Входящие данные должны быть отформатированы в формате JSON с схемой, соответствующей столбцам в этом определении. Трансформация не требуется, если эта схема соответствует схеме целевой таблицы. Если схемы не совпадают, необходимо добавить преобразование для свойства dataFlows для форматирования данных. Ознакомьтесь с API для загрузки логов в Azure Monitor для получения более подробной информации.

Пример DCR ниже содержит следующие детали:

• Отправляет данные в таблицу с именем MyTable_CL в рабочей области с именем my-workspace. Перед установкой этого DCR вам нужно создать таблицу со следующими столбцами:
  • Время генерации
  • Компьютер
  • ДополнительныйКонтекст
  • ExtendedColumn (определено в преобразовании)
• Применяет преобразование к входящим данным для форматирования данных целевой таблицы.

{
    "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/my-resource-group/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 трансформация рабочей области

DCRs преобразования рабочего пространства имеют пустую секцию 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, для каждого из которых определите уникальный запрос преобразования и таблицу вывода, как показано на следующей диаграмме.

Следующий пример фильтрует записи, отправленные в таблицу событий агентом Azure Monitor. Только предупреждения и ошибки отправляются в таблицу событий. Другие события отправляются в копию таблицы событий под названием 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"
            }
        ]
    }
}

Дальнейшие действия

• Получите подробную информацию о различных свойствах в DCR
• Просмотрите различные методы создания DCR