用語集

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

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

このドキュメントは、この仕様書全体で使われるいくつかの用語を定義します。

その他の基本的な用語は概要ドキュメントに記載されています。

ユーザーの役割

Application Owner

アプリケーションやサービスの保守者で、OpenTelemetry SDKの設定とライフサイクルの管理を担う人物。

Library Author

多くのアプリケーションから依存され、OpenTelemetryの計装の対象となる共有ライブラリの保守者。

Instrumentation Author

OpenTelemetry APIに対して書かれたOpenTelemetryの計装の保守者。これは、アプリケーションコード内、共有ライブラリ内、あるいはInstrumentation Library内に書かれた計装を指すことがあります。

Plugin Author

OpenTelemetry SDKのプラグインインターフェースに対して書かれた、OpenTelemetry SDKプラグインの保守者。

共通

Signals

OpenTelemetryはシグナル、つまりテレメトリーのカテゴリを軸に構成されています。メトリクス、ログ、トレース、プロファイル、バゲージはシグナルの例です。各シグナルは、まとまりのある独立した機能の集合を表します。各シグナルは、それぞれ現在の安定性レベルを定義する個別のライフサイクルに従います。

Packages

この仕様書において、パッケージという用語は、他のパッケージとは独立してプログラムにインポートできる、単一の依存関係を表すコードの集合を表します。この概念は、一部の言語では「モジュール」といった異なる用語に対応することがあります。一部の言語では、「パッケージ」という用語が異なる概念を指すことに注意してください。

ABI Compatibility

ABI（application binary interface）とは、マシンコードレベルでソフトウェアコンポーネント間のやり取りを定義するインターフェースです。例えばアプリケーションの実行ファイルと、コンパイルされた共有オブジェクトライブラリのバイナリとの間のインターフェースです。ABI互換性とは、対象の実行ファイルを再コンパイルする必要なく、ライブラリの新しくコンパイルされたバージョンをそこに正しくリンクできることを意味します。

ABI互換性は、一部の言語、特にマシンコードの形式を提供する言語では重要です。他の言語では、ABI互換性は関連する要件ではない場合があります。

In-band and Out-of-band Data

In telecommunications, in-band signaling is the sending of control information within the same band or channel used for data such as voice or video. This is in contrast to out-of-band signaling which is sent over a different channel, or even over a separate network (Wikipedia).

（電気通信において、インバンド信号とは、音声や映像などのデータに使われる同じ帯域またはチャネル内で制御情報を送ることを指す。これに対し、アウトオブバンド信号は異なるチャネル、あるいは別のネットワークを介して送られる。）

OpenTelemetryにおいて、インバンドデータとは、分散システムの構成要素間で業務メッセージの一部として渡されるデータを指します。例えば、トレースやバゲージがHTTPリクエストにHTTPヘッダーの形で含まれる場合です。このようなデータは通常テレメトリー自体を含まず、様々なコンポーネントによって生成されたテレメトリーを関連付けたり結合したりするために使われます。テレメトリー自体はアウトオブバンドデータと呼ばれます。それはアプリケーションから専用のメッセージを介して、通常はビジネスロジックのクリティカルパスからではなく、バックグラウンドのルーチンによって非同期に送信されます。テレメトリーバックエンドへエクスポートされるメトリクス、ログ、トレースは、アウトオブバンドデータの例です。

Manual Instrumentation

エンドユーザーのコードや共有フレームワーク（MongoDB、Redisなど）からテレメトリーを収集するために、Tracing API、Metrics APIなどのOpenTelemetry APIに対してコードを書くこと。

Automatic Instrumentation

エンドユーザーがアプリケーションのソースコードを変更する必要のないテレメトリー収集の方法を指します。方法はプログラミング言語によって異なり、例としてはコード操作（コンパイル時または実行時）、モンキーパッチ、eBPFプログラムの実行があります。

同義語: Auto-instrumentation。

Natively Instrumented

ライブラリやアプリケーションが、標準の計装を提供するためにOpenTelemetry APIを直接使用していることを表します。この場合、instrumented library（計装対象ライブラリ）とinstrumentation library（計装ライブラリ）は同一のライブラリです。

あるライブラリやアプリケーションを計装するために別のinstrumentation libraryやプラグインが必要な場合、そのinstrumented libraryやアプリケーションは、そのinstrumentation libraryやプラグインが同じ作者によって提供されていたり、対象のソフトウェアのエコシステムに適合するプラグインであったりしても、natively instrumentedと呼んではなりません。

