Azure Monitor 中数据收集规则 (DCR) 的结构

本文介绍 DCR 的 JSON 结构，适用于需要直接使用 DCR 定义的情况。

• 有关使用本文中所述的 JSON 的详细信息，请参阅 “创建和编辑 DCR”。
• 有关不同方案的示例，请参阅 Azure Monitor0>Sample DCR。

属性

下表描述了 DCR 顶层的属性。

¹ 此属性并不是为 2024 年 3 月 31 日之前创建的 DCR 创建的。 在此日期之前创建的 DCR 需要指定 数据收集终结点 (DCE) 和 dataCollectionEndpointId 属性。 如果要使用这些嵌入式 DCE，则必须创建新的 DCR。

种类

DCR 中的 kind 属性指定了 DCR 用于的集合的类型。 每种 DCR 具有不同的结构和属性。

下表列出了不同类型的 DCR 及其详细信息。

DCR 数据流概述

DCR 的基本流如下图所示。 后续部分将介绍其中的每个组件。

整个数据流通过 DCR 遵循以下顺序： 数据源 → 输入流 → 数据流 → 目标。 并非所有 DCR 类型都使用每个元素。 下表显示了应用于每个 DCR 类型的元素。

使用多阶段转换时，该 transformations 部分会添加在数据源阶段（客户端）或数据流阶段（引入端）应用的处理器管道，具体取决于所引用的命名转换的位置。

输入流

DCR 的输入流部分定义它收集的传入数据。 根据数据收集方案，可以采用两种类型的传入流。 大多数数据收集方案都使用其中一个输入流，而某些方案同时使用这两种方案。

从日志引入 API 发送的数据使用 streamDeclaration 传入数据的架构，因为 API 发送自定义数据。

来自Azure Monitor代理（AMA）的文本日志是一个数据收集示例，需要 dataSources 和 streamDeclarations。 数据源包括用于连接到数据源的配置，并 streamDeclarations 定义传入数据的架构。

数据源

数据源是监视数据的唯一源，每个数据源都有其自己的格式和公开数据的方法。 每个数据源类型都有一组唯一的参数，必须为每个数据源配置这些参数。 数据源通常返回已知的数据类型，因此无需在 DCR 中定义架构。

例如，使用 Azure Monitor 代理（AMA）从 VM 收集的事件和性能数据使用数据源，例如 windowsEventLogs 和 performanceCounters。 为要收集的事件和性能计数器指定条件，但不需要定义数据本身的结构，因为此架构以潜在的传入数据而闻名。

常见数据源参数

所有数据源类型都共享下面的常见参数。

有效数据源类型

下表列出了当前可用的数据源类型。

¹ 这些数据源同时使用数据源和流声明，因为它们收集的数据架构可能有所不同。 数据源中使用的流应该是流声明中定义的自定义流。

流声明

声明发送到Log Analytics工作区的不同类型的数据。 每个流都是一个对象，其键表示流名称，该名称必须以 Custom- 开头。 该流包含你发送的 JSON 数据中包含的顶级属性的完整列表。 发送到终结点的数据的形状不需要与目标表的形状匹配。 相反，应用在输入数据上的转换的结果需要与目标的形状相匹配。

数据类型

将以下数据类型分配给属性：

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

该 guid 类型在流声明中不可用。 如果源数据包含 GUID 值，请将这些列声明为 string。 表 API 支持该 guid 类型，但值实际上以字符串的形式存储和查询。 有关详细信息，请参阅 Azure Monitor Logs 中的 Column 数据类型。

目的地

在节中 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 对象

每个处理器都是描述特定数据转换操作的声明性构建基块。

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

处理器类型

下表显示了客户端和引入端可用的处理器。

• 客户端标头处理器用于分配给数据源的客户端转换。 由于已知传入数据的架构，因此不需要配置。
• 引入端标头处理器用于向数据流分配的引入端转换。

标头处理器

标头处理器接收原始数据，并将其转换为已知的架构化表格格式。 标头处理器必须是任何转换中的第一个处理器。

头。Syslog

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，但指定 CEF 密钥名称除外 path 。

输出架构：与输入相同，以及每个提取字段的新列。

骨料。基本

使用具有分组维度的聚合运算符汇总记录。

{
    "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 现有 DCR 具有此处理器的直接迁移路径。

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

输出架构：由 KQL 定义，无法静态验证。

相关内容

• 数据收集规则以及创建这些规则的方法的概述
• 在 Azure Monitor 中创建和编辑数据收集规则
• Azure MonitorMulti-stage 转换>
• 在 Azure Monitor 中创建转换
• 从 VM 客户端收集数据