如何监控多个进程的存活和CPU、内存占用

对于很多偏传统的企业，业务还没有大规模运行在 Kubernetes 上，也没有为应用做完整埋点。此时，进程监控仍然是稳定性建设中很基础的一环：至少要知道关键进程是否存活，以及 CPU、内存、句柄、IO 等资源占用是否异常。

本文分享使用夜莺监控开源项目和 Categraf 来构建这个监控能力。

本文要解决的问题

本文围绕一个具体目标展开：用 Categraf 的 procstat 插件采集多个进程的监控指标，通过夜莺查看数据并配置告警。

核心流程如下：

部署 VictoriaMetrics 作为时序数据库。
部署夜莺监控，并把写入目标配置为 VictoriaMetrics。
部署 Categraf，将采集数据上报到夜莺。
配置 Categraf procstat 插件，监控 victoria-metrics-prod 和 n9e 两个进程。
使用 procstat_lookup_count < 1 判断进程是否存活。

夜莺监控简介

夜莺产品架构图

夜莺监控（Nightingale）是一款侧重告警的监控类开源项目。类似 Grafana 的数据源集成方式，夜莺也是对接多种既有的数据源，不过 Grafana 侧重在可视化，夜莺是侧重在告警引擎、告警事件的处理和分发。

夜莺监控项目，最初由滴滴开发和开源，并于 2022 年 5 月 11 日，捐赠予中国计算机学会开源发展委员会（CCF ODC），为 CCF ODC 成立后接受捐赠的第一个开源项目。

其开源仓库地址：

后端(主仓库)：https://github.com/ccfos/nightingale
前端：https://github.com/n9e/fe

虽然夜莺的侧重点是告警，但也支持基本的看图能力。为了让链路更短，本文不额外引入 Grafana，告警和看图都用夜莺完成。

需要注意的是，夜莺没有内置时序数据存储能力，监控数据需要写入单独的时序库。本文使用 VictoriaMetrics 作为 TSDB，因为它和 Prometheus 接口兼容，也支持集群版本。

Categraf 简介

Categraf 是一个开源采集器，集成了数十种采集插件，覆盖机器 CPU、内存、磁盘、网络、IO、进程等常规采集能力，也集成了 MySQL、Redis、Postgres、Oracle、Tomcat 等常见数据库和中间件的采集能力。

Categraf 的代码仓库地址是：https://github.com/flashcatcloud/categraf

Categraf 采集了监控数据之后，要推送给服务端，使用 Prometheus Remote Write 协议。很多后端存储都支持这个协议。所以，Categraf 可以直接推送监控到 Prometheus、VictoriaMetrics，也支持把数据写到夜莺监控（Nightingale），再由夜莺把数据转存到后端时序库。

本文介绍进程监控，所以重点使用 Categraf 的 procstat 插件。

部署 VictoriaMetrics 时序库

如果你已经部署过 VictoriaMetrics 或者 Prometheus 了，可以跳过这一步。

VictoriaMetrics 也是开源的，开源项目的发布包通常在 releases 页面，所以，VictoriaMetrics 的发布包下载地址就是：

https://github.com/VictoriaMetrics/VictoriaMetrics/releases

本文演示时使用 v1.123.0 社区版。后缀带有 enterprise 的发布包是企业版；演示场景使用社区版即可。我是 arm64 环境，所以下载 arm64 发布包：

victoria-metrics-linux-arm64-v1.123.0.tar.gz

解压缩会发现，里边只有一个 victoria-metrics-prod 二进制，真省事。

通过如下命令可以直接启动 VictoriaMetrics：

./victoria-metrics-prod

默认会监听在 8428 端口。VictoriaMetrics 各类参数都是通过命令行参数来控制的，可以通过查看其 help 信息了解具体有哪些参数：

./victoria-metrics-prod --help

这里是演示，所以直接前台启动进程。如果用于生产环境，建议使用 systemd 或 supervisor 等方式托管。

部署夜莺监控

夜莺监控的发布包和 VictoriaMetrics 一样，都是在 github releases 页面：

https://github.com/ccfos/nightingale/releases

本文演示时使用 v8.2.2，我是 arm64 环境，所以下载：n9e-v8.2.2-linux-arm64.tar.gz。

实际上，夜莺也可以跑在 Windows 或者 Mac 上面，只是官方没有提供默认的发布包，需要自行编译了。

