Entityデータモデル

この記事は英語の原文を日本語に翻訳したものです。原文: https://opentelemetry.io/docs/specs/otel/entities/data-model/

翻訳元: open-telemetry/opentelemetry-specification v1.60.0（コミット 29ae8c7）

ステータス: Development

Entityは、生成されたテレメトリー（トレース、メトリクス、プロファイル、ログ）に関連付けられる、関心の対象となるオブジェクトを表します。

例えば、OpenTelemetry SDKを使って生成されたテレメトリーは、通常serviceというEntityに関連付けられます。同様に、OpenTelemetryはホストのシステムメトリクスを定義しており、この場合メトリクスを関連付けたいEntityはhostです。

Entityは、生成されたテレメトリーに間接的に関連付けられることもあります。例えば、テレメトリーを生成するサービスは、そのサービスが実行されているプロセスとも関係があるため、serviceというEntityはprocessというEntityに関連していると言えます。プロセスは通常ホスト上でも実行されるため、processというEntityはhostというEntityに関連していると言えます。

[!NOTE] Entityの関係のモデリングは、今後の仕様策定作業の中で洗練されていく予定です。

以下のデータモデルは、Entityを記録する際の物理的な形式やエンコーディングとは関係なく、Entityの論理モデルを定義します。

必要十分な識別情報

一般に、テレメトリープロデューサーがIDを構成するために利用できるEntityの属性は複数あります。利用可能な属性のうち、EntityのIDには、そのEntityを一意に識別するために十分な最小限の属性の集合を含めるべきです。例えば、ホスト上のプロセスは（process.pid、process.start_time）という属性で一意に識別できます。これに加えてprocess.executable.nameのような属性をIDに追加することは不要であり、必要十分な識別情報の原則に反します。

再現可能な識別情報

Entityの識別属性は、そのEntityを観測する側が繰り返し取得できる値であるべきです（SHOULD）。例えば、processというEntityは、その識別情報がプロセス自身（SDK経由など）から生成されたか、同じホスト上で稼働するOpenTelemetry Collectorから生成されたか、あるいはそのプロセスを記述する他の何らかのシステムから生成されたかにかかわらず、同一の識別情報を持つべきです（同一のプロセスとして認識されるべきです）。

[!TIP] 複数の観測者にわたって再現可能な識別属性を実現する方法は数多くあります。多くの成功しているシステムは、中央のレジストリや知識ストアから識別情報を配布する方式に依っていますが、OpenTelemetryはあらゆる可能なシナリオに対応する必要があります。

識別属性

OpenTelemetryセマンティック規約は、定義済みのすべてのEntity種別について識別属性キーの集合を定義しなければなりません（MUST）。

識別属性の名前は、他のEntity種別との衝突を避けるため、そのEntity種別を接頭辞として使うべきです（SHOULD）。例えば、k8s.nodeというEntityは識別属性としてk8s.node.uidを使います。

Entityが複数の観測者によって送出されうる場合、以下の規則が適用されます。

• 同じEntityを報告する2つの独立した観測者は、すべての識別属性について同一の値を提供できなければなりません（MUST）。

• ある観測者が1つ以上の識別属性を確実に取得できない場合、その観測者はそのEntity種別を使ってテレメトリーを送出してはなりません（MUST NOT）。代わりに、次のいずれかを行うべきです（SHOULD）。

  1. 完全な属性集合を提供できる観測者に委ね、その観測者を信頼できる情報源として扱う。
  2. 確実に補完できる識別属性の集合を持つ別のEntity種別を送出する。

これにより、観測者間でEntityの識別情報が一貫し、曖昧にならないことが保証されます。

ResourceとEntity

OpenTelemetryのシグナル（メトリクス、ログ、トレース、プロファイル）は、k8s.cluster、k8s.node、host、containerなど、それぞれが特定のインフラストラクチャやランタイムのコンポーネントを表す1つ以上のEntityを添付できます。

