全栈可观测性：OpenTelemetry + Grafana从零搭建

当你的应用从单体演进到微服务+前端SPA的组合后，”为什么这个API慢了”这个问题可能需要翻5个服务的日志才能回答。OpenTelemetry（OTel）提供了一套统一的遥测数据标准，让你用同一套工具看到整个请求从前端按钮点击到数据库查询的完整路径。

三大信号：Traces、Metrics、Logs

OTel的核心是三个信号类型：Traces记录一次请求在各服务间的完整调用链，显示每一步的耗时；Metrics聚合系统级指标（QPS、错误率、P99延迟）；Logs是传统的日志但附带了trace_id，可以从日志直接跳转到对应的追踪。三者联动后，故障排查路径变成：Grafana告警发现P99飙升 → 点击查看对应时间段的Traces → 定位到是Redis查询耗时异常 → 查看该trace关联的Logs确认是缓存未命中。

前端也要Instrumentation

大多数团队只在后端加OTel，但前端的性能数据同样关键。@opentelemetry/sdk-trace-web可以追踪页面加载、用户交互和API调用的完整时间线。在Grafana中，你可以看到一条trace从click "购买"按钮开始，经过前端API调用、后端Nginx、应用服务、数据库查询，再返回——全链路透明。

成本与复杂度

OTel的自动Instrumentation可以覆盖80%的场景（HTTP/gRPC/数据库驱动自动插桩），但剩下的20%需要手动添加Span。初始部署成本约1-2天，日常维护极低。数据存储建议使用Grafana Tempo（Traces）+ Mimir（Metrics）+ Loki（Logs），三者使用统一的对象存储后端，运维成本远低于自建ELK。