半泽和莉娜上周帮朋友排查一台CentOS 7.9上的内部网关，服务凌晨三点悄悄退出，systemd把它标记成failed，但因为没有人盯控制台，第二天早上整个链路断了好几个小时才被发现。这种场景我见过太多次了。不是服务本身多难维护，而是systemd其实把状态、日志、资源占用全都摆在那里，关键是你有没有一套顺手的方法去实时盯住它。
这篇文章就围绕systemd服务的实时监控展开，把我平时真正在用的命令组合、脚本思路、踩坑记录整理出来。适合运维、后端开发、以及所有自己维护Linux服务器的同学。不管你是刚接触systemd的新手，还是已经在生产环境摸爬滚打的老手，里面应该都有你能直接拿走用的东西。
1. 先搞清楚监控目标：systemd服务到底要盯什么
很多人一说到监控systemd服务，第一反应就是“服务挂了没有”，然后写个脚本判断 systemctl is-active 是不是active。这个思路没错，但太粗糙了。实时监控的关键不只是知道服务死没死，而是要能在它“快死”、“假死”、“半死不活”的时候提前发现问题。
1.1 服务生命周期状态：不只是active/inactive
systemd把unit的状态拆得很细，systemctl status 里会显示两行：Loaded和Active。Loaded描述unit文件有没有被正确加载，Active描述服务当前处于什么生命周期阶段。Active这一行除了active（running），还有active（exited）、active（waiting）、inactive（dead）、failed、activating、deactivating。每种状态背后的含义完全不同。
我举个例子，active（exited） 这个状态很容易被误判。它表示服务进程正常退出了，但systemd认为这是“预期行为”，所以不算故障。像一些oneshot类型的服务，执行完任务退出，显示的就是这个状态。如果你只判断“不是active就是挂了”，那就误报了。反过来，activating 表示服务正在启动过程中，但如果一个服务长时间停留在activating，那很可能是启动脚本卡住了，这时候进程还活着，但服务实际上已经不可用。
1.2 依赖关系与目标（target）视角
systemd服务的另一个特点是有依赖关系。一个服务挂了，可能连带一票服务起不来。很多人在单个服务上盯了半天，没发现问题，实际上根源在它的依赖上。systemctl list-dependencies 能列出服务的依赖树，systemd-analyze critical-chain 能告诉你当前启动路径上最耗时的环节。
从监控的角度看，我建议定期（比如每天一次）跑一遍 systemctl list-dependencies --reverse，看看哪些服务依赖你负责的核心服务。这样一旦核心服务抖动，你能提前知道影响面有多大，而不是等下游服务全挂了才去一个一个查。
1.3 日志与资源消耗：状态的“隐性指标”
服务状态是“果”，日志和资源消耗是“因”。一个服务反复重启，systemctl status 里可能只看到 active (running)，但 journalctl 里全是报错。不盯日志，你根本不知道它在“带病运行”。
systemd通过CGroup统计服务的资源使用情况。systemctl status 里会直接显示Tasks、Memory、CPU占用，这些数据背后是CGroup在实时统计。对于内存泄漏类问题，盯住Memory这个字段的涨势比看什么监控图都直观。我踩过的坑是，某些服务在内存涨到一定程度后，会被OOM Killer干掉，systemd自动拉起，然后继续涨，形成一个循环。只看status永远都是active，但看Memory曲线就能发现规律。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 实时监控三板斧：systemctl、journalctl、watch的配合
systemd生态里最常用的实时监控工具就是systemctl和journalctl，但很多人只用了它们最基本的功能。其实把watch命令和它们组合起来，就能形成一套不需要装任何额外软件就能用的实时监控方案。
2.1 systemctl status：用好这个被低估的入口
systemctl status 显示的信息非常丰富，但很多人只瞟一眼Active那行就完事了。我建议你仔细看这几个字段：
bas复制