メッセージングスパンに関するセマンティック規約

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

翻訳元: open-telemetry/semantic-conventions v1.44.0（コミット e10a930）

ステータス: Development

[!IMPORTANT]
v1.24.0の本文書以前を使っている既存のメッセージング計装は、次に従うべきです。
メッセージングセマンティック規約が安定版として宣言されるまで、デフォルトで発行するメッセージング規約のバージョンを変更してはなりません（SHOULD NOT）。規約には、属性、メトリクス名、スパン名、スパン種別、計測単位などが含まれますが、これらに限定されません。
既存のメジャーバージョンにおいて、カテゴリー別の値をカンマ区切りで列挙するリストとして環境変数 OTEL_SEMCONV_STABILITY_OPT_IN を導入すべきです（SHOULD）（例: http、databases、messaging）。値の一覧は次のとおりです。
messaging - 新しい安定版のメッセージング規約を発行し、それまで計装が発行していた古い実験的なメッセージング規約の発行を停止します。
messaging/dup - 古い規約と安定版の規約の両方を発行し、円滑な移行を可能にします。
これらの値がいずれも指定されていない場合のデフォルトの動作は、その計装がそれまで発行していた古い実験的なメッセージング規約のバージョンをそのまま発行し続けることです。
注記: 両方の値が指定されている場合、messaging/dup は messaging よりも優先されます。
両方の規約セットを発行し始めてから少なくとも6か月間は、既存のメジャーバージョンを（少なくともセキュリティパッチの適用という形で）維持すべきです（SHOULD）。
次のメジャーバージョンでは、この環境変数を削除すべきです（SHOULD）。
リストに messaging/dup が含まれる場合、スパン名やスパン種別のような「単一の」値を持つ概念については、新しい安定版の値を発行すべきです（SHOULD）。

定義

メッセージ

メッセージングシステムは、例えばHTTPほど標準化されていませんが、次の定義は、同様の概念を持つほとんどのメッセージングシステムに当てはまると仮定します（名称の多くはJMSから借用しています）。

メッセージとは、空である可能性のある本文を持つエンベロープです。このエンベロープは、しばしばキーバリュー形式で、追加のメタデータを伝える手段を提供することがあります。

メッセージは、メッセージプロデューサーによって次に対して送信されます。

物理的には、何らかのメッセージブローカー（単一のサーバー、クラスター、またはIPCを介してアクセスされるローカルプロセスなどが該当します）。ブローカーは、実際の配送、再配送、永続化などを処理します。一部のメッセージングシステムでは、ブローカーが（一部の）メッセージコンシューマーと同一またはコロケーションされている場合があります。 Apache Kafkaでは、メッセージが書き込まれる物理的なブローカーは、パーティションの数と、そのレコードが書き込まれるパーティションのリーダーであるブローカーによって決まります。
論理的には、何らかの特定のメッセージ宛先。

メッセージは、プロトコルの配送方式に応じて、0、1、または複数のコンシューマーに配送されることがあります。

Producer

「Producer」とは、メッセージを作成し送信する特定のインスタンス、プロセス、またはデバイスです。「送信（Sending）」とは、メッセージまたはメッセージのバッチを中継者（intermediary）またはコンシューマーに転送する処理です。一部の中継者は「発行（publishing）」を送信の同義語として使用します。

Consumer

「Consumer」はメッセージを受信し、それに対して処理を行います。コンテキストとデータを使って何らかのロジックを実行し、それが新たなイベントの発生につながることがあります。

Consumerはメッセージを受信し、処理し、決済します。「受信（Receiving）」とは中継者からメッセージを取得する処理、「処理（processing）」とはメッセージに含まれる情報に基づいて動作する処理、「決済（settling）」とはメッセージが正常に処理されたことを中継者に通知する処理です。

Intermediary

「Intermediary」はメッセージを受信し、それを次の受信者（別のIntermediaryまたはConsumer）に転送します。

宛先

宛先は、メッセージングシステム内で、メッセージが送信され、また消費される対象となるエンティティを表します。

宛先は通常、そのメッセージングシステムのインスタンス内でその名前によって一意に識別されます。宛先名の例としては、URLや単純な単語識別子などが挙げられます。

宛先の典型例としては、Kafkaのトピック、RabbitMQのキューやトピックなどがあります。

メッセージの消費

メッセージの消費は、複数のステップで行われることがあります。まず低レベルなメッセージのConsumerへの受信が行われ、その後にメッセージの論理的な処理が行われます。多くの場合、メッセージを待つこと自体は特に興味深いものではなく、メッセージを受信した際にハンドラー関数を呼び出すだけのフレームワーク内に隠蔽されます（TCPポートで着信するHTTPメッセージをリッスンすること自体が特に興味深いものではないのと同様です）。

Consumerグループ

Consumerグループは、メッセージのConsumerに対する論理的なグルーピングを提供します。メッセージングシステムはこれを使って、グループ内でのメッセージ消費の負荷分散、複数種類のConsumerへのメッセージのブロードキャスト、各グループのオフセットの独立した管理を行います。その結果、異なるグループのConsumerは、異なる速度や異なる設定でメッセージを受信できます。

サブスクリプション

サブスクリプションは、メッセージングシステム内で、複数のConsumerがトピックからメッセージを受信できるようにするエンティティを表します。この際、負荷分散、耐久性、フィルタリング、その他システム固有の機能を含む、サブスクリプション固有の消費挙動に従います。

名前付きサブスクリプションとConsumerグループは、負荷分散やブロードキャストといった類似のシナリオのためにメッセージングシステムが使用する、意味的に異なる機構です。

会話

一部のメッセージングシステムでは、メッセージは、以前に送信された特定の別のメッセージに応答する、1つ以上の返信メッセージを受け取ることがあります。このような返信関係によってグループ化されたすべてのメッセージは会話と呼ばれます。このグルーピングは通常、何らかの「In-Reply-To:」メタ情報や、明示的な会話ID（相関IDと呼ばれることもあります）によって行われます。会話は複数のメッセージ宛先にまたがることがあります（例えば、トピックで開始し、一時的な1対1のキューで継続する場合など）。

一時的な宛先と匿名の宛先

一部のメッセージングシステムは、一時的な宛先（多くの場合、一時的なキューのみ）という概念をサポートしています。これは、特定の通信相手の集合（多くの場合1対1）や会話のためだけに確立されるものです。このような宛先はしばしば名前を持たない（匿名）か、自動生成された名前を持ちます。

規約

これらの定義を踏まえ、この節の残りの部分では、メッセージングシステムとのやり取りを記述するスパンに関するセマンティック規約を説明します。

コンテキスト伝搬

メッセージは、プロデューサーからコンシューマーに伝搬される際、1つ以上の中継者内のさまざまなコンポーネントやレイヤーを通過することがあります。既存のコンテキスト伝搬機構を使ってコンシューマー側のトレースをプロデューサー側のトレースと関連付けられるようにするには、すべてのコンポーネントがこの連鎖の中でコンテキストを伝搬しなければなりません。

メッセージングシステム自体が、メッセージがプロデューサーからコンシューマーへ移動する際にそのメッセージを追跡することがあります。そのような追跡はトランスポート層をカバーしますが、プロデューサーとコンシューマーを関連付ける助けにはなりません。プロデューサーとコンシューマーを直接関連付けるには、メッセージとともに伝搬される別のコンテキストが必要です。

メッセージの作成コンテキストは、基盤となるメッセージングトランスポート機構やその計装に関係なく、メッセージのプロデューサーとコンシューマーを関連付け、両者の間の依存関係をモデル化できるようにします。

メッセージ作成コンテキストはプロデューサーによって作成され、コンシューマーに伝搬されるべきです（SHOULD）。メッセージ作成コンテキストがメッセージに付与され、伝搬されない場合、コンシューマー側のトレースをプロデューサー側のトレースと直接関連付けることはできません。

プロデューサーは、各メッセージにメッセージ作成コンテキストを付与すべきです（SHOULD）。可能であれば、メッセージ作成コンテキストは中継者によって変更されないような形で付与すべきです（SHOULD）。

本文書は、作成コンテキストがメッセージに対してどのように付与・抽出されるかについての正確な機構を規定していません。これらの規約の将来のバージョンでは、Trace Context: AMQPプロトコルやTrace Context: MQTTプロトコルを含む（ただしこれらに限定されない）業界標準に従い、それらの標準が安定した状態に達した時点で明確な推奨事項を示す予定です。

