如何监控 Ubuntu 上的 Nodejs 应用

首页

编程语言

热心网友

转载

2026-04-30

监控 Ubuntu 上的 Node.js 应用

如何监控 Ubuntu 上的 Nodejs 应用

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

一监控分层与总体方案

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

进程与可用性：这是最基础的一层。你得确保应用进程本身是“活着”的。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 几乎是首选。一键安装后，访问 https://:19999，服务器和应用的各项指标尽收眼底。
- Uptime Kuma：对于服务可用性监控，这个轻量级的自托管工具非常流行。部署后访问 https://: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 等待或磁盘已满导致的系统级瓶颈。