1. Azure Monitor 概述：为什么它值得你花时间搞懂
说实话，我刚接触 Azure 那会儿，对 Monitor 这类“基础组件”其实没太当回事。那时候我觉得，把应用跑起来才是正经事，监控嘛，出问题了再查日志也来得及。
直到有次线上环境出了个性能抖动——用户疯狂报错，我却翻了大半天日志才定位到是存储层的 IOPS 被打满了。嗯，那半天真是度秒如年。从那以后，我才真正理解了 Azure Monitor 的价值。
1.1 什么是 Azure Monitor？它能做什么？
Azure Monitor 是 Azure 平台统一的监控和诊断服务。说白了，它就是一个“数据中心的眼睛”——帮你收集、分析、响应来自云资源和应用的各项指标与日志。
我个人习惯把它理解为三个层面：
- 看得到：自动采集 VM、数据库、容器、Web 应用等资源的运行状态。
- 理得清：把零散的指标和日志整合到统一的查询与分析引擎里。
- 反应快：基于预设规则触发告警或自动化修复动作。
举个例子，你有一台 SQL Server 跑在 Azure VM 上。Monitor 能告诉你 CPU 涨了多少、磁盘排队长度是不是在飙升、慢查询有没有突然增多。甚至可以在内存快吃满前，自动帮你扩容——这就是它的核心价值。
| 功能维度 | 具体能力 | 实际场景举例 |
|---|---|---|
| 数据采集 | 指标 / 日志 / 变更追踪 | 自动抓取 AKS 集群的 CPU 和内存使用 |
| 存储与分析 | Log Analytics 工作区 + 指标存储 | 用 KQL 查询过去 7 天的 500 错误分布 |
| 可视化 | 仪表板 / 工作簿 / 图表 | 制作一个“应用健康度”大屏 |
| 告警与响应 | 动态阈值 / 自动缩放 / Webhook | 当平均延迟 > 500 ms 时自动重启服务 |
1.2 审计日志在监控中的角色——别等到背锅才想起它
审计日志（Audit Logs）在监控体系里一直有点“低调”。不像 CPU 指标那么直观，也不像应用日志那么接地气。但我想说，它才是真正的“老实人”——你在 Azure 上做的每一次操作，几乎都会被它默默地记下来。
什么是审计日志？
在 Azure 语境下，审计日志通常指 活动日志 (Activity Log) 和特定资源类型（如 SQL、Key Vault）的 诊断日志。它们记录的是“谁、在什么时候、对什么资源、做了什么操作”。
- 活动日志：订阅级别的控制平面事件。比如创建了一个 VM、删除了一个存储账户、修改了网络策略。
- 诊断日志：资源内部的操作记录。比如谁在什么 IP 下调用了 Key Vault 的密钥。
我在项目中遇到过不止一次，应用出了安全事件，团队第一反应是“被黑了”。结果查了一圈，发现是某个运维同事在生产环境误删了配置项。这时候，审计日志就是最直接的证据——操作时间、操作人、操作内容，一条不差。
特别注意：审计日志默认只保留 90 天。如果你有合规或审计需求，务必把日志导出到 Log Analytics 工作区或存储账户做长期保存。否则，过了窗口期，想查也查不到了。
1.3 Azure Monitor 的核心组件——一张图看懂全家桶
刚开始接触 Monitor 的时候，我确实被它那一堆“Log Analytics、工作簿、诊断设置、指标资源管理器……”搞晕过。但其实它核心就几个大块，下面这张图帮你构建整体认知。
从上图可以看出，Azure Monitor 的架构非常清晰——分成四层：
- 数据源层：包括 Azure 资源、操作系统、应用代码、其他云或本地环境。
- 数据收集层：通过诊断设置、代理、API 等方式把数据送入平台。
- 存储与分析层：Log Analytics 工作区是日志的大本营，指标存储负责高性能时序数据。
- 消费层：基于分析结果做可视化、告警或导出到外部系统。
一个小技巧：我习惯在项目初期就把所有关键资源的诊断设置都配置好，指向同一个 Log Analytics 工作区。这样后续做跨资源查询会非常方便，比如“同时查 Web 应用、数据库和防火墙的日志，看一次故障的完整链路”。
1.4 审计日志的存储路径——你可能会用到哪些地方？
如果你是为了集成审计日志存储才来学这门课，那我得重点提一下：审计日志最终落在哪里，决定了你能怎么查、查多久、花多少钱。
核心存储选项对照表
| 存储目标 | 主要用途 | 保留期 | 成本 |
|---|---|---|---|
| Log Analytics 工作区 | 交互式查询、告警、制作工作簿 | 可配置（30天～2年+） | 按数据量收费 |
| Azure 存储账户 (Blob) | 长期归档、合规备份、低成本存储 | 自定义（不限制） | 存储费用很低 |
| Event Hubs | 实时流式传输到 SIEM（如 Splunk） | 按需转发 | 按吞吐量收费 |
我个人比较推荐的实践是：“热数据进 Log Analytics，冷数据进 Blob”。说白了，最近几个月经常查的日志放工作区，方便快速检索；超过半年的历史数据扔存储账户，真有合规审计需求时再拉出来查，能省下不少成本。
我曾经犯过一个错误——把所有审计日志一股脑全保留在 Log Analytics 里，没做归档。结果月底看账单，数据量超了预算一大截。嗯，从那以后，存档策略就成了我搭建监控系统时最优先考虑的事情之一。
1.5 本章小结（快速回顾）
- Azure Monitor 是统一的监控与诊断平台，核心能力覆盖采集、存储、分析、告警。
- 审计日志 记录控制平面和数据平面的所有操作，是安全与合规的基石。
- 核心组件遵循“数据源 → 收集 → 存储分析 → 消费”的经典四层架构。
- 审计日志的存储策略直接影响查询效率和成本——“热存 Log Analytics，冷存 Blob”是通用好方案。