CentOS Node.js日志如何处理

CentOS 上 Node.js 日志处理最佳实践

一 日志采集与输出

日志处理的第一步，是从源头做好采集。在应用内部，直接使用成熟的日志库是最高效的选择。目前社区主流的Winston、Bunyan和Log4js都是不错的选择，它们能帮你轻松实现日志分级、结构化输出（比如JSON格式）以及多目标投递（控制台、本地文件、远程服务）。

以Winston为例，上手非常快：

• 安装：一句 npm i winston 就能搞定。
• 配置：核心在于创建一个Logger实例，定义好日志级别、格式和输出目的地。下面是一个典型的配置示例：

  const winston = require(‘winston’);
  const logger = winston.createLogger({
    level: ‘info’,
    format: winston.format.combine(
      winston.format.timestamp(),
      winston.format.json()
    ),
    transports: [
      new winston.transports.Console(),
      new winston.transports.File({ filename: ‘/var/log/myapp/app.log’ })
    ]
  });

这里有个关键点：强烈建议使用JSON等结构化格式。这看似增加了日志体积，却为后续的检索、分析和可视化铺平了道路，长远来看省时省力。至于日志级别，生产环境通常设为 info 来平衡信息量和性能，调试阶段则可以临时切换到 debug。

二 日志轮转

日志文件不能任其无限增长，否则迟早会撑爆磁盘。因此，轮转（Rotate）机制必不可少。这里有几种主流方案，可以根据你的部署环境来选择。

1. 系统级方案 logrotate（推荐）

这是最经典、最通用的方案，CentOS通常已经预装。

• 安装：如果尚未安装，执行 sudo yum install -y logrotate。
• 配置：在 /etc/logrotate.d/ 目录下为你的应用新建一个配置文件，例如 sudo vim /etc/logrotate.d/nodejs-app。
• 示例配置：下面这个配置实现了按天轮转、保留最近7份、自动压缩归档，并且能很好地处理Node.js应用持续写入文件句柄的问题：

  /var/log/myapp/*.log {
      daily
      rotate 7
      compress
      missingok
      notifempty
      create 0640 node node
      copytruncate
      dateext
  }

• 关键参数说明：
  • copytruncate：这个参数至关重要。它先复制原日志文件内容进行归档，然后清空原文件，避免了因重命名日志文件导致Node.js进程持有的文件句柄失效，通常无需重启应用。如果你的应用支持接收信号（如SIGUSR1）来重新打开日志文件，则可以去掉此参数，改用postrotate脚本发送信号。
  • dateext：为归档文件添加日期后缀（如 .log-20231001.gz），让文件时序一目了然。
• 测试：配置完成后，可以用 sudo logrotate -f /etc/logrotate.d/nodejs-app 命令立即测试一次，检查轮转和压缩是否按预期工作。

2. 进程管理方案 PM2 内置日志轮转

如果你的Node.js应用是使用PM2来管理的，那么利用其生态插件会更方便。

• 安装插件：pm2 install pm2-logrotate
• 常用策略设置：
  • pm2 set pm2-logrotate:max_size 10M （单个日志文件最大10M）
  • pm2 set pm2-logrotate:retain 7 （保留7个归档）
  • pm2 set pm2-logrotate:compress true （启用压缩）
  • pm2 set pm2-logrotate:rotateInterval “0 0 * * *” （每天零点轮转）

这套方案会自动管理 ~/.pm2/logs/ 目录下的日志文件，对于PM2部署场景来说，集成度最高，几乎无需额外配置。

3. 应用内轮转（备选）

对于一些特殊环境，比如容器化部署且没有Systemd，或者需要更精细的控制，可以考虑在应用代码层面实现轮转。使用像 winston-daily-rotate-file 这样的库，可以按日期或文件大小自动切分日志。不过，这种方式需要开发者自己处理好进程内的文件句柄管理，对代码有一定侵入性，通常作为前两种系统级方案的补充或备选。

三 集中式日志与远程传输

当服务器数量增多时，登录每一台机器去看日志就变成了噩梦。这时，就需要将日志集中起来。

1. 使用 rsyslog 进行远程传输

这是Linux系统自带的强大工具，配置简单，适合中小规模场景。

• 服务端：确保rsyslog服务已启用UDP 514端口监听，并重启服务：sudo systemctl restart rsyslog。
• 客户端：在Node.js服务器上，编辑 /etc/rsyslog.d/nodejs.conf，添加一行转发规则：

  *.* @remote_log_server_ip:514

  这表示将所有设施和级别的日志通过UDP发送到远程服务器。
• 应用侧集成：你甚至可以不写文件，直接使用 winston-syslog 传输器，将日志从Node.js应用实时发送到本地的syslog守护进程，再由其转发。

2. 引入完整的日志栈

对于大规模、多服务的生产环境，一套功能完备的集中日志系统是标配。ELK Stack（Elasticsearch, Logstash, Kibana）或 Graylog 是业界常见的选择。它们不仅能海量存储日志，更能提供强大的全文检索、实时分析和可视化仪表盘功能，让从海量日志中定位问题变得高效。

四 清理与维护

日志系统建立后，持续的维护同样重要，否则可能引发新的问题。

1. 自动清理

虽然logrotate会压缩旧日志，但长期积累的 .gz 归档文件也会占用空间。可以设置一个cron任务，定期清理过期的归档文件：

0 0 * * * find /var/log/myapp -type f -name “*.gz” -mtime +7 -delete

这个任务每天零点执行，删除7天前的压缩归档。务必注意，这里的保留周期要和logrotate的 rotate 设置保持一致，避免误删或冗余。

2. 监控与告警

日志本身也是需要被监控的资源。

• 容量监控：必须监控日志所在磁盘分区（通常是 /var/log）的容量和inode使用率。一旦被日志塞满，可能导致服务不可用甚至系统崩溃。
• 内容告警：对日志内容进行监控更有价值。可以设置告警规则，当error级别的日志在短时间内频繁出现时，立即通知相关人员，从而大幅缩短故障发现时间（MTTD）。

3. 权限与安全

日志可能包含敏感信息，权限控制不可忽视。运行Node.js进程的用户（例如 node）应该只拥有对日志目录的写入权限。日志文件的权限建议设置为 0640，属主和属组与运行用户一致，这样可以有效防止未授权用户读取日志内容，避免信息泄露。

五 快速落地清单

最后，我们来梳理一个可以快速上手的行动清单：

• 选择日志库与级别：Winston + JSON格式 + info/debug分级。
• 确定输出目标：开发时输出到控制台方便调试，生产环境同时写入文件（如 /var/log/myapp/app.log）。
• 制定轮转策略：优先采用logrotate（配置 daily/rotate 7/compress/copytruncate/dateext）；如果使用PM2，则直接启用其内置的logrotate插件。
• 规划远程与集中：中小规模先用rsyslog推送到一台中央服务器；规模扩大后，引入ELK或Graylog栈。
• 落实清理与监控：设置cron任务清理旧归档、监控磁盘容量与inode、建立针对error日志的告警机制。