以前は、Resourceデータモデルはシグナルごとにフラット化された属性に依存していました。Entityの導入により、テレメトリーは同一のシグナル内で複数の異なる、しかし互いに関連するコンポーネントを、それぞれ独自の識別情報と追加のメタデータを持つ形で表現できるようになります。EntityはResourceモデルと同じ属性のプールを利用します。これにより、データのより効率的なエンコーディングと転送が可能になるとともに、既存のResource属性との後方互換性も保たれます。

属性参照モデル

Entityは、テレメトリーシグナルのresourceセクション内で定義できます。Entityの識別属性および記述属性は、Resource内で定義された共有属性を参照します。例えば、OTLPでは、Entityは自身のキーバリューペアを直接持ちません。代わりに、OTLP 1.xとの後方互換性を保つため、resource.attributes内のキーを参照します。

この方式は、属性が特定の構造に縛られず、異なるEntityをまたいで柔軟に参照できる属性のフラット化をサポートするために設計されています。このモデルは以下を提供します。

• Entityを共有属性で識別・記述する方法。
• データの重複や不整合を避ける能力。
• エンコーディングと転送のためのより効率的な表現。

共有される記述属性の配置

属性のフラット化により、複数のEntityが同じ属性キーを参照しつつ、Entityごとに異なる値を持つことが可能になります。このような状況では、以下の規則が適用されます。

複数のEntityが、値が競合しうる同じ記述属性キーを共有している場合、その属性は論理的にいずれか1つのEntityにのみ属さなければなりません（MUST）。他のすべてのEntityはそれを参照すべきではありません（SHOULD NOT）。その属性は、テレメトリーシグナルに関連付けられたEntityに、トポロジーグラフ上で最も近い、最も具体的なEntityによって参照されなければなりません（MUST）。

例:

あるシグナルがk8s.clusterとk8s.nodeの両方のEntityを含み、両者が異なる値を持ちうる記述属性cloud.availability_zoneを持つ場合、より具体的なEntityであるk8s.nodeのEntityだけがこのキーを参照できます。

他のEntity（例えばk8s.cluster）は、所有関係の全体像が把握できる別のテレメトリーチャネル（例えばEntity Event）でこの属性を報告できます。

Entityの統合

Entityは、種別が同一であり、識別属性が完全に一致し、かつschema_urlが同一である場合に限り統合してもよい（MAY）ものとします。これは、両方のEntityが同一の識別属性キーを持ち、各キーについて値も一致していなければならないことを意味します。

統合可能性を確認するアルゴリズムの例を示します。

can_merge(current_entity, new_entity) {
  current_entity.type == new_entity.type &&
  current_entity.schema_url == new_entity.schema_url &&
  has_same_attributes(current_entity.identity, new_entity.identity)
}

Entityを統合する際、Descriptionに含まれるすべての属性は統合され、一方のEntityが「プライマリ」として扱われ、属性の値が競合する場合は「プライマリ」側のEntityの値が採用されます。

統合を行うアルゴリズムの例を示します。

merge(current_entity, new_entity) {
  if can_merge(current_entity, new_entity) {
    for attribute in new_entity.description {
      // New entity descriptions take precedence.
      current_entity.description.insert(attribute)
    }
  }
}

注: Entity同士のschema_urlが異なる場合、統合を試みる前に（可能であれば）同じスキーマバージョンに変換すべきです（SHOULD）。ここで定義した統合アルゴリズムは、Entity同士が既に同じスキーマバージョンにあることを前提としています。

Entityの例

このセクションは非規範的であり、データモデルを示す目的でのみ記載しています。

以下に、Entityの例と、それぞれが持つ典型的な識別属性、および関連付けられる可能性のある記述属性の例をいくつか示します。

注: これらの例はセマンティック規約から逸脱している場合があります（MAY）。

container

host

k8s.node

k8s.pod

service.instance