如何监控 Ubuntu 上的 Nodejs 应用

监控 Ubuntu 上的 Node.js 应用

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

一 监控分层与总体方案

一个健壮的监控体系，从来不是单一工具就能搞定的。它更像是一个分层防御系统，每一层都解决不同层面的问题。下面这个方案，可以说是生产环境下的标准配置了。

• 进程与可用性：这是最基础的一层。你得确保应用进程本身是“活着”的。PM2 或 systemd 这类进程管理工具，能帮你实现进程常驻、崩溃自动重启，并且让你能快速查看状态与日志，这是所有后续监控的基石。
• 系统资源：进程活着，不代表服务器健康。这时候，就需要 htop、NetData 这类工具登场了。它们能让你直观地看到 CPU、内存、磁盘 I/O、网络流量等系统层面的指标，帮你快速定位硬件或系统级的瓶颈。
• 应用指标与可视化：系统资源正常，应用就一定没问题吗？未必。你需要在 Node.js 应用内部暴露关键业务指标（比如请求量、延迟、错误率），通过 Prometheus 收集，再用 Grafana 做成仪表盘。这才是真正洞察应用内部状态的“火眼金睛”。
• 日志：指标告诉你“发生了什么”，而日志告诉你“为什么发生”。采用 Winston 这样的库进行结构化日志记录，再结合 journalctl 或集中式方案（如 ELK 栈），你就能在海量日志中快速检索、分析，并基于特定日志模式设置告警。
• 链路与错误：当用户报告“页面很慢”时，你怎么知道慢在哪里？是数据库查询，还是某个外部 API 调用？这就需要 APM（应用性能监控）工具了，比如 New Relic 或 Datadog。它们能自动捕获 HTTP 请求延迟、错误率，并生成完整的分布式调用链，让性能瓶颈无处遁形。
• 可用性探测：最后，别忘了从外部视角看看你的服务。使用像 Uptime Kuma 这样的工具，从外部网络对服务的 HTTP 端点、特定端口进行定时探测和心跳检查，确保终端用户真的能访问到你的服务，并在异常时第一时间收到通知。

二 快速上手 PM2 与 systemd

进程管理是运维的第一课。PM2 和 systemd 是两种主流选择，它们各有侧重，掌握其核心用法能让你事半功倍。

• PM2 常用命令
  • 安装与启动：全局安装后，一条命令即可启动应用：sudo npm install pm2 -g；pm2 start app.js --name “my-app”。
  • 状态与资源：想看看所有应用运行状态？pm2 status。想要一个实时的资源监控面板？pm2 monit 会给你惊喜。
  • 日志：查看实时日志就用 pm2 logs my-app。PM2 会自动帮你管理日志轮转，不用担心日志文件撑爆磁盘。
• systemd 服务示例
  • 创建服务：在系统服务目录创建一个配置文件：sudo nano /etc/systemd/system/my-app.service。
  • 内容要点：配置文件的核心在于这几个部分：

    [Unit]
    Description=Node.js Application
    After=network.target
    
    [Service]
    Type=simple
    User=
    WorkingDirectory=/path/to/your/app
    ExecStart=/usr/bin/node /path/to/your/app/app.js
    Restart=always
    
    [Install]
    WantedBy=multi-user.target

  • 启用与查看：配置好后，依次执行：重载配置 sudo systemctl daemon-reload；启动服务 sudo systemctl start my-app；最后，用 sudo systemctl status my-app 检查服务状态，这是最常用的命令之一。
• 适用场景
  • PM2 的优势在于快速部署和丰富的运行时观测功能，无论是开发调试还是生产环境，用起来都很顺手。
  • systemd 则更偏向系统级集成。如果你需要严格的开机自启、希望与系统日志（journalctl）深度联动，或者是在追求极简依赖的环境下，systemd 是更标准的选择。

三 日志监控与最佳实践

日志不是简单的 console.log，而应该是结构化的、可追溯的事件流。处理好日志，排障效率能提升一个数量级。

