Ubuntu 上 Node.js 日志自动化管理

处理 Node.js 应用的日志，如果只靠手动操作，不仅效率低下，还容易在关键时刻找不到关键信息。一套自动化的管理方案，能让日志从负担变成资产。接下来，我们就来拆解如何在 Ubuntu 系统上，构建一个从采集、轮转、分析到清理的完整日志自动化体系。

一 架构与总体思路

一个健壮的日志管理架构，通常围绕四个核心环节展开：

• 统一输出：这是第一步。要么让 Node.js 应用将日志统一打印到标准输出（stdout/stderr），方便由 systemd 这样的系统服务管理器集中采集；要么使用成熟的日志库（如 Winston、Pino）直接写入文件，并为其配置好后续的轮转机制。
• 集中采集与轮转：日志不能放任自流。使用 systemd 的 journald 或者传统的 rsyslog/syslog-ng 来收集系统级日志；对于文件日志，则交给 logrotate 这个老牌工具，按日或按文件大小进行轮转、压缩，防止单个日志文件膨胀。
• 长期存储与分析：收集不是终点。将日志送入 ELK（Elasticsearch + Logstash + Kibana） 技术栈，或者 Prometheus + Grafana 组合，才能实现高效的检索、可视化看板以及关键的异常告警。
• 自动化清理：磁盘空间是有限的。通过 logrotate 自带的保留策略，或者 systemd timer、cron 定时任务来定期删除过期的历史日志，这是控制成本的必要手段。

二 采集与轮转配置

理论清晰了，具体怎么落地？我们从最常用的两种方式入手。

使用 systemd 托管与采集

如果你的应用通过 systemd 管理，那么集成日志采集会非常顺畅。

• 创建服务单元：在 /etc/systemd/system/nodejs-app.service 中定义服务。关键在于两点：一是将日志输出指向 journald，二是设置自动重启保证服务稳定。
  • 示例要点：
    • ExecStart=/usr/bin/node /path/to/app.js
    • StandardOutput=journal
    • StandardError=journal
    • Restart=always
• 查看与跟踪日志：配置好后，查看日志就变得非常方便。
  • 实时跟踪：journalctl -u nodejs-app -f
  • 按时间筛选：journalctl -u nodejs-app --since “2025-12-19 00:00:00”

使用 logrotate 做文件轮转

对于直接写文件的场景，logrotate 是轮转的不二之选。