スパン名

メッセージングスパンは、スパン名に関する全体的なガイドラインに従うべきです（SHOULD）。

スパン名は {messaging.operation.name} {destination} にすべきです（SHOULD）（{destination}プレースホルダーの正確な定義は以下を参照してください）。

個々のメッセージングシステムに関するセマンティック規約は、異なるスパン名の形式を指定してもかまいません（MAY）。その場合、特定のメッセージング技術に関するセマンティック規約でそれを文書化しなければなりません（MUST）。

{destination}は、その操作が実行される対象のエンティティを記述すべきであり（SHOULD）、アクセス可能であれば、次のいずれかの値に従うべきです（SHOULD）。

messaging.destination.template が利用可能な場合はそれを使用すべきです（SHOULD）。
宛先が一時的でも匿名でもないことが分かっている場合は messaging.destination.name を使用すべきです（SHOULD）。
server.address:server.port は、特定の宛先を対象としない操作にのみ使用すべきです（SHOULD）。

特定の操作について、対応する（低カーディナリティの）{destination} の値が利用できない場合、計装は {destination} を省略すべきです（SHOULD）。

例:

publish shop.orders
send shop.orders
subscribe shop.orders
ack shop.orders
nack print_jobs
process topic with spaces
settle AuthenticationRequest-Conversations

操作種別

これらのセマンティック規約では、メッセージに関連する次の操作種別が定義されています。

Operation type	Description
`create`	メッセージが作成され、または送信のためにクライアントライブラリに渡されます。「Create」スパンは常に単一のメッセージを指し、バッチ送信シナリオにおいてメッセージに一意の作成コンテキストを提供するために使用されます。
`send`	1つ以上のメッセージが中継者への送信のために提供されます。単一のメッセージが送信される場合、「Send」スパンのコンテキストを作成コンテキストとして使用でき、「Create」スパンを作成する必要はありません。
`receive`	1つ以上のメッセージがコンシューマーによって要求されます。この操作はpullベースのシナリオを指し、コンシューマーがメッセージングSDKのメソッドを明示的に呼び出してメッセージを受信します。
`process`	1つ以上のメッセージがコンシューマーによって処理されます。
`settle`	1つ以上のメッセージが決済されます。

スパン種別

スパン種別は、そのスパンが記述する操作種別に基づいて、次の表に従って設定すべきです（SHOULD）。

Operation type	Span kind
`create`	`PRODUCER`
`send`	「Send」スパンのコンテキストが作成コンテキストとして使用される場合は `PRODUCER`、それ以外の場合は `CLIENT`。
`receive`	`CLIENT`
`process`	`CONSUMER`
`settle`	`CLIENT`

この表に従ってスパン種別を設定することで、分析ツールは追加のセマンティックなヒントを必要とせずに、スパンとスパン間の関係を解釈できます。

スパンステータス

スパンステータスの記録方法の詳細については、エラーの記録の文書を参照してください。

トレース構造

Producer spans

「Create」スパンは、メッセージが作成されるか、送信を担当するクライアントライブラリやその他のコンポーネントに渡されたときに作成されてもかまいません（MAY）。単一の「Create」スパンは、単一のメッセージのみを説明すべきです（SHOULD）。「Send」スパンは、メッセージを中継者に送信または発行する操作について作成すべきです（SHOULD）。単一の「Send」スパンは、単一のメッセージ、または（バッチでメッセージを送信する場合の）複数のメッセージを説明できます。

ユーザーがメッセージにカスタムの作成コンテキストを提供する場合、そのコンテキストは変更されるべきではなく（SHOULD NOT）、「Create」スパンは作成されるべきではありません（SHOULD NOT）。それ以外の場合、あるメッセージについて「Create」スパンが存在するなら、そのコンテキストをメッセージに注入すべきです（SHOULD）。「Create」スパンが存在せず、カスタムの作成コンテキストもメッセージに注入されない場合、関連する「Send」スパンのコンテキストをメッセージに注入すべきです（SHOULD）。

「Send」スパンは、「Create」スパンから、またはカスタムの作成コンテキストとして、メッセージに注入された作成コンテキストに常にリンクすべきです（SHOULD）。

常に単一のメッセージを送信するライブラリAPIを計装する場合、「Create」スパンを作らずに「Send」スパンを作成することが推奨されます（RECOMMENDED）。

通常バッチで操作するライブラリAPIを計装する場合、「Send」スパンとともに各メッセージについて「Create」スパンを作成することが推奨されます（RECOMMENDED）。また、「Create」スパンの作成を無効化できる設定オプションを提供することも推奨されます（RECOMMENDED）。

Consumer spans

「Receive」スパンは、アプリケーションコードによって開始される操作（pullベースのシナリオ）としてメッセージをアプリケーションに渡す操作について作成すべきです（SHOULD）。

「Process」スパンは、アプリケーションコードによって開始されない操作（pushベースのシナリオ）としてメッセージをアプリケーションに渡す操作について作成すべきです（SHOULD）。このような「Process」スパンは、通常はコールバックまたはハンドラーである、その操作の期間をカバーします。

「Process」スパンは、メッセージを処理する操作について、pullベースのシナリオにおいて「Receive」スパンに加えて作成されてもかまいません（MAY）。このようなスパンは、アプリケーションコードによって、またはメッセージングSDKの上に構築された抽象化レイヤーによって作成される場合があります。

メッセージングライブラリやSDKによって事前に取得（prefetch）またはキャッシュされ、呼び出し元に転送されるまでのメッセージについて、「Receive」スパンや「Process」スパンを作成してはなりません（MUST NOT）。

単一の「Process」スパンまたは「Receive」スパンは、単一のメッセージ、メッセージのバッチ、またはメッセージが1件も存在しない場合（メッセージが受信されなかったことが伝えられた場合）を説明できます。それが説明する各メッセージについて、「Process」スパンまたは「Receive」スパンは、そのメッセージの作成コンテキストにリンクすべきです（SHOULD）。

[!IMPORTANT] これらの規約は、プロデューサーとコンシューマーを関連付けるデフォルトの機構としてスパンリンクを使用します。その理由は次のとおりです。
多種多様なメッセージングシステムのモデルが存在する中で、保証できる唯一の一貫したトレース構造だからです。
スパンは単一の親しか持てないため、バッチシナリオにおいてプロデューサーとコンシューマーを関連付けられる唯一の選択肢だからです。
HTTPサーバースパンのような別のアンビエントコンテキストのスコープ内でメッセージ消費が発生しうる場合に、プロデューサーとコンシューマーを関連付けられる唯一の選択肢だからです。

「Settle」スパンは、手動または自動でトリガーされるすべての決済操作について作成すべきです（SHOULD）。単一の「Settle」スパンは、単一のメッセージ、または（メッセージがバッチとして決済に渡される場合の）複数のメッセージを説明できます。それが説明する各メッセージについて、「Settle」スパンは、そのメッセージの作成コンテキストにリンクしてもかまいません（MAY）。

Message creation context as parent of “Process” span

単一メッセージのシナリオに限り、「Process」スパンは、メッセージの作成コンテキストを自身の親として使用してもかまいません（MAY）。これにより、プロデューサーとコンシューマーの間で直接の親子関係を実現できます。計装は、「Process」スパンの親としてメッセージ作成コンテキストを使用するかどうかを文書化すべきであり（SHOULD）、ユーザーがこの振る舞いを制御できる設定オプションを提供してもかまいません（MAY）。

処理が別のスパンのスコープ内で発生する場合、「Process」スパンの親として（デフォルトで）メッセージ作成コンテキストを使用することは推奨されません（NOT RECOMMENDED）。

計装が、別の有効なアンビエントコンテキストのスコープ内で「Process」スパンの親としてメッセージ作成コンテキストを使用する場合、メッセージ処理とそのコンテキストとの関連付けを保持するために、そのアンビエントコンテキストを「Process」スパンへのリンクとして追加すべきです（SHOULD）。

例えば、メッセージングブローカーが、HTTPサーバーとメッセージングの両方の計装が有効なコンシューマーアプリケーションに対して、HTTP経由でメッセージをプッシュする場合を考えます。

このとき、メッセージング計装は、次のいずれかの方法で「Process」スパンを作成します。

