Debian Node.js 日志格式有哪些特点

Debian 上 Node.js 日志格式的特点

先说一句大实话：在 Debian 上跑的 Node.js，其实并没有一个统一的“系统级”日志格式。日志长什么样，完全取决于应用本身以及它用的框架、库。常见的做法是：开发环境里，怎么方便读怎么来，文本日志是主流；到了生产环境，就得考虑怎么方便机器采集和检索了，JSON 结构化日志就成了首选。再加上合理的日志级别、准确的时间戳、必要的请求上下文，一套能排序、能过滤、能聚合的日志体系就搭起来了。

常见日志格式与适用场景

• 文本行日志（开发/调试常客）
  典型要素：时间戳、日志级别、消息，有时还会带上文件:行号。特点很鲜明——人读起来特别顺眼，本地排查问题的时候一目了然。但机器解析起来就有点费劲了，成本高。
• JSON 结构化日志（生产环境推荐）
  典型要素：timestamp、level、msg、pid、hostname，还可以扩展 requestId、userId、duration、stack 等上下文。它的优势在于，丢到 ELK 这类集中式日志平台里，检索、聚合、可视化都特别顺手，对可观测性非常友好。
• HTTP 请求日志（Express + morgan 常见组合）
  内置格式有 dev、combined、common、short、tiny 等，字段覆盖了方法、路径、状态码、响应时间、UA 等等。好处是接入快，粒度可调，而且通常跟应用日志分开存放，便于做访问分析。

字段与结构的通用做法

• 时间戳：优先用 ISO 8601 格式，或者跟 syslog 保持一致，这样跨系统排序和解析都不容易出问题。
• 日志级别：遵循 FATAL/ERROR/WARN/INFO/DEBUG/TRACE 这套语义，生产环境一般会把级别调高一些，减少不必要的噪声。
• 上下文扩展：在 JSON 里带上 requestId、traceId、userId、耗时等信息，方便做链路追踪和性能分析。
• 安全合规：密码、密钥、敏感个人信息这些绝对不能记，必要的时候要脱敏，做到最小化输出。

输出、轮转与运维特征

• 多目标输出：同时往控制台和文件里写，比如 error.log 和 combined.log 分开，这样本地调试和持久化归档两不误。
• 日志轮转：用 pm2-logrotate 或者 logrotate 按日或者按大小切割，防止单个文件过大，拖累 I/O 和检索效率。
• 异步与非阻塞：尽量采用异步日志或者高性能的日志库，减少对业务线程的干扰。
• 集中式管理：把日志统一送到 ELK 或兼容的系统里，实现统一检索、告警和可视化。