温馨提示×

如何分析Debian Nodejs日志

小樊
42
2026-08-11 22:56:55
栏目: 编程语言

分析 Debian 上的 Node.js 日志,通常可以从日志来源、日志内容、分析工具、常见问题定位四个层面来做。下面给你一个比较系统的实战指南。


一、先搞清楚 Node.js 日志在哪里

1. 应用自身日志

Node.js 应用一般会:

  • 输出到 stdout / stderr
  • 使用日志库(winston、pino、bunyan 等)
  • 写文件到指定目录,例如:
/var/log/myapp/
/opt/app/logs/

常见日志文件:

app.log
error.log
access.log

2. systemd 管理的 Node.js 服务

如果 Node.js 是通过 systemd 运行的(最常见):

journalctl -u your-node-service.service

实时查看:

journalctl -u your-node-service.service -f

查看最近 100 行:

journalctl -u your-node-service.service -n 100

查看某时间段:

journalctl --since "2025-01-01" --until "2025-01-02"

这是 Debian 上最重要的日志入口


3. PM2 管理的 Node.js

如果用的是 PM2:

pm2 logs
pm2 logs app-name

查看错误日志:

pm2 logs --err

日志路径一般在:

~/.pm2/logs/

4. Nginx / Apache 反向代理日志

如果 Node.js 在 Nginx 后面:

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

二、Node.js 日志常见内容分析

1. 错误类型速查

错误 含义
EADDRINUSE 端口被占用
ECONNREFUSED 连接被拒绝
ETIMEDOUT 请求超时
ENOENT 文件不存在
ERR_HTTP_HEADERS_SENT 重复响应
Cannot find module 依赖缺失

2. 堆栈信息怎么看

Error: connect ECONNREFUSED 127.0.0.1:3306
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:xxx)

重点看:

  • 最上面一行(错误原因)
  • 最下面几行(错误发生位置)
  • 是否是数据库 / Redis / 第三方接口

三、常用分析命令(Debian / Linux)

1. 查找错误

grep -i error app.log
grep -i exception app.log
grep -i "failed" app.log

2. 查看最近日志

tail -n 200 app.log
tail -f app.log

3. 统计错误数量

grep -c "Error" app.log

4. 按时间过滤

awk '/2025-01-01 10:/,/2025-01-01 11:/' app.log

四、结构化日志分析(推荐)

1. 如果是 JSON 日志(pino / winston json)

cat app.log | jq .

筛选错误:

cat app.log | jq 'select(.level=="error")'

五、性能 & 异常问题定位思路

1. 服务频繁重启

  • 看 systemd / PM2 日志
  • 是否内存溢出(OOM)
  • 是否有未捕获异常
dmesg | grep -i oom

2. 请求慢 / 超时

  • 看 access 日志响应时间
  • Node.js 是否阻塞(同步 IO)
  • 数据库慢查询

3. 内存泄漏

长期运行后:

  • RSS 内存增长
  • GC 频繁

可配合:

node --inspect

六、推荐日志最佳实践(避免以后难分析)

✅ 使用结构化日志(JSON)
✅ 区分 info / warn / error
✅ 日志中带 requestId / traceId
✅ 错误日志必须包含堆栈
✅ 不要只 console.log


七、快速排查流程(实战)

# 1. 看服务状态
systemctl status your-node-service

# 2. 看 systemd 日志
journalctl -u your-node-service -n 100

# 3. 看应用日志
tail -f /var/log/myapp/error.log

# 4. 看系统资源
htop
df -h

如果你愿意,可以把一段真实日志贴出来(或脱敏后),我可以帮你逐行分析具体错误原因

0