# 用語集

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


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

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

## ユーザーの役割

### 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](https://en.wikipedia.org/wiki/In-band_signaling)).
>
> （電気通信において、**インバンド信号**とは、音声や映像などのデータに使われる同じ帯域またはチャネル内で制御情報を送ることを指す。これに対し、**アウトオブバンド信号**は異なるチャネル、あるいは別のネットワークを介して送られる。）

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

### Manual Instrumentation

エンドユーザーのコードや共有フレームワーク（MongoDB、Redisなど）からテレメトリーを収集するために、[Tracing API](../trace/api/)、[Metrics 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*を実装するライブラリを表します。

[ライブラリガイドライン](/works/otel-specs-ja/spec/library-guidelines/#sdkの実装)および[ライブラリのリソースセマンティック規約](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/resource/README.md#telemetry-sdk)を参照してください。

### 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](#instrumentation-library)によって行われることもあります。

例: `org.mongodb.client`。

### Instrumentation Library

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

より詳細な定義と命名のガイドラインについては[概要](../overview/#instrumentation-library)を参照してください。

例: `io.opentelemetry.contrib.mongodb`。

同義語: *Instrumenting Library*。

### Tracer Name / Meter Name / Logger Name

これは、新しい`Tracer`や`Meter`を作成するときに指定される`name`と（任意で）`version`の引数を指します（[Obtaining a Tracer](../trace/api/#tracerprovider)、[Obtaining a Meter](../metrics/api/#meterprovider)、[Obtaining a Logger](https://opentelemetry.io/docs/specs/otel/logs/api/#loggerprovider)を参照）。name/versionの組は、[Instrumentation Scope](/works/otel-specs-ja/spec/common/instrumentation-scope/)、例えば[Instrumentation Library](#instrumentation-library)や、その他テレメトリーが発行されるスコープにおけるアプリケーションの単位を識別します。

### Execution Unit

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

## ログ

### Log Record

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

同義語: *Log Entry*。

### Log

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

### Embedded Log

[Span](../trace/api/#span)オブジェクトの中の、[Events](../trace/api/#add-events)のリストに埋め込まれた`Log Record`。

### Standalone Log

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

### Log Attributes

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

### Structured Logs

Log Recordの様々な要素（タイムスタンプ、属性など）を区別できる、明確に定義された構造を持つ形式で記録されるログ。例えば*Syslogプロトコル*（[RFC 5424](https://datatracker.ietf.org/doc/html/rfc5424)）は`structured-data`形式を定義しています。

### Flat File Logs

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

### Log Appender / Bridge

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

## プロファイル

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

### Profile

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

### Profiling

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