基于DaemonSet的Process Exporter监控实践指南

导语

作为一名Kubernetes管理员，你是否经历过： ✅ 服务正常却找不到CPU飙升的根本原因？ ✅ 容器进程异常但无法快速定位根源？ ✅ 缺乏完整的进程级监控体系导致故障排查困难？

本文将带你掌握 Process Exporter 的完整使用链路，涵盖基础部署、Prometheus集成、Grafana可视化及告警规则配置，即使是新手也能轻松上手！

一、初识Process Exporter

1.1 什么是Process Exporter？

• 官方出品：Prometheus生态标准exporter
• 轻量级：镜像仅15MB，支持容器/宿主机进程监控
• 核心能力： ✓ 进程CPU/内存占用 ✓ 文件描述符数量 ✓ 线程数与运行时长 ✓ 支持正则表达式过滤进程

1.2 为什么必须用它？

典型业务价值：

• 识别恶意进程占用资源
• 监控Java应用GC行为
• 分析MySQL连接池耗尽原因

1.3 部署控制器选择

• 全节点覆盖：确保每个Worker节点运行监控实例
• 混合监控：同时采集容器进程和宿主机关键服务（如kubelet、sshd）
• 资源占用优化：避免Deployment模式下多副本的资源浪费

二、快速部署Process Exporter

2.1 架构设计图

2.2 部署YAML模板

# 1. 创建RBAC权限
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: process-exporter
rules:
- apiGroups: [""]
  resources: ["nodes/proxy"]
  verbs: ["get", "list", "watch"]
---
# 2. 配置DaemonSet
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: process-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: process-exporter
  template:
    metadata:
      labels:
        app: process-exporter
    spec:
      hostPID: true          # 共享宿主机 PID 命名空间
      hostNetwork: true      # 可选：共享宿主机网络命名空间
      # 添加容忍规则
      tolerations:
      - operator: Exists  # 容忍所有污点
      containers:
      - name: process-exporter
        image: prometheus/process-exporter:v1.7.0
        args:
        - "-procfs=/host/proc"          # 指定宿主机 /proc 路径
        - "-config.path=/etc/process-exporter/config.yaml"
        volumeMounts:
        - name: config-volume
          mountPath: /etc/process-exporter/config.yaml  # 挂载为文件
          subPath: config.yaml                           # 指定子路径
        - name: proc                     # 挂载宿主机的 /proc
          mountPath: /host/proc
          readOnly: true
        ports:
        - containerPort: 9256
        resources:
          limits:
            cpu: "200m"
            memory: "256Mi"
        securityContext:
          capabilities:
            add:
            - SYS_PTRACE                # 允许追踪进程
            - SYS_ADMIN                 # 可选：访问宿主机资源
      volumes:
      - name: config-volume
        configMap:
          name: process-exporter-config
          items:                        # 明确指定 ConfigMap 的键和路径
          - key: config.yaml            # ConfigMap 中的键名
            path: config.yaml           # 挂载到容器内的文件名
      - name: proc
        hostPath:
          path: /proc                   # 宿主机 /proc 目录
---
apiVersion: v1
kind: Service
metadata:
  name: process-exporter
  namespace: monitoring
  labels:
    app: process-exporter  # 必须与 ServiceMonitor 的 selector 匹配
spec:
  ports:
  - port: 9256
    targetPort: 9256
    protocol: TCP
    name: http              # 端口名称必须与 ServiceMonitor 的 endpoints.port 匹配
  selector:
    app: process-exporter   # 关联到 Deployment 的 Pod 标签

2.3 configmap配置

apiVersion: v1
kind: ConfigMap
metadata:
  name: process-exporter-config
  namespace: monitoring
data:
  config.yaml: |
    process_names:
      - name: "{{.Comm}}"       # 进程组名称模板（使用进程名作为标签）
        cmdline:                # 匹配命令行参数的正则表达式
        - '.+'                  # 匹配所有进程

2.4 验证部署

