Ubuntu Node.js日志记录哪些重要事件

在 Ubuntu 环境里跑 Node.js 服务，日志到底该记录哪些事儿？这个问题看起来基础，但真到了线上排查问题的时候，很多时候就卡在日志不完整或没记到点上。为了让可观测性和可运维性真正落地，值得把日志的重点放到下面这几类事件上。每条日志尽量都带上时间戳、日志级别、消息体、堆栈信息以及请求上下文——这几样是检索和告警的根基。

核心事件清单

下面这个表格，基本覆盖了生产环境下最重要的几类场景。每一行的字段和级别都可以作为初始模板，实际使用时按业务做微调就好。

日志级别与保留策略

日志级别的划分其实不难，关键是分层清晰、实用至上。标准顺序无非就是 Fatal -> Error -> Warn -> Info -> Debug -> Trace。生产环境一般开 info、warn、error 就够了，调试的时候再临时把 debug 或 trace 打开，千万别在生产环境长期开低级别日志，磁盘和性能都吃不消。每条日志里建议带上时间戳、级别和上下文，方便后续做聚合分析。

日志格式推荐用 JSON 这种结构化方式，对接 ELK、Graylog 或者 Loki 这类集中式系统会更省心。另外要按大小或日期做日志切分并设置保留策略，否则单文件越滚越大，最后磁盘占满就麻烦了。

在 Ubuntu 上的落地与查看方式

落地细节上，有不少值得说的。首先是日志库的选择，Winston、Pino 或 Bunyan 都行，关键是能同时输出到控制台和文件，而且最好支持按日志级别分流。比如 error 级别的单独写一个 error.log，所有日志都写进 combined.log，这样排查的时候清晰很多。

Express 应用的话，建议接上 morgan 来记录 HTTP 访问，另外单独做一个错误中间件来记录异常堆栈，别把错误堆栈和正常请求日志混在一起。如果服务是用 systemd 管的，用 journalctl -u your-node-service 就能实时查看和检索；要是用了 PM2，pm2 logs 加上级别筛选也挺方便。更进一步，把日志接到 ELK 或 Graylog 做集中可视化管理，对关键错误也可以集成 Sentry 这类错误追踪平台，效率会高很多。

关键事件的最小落地示例

最后，挑两个最容易搞错的场景单独说说。第一个是未捕获异常和未处理 Promise 拒绝——这类事件务必记录完整堆栈，并且记录后要安全退出进程，否则状态不一致会造成更隐蔽的问题。第二个是资源与性能预警，比如内存逼近上限、GC 频繁、事件循环延迟过高，这些不能等到系统崩了才去翻日志，应该在阈值触发时就输出 warn 或 error 级别的日志，同时附上当时的采样上下文，比如 heapUsed、rss、gc 统计和 loop delay，这样才能提前干预。