OpenTelemetry

OBI ネットワークメトリクスの設定オプション

Fri, 23 Oct 2026 10:16:00 -0400

ネットワークメトリクスは、OBI 設定 YAML ファイルの network プロパティ、または OTEL_EBPF_NETWORK_ を接頭辞とする環境変数のセットで設定します。

YAML の例:

network:
 enable: true
 cidrs:
 - 10.10.0.0/24
 - 10.0.0.0/8
 - 10.30.0.0/16
attributes:
 kubernetes:
 enable: true
 select:
 obi_network_flow_bytes:
 include:
 - k8s.src.owner.name
 - k8s.src.namespace
 - k8s.dst.owner.name
 - k8s.dst.namespace
 - src.cidr
 - dst.cidr
otel_metrics_export:
 endpoint: http://localhost:4318

network YAML セクションに加えて、OBI の設定にはネットワークメトリクスをエクスポートするためのエンドポイントが必要です（前述の例では otel_metrics_export ですが、Prometheus エンドポイントも受け付けます）。

ネットワークメトリクスの設定プロパティ

ネットワークメトリクスを有効化するには、第一階層のメトリクスセクションの features に次のいずれかを追加します。

network は obi_network_flow_bytes メトリクスを有効化します。これは、クラスター内の 2 つのエンドポイント間のバイト数です
network_inter_zone は obi_network_inter_zone_bytes メトリクスを有効化します。これは、クラウドクラスター内の異なるアベイラビリティゾーン間のバイト数です

注意

obi_network_inter_zone_bytes 仕様は現在実験的であり、Kubernetes クラスターでのみ利用可能です。仕様は最終的なものではなく、将来のバージョンの OBI で破壊的変更が導入される可能性があります。

DockerコンテナとしてOBIを実行する

Fri, 23 Oct 2026 10:16:00 -0400

OBIは、スタンドアロンのDockerコンテナとして実行し、別のコンテナで実行されているプロセスを計装できます。

OBIのコンテナイメージは、以下の両方のレジストリに公開されています。

Docker Hub: otel/ebpf-instrument:v<version>
GHCR: ghcr.io/open-telemetry/opentelemetry-ebpf-instrumentation/ebpf-instrument:v<version>

開発タグは Docker Hub にも以下の名前で公開されています。

otel/ebpf-instrument:main

OBIコンテナは、次のように構成する必要があります。

特権コンテナとして実行するか、SYS_ADMIN ケーパビリティを持つコンテナとして実行します(ただし、この最後のオプションは一部のコンテナ環境では機能しない場合があります)。
host PID名前空間を使用して、他のコンテナ内のプロセスにアクセスできるようにします。

イメージの署名と検証

OBIコンテナイメージは、GitHub Actions の OIDC（OpenID Connect）プロトコルで認証されたエフェメラルキーを使用して、Cosign で署名されています。これにより、OpenTelemetry プロジェクトが公開したコンテナの真正性と完全性が保証されます。

以下のコマンドを使用して、コンテナイメージの署名を検証できます。

export VERSION=v0.12.1

# Docker Hub のリリースイメージを検証する
cosign verify --certificate-identity-regexp 'https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/' --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' otel/ebpf-instrument:${VERSION}

# GHCR の同じリリースを検証する
cosign verify --certificate-identity-regexp 'https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/' --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' ghcr.io/open-telemetry/opentelemetry-ebpf-instrumentation/ebpf-instrument:${VERSION}

出力例を以下に示します。

Verification for index.docker.io/otel/ebpf-instrument:main --
The following checks were performed on each of these signatures:
 - The cosign claims were validated
 - Existence of the claims in the transparency log was verified offline
 - The code-signing certificate was verified using trusted certificate authority certificates

[{"critical":{"identity":{"docker-reference":"index.docker.io/otel/ebpf-instrument:main"},"image":{"docker-manifest-digest":"sha256:55426a2bbb8003573a961697888aa770a1f5f67fcda2276dc2187d1faf7181fe"},"type":"https://sigstore.dev/cosign/sign/v1"},"optional":{}}]

検証が成功すると、Cosign のクレームが検証されたことと署名されたイメージダイジェストが表示されます。検証が失敗した場合は、以下を確認してください。

OBI Config v2 リファレンス

Fri, 23 Oct 2026 10:16:00 -0400

Config v2 は OBI v0.11.0 以降で利用可能です。 OpenTelemetry の宣言的構成構造を使用します。リソース、サンプリング、エクスポーターなどの共通設定はドキュメントのルートに配置し、OBI 固有の設定は extensions.obi 配下にまとめます。

すでに Config v1 ファイルがある場合は、手動で書き直すかわりに Config v1 から v2 への移行ガイドを使用してください。

構成構造の選択

構成の構造は、OBI の実行方法によって異なります。

スタンドアロン OBI: 完全な OpenTelemetry 宣言的構成ドキュメントを使用します。共通の OpenTelemetry 設定をドキュメントのルートに定義し、OBI 設定を extensions.obi 配下に定義します。
OBI Collector レシーバー: OBI のキャプチャ設定を receivers.obi 配下に直接定義します。リソースエンリッチメント、処理、エクスポートの設定には Collector パイプラインを使用します。

スタンドアロン OBI の設定

以下の例では、1 つの実行可能ファイルを計装し、キャプチャしたスパンをデバッグ用に標準出力に出力します。この設定を本番環境で使用する前に、実行可能ファイルのパスを置き換え、debug_trace_output を削除し、tracer_provider 配下に OTLP エクスポーターを設定してください。

file_format: '1.0'

extensions:
 obi:
 version: '2.0'
 capture:
 policy:
 default_action: exclude
 rules:
 - action: include
 match:
 process:
 exe_path_glob: ['/path/to/your/application']
 daemon:
 logging:
 debug_trace_output: text

OBI を起動する前に、構成ファイルを検証します。

OBI グローバル設定プロパティ

Fri, 23 Oct 2026 10:16:00 -0400

注記

このページでは Config v1 のフィールド名、例、環境変数を使用しています。 Config v2 については、Config v2 リファレンスを参照してください。既存のファイルを変換するには、移行ガイドを使用してください。

OBI は、環境変数またはコマンドライン引数 -config か環境変数 OTEL_EBPF_CONFIG_PATH を使用して渡す YAML 設定ファイルを通じて設定できます。環境変数は設定ファイルのプロパティよりも優先されます。たとえば、次のコマンドラインでは、OTEL_EBPF_LOG_LEVEL オプションが config.yaml 内の log_level 設定を上書きします。

