北京
在可观测性领域，OpenTelemetry（简称OTel）已经成了绕不开的名字。但如果你试图把一个团队从厂商专属SDK迁移到它上面，大概率会听到这样的抱怨："为什么这东西看起来还没做完？"
厂商提供的可观测性SDK，说白了就是"傻瓜式"的。装上就能用，仪表盘自动出数据，至于各个组件怎么拼在一起，那是别人的事。而OpenTelemetry呢？一进门就贴满了"实验性"的标签，同一件事还给你六种不同的做法。
这种"OTel似乎有问题"的模糊感觉，在可观测性圈子里已经流传了一阵子。但感觉归感觉，能不能用数据说话？问题到底是真的存在，还是社区对"进展缓慢"的感知出了偏差？是维护者不够多、范围铺得太大，还是另有原因？
作者决定做一份表格，把问题摊开来看。
一开始，作者的猜测是"经典的开源项目贪多嚼不烂"——维护者不够、预算不足。但数据看下来，这些因素确实存在，却还有别的东西在起作用。
真正的核心，是一场三方碰撞。
OpenTelemetry内部有一个"二进制稳定性门槛"：一旦某个功能被标记为稳定（stable），就永远不能改了。这个门槛本身是好事，但问题在于，实际能拍板的核心维护者人数非常少。两相叠加，就出现了一个尴尬的局面——大家都不太敢把一个功能从"实验性"转正，因为一旦锁定，就再也没有回头路。
再加上OTel试图覆盖的语言和框架范围极其庞大，这就形成了一个"完美风暴"：既然功能转正后就改不了，那不如在讨论阶段就把所有潜在问题都吵个遍。于是，语义约定（semantic-conventions）仓库里的讨论一拖再拖，不同语言的支持进度也天差地别。
Golang和Dotnet是一等公民，其他语言则落后了好几年。
这种状况带来的直接后果是：作者在向小团队推荐OTel时，变得越来越谨慎。那些没有时间、预算和"情绪带宽"去折腾的团队，自动埋点（auto-instrumentation）确实很神奇，但"自动埋点能用"和"现在我得手动埋点"之间的落差，陡得足以让人摔跟头。在把人推下悬崖之前，你至少得先警告一声。
所以，OTel的问题不是简单的"维护者不够"或"范围太大"，而是稳定性承诺、稀缺的维护人力和庞大的支持范围这三者之间的结构性矛盾。这个矛盾不解决，"为什么还没做完"的疑问，恐怕还会继续问下去。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
