怎样定位nodejs日志异常

定位 Node.js 日志异常，通常可以按“看现象 → 找日志 → 定位代码 → 复现/验证”的思路进行。下面给你一套比较实用的方法论和工具清单。

一、先明确“异常”是什么

Node.js 日志异常常见有几类：

1. 进程崩溃
   • uncaughtException
   • unhandledRejection
2. 接口报错但进程还在
   • 500 / 超时 / 逻辑错误
3. 日志本身有问题
   • 日志缺失、重复、级别不对
4. 性能异常
   • CPU 高、内存涨、Event Loop 卡

二、基础定位手段（必做）

1. 捕获全局异常（第一步）

process.on('uncaughtException', (err) => {
  console.error('uncaughtException', err);
});

process.on('unhandledRejection', (reason) => {
  console.error('unhandledRejection', reason);
});

至少能知道“死在哪”

2. 使用结构化日志（非常重要）

不要用 console.log 裸打：

✅ 推荐：

• winston
• pino（性能最好）
• bunyan

示例（pino）：

const pino = require('pino');
const logger = pino();

logger.error({ err }, 'request failed');

日志里应包含：

• timestamp
• level
• requestId
• err.stack

3. 给每次请求一个 ID（链路追踪）

requestId: abc123

工具：

• cls-hooked
• async_hooks
• Express / Koa 中间件

这样你可以：

grep abc123 app.log

直接看完整调用链。

三、日志异常定位流程

Step 1：看错误日志级别

grep -E "ERROR|FATAL" app.log

Step 2：看异常堆栈

重点看：

• 最上面你自己的代码
• 不要只看 Node 内部

Step 3：反查请求上下文

requestId → userId → 接口 → 参数

四、进阶定位工具

1. 内存 / CPU 异常

node --inspect

用 Chrome DevTools：

• Memory
• CPU Profiler

2. 核心转储（crash）

node --abort-on-uncaught-exception

生成 core dump 后用：

• lldb
• gdb

3. 日志聚合（生产环境）

• ELK
• Loki + Grafana
• Datadog
• Sentry（强烈推荐）

Sentry 能直接给你：

• 错误堆栈
• 影响用户数
• 发生频率

五、常见“看起来像日志问题，其实是代码问题”

六、一个标准排查清单 ✅

• [ ] 是否捕获全局异常
• [ ] 日志是否结构化
• [ ] 是否有 requestId
• [ ] 是否能按 ID 查全链路
• [ ] 是否有错误级别过滤
• [ ] 是否接入监控/告警

如果你愿意，可以把：

• 报错日志样例
• 使用的框架（Express / Koa / Nest）
• 是否生产环境

发给我，我可以帮你具体定位。