設定引数の場合は次のとおりです。

OTEL_EBPF_LOG_LEVEL=debug obi -config /path/to/config.yaml

設定環境変数の場合は次のとおりです。

OTEL_EBPF_LOG_LEVEL=debug OTEL_EBPF_CONFIG_PATH=/path/to/config.yaml obi

設定ファイルのテンプレートについては、YAML 設定ファイルの例を参照してください。

OBI は、HTTP および gRPC アプリケーションからトレースを生成、変換、エクスポートするコンポーネントのパイプラインで構成されています。 YAML 設定では、各コンポーネントに独自のトップレベルセクションがあります。

オプションとして、OBI はネットワークレベルのメトリクスも提供します。詳細については、ネットワークメトリクスのドキュメントを参照してください。

以下のセクションでは、OBI 設定全体に適用されるグローバル設定プロパティについて説明します。

例

trace_printer: json
shutdown_timeout: 30s
channel_buffer_len: 33

YAML 環境変数	説明	型	デフォルト
(YAML なし) `OTEL_EBPF_AUTO_TARGET_EXE`	実行可能ファイルのフルパスへのグロブマッチングによって計装するプロセスを選択します。	string	未設定
(YAML なし) `OTEL_EBPF_AUTO_TARGET_LANGUAGE`	検出されたプログラミング言語（グロブマッチャー）によって計装するプロセスを選択します。たとえば `go`、`java`、`nodejs` などです。	string	未設定
`open_port` `OTEL_EBPF_OPEN_PORT`	オープンポートによって計装するプロセスを選択します。ポートとポート範囲のカンマ区切りリストを受け付けます。	string	未設定
`target_pids` `OTEL_EBPF_TARGET_PID`	PID によって計装するプロセスを選択します。YAML リスト、単一値、またはカンマ区切り環境変数リストを受け付けます。	integer または integer のリスト	未設定
`shutdown_timeout` `OTEL_EBPF_SHUTDOWN_TIMEOUT`	グレースフルシャットダウンのタイムアウトを設定します。	string	“10s”
`log_level` `OTEL_EBPF_LOG_LEVEL`	プロセスロガーの詳細レベルを設定します。有効な値は `DEBUG`、`INFO`、`WARN`、`ERROR` です。	string	`INFO`
`log_format` `OTEL_EBPF_LOG_FORMAT`	ロガーの出力形式を設定します。有効な値は `text`、`json`　です。	string	`text`
`trace_printer` `OTEL_EBPF_TRACE_PRINTER`	計装されたトレースを指定された形式で標準出力に出力します。トレースプリンター形式を参照してください。	string	`disabled`
`enforce_sys_caps` `OTEL_EBPF_ENFORCE_SYS_CAPS`	起動時にシステムケーパビリティが不足している場合の OBI の処理方法を制御します。	boolean	`false`

ヘルスチェックエンドポイント

OBI は TCP または Unix ドメインソケットを介して /healthz を公開できます。 JSON レスポンスにはスキーマバージョン、現在の Unix 時刻、プロセスのアップタイムが含まれます。このエンドポイントはデフォルトで無効です。

クラウドアベイラビリティゾーン間のトラフィックを測定する

Fri, 23 Oct 2026 10:16:00 -0400

注記

この機能は現在 Kubernetes クラスターでのみ利用可能です。

クラウドアベイラビリティゾーン間のトラフィックには追加コストがかかる場合があります。 OBI は、通常のネットワークメトリクスに src.zone および dst.zone 属性を追加するか、または別のメトリクス obi.network.inter.zone.bytes（OTel）/ obi_network_inter_zone_bytes_total（Prometheus）を提供することで、これを測定できます。

通常のネットワークメトリクスに `src.zone` と `dst.zone` 属性を追加する

送信元と送信先のアベイラビリティゾーン属性は、OBI ではデフォルトで無効化されています。有効化するには、OBI の YAML 設定で含めるネットワーク属性のリストに明示的に追加します。

attributes:
 select:
 obi_network_flow_bytes:
 include:
 - k8s.src.owner.name
 - k8s.src.namespace
 - k8s.dst.owner.name
 - k8s.dst.namespace
 - k8s.cluster.name
 - src.zone
 - dst.zone

この設定により、異なる src_zone および dst_zone 属性を持つ obi_network_flow_bytes_total メトリクスごとにゾーン間トラフィックが可視化されます。

ゾーン間トラフィック測定でより高い粒度（たとえば、送信元/送信先の Pod やノード）が必要な場合、ゾーン属性の追加は、同じアベイラビリティゾーン内のトラフィックに対してもメトリクスのカーディナリティに影響します。

`obi.network.inter.zone` メトリクスを使用する

ゾーン間トラフィック用に別のメトリクスを使用すると、通常のネットワークメトリクスに src.zone および dst.zone 属性が追加されないため、データ収集によるメトリクスのカーディナリティへの影響を低減できます。

obi.network.inter.zone メトリクスを有効化するには、network_inter_zone オプションを OTEL_EBPF_METRICS_FEATURES 設定オプション、またはそれに対応する YAML オプションに追加します。たとえば、OBI が OpenTelemetry 経由でメトリクスをエクスポートするように設定されている場合は次のとおりです。

OBI ネットワークメトリクスのクイックスタート

Fri, 23 Oct 2026 10:16:00 -0400

OBI は、あらゆる環境（物理ホスト、仮想ホスト、コンテナ）でネットワークメトリクスを生成できます。 OBI は送信元および送信先の Kubernetes エンティティのメタデータで各メトリクスを装飾できるため、Kubernetes 環境の使用が推奨されます。

このクイックスタートガイドの手順は、kubectl コマンドラインユーティリティを使用して直接 Kubernetes にデプロイすることに焦点を当てています。このチュートリアルでは、OBI を Kubernetes にゼロからデプロイする方法を説明します。 Helm を使用する場合は、Helm を使用した Kubernetes への OBI のデプロイドキュメントを参照してください。

ネットワークメトリクスを有効化して OBI をデプロイする

ネットワークメトリクスを有効化するには、OBI の設定で次のオプションを指定します。

環境変数:

export OTEL_EBPF_NETWORK_METRICS=true

ネットワークメトリクスでは、メトリクスを Kubernetes メタデータで装飾する必要があります。この機能を有効化するには、OBI の設定で次のオプションを指定します。

環境変数:

export OTEL_EBPF_KUBE_METADATA_ENABLE=true

その他の設定オプションについては、OBI 設定オプションを参照してください。

OBI の設定の詳細については、OBI 設定ドキュメントを参照してください。