「Process」スパンをHTTPサーバースパンコンテキストの子とし、メッセージ作成コンテキストへのリンクを持たせる。これがデフォルトの振る舞いです。
「Process」スパンをメッセージ作成コンテキストの子とし、2つのリンク（メッセージ作成コンテキストへのリンクとHTTPサーバースパンコンテキストへのリンク）を持たせる。これはオプトインの振る舞いです。

Messaging spans

以下の節では、操作種別ごとに1つのスパンを定義します。個々のメッセージングシステムに関するセマンティック規約は、システム固有の属性と要求レベルを追加することでこれらのスパンを詳細化します。

これらのスパンで使用される属性は、次の名前空間に整理されています。

messaging.message: 個々のメッセージを記述する属性を含みます。
messaging.destination: メッセージが送信される論理的なエンティティを記述する属性を含みます。詳細は宛先を参照してください。
messaging.batch: バッチ操作を記述する属性を含みます。
messaging.consumer: メッセージを消費するアプリケーションインスタンスを記述する属性を含みます。詳細はConsumerを参照してください。

メッセージングシステム固有の属性は、対応する messaging.{system} 名前空間で定義しなければなりません（MUST）。

Createスパン

Status:

送信のためにクライアントライブラリに渡されるか、作成されるメッセージを記述します。

「Create」スパンは常に単一のメッセージを指し、バッチ送信シナリオにおいてメッセージに一意の作成コンテキストを提供するために使用されます。「Create」スパンは、それにリンクするクライアントの「Send」スパン（messaging.send.client）とともにのみ使用されます。「Send」スパン自体が作成コンテキストとして機能する場合は、代わりにプロデューサーの「Send」スパン（messaging.send.producer）を使用し、「Create」スパンは省略します。詳細はProducer spansを参照してください。

Span kind は PRODUCER にすべきです（SHOULD）。

Span status はエラーの記録の文書に従うべきです（SHOULD）。

Attributes:

Key	Requirement Level	Value Type	Description	Example Values
`messaging.operation.name`	`Required`	string	メッセージング操作のシステム固有の名前。	`create`
`messaging.system`	`Required`	string	クライアント計装によって識別されるメッセージングシステム。[1]	`activemq`; `aws.sns`; `aws_sqs`
`error.type`	`Conditionally Required` メッセージング操作が失敗した場合に限る。	string	操作が終了したエラーのクラスを記述します。[2]	`amqp:decode-error`; `KAFKA_STORAGE_ERROR`; `channel-error`
`messaging.destination.name`	`Conditionally Required` [3]	string	メッセージの宛先名 [4]	`MyQueue`; `MyTopic`
`messaging.destination.template`	`Conditionally Required` [5]	string	メッセージング宛先名の低カーディナリティな表現 [6]	`/customers/{customerId}`
`messaging.operation.type`	`Conditionally Required` 適用可能な場合。	string	メッセージング操作の種別を識別する文字列。[7]	`create`
`messaging.destination.partition.id`	`Recommended` 適用可能な場合。	string	メッセージが送信または受信されるパーティションの識別子。`messaging.destination.name` 内で一意。	`1`
`messaging.message.conversation_id`	`Recommended`	string	メッセージが属する会話を識別する会話ID。文字列として表現されます。「Correlation ID」と呼ばれることもあります。	`MyConversationId`
`messaging.message.id`	`Recommended` スパンが単一メッセージに対する操作を記述する場合。	string	メッセージングシステムがメッセージの識別子として使用する値。文字列として表現されます。	`452a7c7c7c7048c2f887f61572b18fc2`
`server.address`	`Recommended`	string	利用可能であればリバースDNSルックアップなしのサーバードメイン名。それ以外の場合はIPアドレスまたはUNIXドメインソケット名。[8]	`example.com`; `10.1.2.80`; `/tmp/my.sock`
`server.port`	`Recommended`	int	サーバーのポート番号。[9]	`80`; `8080`; `443`
`messaging.message.body.size`	`Opt-In`	int	メッセージ本文のバイト数。単一メッセージの操作を記述するスパンにのみ適用されます。[10]	`1439`
`messaging.message.envelope.size`	`Opt-In`	int	メッセージ本文とメタデータのバイト数。[11]	`2738`

[1] messaging.system: 実際のメッセージングシステムは、クライアントが認識しているものと異なる場合があります。例えば、Kafkaクライアントライブラリを使ってAzure Event Hubsと通信する場合、計装の知識に基づいて messaging.system は kafka に設定されます。

[2] error.type: error.type は予測可能であるべきであり（SHOULD）、低カーディナリティであるべきです（SHOULD）。

error.type がある型（例えば例外の型）に設定される場合、そのアーティファクト内で型を識別する正規のクラス名を使用すべきです（SHOULD）。

記録されるエラー型が、失敗の分類にとって意味を持たないラッパーである場合、計装は代わりに内部エラーの型を使用してもかまいません（MAY）。例えば、Goでは、%w を使って fmt.Errorf で作成されたエラーは、ラッパー型が失敗の分類に役立たない場合、アンラップされてもかまいません（MAY）。

計装は、報告するエラーの一覧を文書化すべきです（SHOULD）。

1つの計装ライブラリ内での error.type のカーディナリティは低くあるべきです。複数の計装ライブラリやアプリケーションからのデータを集約するテレメトリーの利用者は、追加のフィルターが適用されないクエリ時には error.type が高カーディナリティになることを想定しておくべきです。

操作が正常に完了した場合、計装は error.type を設定するべきではありません（SHOULD NOT）。

特定のドメインが独自のエラー識別子の集合（HTTPやRPCのステータスコードなど）を定義している場合、次のようにすることが推奨されます（RECOMMENDED）。

ドメイン固有の属性を使用する
ドメイン固有の集合内で定義されているかどうかにかかわらず、すべてのエラーを捕捉するために error.type を設定する

[3] messaging.destination.name: スパンが単一メッセージに対する操作を記述する場合、またはその値がバッチ内のすべてのメッセージに当てはまる場合。

[4] messaging.destination.name: ブローカー内の特定のキュー、トピック、またはその他のエンティティを一意に識別すべきです（SHOULD）。ブローカーにそのような概念がない場合は、ブローカー自体を一意に識別すべきです（SHOULD）。

[5] messaging.destination.template: 利用可能な場合。宛先名の低カーディナリティが保証されない限り、計装は messaging.destination.name をテンプレートとして使用してはなりません（MUST NOT）。

[6] messaging.destination.template: 宛先名はテンプレートから構築されることがあります。例えば、ユーザー名や商品IDを含む宛先名です。この場合、宛先名自体は高カーディナリティですが、その基盤となるテンプレートは低カーディナリティであり、グルーピングや集計に効果的に使用できます。

[7] messaging.operation.type: create に設定すべきです（SHOULD）。

[8] server.address: ブローカーの、利用可能であればリバースDNSルックアップなしのサーバードメイン名。それ以外の場合はIPアドレスまたはUNIXドメインソケット名。

[9] server.port: クライアント側から観測され、かつ中継者を経由して通信している場合、server.port は、利用可能であれば、その中継者の背後にあるサーバーポート（例えばプロキシ経由の場合など）を表すべきです（SHOULD）。

[10] messaging.message.body.size: これは圧縮後または圧縮前のいずれのボディサイズも指すことができます。両方のサイズが分かっている場合は、圧縮前のボディサイズを使用すべきです（SHOULD）。

[11] messaging.message.envelope.size: これは圧縮後または圧縮前のいずれのサイズも指すことができます。両方のサイズが分かっている場合は、圧縮前のサイズを使用すべきです（SHOULD）。

次の属性は、サンプリング判断に重要となりうるため、（いずれかが提供される場合）スパン作成時点で提供すべきです（SHOULD）。

error.type には、次のよく知られた値の一覧があります。いずれかが該当する場合はその値を使用しなければならず（MUST）、それ以外の場合は独自の値を使ってもかまいません（MAY）。

Value	Description	Stability
`_OTHER`	計装がカスタム値を定義していない場合に使用されるフォールバックのエラー値。

messaging.operation.type には、次のよく知られた値の一覧があります。いずれかが該当する場合はその値を使用しなければならず（MUST）、それ以外の場合は独自の値を使ってもかまいません（MAY）。

