Linux 服务日志排查:journalctl、Nginx、PM2 应该怎么看

日志排查的第一原则

线上服务出问题时,最容易犯的错是只看一个地方。

比如用户反馈“网站打不开”,你只看应用日志,可能什么都没有。因为请求可能根本没打到 Node:

DNS 解析错了
Nginx 没转发
证书过期
服务器被 OOM kill
PM2 进程已经挂了
数据库连接失败但应用没打印清楚

所以排查要分层:

系统层:机器是否正常
  ↓
入口层:Nginx 是否收到请求
  ↓
应用层:PM2 / Node 是否正常
  ↓
业务层:接口和数据库是否正常

不要一上来就改代码。先确认请求到底卡在哪一层。

先看系统层

系统层主要回答三个问题:

机器有没有重启?
有没有 OOM?
CPU、内存、磁盘是否异常?

常用命令:

uptime
free -h
df -h
journalctl --no-pager -n 100

看 OOM:

journalctl --no-pager | grep -i "out of memory"
journalctl --no-pager | grep -i "oom"

如果看到某个进程被 kernel kill,应用日志里通常不会有完整错误。因为进程是被系统直接杀掉的,不是自己优雅退出。

这种情况下,继续盯业务日志没有意义,要先处理内存压力。

再看 Nginx

Nginx 是 Web 服务入口。它能告诉你:

请求有没有到服务器
哪些路径访问最多
是否大量 404/500
上游应用是否连接失败
响应耗时是否异常

常见日志位置取决于安装方式,可能在:

/var/log/nginx/access.log
/var/log/nginx/error.log

或面板环境自己的站点日志目录。

看最近错误:

tail -n 100 /var/log/nginx/error.log

看访问高频路径:

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

看高频 IP:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

这些命令不是为了炫技,而是快速判断:

是正常用户访问慢?
还是某个 IP 在刷接口?
是静态资源 404?
还是后端 API 500?

看 PM2 状态

如果应用用 PM2 管理,先看:

pm2 list
pm2 logs my-blog
pm2 monit

pm2 list 关注:

status 是否 online
restart 次数是否不断增加
memory 是否接近限制
CPU 是否异常

pm2 logs 关注:

启动时报错
数据库连接失败
运行时异常
未捕获 promise rejection

有一个细节:如果 Node 进程在启动前就失败,项目自己的日志可能没有任何内容。此时要看 PM2 daemon 日志,通常在:

~/.pm2/pm2.log

它会记录 Node 启动参数错误、环境变量文件找不到等更早期的问题。

看应用访问日志

如果项目有自己的访问日志,它比 Nginx 更接近业务。

好的访问日志应该能看到:

path
method
status code
response time
IP
user agent
user id
request body 摘要
是否 bot

排查慢接口时,重点看:

今日最慢请求
5xx 错误
同 IP 高频访问同一路径
某个接口耗时是否突然升高

如果 Nginx 显示请求已经转发,PM2 也 online,但用户仍然说慢,应用访问日志通常是最有价值的入口。

四层日志怎么组合判断

场景 1:用户说网站完全打不开

排查顺序:

ping / curl 域名
  ↓
Nginx error.log
  ↓
pm2 list
  ↓
pm2 logs
  ↓
系统 journalctl

如果 Nginx 没收到请求,看域名、DNS、防火墙。
如果 Nginx 收到但 upstream failed,看 PM2 和 Node。
如果 PM2 反复重启,看应用日志和 PM2 daemon 日志。
如果系统有 OOM,先处理内存。

场景 2:只有某个接口很慢

排查顺序:

应用访问日志找慢请求
  ↓
确认 path、耗时、IP
  ↓
看接口内 SQL 或第三方调用
  ↓
看是否被同 IP 高频刷
  ↓
必要时加限流或优化查询

不要先重启服务。重启可能暂时缓解,但也会抹掉部分现场。

场景 3:每天固定时间 CPU 飙升

排查顺序:

journalctl 看定时任务
  ↓
systemctl list-timers
  ↓
看 crontab
  ↓
看备份、索引、包管理器缓存任务

固定时间的问题通常不是用户流量,而是定时任务、备份、系统服务或监控脚本。

日志排查的几个习惯

1. 先看时间线

把用户反馈时间、服务器日志时间、部署时间、重启时间放在一起看。

很多问题一眼就能发现:

20:01 部署
20:03 PM2 重启
20:04 大量 500
20:05 用户反馈打不开

2. 不要只看最后一条错误

最后一条错误可能只是结果,不是原因。比如数据库连接失败前,可能已经有内存不足或配置加载失败。

3. 保存现场

排查前先记录:

当前 PM2 状态
最近错误日志
系统负载
内存和磁盘
慢请求样本

不要一上来就清日志或重启。

4. 区分用户流量和机器人流量

很多小站的异常流量来自爬虫、扫描器和恶意请求。看 UA、IP、路径频率,能避免误判为真实用户问题。

总结

日志排查不是“看到报错就修”,而是先判断问题在哪一层。

一套稳定顺序是:

系统是否正常
Nginx 是否收到请求
PM2 / Node 是否在线
应用访问日志是否有慢请求或错误
数据库和外部依赖是否异常

按层排查,比在代码里乱猜快得多。真正成熟的服务,不是永远不出问题,而是出问题时能快速找到证据。

下次见。

-EOF-