# リソース

> Source: https://www.ymotongpoo.com/works/otel-specs-ja/spec/resource/


## 概要

**リソース**は、テレメトリーが生成される対象となる観測対象エンティティを表します。OpenTelemetryでは、すべてのシグナルがリソースに関連付けられ、同じ発生源から得られたデータの文脈的な相関を可能にします。例えば、あるスパンで高いレイテンシーを観測した場合、そのレイテンシーが観測された時間帯について、同じエンティティのメトリクスを確認する必要があります。

> [!NOTE]
> テレメトリーを*技術的に発する*エンティティと、リソースによって*記述される*エンティティは、必ずしも同じではありません。コード変更なしに実行中のプロセスを観測するeBPFベースのエージェントのような自動計装の場面では、計装エージェントが観測対象のワークロードに代わってテレメトリーを生成します。このような場合、リソースは*観測対象*のエンティティ（例えば計装対象のサービスやプロセス）を記述するものであり、エージェント自身を記述するものではありません。`telemetry.sdk.name`や`telemetry.distro.name`のような計装ツールに関する属性は、それぞれのセマンティック規約に従って付与されるべきであり、観測対象のエンティティを識別するために使うべきではありません。

リソースはオブザーバビリティにとって2つの重要な側面を提供します。

- テレメトリーが生成される対象の観測対象エンティティを識別しなければなりません（MUST）。
- そのエンティティがユーザーのインフラストラクチャー内のどこに存在するかをユーザーが判断できるようにするべきです（SHOULD）。

### アイデンティティ

リソースは、「何が」ある効果を生み出したのかを理解し、同じ発生源の他のシグナルを評価するための自然な手段を提供します。これは、OpenTelemetry SDKで生成されるすべてのテレメトリーに、同一の識別属性の集合を付与することで実現されます。

リソースのアイデンティティは、OpenTelemetryにおける相関の主要な形態である、オブザーバビリティシグナルの自然な軸を提供します。

### ナビゲーション

リソースと属性の設計に暗黙的に含まれているのは、ユーザーが自分たちのインフラストラクチャーやツール、UIなどをナビゲートして、テレメトリーが報告する対象と*同一の*エンティティを見つけられるようにすることです。例えば、実際にはリソースが以下のように複数のエンティティを含むことがあります。

- プロセス
- コンテナ
- Kubernetesのpod名
- 名前空間
- デプロイメント

これらそれぞれの識別属性を含めることで、ユーザーは`kubectl`やKubernetesのUIを通じて、テレメトリーを生成している特定のプロセスを見つけられます。これは、あるプロセスを他のプロセスと一意に識別できることと同じくらい重要です。

> [!TIP]
> オブザーバビリティシグナルはアクションにつながるべきです（SHOULD）。あるプロセスが苦しんでいることを知るだけでは、そのプロセスの負荷を下げるためにデプロイメントをスケールアップできることに比べて有用性が低いといえます。

リソースにとって重要なのがアイデンティティだけであれば、単にUUIDを使うこともできます。しかしその場合、これらのUUIDを人間が理解しやすい形にするための、別のアクセスしやすいシステムに依存することになります。OpenTelemetryは、UUIDのみによる解決策を選択することも可能なモデルを提供しつつ、既定ではアイデンティティとナビゲーションの両方を提供する*ブレンド*されたアプローチを採用しています。

このことから、次の概念である「システムのニーズに合わせてアイデンティティをテレスコーピングする」という考え方につながります。

### テレスコーピング

OpenTelemetryでは、オブザーバビリティシグナルと*一緒に*送信する必要がある情報と、後から結合できる情報をユーザー自身が決められる柔軟性を提供したいと考えています。これを「アイデンティティのテレスコーピング」と呼びます。ユーザーは、OpenTelemetryのリソースがワイヤー上でどれだけ*小さく*、あるいは*大きく*なるか（そして対応して、ストレージソリューションによってはデータポイントが保存時にどれだけ大きくなるか）を決められます。

例えば極端な例として、OpenTelemetryはテレメトリーを生成するすべてのシステムに対してUUIDを合成することもできます。リソースとエンティティに関するすべての識別属性は、このUUIDとの既知の関係を持つサイドチャネルで送信できます。これはテレメトリーの実行時生成と送信を最適化できる一方で、下流のストレージシステムが取り込み時またはクエリ時にデータを再び結合する必要があるという代償を伴います。アラートのような高パフォーマンスを要求する用途では、こうした結合のコストは高くつくことがあります。

実際には、ユーザーはSDKとコレクターにおけるリソース検出の設定を通じてリソースのアイデンティティを制御します。最小限のアイデンティティを望むユーザーは、例えばリソース検出を`service.instance.id`だけに限定します。一部のユーザーは、多くの概念を追加してリソース検出を大きくカスタマイズします。

## 仕様

- [データモデル](/works/otel-specs-ja/spec/resource/data-model/)
- [リソースSDK](/works/otel-specs-ja/spec/resource/sdk/)

- [リソースのデータモデル](/works/otel-specs-ja/spec/resource/data-model/)
- [リソースSDK](/works/otel-specs-ja/spec/resource/sdk/)