OpenTelemetry 开发者体验调查的见解
OpenTelemetry 开发者体验 SIG 最近对社区进行了调查，以更好地了解 SIG 可以在哪些方面产生最大的影响来改善开发者体验。我们收到了 218 份回复，我们将利用这些回复来指导 SIG 内的工作优先级。本文总结了我们的调查结果以及我们将在近期关注的领域。
感谢所有参与调查的人！如果您有兴趣加入我们的行列，或对 OpenTelemetry 的开发者体验可以改进的方面提供更多见解，请随时与我们联系。SIG 的联系信息可在社区仓库的跨领域 SIG 列表中找到，我们自己的 GitHub 仓库在此。
关键要点
调查回复强调了改进文档、提供更深入的示例以及在生产中配置、部署和调试 OpenTelemetry 方面的必要性。以下是主要关注领域：
- 文档
- 文档导航困难，用户需要切换 OpenTelemetry 网站和 GitHub 仓库。许多用户报告说需要从各种来源拼凑信息。
- 缺乏 SDK 和 Collector 的生产使用示例。
- 本地调试
- 很难知道导出为何不起作用，以及 SDK 是否在丢弃数据。更好的本地调试工具将有助于故障排除。
- SDK 配置
- 总体复杂性（配置和概念）
- SDK 配置很复杂，许多用户指出，排查导出器是最痛苦的部分。
- Collector 操作
- 需要关于 Collector 配置及其组件的调试指南。OTTL 被提及了几次，因为它难以排查。
详细见解
关于受访者的基本信息
调查回复来自用户，其中大部分在生产环境中使用 OpenTelemetry（83%），并且不为供应商工作（77.4%）。82% 的人认为他们的组织已达到可观测性旅程的中级或高级阶段。
使用的平台倾向于 Kubernetes (68.2%) 和 AWS (34.6%)，裸机仍占有可观的比例 (12%)。
编程语言的使用分布在 Go、Java、JavaScript、Python 和 .NET 这些常用语言之间，但分布广泛，甚至包括没有官方 API/SDK 实现的语言，如下第二个图所示。
虽然后端或运营方面的工作者占受访者的大多数，但移动和浏览器也有代表，见第三个图。
文档
结果表明，到目前为止，人们在开始使用 OpenTelemetry 时，从网站和语言的 GitHub 仓库获取第一天信息，分别为 75.1% 和 43.8%，而 25.1% 来自其供应商的文档。然而，在有关手动插装、自动插装和设置 SDK 的三个问题中，文档不明确位居榜首。对于 Collector，它仅次于“配置处理器”。
有关文档用户体验的更多详细信息，请参阅用户 SIG进行的调查结果。
Collector 用量
入手 Collector 被认为是相当容易的，尽管根据关于操作 Collector 的问题和整体体验的问题的结果，似乎存在一个明显的差距，即在开始使用和操作更复杂的管道或大规模部署之间。未来计划部分将对此进行更详细的说明。
有趣的是，在“您使用哪个 Collector？”的问题中，collector-contrib 占了很大比例。令人遗憾的是，尚不清楚这是因为用户不了解 OCB（https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder）来构建自定义镜像，还是不打算使用它，或者是因为缺乏关于其使用方法的充分文档。
SDK 和插装
手动插装和入门 SDK 略微偏向于更难。另一方面，自动插装则倾向于更容易入门。尽管开始使用自动插装相对简单，但结果表明，丰富遥测数据更难。
调试
在调查的最后一个问题“可以改进开发者体验的哪些方面？”的回复中，一个共同的主题是对更易于设置的本地环境的渴望——一个能够看到本地运行的应用程序中所有遥测数据——以及来自 SDK 的更多信息，无论是在开发过程中还是在生产中，当出现问题时，例如数据丢失或导出器配置错误。
未来计划
受访者的调查结果是我们努力改善 OpenTelemetry 开发者体验的宝贵资源。我们将把一些反馈传递给相关 SIG，致力于原型设计解决方案，并与其他团队进行跟进。
再次感谢所有参与调查的人！尽管调查已经结束，但我们仍然欢迎反馈。如果您想提供更多信息，或想加入我们，请随时通过Slack 或在我们的每周会议上联系我们。