シンプルなセットアップ

OBI をデプロイする

次の YAML 設定は、ネットワークメトリクス用のシンプルな OBI デプロイメントを提供します。

apiVersion: v1
kind: ServiceAccount
metadata:
 namespace: obi
 name: obi
---
apiVersion: v1
kind: ConfigMap
metadata:
 namespace: obi
 name: obi-config
data:
 obi-config.yml: |
 network:
 enable: true
 attributes:
 kubernetes:
 enable: true
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
 namespace: obi
 name: obi
spec:
 selector:
 matchLabels:
 instrumentation: obi
 template:
 metadata:
 labels:
 instrumentation: obi
 spec:
 serviceAccountName: obi
 hostNetwork: true
 dnsPolicy: ClusterFirstWithHostNet
 containers:
 - name: obi-config
 configMap:
 name: obi-config
 - name: obi
 image: otel/ebpf-instrument:main
 securityContext:
 privileged: true
 volumeMounts:
 - mountPath: /config
 name: obi-config
 env:
 - name: OTEL_EBPF_CONFIG_PATH
 value: '/config/obi-config.yml'

この設定についての注意点は次のとおりです。

OBI のエクスポートモードを構成する

Fri, 23 Oct 2026 10:16:00 -0400

注記

このページでは Config v1 のフィールド名と例を使用しています。 Config v2 については、Config v2 リファレンスを参照してください。既存のファイルを変換するには、移行ガイドを使用してください。

Direct モードでは、OBI は OpenTelemetry protocol（OTLP）を使用して、メトリクスとトレースをリモートエンドポイントへ直接プッシュします。

OBI は、たとえばプルモードでスクレイプできるように、Prometheus HTTP エンドポイントを公開することもできます。

Direct モードを使用するには、認証情報を含む構成が必要です。 OTLP エンドポイントの認証情報は、次の環境変数で設定します。

OTEL_EXPORTER_OTLP_ENDPOINT
OTEL_EXPORTER_OTLP_HEADERS

Prometheus のスクレイプエンドポイントを使用して Direct モードで実行する方法については、構成ドキュメントを参照してください。

OBI の構成と実行

このチュートリアルでは、OBI と OTel Collector が同じホスト上でネイティブに実行されていることを前提としています。そのため、トラフィックを保護したり、OTel Collector の OTLP レシーバーで認証を提供したりする必要はありません。

OpenTelemetry eBPF Instrumentation をインストールし、サンプルの構成ファイルをダウンロードしてください。

まず、計装する実行ファイルを指定します。ポート 443 で実行されているサービスの実行ファイルの場合は、YAML ドキュメントに open_port プロパティを追加します。

discovery:
 instrument:
 - open_ports: 443

次に、トレースとメトリクスの送信先を指定します。 OTel collector がローカルホストで実行されている場合は、ポート 4318 を使用します。

HelmでKubernetesにOBIをデプロイする

Sun, 18 Oct 2026 02:41:27 +0000

注記

Helm の各種設定オプションの詳細については、 OBI Helm チャートドキュメントを参照するか、 Artifact Hub でチャートを参照してください。詳細な設定パラメーターについては、 values.yaml ファイルを参照してください。

Helm から OBI をデプロイする
OBI の設定
OBI メタデータの設定
k8s-cache による Kubernetes メタデータの集約
Helm 設定へのシークレットの提供

Helm から OBI をデプロイする

まず、OpenTelemetry Helm リポジトリを Helm に追加する必要があります。

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts

次のコマンドは、obi 名前空間にデフォルト設定の OBI DaemonSet をデプロイします。

helm install obi -n obi --create-namespace open-telemetry/opentelemetry-ebpf-instrumentation

OBI のデフォルト設定は次のようになっています。

Pod HTTP ポート 9090 の /metrics パスで Prometheus メトリクスとしてメトリクスをエクスポートします。
クラスター内のすべてのアプリケーションを計装しようとします。
デフォルトではアプリケーションレベルのメトリクスのみを提供し、ネットワークレベルのメトリクスは除外します。
k8s.namespace.name や k8s.pod.name などの Kubernetes メタデータラベルでメトリクスを装飾するよう OBI を設定します。

OBI の設定

OBI のデフォルト設定をオーバーライドしたい場合があります。たとえば、Prometheus のかわりに OpenTelemetry としてメトリクスやスパンをエクスポートしたり、計装するサービス数を制限したりする場合です。

OpenTelemetry PHP Distro のセットアップ

Mon, 21 Sep 2026 07:12:04 +0000

OpenTelemetry PHP Distro を使用して PHP アプリケーションを計装し、OTLP 互換バックエンドにテレメトリーデータを送信する方法を学びます。

前提条件

テレメトリーデータの送信先（OTLP エンドポイント）があること。
サポートされている Linux ディストリビューションと PHP バージョンを使用していること。
同じプロセスで他の PHP APM や OpenTelemetry エージェントを実行していないこと。

サポートされているオペレーティングシステムと PHP バージョンについては、サポートされているテクノロジーを参照してください。

制限事項

既知のランタイムおよび互換性の制限事項については、制限事項に記載されています。

パッケージのダウンロードとインストール

GitHub Releases ページからプラットフォームに合ったパッケージをダウンロードしてインストールします。

RPM（RHEL/CentOS/Fedora）

sudo rpm -ivh <package-file>.rpm

DEB（Debian/Ubuntu）

sudo dpkg -i <package-file>.deb

APK（Alpine）

sudo apk add --allow-untrusted <package-file>.apk

エクスポーターの設定

最低限、以下を設定してください。

OTEL_EXPORTER_OTLP_ENDPOINT
OTEL_EXPORTER_OTLP_HEADERS

例:

export OTEL_EXPORTER_OTLP_ENDPOINT="https://your-otlp-endpoint:443/"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer <token>"

PHP プロセスの再起動

インストールと設定が完了したら、PHP プロセス（たとえば php-fpm、Apache ワーカー、長時間実行される CLI ワーカー）を再起動して、エクステンションをロードします。

パフォーマンスオーバーヘッド

Sun, 20 Sep 2026 00:56:06 +0000

このページでは、OpenTelemetry PHP Distro を使用する際のパフォーマンスへの影響を概説し、オーバーヘッドを最小化するためのガイダンスを提供します。

他の計装エージェントと同様に、Distro はアプリケーションプロセス内で実行され、ランタイムコストが追加されます。正確な影響は、アーキテクチャ、設定、デプロイ環境、ワークロードによって異なります。

