Ubuntu 上 Node.js 日志分析实操指南
一 定位与查看日志
- 常见位置与方式
- 应用自定义日志：项目目录下的 logs/（如 app.log、error.log），或在代码中由日志库（如 winston、morgan、pino）指定路径。
- PM2 管理：日志集中在 ~/.pm2/logs/（常见为 xxx-out.log、xxx-error.log），可用 pm2 logs 统一查看。
- systemd 服务：使用 journalctl -u your-node-service 查看；部分系统也会写入 /var/log/syslog 或 /var/log/nodejs/（若配置了文件输出）。
- 快速查看与检索命令
- 实时查看：tail -f /path/to/app.log
- 按级别筛选：grep -i “ERROR” error.log
- 最近 N 行：pm2 logs --lines 1000
- 时间窗口：journalctl -u your-node-service --since “10 minutes ago”
- 系统层面：tail -f /var/log/syslog
以上路径与命令适用于大多数 Ubuntu + Node.js 场景，可先定位日志落点，再进入分析环节。
二 常用分析命令与快速定位
- 错误与警告速查
- 统计错误数：grep “ERROR” combined.log | wc -l
- 精确匹配错误并查看上下文：grep -A 10 -B 5 “SpecificError” app.log
- 按时间范围提取：awk ‘/2025-04-01 10:00:00/,/2025-04-01 11:00:00/’ app.log
- 堆栈与未处理异常
- 堆栈定位：grep -n "at " error.log（堆栈行通常以 at 开头，配合行号快速跳转）
- 未处理 Promise：grep -i “UnhandledPromiseRejectionWarning” app.log
- 过时 API 警告：grep -i “DeprecationWarning” app.log
- 请求与性能线索
- URL/状态码统计：awk ‘{print $7, $9}’ access.log | sort | uniq -c | sort -nr | head（假设 $7 为 URL、$9 为状态码）
- 响应时间分布：awk ‘{print $NF}’ access.log | sort -n | tail（假设 $NF 为响应时间，如 ms）
以上命令覆盖错误计数、上下文定位、时间窗口抽取与常见 Node.js 警告筛查，适合快速“从现象到根因”的排查路径。
三 典型问题与修复路径
- 端口被占用 EADDRINUSE
- 查占用：sudo lsof -i :3000
- 释放：sudo kill -9
- 模块缺失 Module not found
- 语法错误 SyntaxError
- 未处理的 Promise
- 为所有 Promise 添加 .catch() 或使用 try/catch；临时兜底可监听：process.on(“unhandledRejection”, …)
- 监听器泄漏 MaxListenersExceededWarning
- 检查重复添加监听，使用 removeListener 或在创建 EventEmitter 时合理设置 setMaxListeners。
- 内存不足 JavaScript heap out of memory
- 临时提升堆上限：node --max-old-space-size=4096 app.js
- 进一步用性能分析工具（如 clinic）定位泄漏点并优化数据结构与缓存策略。
以上问题在 Node.js 生产环境中高频出现，按“定位 → 修复 → 验证”闭环处理即可。
四 结构化与集中化分析
- 日志结构化
- 使用 winston/pino/morgan 输出 JSON 格式，便于检索与聚合；为每条日志附带 timestamp、level、requestId、userId、service 等关键字段。
- 日志轮转
- 使用 logrotate 管理体积，示例（/etc/logrotate.d/nodejs）：
- /var/log/nodejs/*.log { daily; missingok; rotate 7; compress; notifempty; create 0640 root adm }
- 集中式平台
- ELK Stack（Elasticsearch + Logstash + Kibana）：Logstash 用 grok 解析日志并写入 ES，Kibana 建立索引模式与可视化面板。
- 轻量替代：Grafana Loki 或与 Prometheus/Grafana 联动做指标与日志一体化观测。
结构化与集中化能显著提升“多实例、长时间窗口”下的分析效率与可观测性。
五 高效排查流程清单
- 明确时间线与范围：先界定问题发生的时间段与影响范围（单实例/多实例、特定接口）。
- 快速筛查：用 tail -f、grep -i “ERROR”、journalctl --since 观察错误趋势与最新现场。
- 定位根因：结合堆栈跟踪、请求ID与上下文参数，还原调用链，必要时本地复现。
- 修复与回归：修复代码/配置/依赖后，回归验证并观察错误率与延迟是否恢复。
- 预防与优化：完善日志级别与结构化字段，配置轮转与告警，建立仪表盘持续观测。
以上流程强调“先稳现场、再找根因、后防再发”，适合日常运维与线上应急。
