📚 课程目录第3章 Databricks指标采集与监控体系

3. Databricks指标采集与监控体系

Databricks 的可观测性不是靠单一工具完成的，而是由多个采集通道叠加形成的分层体系。理解这套体系的关键，是先分清每一层"能看到什么、看不到什么"，再决定用哪一层的数据建立基线、触发告警。本节围绕 Spark UI、Ganglia、Metrics API 与 Prometheus 四条主线，说明集群与作业指标如何被采集、汇聚和消费。

四条采集通道的定位差异

Spark UI 是作业级诊断入口，它绑定在 Driver 上，展示 Stage、Task、Shuffle Read/Write、GC 时间、Executor 的存储与计算状态。它的优势是粒度细、能直接定位到某个 Task 的倾斜或失败；局限是数据保留时间短（默认随应用结束而消失，除非开启 Event Log 写入持久存储），且不提供集群节点的 CPU、磁盘、网络等主机层指标。

Ganglia 是 Databricks 经典集群（非 Serverless）中默认提供的主机层监控，采集每个节点的 CPU 利用率、内存使用、磁盘 I/O、网络吞吐，并以时间序列方式展示。它回答的是"机器是否成为瓶颈"，但无法告诉你某个 Spark Stage 为什么慢。

Metrics API 是程序化获取集群与作业指标的接口，通过 REST 调用可以拉取节点级和 Spark 级的指标快照，适合做自动化巡检、把数据写入外部时序库，或与自建监控平台集成。Prometheus 则通过指标抓取与长期存储，把上述离散数据变成可查询、可告警、可做基线对比的时间序列。

关键性能指标的采集口径

建立基线之前，必须先固定每个指标的采集口径，否则不同时间点的数据不可比。以下参数为教学示例，实际取值需按集群规格与业务负载调整。

指标	采集来源	口径说明	示例基线
节点 CPU 利用率	Ganglia / Metrics API	5 分钟窗口均值，排除 Driver 节点	峰值 < 75%
Executor 堆内存	Spark Metrics Sink	JVM heap used / max，取 P95	< 80%
Shuffle Write	Spark UI / Event Log	单 Stage 落盘字节数	单 Stage < 20 GB
Shuffle Spill	Spark UI	磁盘溢写次数，按 Executor 汇总	0 次为佳，> 3 次告警
Stage 时长	Event Log	从 Stage 提交到完成	P95 < 8 分钟
Task 延迟	Spark UI	单 Task 执行时间 P99	P99 < 90 秒

从采集到基线的落地路径

第一步是打开持久化采集。在集群 Spark 配置中启用 Event Log，把日志写入 DBFS 或云存储路径，这样 Spark UI 的数据在应用结束后仍可回溯：

spark.eventLog.enabled true
spark.eventLog.dir dbfs:/cluster-logs/spark-events
spark.sql.adaptive.enabled true
spark.sql.adaptive.coalescePartitions.enabled true

第二步是接入 Metrics API 做程序化拉取。以下示例用 REST 调用获取集群节点指标，实际使用时需替换集群 ID 与访问令牌：

GET /api/2.0/clusters/get?cluster_id=<cluster-id>
GET /api/2.0/metrics/cluster?cluster_id=<cluster-id>&start_time=...
Authorization: Bearer <token>

第三步是把指标写入 Prometheus。Databricks 的 Spark Metrics Sink 支持将 JVM、Executor、Streaming 指标以 Prometheus 格式暴露，配合抓取配置即可长期存储。对于 Ganglia 与 Metrics API 的数据，可通过定时任务拉取后以 Pushgateway 方式写入。

基线不是一次设定就固定不变。建议按"工作日高峰 / 夜间批处理 / 周末"三个时段分别统计 P50 与 P95，形成分时段基线，避免用统一阈值误报。

如何判断指标是否异常

单点超阈值不等于故障，需要结合趋势与关联指标判断。例如 CPU 利用率升高但 Stage 时长未变，通常只是负载增加；若 CPU 正常而 Shuffle Spill 次数上升、Task P99 明显拉长，则更可能是数据倾斜或分区数不足。此时应回到 Spark UI 查看该 Stage 的 Task 时间分布，确认是否存在少数 Task 远慢于其他 Task。

Ganglia 在 Serverless 计算中不可用，Serverless 场景应改用 Metrics API 与 Spark UI 的 Event Log 组合采集，不要沿用经典集群的监控假设。

把四条通道的数据对齐到同一时间轴，是建立有效监控体系的核心。Spark UI 提供作业内部因果，Ganglia 与 Metrics API 提供主机资源背景，Prometheus 提供长期趋势与告警能力。只有把"作业为什么慢"与"机器是否吃紧"放在一起看，基线才具备诊断价值，而不是一组孤立的数字。