Value	Description	Stability
`create`	メッセージが作成されます。「Create」スパンは常に単一のメッセージを指し、バッチ送信シナリオにおいてメッセージに一意の作成コンテキストを提供するために使用されます。
`process`	1つ以上のメッセージがコンシューマーによって処理されます。
`receive`	1つ以上のメッセージがコンシューマーによって要求されます。この操作はpullベースのシナリオを指し、コンシューマーがメッセージングSDKのメソッドを明示的に呼び出してメッセージを受信します。
`send`	1つ以上のメッセージが中継者への送信のために提供されます。単一のメッセージが送信される場合、「Send」スパンのコンテキストを作成コンテキストとして使用でき、「Create」スパンを作成する必要はありません。
`settle`	1つ以上のメッセージが決済されます。

messaging.system には、次のよく知られた値の一覧があります。いずれかが該当する場合はその値を使用しなければならず（MUST）、それ以外の場合は独自の値を使ってもかまいません（MAY）。

Value	Description	Stability
`activemq`	Apache ActiveMQ
`aws.sns`	Amazon Simple Notification Service（SNS）
`aws_sqs`	Amazon Simple Queue Service（SQS）
`eventgrid`	Azure Event Grid
`eventhubs`	Azure Event Hubs
`gcp_pubsub`	Google Cloud Pub/Sub
`jms`	Java Message Service
`kafka`	Apache Kafka
`pulsar`	Apache Pulsar
`rabbitmq`	RabbitMQ
`rocketmq`	Apache RocketMQ
`servicebus`	Azure Service Bus

Sendスパン（プロデューサー）

Status:

「Send」スパンのコンテキストがメッセージ作成コンテキストとして使用される、1つ以上のメッセージが中継者に送信されることを記述します。

別途「Create」スパンが存在せず、「Send」スパンのコンテキストが作成コンテキストとしてメッセージに注入される場合にこのスパンを使用します。詳細はProducer spansを参照してください。

Span kind は PRODUCER にすべきです（SHOULD）。

Span status はエラーの記録の文書に従うべきです（SHOULD）。

Attributes:

Key	Requirement Level	Value Type	Description	Example Values
`messaging.operation.name`	`Required`	string	メッセージング操作のシステム固有の名前。	`send`; `publish`
`messaging.system`	`Required`	string	クライアント計装によって識別されるメッセージングシステム。[1]	`activemq`; `aws.sns`; `aws_sqs`
`error.type`	`Conditionally Required` メッセージング操作が失敗した場合に限る。	string	操作が終了したエラーのクラスを記述します。[2]	`amqp:decode-error`; `KAFKA_STORAGE_ERROR`; `channel-error`
`messaging.batch.message_count`	`Conditionally Required` [3]	int	バッチ処理操作のスコープ内で送信、受信、または処理されたメッセージの数。[4]	`0`; `1`; `2`
`messaging.destination.name`	`Conditionally Required` [5]	string	メッセージの宛先名 [6]	`MyQueue`; `MyTopic`
`messaging.destination.template`	`Conditionally Required` [7]	string	メッセージング宛先名の低カーディナリティな表現 [8]	`/customers/{customerId}`
`messaging.operation.type`	`Conditionally Required` 適用可能な場合。	string	メッセージング操作の種別を識別する文字列。[9]	`send`
`messaging.client.id`	`Recommended`	string	メッセージを消費または生成するクライアントの一意の識別子。	`client-5`; `myhost@8742@s8083jm`
`messaging.destination.partition.id`	`Recommended` 適用可能な場合。	string	メッセージが送信または受信されるパーティションの識別子。`messaging.destination.name` 内で一意。	`1`
`messaging.message.conversation_id`	`Recommended`	string	メッセージが属する会話を識別する会話ID。文字列として表現されます。「Correlation ID」と呼ばれることもあります。	`MyConversationId`
`messaging.message.id`	`Recommended` スパンが単一メッセージに対する操作を記述する場合。	string	メッセージングシステムがメッセージの識別子として使用する値。文字列として表現されます。	`452a7c7c7c7048c2f887f61572b18fc2`
`network.peer.address`	`Recommended` このメッセージングシステムに適用可能な場合。	string	操作が実行されたメッセージング中継者ノードのピアアドレス。[10]	`10.1.2.80`; `/tmp/my.sock`
`network.peer.port`	`Recommended` `network.peer.address` が設定されている場合に限る。	int	操作が実行されたメッセージング中継者ノードのピアポート。	`65123`
`server.address`	`Recommended`	string	利用可能であればリバースDNSルックアップなしのサーバードメイン名。それ以外の場合はIPアドレスまたはUNIXドメインソケット名。[11]	`example.com`; `10.1.2.80`; `/tmp/my.sock`
`server.port`	`Recommended`	int	サーバーのポート番号。[12]	`80`; `8080`; `443`
`messaging.message.body.size`	`Opt-In`	int	メッセージ本文のバイト数。単一メッセージの操作を記述するスパンにのみ適用されます。[13]	`1439`
`messaging.message.envelope.size`	`Opt-In`	int	メッセージ本文とメタデータのバイト数。[14]	`2738`

[2] error.type: error.type は予測可能であるべきであり（SHOULD）、低カーディナリティであるべきです（SHOULD）。

error.type がある型（例えば例外の型）に設定される場合、そのアーティファクト内で型を識別する正規のクラス名を使用すべきです（SHOULD）。

計装は、報告するエラーの一覧を文書化すべきです（SHOULD）。

操作が正常に完了した場合、計装は error.type を設定するべきではありません（SHOULD NOT）。

ドメイン固有の属性を使用する
ドメイン固有の集合内で定義されているかどうかにかかわらず、すべてのエラーを捕捉するために error.type を設定する

[3] messaging.batch.message_count: スパンがメッセージのバッチに対する操作を記述する場合。

[4] messaging.batch.message_count: 計装は、単一のメッセージを操作するスパンに messaging.batch.message_count を設定するべきではありません（SHOULD NOT）。メッセージングクライアントライブラリが同じ操作についてバッチAPIと単一メッセージAPIの両方をサポートする場合、計装はバッチ処理APIには messaging.batch.message_count を使用すべきであり（SHOULD）、単一メッセージAPIには使用するべきではありません（SHOULD NOT）。

[5] messaging.destination.name: スパンが単一メッセージに対する操作を記述する場合、またはその値がバッチ内のすべてのメッセージに当てはまる場合。

[6] messaging.destination.name: ブローカー内の特定のキュー、トピック、またはその他のエンティティを一意に識別すべきです（SHOULD）。ブローカーにそのような概念がない場合は、ブローカー自体を一意に識別すべきです（SHOULD）。

[7] messaging.destination.template: 利用可能な場合。宛先名の低カーディナリティが保証されない限り、計装は messaging.destination.name をテンプレートとして使用してはなりません（MUST NOT）。

[8] messaging.destination.template: 宛先名はテンプレートから構築されることがあります。例えば、ユーザー名や商品IDを含む宛先名です。この場合、宛先名自体は高カーディナリティですが、その基盤となるテンプレートは低カーディナリティであり、グルーピングや集計に効果的に使用できます。

[9] messaging.operation.type: send に設定すべきです（SHOULD）。

[10] network.peer.address: 個々のメッセージングシステムのセマンティック規約は、network.peer.* 属性が適用可能かどうかを文書化すべきです（SHOULD）。アプリケーションが個々の中継者ノードと直接やり取りする場合、ネットワークピアのアドレスとポートは重要です。メッセージング操作に複数回のネットワーク呼び出し（例えば再試行）が伴う場合、最後に接続したノードのアドレスを使用すべきです（SHOULD）。

[11] server.address: ブローカーの、利用可能であればリバースDNSルックアップなしのサーバードメイン名。それ以外の場合はIPアドレスまたはUNIXドメインソケット名。

[12] server.port: クライアント側から観測され、かつ中継者を経由して通信している場合、server.port は、利用可能であれば、その中継者の背後にあるサーバーポート（例えばプロキシ経由の場合など）を表すべきです（SHOULD）。

[13] messaging.message.body.size: これは圧縮後または圧縮前のいずれのボディサイズも指すことができます。両方のサイズが分かっている場合は、圧縮前のボディサイズを使用すべきです（SHOULD）。

[14] messaging.message.envelope.size: これは圧縮後または圧縮前のいずれのサイズも指すことができます。両方のサイズが分かっている場合は、圧縮前のサイズを使用すべきです（SHOULD）。

