systemd 时代，看 Node 服务日志别只盯着 tail

早些年排查线上日志，很多人的第一反应都是 tail -f。我也一样，因为它直接、顺手，而且大多数教程都是这么教的。可 2017 年之后，随着 systemd 越来越常见，我慢慢发现，如果 Node 服务本身就是被 systemd 接管的，只盯着 tail 其实会漏掉很多关键信息。

不是说 tail 不能用，而是它已经不再是唯一入口了。

两种看法各自擅长什么

我后来会这样分：

场景	更顺手的方式
已知日志文件路径，只想持续跟输出	tail -f
想看服务启动、退出、重启记录	journalctl
怀疑是 systemd 拉起失败、权限异常、环境变量没带上	journalctl
想快速回看历史几十行应用日志	两者都行，看部署方式

也就是说，tail 更像“跟着文件走”，journalctl 更像“跟着服务走”。

为什么 Node 服务特别适合结合看

Node 服务有个特点：如果进程起不来、起了就退、或者被 systemd 自动重启，单看日志文件可能根本看不到完整现场。
因为有些失败发生在应用还没来得及把日志写进文件之前，systemd 那一层的信息反而更完整。

例如：

• 启动脚本路径写错
• 工作目录不对
• 环境变量没有注入
• 权限不足导致服务被秒退

这些都不是业务日志最先能表达出来的。

我现在更习惯的排查顺序

如果服务状态异常，我一般不会立刻 tail 某个文件，而是先看服务状态，再决定日志入口。

顺序通常是：

1. 先确认服务是否被 systemd 正常接管
2. 看最近一次启动和退出记录
3. 再根据需要追业务日志文件

这样做的好处是能先搞清楚问题发生在“服务层”还是“应用层”。

tail 仍然有价值，但别把它当唯一视角

我现在依然大量使用 tail，尤其在跟接口日志、Nginx 访问日志时，它依旧非常高效。
但只要问题涉及服务没起来、重启循环、开机自启异常，我就会第一时间想到 journalctl。

工具没变难，视角只是多了一层。
当部署方式变了，排障习惯也该跟着升级。

小结

2017 年之后再看 Linux 上的 Node 服务，我越来越觉得“服务日志”和“文件日志”是两套不同线索。只靠 tail 容易快，但不一定全；把 journalctl 也纳入日常工具箱，很多莫名其妙的启动问题会更快露面。