以下のベンチマークでは、ローカルの Docker セットアップ（PHP-FPM 8.2 + NGINX）で複数の PHP オブザーバビリティのバリアントを比較しています。コレクターを使用するシナリオでは、コレクターもローカルで実行され、ホストの CPU リソースを共有しています。

ベンチマークのセットアップ

アプリケーション: PHP-FPM 8.2 上の Laravel/Aimeos
環境: NGINX を使用したローカル Docker
テレメトリーの送信先: OTLP 互換エンドポイント

結果

バリアント	リクエストあたりの平均時間 [ms]	オーバーヘッド [ms]
エージェントなし	17.36	0.00
ベンダー固有の APM エージェント	20.63	3.27
OpenTelemetry PHP Distro	23.08	5.71
OpenTelemetry PHP Distro + ローカルコレクター	24.37	7.01
バニラ OpenTelemetry PHP + protobuf（C エクステンション）+ コレクター	25.76	8.40
バニラ OpenTelemetry PHP pure-PHP protobuf エクスポート + コレクター	49.02	31.66
バニラ OpenTelemetry PHP pure-PHP protobuf エクスポート	2158.58	2141.22

主な知見

OpenTelemetry PHP Distro は、pure-PHP protobuf エクスポートを使用したバニラ OpenTelemetry PHP と比較して、オーバーヘッドを大幅に削減します。
ローカルのコレクター配置は、PHP ワーカーと CPU を取り合う場合にオーバーヘッドを増加させる可能性があります。
バニラ OpenTelemetry PHP の pure-PHP protobuf エクスポートは、このベンチマークでは非常に高いオーバーヘッドをもたらします。

推奨事項

自身のワークロードとインフラストラクチャでオーバーヘッドを測定してください。
非同期トランスポートを使用した OTLP HTTP/protobuf を優先してください。
レイテンシーに敏感なアプリケーションワーカーと、負荷の高いコレクターワークロードの同居は避けてください。
SLO を満たすようにサンプリングとエクスポーターの設定を調整してください。

制限事項

Sun, 20 Sep 2026 00:55:07 +0000

このページでは、OpenTelemetry PHP Distro の既知の制限事項と制約について説明します。

他の PHP テレメトリーエージェントとの併用

OpenTelemetry PHP Distro を、他の PHP APM や OpenTelemetry エージェントと同じプロセス内で同時に実行しないでください。両方を実行すると、競合、重複した計装、不安定な動作の原因になります。

`open_basedir`

php.ini で open_basedir が有効な場合、distro のインストールパスを許可されたパスに含める必要があります。含めない場合、エージェントの読み込みに失敗する可能性があります。

`xdebug`

xdebug との併用は本番環境では推奨されず、計装されたプロセスで安定性やメモリの問題を引き起こす可能性があります。

ファイルベース設定（`OTEL_CONFIG_FILE`）

ファイルベース（宣言的）設定を使用する場合:

リモート設定（OpAMP）は利用できません。ファイルベース設定とリモート設定は相互に排他的です。
Registry::registerResourceDetector() で登録されたリソースディテクター（たとえば opentelemetry-php-contrib のクラウドプロバイダーディテクター）は自動的には有効になりません。 ComponentProvider を提供し、YAML の resource.detection/development.detectors セクションに明示的にリストする必要があります。
distro には telemetry.distro.name と telemetry.distro.version 属性のためのビルトイン distro ディテクターが付属しています。使い方については設定を参照してください。
YAML ファイル内の環境変数の置換（${VAR_NAME}）は、値の読み取りに $_SERVER を使用します。ウェブサーバーコンテキスト（Apache、nginx+FPM）では、プロセス環境変数は自動的に $_SERVER で利用可能にはなりません。 YAML 設定で ${VAR_NAME} 置換を使用するには、変数が PHP に公開されていることを確認してください:
- Apache (mod_php): バーチャルホスト設定で PassEnv VAR_NAME または SetEnv VAR_NAME value を使用してください。
- PHP-FPM: FPM プール設定で env[VAR_NAME] = value を設定するか、clear_env = no を設定してすべてのプロセス環境変数を渡してください。
- または、${VAR_NAME} 置換を使用するかわりに、YAML ファイルに値を直接ハードコードしてください。

仕様ステータスの概要

Wed, 16 Sep 2026 00:09:32 +0000

OpenTelemetryは、シグナルごとに開発されています。シグナルの例として、トレース、メトリクス、バゲッジ、ロギングがあります。シグナルは、分散システム全体でデータを相関させるための共有メカニズムであるコンテキスト伝搬に基づいて構築されています。

各シグナルは、4つのコアコンポーネントで構成されています。

シグナルには、プラグインと計装のエコシステムであるcontribコンポーネントも存在します。すべての計装は同じセマンティック規則を共有しており、HTTPリクエストなどの一般的な操作を監視する際に同じデータを生成することを保証しています。

シグナルとコンポーネントの詳細については、OTel仕様の概要を参照してください。

コンポーネントのライフサイクル

コンポーネントは、Draft、Experimental、Stable、Deprecated、Removedの開発サイクルに従います。

Draft コンポーネントは設計中であり、仕様には追加されていません。
Experimental コンポーネントはリリースされており、ベータテストが可能です。
Stable コンポーネントは後方互換性があり、長期サポートの対象となります。
Deprecated コンポーネントは安定していますが、最終的には削除される可能性があります。

ライフサイクルと長期サポートの完全な定義については、バージョニングと安定性を参照してください。

現在のステータス

以下は、現在利用可能なシグナルの高レベルなステータスレポートです。 OpenTelemetryクライアントは共通の仕様に準拠していますが、それぞれ独立して開発されている点に注意してください。

各クライアントの現在のステータスは、GitHubリポジトリのREADMEで確認することをお勧めします。特定の機能に対するクライアントのサポート状況は、仕様準拠の表で確認できます。

次の各セクションでは、コレクターのステータスはプロトコルのステータスと同じであることに注意してください。

トレーシング

仕様
API: stable
SDK: stable
プロトコル: stable
注意事項:
- トレーシングの仕様は現在完全に安定しており、長期サポートの対象となっています。
- トレーシングの仕様は拡張可能ですが、後方互換性のある方法のみです。
- OpenTelemetryクライアントは、トレーシングの実装が完了するとv1.0にバージョニングされます。

メトリクス

仕様
API: stable
SDK: mixed
プロトコル: stable
注意事項:
- OpenTelemetryのメトリクスは現在アクティブに開発中です。
- データモデルはOTLPプロトコルの一部として安定してリリースされています。
- 実験的なメトリクスパイプラインのサポートがコレクターで利用可能です。
- PrometheusのCollectorサポートは、Prometheusコミュニティと協力して開発中です。