次の属性は、サンプリング判断に重要となりうるため、（いずれかが提供される場合）スパン作成時点で提供すべきです（SHOULD）。

Value	Description	Stability
`_OTHER`	計装がカスタム値を定義していない場合に使用されるフォールバックのエラー値。

Value	Description	Stability
`create`	メッセージが作成されます。「Create」スパンは常に単一のメッセージを指し、バッチ送信シナリオにおいてメッセージに一意の作成コンテキストを提供するために使用されます。
`process`	1つ以上のメッセージがコンシューマーによって処理されます。
`receive`	1つ以上のメッセージがコンシューマーによって要求されます。この操作はpullベースのシナリオを指し、コンシューマーがメッセージングSDKのメソッドを明示的に呼び出してメッセージを受信します。
`send`	1つ以上のメッセージが中継者への送信のために提供されます。単一のメッセージが送信される場合、「Send」スパンのコンテキストを作成コンテキストとして使用でき、「Create」スパンを作成する必要はありません。
`settle`	1つ以上のメッセージが決済されます。

Value	Description	Stability
`activemq`	Apache ActiveMQ
`aws.sns`	Amazon Simple Notification Service（SNS）
`aws_sqs`	Amazon Simple Queue Service（SQS）
`eventgrid`	Azure Event Grid
`eventhubs`	Azure Event Hubs
`gcp_pubsub`	Google Cloud Pub/Sub
`jms`	Java Message Service
`kafka`	Apache Kafka
`pulsar`	Apache Pulsar
`rabbitmq`	RabbitMQ
`rocketmq`	Apache RocketMQ
`servicebus`	Azure Service Bus

Sendスパン（クライアント）

Status:

別のメッセージ作成コンテキスト（「Create」スパンまたはカスタムコンテキスト）が既に存在する状態で、1つ以上のメッセージが中継者に送信されることを記述します。

メッセージについて既に「Create」スパン（またはカスタムの作成コンテキスト）が存在する場合にこのスパンを使用します。この場合、「Send」スパンはトランスポート操作のみを記述し、メッセージに注入された作成コンテキストにリンクします。詳細はProducer spansを参照してください。

Span kind は CLIENT にすべきです（SHOULD）。

Span status はエラーの記録の文書に従うべきです（SHOULD）。

Attributes:

Key	Requirement Level	Value Type	Description	Example Values
`messaging.operation.name`	`Required`	string	メッセージング操作のシステム固有の名前。	`send`; `publish`
`messaging.system`	`Required`	string	クライアント計装によって識別されるメッセージングシステム。[1]	`activemq`; `aws.sns`; `aws_sqs`
`error.type`	`Conditionally Required` メッセージング操作が失敗した場合に限る。	string	操作が終了したエラーのクラスを記述します。[2]	`amqp:decode-error`; `KAFKA_STORAGE_ERROR`; `channel-error`
`messaging.batch.message_count`	`Conditionally Required` [3]	int	バッチ処理操作のスコープ内で送信、受信、または処理されたメッセージの数。[4]	`0`; `1`; `2`
`messaging.destination.name`	`Conditionally Required` [5]	string	メッセージの宛先名 [6]	`MyQueue`; `MyTopic`
`messaging.destination.template`	`Conditionally Required` [7]	string	メッセージング宛先名の低カーディナリティな表現 [8]	`/customers/{customerId}`
`messaging.operation.type`	`Conditionally Required` 適用可能な場合。	string	メッセージング操作の種別を識別する文字列。[9]	`send`
`messaging.client.id`	`Recommended`	string	メッセージを消費または生成するクライアントの一意の識別子。	`client-5`; `myhost@8742@s8083jm`
`messaging.destination.partition.id`	`Recommended` 適用可能な場合。	string	メッセージが送信または受信されるパーティションの識別子。`messaging.destination.name` 内で一意。	`1`
`messaging.message.conversation_id`	`Recommended`	string	メッセージが属する会話を識別する会話ID。文字列として表現されます。「Correlation ID」と呼ばれることもあります。	`MyConversationId`
`messaging.message.id`	`Recommended` スパンが単一メッセージに対する操作を記述する場合。	string	メッセージングシステムがメッセージの識別子として使用する値。文字列として表現されます。	`452a7c7c7c7048c2f887f61572b18fc2`
`network.peer.address`	`Recommended` このメッセージングシステムに適用可能な場合。	string	操作が実行されたメッセージング中継者ノードのピアアドレス。[10]	`10.1.2.80`; `/tmp/my.sock`
`network.peer.port`	`Recommended` `network.peer.address` が設定されている場合に限る。	int	操作が実行されたメッセージング中継者ノードのピアポート。	`65123`
`server.address`	`Recommended`	string	利用可能であればリバースDNSルックアップなしのサーバードメイン名。それ以外の場合はIPアドレスまたはUNIXドメインソケット名。[11]	`example.com`; `10.1.2.80`; `/tmp/my.sock`
`server.port`	`Recommended`	int	サーバーのポート番号。[12]	`80`; `8080`; `443`
`messaging.message.body.size`	`Opt-In`	int	メッセージ本文のバイト数。単一メッセージの操作を記述するスパンにのみ適用されます。[13]	`1439`
`messaging.message.envelope.size`	`Opt-In`	int	メッセージ本文とメタデータのバイト数。[14]	`2738`

[2] error.type: error.type は予測可能であるべきであり（SHOULD）、低カーディナリティであるべきです（SHOULD）。

error.type がある型（例えば例外の型）に設定される場合、そのアーティファクト内で型を識別する正規のクラス名を使用すべきです（SHOULD）。

計装は、報告するエラーの一覧を文書化すべきです（SHOULD）。

操作が正常に完了した場合、計装は error.type を設定するべきではありません（SHOULD NOT）。

ドメイン固有の属性を使用する
ドメイン固有の集合内で定義されているかどうかにかかわらず、すべてのエラーを捕捉するために error.type を設定する

[3] messaging.batch.message_count: スパンがメッセージのバッチに対する操作を記述する場合。

[9] messaging.operation.type: send に設定すべきです（SHOULD）。

次の属性は、サンプリング判断に重要となりうるため、（いずれかが提供される場合）スパン作成時点で提供すべきです（SHOULD）。

Value	Description	Stability
`_OTHER`	計装がカスタム値を定義していない場合に使用されるフォールバックのエラー値。

Value	Description	Stability
`create`	メッセージが作成されます。「Create」スパンは常に単一のメッセージを指し、バッチ送信シナリオにおいてメッセージに一意の作成コンテキストを提供するために使用されます。
`process`	1つ以上のメッセージがコンシューマーによって処理されます。
`receive`	1つ以上のメッセージがコンシューマーによって要求されます。この操作はpullベースのシナリオを指し、コンシューマーがメッセージングSDKのメソッドを明示的に呼び出してメッセージを受信します。
`send`	1つ以上のメッセージが中継者への送信のために提供されます。単一のメッセージが送信される場合、「Send」スパンのコンテキストを作成コンテキストとして使用でき、「Create」スパンを作成する必要はありません。
`settle`	1つ以上のメッセージが決済されます。

Value	Description	Stability
`activemq`	Apache ActiveMQ
`aws.sns`	Amazon Simple Notification Service（SNS）
`aws_sqs`	Amazon Simple Queue Service（SQS）
`eventgrid`	Azure Event Grid
`eventhubs`	Azure Event Hubs
`gcp_pubsub`	Google Cloud Pub/Sub
`jms`	Java Message Service
`kafka`	Apache Kafka
`pulsar`	Apache Pulsar
`rabbitmq`	RabbitMQ
`rocketmq`	Apache RocketMQ
`servicebus`	Azure Service Bus

Receiveスパン

Status:

コンシューマーによって（pullベースで）要求される、1つ以上のメッセージを記述します。

「Receive」スパンは、コンシューマーがメッセージングSDKのメソッドを明示的に呼び出してメッセージを受信するpullベースのシナリオについて作成されます。詳細はConsumer spansを参照してください。

Span kind は CLIENT にすべきです（SHOULD）。

Span status はエラーの記録の文書に従うべきです（SHOULD）。

Attributes:

Key	Requirement Level	Value Type	Description	Example Values
`messaging.operation.name`	`Required`	string	メッセージング操作のシステム固有の名前。	`receive`; `poll`
`messaging.system`	`Required`	string	クライアント計装によって識別されるメッセージングシステム。[1]	`activemq`; `aws.sns`; `aws_sqs`
`error.type`	`Conditionally Required` メッセージング操作が失敗した場合に限る。	string	操作が終了したエラーのクラスを記述します。[2]	`amqp:decode-error`; `KAFKA_STORAGE_ERROR`; `channel-error`
`messaging.batch.message_count`	`Conditionally Required` [3]	int	バッチ処理操作のスコープ内で送信、受信、または処理されたメッセージの数。[4]	`0`; `1`; `2`
`messaging.destination.name`	`Conditionally Required` [5]	string	メッセージの宛先名 [6]	`MyQueue`; `MyTopic`
`messaging.destination.template`	`Conditionally Required` [7]	string	メッセージング宛先名の低カーディナリティな表現 [8]	`/customers/{customerId}`
`messaging.operation.type`	`Conditionally Required` 適用可能な場合。	string	メッセージング操作の種別を識別する文字列。[9]	`receive`
`messaging.client.id`	`Recommended`	string	メッセージを消費または生成するクライアントの一意の識別子。	`client-5`; `myhost@8742@s8083jm`
`messaging.destination.partition.id`	`Recommended` 適用可能な場合。	string	メッセージが送信または受信されるパーティションの識別子。`messaging.destination.name` 内で一意。	`1`
`messaging.message.conversation_id`	`Recommended`	string	メッセージが属する会話を識別する会話ID。文字列として表現されます。「Correlation ID」と呼ばれることもあります。	`MyConversationId`
`messaging.message.id`	`Recommended` スパンが単一メッセージに対する操作を記述する場合。	string	メッセージングシステムがメッセージの識別子として使用する値。文字列として表現されます。	`452a7c7c7c7048c2f887f61572b18fc2`
`network.peer.address`	`Recommended` このメッセージングシステムに適用可能な場合。	string	操作が実行されたメッセージング中継者ノードのピアアドレス。[10]	`10.1.2.80`; `/tmp/my.sock`
`network.peer.port`	`Recommended` `network.peer.address` が設定されている場合に限る。	int	操作が実行されたメッセージング中継者ノードのピアポート。	`65123`
`server.address`	`Recommended`	string	利用可能であればリバースDNSルックアップなしのサーバードメイン名。それ以外の場合はIPアドレスまたはUNIXドメインソケット名。[11]	`example.com`; `10.1.2.80`; `/tmp/my.sock`
`server.port`	`Recommended`	int	サーバーのポート番号。[12]	`80`; `8080`; `443`
`messaging.message.body.size`	`Opt-In`	int	メッセージ本文のバイト数。単一メッセージの操作を記述するスパンにのみ適用されます。[13]	`1439`
`messaging.message.envelope.size`	`Opt-In`	int	メッセージ本文とメタデータのバイト数。[14]	`2738`

[2] error.type: error.type は予測可能であるべきであり（SHOULD）、低カーディナリティであるべきです（SHOULD）。

error.type がある型（例えば例外の型）に設定される場合、そのアーティファクト内で型を識別する正規のクラス名を使用すべきです（SHOULD）。

計装は、報告するエラーの一覧を文書化すべきです（SHOULD）。

操作が正常に完了した場合、計装は error.type を設定するべきではありません（SHOULD NOT）。

ドメイン固有の属性を使用する
ドメイン固有の集合内で定義されているかどうかにかかわらず、すべてのエラーを捕捉するために error.type を設定する

[3] messaging.batch.message_count: スパンがメッセージのバッチに対する操作を記述する場合。

[9] messaging.operation.type: receive に設定すべきです（SHOULD）。

次の属性は、サンプリング判断に重要となりうるため、（いずれかが提供される場合）スパン作成時点で提供すべきです（SHOULD）。

Value	Description	Stability
`_OTHER`	計装がカスタム値を定義していない場合に使用されるフォールバックのエラー値。

Value	Description	Stability
`create`	メッセージが作成されます。「Create」スパンは常に単一のメッセージを指し、バッチ送信シナリオにおいてメッセージに一意の作成コンテキストを提供するために使用されます。
`process`	1つ以上のメッセージがコンシューマーによって処理されます。
`receive`	1つ以上のメッセージがコンシューマーによって要求されます。この操作はpullベースのシナリオを指し、コンシューマーがメッセージングSDKのメソッドを明示的に呼び出してメッセージを受信します。
`send`	1つ以上のメッセージが中継者への送信のために提供されます。単一のメッセージが送信される場合、「Send」スパンのコンテキストを作成コンテキストとして使用でき、「Create」スパンを作成する必要はありません。
`settle`	1つ以上のメッセージが決済されます。

Value	Description	Stability
`activemq`	Apache ActiveMQ
`aws.sns`	Amazon Simple Notification Service（SNS）
`aws_sqs`	Amazon Simple Queue Service（SQS）
`eventgrid`	Azure Event Grid
`eventhubs`	Azure Event Hubs
`gcp_pubsub`	Google Cloud Pub/Sub
`jms`	Java Message Service
`kafka`	Apache Kafka
`pulsar`	Apache Pulsar
`rabbitmq`	RabbitMQ
`rocketmq`	Apache RocketMQ
`servicebus`	Azure Service Bus

Processスパン

Status:

コンシューマーによって（pushベースで）処理される、1つ以上のメッセージを記述します。

「Process」スパンは、コールバックまたはハンドラーを通じてメッセージがアプリケーションに渡されるpushベースのシナリオについて作成されます。詳細はConsumer spansを参照してください。

単一メッセージのシナリオに限り、メッセージ作成コンテキストが親として使用される場合については、Message creation context as parent of “Process” spanを参照してください。

Span kind は CONSUMER にすべきです（SHOULD）。

Span status はエラーの記録の文書に従うべきです（SHOULD）。

Attributes:

Key	Requirement Level	Value Type	Description	Example Values
`messaging.operation.name`	`Required`	string	メッセージング操作のシステム固有の名前。	`process`; `consume`
`messaging.system`	`Required`	string	クライアント計装によって識別されるメッセージングシステム。[1]	`activemq`; `aws.sns`; `aws_sqs`
`error.type`	`Conditionally Required` メッセージング操作が失敗した場合に限る。	string	操作が終了したエラーのクラスを記述します。[2]	`amqp:decode-error`; `KAFKA_STORAGE_ERROR`; `channel-error`
`messaging.batch.message_count`	`Conditionally Required` [3]	int	バッチ処理操作のスコープ内で送信、受信、または処理されたメッセージの数。[4]	`0`; `1`; `2`
`messaging.destination.name`	`Conditionally Required` [5]	string	メッセージの宛先名 [6]	`MyQueue`; `MyTopic`
`messaging.destination.template`	`Conditionally Required` [7]	string	メッセージング宛先名の低カーディナリティな表現 [8]	`/customers/{customerId}`
`messaging.operation.type`	`Conditionally Required` 適用可能な場合。	string	メッセージング操作の種別を識別する文字列。[9]	`process`
`messaging.client.id`	`Recommended`	string	メッセージを消費または生成するクライアントの一意の識別子。	`client-5`; `myhost@8742@s8083jm`
`messaging.destination.partition.id`	`Recommended` 適用可能な場合。	string	メッセージが送信または受信されるパーティションの識別子。`messaging.destination.name` 内で一意。	`1`
`messaging.message.conversation_id`	`Recommended`	string	メッセージが属する会話を識別する会話ID。文字列として表現されます。「Correlation ID」と呼ばれることもあります。	`MyConversationId`
`messaging.message.id`	`Recommended` スパンが単一メッセージに対する操作を記述する場合。	string	メッセージングシステムがメッセージの識別子として使用する値。文字列として表現されます。	`452a7c7c7c7048c2f887f61572b18fc2`
`server.address`	`Recommended`	string	利用可能であればリバースDNSルックアップなしのサーバードメイン名。それ以外の場合はIPアドレスまたはUNIXドメインソケット名。[10]	`example.com`; `10.1.2.80`; `/tmp/my.sock`
`server.port`	`Recommended`	int	サーバーのポート番号。[11]	`80`; `8080`; `443`
`messaging.message.body.size`	`Opt-In`	int	メッセージ本文のバイト数。単一メッセージの操作を記述するスパンにのみ適用されます。[12]	`1439`
`messaging.message.envelope.size`	`Opt-In`	int	メッセージ本文とメタデータのバイト数。[13]	`2738`

