📚 课程目录第2章 Azure Monitor体系结构

2. Azure Monitor体系结构

Azure Monitor 并不是一个单一产品，而是一套围绕“遥测数据”构建的统一平台。理解它的体系结构，关键要抓住四个问题：数据从哪里来（数据源）、数据存到哪里（数据平台）、数据怎么走（数据路由）、数据留多久（保留策略）。把这四条主线理清，后面配置诊断设置、编写 KQL 查询、设计告警和成本控制时，就不会“只见工具、不见结构”。

一、数据平台：两类存储，各司其职

Azure Monitor 的存储层主要由两部分组成：Azure Monitor Metrics（指标库）和Log Analytics 工作区（日志库）。它们不是同一份数据的两种视图，而是面向不同使用场景的两套引擎。

指标库是时序数据库，专为轻量、高频、近实时的数值型数据设计。它保存的是带时间戳的数值序列，例如 CPU 百分比、请求数、队列长度。指标库的特点是写入快、查询快、保留时间相对短，适合做实时图表和基于阈值的指标告警。默认情况下，平台指标保留约 93 天，且大部分平台指标无需预先配置即可查看。

Log Analytics 工作区是日志与结构化遥测的存储与分析引擎，底层基于 Kusto 引擎，用 KQL 查询。它承载资源日志、活动日志、应用日志、容器日志、自定义日志等。日志库支持更长的保留期、更复杂的关联分析，也是绝大多数生产排障的主战场。工作区是“数据落点”的核心对象，它的区域、定价层、保留设置会直接影响成本与合规。

一个常见误区：以为“指标和日志是同一份数据的两种格式”。实际上，很多资源日志需要显式配置诊断设置才会进入工作区，而平台指标默认就在指标库中。二者采集路径不同，不能互相替代。

二、数据源：遥测从哪几路汇入

Azure Monitor 的数据源可以按“层级”来记忆，这样在排查“为什么没有数据”时能快速定位。

应用层：Application Insights 采集请求、依赖、异常、跟踪、页面浏览等，SDK 或自动插桩写入。
资源层：各类 Azure 资源（VM、App Service、AKS、SQL、存储等）产生的平台指标与资源日志。
订阅/租户层：活动日志记录控制面操作，如创建、删除、修改资源，以及服务健康事件。
操作系统/代理层：Azure Monitor Agent（AMA）通过数据收集规则（DCR）采集来宾 OS 的性能计数器、事件日志、Syslog 等。
自定义来源：通过数据收集器 API、Logs Ingestion API 或 SDK 写入自定义日志与指标。

这里要特别区分平台指标与资源日志：平台指标自动可用，资源日志通常需要诊断设置才能导出。很多“监控没数据”的问题，根源就是资源日志从未被路由到任何目标。

三、数据路由：诊断设置是核心枢纽

数据路由决定了遥测数据“往哪去”。在 Azure Monitor 中，最主要的配置对象是诊断设置（Diagnostic Settings）。它定义了三件事：采集哪些类别（Categories）、发送到哪些目标（Destinations）、以及是否启用。

诊断设置支持的目标主要有四类：

Log Analytics 工作区：用于 KQL 分析、日志告警、工作簿。
存储账户：用于长期归档、低成本留存、合规审计。
事件中心（Event Hubs）：用于流式转发到第三方 SIEM 或自建消费程序。
合作伙伴解决方案：如部分第三方监控平台。

一个资源可以配置多条诊断设置，把不同类别发往不同目标。例如：把 Audit 类别发到存储账户做长期归档，把 AllLogs 发到工作区做实时分析。这种“分流”设计是控制成本和满足合规的常用手段。

对于虚拟机来宾数据，路由由数据收集规则（DCR）控制。DCR 定义了采集哪些数据源、做哪些转换（如用 KQL 过滤或脱敏）、以及发送到哪个工作区。DCR 与 AMA 配合，取代了旧的 Log Analytics 代理配置方式，也让采集策略更集中、更可复用。

四、保留策略：成本与合规的平衡点

保留策略直接决定“数据能查多久”和“账单有多高”。不同平台的保留机制不同，需要分开理解。

指标库的保留由平台管理，平台指标默认约 93 天。这个期限通常不可按资源单独延长，如果需要更长时间的趋势数据，常见做法是定期把指标导出到存储账户或工作区。

Log Analytics 工作区的保留分为两层：交互保留（Interactive Retention）和长期保留（Long-Term Retention）。交互保留期内数据可随时用 KQL 查询，默认 30 天，可按表调整到 30 天至 730 天不等（具体上限随表类型和定价层变化）。超过交互保留期后，可以启用长期保留，把数据以更低成本保存最长约 12 年，但查询时需要走“搜索作业（Search Job）”或“还原（Restore）”流程，不能像普通表那样直接查。

这里有一个非常实用的成本控制点：按表设置保留。例如，把高频写入但价值衰减快的表（如容器 stdout 日志）交互保留设为 30 天，把审计类表设为 90 天或更长。这样既满足合规，又避免为“很少查的旧数据”支付高额分析费用。

保留期设置过短会导致排障时“数据已经过期”。生产环境建议至少保留 30 天交互数据，并对关键审计表启用长期保留。调整保留期前，先确认合规要求和历史排障需求。

五、把结构落到配置上

理解了体系结构，配置时就有了清晰的检查顺序。下面是一份可直接参考的诊断设置配置示例，用于把某虚拟机的资源日志同时发往工作区和存储账户：

# 示例：为 VM 创建诊断设置（示意参数，实际以环境为准）
az monitor diagnostic-settings create \
  --name "vm-diag-to-law-and-storage" \
  --resource "/subscriptions/<sub-id>/resourceGroups/rg-prod/providers/Microsoft.Compute/virtualMachines/vm-app01" \
  --workspace "/subscriptions/<sub-id>/resourceGroups/rg-monitor/providers/Microsoft.OperationalInsights/workspaces/law-prod" \
  --storage-account "/subscriptions/<sub-id>/resourceGroups/rg-monitor/providers/Microsoft.Storage/storageAccounts/stmonitorprod" \
  --logs '[{"category":"Administrative","enabled":true},{"category":"Security","enabled":true}]' \
  --metrics '[{"category":"AllMetrics","enabled":true}]'

配置完成后，验证路径也很明确：先确认资源是否真的产生了对应类别的日志，再确认诊断设置是否启用且目标正确，最后在工作区中用 KQL 查询对应表（如 AzureActivity、Heartbeat、Perf 或资源专属表）确认数据已到达。如果查询为空，优先检查诊断设置的目标区域是否与工作区一致——跨区域写入虽然支持，但会增加延迟和成本。

最后要强调一个设计原则：先想清楚“谁在什么时候需要什么数据”，再决定路由和保留。实时告警需要的数据进工作区并保持足够交互保留；合规归档的数据进存储账户；需要转发到外部 SIEM 的数据走事件中心。把数据源、路由、平台、保留四者对齐，Azure Monitor 才能既好用又可控。