• 新建配置：在 /etc/logrotate.d/nodejs-app 中创建专属配置。
  • 示例配置：

    /var/log/nodejs/*.log {
        daily
        missingok
        rotate 7
        compress
        notifempty
        create 0640 root adm
        copytruncate
    }
    

  • 关键项说明：
    • daily、rotate 7、compress 这三项联手，控制了按天轮转、保留最近7份、并压缩旧日志的策略。
    • copytruncate 这个参数很重要，它先复制原日志文件再清空，适用于持续写入且不支持重开文件句柄的应用。如果应用能响应 USR1 等信号来重新打开日志文件，那么在 postrotate 脚本里发信号是更优雅的方式。
• 手动测试与生效：配置好后别急着上线，先测试一下。
  • 干跑测试：sudo logrotate -d /etc/logrotate.d/nodejs-app（模拟执行，看输出是否符合预期）
  • 强制执行：sudo logrotate -f /etc/logrotate.d/nodejs-app（立即运行一次）

直接在 Node.js 内做轮转（可选）

对于容器化部署或没有 systemd 的环境，也可以考虑在应用层解决。使用像 winston-daily-rotate-file 或 pino-rotate 这样的模块，直接在 Node.js 代码中实现按天或按大小的日志切分与压缩，将复杂性收敛到应用内部。

三 集中分析与告警

日志集中起来后，真正的价值在于分析和洞察。

搭建 ELK 做检索与可视化

ELK 栈是处理日志分析的主流选择之一。

• 安装与启动（以 7.x 版本源为例）：
  • 添加官方 GPG 密钥和源后，通过 apt 安装 elasticsearch, logstash, kibana 三个包。
  • 启动并设为开机自启：sudo systemctl enable --now elasticsearch kibana（Logstash 通常按需启动）。
• 配置 Logstash 采集：在 /etc/logstash/conf.d/nodejs.conf 中配置管道。

  input {
    file {
      path => “/var/log/nodejs/*.log”
      start_position => “beginning”
    }
  }
  filter {
    # 这里可以留空，或者使用 grok、json 等插件解析日志结构
  }
  output {
    elasticsearch {
      hosts => [“localhost:9200”]
      index => “nodejs-logs-%{+YYYY.MM.dd}”
    }
  }
  

• 可视化分析：在 Kibana 中创建对应的索引模式，然后就可以自由地创建仪表板了。比如，统计错误级别的日志趋势、分析 API 响应时间的分布，都能一目了然。

错误告警与报表自动化

除了看板，自动化的告警和报表能让你更主动。

• 简单报表脚本示例：每天统计错误日志并邮件发送。

  #!/bin/bash
  # 提取 ERROR 日志行（前10个字段示例）
  grep “ERROR” /var/log/nodejs/error.log | awk ‘{print $1,$2,$3,$4,$5,$6,$7,$8,$9,$10}’ > error_report.txt
  # 发送邮件
  mail -s “Node.js Error Report” your_email@example.com < error_report.txt
  

• 定时执行：通过 crontab 设置每天运行。
  • 编辑 crontab：crontab -e
  • 加入一行：0 0 * * * /path/to/report.sh（表示每天零点执行）
• 指标与可视化进阶：对于性能监控，可以结合 Prometheus。在 Node.js 应用中使用 prom-client 这类库暴露指标，由 Prometheus 抓取，最后在 Grafana 中配置丰富的面板和基于阈值的告警规则。

四 自动化清理策略

日志生命周期管理的最后一环，是优雅地清理旧数据。

• 首选方案：优先使用上文 logrotate 配置中的 rotate 参数来控制保留份数，通常无需额外配置清理任务。
• 使用 systemd timer 定期清理：如果运维体系基于 systemd，用 timer 更统一。
  • 清理脚本 (/usr/local/bin/clean-nodejs-logs.sh)：

    #!/bin/bash
    LOG_DIR=“/var/log/nodejs”
    # 删除7天前的压缩日志
    find “$LOG_DIR” -type f -name “*.gz” -mtime +7 -delete
    # 删除30天前的原始日志文件
    find “$LOG_DIR” -type f -name “*.log” -mtime +30 -delete
    

  • 赋予执行权限：chmod +x /usr/local/bin/clean-nodejs-logs.sh
  • 定时器单元 (/etc/systemd/system/clean-nodejs-logs.timer)：

    [Unit]
    Description=Clean Node.js logs older than 7/30 days
    
    [Timer]
    OnCalendar=daily
    Persistent=true
    
    [Install]
    WantedBy=timers.target
    

  • 服务单元 (/etc/systemd/system/clean-nodejs-logs.service)：

    [Service]
    ExecStart=/usr/local/bin/clean-nodejs-logs.sh
    

  • 启用定时器：systemctl daemon-reload && systemctl enable --now clean-nodejs-logs.timer
• 使用 cron 定时清理：这是最通用的方案，适合任何环境。
  • 每天凌晨2点清理7天前的 .gz 文件：0 2 * * * find /var/log/nodejs -type f -name “*.gz” -mtime +7 -delete
  • 每天凌晨3点清理30天前的原始 .log 文件：0 3 * * * find /var/log/nodejs -type f -name “*.log” -mtime +30 -delete

五 落地检查清单

方案配置完成后，建议按照以下清单进行一次完整的验收，确保每个环节都运转正常：

• 日志路径与权限：确认 Node.js 应用对指定的日志目录有写入权限。如果使用 systemd 服务，检查服务配置的 User/Group 是否与日志目录的属主匹配。
• 轮转验证：执行一次 logrotate 的强制执行（-f），确认旧日志被正确压缩、按保留策略（如7份）管理，并且应用在轮转后能持续写入新日志，无报错。
• 采集链路：检查 journald 或 rsyslog 是否能收到日志；如果使用 ELK，确认 Logstash 管道正常，Elasticsearch 中按天创建了索引，并且能在 Kibana 中检索到最新的日志条目。
• 告警验证：在测试环境或通过特定接口，故意制造一些错误或触发阈值的事件，验证 Grafana/Prometheus 的告警是否正常触发，或日志报表脚本是否能正确生成并发送通知。
• 容量评估：根据日志生成速度和保留周期（如 rotate 天数），估算所需的磁盘空间。定期审计日志目录大小，确保不会因日志增长过快而占满磁盘，必要时调整 maxFiles 或保留策略。