使用如下命令解压缩：

mkdir n9e
tar zxvf n9e-v8.2.2-linux-arm64.tar.gz -C n9e

然后进入 n9e 目录直接启动就可以了：

./n9e

默认监听在 17000 端口，可以使用浏览器访问 WEB UI，默认用户名是 root，默认密码是 root.2020。

之所以可以一键启动，是因为默认使用 sqlite 存储，默认使用 miniredis 做缓存。如果是生产环境，请使用单独的 MySQL 和 Redis。MySQL 和 Redis 的连接配置在 n9e 二进制同级目录下的 etc/config.toml 里。

配置文件里各项是什么含义，请参考：夜莺配置文件详解。

Ctrl + C 先把刚才的夜莺进程停掉，咱们修改一下 etc/config.toml 中的时序库地址，改成刚才启动的 VictoriaMetrics 的地址：

[[Pushgw.Writers]]
Url = "http://127.0.0.1:8428/api/v1/write"

127.0.0.1:8428 是我刚部署的 VictoriaMetrics 的地址，请你根据自身环境调整具体的 IP 和端口。

这个配置的含义是：夜莺接收到 Categraf 上报的监控数据之后，转存到这个地址指向的时序库。

重启夜莺进程：

./n9e

这里仍然是演示用法，直接前台启动。如果用于生产环境，建议使用 systemd 或 supervisor 等方式托管。

服务端搞定了，接下来搞客户端。

部署 Categraf

Categraf 需要部署在所有要监控的目标机器上。其发布包的下载地址是：

https://github.com/flashcatcloud/categraf/releases

本文演示时使用 v0.4.14，所以下载：categraf-v0.4.14-linux-arm64.tar.gz。

解压缩，修改 Categraf 的主配置文件：conf/config.toml。这里核心是要修改 writers 部分：

[[writers]]
url = "http://127.0.0.1:17000/prometheus/v1/write"

我的测试环境里，Categraf 和夜莺是在一台机器上的，所以连接地址写的是 127.0.0.1，如果你不在一台机器上，请根据自身情况做调整。

接下来我们用如下命令做个测试，看看 Categraf 能否启动并采集系统基础指标：

./categraf --test --inputs system

我的环境里输出如下内容：

$ ./categraf --test --inputs system
2025/08/08 12:14:48 main.go:151: I! runner.binarydir: /home/ulric/demo/categraf-v0.4.14-linux-arm64
2025/08/08 12:14:48 main.go:152: I! runner.hostname: ubuntu
2025/08/08 12:14:48 main.go:153: I! runner.fd_limits: (soft=1048576, hard=1048576)
2025/08/08 12:14:48 main.go:154: I! runner.vm_limits: (soft=unlimited, hard=unlimited)
2025/08/08 12:14:48 provider_manager.go:60: I! use input provider: [local]
2025/08/08 12:14:48 prometheus_agent.go:19: I! prometheus scraping disabled!
2025/08/08 12:14:48 ibex_agent.go:19: I! ibex agent disabled!
2025/08/08 12:14:48 agent.go:38: I! agent starting
2025/08/08 12:14:48 metrics_agent.go:323: I! input: local.system started
2025/08/08 12:14:48 agent.go:46: I! [*agent.MetricsAgent] started
2025/08/08 12:14:48 agent.go:49: I! agent started
1754626488 12:14:48 system_load5 agent_hostname=ubuntu 0.11
1754626488 12:14:48 system_load15 agent_hostname=ubuntu 0.09
1754626488 12:14:48 system_n_cpus agent_hostname=ubuntu 8
1754626488 12:14:48 system_load_norm_1 agent_hostname=ubuntu 0.0075
1754626488 12:14:48 system_load_norm_5 agent_hostname=ubuntu 0.01375
1754626488 12:14:48 system_load_norm_15 agent_hostname=ubuntu 0.01125
1754626488 12:14:48 system_uptime agent_hostname=ubuntu 1134501
1754626488 12:14:48 system_load1 agent_hostname=ubuntu 0.06

表示一切正常。然后通过如下命令启动 Categraf：

./categraf

注意，测试时加了 --test 参数。测试模式不会把采集数据上报服务端，只会打印在本地控制台。正式启动时要去掉 --test 参数。