Telemetry SDK

OpenTelemetry APIを実装するライブラリを表します。

ライブラリガイドラインおよびライブラリのリソースセマンティック規約を参照してください。

Constructors

コンストラクタとは、Application OwnerがOpenTelemetry SDKとContribパッケージを初期化・設定するために使う公開コードです。コンストラクタの例には、設定オブジェクト、環境変数、ビルダーがあります。

SDK Plugins

プラグインとは、OpenTelemetry SDKを拡張するライブラリです。プラグインインターフェースの例には、SpanProcessor、Exporter、Samplerインターフェースがあります。

Exporter Library

エクスポーターとは、Exporterインターフェースを実装し、コンシューマーにテレメトリーを送出するSDKプラグインです。

Instrumented Library

テレメトリーシグナル（トレース、メトリクス、ログ）が収集される対象のライブラリを表します。

OpenTelemetry APIへの呼び出しは、Instrumented Library自身によって行われることもあれば、別のInstrumentation Libraryによって行われることもあります。

例: org.mongodb.client。

Instrumentation Library

指定したInstrumented Libraryに対して計装を提供するライブラリを表します。組み込みのOpenTelemetry計装を持つ場合、Instrumented LibraryとInstrumentation Libraryは同一のライブラリになることがあります。

より詳細な定義と命名のガイドラインについては概要を参照してください。

例: io.opentelemetry.contrib.mongodb。

同義語: Instrumenting Library。

Tracer Name / Meter Name / Logger Name

これは、新しいTracerやMeterを作成するときに指定されるnameと（任意で）versionの引数を指します（Obtaining a Tracer、Obtaining a Meter、Obtaining a Loggerを参照）。name/versionの組は、Instrumentation Scope、例えばInstrumentation Libraryや、その他テレメトリーが発行されるスコープにおけるアプリケーションの単位を識別します。

Execution Unit

マルチタスクの様々な概念で使われる、逐次的なコード実行の最小単位を指す包括的な用語。例としてはスレッド、コルーチン、ファイバーがあります。

ログ

Log Record

イベントの記録。通常、レコードにはイベントが発生した時刻を示すタイムスタンプと、何が起きたのか、どこで起きたのかなどを記述するその他のデータが含まれます。

同義語: Log Entry。

Log

Log Recordの集合を指すために使われることがあります。人によってはLogを単一のLog Recordを指すために使うこともあるため、曖昧になりがちであり、この用語は慎重に使うべきであり、曖昧さが生じうる文脈では追加の修飾語（例えばLog Record）を使うべきです。

Embedded Log

Spanオブジェクトの中の、Eventsのリストに埋め込まれたLog Record。

Standalone Log

Spanに埋め込まれず、別の場所に記録されるLog Record。

Log Attributes

Log Recordに含まれるキーと値のペア。

Structured Logs

Log Recordの様々な要素（タイムスタンプ、属性など）を区別できる、明確に定義された構造を持つ形式で記録されるログ。例えばSyslogプロトコル（RFC 5424）はstructured-data形式を定義しています。

Flat File Logs

テキストファイルに、多くの場合1レコードにつき1行の形式で記録されるログ（複数行にわたるレコードも可能です）。より構造化された形式（例えばJSONファイル）でテキストファイルに書かれたログをFlat File Logsとみなすかどうかについて、業界内で共通の合意はありません。この区別が重要な場面では、具体的に明示することが推奨されます。

Log Appender / Bridge

ログアペンダーまたはブリッジとは、Log APIを使って既存のロギングライブラリのログをOpenTelemetryへ橋渡しするコンポーネントです。「log bridge」と「log appender」という用語は同義に使われており、これらのコンポーネントはデータをOpenTelemetryへ橋渡しするものですが、ロギングの領域ではしばしばアペンダーと呼ばれることを反映しています。

プロファイル

プロファイルはOpenTelemetryのシグナルを表します。

Profile

プロファイルシグナルの文脈において、プロファイルはOpenTelemetryのInstrumentation Scopeに関する1つ以上のサンプル（関連するメタデータを伴うスタックトレース）を保持します。

Profiling

プロファイリングとは、プロファイルシグナルとして報告されるデータを収集するプロセスを表します。