📚 课程目录第4章诊断设置入门

4、诊断设置入门：为Azure资源启用诊断设置

聊到Azure Monitor的审计日志存储，有个环节绕不开——诊断设置。说白了，它就是Azure资源和Log Analytics工作区、存储账户之间的“管道”。没有这根管子，日志数据根本流不过去。

我刚开始接触这块时也犯过迷糊：明明启用了诊断设置，怎么日志就是收不到？后来才发现，目标选错了，或者流类型没勾全。嗯，今天咱们就把这事彻底捋清楚。

4.1 诊断设置是什么？

诊断设置是Azure Resource Manager层面的一项配置。它定义了：

从哪个资源收集日志（比如一个VM、一个AKS集群、一个Key Vault）
收集哪些日志类别（比如审核日志、指标、性能计数器）
把日志送到哪里（三大目标：Log Analytics工作区、存储账户、事件中心）

每个资源最多可以配置5个诊断设置。我通常会为关键资源配两个：一个送Log Analytics用于实时分析，另一个送存储账户做长期合规归档。

小提示：诊断设置是“增量生效”的。配置完成后，新产生的日志会立刻按规则路由，但之前的历史日志不会被回溯发送。如果你需要补历史数据，得额外走导出或API。

4.2 目标选项：送到哪里去？

Azure给了三种目标，各有各的适用场景。我总结了一张表，你一看就明白：

目标类型	适用场景	优势	成本
Log Analytics 工作区	实时查询、告警、可视化、工作簿	支持KQL查询，与Azure Monitor深度集成	按数据量收费（GB/月）
Azure 存储账户	长期归档、合规保留、低成本存储	存储成本低，可配合保留策略自动删除	存储费用 + 事务费用
事件中心	流式处理、对接第三方SIEM（如Splunk）	低延迟、高吞吐、支持实时管道	事件中心吞吐单元费用

我个人习惯：生产环境至少同时配Log Analytics和存储账户。Log Analytics保证我能随时查，存储账户保证能扛住合规审计。如果预算紧张，也可以只配存储账户，然后用Azure Data Explorer做查询——不过那样延迟会稍高。

注意：存储账户目标必须和资源在同一个区域吗？不强制，但跨区域会产生额外的出站流量费用。我曾经有一个客户把华南的VM日志发到华东的存储账户，月底看到账单直接懵了。建议：存储账户和资源放在同一区域，除非有明确的异地容灾需求。

4.3 配置步骤：一步一步来

配置诊断设置可以通过门户、CLI、PowerShell或者ARM模板。我演示一下最常见的门户操作，因为大部分初学者都是从这里起步的。

4.3.1 在Azure门户中配置

进入目标资源（比如一个虚拟机）。
左侧菜单找到「监控」→「诊断设置」。
点击「+ 添加诊断设置」。
给设置起个名字（比如“audit-log-to-la-and-storage”）。
勾选你要收集的日志类别：
- 类别组：audit、security、performance、admin 等
- 如果资源支持，会有「allLogs」选项——我建议直接勾上，免得漏东西。
在「目标细节」区域：
- 勾选「发送到Log Analytics工作区」，选择已有的工作区。
- 勾选「存档到存储账户」，选择存储账户并设置保留天数（比如365天）。
- 如果需要实时流，勾选「流式发送到事件中心」。
点击「保存」。

保存后几秒钟，新日志就会开始流向目标。你可以去Log Analytics里用KQL验证：

// 检查AuditLogs是否到达
AuditLogs
| where TimeGenerated > ago(10m)
| count

如果返回非零计数，说明配置生效。如果一直是0，先去存储账户里看有没有容器生成——有些资源产生日志的速度很慢，需要等几分钟。

4.3.2 用Azure CLI配置（推荐自动化场景）

我更喜欢用CLI，尤其是在做批量部署时。下面是一个完整示例：

# 设置变量
resourceId="/subscriptions/<订阅ID>/resourceGroups/<资源组>/providers/Microsoft.Compute/virtualMachines/<VM名>"
workspaceId="/subscriptions/<订阅ID>/resourceGroups/<资源组>/providers/Microsoft.OperationalInsights/workspaces/<工作区名>"
storageAccountId="/subscriptions/<订阅ID>/resourceGroups/<资源组>/providers/Microsoft.Storage/storageAccounts/<存储账户名>"

# 创建诊断设置
az monitor diagnostic-settings create \
  --resource $resourceId \
  --name "vm-diag-to-la-and-storage" \
  --workspace $workspaceId \
  --storage-account $storageAccountId \
  --logs '[
    {"category": "Administrative", "enabled": true, "retentionPolicy": {"enabled": true, "days": 365}},
    {"category": "Security", "enabled": true, "retentionPolicy": {"enabled": true, "days": 365}}
  ]' \
  --metrics '[{"category": "AllMetrics", "enabled": true, "retentionPolicy": {"enabled": true, "days": 365}}]'

注意：--logs参数里，每个类别都要显式写retentionPolicy。如果目标不是存储账户而是纯Log Analytics，保留策略可以设成"enabled": false。

  关键点：诊断设置一旦创建，它会持续运行直到被删除。我见过有人不小心把诊断设置指向了错误的存储账户，结果合规日志全写错了地方。所以配置完成后，建议立刻去目标端检查几分钟内是否有数据写入。

4.4 诊断设置的核心逻辑流程图

下面这张图展示了诊断设置在整个审计日志流中的位置。通常我把它画给团队新人看，能快速建立全局认知。

从图上可以清楚看到：诊断设置就像个“分流器”，一份日志可以同时流向三个目标，互不干扰。你想想看，这种设计多灵活——实时查询、长期存储、流式传输，一条管道全搞定。

4.5 几个常见的坑

配置本身不复杂，但我在项目中遇到过好几个因为小细节翻车的案例：

漏勾了日志类别：默认只勾了“指标”，忘了勾“日志”，结果审计日志一条也没有。诊断设置建好后，务必在Log Analytics里跑个count验证。
保留天数设得太短：有些合规要求保留7年，你只设了30天，到时候被审计问住就尴尬了。我建议先跟法务/合规对齐需求再设。
存储账户没开层级命名空间：如果你要用Azure Data Lake Storage Gen2，得确保存储账户开启了层级命名空间。否则诊断日志写入时会报错。
跨租户发送日志：诊断设置不支持直接跨租户发送Log Analytics。有一次我想把订阅A的日志送到订阅B的工作区，发现门户里根本选不了——得用Azure Lighthouse或者先导出再导入。

曾经有个客户把所有诊断设置都指向了同一个Log Analytics工作区，但那个工作区所在区域是“美国东部”。他们的资源全在“西欧”，结果每秒的跨区域数据传输费用比日志存储本身还贵。后来我帮他们把工作区迁到了西欧，成本直接降了60%。记住：目标工作区应和资源尽量同区域。

4.6 小结

诊断设置是Azure Monitor审计管道的第一道闸门。选对目标、配好类别、设好保留、验证数据——这几步做到位，后面的审计日志存储就稳了。理论上你可以在几分钟内搞定一个资源的配置，但要把最佳实践落地，还是得多花点心思在上面。