这是个很常见的需求——毕竟谁不想把抓取指标的性能数据也精准归因到每个业务应用呢？咱们一步步拆解问题，找到解决方案：

为什么默认做不到？ #

首先得明确：Prometheus的scrape_samples_scraped这类scrape_*系列指标，是针对单次抓取任务生成的全局统计指标，不是附着在单个业务指标上的元数据。它们的job标签默认取自你prometheus.yml中配置的抓取任务job_name，和业务指标里的job标签完全是两回事——honor_labels只作用于从目标抓取到的业务指标，对Prometheus自身生成的这些内部指标无效。

你的场景里，Prometheus只抓取一个集中式应用的endpoint，所以默认只会生成一条scrape_samples_scraped，job标签是这个集中式应用的任务名，没法直接拆分到各个源应用。

两种可行的解决方案 #

方案1：拆分集中式应用的暴露端点（推荐） #

这是最贴合Prometheus原生设计的方法：让你的集中式应用为每个源应用单独暴露一个metrics端点（比如/metrics/appA、/metrics/appB），然后在Prometheus里为每个端点配置独立的抓取任务，把job_name设为对应源应用的名称。

示例prometheus.yml配置：

scrape_configs:
  - job_name: 'ApplicationA'
    honor_labels: true
    static_configs:
      - targets: ['exporter:9090']  # 你的集中式应用地址
    metrics_path: '/metrics/ApplicationA'

  - job_name: 'ApplicationB'
    honor_labels: true
    static_configs:
      - targets: ['exporter:9090']
    metrics_path: '/metrics/ApplicationB'

这样配置后，每次抓取对应一个源应用的指标，scrape_samples_scraped的job标签会自动是ApplicationA/ApplicationB，数值也正好是该应用的样本数，完全符合你想要的效果。

方案2：用记录规则聚合样本数（适配无法修改集中式应用的场景） #

如果没法调整集中式应用的端点设计，你可以通过Prometheus的记录规则，基于业务指标的job标签聚合出每个源应用的样本数，生成和scrape_samples_scraped类似的自定义指标。

1. 先在prometheus.yml中添加规则文件引用：

rule_files:
  - 'sample_count_rules.yml'

2. 创建sample_count_rules.yml文件，编写聚合规则：

groups:
- name: sample_count_aggregation
  rules:
  - record: scrape_samples_scraped
    expr: count by (job, instance) ({__name__!~"scrape_.+"})
    labels:
      aggregated: 'true'

这个规则会：

• 排除Prometheus自身的scrape_*指标（用__name__!~"scrape_.+"）
• 按源应用的job标签和抓取实例分组，统计每组的业务指标数量
• 生成新的scrape_samples_scraped指标，标签包含源应用的job

注意：这个方法是近似统计，和原生scrape_samples_scraped的数值可能有细微差异（比如是否包含集中式应用自身的指标），但能满足“将样本量归因到对应源应用”的核心需求。

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