OpenTelemetry 使命、愿景和价值观

使命

我们社区的总体北极星

OpenTelemetry 的使命：通过使高质量、可移植的遥测无处不在，从而实现有效的可观测性。

愿景

我们为 OTel 最终用户设想的世界

有效的可观测性之所以强大，是因为它使开发人员能够更快地创新，同时保持高可靠性。但有效的可观测性绝对需要高质量的遥测——以及使其成为可能的高性能、一致的仪器。

在这种情况下，遥测是指从软件应用程序中流出的原始观测数据流，“高质量遥测”可能是优秀可观测性的要求，但仍然不合理且不切实际地期望应用程序软件的开发人员自己添加或维护必要的仪器。这是一项艰巨的任务，实际上它“不仅仅是代码”——还需要围绕协议和语义约定（用于标签、属性和其他元数据）进行必要的对齐。

那么，我们如何在没有大量、不可持续的工程努力的情况下获得高质量、即插即用的遥测呢？这就是 OpenTelemetry 的用武之地。为了实现我们的愿景，OpenTelemetry 认为有五个关键机会，列于此处：

遥测应该简单

通过 OpenTelemetry，我们希望高质量的遥测变得简单，尤其对于最终用户。这意味着 OpenTelemetry 应该具有快速的价值实现时间，设置合理的默认值但允许进行自定义，并与优秀的文档和一流的整体开发体验相匹配。

遥测应该普遍

遥测协议和约定应该在语言和信号类型（跟踪、指标、日志等）之间统一，而不是分歧或孤立。这意味着 OpenTelemetry 致力于寻找在本地和全局一致工作的技术解决方案。

遥测应该是中立的

几十年来，来自监控和可观测性供应商的专有即插即用代理一直是来自整个应用程序堆栈的有价值遥测的主要来源。不幸的是，这些代理之间缺乏通用标准或 API 导致了客户被供应商锁定，并通过将遥测收集与遥测存储和分析紧密耦合而阻碍了创新。通过 OpenTelemetry，我们努力为所有可观测性提供商提供公平的竞争环境，避免被任何供应商锁定，并与其他遥测和可观测性生态系统中的开源项目互操作。

遥测应该是松散耦合的

OpenTelemetry 最终用户应该能够选择他们想要的组件，而无需引入项目的其余部分。为了实现这一点，OpenTelemetry 的软件架构在可能的情况下是解耦的。作为推论，这也意味着 OpenTelemetry 不想在特定的项目或技术方面“选择获胜者”：在可能的情况下，我们更倾向于为最终用户提供选择。

遥测应该是内置的

从历史上看，遥测是由开发人员手动集成或通过编译后代理集成的。OpenTelemetry 认为高质量的遥测可以内置到整个软件堆栈中——就像今天的注释一样。

虽然 OpenTelemetry 的结构和技术细节可能会随着时间的推移而改变，但直到我们实现使命，这五个关键机会仍然存在，作为项目，我们在规划我们的道路时会参考它们来定位——并重新定位。

工程价值观

指导我们贡献的原则

OpenTelemetry 的使命和愿景描述了我们想去的地方。OpenTelemetry 的工程价值观描述了我们想如何到达那里。

OpenTelemetry 的核心工程价值观是兼容性、稳定性、弹性和性能。

我们重视兼容性

考虑到利益相关者和支持的平台数量，遵循规范和实现互操作性非常重要。OpenTelemetry 致力于符合标准、供应商中立，并在语言和组件之间保持一致。

我们重视稳定性

由于许多库都依赖 OpenTelemetry API，API 稳定性和向后兼容性对我们的最终用户至关重要。作为推论，我们不会引入新概念，除非我们确信它们是 OpenTelemetry 的广泛最终用户子集所需要的。

我们重视弹性

在 OpenTelemetry 中，我们重视技术弹性：在资源稀缺或其他环境挑战面前，适应和继续运行的能力。OpenTelemetry 旨在在应用程序行为不当时工作并继续收集遥测信号，OpenTelemetry 代码旨在根据需要优雅地降级。

我们重视性能

OpenTelemetry 用户不必在高品质遥测和高性能应用程序之间做出选择。高性能是 OpenTelemetry 的一个要求，并且意外的宿主应用程序干扰效应是不可接受的。

社区价值观

指导我们互动的原则

OpenTelemetry 项目旨在成为一个受欢迎的地方，让新老成员感到安全，可以尊重地分享他们的意见和分歧。我们希望吸引各种各样的人与我们合作，这意味着要认识到人们来自不同的背景和文化。

可能出现社区成员行为可疑的情况。如果您看到或经历了不可接受的行为，或者任何会使我们的社区不那么受欢迎的事情，请大声说出来！有关如何举报不可接受行为的更多信息，请参阅我们的行为准则。

虽然我们希望鼓励每个人以自己的方式表达自己，但有一些行为我们希望您在与其他社区成员互动时采纳。

代表项目行事

众所周知，许多项目维护者受雇于在 OpenTelemetry 中拥有商业利益的公司，尤其是可观测性领域的供应商。尽管如此，我们期望社区成员以项目最佳利益行事。作为项目的维护者或贡献者行事时，每个成员的优先事项应首先代表项目及其社区的利益，而不是他们自己的利益和其他义务（例如雇主）。

披露潜在的利益冲突

即使在项目内部，人们也可能扮演不同的角色：Collector 的维护者可能是治理委员会的成员，JavaScript 的维护者可能是技术委员会的成员，依此类推。当您的消息的上下文可能不明确时，请清楚您正在使用哪个角色。例如，在 GC 会议期间，一位同时也是 Collector 维护者的人可能会说：“作为 Collector 的维护者，我相信……，而作为 GC 成员，我相信……”

Assume positive intent

我们在日常工作中都有不同的优先事项，虽然我们中的一些人全职从事 OpenTelemetry 工作，但我们中的一些人根据我们雇主的商业利益来改进项目的特定部分。在审查提案、文档或代码时，请考虑不同的观点，但更重要的是，请 Assume positive intent：虽然提案乍一看可能偏向于特定观点，但如果能提供不同的观点，作者很可能会乐于改进它。

尊重地不同意

我们的项目每天都会做出许多决定。尽管我们尽了最大的努力，但并非所有决定都是正确的。我们鼓励提出和辩论想法和解决方案，直到达成一致或达到“Disagree and commit”阶段。我们无法容忍的是将对想法的攻击变成对人的攻击：在情绪激动的时候，可能会诱使进行人身攻击，但这始终是错误的。如果您有理由相信您辩论的人没有以项目利益行事，请寻求调解，而不是进一步参与。虽然问题的技术优点应由 SIG 由维护者解决，或在最终情况下由技术委员会（TC）解决，但非技术问题应提交给治理委员会。

好好相处

正如 Erin Meyer 的《文化地图》所证明的，来自不同文化背景的人们有不同的沟通方式。虽然我们不期望您成为理解潜台词的大师，但我们希望您善待他人，并且您的沟通清晰，无需对方推断未明确写明的内容。这包括在传达您的想法时保持基本的礼貌，并将讽刺或不当评论留给自己。