[2] error.type: error.type は予測可能であるべきであり（SHOULD）、低カーディナリティであるべきです（SHOULD）。

error.type がある型（例えば例外の型）に設定される場合、そのアーティファクト内で型を識別する正規のクラス名を使用すべきです（SHOULD）。

計装は、報告するエラーの一覧を文書化すべきです（SHOULD）。

操作が正常に完了した場合、計装は error.type を設定するべきではありません（SHOULD NOT）。

ドメイン固有の属性を使用する
ドメイン固有の集合内で定義されているかどうかにかかわらず、すべてのエラーを捕捉するために error.type を設定する

[3] messaging.batch.message_count: スパンがメッセージのバッチに対する操作を記述する場合。

[9] messaging.operation.type: process に設定すべきです（SHOULD）。

[10] server.address: ブローカーの、利用可能であればリバースDNSルックアップなしのサーバードメイン名。それ以外の場合はIPアドレスまたはUNIXドメインソケット名。

[11] server.port: クライアント側から観測され、かつ中継者を経由して通信している場合、server.port は、利用可能であれば、その中継者の背後にあるサーバーポート（例えばプロキシ経由の場合など）を表すべきです（SHOULD）。

[12] messaging.message.body.size: これは圧縮後または圧縮前のいずれのボディサイズも指すことができます。両方のサイズが分かっている場合は、圧縮前のボディサイズを使用すべきです（SHOULD）。

[13] messaging.message.envelope.size: これは圧縮後または圧縮前のいずれのサイズも指すことができます。両方のサイズが分かっている場合は、圧縮前のサイズを使用すべきです（SHOULD）。

次の属性は、サンプリング判断に重要となりうるため、（いずれかが提供される場合）スパン作成時点で提供すべきです（SHOULD）。

Value	Description	Stability
`_OTHER`	計装がカスタム値を定義していない場合に使用されるフォールバックのエラー値。

Value	Description	Stability
`create`	メッセージが作成されます。「Create」スパンは常に単一のメッセージを指し、バッチ送信シナリオにおいてメッセージに一意の作成コンテキストを提供するために使用されます。
`process`	1つ以上のメッセージがコンシューマーによって処理されます。
`receive`	1つ以上のメッセージがコンシューマーによって要求されます。この操作はpullベースのシナリオを指し、コンシューマーがメッセージングSDKのメソッドを明示的に呼び出してメッセージを受信します。
`send`	1つ以上のメッセージが中継者への送信のために提供されます。単一のメッセージが送信される場合、「Send」スパンのコンテキストを作成コンテキストとして使用でき、「Create」スパンを作成する必要はありません。
`settle`	1つ以上のメッセージが決済されます。

Value	Description	Stability
`activemq`	Apache ActiveMQ
`aws.sns`	Amazon Simple Notification Service（SNS）
`aws_sqs`	Amazon Simple Queue Service（SQS）
`eventgrid`	Azure Event Grid
`eventhubs`	Azure Event Hubs
`gcp_pubsub`	Google Cloud Pub/Sub
`jms`	Java Message Service
`kafka`	Apache Kafka
`pulsar`	Apache Pulsar
`rabbitmq`	RabbitMQ
`rocketmq`	Apache RocketMQ
`servicebus`	Azure Service Bus

Settleスパン

Status:

決済される、1つ以上のメッセージを記述します。

「Settle」スパンは、手動または自動でトリガーされるすべての決済操作について作成されます。詳細はConsumer spansを参照してください。

Span kind は CLIENT にすべきです（SHOULD）。

Span status はエラーの記録の文書に従うべきです（SHOULD）。

Attributes:

Key	Requirement Level	Value Type	Description	Example Values
`messaging.operation.name`	`Required`	string	メッセージング操作のシステム固有の名前。	`ack`; `nack`; `settle`
`messaging.system`	`Required`	string	クライアント計装によって識別されるメッセージングシステム。[1]	`activemq`; `aws.sns`; `aws_sqs`
`error.type`	`Conditionally Required` メッセージング操作が失敗した場合に限る。	string	操作が終了したエラーのクラスを記述します。[2]	`amqp:decode-error`; `KAFKA_STORAGE_ERROR`; `channel-error`
`messaging.batch.message_count`	`Conditionally Required` [3]	int	バッチ処理操作のスコープ内で送信、受信、または処理されたメッセージの数。[4]	`0`; `1`; `2`
`messaging.destination.name`	`Conditionally Required` [5]	string	メッセージの宛先名 [6]	`MyQueue`; `MyTopic`
`messaging.destination.template`	`Conditionally Required` [7]	string	メッセージング宛先名の低カーディナリティな表現 [8]	`/customers/{customerId}`
`messaging.operation.type`	`Conditionally Required` 適用可能な場合。	string	メッセージング操作の種別を識別する文字列。[9]	`settle`
`messaging.client.id`	`Recommended`	string	メッセージを消費または生成するクライアントの一意の識別子。	`client-5`; `myhost@8742@s8083jm`
`messaging.destination.partition.id`	`Recommended` 適用可能な場合。	string	メッセージが送信または受信されるパーティションの識別子。`messaging.destination.name` 内で一意。	`1`
`messaging.message.conversation_id`	`Recommended`	string	メッセージが属する会話を識別する会話ID。文字列として表現されます。「Correlation ID」と呼ばれることもあります。	`MyConversationId`
`messaging.message.id`	`Recommended` スパンが単一メッセージに対する操作を記述する場合。	string	メッセージングシステムがメッセージの識別子として使用する値。文字列として表現されます。	`452a7c7c7c7048c2f887f61572b18fc2`
`network.peer.address`	`Recommended` このメッセージングシステムに適用可能な場合。	string	操作が実行されたメッセージング中継者ノードのピアアドレス。[10]	`10.1.2.80`; `/tmp/my.sock`
`network.peer.port`	`Recommended` `network.peer.address` が設定されている場合に限る。	int	操作が実行されたメッセージング中継者ノードのピアポート。	`65123`
`server.address`	`Recommended`	string	利用可能であればリバースDNSルックアップなしのサーバードメイン名。それ以外の場合はIPアドレスまたはUNIXドメインソケット名。[11]	`example.com`; `10.1.2.80`; `/tmp/my.sock`
`server.port`	`Recommended`	int	サーバーのポート番号。[12]	`80`; `8080`; `443`

[2] error.type: error.type は予測可能であるべきであり（SHOULD）、低カーディナリティであるべきです（SHOULD）。

error.type がある型（例えば例外の型）に設定される場合、そのアーティファクト内で型を識別する正規のクラス名を使用すべきです（SHOULD）。

計装は、報告するエラーの一覧を文書化すべきです（SHOULD）。

操作が正常に完了した場合、計装は error.type を設定するべきではありません（SHOULD NOT）。

ドメイン固有の属性を使用する
ドメイン固有の集合内で定義されているかどうかにかかわらず、すべてのエラーを捕捉するために error.type を設定する

[3] messaging.batch.message_count: スパンがメッセージのバッチに対する操作を記述する場合。

[9] messaging.operation.type: settle に設定すべきです（SHOULD）。

次の属性は、サンプリング判断に重要となりうるため、（いずれかが提供される場合）スパン作成時点で提供すべきです（SHOULD）。

Value	Description	Stability
`_OTHER`	計装がカスタム値を定義していない場合に使用されるフォールバックのエラー値。

Value	Description	Stability
`create`	メッセージが作成されます。「Create」スパンは常に単一のメッセージを指し、バッチ送信シナリオにおいてメッセージに一意の作成コンテキストを提供するために使用されます。
`process`	1つ以上のメッセージがコンシューマーによって処理されます。
`receive`	1つ以上のメッセージがコンシューマーによって要求されます。この操作はpullベースのシナリオを指し、コンシューマーがメッセージングSDKのメソッドを明示的に呼び出してメッセージを受信します。
`send`	1つ以上のメッセージが中継者への送信のために提供されます。単一のメッセージが送信される場合、「Send」スパンのコンテキストを作成コンテキストとして使用でき、「Create」スパンを作成する必要はありません。
`settle`	1つ以上のメッセージが決済されます。

