📚 课程目录第4章数据收集规则（DCR）基础与配置

4. 数据收集规则（DCR）基础与配置

聊到 Azure Monitor 日志集成，有个东西绕不过——数据收集规则（Data Collection Rule，简称 DCR）。说白了，它就是整个日志管道的“交通指挥员”。你想想看，日志从 VM、容器、应用一路跑到 Log Analytics 工作区，中间谁来决定格式、过滤条件、目标表？就是 DCR。

我刚开始接触 DCR 的时候，总觉得它和以前的诊断设置差不多。后来踩过坑才明白——诊断设置只管 Azure 平台层面的日志，而 DCR 是为混合环境、自定义场景设计的。一个管“平台”，一个管“数据流”。

4.1 DCR 是什么？

数据收集规则是一个 JSON 格式的 Azure 资源。它定义了：

数据源：从哪收（Windows 事件、Syslog、性能计数器、文本日志等）
数据流：怎么处理（转换、过滤、添加上下文）
目标：送到哪（Log Analytics 工作区、Azure Storage、Event Hubs）

每个 DCR 可以和多个数据源关联，也可以被多个机器共同引用。我习惯把 DCR 想象成一个“数据管道模板”——你定义一次，到处复用。

4.2 DCR 的两种使用模式

模式	适用场景	典型工作流
直接关联模式	Azure VM、VMSS、Arc 服务器	创建 DCR → 通过 Azure Policy 或门户直接关联到资源
数据收集端点（DCE）	自定义日志、API 推送、非 Azure 环境	创建 DCE → 创建 DCR 并绑定 DCE → 客户端通过 DCE 端点推送

我记得有个项目，客户想把本地机房的 IIS 日志直接推到 Log Analytics。直接用直接关联模式根本不行——本地机器不在 Azure 资源体系里。后来我启用了数据收集端点，配合 DCR 的自定义日志转换，才把问题解决。嗯，这里有两个概念要分清。

4.3 DCR 的核心结构

我们来看一个典型的 DCR JSON 片段。不用怕，虽然长，但骨架很清晰：

{
  "location": "eastasia",
  "properties": {
    "dataSources": {
      "windowsEventLogs": [
        {
          "name": "myWinEventLog",
          "streams": ["Microsoft-WindowsEvent"],
          "xPathQueries": ["System!*[System[(Level=1 or Level=2 or Level=3)]]"]
        }
      ],
      "performanceCounters": [
        {
          "name": "cpuCounter",
          "streams": ["Microsoft-Perf"],
          "scheduledTransferPeriod": "PT1M",
          "counterSpecifiers": ["\\Processor(_Total)\\% Processor Time"]
        }
      ]
    },
    "destinations": {
      "logAnalytics": [
        {
          "workspaceId": "your-workspace-id",
          "workspaceResourceId": "/subscriptions/.../workspaces/your-la"
        }
      ]
    },
    "dataFlows": [
      {
        "streams": ["Microsoft-WindowsEvent", "Microsoft-Perf"],
        "destinations": ["logAnalytics"],
        "transformKql": "source | where TimeGenerated > ago(1d)"
      }
    ]
  }
}

注意 dataFlows 里的 transformKql 字段。我个人非常喜欢这个设计——你在管道中间就能用 KQL 做过滤、投影、甚至计算字段，不用等数据落库再跑查询。省时省资源。

4.4 配置步骤（实操要点）

确定数据源类型：Windows 事件、Linux Syslog、性能计数器、自定义文本日志、JSON 日志……每种源的 schema 不一样。
创建 DCR：Azure 门户 → Monitor → 数据收集规则 → 创建。或者用 ARM、CLI、PowerShell。
关联目标资源：进入 DCR 的“资源”页面，添加 VM 或 Arc 服务器。也可以用 Azure Policy 批量关联。
验证数据是否到达：等 5-10 分钟，在 Log Analytics 里查 Heartbeat 表，看对应机器有没有打标记。
调试日志管道：如果数据没来，先看 VM 上的 AMA（Azure Monitor Agent） 是否正常运行。再检查 DCR 中 XPath 或者 KQL 过滤是否写得太严。

避坑：我曾经把 Windows 事件日志的 XPath 写错了一个括号，结果系统日志全部被过滤掉了。整整两天没数据。后来才发现是 XPath 查询格式问题。建议先在本地用 PowerShell 测试 Get-WinEvent -FilterXPath，确认能返回预期日志，再复制到 DCR 里。

4.5 DCR 与 AMA 的关系

Azure Monitor Agent（AMA）是新一代代理，DCR 是它的“配置大脑”。两者必须配合使用：

AMA 负责在机器上收集日志和指标
DCR 告诉 AMA 收集什么、怎么收、送到哪
一台机器可以关联多个 DCR，但不能互相冲突

注意：旧版 Log Analytics Agent 不支持 DCR。如果你还在用旧代理，建议尽快迁移到 AMA 加 DCR 的模式。微软已经宣布旧代理会在 2024 年 8 月之后停止主流支持。

4.6 DCR 的安全要点

方面	建议
身份认证	DCR 本身使用 Azure 托管标识，不需要存储密钥
网络隔离	如果启用了数据收集端点（DCE），可以绑定专用链接（Private Link）
数据过滤	在 `transformKql` 中过滤掉敏感字段，避免把密码等写入工作区
RBAC 权限	需要 `Monitoring Contributor` 或 `Contributor` 才能创建/修改 DCR

我见过一个案例，客户把所有 VM 的 EventID 4688（进程创建）全量收集，结果每天产生 2TB 日志。后来在 DCR 里加了过滤条件，只保留特定用户的进程创建事件，日志量降了 90%。所以 过滤不只在查询时做，在管道入口做更省钱。

4.7 一张图看懂 DCR 工作流

核心逻辑：数据源通过 AMA 代理或直接通过 DCE 端点，经过 DCR 定义的转换和过滤后，送达目标存储。DCR 是整个链路的“灵魂”，变更 DCR 即动态调整日志管道路径，无需重启代理。

4.8 小总结

DCR 不是万能的，但它是当前 Azure 日志集成的“标准姿势”。如果你还在用旧代理加诊断设置配各种自定义脚本，我建议早点切换到 DCR 体系。它带来的好处是：

统一管理：一个 DCR 控制多个数据源
动态生效：改 DCR 几分钟内推送到所有关联机器
内置转换：KQL 过滤省去二次处理成本