如何将Prometheus各采集job在Grafana中配置为独立数据源

完全不需要把每个job部署成独立的Prometheus服务，现有架构下有两种低成本、无额外运维负担的实现方式，完全匹配“不用手动写job过滤、Dashboard内隔离其他job指标”的需求：

方案1：基于现有单Prometheus实例，在Grafana侧配置带过滤规则的独立数据源（改动最小、最推荐） #

这个方案完全不需要修改现有的prometheus.yaml配置，只需要在Grafana的数据源管理页面完成配置即可：

• 为每个应用（app1、app2、app3）分别新建一个Prometheus类型的数据源，所有数据源的后端地址都指向现有同一个Prometheus服务
• 进入每个数据源的配置页，找到Custom Query Parameters配置项，给对应的数据源传入全局匹配规则：
  • app1对应的数据源配置参数：match[]={job="app1"}
  • app2对应的数据源配置参数：match[]={job="app2"}
  • app3对应的数据源配置参数：match[]={job="app3"}
• 配置生效后会达成两个核心效果：
  • 所有走该数据源的PromQL查询，会自动把配置的match[]条件附加到请求中，写查询时不需要再手动追加{job="appX"}的过滤标签
  • Grafana的指标下拉检索、标签值发现接口请求，同样会带上这个全局匹配规则，指标列表会直接过滤掉其他job的所有无关指标，从查询入口实现Dashboard的指标隔离，不会出现跨job的指标混入问题

注意：这个方案的过滤逻辑是在Prometheus查询请求层面实现的，不是Dashboard前端层面的简单隐藏，隔离效果和独立数据源完全一致，没有额外的性能损耗。相比在Dashboard里加全局变量做过滤的方式，这种配置会把过滤规则应用到所有接口请求上，包括指标列表检索、标签值发现，不会出现下拉列表混入其他job指标的问题。

方案2：物理隔离的多Prometheus实例部署（适合高权限隔离要求场景） #

如果后续对指标隔离的权限要求更高，完全不需要依靠Grafana侧的规则做过滤，可以调整Prometheus的部署架构：

• 拆分部署多套独立的Prometheus实例，每个Prometheus的scrape_configs只配置对应单个应用的采集任务
• 每个Prometheus实例在Grafana中对应独立的数据源，由于采集阶段就已经做了job级别的目标拆分，所有指标天然归属对应应用，既不需要手动加job过滤，也不存在跨job的指标泄露问题
• 这种方案的运维成本会随着应用数量线性上升，仅适合应用规模小、安全隔离要求极高的场景，大部分场景下第一种方案的性价比更高。

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