每个人都可以，
拥有SSL证书

有一回线上报警，查日志时发现多个实例的输出糊在一起，根本不知道哪个请求打到了哪个进程。Fastify 本身就带了挺靠谱的日志方案，配合 PM2 的集群模式，理清楚之后舒服多了。这里记一下我实际用的配置和遇到的小坑。

Fastify 底层用的是 Pino，初始化时往 logger 对象里传点参数就行。最简单的就是指定 level 和日志文件路径，开发环境用 info 足够，生产再调高。

const fastify = require('fastify')({
  logger: {
    level: 'info',
    file: './logs/fastify.log'
  }
});

fastify.get('/', (request, reply) => {
  request.log.info('Processing incoming request');
  reply.send({ message: 'Hello World' });
});

fastify.listen(3000, (err) => {
  if (err) {
    fastify.log.error(err);
    process.exit(1);
  }
});

Pino 默认记录的请求信息比较全，但有时日志太胖，查起来反而慢。

可以加 serializers 只保留 method、url、statusCode 这些关键字段，省点磁盘不说，看的时候也清爽。

const fastify = require('fastify')({
  logger: {
    serializers: {
      req(req) {
        return { method: req.method, url: req.url };
      },
      res(res) {
        return { statusCode: res.statusCode };
      }
    }
  }
});

线上环境最怕把 token 之类的敏感字段打到日志里。

Fastify 的 redact 配置可以直接把 req.headers.authorization 这种路径的内容替换成 [Redacted]，一行就解决，不用自己在每个地方手动删。这个很多人会绕进去，明明框架层已经处理好了，还在业务代码里做脱敏。

const fastify = require('fastify')({
  logger: {
    redact: ['req.headers.authorization'],
    level: 'info'
  }
});

单实例跑着没问题，但要多核利用就得靠 PM2 的 cluster 模式。

一般我会用 ecosystem.config.js 管理，省得每次敲一堆参数。instances 设成 3，exec_mode 记得写 'cluster'，漏了就成 fork 模式了，没有负载均衡。

module.exports = {
  apps: [{
    name: 'fastify-cluster',
    script: './app.js',
    instances: 3,
    exec_mode: 'cluster',
    log_date_format: "YYYY-MM-DD HH:mm:ss",
    out_file: './logs/out.log',
    error_file: './logs/err.log',
    merge_logs: true
  }]
};

这里其实容易踩坑：merge_logs 设成 true，所有实例的 stdout/stderr 会混到一个文件里，查看是方便，一个 tail 就出来了，但多个进程的日志交叉混排，没带进程标识的话根本分不清哪条是谁打的——这正是开头说的那种情况。要么在 Fastify 里每次请求日志都带上 process.pid，要么 merge_logs 设成 false，让每个实例单独写文件。

我后来选了前者，业务日志里加 pid，然后用 pm2-logrotate 定期切割，防止单文件膨胀。

集群模式下主进程只负责监听端口，请求进来按 round-robin 分给各个 worker。其实就是 Node 内置 cluster 模块的默认行为，没什么黑魔法。

想验证负载均衡是不是真在工作，可以在路由里直接把 process.pid 打回去，用 curl 多打几次就能看到请求被分发到不同实例了。

const fastify = require('fastify')({
  logger: true
});

fastify.get('/', (request, reply) => {
  request.log.info(`Handling request in PID ${process.pid}`);
  reply.send({ pid: process.pid });
});

fastify.listen(3000, (err) => {
  if (err) {
    fastify.log.error(err);
    process.exit(1);
  }
});

日志级别在开发时可以开 info，上了生产建议调到 warn 或更高，不然请求量大起来，光打印 info 就能拖慢不少。再就是日志轮转，pm2-logrotate 装一下，配好单文件大小和保留份数就行，不配的话磁盘迟早被写满。监控方面，单靠肉眼扫日志文件效率太低，最好接一个外部日志平台，搭 ELK 也好，扔到云厂商的日志服务也罢，能搜就行。

安全配置上，日志文件权限别图省事 777，只放给应用用户读写，脱敏配置也再检查一遍，别等出了事才想起。

碰到日志时间格式不对的，多半是 log_date_format 没写或者写错了，PM2 默认用时间戳，看着难受。实例启动失败，直接 pm2 logs 看错误输出，或者去 ~/.pm2/logs 目录下翻具体进程的日志，比瞎猜快得多。

负载不均的话，一般不是 PM2 的锅，大概率某个实例在处理长任务或者系统资源没均衡分配，查查 CPU 和事件循环延迟就能定位。

配置都不复杂，全是些小点，但上线前挨个确认一遍，能省下不少半夜被叫起来查日志的时间。

现在看着整整齐齐的输出和均匀打到各实例的请求，起码能睡个整觉了。