3. Azure Monitor基础
Azure Monitor 是 Azure 上所有可观测性能力的统一入口，但它本身并不是一个单一产品，而是由若干数据平面、采集通道和存储后端组合而成的平台。理解 Azure Monitor，关键不是记住菜单路径，而是分清四类数据各自从哪里来、经过什么通道、最终落在哪里、用什么查询语言读取。只有把这条链路理清，后面做数据工厂、Synapse、Databricks 的监控时才不会把指标、日志和活动日志混为一谈。
四类核心数据：指标、日志、活动日志、平台日志
指标（Metrics）是随时间变化的数值序列，采样频率高、结构固定、保留时间短（默认 93 天，可归档到存储）。例如数据工厂的 PipelineSucceededRuns、Synapse SQL 池的 DWUUsedPercent、存储账户的 Transactions。指标适合做阈值告警和实时看板，但不适合承载带上下文的明细。
日志（Logs）是结构化或半结构化的记录，写入 Log Analytics 工作区，用 KQL 查询，保留期可配置（交互式默认 30 天，长期保留可到 12 年）。日志承载的是“发生了什么”的细节，比如一次复制活动的行数、耗时、错误码。
活动日志（Activity Log）是订阅级的控制平面记录，自动采集，无需配置。它记录的是资源层面的操作：谁在什么时候创建、修改、删除了哪个资源，以及服务健康事件。活动日志默认保留 90 天，可导出到工作区或存储。它回答的是“谁动了我的资源”，而不是“数据管道跑得怎么样”。
资源日志（Resource Logs，旧称诊断日志）是数据平面日志，必须通过诊断设置显式开启才会产生。这是数据平台监控中最容易被忽略的一环：不配置诊断设置，数据工厂的活动运行明细、Synapse 的 SQL 请求日志、Key Vault 的访问审计都不会进入工作区。
诊断设置：把资源日志接进工作区
诊断设置是 Azure Monitor 中最具操作性的配置对象。它的结构很简单：一个数据源（某个具体资源，如某个数据工厂、某个 Synapse 工作区），一组类别（categories，如 PipelineRuns、ActivityRuns、TriggerRuns），以及一个或多个目标（Log Analytics 工作区、存储账户、事件中心）。
以数据工厂为例，开启诊断设置时通常勾选 PipelineRuns、ActivityRuns、TriggerRuns 三类，目标选同一个 Log Analytics 工作区。配置完成后，工作区中会出现 ADFPipelineRun、ADFActivityRun、ADFTriggerRun 三张表。此时用 KQL 就能查到每次管道运行的 RunId、Status、DurationMs、ErrorCode 等字段。
ADFActivityRun
| where TimeGenerated > ago(1h)
| where Status == "Failed"
| project TimeGenerated, PipelineName, ActivityName,
ErrorCode, ErrorMessage, DurationMs
| order by TimeGenerated desc这段查询是数据平台排障的起点：先定位失败活动，再顺着 RunId 关联到管道级运行记录，判断是单点失败还是整条管道失败。如果没有诊断设置，这些表根本不存在，只能依赖数据工厂自身的监控界面，无法与其它资源日志做关联分析。
工作区架构：集中还是分散
Log Analytics 工作区是日志的物理边界，也是权限、保留期和查询成本的边界。设计工作区架构时，核心权衡是集中与分散。
集中式：所有资源日志写入同一个工作区。优点是跨资源关联查询方便，一条 KQL 就能把数据工厂失败和 Synapse 慢查询串起来；缺点是权限粒度粗，不同团队的日志混在一起，且跨区域写入可能产生额外流量成本。
分散式：按业务线、环境或区域拆分工作区。优点是权限清晰、成本归属明确；缺点是跨工作区查询需要 workspace() 函数或跨工作区查询，复杂度上升。
对数据平台而言，比较务实的做法是：按环境（生产 / 非生产）拆两个工作区，生产环境内再按平台层（数据工厂、Synapse、Databricks、存储）用资源上下文区分，而不是每个资源一个工作区。这样既保留了生产环境的关联查询能力，又隔离了非生产环境的噪声和成本。
| 维度 | 集中式工作区 | 分散式工作区 |
|---|---|---|
| 跨资源关联查询 | 直接，单条 KQL | 需跨工作区函数 |
| 权限粒度 | 粗，工作区级 | 细，按团队/环境 |
| 成本归属 | 难拆分 | 清晰 |
| 保留策略 | 统一 | 可按工作区差异化 |
| 适用场景 | 中小规模、强关联 | 多团队、多环境、合规隔离 |
与数据平台监控的集成方式
数据平台各服务的集成方式并不一致，需要分别处理：
- Azure 数据工厂：通过诊断设置把
ActivityRuns等类别送入工作区，这是获取活动级明细的唯一途径。指标侧可直接用PipelineFailedRuns做告警。 - Synapse Analytics：SQL 池的
SQLRequests、ExecRequests等类别需诊断设置开启；Spark 池日志通过工作区或存储接入。DWU 使用率走指标。 - Databricks：诊断设置可将
clusters、jobs、notebook等日志送入工作区，但集群内 Spark 日志通常还需配置集群日志投递路径。 - 存储账户：
StorageRead、StorageWrite、StorageDelete类别用于审计访问，指标侧看Transactions和SuccessE2ELatency。
集成完成后，一个典型的排障路径是：指标告警发现数据工厂失败率上升 → 活动日志确认没有资源变更 → 工作区中查 ADFActivityRun 定位失败活动 → 关联 SynapseSqlPoolRequestSteps 判断是否下游 SQL 超时。这条路径把四类数据串成了一个闭环，也是 Azure Monitor 在数据平台上真正的价值所在。