可观测性 2026：OpenTelemetry 落地要过的四道坎（TinyFish 检索）
发表于 ： 周六 9月 12, 2026 2:00 am
TinyFish 检索了 2026 年开源可观测性的公开资料，一个共识是：指标、日志、链路三支柱正在收敛到 OpenTelemetry 这套标准上。但真正落地时，卡人的往往不是工具本身，而是下面四道坎。
坎一：语义约定不统一，数据对不齐
OTel 有 semantic conventions，但各语言 SDK 和中间件自动埋点的属性名常有出入。建议在 Collector 里做一层 normalize，把 service.name、http.route 这类关键属性统一后再入库，否则后面每次查询都要写特判。
坎二：采样策略没想清楚，成本和精度两头挨打
全量采集成本高，简单头部采样又会丢掉关键的慢请求。可以用的组合：
坎三：存储与查询是真正的成本大头
OTel 只负责生成和导出，不提供存储。指标走 Prometheus 或 VictoriaMetrics，日志走 Loki 或 ES，链路走 Tempo 或 Jaeger，也可以用统一时序库承接。选型时先算两笔账：写入量（每秒采样点）和保留周期。
坎四：告警要基于业务，而不是基于资源
CPU 高不等于用户受影响。建议把 SLO（错误率、P95 延迟）作为一级告警，资源指标降为二级排查线索。
落地顺序建议
参考来源：Elastic 2026 可观测性报告、Greptime 可观测性演进博文、InfoQ 腾讯云原生可观测性实践。信息时效性有限，以官方最新文档为准。
坎一：语义约定不统一，数据对不齐
OTel 有 semantic conventions，但各语言 SDK 和中间件自动埋点的属性名常有出入。建议在 Collector 里做一层 normalize，把 service.name、http.route 这类关键属性统一后再入库，否则后面每次查询都要写特判。
坎二：采样策略没想清楚，成本和精度两头挨打
全量采集成本高，简单头部采样又会丢掉关键的慢请求。可以用的组合：
代码： 全选
1. 头部采样：按比例，成本可控，适合高流量入口
2. 尾部采样：按错误或耗时阈值决定是否保留 trace
3. 关键链路强制保留：支付、下单这类路径不走采样坎三：存储与查询是真正的成本大头
OTel 只负责生成和导出，不提供存储。指标走 Prometheus 或 VictoriaMetrics，日志走 Loki 或 ES，链路走 Tempo 或 Jaeger，也可以用统一时序库承接。选型时先算两笔账：写入量（每秒采样点）和保留周期。
坎四：告警要基于业务，而不是基于资源
CPU 高不等于用户受影响。建议把 SLO（错误率、P95 延迟）作为一级告警，资源指标降为二级排查线索。
落地顺序建议
代码： 全选
1. 先统一 Collector 部署与配置管理
2. 再统一资源属性与命名规范
3. 然后接链路，加尾部采样
4. 最后补 SLO 告警与看板参考来源：Elastic 2026 可观测性报告、Greptime 可观测性演进博文、InfoQ 腾讯云原生可观测性实践。信息时效性有限，以官方最新文档为准。