OTel 进展不太顺利

原文 ↗ Hacker News 讨论 ↗

OpenTelemetry（OTel）正在成为事实上的可观测性标准，但许多工程师认为，与 Prometheus、Jaeger，或 Datadog、AWS X-Ray 这类厂商特定方案相比，它过度设计、速度慢且复杂。批评者指出其 SDK 沉重、文档混乱、性能和冷启动惩罚明显（尤其在无服务器环境中），以及集成模式别扭；支持者则认为，面向追踪、指标和日志的通用开放标准，仍然是避免供应商锁定并实现互操作性的最佳方式。这场讨论凸显了灵活而雄心勃勃的标准与轻量、专用工具之间更广泛的张力，也反映出人们对更好的开发者体验以及在可观测性各层之间提供更一致抽象的渴望。

关于 OTel 的整体看法

  • 许多人认为 OTel 过度设计、复杂且不成熟，尤其是与更简单、聚焦的工具相比。
  • 也有人认为它“还行”或“很重要”，因为它是一个通用标准；不完美，但它是实现互操作性的最佳可行路径。
  • 一个反复出现的张力：雄心勃勃的目标和沉重的设计 vs. 实际可用性、性能和清晰度。

复杂性、API 与开发者体验

  • SDK 和埋点被描述为“令人眩晕地复杂”、“Java/XML 极简主义的反面”，以及“委员会式设计”。
  • 自动埋点经常会破坏非平凡应用；contrib 包被认为脆弱且难以定制。
  • 全局状态、静态方法、隐藏的“inject”逻辑，以及跨语言的一致性都受到批评；很多人希望使用简单、明确、DI 风格的客户端。
  • 文档普遍被认为质量差、不一致，有时甚至是错的；一些用户转而依赖阅读源码、抓包和调试导出器。

性能、成本与无服务器

  • 多位用户报告了显著的 CPU/内存开销，尤其是在 Python/Ruby 和 Lambda 中；冷启动惩罚可能非常严重。
  • 对于 Lambda，OTel layers 和 AWS 的 OTel distro 被认为比旧的 X-Ray 工具或厂商代理更重。
  • 有人担心监控的成本会比运行应用本身更高；在“OTel 税”和供应商锁定之间做权衡。

追踪、指标、日志模型

  • 关于追踪、指标和日志应当统一还是本质上不同，存在争论。
  • 有人建议只埋点一次，使用通用的“events/spans”，然后动态派生日志/指标/追踪；也有人认为这在概念上很漂亮，但在实践中脆弱、昂贵或无法扩展。
  • 自适应采样和摄取端聚合被提及为现实中的策略；成本通常由存储主导。

替代方案与生态

  • 许多人称赞 Prometheus（配合 exporters、node/blackbox exporters、Mimir/VictoriaMetrics）以及 Jaeger/Tempo，因为它们的心智模型更简单且更可靠。
  • 一些人更喜欢自托管栈（Grafana + Loki/Tempo/Mimir、VictoriaMetrics、基于 ClickHouse 的栈、SigNoz），但也指出碎片化和多种查询语言是痛点。
  • 对于低摩擦、“开箱即用”的方案，专有厂商（Datadog、AWS CloudWatch/X-Ray 等）被认为更容易上手，但锁定性更强。

标准 vs. 现实

  • OTel 作为厂商中立的 OTLP 规范和通用 schema 的价值得到了认可。
  • 令人沮丧的是，尽管有标准，导出器仍然需要针对各厂商的特殊处理，而且许多厂商只提供部分、存在 bug 或二等公民级别的 OTel 支持。