# 查看Pod状态
kubectl get pods -n monitoring -l app=process-exporter

# 测试数据采集
kubectl exec -it <pod-name> -- curl http://localhost:9103/metrics | grep java_process_cpu_seconds_total

三、与Prometheus监控体系集成

3.1 Prometheus Operator自动接入

步骤1：单独创建ServiceMonitor

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: process-exporter
  namespace: monitoring
spec:
  endpoints:
  - port: http
    interval: 15s
    path: /metrics
    relabelings:
    - sourceLabels: [__meta_kubernetes_pod_node_name]
      targetLabel: node  # 自动添加节点标签
  namespaceSelector:
    matchNames:
    - monitoring        # 监控的命名空间
  selector:
    matchLabels:
      app: process-exporter

步骤2：自动化数据同步

Operator会自动完成以下操作： ✅ 创建TargetGroup ✅ 注册到Prometheus Server ✅ 自动生成Recording Rules

3.2 Grafana看板和指标

3.2.1 关键指标

在实际监控进程时，主要使用的指标就是cpu和内存。

• process-exporter中进程的指标以namedprocess_namegroup开头：
• namedprocess_namegroup_cpu_seconds_total：cpu使用时间，通过mode区分是user还是system
• namedprocess_namegroup_memory_bytes：内存占用，通过memtype区分不同的占用类型
• namedprocess_namegroup_num_threads：线程数
• namedprocess_namegroup_open_filedesc：打开的文件句柄数
• namedprocess_namegroup_read_bytes_total：进程读取的字节数
• namedprocess_namegroup_thread_context_switches_total：线程上下文切换统计
• namedprocess_namegroup_thread_count：线程数量统计
• namedprocess_namegroup_thread_cpu_seconds_total：线程的cpu使用时间
• namedprocess_namegroup_thread_io_bytes_total：线程的io

3.2.2 cpu相关

cpu是我们最经常关注的指标，如果使用node-exporter采集节点的指标数据，可以得到机器的cpu占比。

而使用process-exporter采集的是进程的指标，具体来说就是采集/proc/pid/stat中与cpu时间有关的数据：

• 第14个字段：utime，进程在用户态运行的时间，单位为jiffies
• 第15个字段：stime，进程在内核态运行的时间，单位为jiffies
• 第16个字段：cutime，子进程在用户态运行的时间，单位为jiffies
• 第17个字段：cstime，子进程在内核态运行的时间，单位为jiffies

那么通过上述值就可以得到进程的单核CPU占比：

• 进程的单核CPU占比=(utime+stime+cutime+cstime)/时间差
• 进程的单核内核态CPU占比=(stime+cstime)/时间差

因此，进程的单核CPU占比的promsql语句为increase(namedprocess_namegroup_cpu_seconds_total{mode="user",groupname="procname"}[30s])*100/30，单核内核态CPU占比的promsql语句为increase(namedprocess_namegroup_cpu_seconds_total{mode="system",groupname="procname"}[30s])*100/30。

注意：实测发现，process-exporter获取的数据与/proc/pid/stat中的有一定差异，需要进一步看下。

3.2.3 memory

process-exporter采集内存的指标时将内存分成5种类型：

• resident：进程实际占用的内存大小，包括共享库的内存空间，可以从/proc/pid/status中的VmRSS获取
• proportionalResident：与resident相比，共享库的内存空间会根据进程数量平均分配
• swapped：交换空间，系统物理内存不足时，会将不常用的内存页放到硬盘的交换空间，可以从/proc/pid/status中的VmSwap获取
• proportionalSwapped：将可能被交换的内存页按照可能性进行加权平均
• virtual：虚拟内存，描述了进程运行时所需要的总内存大小，包括哪些还没有实际加载到内存中的代码和数据，可以从/proc/pid/status中的VmSize获取

对于一般的程序来说，重点关注的肯定是实际内存，也就是resident和virtual，分别表示实际在内存中占用的空间和应该占用的总空间

