APM 与生产监控

开发期用 nrt-debug；上线后需要 metrics、tracing、错误聚合——APM（Application Performance Monitoring）把 延迟、吞吐、GC、未捕获异常 持续可视化，衔接 broader observability 路线。

学习目标

• 说清 metrics / logs / traces 三支柱在 Node 中的落点
• 了解 OpenTelemetry 与常见 SaaS（Datadog、New Relic 等）集成方式
• 避免在高 QPS 路径上同步打满日志

三支柱速览

支柱	Node 典型实现	回答的问题
Metrics	prom-client、OTel Meter	QPS、P99、heap、event loop lag
Logs	pino、winston → stdout/ELK	某次请求发生了什么
Traces	OpenTelemetry + Jaeger/Tempo	慢在哪一段、跨服务链路

Golden signals：延迟、流量、错误、饱和度（CPU、event loop delay）。

Event Loop 延迟

主线程被 nrt-worker 未 offload 的 CPU 堵住时，所有请求一起慢——监控 eventLoopUtilization / perf_hooks.monitorEventLoopDelay：

import { monitorEventLoopDelay } from "node:perf_hooks";

const h = monitorEventLoopDelay({ resolution: 10 });
h.enable();

setInterval(() => {
  console.log({
    p50: h.percentile(50) / 1e6,
    p99: h.percentile(99) / 1e6,
  });
  h.reset();
}, 10_000);

P99 持续 > 50–100ms 值得查同步代码或 GC（nrt-gc）。

OpenTelemetry 入门（概念）

// 伪代码：实际需 @opentelemetry/sdk-node 等包
import { trace } from "@opentelemetry/api";

const span = trace.getTracer("app").startSpan("handleRequest");
try {
  await doWork();
} finally {
  span.end();
}

自动 instrumentation 可钩住 http、fs——注意 采样率（生产常 1–10%），避免 trace 存储爆炸。

与 Java Micrometer / Spring Actuator 类似：统一 export 到 Prometheus/Grafana 是常见自建方案。

错误与 process 事件

process.on("uncaughtException", (err) => {
  // 上报 APM 后：记录、告警；是否 exit 视策略而定
  console.error(err);
});

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