Node.js在Ubuntu上如何处理日志

Node.js 在 Ubuntu 的日志处理实践

一 日志输出方式与位置

先说一个核心判断：日志处理，第一步得先搞清楚日志往哪儿去。开发调试时，console.log 或 console.error 直接输出到控制台，方便快捷。但到了生产环境，这招就不够看了——你得考虑持久化和分割，这时候，引入一个专业的日志库或者借助进程管理器，就成了标准操作。

那么，市面上有哪些趁手的日志库呢？

• Winston：社区最流行的选择之一，支持多种传输方式，配置起来也直观，能满足绝大多数应用场景。
• Pino：如果你追求极致的性能，尤其是在高并发场景下，Pino 的超低开销优势就凸显出来了。
• Bunyan：它默认输出结构化的 JSON 日志，格式统一，后续做检索和分析会非常省心。
• Log4js：功能相当丰富，配置灵活度极高，适合那些对日志有复杂定制化需求的团队。

日志写好了，它们通常躺在哪儿？不外乎这几个地方：

• 你项目目录下的 logs/ 文件夹，或者自定义的某个路径。
• 系统级的 /var/log/ 目录，如果你的应用是以系统服务的形式运行，放在这里更符合运维规范。
• 如果你用了 PM2 来管理进程，那日志默认会在 $HOME/.pm2/logs/ 下，比如 app-out.log 和 app-err.log，分门别类，一目了然。

查看和分析这些日志，是日常基本功。用 tail -f /path/to/file.log 可以实时追踪最新动态；用 less 或 cat 则可以翻阅历史。一旦发现异常，重点要关注错误类型、具体消息和完整的堆栈跟踪，这才是定位问题的关键线索。

二 日志轮转与保留策略

日志文件可不能放任它无限增长。否则，不仅占满磁盘，查找历史记录也会变成噩梦。因此，一套清晰的轮转与保留策略必不可少。

轮转通常可以从两个层面入手：

应用内轮转：对于 Node.js 应用，可以使用像 winston-daily-rotate-file 这样的库。它能帮你按天或者按文件大小自动切分日志，同时控制保留的文件数量。这样做的好处是，回滚到某个时间点的日志，或者进行归档，都变得非常方便。

系统级轮转：这是更通用、更规范的运维手段，使用 Linux 系统自带的 logrotate 工具。它可以统一管理所有服务的日志，执行轮转、压缩和清理。下面是一个典型的 Node.js 应用日志轮转配置示例（通常放在 /etc/logrotate.d/nodejs）：

• 路径：/var/log/nodejs/*.log
• 策略：
  • daily：每日轮转一次。
  • rotate 7：保留最近 7 天的日志文件。
  • compress：轮转后的旧日志用 gzip 压缩，节省空间。
  • missingok：如果日志文件缺失，不报错。
  • notifempty：空文件就不进行轮转。
  • create 0640 root adm：轮转后创建的新日志文件，设置权限为 0640，所属用户和组为 root 和 adm。

三 进程管理与系统日志集成

在现代部署中，Node.js 应用很少“裸跑”，通常会由专门的进程管理器或系统服务来托管。这直接影响了日志的收集和管理方式。

使用 PM2：这可能是 Node.js 生态中最流行的进程管理工具了。安装全局包后，用 pm2 start app.js --name my-app 启动应用。查看日志尤其方便，一句 pm2 logs my-app 就能实时聚合显示标准输出和错误输出，并且 PM2 自身也支持日志文件分割和添加时间戳。

使用 systemd：在 Ubuntu 上，将 Node.js 服务托管为 systemd 服务是更原生、更稳定的方式。这时，应用只需将日志输出到 stdout/stderr，systemd 的 journal 会负责捕获。查看日志就交给了 journalctl 命令：

• 实时跟踪：journalctl -u your-nodejs.service -f
• 按时间筛选：journalctl -u your-nodejs.service --since “2025-11-24 00:00:00”

与 Rsyslog 集成：对于更复杂的架构，比如需要将多个服务的日志集中处理，可以将应用日志发送到系统的 Rsyslog。由 Rsyslog 统一进行过滤、转发和存储，非常适合微服务场景下的日志集中化治理。

四 结构化与集中式日志

当应用数量增多，原始的文本日志就显得力不从心了。这时，需要向更高级的日志管理方式演进。

结构化日志：这是第一步，也是至关重要的一步。放弃难以解析的纯文本，改用 Winston、Pino、Bunyan 等库输出 JSON 格式的日志。在每条日志中固定包含 timestamp（时间戳）、level（日志级别）、service（服务名）、trace_id（追踪ID）等字段。这样一来，无论是用 grep 简单查找，还是用专业工具进行聚合分析和链路追踪，效率都会成倍提升。

集中式日志：单机日志看得再明白，也解决不了分布式系统的问题。因此，需要将来自所有服务器的结构化日志，收集到一个中心平台。ELK Stack（Elasticsearch, Logstash, Kibana） 或 Graylog 是经典组合。它们能实现跨服务的统一检索、实时可视化以及设置告警。如果日志量非常大，还可以在应用和日志收集器之间引入 Kafka 这类消息队列作为缓冲，削峰填谷，保证稳定性。

监控与可视化联动：必须警惕的是，日志不是孤立的。它应该与系统监控指标联动。结合 Prometheus 收集应用指标（如请求延迟、错误率、内存/CPU使用情况），再用 Grafana 进行可视化展示。当监控图表发现异常时，能快速关联查询到对应时间段的详细日志，这才是高效故障排查的完整闭环。

五 快速上手示例

理论说了这么多，不如看一段实际代码来得直观。这里以 Winston 为例，展示如何快速配置一个既能写文件、又能区分错误日志的 logger。

首先，安装依赖：npm install winston

接着，创建并配置日志器：

const winston = require(‘winston’);
const logger = winston.createLogger({
    level: ‘info’,
    format: winston.format.json(),
    transports: [
        new winston.transports.File({ filename: ‘error.log’, level: ‘error’ }),
        new winston.transports.File({ filename: ‘combined.log’ })
    ]
});
if (process.env.NODE_ENV !== ‘production’) {
    logger.add(new winston.transports.Console({ format: winston.format.simple() }));
}
logger.info(‘Server started on port 3000’);
logger.error(‘Database connection failed’);

这段配置做了几件事：将错误级别及以上的日志单独写入 error.log，将所有级别（info及以上）的日志写入 combined.log，并且在非生产环境时，同时在控制台输出简化格式的日志。

代码运行后，在项目目录下执行 tail -f combined.log 或 tail -f error.log，就能实时看到日志输出了。从这开始，你的 Node.js 应用就有了一个可靠、可管理的日志基础。