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

对于很多偏传统的企业，尚未大规模应用 Kubernetes 技术，也没有为应用埋点，此时进程监控就很关键了。最典型的需求就是监控进程的存活性和进程的资源（CPU、内存等）占用。

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

夜莺监控简介

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

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

其开源仓库地址：

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

虽然夜莺的侧重点是告警，但是也支持基本的看图能力，基本够用，为了省事就不引入 Grafana 等其他看图工具了，告警、看图都用夜莺来搞。

但是注意，夜莺没有内置时序数据存储能力，即监控数据的存储需要单独找一个时序库，目前业内情况来看，最推荐的是 VictoriaMetrics，和 Prometheus 接口兼容、性能好、支持集群版本。待会演示的时候我们就用 VictoriaMetrics 来作为时序库（TSDB）。

Categraf 简介

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

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

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

今天我们介绍进程监控，就使用 Categraf 来做。待会做具体演示。

下面进入安装环节，先安装时序库。

部署 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 上报的监控数据之后，转存到这个地址指向的时序库。

OK，重启启动夜莺进程：

./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 的地址配置到 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 来做进程筛选

OK，我们去查看一下相关数据是否能够正常查到：

一切正常。后面就可以对这些数据配置告警、配置仪表盘了。最重要的告警规则是：

procstat_lookup_count < 1

即，要采集的进程数量为 0，即进程挂了，需要告警。

后记

对于 SRE 或对稳定性比较在意的 DEV 人员，监控系统绝对是必备利器。希望本文对大家有所帮助。