Prometheus 不会从 PCP pmproxy 中抓取所有指标
Prometheus does not scrape all metrics from PCP pmproxy
在装有 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
时,输出非常丰富,涵盖了许多名称空间,即。内存、网络、内核、文件系统、hotproc 等,但是当我用 Prometheus 抓取它时,作业定义为:
scrape_configs:
- job_name: 'pcp'
scrape_interval: 10s
sample_limit: 0
static_configs:
- targets: ['127.0.0.1:44323']
我看到目标状态UP,但是在控制台中只有这两个metric命名空间可以查询:hinv和mem。我试图从 /metrics
页面复制其他指标名称,但查询导致错误:'No datapoints found.' 最初我认为问题可能是由于每个目标的样本数量或采样间隔的限制太小(我最初将其设置为 1s),但 hinv 和 mem 彼此不相邻,它们之间还有其他指标(即文件系统、内核)被省略。这可能是什么原因?
我还没有找到问题的确切原因,但它一定是特定于版本的,因为在我下载并启动最新版本 2.19 之后问题就消失了,并且使用完全相同的配置 Prometheus 正在读取所有指标来自目标。
添加另一个答案,因为我刚刚在另一个环境中再次看到这个问题,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']
当一个度量域出现问题时,通常是 lustre 或 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']
[...]
这样一来,尽管一个或所有额外的指标失败了,但核心领域的指标总是被成功抓取。这样的设置似乎更健壮,但是它使目标状态视图更忙,因为有更多的抓取作业。
在装有 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
时,输出非常丰富,涵盖了许多名称空间,即。内存、网络、内核、文件系统、hotproc 等,但是当我用 Prometheus 抓取它时,作业定义为:
scrape_configs:
- job_name: 'pcp'
scrape_interval: 10s
sample_limit: 0
static_configs:
- targets: ['127.0.0.1:44323']
我看到目标状态UP,但是在控制台中只有这两个metric命名空间可以查询:hinv和mem。我试图从 /metrics
页面复制其他指标名称,但查询导致错误:'No datapoints found.' 最初我认为问题可能是由于每个目标的样本数量或采样间隔的限制太小(我最初将其设置为 1s),但 hinv 和 mem 彼此不相邻,它们之间还有其他指标(即文件系统、内核)被省略。这可能是什么原因?
我还没有找到问题的确切原因,但它一定是特定于版本的,因为在我下载并启动最新版本 2.19 之后问题就消失了,并且使用完全相同的配置 Prometheus 正在读取所有指标来自目标。
添加另一个答案,因为我刚刚在另一个环境中再次看到这个问题,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']
当一个度量域出现问题时,通常是 lustre 或 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']
[...]
这样一来,尽管一个或所有额外的指标失败了,但核心领域的指标总是被成功抓取。这样的设置似乎更健壮,但是它使目标状态视图更忙,因为有更多的抓取作业。