3.2.4 看板

process-exporter基于上述指标提供了grafana的面板可以直接导入：https://grafana.com/grafana/dashboards/249-named-processes/

可以看到，面板中的cpu和读写是直接基于指标和rate函数得到的，内存则是直接基于指标而来的。

四、配置说明

proces-exporter的配置包括两部分的配置项，一个是process-exporter的一些参数控制，另一个是进程信息的配置。

一般来说，exporter都会有几部分的参数控制采集：

• config/config.path：指定配置文件路径
• web.listen-address：指定监听端口，通常都会有默认的端口，prometheus就是访问该端口获取指标数据
• web.telemetry-path：指标数据的url，通常都是/metrics

除了有以上配置项之外，process-exporter还有其他特有的配置项：

• children：如果某个进程被采集，那么它的子进程也属于该组
• namemapping：名称映射，
• procfs：proc文件系统的路径，默认是/proc
• procnames：需要采集的进程名列表
• threads：是否采集线程，默认为是

基于性能的考虑，process-exporter只能对事先配置的进程进行指标采集，因此，需要对进程进行过滤，只采集需要的进程的指标。

在过滤进程时，会将进程进行分组，因此，就会有分组的名称，以及将进程放到分组的规则。例如，如果使用deb/rpm安装process-exporter时，默认的配置文件是：

process_names:
  - name: "{{.Comm}}"
    cmdline:
    - '.+'

process_names是个数组，每个成员表示一个分组。

name是分组的名称，这里使用模版。cmdline用于对分组中的进程进行过滤，这里的正则表达式就表示过滤所有进程。

因此，上述配置文件的含义是：采集所有进程的指标数据，当遍历到某个进程时，获取该进程的进程名，然后放到进程名对应的分组。

name字段可以使用固定的字符串，也可以使用以下模版：

• {{.Comm}}：进程名
• {{.ExeBase}}：可执行文件的文件名，与进程的区别是，进程名有长度15的限制
• {{.ExeFull}}：可执行文件的全路径
• {{.Username}}：进程的有效用户名
• {{.Matches}}：用正则匹配cmdline等字段时得到的匹配项的map，例如下面的Cfgfile
• {{.PID}}：pid，使用pid表示这个组只会有这一个进程
• {{.StartTime}}：进程的起始时间
• {{.Cgroups}}：进程的cgoup，可以用于区分不同的容器

进行分组进程过滤除了使用cmdline字段，还可以使用comm和exe，分别表示进程名和二进制路径，并且遵循以下规则：

• 如果使用了多个字段，则必须都匹配，例如，如果既使用了comm，又使用了exe，两个过滤必须都满足
• 对于comm和exe，它们是字符串数组，并且是OR的关系
• 对于cmdline，则是正则表达式数组，并且是AND的关系

例如：

process_names:
  # 进程名过滤，超过15个字符会被截断
  - comm:
    - bash

  # argv[0]，如果开头不是/，说明匹配进程名
  # 如果开头是/，则需要使用二进制路径全匹配
  - exe:
    - postgres
    - /usr/local/bin/prometheus

  # 如果使用多个字段进行匹配，则需要都匹配
  - name: "{{.ExeFull}}:{{.Matches.Cfgfile}}"
    exe:
    - /usr/local/bin/process-exporter
    cmdline:
    - -config.path\s+(?P<Cfgfile>\S+)

# 监控NVIDIA GPU进程
filter:
  - name: gpu-process
    pattern: "^nvidia-smi"
    env: ["NVIDIA_VISIBLE_DEVICES=all"]

五、结语

通过DaemonSet部署的Process Exporter，配合Prometheus Operator和Grafana看板，可构建覆盖 容器进程-宿主机服务-硬件资源 的全维度监控体系。建议按照以下步骤落地：

1. 分阶段实施：从测试环境到生产逐步推进
2. 制定监控SLA：明确不同级别进程的监控指标阈值
3. 定期演练：模拟进程异常验证告警有效性