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

3. 指标采集与监控体系

在 Databricks AI 数据平台上，可观测性的第一层是指标（Metrics）。日志告诉你“发生了什么事件”，而指标告诉你“系统当前处于什么状态、变化趋势如何”。本节围绕四条采集路径展开：Prometheus 负责通用时序指标抓取与告警，Ganglia 负责集群级资源聚合视图，Spark Metrics System 负责作业内部细粒度指标，Databricks Metrics API 则提供平台原生的作业与集群指标出口。理解它们的采集对象、数据模型与接入方式，才能构建出真正可用的自定义指标看板。

一、四条采集路径的分工

这四者不是互相替代，而是覆盖不同层次：

Prometheus：拉取式（pull）时序数据库，通过 HTTP 端点周期性抓取指标，配合 PromQL 查询与 Alertmanager 告警。适合采集集群节点、容器、JVM 以及自定义业务指标。
Ganglia：面向大规模集群的分布式监控系统，采用层次化聚合（gmond → gmetad → gweb），擅长展示 CPU、内存、网络、磁盘的集群级热力图与聚合趋势。
Spark Metrics System：Spark 内置的指标框架，通过 Sink 将 Driver/Executor 的 JVM、Shuffle、Stage、Task 指标输出到 CSV、JMX、Graphite、Prometheus 等目标。
Databricks Metrics API：平台原生接口，暴露集群利用率、作业运行时长、DBU 消耗、任务状态等指标，适合与外部监控系统对接。

下图展示了四条路径从数据源到看板的整体信号链关系：

二、Prometheus 接入 Databricks 的关键配置

Prometheus 采集 Databricks 指标通常有两种方式：一是通过 Spark Metrics System 的 PrometheusServlet Sink 暴露端点，二是通过 Databricks Metrics API 定期拉取后写入 Pushgateway 或远程写（remote write）。以 Spark 侧为例，在集群 Spark 配置中设置：

spark.metrics.conf.*.sink.prometheusServlet.class=org.apache.spark.metrics.sink.PrometheusServlet
spark.metrics.conf.*.sink.prometheusServlet.path=/metrics/prometheus
spark.metrics.conf.master.sink.prometheusServlet.path=/metrics/master/prometheus
spark.metrics.conf.applications.sink.prometheusServlet.path=/metrics/applications/prometheus

配置生效后，Driver 的 4040 端口会暴露 /metrics/prometheus 路径。Prometheus 的 scrape_configs 中增加对应 job，抓取间隔建议 15s～30s。需要注意：Databricks 集群的 Driver 地址是动态的，生产环境通常配合服务发现或通过 Metrics API 中转。

三、Spark Metrics System 的指标命名与 Sink 选择

Spark 指标采用 namespace.metricName 的层级命名，常见命名空间包括：

driver.jvm.*：JVM 堆内存、GC 时间、线程数
executor.jvm.*：Executor 侧 JVM 指标
driver.ShuffleMetrics.*：Shuffle 读写字节数、记录数
executor.threadpool.*：线程池活跃/完成任务数
driver.DAGScheduler.*：Stage 提交、完成、失败计数

Sink 的选择取决于目标系统：CSV Sink 适合离线分析，JMX Sink 适合与 JVM 监控工具集成，Graphite Sink 适合推送到 Graphite，PrometheusServlet Sink 适合拉取式采集。生产环境推荐 PrometheusServlet + JMX 双 Sink，兼顾实时看板与深度诊断。

四、Databricks Metrics API 的使用

Databricks Metrics API 提供 REST 接口，可查询集群利用率、作业运行指标、DBU 消耗等。典型调用流程：

使用 Personal Access Token 或 Service Principal 获取认证。
调用 GET /api/2.0/clusters/get 获取集群状态与配置。
调用 GET /api/2.0/clusters/events 获取集群事件时间线。
调用 GET /api/2.1/jobs/runs/get 获取作业运行指标。
将返回的 JSON 指标转换为 Prometheus 格式，通过 Pushgateway 或 remote write 写入 TSDB。

示例：将作业运行时长转换为 Prometheus 指标，可在采集脚本中提取 run_duration 字段，生成 databricks_job_run_duration_seconds{job_id="123"} 并推送。这样就能在 Grafana 中与 Spark 内部指标关联分析。

五、自定义指标看板的设计要点

看板不是指标越多越好，而是要围绕“可行动”设计。建议按三层组织：

集群健康层：节点 CPU/内存/磁盘使用率、Ganglia 聚合视图、集群事件。
作业性能层：Stage 耗时、Shuffle 读写、Task 失败率、GC 时间、作业运行时长。
成本与容量层：DBU 消耗趋势、集群利用率、空闲时长。

每层设置明确的告警阈值。例如：Shuffle 读写字节数突增 3 倍、GC 时间占比超过 20%、Task 失败率超过 5%、集群空闲超过 30 分钟，都应触发告警。告警规则用 PromQL 表达，例如：

rate(spark_executor_jvm_gc_time_seconds_total[5m]) 
  / rate(spark_executor_jvm_run_time_seconds_total[5m]) > 0.2

建议先采集 1～2 周基线数据，再设定阈值。没有基线的阈值往往不是误报就是漏报。

六、常见问题与排查

实际接入中最常见的问题有三类：一是指标端点不可达，通常是 Spark 配置未生效或网络策略拦截；二是指标缺失，检查 Sink 是否配置到正确的 namespace；三是指标重复或标签冲突，检查 Prometheus 的 relabel 配置。排查时先用 curl 直接访问指标端点确认数据存在，再检查 Prometheus Targets 页面确认抓取状态，最后用 PromQL 查询验证数据是否入库。

Databricks 集群重启后 Driver 地址会变化，静态 scrape 配置会失效。生产环境务必使用服务发现或 Metrics API 中转方案。

掌握这四条采集路径后，下一层就是如何将指标转化为可读的看板与可执行的告警。指标采集是基础，看板设计是表达，告警规则是行动——三者缺一不可。