Ubuntu Node.js日志记录哪些重要事件
在Ubuntu环境运行Node.js服务时，日志应记录应用生命周期、HTTP访问、未捕获异常、未处理Promise拒绝、资源性能瓶颈、数据库与缓存、外部依赖、认证授权、安全审计、配置启动问题及定时任务等事件。每条日志需包含时间戳、级别、消息体、堆栈及请求上下文。生产环境启用info、warn、error级别，采用JSON格式，按大小或日期切分并设置保留策略。
在 Ubuntu 环境里跑 Node.js 服务，日志到底该记录哪些事儿？这个问题看起来基础，但真到了线上排查问题的时候，很多时候就卡在日志不完整或没记到点上。为了让可观测性和可运维性真正落地，值得把日志的重点放到下面这几类事件上。每条日志尽量都带上时间戳、日志级别、消息体、堆栈信息以及请求上下文——这几样是检索和告警的根基。
核心事件清单
下面这个表格，基本覆盖了生产环境下最重要的几类场景。每一行的字段和级别都可以作为初始模板，实际使用时按业务做微调就好。
| 事件类别 | 典型场景 | 建议记录字段 | 日志级别 |
|---|---|---|---|
| 应用生命周期 | 启动、就绪、优雅关闭、重启 | pid、版本、端口、启动参数、信号(SIGTERM/SIGINT)、停机耗时 | info |
| HTTP 访问与性能 | 请求到达、响应返回、耗时、状态码 | method、url、status、user-agent、referer、remote-ip、响应时间、content-length、request-id | info（4xx/5xx 可提升为 warn/error） |
| 未捕获异常 uncaughtException | 同步异常未捕获 | error、堆栈、type、time、pid | fatal（记录后建议安全退出） |
| 未处理 Promise 拒绝 unhandledRejection | Promise 无 .catch() | reason、堆栈、promise | error |
| Node.js 运行时警告 | DeprecationWarning、MaxListenersExceededWarning 等 | warning 类型、模块、堆栈、触发位置 | warn |
| 资源与性能瓶颈 | 内存逼近上限、GC 频繁、事件循环延迟高 | heapUsed、rss、external、gc 统计、loop delay、采样点 | warn/error（阈值触发） |
| 数据库与缓存 | 连接失败/超时、查询慢、断连重连 | db/redis 类型、host、port、错误码、耗时、sql/key、重试次数 | error/warn |
| 外部依赖与消息队列 | HTTP 调用失败、第三方 API 异常、MQ 生产/消费失败 | url/队列、状态码/错误码、时延、重试、trace-id | error/warn |
| 身份认证与授权 | 登录成功/失败、令牌无效/过期、权限不足 | user-id/用户名、ip、ua、路径、结果、原因 | info/warn/error |
| 安全与审计 | 暴力登录、可疑输入、权限变更、配置变更 | 事件类型、来源 ip、账号、时间、变更前后快照 | warn/error |
| 配置与启动问题 | 环境变量缺失、配置校验失败、端口被占用 | 缺失项、期望值、实际值、端口占用详情 | error |
| 定时任务与后台作业 | 任务开始/结束、失败重试、超时 | 任务名、开始/结束时间、耗时、结果、错误 | info/error |
日志级别与保留策略
日志级别的划分其实不难，关键是分层清晰、实用至上。标准顺序无非就是 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，这样才能提前干预。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
AirBuddy 3 是面向 macOS 的蓝牙外设增强工具，可集中查看 AirPods、Beats 与苹果设备电量，提供快速连接、播放控制、电量提醒、桌面小组件和多台 Mac 外设接力等功能。
AirServer macOS版可把 Mac 转换为无线投屏接收端，通过 AirPlay 或 Google Cast 接收手机、平板和电脑画面，并支持多设备同时连接、高清镜像及会话录制，适合家庭娱乐、课堂教学、会议演示和应用展示。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
PixTV 是一款在浏览器中使用的 AI 视觉内容创作平台，提供图片、视频、音频、文字生成、AI 分镜、局部重绘、提示词反推和无限画布等工具，适合短剧、漫剧、广告及社交媒体内容制作。
Autodesk Maya 是面向影视、电视、动画和游戏行业的专业三维制作软件，集多边形与 NURBS 建模、角色绑定、关键帧和动作捕捉动画、Bifrost 特效模拟、材质开发及 Arnold 渲染于一体，