第3章 诊断设置：把 Azure 资源日志送进 Log Analytics
说实话，很多刚接触 Azure Monitor 的朋友，第一步就卡在“日志到底怎么进去？”这个问题上。
我记得自己第一次配诊断设置时，愣是对着门户点了半天，结果发现日志根本没过来。原因特别简单——我忘了勾选“发送到 Log Analytics”。嗯，这种低级错误犯一次就够了。
这一章，咱们就把诊断设置这回事彻底捋清楚。说白了，它就是 Azure 资源跟 Log Analytics 工作区之间的一根“数据管道”。没有这根管子，你啥日志都别想查。
3.1 诊断设置是什么？
诊断设置（Diagnostic Settings）是 Azure 平台内置的一个配置机制。它的作用就一个：把某个 Azure 资源产生的平台日志和指标，转发到你指定的目标位置。目标位置可以是 Log Analytics 工作区、存储账户、事件中心，或者 Azure 合作伙伴解决方案。
我在项目里见过不少人，试图用代理（Agent）去采集 Azure 平台日志——那完全是绕弯子。平台日志，比如 Azure 活动日志、资源日志、指标，根本不需要代理，诊断设置就是最正的路。
核心原则：诊断设置只处理“平台级”数据，不处理“来宾 OS 级”数据。虚拟机内部的应用程序日志、系统日志，得靠 Log Analytics 代理或 Azure Monitor Agent 来搞定。别混了。
3.2 支持诊断设置的资源类型
不是所有 Azure 资源都支持诊断设置。我整理了一张常用清单，你在项目里大概率会遇到这些：
| 资源类型 | 是否支持 | 常见日志类别举例 |
|---|---|---|
| Azure SQL 数据库 | 是 | QueryStoreRuntimeStatistics, Errors |
| Azure Key Vault | 是 | AuditEvent, VaultAccess |
| Azure 负载均衡器 | 是 | LoadBalancerAlertEvent, ProbeHealthStatus |
| Azure 应用程序网关 | 是 | AccessLog, PerformanceLog, FirewallLog |
| Azure Functions | 是 | FunctionAppLogs, AppMetrics |
| Azure Kubernetes Service (AKS) | 是 | kube-apiserver, kube-controller-manager |
| Azure 存储账户 | 是 | StorageRead, StorageWrite, StorageDelete |
| 经典虚拟机（来宾级别） | 否（需代理） | — |
检查你的资源是否支持，最快的方法是：在 Azure 门户打开资源，左侧菜单里找“诊断设置”或“Monitoring → Diagnostic settings”。如果有这个菜单项，说明可以配。
3.3 创建诊断设置：两种方式
我通常用两种方式创建诊断设置，看场景选：
3.3.1 Azure 门户（傻瓜式）
适合少量资源、临时调试。步骤很简单：
- 打开目标资源，找到“诊断设置”
- 点击“+ 添加诊断设置”
- 输入名称，比如 “SendToLAW-Prod”
- 勾选你要发送的日志类别和指标
- 在“目标详细信息”里选择“发送到 Log Analytics 工作区”
- 选择你的工作区（注意：工作区必须跟资源在同一个 Azure AD 租户）
- 保存
小建议：命名时最好带上环境标识，比如 “PROD-SQL-MetricsToLAW”。我吃过亏，因为随便写了“test2”，一个月后谁也不记得那是啥。
3.3.2 ARM 模板 / Terraform（工程化）
生产环境我坚决不用手动配，太容易漏。用代码定义诊断设置，可重复、可审计。下面是一个标准的 ARM 模板片段：
{
"type": "Microsoft.Insights/diagnosticSettings",
"apiVersion": "2021-05-01-preview",
"name": "SendToLAW",
"properties": {
"workspaceId": "[parameters('workspaceResourceId')]",
"logs": [
{
"category": "AuditEvent",
"enabled": true,
"retentionPolicy": {
"enabled": false,
"days": 0
}
}
],
"metrics": [
{
"category": "AllMetrics",
"enabled": true,
"retentionPolicy": {
"enabled": false,
"days": 0
}
}
]
}
}你看，这里面有个关键点：retentionPolicy 我都设置成 false。为什么？因为日志到了 Log Analytics 工作区之后，保留策略统一在工作区层面管理。如果你在诊断设置里又设了保留天数，两个策略会打架，最后谁也说不清。
注意：诊断设置中如果设置 retentionPolicy.enabled = true 且 days > 0，Azure 会在日志发送到目标之前先按这个天数截断。我碰到过一次诡异情况：用户说工作区里看不到历史数据，查了半天发现诊断设置里 retentionDays=30，而工作区保留是365天，结果第31天的数据直接被平台丢弃了。
3.4 诊断设置的工作原理
你可能好奇：数据从资源到 Log Analytics 到底经历了什么？我画了一张图来解释这整个流程。
你看这个流程：资源产生日志 → 诊断设置按你选的类别过滤 → 路由到 Log Analytics（或其他目标）。整个过程是实时的，Azure 内部走的是平台专属通道，不占用资源本身的网络带宽。
3.5 常见踩坑点
我这些年修过的诊断设置相关问题，总结下来就这几类：
- 日志延迟：诊断设置的日志延迟通常在 5-15 分钟。如果你发现实时性要求高的场景（比如入侵检测），可以考虑用事件中心配合流分析。
- 配额限制：每个 Azure 资源最多只能创建 5 个诊断设置。我以前遇到过一口气配了 6 个，结果第 6 个直接报错。合理规划，尽量复用同一个设置发送多个目标。
- 跨租户限制：诊断设置的目标（Log Analytics 工作区）必须与资源在同一个 Azure AD 租户内。不能把 A 租户的日志发到 B 租户的工作区。跨租户场景需要用事件中心中转。
- 删除诊断设置：当你删除一个诊断设置后，数据会在几分钟内停止流入目标。但是已经发送的数据不会丢失。我曾经在排障时删除了诊断设置重新配，结果把问题日志中断了 10 分钟，后来才意识到应该先加一个新设置再删旧的，这样能保证连续性。
经验之谈：如果你在排查“为什么日志没进工作区”，最有效的办法是先查 AzureActivity 表里有没有对应诊断设置的创建操作。如果创建成功，但日志没来，可能是资源本身没有产生对应的日志类别。比如 Azure SQL 的 QueryStoreRuntimeStatistics，只有开启了查询存储才会有数据。
3.6 通过 API 检查诊断设置状态
运维时我经常要批量检查所有资源的诊断设置配置对不对。手动点门户太慢，可以用 Azure CLI 或 PowerShell 来查。
Azure CLI 示例：
# 列出某个资源的所有诊断设置
az monitor diagnostic-settings list \
--resource /subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.KeyVault/vaults/{vaultName} \
--output table
# 获取某个诊断设置的详细信息
az monitor diagnostic-settings show \
--resource /subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.KeyVault/vaults/{vaultName} \
--name "SendToLAW"PowerShell 示例：
# 获取资源组内所有已启用诊断设置的资源
Get-AzDiagnosticSetting -ResourceGroupName "myRG" |
Select-Object Name, ResourceId, WorkspaceId, Logs, Metrics这两个命令我几乎每周都要敲。尤其在做巡检的时候，我会写个脚本去对比“所有应配日志的资源”和“实际有诊断设置的资源”，找出漏配项。
核心结论：诊断设置是整个 Azure Monitor 日志架构的“入水管”。水管没接好，后面所有分析、告警、可视化全白搭。花 10 分钟把诊断设置配清楚，能省你后续无数排查时间。
3.7 本章小结
诊断设置本身不复杂，但细节特别多。记住三件事：
- 只适用于平台日志，来宾 OS 日志用代理
- 不要跟工作区保留策略冲突
- 生产环境用代码部署，避免人为遗漏