OpenTelemetry 为何步履维艰
OTel isn't going well (and I made a spreadsheet about it)
多年来，我常听到团队抱怨 OpenTelemetry 似乎永远无法‘完工’。相比开箱即用的厂商 SDK，OpenTelemetry 充满了实验性标记和复杂的实现路径。虽然其坚持厂商中立值得尊敬，但项目正陷入维护者稀缺、范围过大与二进制稳定性要求之间的三重困境。通过对比 Envoy 和 Prometheus 的数据，我发现许多语言的 SDK 维护工作过度集中在极少数人身上，导致语义规范讨论冗长，新功能推进缓慢。这并非社区热情不足，而是项目复杂度已超出业余维护的极限，需要更现实的资源投入。
OpenTelemetry 内部发生的实际问题是一场三方碰撞：二进制稳定性门槛、极少的维护者团队以及他们试图覆盖的庞大语言和框架范围。
- bilalq
OTel 真是让人抓狂。如果它不是这个领域里显而易见的赢家，我也不会抱怨得这么厉害。但现实是：
1. 过了这么久，各大厂商对 OTel 的支持依然处于某种奇怪的 alpha/beta 阶段。
2. 性能损耗相当大，以至于让人质疑：如果运行同样的工作负载现在需要两倍的计算资源或内存，那做性能监控的意义何在？
3. Serverless 运行时在冷启动时因为 OTel 要付出沉重代价。
4. 任何实际应用场景中，你基本上被迫同时运行网关采集器（gateway collectors）和边缘采集器（edge collectors）。
5. 你仍然需要以独特的方式配置目标导出器（destination exporters）。这让人不禁怀疑 OTel 的价值到底在哪里。
6. 那些功能超出 OTel 覆盖范围的厂商，仍然需要他们自己定制的监控方案。那这一切的初衷又是什么？