主要观点：

• 对 OpenTelemetry 常抱怨，认为其已偏离最初追踪标准的目标，成为涵盖过广的规范，失去方向，如尝试为日志和指标建立规范等。
• 2015 年构建分布式追踪规范，后 OpenTracing 与 OpenCensus 合并成 OpenTelemetry，其目标对发送者和开发者都有意义，但如今已偏离。
• 从供应商角度看，虽希望建立标准解决应用程序的检测问题，但实际未达成，且 OpenTelemetry 规范让开发者采用困难，概念过多。
• Sentry 希望有可移植的检测，兼容 OpenTelemetry 但不仅于此，还希望实现 crash 报告等其他遥测功能，目前其基于 OpenTelemetry 的 JavaScript SDK 效果不佳。
• 提出应拥有专注追踪的轻量级 SDK，代码不增加运行时性能和包大小，除非选择收集方法，且将其他非追踪相关内容分离。

关键信息：

• 2015 年构建分布式追踪规范，OpenTracing 后与 OpenCensus 合并成 OpenTelemetry。
• Sentry 希望有可移植检测，兼容 OpenTelemetry 但不止于此。
• OpenTelemetry 规范让开发者采用困难，概念多。
• 目前 Sentry 基于 OpenTelemetry 的 JavaScript SDK 效果不佳。
• 提出专注追踪的轻量级 SDK 等建议。

重要细节：

• 早期在生产系统中调试性能问题需识别供应商或构建 APM 类似解决方案，且需用类似 span 的数据结构注释代码。
• 如今技术更复杂，需要更好的追踪技术，供应商希望建立标准解决检测问题但未达成。
• OpenTelemetry 超越追踪，尝试为日志和指标建立标准，感觉像 BigMonitoring 试图保持相关性。
• Sentry 希望通过 piggyback 在 OpenTelemetry 上实现目标，但效果不佳，存在版本冲突等问题。
• 提出专注追踪的轻量级 SDK 及相关建议，如不增加运行时性能等，将其他非追踪内容分离。