バゲッジ

仕様
API: stable
SDK: stable
プロトコル: N/A
注意事項:
- OpenTelemetryのバゲッジは現在完全に安定しています。
- バゲッジはオブザーバビリティツールではなく、トランザクションに任意のキーと値を付与し、ダウンストリームのサービスがそれらにアクセスできるようにするシステムです。そのため、バゲッジにはOTLPやコレクターのコンポーネントは存在しません。

ロギング

仕様
Bridge API: stable
SDK: stable
プロトコル: stable
注意事項:
- ログデータモデルは、OpenTelemetryプロトコルの一部としてリリースされています。
- StanzaのOpenTelemetryプロジェクトへの寄贈により、多くのデータ形式のログ処理がコレクターに追加されました。
- OpenTelemetry Log Bridge APIを使用して、既存のログフレームワークからOpenTelemetryにログをブリッジするアペンダーの作成できます。 Log Bridge APIは、エンドユーザーが直接呼び出すことを想定していません。ログアペンダーは現在多くの言語で開発中です。
- OpenTelemetry Log SDKは、Log Bridge APIの標準的な実装です。アプリケーションはSDKを構成して、ログの処理とエクスポート方法（例、OTLPの使用）を指定します。
- OpenTelemetry Log Bridge APIは、イベントセマンティック規約に準拠したログレコードを発行するための実験的なサポートを含んでいます。

プロファイル

仕様
プロトコル: development

はじめに

Fri, 11 Sep 2026 01:10:10 +0000

このページでは、OpenTelemetry を使って Kubernetes クラスターの監視を始める最速の方法を説明します。 Kubernetesクラスター、ノード、ポッド、コンテナのメトリクスとログの収集、そしてクラスタがOTLPデータを出力するサービスをサポートできるようにすることに焦点を当てます。

Kubernetes で OpenTelemetry が動いているところを見たいのであれば、OpenTelemetryデモから始めるのがベストです。このデモは OpenTelemetry の実装を説明するためのものですが、Kubernetes 自体を監視する方法の例ではありません。このウォークスルーを終えたら、デモをインストールして、すべての監視がアクティブなワークロードにどのように反応するかを見るのは楽しい実験になるでしょう。

PrometheusからOpenTelemetryへの移行を始めようとしている場合、あるいはOpenTelemetryコレクターを使ってPrometheusメトリクスを収集することに興味がある場合は、Prometheusレシーバーを参照してください。

概要

Kubernetesは多くの重要なテレメトリーをさまざまな方法で公開しています。ログ、イベント、多くの異なるオブジェクトのメトリクス、そしてワークロードによって生成されたデータがあります。

このすべてのデータを収集するために、OpenTelemetryコレクターを使用します。コレクターは、このデータを効率的に収集し、意味のある方法で強化できる、自由に使えるさまざまなツールを備えています。

すべてのデータを収集するには、コレクターを2つの方法でインストールする必要があります。 1つはデーモンセットとして、もう1つはデプロイメントとしてです。コレクターのデーモンセットインストールは、ノード、ポッド、コンテナのサービス、ログ、メトリクスが発するテレメトリーを収集するために使用されます。コレクターのデプロイメントインストールは、クラスタのメトリクスとイベントの収集に使用されます。

コレクターをインストールするには、OpenTelemetry Collector Helm チャートを使用します。 Helm には、コレクターを簡単に設定するためのいくつかの設定オプションが付属しています。 Helm に慣れていない場合は、Helm プロジェクトサイトを確認してください。 Kubernetes オペレーターを使うことに興味があるなら、OpenTelemetry Operator を参照してほしいですが、このガイドでは Helm チャートにフォーカスします。

準備

このガイドでは、Kindクラスターを使用することを前提に説明しますが、適切と思われるKubernetesクラスターを自由に使用することができます。

すでにKindがインストールされていると仮定して、新しいKindクラスタを作成します。

kind create cluster

すでに Helm がインストールされていると仮定して、OpenTelemetry Collector Helm チャートを追加し、後でインストールできるようにします。

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts

デーモンセットコレクター

Kubernetesのテレメトリーを収集する最初のステップは、ノードとそのノード上で実行されているワークロードに関連するテレメトリーを収集するために、OpenTelemetry Collectorのデーモンセットインスタンスをデプロイすることです。デーモンセットは、コレクターのこのインスタンスがすべてのノードにインストールされていることを保証するために使用されます。デーモンセット内のコレクターの各インスタンスは、それが実行されているノードからのみデータを収集します。

対応テクノロジー

Thu, 10 Sep 2026 13:10:23 +0000

OpenTelemetry PHP Distro は OpenTelemetry PHP のディストリビューションです。 OpenTelemetry の互換性を継承し、ネイティブコンポーネントによってランタイム機能を拡張します。

自動計装の範囲

自動計装は対応するフレームワークやライブラリのテレメトリーをキャプチャしますが、以下は計装しません。

プロプライエタリまたはカスタムフレームワークの内部
計装フックのないクローズドソースコンポーネント
アプリケーション固有のビジネスロジック

対応していない領域については、手動の OpenTelemetry 計装を使用してください。

PHP バージョン

対応する PHP バージョン: 8.1 から 8.5。

対応する SAPI

php-cli
php-fpm
php-cgi/fcgi
mod_php（prefork）

対応するオペレーティングシステム

Linux
- アーキテクチャ: x86_64、arm64
- glibc ベースのシステム: deb、rpm
- musl ベースのシステム（Alpine）: apk

計装済みフレームワーク

Laravel 6.x から 13.x
Slim 4.x

計装済みライブラリ

cURL
HTTP async（php-http/httplug）
MySQLi
PDO
PostgreSQL
PSR-18 HTTP Client（psr/http-client）

同梱の自動計装パッケージ

名前	ディストロバージョン	パッケージ
`curl`	1.0	open-telemetry/opentelemetry-auto-curl
`http-async-client`	1.0	open-telemetry/opentelemetry-auto-http-async
`laravel`	1.0	open-telemetry/opentelemetry-auto-laravel
`mysqli`	1.0	open-telemetry/opentelemetry-auto-mysqli
`pdo`	1.0	open-telemetry/opentelemetry-auto-pdo
`postgresql`	1.2	open-telemetry/opentelemetry-auto-postgresql
`psr18`	0.5	open-telemetry/opentelemetry-auto-psr18
`slim`	1.0	open-telemetry/opentelemetry-auto-slim

