线上系统为什么慢?为什么挂?不打开"望远镜"你永远只能猜。OpenTelemetry 是 CNCF 第二大项目(仅次于 K8s)——用一套标准 API 产出 Traces / Metrics / Logs,然后随你接 Datadog / Grafana / Jaeger / New Relic,换后端不用改代码。这就是 2026 可观测性的通行证。
Datadog 要用 dd-trace,New Relic 要用 newrelic-agent,Prometheus 要埋 prom-client——换一家监控就要把代码里所有埋点重写一遍。供应商锁定 + 多套 SDK 并存 = 可观测性永远做不完。
API 层 + 协议层(OTLP)统一标准。代码里埋一次 span,后端想接 Jaeger 接 Jaeger,想接 Datadog 接 Datadog,Collector 里改一行配置就行。可观测性终于和业务代码解耦。
Logs/Metrics/Traces 三支柱;为什么 OpenCensus + OpenTracing 合并成 OTel;CNCF 地位、规范组(Spec)和实现组(SDK)如何分工。
Trace/Span/SpanContext 概念;TraceId、SpanId、Baggage;父子关系、Link、Status、Attributes;Node.js / Python 第一个 tracer 跑通。
Counter / UpDownCounter / Histogram / Gauge / Observable;同步 vs 异步;View 聚合、Delta vs Cumulative;和 Prometheus 兼容性。
OTel Log SDK;和 Winston/Pino/logback 桥接;关键——如何把 trace_id 自动注入日志,让日志在 Jaeger/Tempo 里一键跳转。
W3C TraceContext / Baggage header;跨进程、跨语言、跨异步边界传 context;Node.js AsyncLocalStorage、Python contextvars、Go context.Context。
无需改业务代码自动埋点:HTTP/gRPC/DB/Redis/Kafka 几十种库。Node.js 的 --require、Python 的 opentelemetry-instrument、Java Agent。
OTel Collector 的 receiver/processor/exporter 管道;部署模式(Agent vs Gateway);批处理、采样、tail-based sampling、负载均衡。
Semantic Conventions:HTTP、DB、Messaging、RPC 字段命名规范;Resource 描述服务、主机、容器、k8s Pod;没有语义约定就没有自动面板。
主流后端选型对比;Grafana LGTM(Loki+Grafana+Tempo+Mimir)stack;Datadog/New Relic 直连;自建 vs 云服务成本/运维 trade-off。
生产部署清单:采样策略、高基数警告、成本控制、GenAI 语义约定(OpenLLMetry);LangChain/LlamaIndex 链路追踪;troubleshooting 经验。
第 2、5、7 章是核心:Trace 数据结构、Context 传播、Collector 架构。第 8 章语义约定是"埋点有无价值"的分水岭。
直接跳第 10 章看 GenAI 语义约定与 OpenLLMetry。配合第 2 章理解 trace 模型——LLM agent 的每次 tool 调用就是一个 span。