• 应用内结构化日志
  • 告别杂乱无章的文本输出。使用 Winston 这样的库，可以轻松定义日志级别和输出格式，比如输出为 JSON，便于后续的机器解析和聚合：

    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' })
      ]
    });
    logger.info('Application started');
    logger.error('An error occurred:', error);

• 系统与服务日志
  • 如果你的应用托管在 systemd 下，查看日志就变得非常统一：journalctl -u my-app.service -f（那个 -f 参数代表实时跟踪，是排障利器）。
  • 对于直接输出到文件的日志，经典的 tail -f combined.log 命令依然是快速跟踪最新日志的不二法门。
• 集中式与可视化
  • 当服务数量不多时，PM2 自带的日志管理或许够用。但一旦进入中大规模部署，就必须考虑集中式日志方案了。将日志收集到 ELK（Elasticsearch, Logstash, Kibana）栈或类似的云日志服务中，可以实现跨节点的统一检索、可视化分析和基于内容的告警，这才是现代运维的标配。

四 指标与可视化 告警

可视化仪表盘和主动告警，是监控从“被动查看”走向“主动运维”的关键一步。

• Prometheus + Grafana
  • 首先，在应用中引入 prom-client 库来暴露指标，通常会增加一个 /metrics 端点。例如，记录 HTTP 请求延迟的典型做法如下：

    const client = require('prom-client');
    const httpRequestDuration = new client.Histogram({
      name: 'http_request_duration_ms',
      help: 'Duration of HTTP requests in ms',
      labelNames: ['method', 'route', 'code'],
      buckets: [0.1, 5, 15, 50, 100, 200, 300, 400, 500]
    });
    app.use((req, res, next) => {
      const start = Date.now();
      res.on('finish', () => {
        httpRequestDuration
          .labels(req.method, req.route || req.path, res.statusCode)
          .observe(Date.now() - start);
      });
      next();
    });

  • 接着，配置 Prometheus 定时来抓取这个 /metrics 端点。最后，在 Grafana 中，你可以利用这些数据构建丰富的仪表盘，并为关键指标（如95分位延迟大于500ms）设置告警规则，通过邮件、Slack等渠道通知你。
• 系统与应用性能面板
  • NetData：如果你想要一个开箱即用、零配置的实时监控仪表盘，NetData 几乎是首选。一键安装后，访问 http://:19999，服务器和应用的各项指标尽收眼底。
  • Uptime Kuma：对于服务可用性监控，这个轻量级的自托管工具非常流行。部署后访问 http://:3001，即可轻松设置对 HTTP、TCP 端口、甚至心跳包的探测，并支持通过 Telegram、Discord、Slack 等多种方式发送宕机通知。

五 进阶排障与性能分析

当常规监控发现异常时，就需要这些“外科手术刀”级别的工具进行深度诊断了。

• 内存与 CPU 快照
  • 怀疑内存泄漏？使用 heapdump 模块可以在运行时生成堆内存快照：

    const heapdump = require('heapdump');
    heapdump.writeSnapshot('/path/to/snapshot.heapsnapshot');

  • 生成的文件可以导入到 Chrome DevTools 的 Memory 面板中进行分析，你能清晰地看到哪些对象占据了大量内存，以及它们的引用链，从而精准定位泄漏源。
• 运行时诊断
  • 使用 node --inspect 参数启动应用，它会打开一个调试端口。随后，在 Chrome 浏览器中打开 chrome://inspect，你就可以像调试前端代码一样，使用 DevTools 的 Performance 和 Memory 面板对 Node.js 进程进行 CPU 性能分析和内存堆快照录制，这对分析性能热点和内存问题极具价值。
• 系统层面观测
  • 有些问题根子在系统层面。这时候，一套经典的 Linux 命令组合拳就派上用场了：用 top/htop 看实时进程，vmstat 看系统整体负载，iostat 看磁盘 I/O，free 看内存使用，df 看磁盘空间。综合使用它们，可以快速判断是否是 CPU 饱和、内存不足、I/O 等待或磁盘已满导致的系统级瓶颈。