同梱のメトリクスパッケージ

ディストロバージョン	パッケージ	出力メトリクス
0.6.0	open-telemetry/opentelemetry-metrics-runtime	PHP memory usage, GC cycles, peak memory

追加のランタイム機能

自動ルートスパン生成
ルートスパンの URL グルーピング
推論スパン
属性ベースの計装（#[WithSpan]、#[SpanAttribute]）
バックグラウンドテレメトリー送信
PHP ランタイムメトリクス（メモリ、GC — ネイティブ非同期トランスポート経由で自動的にエクスポート）

バックグラウンド送信（ノンブロッキングエクスポート）は OTLP http/protobuf（デフォルト）で動作します。エクスポーターまたはプロトコルが対応していないトランスポート（たとえば gRPC）に変更された場合、エクスポートは同期的になります。

設定

Thu, 03 Sep 2026 05:34:28 +0000

OpenTelemetry PHP Distro は、標準的な OpenTelemetry SDK の設定と Distro 固有のオプションをサポートしています。

設定方法

PHP プロセスで利用可能な環境変数を使用して設定します。

OTEL_*：OpenTelemetry 標準オプション
OTEL_PHP_*：Distro 固有のオプション

例:

export OTEL_EXPORTER_OTLP_ENDPOINT="https://your-endpoint:443/"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer <token>"
export OTEL_PHP_LOG_LEVEL_STDERR="INFO"

OpenTelemetry オプション

Distro は標準的な OpenTelemetry PHP SDK オプションをサポートしています。

オプション	デフォルト	使用可能な値	説明
`OTEL_EXPORTER_OTLP_ENDPOINT`	`http://localhost:4318`	URL	OTLP エンドポイント URL
`OTEL_EXPORTER_OTLP_HEADERS`	（空）	`key=value,key2=value2`	OTLP リクエストヘッダー
`OTEL_EXPORTER_OTLP_INSECURE`	`false`	`true` または `false`	TLS 検証を無効化（テスト専用）
`OTEL_EXPORTER_OTLP_CERTIFICATE`	（空）	ファイルシステムパス（PEM）	OTLP TLS 用の CA 証明書パス
`OTEL_EXPORTER_OTLP_CLIENT_CERTIFICATE`	（空）	ファイルシステムパス（PEM）	OTLP mTLS 用のクライアント証明書
`OTEL_EXPORTER_OTLP_CLIENT_KEY`	（空）	ファイルシステムパス（PEM）	OTLP mTLS 用のクライアント鍵
`OTEL_EXPORTER_OTLP_CLIENT_KEYPASS`	（空）	文字列	暗号化された OTLP クライアント鍵のパスフレーズ
`OTEL_SERVICE_NAME`	`unknown_service`	文字列	`service.name` リソース属性の値
`OTEL_RESOURCE_ATTRIBUTES`	（空）	`key=value,key2=value2`	リソース属性
`OTEL_TRACES_SAMPLER`	`parentbased_always_on`	サンプラー名	トレースサンプラー
`OTEL_TRACES_SAMPLER_ARG`	（空）	文字列/数値	サンプラー引数
`OTEL_LOG_LEVEL`	`info`	`error`, `warn`, `info`, `debug`	SDK 内部ログレベル

