1. 可观测性工程导论

在传统运维里，我们常把“监控”理解为对已知故障模式的盯防：CPU 超过 80% 报警、磁盘剩余空间低于 10% 报警、服务进程消失报警。这套思路的前提是——我们事先知道哪些指标会出问题。但 Azure 数据平台（Data Factory、Synapse、Databricks、Event Hubs、ADLS Gen2、Stream Analytics 等）的故障往往不是“某个指标越界”，而是“一条数据没有按时到达”“一个管道静默地少处理了 3% 的行”“某个分区在凌晨 2 点后延迟持续爬升”。这类问题无法靠预设阈值回答，只能靠对系统内部状态的推断能力来回答。

可观测性工程（Observability Engineering）正是为这种“未知的未知”而生的学科。它的定义可以概括为：通过系统对外输出的遥测数据，在不预先假设故障模式的前提下，推断系统内部状态、定位异常根因并验证修复效果的能力。注意三个关键词：不预设故障模式、推断内部状态、验证修复。监控回答“是否正常”，可观测性回答“为什么不正常、哪里不正常、影响谁”。

三大支柱：日志、指标、追踪各自回答什么

可观测性的三大支柱并非三个可以互相替代的工具，而是三种互补的“提问方式”。理解它们的差异，比记住它们的名字更重要。

• 日志（Logs）：离散的、带时间戳的事件记录，回答“发生了什么具体事件”。在 Azure 数据平台中，典型来源是 Data Factory 活动运行日志、Databricks 集群驱动日志、Synapse 专用 SQL 池的 DMV 输出、ADLS Gen2 的诊断日志。日志信息密度高但体量大，适合事后取证与精确排查。
• 指标（Metrics）：按固定时间间隔聚合的数值序列，回答“整体趋势如何、是否越界”。例如 Event Hubs 的 IncomingMessages、Synapse 的 DWU 使用率、Databricks 的集群 CPU 与 shuffle 字节数。指标成本低、适合长期留存与告警，但丢失了个体事件的细节。
• 追踪（Traces）：一次请求或一次数据流经多个组件时形成的因果链路，回答“这次处理经过了哪些环节、哪一段慢或失败”。在数据平台中，追踪常以“管道运行 ID + 活动 ID + 子作业 ID”的关联形式出现，把 ADF 的 Copy 活动、Databricks 的 notebook 任务、Synapse 的存储过程串成一条链。

三者的关系可以用一个判断路径来理解：指标告诉你“有事发生”，追踪告诉你“事发生在哪一段”，日志告诉你“那一段里到底出了什么错”。缺少任何一根支柱，排查都会退化为猜测。

在 Azure 数据平台中的价值与边界

把三支柱落到 Azure 数据平台，价值体现在三个具体场景。第一，数据新鲜度保障：Event Hubs 的 IncomingMessages 指标下降、Stream Analytics 的 Watermark Delay 上升、下游 Synapse 表长时间无新分区，三者结合可以判断是“上游没数据”还是“处理链路卡住”。第二，管道性能回归：Data Factory 管道运行时长 P95 从 12 分钟涨到 25 分钟，追踪显示 Copy 活动耗时正常而 Databricks notebook 活动翻倍，日志显示 shuffle spill 激增，根因指向数据倾斜而非网络。第三，成本异常归因：Synapse DWU 使用率持续高位，追踪到某个存储过程被高频调用，日志确认其扫描了未分区的大表。

但可观测性有明确边界，必须诚实对待。其一，它不能替代正确的架构设计：如果管道没有幂等性、没有分区裁剪，再多的遥测也只能告诉你“它很慢”，无法让它变快。其二，它受采样与成本约束：全量日志在 PB 级数据平台中不可承受，通常需要对日志采样、对指标降精度、对追踪设置采样率，这必然带来“可能漏掉低频异常”的风险。其三，它依赖关联标识的完整性：如果 ADF 的 runId 没有传递到 Databricks 作业，追踪链就会断裂，此时只能退回到时间窗口对齐的粗略推断。其四，它不自动给出因果：相关性不等于因果，可观测性提供的是证据链，最终判断仍需工程师结合业务语义完成。

一个可落地的最小起步示例

假设你要为一个 ADF + Databricks + Synapse 的每日批处理链路建立可观测性基线。可以按以下方式组织遥测，参数为示例假设值，用于说明结构而非实测结果：

指标层（Azure Monitor，1 分钟粒度，保留 30 天）
  ADF: PipelineRunDuration / ActivityRunDuration / FailedRuns
  Databricks: ClusterCPU / ShuffleBytesWritten / JobRunDuration
  Synapse: DWUUsedPercent / ActiveQueries

追踪层（关联标识贯穿）
  ADF runId  →  传入 Databricks job 参数 correlation_id
  Databricks job run_id  →  写入 Synapse 审计表 etl_audit

日志层（Log Analytics，按需查询）
  ADF 活动输出 → 失败时保留完整 errorCode 与 message
  Databricks 驱动日志 → 仅保留 WARN/ERROR 级别
  Synapse DMV → 每 5 分钟快照一次等待类型

建立基线后，先观察一周的正常波动范围，再设置告警。例如管道时长 P95 基线为 12 分钟，告警阈值可设为 18 分钟（1.5 倍），而不是拍脑袋的 30 分钟。这样告警才有信噪比，可观测性才不会退化成“告警疲劳”。

最后要强调：可观测性工程不是买一套工具，而是一种工程习惯——在设计和实现数据管道时，就同步考虑“如果它出问题，我需要哪些遥测才能解释它”。这种习惯，才是 Azure 数据平台从“能跑”走向“可信”的分水岭。