2. Databricks工作区与可观测性数据源

Databricks 的可观测性不是从某个单一监控面板开始的，而是从理解“哪些组件在产生运行信号、这些信号存放在哪里、以什么粒度暴露”开始的。一个工作区里同时运行着集群、作业、笔记本、Delta Live Tables（DLT）管道和 SQL 仓库，它们各自产生不同形态的日志、指标、事件和血缘信息。如果不知道信号源的位置和结构，后续的采集、聚合与告警就无从谈起。本节按组件逐一梳理可观测性数据源，并给出可落地的采集路径。

工作区：审计与事件的总入口

工作区是账户下的逻辑隔离单元，也是审计日志（Audit Logs）的归属边界。审计日志记录了谁在什么时间对哪个对象执行了什么操作，例如 workspaceConf、clusterCreate、runCommand、jobRunStart 等事件。它有两种投递方式：一是通过账户控制台的诊断日志（Diagnostic Logs）投递到 S3、ADLS 或 GCS；二是通过 system.access.audit 系统表在 Unity Catalog 中直接查询。前者适合长期归档与外部 SIEM 集成，后者适合在 Databricks 内部用 SQL 做即时分析。采集时通常把审计日志按 workspace_id、service_name、action_name、event_time 分区，便于按工作区和操作类型下钻。

集群：指标与日志的双通道

集群是计算资源的载体，其可观测性信号分为两类。第一类是 Ganglia 指标，包括 CPU 利用率、内存使用、磁盘 I/O、网络吞吐和 shuffle 读写，可通过集群的 Metrics 页面查看，也可通过 system.compute.node_timeline 和 system.compute.clusters 系统表获取节点级与集群级的时间线数据。第二类是 Spark 日志，包括 driver 日志、executor 日志和事件日志（Event Log）。事件日志是 Spark 作业级可观测性的核心，它记录了 stage、task、shuffle、executor 增删等结构化事件，通常写入 DBFS 或云存储路径，再由 Spark History Server 或外部工具解析。采集时建议开启 spark.eventLog.enabled 并指定 spark.eventLog.dir，同时把日志路径纳入统一存储生命周期管理。

作业：运行状态与重试链路

作业（Job）是调度层的主要观测对象。每次运行会产生一条 run 记录，包含 run_id、job_id、life_cycle_state、result_state、start_time、end_time 和触发方式。这些信息可通过 Jobs API 的 /api/2.1/jobs/runs/list 拉取，也可通过 system.lakeflow.job_run_timeline 系统表查询。作业的可观测性重点在于：区分“调度延迟”与“执行失败”，识别重试次数和失败原因，以及追踪任务依赖链中的瓶颈任务。采集时通常按 job_id 和 run_id 建立主键，把每次运行的状态变化作为时间序列事件存储，便于计算成功率、P95 运行时长和失败分布。

笔记本：交互式执行的细粒度信号

笔记本的可观测性相对特殊，因为它以交互式命令为单位。每次 runCommand 都会在审计日志中留下记录，包含 notebook_id、command_id、execution_time 和用户身份。对于需要深入分析执行性能的场景，可以结合 Spark 事件日志中的 stage 信息，把某个命令映射到具体的 stage 和 task。采集笔记本信号时，重点不是记录每个单元格的内容，而是记录命令的执行时长、失败率和资源消耗，用于识别低效查询或异常重试。

Delta Live Tables：管道级事件与数据质量

DLT 管道把数据流、数据质量和血缘整合在一起。每次管道更新会产生一组事件，包括 flow_progress、dataset_definition、data_quality 和 update_progress。这些事件可通过 DLT 事件日志 API 获取，也可通过 system.lakeflow.pipeline_events 系统表查询。DLT 的可观测性价值在于：它把“数据是否按预期到达”“质量规则是否通过”“流是否积压”直接暴露为结构化事件。采集时应重点关注 flow_progress 中的 num_output_rows、num_input_rows 和 backlog_bytes，以及 data_quality 中的 passed_records 与 failed_records。

SQL 仓库：查询性能与并发信号

SQL 仓库的可观测性主要来自查询历史（Query History）和仓库指标。查询历史记录每次 SQL 执行的 query_id、statement_text、duration、rows_produced、read_bytes 和 waiting_time，可通过 system.query.history 系统表查询。仓库指标则包括并发查询数、排队时长、集群扩缩容事件和缓存命中率。采集 SQL 仓库信号时，重点是把“查询慢”拆解为“排队慢”“编译慢”“执行慢”和“结果拉取慢”，从而定位是仓库容量不足还是查询本身低效。

采集落地的关键约定

把上述信号真正接入可观测性平台时，需要统一几个约定。第一，时间戳统一使用 event_time（UTC），避免跨时区聚合时出现偏差。第二，主键设计要能唯一标识一次运行或一次查询，例如作业用 job_id + run_id，DLT 用 pipeline_id + update_id，SQL 用 query_id。第三，原始事件与聚合指标分开存储：原始事件保留完整字段用于排障，聚合指标按分钟或小时粒度预计算用于看板和告警。第四，采集频率要与信号变化速度匹配——集群指标可以 1 分钟一次，作业状态可以 30 秒一次，审计日志可以 5 分钟批量拉取。

理解这些数据源之后，下一步才是选择采集工具和构建管道。本节的目标是建立一张“信号地图”：知道每个组件产生什么信号、信号在哪里、以什么方式取出来。有了这张地图，后续无论是用系统表做 SQL 分析，还是用 API 拉取后写入 Delta 表，都能找到对应的入口和字段。