另外，Categraf 的 conf 目录下有很多 input. 开头的配置目录，每个目录对应一个采集插件。通常如果各类系统指标都想采集，可以保持这些配置目录不动；如果只想启用部分插件，可以删除不需要的插件配置目录。

我上面的操作是直接启动了 Categraf，各类 CPU、内存之类的指标也就会被采集到。那我们去夜莺里查看一下相关数据看看。

配置数据源查看数据

首先，把刚才的 VictoriaMetrics 作为数据源配进来，这点跟 Grafana 很像：

VictoriaMetrics 数据源配置

把 VictoriaMetrics 的地址配置到 URL 里。

VictoriaMetrics URL

然后到 指标-即时查询，即可查询 Categraf 采集的监控数据。

夜莺-指标-即时查询

配置进程监控

Categraf 监控进程使用 procstat 插件，配置文件在 conf/input.procstat/procstat.toml。假设要监控 victoria-metrics-prod 进程和 n9e 进程，可以使用下面的配置：

[[instances]]
search_exec_substring = "victoria"
gather_total = true
gather_per_pid = true
gather_more_metrics = [
    "threads",
    "fd",
    "io",
    "uptime",
    "cpu",
    "mem",
    "limit",
]

[[instances]]
search_exec_substring = "n9e"
gather_total = true
gather_per_pid = true
gather_more_metrics = [
    "threads",
    "fd",
    "io",
    "uptime",
    "cpu",
    "mem",
    "limit",
]

然后通过如下命令可以测试能否采集到数据：

./categraf --test --inputs procstat

采集到的一些关键指标如下：

procstat_lookup_count 进程数量，如果为 0，表示对应的进程挂了
procstat_rlimit_num_fds_soft 进程的软限制句柄数，如果是 1024，通常表示系统参数没有调优好
procstat_cpu_usage_total 进程 CPU 使用率
procstat_mem_usage_total 进程内存使用率
procstat_num_fds_total 进程打开的文件句柄数
procstat_read_bytes_total 进程读取的总字节数
procstat_write_bytes_total 进程写入的总字节数

机器上的进程数量很多，还有很多内核进程。要采集哪些进程，需要告诉 Categraf 如何过滤，也就是几个 search 相关配置：

search_exec_substring 相当于拿 readlink -e /proc/<pid>/exe 与 search_exec_substring 的内容做字符串匹配，如果匹配上了，就采集这个进程的信息
search_cmdline_substring 相当于拿 cat /proc/<pid>/cmdline 与 search_cmdline_substring的内容做字符串匹配，如果匹配上了，就采集这个进程的信息
search_win_service 用于 windows 机器，表示要监控的 windows 服务名字, 当然 windows 机器上也可以用 search_exec_substring 或者 search_cmdline_substring 来做进程筛选

配置完成后，到夜莺中查看相关数据是否能够正常查到：

夜莺监控指标查询-绘图

一切正常后，就可以对这些数据配置告警和仪表盘。进程存活监控最重要的告警规则是：

procstat_lookup_count < 1

含义是：要采集的进程数量为 0，即目标进程没有被匹配到，需要告警。

指标	用途
`procstat_lookup_count`	判断目标进程是否存在
`procstat_cpu_usage_total`	观察目标进程 CPU 使用率
`procstat_mem_usage_total`	观察目标进程内存使用率
`procstat_num_fds_total`	观察目标进程打开的文件句柄数
`procstat_read_bytes_total` / `procstat_write_bytes_total`	观察目标进程 IO 读写量

后记

对于 SRE 或对稳定性比较在意的 DEV 人员，进程监控是最基础也最容易落地的监控能力。本文这套配置的关键点是：先打通夜莺、Categraf、VictoriaMetrics 的数据链路，再用 procstat 明确进程匹配方式，最后用 procstat_lookup_count < 1 兜住进程存活风险。

FAQ

Q1：进程监控适合哪些场景？ A：适合尚未全面使用 Kubernetes、应用埋点不足、但需要监控关键服务进程是否存活的场景。

Q2：search_exec_substring 和 search_cmdline_substring 怎么选？ A：如果进程可执行文件路径稳定，优先用 search_exec_substring；如果需要按启动参数区分多个同名进程，可以用 search_cmdline_substring。

Q3：测试模式为什么看到了指标，但夜莺里没有数据？ A：./categraf --test 只会在本地打印采集结果，不会上报服务端。正式上报时需要去掉 --test 参数。