直接回答：三大支柱分工：Metrics 是聚合数值（QPS、错误率、延迟分位），低开销、适合告警和趋势；Logs 是离散事件记录，信息量最大但成本高，用于事后排查细节；Traces 把一次请求跨服务的调用链串起来，回答"慢在哪一段、错在哪一环"。三者互补：指标发现异常，trace 定位到服务，日志还原现场。OpenTelemetry（OTel）是 CNCF 的统一标准：一套 API/SDK/协议（OTLP）同时生产三种信号，让应用埋点与后端厂商解耦。

展开解析：OTel 的核心价值是"埋点一次，后端随便换"：SDK 采集后经 Collector（接收、处理、导出的独立组件）路由到 Prometheus、Jaeger、Loki 或商业 APM，换厂商不改应用代码。落地要点：trace 靠 context propagation（W3C traceparent header）跨进程串联，异步消息场景要手动注入/提取上下文；采样策略决定成本——头部采样简单省钱，尾部采样（Collector 按错误/慢请求保留）更聪明；指标注意基数爆炸（label 取值无界如 user_id 是灾难）。给面试加分的洞察：三大支柱正在融合——exemplar 把指标数据点关联到具体 trace，log 带 trace_id 后三种信号可互相跳转，排障体验质变。

追问方向：push 与 pull 指标模型之争？Collector 的部署形态（agent/gateway）？日志结构化的关键字段？

（约 460 字）