可观测性实战：OpenTelemetry 让系统问题无处遁形

在微服务和云原生架构盛行的今天，系统复杂度呈指数级增长。当用户反馈"页面加载慢"时，你如何在几十个微服务中快速定位问题？这就是可观测性（Observability）要解决的核心问题。

可观测性的三大支柱

日志（Logging）：记录系统发生的事件，回答"发生了什么"

指标（Metrics）：聚合的数值数据，回答"系统状态如何"

追踪（Tracing）：请求在系统中的完整路径，回答"请求去了哪里"

为什么选择 OpenTelemetry？

过去，你需要为日志、指标、追踪分别接入不同的 SDK（Prometheus、Jaeger、ELK...），代码侵入性强且难以维护。OpenTelemetry（OTel）作为 CNCF 项目，提供了统一的观测数据收集标准：

• ✅ 一次接入，多后端输出
• ✅ 厂商中立，避免锁定
• ✅ 自动仪器化，减少手动埋点
• ✅ 支持 30+ 语言和框架

实战：5 分钟接入 Node.js 应用

// 安装依赖
npm install @opentelemetry/api @opentelemetry/sdk-node \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-http

// 初始化 SDK
const { NodeSDK } = require("@opentelemetry/sdk-node");
const { getNodeAutoInstrumentations } = 
  require("@opentelemetry/auto-instrumentations-node");
const { OTLPTraceExporter } = 
  require("@opentelemetry/exporter-trace-otlp-http");

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: "http://localhost:4318/v1/traces"
  }),
  instrumentations: [getNodeAutoInstrumentations()]
});

sdk.start();

就这么简单！你的 Express、HTTP、数据库调用都会被自动追踪。

关键实践建议

1. 统一采样策略：生产环境全量采集成本高，建议按 10% 采样或错误请求 100% 采集
2. 上下文传播：确保 traceId 在服务间传递，才能看到完整调用链
3. 语义约定：使用 OTel 标准属性名（如 http.method、db.system），便于统一分析
4. 告警关联：将指标告警与追踪关联，点击告警直接看到慢请求详情

常见陷阱

• ❌ 过度采集：每个请求都记录详细日志，存储成本爆炸
• ❌ 采样不一致：不同服务采样率不同，调用链断裂
• ❌ 忽略业务指标：只监控系统指标，不关注业务转化率

推荐技术栈

• 收集：OpenTelemetry Collector
• 存储：Prometheus（指标）+ Tempo/Jaeger（追踪）+ Loki（日志）
• 可视化：Grafana
• SaaS 替代：DataDog、New Relic、观测云

结语

可观测性不是锦上添花，而是现代系统的必备能力。投入时间建设观测体系，会在故障排查时获得十倍回报。从今天开始，让你的系统"透明"起来！

---

你觉得可观测性最难落地的是什么？欢迎在评论区交流~