Value	Description	Stability
`activemq`	Apache ActiveMQ
`aws.sns`	Amazon Simple Notification Service（SNS）
`aws_sqs`	Amazon Simple Queue Service（SQS）
`eventgrid`	Azure Event Grid
`eventhubs`	Azure Event Hubs
`gcp_pubsub`	Google Cloud Pub/Sub
`jms`	Java Message Service
`kafka`	Apache Kafka
`pulsar`	Apache Pulsar
`rabbitmq`	RabbitMQ
`rocketmq`	Apache RocketMQ
`servicebus`	Azure Service Bus

バッチ操作におけるメッセージ単位の属性の記録

すべてのメッセージング操作（send、receive、process、またはこの仕様書がカバーしていないその他の操作）は、単一のメッセージ、バッチのメッセージ、またはその両方を記述できます。 messaging.message または messaging.{system}.message 名前空間内の属性は個々のメッセージに適用され、通常は同じバッチ内のメッセージ間で異なります。

KafkaやAzure Event Gridなどの一部のメッセージングシステムでは、1回の操作で異なるトピックにメッセージのバッチを送信できるため、単一のメッセージング操作の中で messaging.destination.name やその他の宛先属性が異なることがあります。

属性の値がバッチ内のすべてのメッセージで同じ場合、計装はバッチ操作を表すスパンにその属性を設定すべきです（SHOULD）。属性の値が異なる場合、計装は個々のメッセージを記述するリンクにその属性を設定すべきです（SHOULD）。

リンクを使った関連付けの詳細については、バッチ受信を参照してください。

例

この節には、上記の規約の使用方法を示す例の一覧が含まれています。緑色のボックスは、これらの規約に準拠するために存在が必須のスパンを示します。その他のボックスは、規約でカバーされてはいるものの必須ではないスパンであり、メッセージングスパンを全体のトレースフローにどのように統合できるかを理解するのに役立つことを意図しています。実線の矢印は親子関係を、点線の矢印はリンク関係を示します。

[!IMPORTANT] 「Span」ボックス内のテキストは、参照および可視化のためだけのものです。実際に報告されるべきスパン名やその他の属性については、付随する表を確認してください。

複数のコンシューマーを持つトピック

RabbitMQ上のトピックエクスチェンジ「T」にメッセージを発行するパブリッシャーがあり、両方にメッセージが配送される2つのコンシューマーがある場合を考えます。

flowchart LR;
  subgraph PRODUCER
  direction TB
  P[Span Send A]
  end
  subgraph CONSUMER1
  direction TB
  R1[Span Process A 1]
  end
  subgraph CONSUMER2
  direction TB
  R2[Span Process A 2]
  end
  P-. link .-R1;
  P-- parent -->R1;
  P-. link .-R2;
  P-- parent -->R2;

  classDef normal fill:green
  class P,R1,R2 normal
  linkStyle 0,1,2,3 color:green,stroke:green

Field or Attribute	Producer	Consumer 1	Consumer 2
Span name	`publish T`	`consume T`	`consume T`
Parent (optional)		`publish T`	`publish T`
Links		`publish T`	`publish T`
SpanKind	`PRODUCER`	`CONSUMER`	`CONSUMER`
`server.address`	`"ms"`	`"ms"`	`"ms"`
`server.port`	`1234`	`1234`	`1234`
`messaging.system`	`"rabbitmq"`	`"rabbitmq"`	`"rabbitmq"`
`messaging.destination.name`	`"T"`	`"T"`	`"T"`
`messaging.operation.name`	`"publish"`	`"consume"`	`"consume"`
`messaging.operation.type`	`"send"`	`"process"`	`"process"`
`messaging.message.id`	`"a"`	`"a"`	`"a"`

バッチ受信

Kafka上のトピック「Q」に2つのメッセージを発行するプロデューサーがあり、それら両方のメッセージを1回のバッチで受信するコンシューマーがある場合を考えます。

flowchart LR;
  subgraph PRODUCER
  direction TB
  PA[Span Send A]
  PB[Span Send B]
  end
  subgraph CONSUMER
  direction TB
  D1[Span Receive A B]
  end
  PA-. link .-D1;
  PB-. link .-D1;

  classDef normal fill:green
  class PA,PB,D1 normal
  linkStyle 0,1 color:green,stroke:green

Field or Attribute	Producer Span A	Producer Span B	Consumer
Span name	`send Q`	`send Q`	`poll Q`
Parent
Links			Span Send A, Span Send B
Link attributes			Span Send A: `messaging.message.id`: `"a1"`
			Span Send B: `messaging.message.id`: `"a2"`
SpanKind	`PRODUCER`	`PRODUCER`	`CLIENT`
`server.address`	`"ms"`	`"ms"`	`"ms"`
`server.port`	`1234`	`1234`	`1234`
`messaging.system`	`"kafka"`	`"kafka"`	`"kafka"`
`messaging.destination.name`	`"Q"`	`"Q"`	`"Q"`
`messaging.operation.name`	`"send"`	`"send"`	`"poll"`
`messaging.operation.type`	`"send"`	`"send"`	`"receive"`
`messaging.message.id`	`"a1"`	`"a2"`
`messaging.batch.message_count`			2

“Create"スパンを使ったバッチ発行

Kafka上のトピック「Q」に2つのメッセージを含むバッチを発行するプロデューサーがあり、それぞれ一方のメッセージを受信する2つの異なるコンシューマーがある場合を考えます。

この場合、計装は各メッセージについて「Create」スパンを報告し、その「Create」スパンにリンクする「Send」スパンを報告します。

flowchart LR;
  subgraph PRODUCER
  direction TB
  CA[Span Create A]
  CB[Span Create B]
  P[Span Send]
  end
  subgraph CONSUMER1
  direction TB
  D1[Span Receive A]
  end
  subgraph CONSUMER2
  direction TB
  D2[Span Receive B]
  end
  CA-. link .-P;
  CB-. link .-P;
  CA-. link .-D1;
  CB-. link .-D2;

  classDef normal fill:green
  class P,CA,CB,D1,D2 normal
  linkStyle 0,1,2,3 color:green,stroke:green

Field or Attribute	Producer Span Create A	Producer Span Create B	Producer Span Send	Consumer 1	Consumer 2
Span name	`create Q`	`create Q`	`send Q`	`poll Q`	`poll Q`
Parent
Links				Span Create A	Span Create B
SpanKind	`PRODUCER`	`PRODUCER`	`CLIENT`	`CLIENT`	`CLIENT`
`server.address`	`"ms"`	`"ms"`	`"ms"`	`"ms"`	`"ms"`
`server.port`	`1234`	`1234`	`1234`	`1234`	`1234`
`messaging.system`	`"kafka"`	`"kafka"`	`"kafka"`	`"kafka"`	`"kafka"`
`messaging.destination.name`	`"Q"`	`"Q"`	`"Q"`	`"Q"`	`"Q"`
`messaging.operation.name`	`"create"`	`"create"`	`"send"`	`"poll"`	`"poll"`
`messaging.operation.type`	`"create"`	`"create"`	`"send"`	`"receive"`	`"receive"`
`messaging.message.id`	`"a1"`	`"a2"`		`"a1"`	`"a2"`
`messaging.batch.message_count`			2

“Create"スパンを使わないバッチ発行

ユーザーが提供した設定に基づき、この場合の計装は「Send」スパンのみを報告します。「Send」スパンのコンテキストは両方のメッセージに注入されます。

flowchart LR;
  subgraph PRODUCER
  direction TB
  P[Span Send]
  end
  subgraph CONSUMER1
  direction TB
  D1[Span Receive A]
  end
  subgraph CONSUMER2
  direction TB
  D2[Span Receive B]
  end
  P-. link .-D1;
  P-. link .-D2;

  classDef normal fill:green
  class P,D1,D2 normal
  linkStyle 0,1 color:green,stroke:green

Field or Attribute	Producer	Consumer 1	Consumer 2
Span name	`send Q`	`poll Q`	`poll Q`
Parent
Links		Span Send	Span Send
SpanKind	`PRODUCER`	`CLIENT`	`CLIENT`
`server.address`	`"ms"`	`"ms"`	`"ms"`
`server.port`	`1234`	`1234`	`1234`
`messaging.system`	`"kafka"`	`"kafka"`	`"kafka"`
`messaging.destination.name`	`"Q"`	`"Q"`	`"Q"`
`messaging.operation.name`	`"send"`	`"poll"`	`"poll"`
`messaging.operation.type`	`"send"`	`"receive"`	`"receive"`
`messaging.message.id`		`"a1"`	`"a2"`
`messaging.batch.message_count`	2