在 Ubuntu 上运行 Node.js 应用时，日志往往是最先失控的一块：文件持续增长、错误输出和普通输出混在一起，查问题时很难快速定位。本文按照“安装 Node.js 与 pm2、配置日志参数、用配置文件启动并检查日志”的顺序梳理一遍，帮助你判断哪些设置适合直接用默认值，哪些项需要按生产环境单独调整。
安装 Node.js 和 pm2
如果系统里还没有 Node.js，可以先更新软件索引并安装 nodejs 和 npm：
sudo apt update
sudo apt install nodejs npm随后全局安装 pm2。它既是 Node.js 进程管理器，也负责日志输出、重启控制和多实例运行，适合拿来做基础运维：
sudo npm install pm2 -g装好之后，就具备了管理应用进程和日志的基本条件。
先让应用跑起来
在正式加配置前，可以先直接启动一次应用，确认入口文件和运行环境没有问题：
pm2 start app.js这里的 app.js 替换成你自己的 Node.js 入口文件即可。这样做的好处是先把“程序能否正常运行”和“日志如何管理”分开处理，排错时更直接。
如果这一步能够正常启动，后面再切换到配置文件方式就会顺畅很多。
通过 ecosystem.config.js 配置日志分割
pm2 默认会接管应用日志，但如果你希望明确指定日志路径、输出格式和轮转行为，更适合使用 ecosystem.config.js。可以新建或编辑这个文件：
module.exports = {
apps: [{
name: 'my-app',
script: 'app.js',
instances: 'max', // 或者指定具体数字
autorestart: true,
watch: false,
max_memory_restart: '1G',
env: {
NODE_ENV: 'development'
},
env_production: {
NODE_ENV: 'production'
},
log_date_format: "YYYY-MM-DD HH:mm Z",
out_file: "./logs/out.log",
error_file: "./logs/error.log",
combine_logs: true,
rotate_logs: true,
time: true,
append: true,
cron_restart: "0 0 * * *", // 每天午夜重启应用
}]
};这份配置里，和日志管理关系最密切的参数主要有几类：
日志输出位置
out_file 和 error_file 分别定义标准输出和错误输出的文件路径。把两类日志拆开保存，通常会比全部混在一个文件里更利于排查问题。
日志格式与时间信息
log_date_format 用来控制时间戳格式，time: true 则会让日志附带时间信息。对于多实例应用或跨天排障，这两项非常实用。
多实例与日志合并
instances: 'max' 表示按可用 CPU 核心尽可能多开实例；combine_logs: true 则用于合并日志输出。是否开启合并，要看你更重视统一查看，还是更希望按实例拆分排查。
轮转与重启策略
rotate_logs: true 是本文的核心设置，表示启用日志分割。配合 cron_restart: "0 0 * * *"，可以让应用在每天午夜重启一次，适合需要定期整理运行状态的场景。
另外，max_memory_restart: '1G' 也值得保留。它不直接负责日志分割，但能在内存占用异常时触发重启，避免日志无限增长的同时服务状态已经失控。
用配置启动并检查日志
配置文件准备好之后，直接用它启动应用：
pm2 start ecosystem.config.js启动完成后，可以用下面的命令查看日志：
pm2 logs这条命令会输出所有应用日志。如果只想看某个应用，例如配置中的 my-app，可以这样查：
pm2 logs my-app当日志量已经比较大，但你只关心最近一段输出时，可以限制行数：
pm2 logs my-app --lines 100这种方式尤其适合线上排错，能直接聚焦最近 100 行变化，而不用从头翻完整文件。
停用与重启应用
日常维护中，最常用的两个动作就是停止和重启：
pm2 stop my-app
pm2 restart my-app当你调整了配置、更新了代码，或者需要配合日志观察应用状态时，这两条命令会经常用到。结合前面的日志查看命令，可以很快确认重启后是否出现新的报错或异常输出。
这套方案适合什么场景
如果你是在 Ubuntu 上维护一个常驻运行的 Node.js 服务，pm2 这套做法足够覆盖大多数基础日志管理需求。它的优点不在于复杂，而在于把启动、重启、日志输出和日志分割放进了同一套工具链里。
实际使用时，可以先按文中的配置跑通，再根据项目规模细化策略，比如是否保留 combine_logs: true、是否需要每日定时重启、日志文件是否要按目录进一步拆分。只要日志路径、时间格式和轮转逻辑先明确下来，后续排障成本通常会低很多。
