リソース
この記事は英語の原文を日本語に翻訳したものです。原文: https://opentelemetry.io/docs/specs/otel/resource/
翻訳元: open-telemetry/opentelemetry-specification v1.60.0（コミット 29ae8c7）
概要
リソースは、テレメトリーが生成される対象となる観測対象エンティティを表します。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だけに限定します。一部のユーザーは、多くの概念を追加してリソース検出を大きくカスタマイズします。