Distro 固有のオプション（`OTEL_PHP_*`） {#distro-specific-options-otelphp}

すべての OTEL_PHP_* オプションは環境変数または php.ini で設定できます。

ログ

Fri, 14 Aug 2026 13:05:50 +0000

ログは、構造化（推奨）または非構造化された、任意のメタデータを含む、タイムスタンプ付きのテキストレコードです。すべてのテレメトリーシグナルの中で、ログは最も大きな遺産を持っています。ほとんどのプログラミング言語には、組み込みのログ機能があるか、もしくはよく知られ、広く使われているログライブラリがあります。

OpenTelemetry のログ

OpenTelemetry は、ログレコードを生成するための Logs API と SDK、そして既存のロギングフレームワークと統合するための言語 SDK とロギングブリッジを提供します。ログとは、ロギングプロバイダを通して送信されるあらゆるデータを指し、イベントはログの特殊なタイプです。すべてのログがイベントであるとは限りませんが、すべてのイベントはログです。 Logs API は公開されており、アプリケーションコードから直接使用することも、既存のロギングライブラリやブリッジを介して間接的に使用することもできます。

OpenTelemetry は、既に生成されているログを扱うように設計されており、ログを他のシグナルと関連付けたり、コンテキスト属性を追加したり、異なるソースを共通のフォーマットに正規化して処理およびエクスポートするためのツールを提供します。

OpenTelemetry コレクターの OpenTelemetry のログ

OpenTelemetry コレクターはログを扱うための複数のツールを提供します。

既知の特定のログデータソースを解析する複数のレシーバー
任意のファイルからログを読み取り、異なるフォーマットの解析や正規表現の解析が可能な filelogreceiver
ネストされたデータの解析、構造のフラット化、値の追加/削除/更新などを実行できる transformprocessor などのプロセッサー
OpenTelemetry 以外のフォーマットでログデータを送信できるエクスポーター

OpenTelemetry を採用する最初のステップとして、汎用的なログエージェントとしてコレクターをデプロイすることがよく含まれます。

アプリケーションの OpenTelemetry

アプリケーションにおいて、OpenTelemetry のログは任意のログライブラリやビルトインのログ機能を使って作成されます。自動計装を追加したりSDKを活用したりすると、OpenTelemetry は既存のログをアクティブなトレースやスパンと自動的に関連付け、それらの ID をログの本体に含めます。つまり、OpenTelemetry はログとトレースを自動的に関連付けます。

言語サポート

ログは OpenTelemetry 仕様の stable シグナルです。ログAPIとSDKの各言語固有の実装については、ステータスは以下の通りです。

Language	Logs
C++	Stable
C#/.NET	Stable
Erlang/Elixir	Development
Go	Release candidate
Java	Stable
JavaScript	Development
PHP	Stable
Python	Development
Ruby	Development
Rust	Stable
Swift	Development

構造化、非構造化、半構造化ログ

OpenTelemetryはあらゆるログ形式に対応していますが、すべての形式が分析に等しく役立つわけではありません。次のセクションでは、構造化ログ、半構造化ログ、非構造化ログの違いについて説明します。重要：JSON形式でエンコードされたログは、安定したスキーマを持つという意味で自動的に「構造化」されるわけではありません。半構造化されている場合もあります。構造化ログとは、一貫したスキーマ、または明確に定義された型付きフィールドを持ち、下流の処理が確実に依存できるログを指します。

メトリクス

Sat, 04 Jul 2026 13:13:37 +0900

メトリクスとは、実行時に取得されるサービスの測定値のことです。測定値を取得した瞬間はメトリクスイベントとして知られており、測定値そのものだけでなく、キャプチャした時刻と関連するメタデータから構成されます。

アプリケーションとリクエストのメトリクスは、可用性とパフォーマンスの重要な指標です。カスタムメトリクスは、可用性指標がユーザー体験やビジネスにどのような影響を与えるかについての洞察を提供できます。収集したデータを使用して、障害を警告したり、需要が高まったときにデプロイを自動的にスケールアップするスケジューリング決定をトリガーしたりできます。

OpenTelemetryのメトリクスがどのように機能するのかを理解するために、コードの計装の一部を担うコンポーネントのリストを見てみましょう。

メータープロバイダー

メータープロバイダー（MeterProvider と呼ばれることもあります）は、Meterのファクトリーです。ほとんどのアプリケーションでは、メータープロバイダーは一度だけ初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。メータープロバイダーの初期化には、リソースとエクスポーターの初期化も含まれます。これは通常、OpenTelemetryを使った計測の最初のステップです。いくつかの言語SDKでは、グローバルなメータープロバイダーがすでに初期化されています。

メーター

メーターはメトリクス計装を作成し、実行時にサービスに関する測定値を取得します。メーターはメータープロバイダーから作成されます。

メトリクスエクスポーター

メトリクスエクスポーターはメトリクスデータをコンシューマーに送ります。このコンシューマーは、開発中のデバッグのための標準出力、OpenTelemetryコレクター、あるいは、あなたが選んだオープンソースやベンダーのバックエンドです。

メトリクス計装

OpenTelemetryでは、計測は メトリクス計装 によって行われます。メトリクス計装は以下のように定義されます。

名前
種類
単位（オプション）
説明（オプション）

名前、単位、説明は、開発者が自分で定義するか、リクエストやプロセスメトリクスのような一般的なものについては、セマンティック規約を介して定義されます。

計装の種類は以下のいずれかです。

Counter（カウンター）：時間とともに蓄積される値。これは車のオドメーターのようなものだと考えられます。
Asynchronous Counter（非同期カウンター）： カウンター と同じですが、各エクスポートに対して一度だけ収集されます。連続したインクリメントにアクセスできず、集約された値のみにアクセスできる場合に使用できます。
UpDownCounter（アップダウンカウンター）: 時間の経過とともに蓄積されるけれども、減少することもある値。たとえば、キューの長さは、キュー内のワークアイテムの数によって増減します。
Asynchronous UpDownCounter（非同期アップダウンカウンター）: アップダウンカウンターと同じですが、各エクスポートに対して一度だけ収集されます。連続的な変更にアクセスできず、集約された値（たとえば、現在のキューのサイズ）のみにアクセスできる場合に使用できます。
Gauge（ゲージ）: 読み取った時点での現在の値を測定します。たとえば、自動車の燃料計など。ゲージは同期しています。
Asynchronous Gauge（非同期ゲージ）: ゲージと同じですが、各エクスポートに対して一度だけ収集されます。連続的な変更にアクセスできず、集約された値のみにアクセスできる場合に使用できます。
Histogram（ヒストグラム）: リクエストのレイテンシーなどの値をクライアント側で集約したもの。値の統計に興味がある場合は、ヒストグラムが良いでしょう。たとえば、どれくらいのリクエストが1秒未満か、といった疑問に答えてくれます。

同期と非同期の計装、またどの種類の計装があなたのユースケースにもっとも適しているかについては、補足ガイドラインを参照してください。

集約（アグリゲーション）

メトリクス計装に加えて、**集約（アグリゲーション）**という概念も理解すべき重要なものです。集約とは、多数の測定値を組み合わせて、ある時間ウィンドウの間に発生したメトリクスイベントに関する正確な統計値または推定統計値にする手法です。 OTLPプロトコルは、このような集約されたメトリクスを伝送します。 OpenTelemetry APIは、各計装に対してデフォルトの集約を提供します。これはビューを使ってオーバーライドできます。 OpenTelemetryプロジェクトは、ビジュアライザーやテレメトリーバックエンドでサポートされるデフォルトの集計を提供することを目指しています。

はじめに

Mon, 08 Jun 2026 08:54:21 +0900

セットアップ

opentelemetry-java-instrumentationリポジトリの Releasesからopentelemetry-javaagent.jarをダウンロードし、任意のディレクトリに配置してください。この JAR ファイルにはエージェントと計装ライブラリが含まれています。
JVM の起動引数に -javaagent:path/to/opentelemetry-javaagent.jar とその他の設定を追加し、アプリケーションを起動します。
- 起動コマンドに直接指定する場合。
```
java -javaagent:path/to/opentelemetry-javaagent.jar -Dotel.service.name=your-service-name -jar myapp.jar
```
- JAVA_TOOL_OPTIONS やその他の環境変数を経由する場合。
```
export JAVA_TOOL_OPTIONS="-javaagent:path/to/opentelemetry-javaagent.jar"
export OTEL_SERVICE_NAME="your-service-name"
java -jar myapp.jar
```

宣言的設定

宣言的設定では、環境変数やシステムプロパティのかわりに YAML ファイルを使用します。多くの設定オプションを指定する場合や、環境変数やシステムプロパティでは利用できない設定オプションを使用したい場合に便利です。

詳細については、宣言的設定ページを参照してください。

エージェントの設定

エージェントは高度にカスタマイズ可能です。

一つの選択肢は、設定プロパティを-Dフラグを通じて渡すことです。この例では、サービス名とトレース用の Zipkin エクスポーターを設定しています。

java -javaagent:path/to/opentelemetry-javaagent.jar \
 -Dotel.service.name=your-service-name \
 -Dotel.traces.exporter=zipkin \
 -jar myapp.jar

環境変数を使用してエージェントを設定することもできます。

OTEL_SERVICE_NAME=your-service-name \
OTEL_TRACES_EXPORTER=zipkin \
java -javaagent:path/to/opentelemetry-javaagent.jar \
 -jar myapp.jar

Javaプロパティファイルを指定して、そこから設定値を読み込むこともできます。

java -javaagent:path/to/opentelemetry-javaagent.jar \
 -Dotel.javaagent.configuration-file=path/to/properties/file.properties \
 -jar myapp.jar

または、以下のように設定もできます。

OTEL_JAVAAGENT_CONFIGURATION_FILE=path/to/properties/file.properties \
java -javaagent:path/to/opentelemetry-javaagent.jar \
 -jar myapp.jar

すべての設定オプションについては、エージェント設定を参照してください。

トレース

Wed, 03 Jun 2026 17:03:29 +0900

トレース は、リクエストがアプリケーションに投げられたときに何が起こるかの全体像を教えてくれます。あなたのアプリケーションが、単一のデータベースを持つモノリスであろうと、洗練されたメッシュサービスであろうと、トレースは、リクエストがアプリケーションの中でたどる完全な「経路」を理解するために不可欠です。

スパンで表現される以下の3つのJSONデータで、これを探ってみましょう。

注記

以下のJSONの例は、特定のフォーマット、特にOTLP/JSONを表すものではありません。OTLP/JSONは、より冗長です。

hello スパンは次のとおりです。

{
 "name": "hello",
 "context": {
 "trace_id": "5b8aa5a2d2c872e8321cf37308d69df2",
 "span_id": "051581bf3cb55c13"
 },
 "parent_id": null,
 "start_time": "2022-04-29T18:52:58.114201Z",
 "end_time": "2022-04-29T18:52:58.114687Z",
 "attributes": {
 "http.route": "some_route1"
 },
 "events": [
 {
 "name": "Guten Tag!",
 "timestamp": "2022-04-29T18:52:58.114561Z",
 "attributes": {
 "event_attributes": 1
 }
 }
 ]
}

これはルートスパンであり、オペレーション全体の始まりと終わりを示します。トレースを示す trace_id フィールドがありますが、parent_id がないことに注意してください。これがルートスパンであることを示します。

hello-greetings スパンは次のとおりです。

{
 "name": "hello-greetings",
 "context": {
 "trace_id": "5b8aa5a2d2c872e8321cf37308d69df2",
 "span_id": "5fb397be34d26b51"
 },
 "parent_id": "051581bf3cb55c13",
 "start_time": "2022-04-29T18:52:58.114304Z",
 "end_time": "2022-04-29T22:52:58.114561Z",
 "attributes": {
 "http.route": "some_route2"
 },
 "events": [
 {
 "name": "hey there!",
 "timestamp": "2022-04-29T18:52:58.114561Z",
 "attributes": {
 "event_attributes": 1
 }
 },
 {
 "name": "bye now!",
 "timestamp": "2022-04-29T18:52:58.114585Z",
 "attributes": {
 "event_attributes": 1
 }
 }
 ]
}

このスパンは、挨拶（greetings）のような特定のタスクをカプセル化していて、その親は hello スパンです。このスパンはルートスパンと同じ trace_id を共有していて、同じトレースの一部であることを示しています。さらに、 hello スパンの span_id と一致する parent_id を持っています。

前提条件

Tue, 05 Aug 2025 22:35:37 +0900

このリポジトリにコントリビュートするために、以下の技術とツールに精通している必要があります。

git
GitHub
Markdown (CommonMark)
YAML

ローカルでドキュメントがビルドとテストされる方法に関連する技術的な詳細は、開発を参照してください。

CNCF CLA に署名

すべての OpenTelemetry コントリビューターは Linux Foundation Contributor License Agreement (CLA) に署名しなければいけません。

CLA への署名を終えていないコントリビューターからのプルリクエストは自動テストが失敗します。指定する名前とメールアドレスは git config で見つかったものと一致している必要があり、git 名とメールアドレスは CNCF で利用するものと一致している必要があります。

行動規範

すべての OpenTelemetry コントリビューターは CNCF Community Code of Conduct に従う必要があります。

コミュニティガイドライン

役割や期待事項を含む OpenTelemetry コミュニティの一般的なガイドラインは、OpenTelemetry New Contributor Guide を参照してください。

OpenTelemetry

OBI ネットワークメトリクスの設定オプション

ネットワークメトリクスの設定プロパティ

DockerコンテナとしてOBIを実行する

イメージの署名と検証

OBI Config v2 リファレンス

構成構造の選択

スタンドアロン OBI の設定

OBI グローバル設定プロパティ

ヘルスチェックエンドポイント

クラウドアベイラビリティゾーン間のトラフィックを測定する

通常のネットワークメトリクスに src.zone と dst.zone 属性を追加する

obi.network.inter.zone メトリクスを使用する

OBI ネットワークメトリクスのクイックスタート

ネットワークメトリクスを有効化して OBI をデプロイする

シンプルなセットアップ

OBI をデプロイする

OBI のエクスポートモードを構成する

OBI の構成と実行

HelmでKubernetesにOBIをデプロイする

Helm から OBI をデプロイする

OBI の設定

OpenTelemetry PHP Distro のセットアップ

前提条件

制限事項

パッケージのダウンロードとインストール

RPM（RHEL/CentOS/Fedora）

DEB（Debian/Ubuntu）

APK（Alpine）

エクスポーターの設定

PHP プロセスの再起動

パフォーマンスオーバーヘッド

ベンチマークのセットアップ

結果

主な知見

推奨事項

制限事項

他の PHP テレメトリーエージェントとの併用

open_basedir

xdebug

ファイルベース設定（OTEL_CONFIG_FILE）

仕様ステータスの概要

コンポーネントのライフサイクル

現在のステータス

トレーシング

メトリクス

バゲッジ

ロギング

プロファイル

はじめに

概要

準備

デーモンセットコレクター

対応テクノロジー

自動計装の範囲

PHP バージョン

対応する SAPI

対応するオペレーティングシステム

計装済みフレームワーク

計装済みライブラリ

同梱の自動計装パッケージ

同梱のメトリクスパッケージ

追加のランタイム機能

設定

設定方法

OpenTelemetry オプション

Distro 固有のオプション（OTEL_PHP_*） {#distro-specific-options-otelphp}

ログ

OpenTelemetry のログ

OpenTelemetry コレクターの OpenTelemetry のログ

アプリケーションの OpenTelemetry

言語サポート

構造化、非構造化、半構造化ログ

メトリクス

メータープロバイダー

メーター

メトリクスエクスポーター

メトリクス計装

集約（アグリゲーション）

はじめに

通常のネットワークメトリクスに `src.zone` と `dst.zone` 属性を追加する

`obi.network.inter.zone` メトリクスを使用する

`open_basedir`

`xdebug`

ファイルベース設定（`OTEL_CONFIG_FILE`）

Distro 固有のオプション（`OTEL_PHP_*`） {#distro-specific-options-otelphp}