Prometheus 不会从 PCP pmproxy 中抓取所有指标答案

【问题标题】：Prometheus does not scrape all metrics from PCP pmproxyPrometheus 不会从 PCP pmproxy 中抓取所有指标
【发布时间】：2020-06-11 09:15:41
【问题描述】：

在装有 Fedora 30 的笔记本电脑上，我安装并运行了 Performance Co-Pilot (PCP) 守护程序，并从包 golang-github-prometheus-prometheus-1.8.0-4.fc30.x86_64 安装了 Prometheus。在 PCP 收集器的配置中，我指定了以下度量名称空间：

# Performance Metrics Domain Specifications
# 
# This file is automatically generated during the build
# Name  Id      IPC     IPC Params      File/Cmd
#root   1   pipe    binary      /var/lib/pcp/pmdas/root/pmdaroot
#pmcd   2   dso pmcd_init   /var/lib/pcp/pmdas/pmcd/pmda_pmcd.so
proc    3   pipe    binary      /var/lib/pcp/pmdas/proc/pmdaproc -d 3
#xfs    11  pipe    binary      /var/lib/pcp/pmdas/xfs/pmdaxfs -d 11
linux   60  pipe    binary      /var/lib/pcp/pmdas/linux/pmdalinux
#pmproxy    4   dso pmproxy_init    /var/lib/pcp/pmdas/mmv/pmda_mmv.so
mmv 70  dso mmv_init    /var/lib/pcp/pmdas/mmv/pmda_mmv.so
#jbd2   122 dso jbd2_init   /var/lib/pcp/pmdas/jbd2/pmda_jbd2.so
#kvm    95  pipe    binary      /var/lib/pcp/pmdas/kvm/pmdakvm -d 95

[access]
disallow ".*" : store;
disallow ":*" : store;
allow "local:*" : all;

当我访问 URL localhost:44323/metrics 时，输出非常丰富，涵盖了许多命名空间，即。 mem、network、kernel、filesys、hotproc 等，但是当我用 Prometheus 抓取它时，工作定义为：

scrape_configs:
  - job_name: 'pcp'
    scrape_interval: 10s
    sample_limit: 0
    static_configs:
      - targets: ['127.0.0.1:44323']

我看到目标状态为 UP，但在控制台中只有这两个度量命名空间可用于查询：hinv 和 mem。我试图从/metrics 页面复制其他指标名称，但查询导致错误：“未找到数据点。”最初我认为问题可能是由于每个目标的样本数限制或采样间隔太小（我最初将其设置为 1s），但 hinv 和 mem 彼此不相邻并且还有其他指标（即文件系统，内核）在它们之间被省略。这可能是什么原因？

【问题讨论】：

标签： performance prometheus metrics

【解决方案1】：

我还没有找到问题的确切原因，但它一定是特定于版本的，因为在我下载并启动最新版本 2.19 后，问题就消失了，并且使用完全相同的配置 Prometheus 正在从目标。

【讨论】：

【解决方案2】：

添加另一个答案，因为我刚刚在另一个环境中再次看到这个问题，其中 Prometheus v.2.19 通过 PMAPI 从 CentOS 7 服务器上的 PCP v.5 提取指标。在 Prometheus 配置文件中，抓取被配置为具有多个指标域的单个作业，即：

- job_name: 'pcp'
  file_sd_configs:
  - files: [...]
  metric_path: '/metrics'
  params:
    target: ['kernel', 'mem', 'disk', 'network', 'mounts', 'lustre', 'infiniband']

当一个指标域出现问题时，通常是 luster 或 infiniband，由于主机上缺少相应的硬件，只收集内核指标，不收集其他指标。

问题已通过将抓取作业拆分为多个作业而得到解决，每个作业只有一个目标，即：

 - job_name: 'pcp-kernel'
  file_sd_configs:
  - files: [...]
  metric_path: '/metrics'
  params:
    target: ['kernel']

- job_name: 'pcp-mem'
  file_sd_configs:
  - files: [...]
  metric_path: '/metrics'
  params:
    target: ['mem']

[...]

这样，即使有一个或所有额外的指标失败，核心域的指标也总是能成功抓取。这样的设置似乎更健壮，但是它使目标状态视图更加繁忙，因为有更多的抓取作业。

【讨论】：