Resource
概述
资源是生成遥测数据的实体的表示。在 OpenTelemetry 中，所有信号都与一个资源相关联，从而能够实现同一来源数据的上下文关联。例如，如果我在一个 Span 中看到高延迟，我需要查看在观察到延迟时产生该 Span 的同一实体的指标。
资源为可观测性提供了两个重要方面
- 它必须识别产生遥测数据的实体。
- 它应该允许用户确定该实体在其基础设施中的位置。
标识
资源提供了一种自然的方式来理解“什么”产生了影响，并评估来自同一来源的其他信号。这是通过将一组相同的标识属性附加到 OpenTelemetry SDK 中生成的所有遥测数据来实现的。
资源标识为可观测性信号提供了一个自然的枢纽点，这是 OpenTelemetry 中一种关键的关联类型。
导航
资源和属性的设计隐含地确保用户能够导航其基础设施、工具、UI 等，以找到遥测数据所报告的*同一*实体。例如，实际上我们可以看到资源包含多个实体，例如
- 一个进程
- 一个容器
- 一个 Kubernetes Pod 名称
- 一个命名空间
- 一个部署
通过包含这些实体的标识属性，我们可以帮助用户通过 `kubectl` 或 Kubernetes UI 导航，以找到生成遥测数据的特定进程。这与能够唯一区分一个进程与其他进程同样重要。
提示
可观测性信号应该是可操作的。知道一个进程正在挣扎，不如能够扩展部署以减轻该进程的负载有用。
如果资源唯一重要的事情是标识，我们可以简单地使用 UUID。然而，这将依赖于其他易于访问的系统来提供这些 UUID 的人类可读的理解。OpenTelemetry 提供了一种模型，其中可以选择一个完全仅 UUID 的解决方案，但默认采用*混合*方法，其中资源同时提供标识和导航。
这就引出了下一个概念：根据系统需求调整身份。
缩放
在 OpenTelemetry 中，我们希望为用户提供灵活性，让他们决定需要*随*可观测性信号发送哪些信息，以及哪些信息可以在以后进行联接。我们将此称为“缩放身份”，用户可以决定 OpenTelemetry 资源在传输时的*大小*（相应地，数据点在存储时的大小，取决于存储解决方案）。
例如，在极端情况下，OpenTelemetry 可以为每个生成遥测数据的系统合成一个 UUID。资源和实体的所有标识属性都可以通过一个具有已知与此 UUID 关系的侧通道发送。虽然这会优化遥测数据的运行时生成和发送，但代价是下游存储系统需要在摄取时或查询时将数据重新联接在一起。对于高性能用例，例如警报，这些联接可能非常昂贵。
实际上，用户通过 SDK 和收集器中的资源检测配置来控制资源标识。希望最小化标识的用户将只将资源检测限制到例如 `service.instance.id`。一些用户会高度自定义资源检测，并添加许多概念。