如何通过日志监控Ubuntu上的Node.js

在Ubuntu上部署Node.js应用，日志监控是运维工作中既基础又关键的一环。无论是开发调试还是生产运维，一套清晰的日志管理策略都能让你在问题发生时快速定位，而不是在海量的文本里“大海捞针”。今天，我们就来系统地梳理一下，从本地查看、进程管理到集中化平台，如何高效地监控你的Node.js日志。

一 本地实时查看与过滤

当问题刚出现时，最直接的方式就是登录服务器，实时查看日志流。这里有几个经典命令组合，堪称运维人员的“瑞士军刀”。

使用 tail -f 可以实时跟踪日志文件的末尾新增内容，比如 tail -f /var/log/myapp.log。如果想在滚屏的信息中快速捕捉错误，可以配合 grep 进行关键字过滤：tail -f /var/log/myapp.log | grep 'ERROR'。如果不需要实时流，只想定期刷新查看最后几行，watch 命令会很方便：watch -n 2 "tail -n 20 /var/log/myapp.log"。

面对多个需要同时关注的日志文件时，multitail 工具就派上用场了。它不仅能分屏显示多个日志，还能高亮关键字，让重要信息一目了然。安装命令是 sudo apt-get install multitail，使用起来也很简单：multitail /var/log/myapp.log。

对于开发环境，频繁重启应用查看日志很麻烦。这时，nodemon 这类工具就非常合适。它监听文件变更并自动重启应用，同时将控制台输出（包括日志）直接显示在终端，非常适合开发期的调试：nodemon app.js。

二 使用进程管理器 PM2 统一收集与轮转

当应用正式上线，一个可靠的进程管理器就不可或缺了。PM2 不仅能守护进程，其内置的日志管理功能也让日常运维轻松不少。

首先全局安装并启动你的应用：sudo npm install -g pm2，然后 pm2 start app.js --name my-api。之后，查看日志就变得非常统一。

运行 pm2 logs 可以查看所有被PM2管理的应用日志；pm2 logs my-api 则只查看指定应用。如果需要原始的、未经PM2格式化的输出，可以加上 --raw 参数。当然，过滤功能也少不了：pm2 logs | grep error。

PM2 会自动将应用的标准输出和错误输出记录到 ~/.pm2/logs/ 目录下。随着时间推移，单个日志文件可能会变得巨大。这时，可以运行 pm2 logrotate 来配置日志轮转策略，支持按文件大小或时间进行切分，有效避免磁盘空间被单个日志文件占满。

三 结构化日志与系统日志集成

纯文本日志虽然直观，但在进行自动化分析和检索时就不够友好了。将日志结构化，并与系统日志服务集成，是走向专业运维的重要一步。

在代码层面，推荐使用 Winston 或 Bunyan 这类日志库。它们能输出结构化的JSON格式日志，并支持分级（如info、error、debug），极大方便了后续的日志聚合与检索。以下是一个Winston的配置示例：

首先安装：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' }),
    new winston.transports.Console()
  ]
});

logger.info('Server started', { port: 3000 });
logger.error('DB connection failed', { err: err.message });

更进一步，可以将应用日志写入系统的 syslog 服务（如 rsyslog 或 syslog-ng）。这样，你的Node.js应用日志就能和系统其他服务的日志统一管理，甚至方便地转发到远程服务器。这需要用到 syslog 传输插件：

安装：npm install winston syslog-transport。

const winston = require('winston');
const SyslogTransport = require('syslog-transport');
const logger = winston.createLogger({
  transports: [
    new SyslogTransport({
      host: 'localhost',
      app_name: 'my-node-app',
      facility: 'local0'
    })
  ]
});
logger.info('Hello, syslog');

日志写入系统后，就可以使用 systemd 的 journalctl 工具来查看了。例如，实时跟踪你的服务日志：journalctl -u my-node-app -f。

四 集中式日志平台搭建与远程转发

当服务器数量增多，登录每一台机器看日志就变得不现实。搭建一个集中式日志平台，将所有日志汇聚一处进行搜索、分析和可视化，是中型以上项目的标配。

市面上有几种主流方案，可以根据团队技术栈和需求来选择：

这里提供各方案的快速上手配置：

ELK方案：在 Logstash 的配置目录（如 /etc/logstash/conf.d/nodejs.conf）中添加如下配置，指定日志文件路径和Elasticsearch输出。

input {
  file {
    path => "/var/log/myapp/*.log"
    start_position => "beginning"
  }
}
output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "nodejs-logs-%{+YYYY.MM.dd}"
  }
}

启动后，在 Kibana（通常访问 http://:5601）中配置索引模式即可查看日志。

EFK方案：使用 Fluentd 作为采集端，配置类似。在 /etc/td-agent/td-agent.conf 中配置 source 和 match。

  @type tail
  path /var/log/myapp/*.log
  pos_file /var/log/td-agent/nodejs.log.pos
  tag nodejs.log
  
    @type none
  


  @type elasticsearch
  host localhost
  port 9200
  logstash_format true
  flush_interval 10s

Syslog 远程转发：这是最轻量的集中化方式。在客户端的 /etc/rsyslog.conf 末尾添加一行 *.* @:514（UDP协议），即可将所有日志转发到远程服务器。使用 syslog-ng 也可实现类似功能，定义好 destination 和 log 路径即可。记得修改配置后重启服务。

五 生产落地建议

掌握了工具，最后聊聊在生产环境中落地日志监控时的一些最佳实践和思考。

统一日志格式：这是后续所有自动化处理的基础。强烈建议在应用层就使用 Winston/Bunyan 输出结构化的 JSON 日志，确保包含时间戳（timestamp）、日志级别（level）、服务名（service）、请求追踪ID（trace_id）等关键字段。格式统一了，无论是检索、聚合还是关联分析，都会事半功倍。

日志轮转与保留：日志不能无限增长。除了使用 PM2 自带的 logrotate，也可以利用 Linux 系统自带的 logrotate 工具，按日或按文件大小进行切割，并设置合理的保留天数（如30天），这是防止磁盘被日志写满的最基本操作。

安全与合规：集中式日志平台往往存储了大量敏感信息。务必启用认证和授权机制。如果使用远程 Syslog，出于可靠性和安全性考虑，建议优先选择 TCP 或 TLS 加密传输，并在服务器端配置防火墙规则，限制可连接的客户端IP网段。

告警与可视化：日志不能只存不看。可以在 Kibana 中基于特定错误关键字设置告警规则。如果需要对应用性能指标（如请求延迟、错误率、内存占用）进行监控，可以结合 Prometheus（收集指标）和 Grafana（可视化）来搭建更完整的可观测性体系。

故障排查流程：当线上出现问题，一个高效的排查动线很重要。通常可以遵循这样的顺序：首先通过 tail -f 或 pm2 logs 快速查看实时错误，定位问题应用；接着检查 journalctl 查看系统级关联日志和资源状态（如 dmesg）；最后，登录到 ELK/EFK 等集中日志平台，根据时间线和 trace_id 回溯完整的请求链路和上下文信息，进行根因分析。