如何使用Prometheus监控按需动态创建的小型Spark集群

核心矛盾很明确：Prometheus默认的pull采集逻辑需要提前感知采集目标的地址，临时按需启动的小型Spark集群生命周期短、端点不固定，靠手动改静态配置根本跟不上集群启停节奏，以下是生产环境验证过的落地方案，按实施成本从低到高排序：

• 基于文件服务发现的轻量适配
  这是成本最低的方案，不需要额外部署第三方组件，只要调整Spark集群的启停脚本即可。
  每次启动临时Spark集群时，在启动流程末尾自动提取Driver、所有Executor的指标暴露地址（推荐直接开Spark自带的Prometheus Servlet，启动参数加spark.ui.prometheus.enabled=true即可，指标默认在各自WebUI的/metrics/prometheus路径下，不用额外挂载JMX Exporter agent），按Prometheus文件服务发现的格式，为单个集群生成独立的yaml配置文件，存放到Prometheus指定的服务发现目录下，文件里给当前集群的所有采集目标打上专属标签，比如spark_cluster_id=<集群唯一标识>、job_owner=<提交人>、expected_lifetime=<预期运行时长>。
  Prometheus侧只需要加一段简单的采集配置即可自动识别新增的集群：

  scrape_configs:
    - job_name: 'adhoc_spark'
      file_sd_configs:
        - files:
          - '/data/prometheus/sd/spark/*.yaml'
          refresh_interval: 15s
  

  集群运行结束触发销毁流程时，直接删掉对应集群的yaml配置文件即可，Prometheus会在15秒的扫描周期内自动移除失效的采集目标，不需要重载服务。为了避免集群异常退出没来得及删配置导致无效采集，可以加一条relabel规则，自动丢弃超过预期运行时长的目标。

• 对接资源调度器的原生服务发现
  如果你的临时Spark集群统一跑在Kubernetes、YARN这类资源调度平台上，连启停脚本的注册逻辑都不用自己写，直接对接调度器的服务发现能力即可。
  要是是Spark on K8s场景，直接在Prometheus里配置kubernetes_sd_configs，监听跑Spark作业的指定namespace，通过spark-app-selector这类原生标签自动筛选出Spark Driver和Executor的Pod，通过relabel自动提取PodIP和指标端口，Pod随集群销毁删除后，Prometheus会自动同步移除对应采集目标，全程无人工干预。
  要是是Spark on YARN场景，可以写个百行代码以内的轻量适配器，定期调用YARN ResourceManager的接口拉取所有RUNNING状态的Spark作业的AM、Container地址，转成Prometheus HTTP服务发现要求的格式返回，Prometheus侧配置http_sd_configs对接这个适配器即可，也不用维护本地文件。

• 短生命周期集群的中转采集方案
  如果你的临时Spark集群规模特别大、单集群生命周期极短（比如平均运行时长不到5分钟），硬做pull模式的服务发现开销太高，可以换中转采集的思路：
  要么部署统一的Pushgateway集群，Spark启动时配置把指标推送到Pushgateway，带上集群唯一标识标签，Prometheus固定从Pushgateway拉取指标即可，注意要配置集群销毁时主动调用Pushgateway接口删除对应集群的指标，避免留存垃圾数据；要么在所有计算节点上部署常驻的轻量采集Agent（比如Grafana Agent、VictoriaMetrics Agent），由Agent自动发现同节点上启动的Spark进程，主动拉取指标后远程写入统一的时序库，这种方案对Spark作业完全无侵入，不需要改任何启动脚本，适合集群启停频率极高的场景。

几个生产踩过的坑提醒：

1. 不管用哪种方案，一定要给临时集群的指标打上明确的集群标识标签，配置对应的指标清理、target丢弃规则，避免大量失效集群的废数据占满时序库存储。
2. 临时集群的采集间隔不要设得太短，15~30秒足够覆盖监控需求，过短的采集间隔会产生大量无效请求，拉高Prometheus的负载。
3. 不要用Pushgateway做指标聚合或者长期存储，它只是指标中转组件，存太多历史数据会直接影响采集性能。

内容的提问来源于stack exchange，提问作者idan ahal