规范原则
本文档定义了通用原则，这些原则将帮助设计者创建和扩展 OpenTelemetry 规范，以适应新的用例并修复问题。
OpenTelemetry 使命与价值观
应结合 OpenTelemetry 的整体价值观来理解本文档，其中阐述了以下核心价值观：
此外，它还阐述了以下核心工程价值观：
除了这些核心价值观之外，我们还从规范工作中吸取了一些经验，并驱动着我们编写规范的方式。
规范原则
以下是 OpenTelemetry 规范的关键原则：
请注意，有时这些原则会相互冲突。例如，保持稳定性可能会限制简洁性的可能性。这些原则是指导设计的标准，是我们评估规范添加或更改的依据。
让我们更详细地看看每个原则。
以用户为中心
如果没有它所支持的生态系统，该规范将毫无用处。更改应侧重于真实世界的用例和真实用户的需求。此外，更改应能在整个 OpenTelemetry 生态系统中实现。
这意味着提案应考虑“端到端”，而不是“只添加这一小部分”。
在进行更改之前，项目和提案应提供原型或实现。
关于原型，我们有一些简单的经验法则：
- API/SDK 更改应在三种语言中进行原型设计。目标是覆盖可能的 API 设计，而不是任何特定的语言。
- 一种语言应涵盖类型化的面向对象生态系统（Java、.NET 等）。
- 一种语言应涵盖动态类型化生态系统（Python、JavaScript）。
- 一种语言应涵盖结构化生态系统（Go、Rust）。
- 协议更改应在客户端和服务器端进行原型设计。
- 原型可以是未合并的拉取请求、现有项目等，但必须展示该功能，并自信地表明其规范将取得成功。
通用性
该规范需要能在各种语言、框架、生态系统和社区中实现。该规范应允许 OpenTelemetry 组件为用户提供地道的体验。
规范应侧重于“是什么”，而不是“怎么做”。在描述“怎么做”时，使用非规范性语言或补充指南，如本文档。
稳定性
不要。破坏。用户。
是的，这重复了 OpenTelemetry 的整体使命 稳定性。稳定性就是这么重要。
为了实现 OpenTelemetry 的使命“遥测应该是内置的”，我们需要创建一组对用户来说可以依赖的组件。不稳定会破坏信任，并损害成为应用程序和库作者乐于开箱即用集成的解决方案的使命。
当事物确实发生变化时，规范（和实现）应承担繁重的工作，以确保 OpenTelemetry 生态系统的无缝、平稳的体验。
一致性
不要让用户在与 OpenTelemetry 中的每个功能交互时都要学习新的概念和行为。这包含三个子原则：
- 倾向于简单、广泛适用的功能。
- 在不同信号之间偏好相似的概念和行为。
- 在可能的情况下，在不同信号和组件之间重用命名约定。
简洁性
简洁优于复杂。抽象应该能够证明其自身价值。OpenTelemetry 的范围很广，组件很多。通过简单的设计和解决方案来解决复杂问题，可以大大降低维护负担，并在未来更容易演进。
此外，规范由许多人阅读和解释。复杂的语言、细微的措辞和不清晰的描述会导致混淆，并常常导致糟糕的用户体验，因为某些部分没有按照预期进行解释。