OpenTelemetry

OBI Network Metrics configuration options

Sun, 18 Jan 2026 06:12:55 -0500

Network metrics are configured under the network property of the OBI Configuration YAML file or with a set of environment variables prefixed as OTEL_EBPF_NETWORK_.

Example 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

In addition to the network YAML section, OBI configuration requires an endpoint to export the network metrics (in the previous example, otel_metrics_export, but it also accepts a Prometheus endpoint).

Measure traffic between Cloud availability zones

Wed, 14 Jan 2026 07:44:34 -0500

Note

This feature is currently only available in Kubernetes clusters.

Traffic between Cloud Availability Zones might incur additional costs. OBI is able to measure it either by adding src.zone and dst.zone attributes to regular network metrics, or by providing a separate obi.network.inter.zone.bytes (OTel) / obi_network_inter_zone_bytes_total (Prometheus) metric.

Add `src.zone` and `dst.zone` attributes to regular network metrics

Source and destination availability zone attributes are disabled by default in OBI. To enable it, explicitly add them to the list of included network attributes in the OBI YAML configuration:

ゲートウェイ

Thu, 08 Jan 2026 22:37:28 +0530

コレクターのゲートウェイデプロイメントパターンは、アプリケーション（または他のコレクター）がテレメトリーシグナルを単一のOTLPエンドポイントに送信し、そのエンドポイントが実行されている1つ以上のコレクターインスタンスによって処理される構成です。このコレクターインスタンスは、通常、クラスターごと、データセンターごと、またはリージョンごとに単独のサービス（たとえばKubernetesのデプロイメント）として実行されます。

一般的なケースでは、アウトオブボックスのロードバランサーを使用して、コレクター間で負荷を分散できます。

テレメトリーデータの処理が特定のコレクターで行われる必要があるユースケースでは、2層の設定を使用します。 1層目のコレクターは、Trace ID/サービス名を意識したロードバランシングエクスポーターを使用して設定され、2層目ではスケールアウトを処理するコレクターが使用されます。たとえば、テイルサンプリングプロセッサーを使用する場合、すべてのスパンが同じコレクターインスタンスに到達し、そこでそのサンプリングポリシーが適用されるように、ロードバランシングエクスポーターを使用する必要があります。

ロードバランシングエクスポーターを使用する場合の例を見てみましょう。

アプリケーションで、SDKがOTLPデータを中央の場所に送信するように設定されます。
ロードバランシングエクスポーターを使用して設定されたコレクターが、シグナルを複数のコレクターに分散します。
コレクターはテレメトリーデータを1つ以上のバックエンドに送信するように設定されます。

例

NGINXを「アウトオブボックス」のロードバランサーとして使用

2つのコレクター（collector1とcollector2）が設定され、NGINXを使用してその間でトラフィックをロードバランシングしたい場合、次の設定を使用できます。

server {
 listen 4317 http2;
 server_name _;

 location / {
 grpc_pass grpc://collector4317;
 grpc_next_upstream error timeout invalid_header http_500;
 grpc_connect_timeout 2;
 grpc_set_header Host $host;
 grpc_set_header X-Real-IP $remote_addr;
 grpc_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }
}

server {
 listen 4318;
 server_name _;

 location / {
 proxy_pass http://collector4318;
 proxy_redirect off;
 proxy_next_upstream error timeout invalid_header http_500;
 proxy_connect_timeout 2;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }
}

upstream collector4317 {
 server collector1:4317;
 server collector2:4317;
}

upstream collector4318 {
 server collector1:4318;
 server collector2:4318;
}

ロードバランシングエクスポーター

コレクターの中央集権型デプロイメントパターンの具体的な例として、まずロードバランシングエクスポーターについて詳しく見ていきましょう。これには2つの主な設定項目があります：

resolverは、下流のコレクター（またはバックエンド）をどこで見つけるかを決定します。ここでstaticサブキーを使用すると、コレクターのURLを手動で列挙する必要があります。他のサポートされているリゾルバーはDNSリゾルバーで、定期的に更新を確認し、IPアドレスを解決します。このリゾルバータイプでは、hostnameサブキーがIPアドレスのリストを取得するために問い合わせるホスト名を指定します。
routing_keyフィールドを使用するとロードバランシングエクスポーターがスパンを特定の下流のコレクターにルーティングするように指示します。このフィールドをtraceID（デフォルト）に設定すると、ロードバランシングエクスポーターはtraceIDに基づいてスパンをエクスポートします。その他の場合、routing_keyにserviceを設定すると、サービス名に基づいてスパンをエクスポートします。これは、スパンメトリクスコネクターのようなコネクターを使用する際に有用で、サービスのすべてのスパンが同じ下流のコレクターに送信され、メトリクス収集が行われ、正確な集約が保証されます。

OTLPエンドポイントを提供する最初の層のコレクターは次のように設定されます。

receivers:
 otlp:
 protocols:
 grpc:
 endpoint: 0.0.0.0:4317

exporters:
 loadbalancing:
 protocol:
 otlp:
 tls:
 insecure: true
 resolver:
 static:
 hostnames:
 - collector-1.example.com:4317
 - collector-2.example.com:5317
 - collector-3.example.com

service:
 pipelines:
 traces:
 receivers: [otlp]
 exporters: [loadbalancing]

receivers:
 otlp:
 protocols:
 grpc:
 endpoint: 0.0.0.0:4317

exporters:
 loadbalancing:
 protocol:
 otlp:
 tls:
 insecure: true
 resolver:
 dns:
 hostname: collectors.example.com

service:
 pipelines:
 traces:
 receivers: [otlp]
 exporters: [loadbalancing]

receivers:
 otlp:
 protocols:
 grpc:
 endpoint: 0.0.0.0:4317

exporters:
 loadbalancing:
 routing_key: service
 protocol:
 otlp:
 tls:
 insecure: true
 resolver:
 dns:
 hostname: collectors.example.com
 port: 5317

service:
 pipelines:
 traces:
 receivers: [otlp]
 exporters: [loadbalancing]

ロードバランシングエクスポーターは、otelcol_loadbalancer_num_backendsやotelcol_loadbalancer_backend_latencyなどのメトリクスを出力し、これらを使用してOTLPエンドポイントコレクターのヘルスとパフォーマンスを監視できます。

はじめに

Thu, 08 Jan 2026 22:37:28 +0530

このページでは、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, 08 Jan 2026 12:52:37 -0300

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

OpenTelemetry のログ

OpenTelemetry はログを作成するための独自の API や SDK を定義しません。かわりに、OpenTelemetry のログは、ログフレームワークやインフラコンポーネントから得られるログを指します。 OpenTelemetry SDK と自動計装は、複数のコンポーネントを活用しログをトレースと関連付けます。

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	Beta
Java	Stable
JavaScript	Development
PHP	Stable
Python	Development
Ruby	Development
Rust	Beta
Swift	Development

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

OpenTelemetry は構造化ログと非構造化ログを技術的に区別していません。 OpenTelemetry では既存のどのようなログも利用できます。しかし、すべてのログフォーマットは等しく有用ではありません！特に、構造化ログは大規模な解析や分析がしやすいため、本番環境のオブザーバビリティに推奨されます。後述するセクションは構造化、非構造化、半構造化ログの違いを説明します。

コレクターなし

Thu, 08 Jan 2026 12:52:37 -0300

最もシンプルなパターンは、コレクターをまったく使用しないことです。このパターンは、OpenTelemetry SDKで計装されたアプリケーションが、テレメトリーシグナル（トレース、メトリクス、ログ）をバックエンドに直接エクスポートする構成です。

例

アプリケーションからバックエンドにシグナルを直接エクスポートする方法について、具体的なエンドツーエンドの例はプログラミング言語のコード計装をご覧ください。

トレードオフ

長所：

使用が簡単（特に開発/テスト環境で）
運用に追加の可動部品が必要ない（本番環境で）

短所：

収集、処理、または取り込みの変更がある場合、コード変更が必要
アプリケーションコードとバックエンド間の強い結合
言語実装ごとにエクスポーターの数が制限されている

はじめに

Wed, 24 Dec 2025 00:19:31 +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, 17 Dec 2025 18:49:09 +0900

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

トレース

Wed, 17 Dec 2025 18:38:59 +0900

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

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

Note

以下の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 を持っています。

OBI network metrics quickstart

Tue, 16 Dec 2025 14:16:09 +0100

OBI can generate network metrics in any environment (physical host, virtual host, or container). It’s recommended to use a Kubernetes environment, as OBI is able to decorate each metric with the metadata of the source and destination Kubernetes entities.

The instructions in this quickstart guide focus on deploying directly to Kubernetes with the kubectl command line utility. This tutorial describes how to deploy OBI in Kubernetes from scratch. To use Helm, consult the Deploy OBI in Kubernetes with Helm documentation.

KubernetesにOBIをデプロイする

Fri, 31 Oct 2025 11:11:54 -0400

このドキュメントでは、必要なエンティティをすべて自分で設定して、KubernetesにOBIを手動でデプロイする方法について説明します。

Kubernetesメタデータデコレーションを構成する

OBIは、次のKubernetesラベルでトレースをデコレートできます。

k8s.namespace.name
k8s.deployment.name
k8s.statefulset.name
k8s.replicaset.name
k8s.daemonset.name
k8s.node.name
k8s.pod.name
k8s.container.name
k8s.pod.uid
k8s.pod.start_time
k8s.cluster.name

メタデータデコレーションを有効化するには、次のことが必要です。

ServiceAccountを作成し、PodとReplicaSetの両方に対してlistとwatchの権限を付与するClusterRoleをバインドします。以下の例のファイルをデプロイすることで実行できます。

apiVersion: v1
kind: ServiceAccount
metadata:
 name: obi
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: obi
rules:
 - apiGroups: ['apps']
 resources: ['replicasets']
 verbs: ['list', 'watch']
 - apiGroups: ['']
 resources: ['pods', 'services', 'nodes']
 verbs: ['list', 'watch']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: obi
subjects:
 - kind: ServiceAccount
 name: obi
 namespace: default
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: obi

(OBIを別の名前空間にデプロイしている場合は、namespace: default の値を変更する必要があります)

エージェント

Fri, 31 Oct 2025 11:11:54 -0400

コレクターのエージェントデプロイメントパターンは、OpenTelemetry SDKを使用して計装されたアプリケーション（OpenTelemetryプロトコル（OTLP）を使用）や、他のコレクター（OTLPエクスポーターを使用）が、テレメトリーシグナルをコレクターインスタンスに送信する構成です。このコレクターインスタンスは、アプリケーションと同じホストまたはアプリケーションの横に配置されたサイドカーやデーモンセットとして動作します。

各クライアント側SDKまたはダウンストリームコレクターは、コレクターの場所を設定します。

アプリケーションで、SDKがOTLPデータをコレクターに送信するように設定されます。
コレクターは、テレメトリーデータを1つ以上のバックエンドに送信するように設定されます。

例

コレクターのエージェントデプロイメントパターンの具体例は以下のようになります。たとえば、Javaアプリケーションを計装してメトリクスをエクスポートするためにOpenTelemetry Java SDKを使用します。アプリケーションのコンテキスト内で、OTEL_METRICS_EXPORTERをotlp（デフォルト値）に設定し、OTLPエクスポーターをコレクターのアドレスで設定します。たとえば、Bashまたはzshシェルでは、次のように設定します。

export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.example.com:4318

collector.example.com:4318 で動作するコレクターは次のように設定されます。

receivers:
 otlp: # アプリケーションがトレースを送信するOTLPレシーバー
 protocols:
 http:
 endpoint: 0.0.0.0:4318

processors:
 batch:

exporters:
 otlp/jaeger: # JaegerはOTLPを直接サポートしています
 endpoint: https://jaeger.example.com:4317

service:
 pipelines:
 traces/dev:
 receivers: [otlp]
 processors: [batch]
 exporters: [otlp/jaeger]

receivers:
 otlp: # アプリケーションがメトリクスを送信するOTLPレシーバー
 protocols:
 http:
 endpoint: 0.0.0.0:4318

processors:
 batch:

exporters:
 prometheusremotewrite: # PRWエクスポーター、メトリクスをバックエンドに取り込む
 endpoint: https://prw.example.com/v1/api/remote_write

service:
 pipelines:
 metrics/prod:
 receivers: [otlp]
 processors: [batch]
 exporters: [prometheusremotewrite]

receivers:
 otlp: # アプリケーションがログを送信するOTLPレシーバー
 protocols:
 http:
 endpoint: 0.0.0.0:4318

processors:
 batch:

exporters:
 file: # ファイルエクスポーター、ログをローカルファイルに取り込む
 path: ./app42_example.log
 rotation:

service:
 pipelines:
 logs/dev:
 receivers: [otlp]
 processors: [batch]
 exporters: [file]

実際に試してみたい場合は、エンドツーエンドのJavaやPythonの例で確認できます。

Configure OBI export modes

Mon, 13 Oct 2025 13:27:04 -0400

In Direct mode OBI pushes metrics and traces directly to a remote endpoint using the OpenTelemetry protocol (OTLP).

OBI can also expose a Prometheus HTTP endpoint ready to scrape, for example in pull mode.

To use Direct mode requires configuration with authentication credentials. Set the OTLP endpoint authentication credentials with these environment variables:

OTEL_EXPORTER_OTLP_ENDPOINT
OTEL_EXPORTER_OTLP_HEADERS

To run in Direct mode using the Prometheus scrape endpoint, see the configuration documentation.

Configure and run OBI

This tutorial assumes OBI and OTel Collector are running natively on the same host, so there is no need to secure the traffic nor provide authentication in the OTel Collector OTLP receiver.

メトリクス

Mon, 08 Sep 2025 15:58:45 +0900

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

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

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

メータープロバイダー

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

メーター

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

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

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

メトリクス計装

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

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

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

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

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

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

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

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

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

Mon, 08 Sep 2025 15:54:16 +0900

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

OBIの最新イメージは、Docker Hubで次の名前で見つけられます。

ebpf-instrument:main

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

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

Docker CLIの例

この例では、HTTP/SまたはgRPCサービスを実行しているコンテナが必要です。コンテナがない場合は、Goで書かれたシンプルなブログエンジンサービスを使用できます。

docker run -p 18443:8443 --name goblog mariomac/goblog:dev

上記のコマンドは、シンプルなHTTPSアプリケーションを実行します。このプロセスはコンテナの内部ポート8443を開き、ホストレベルではポート18443として公開されます。

環境変数を設定し、OBIが標準出力に出力し、実行可能ファイルを検査するようにポート(コンテナ)をリッスンするように構成します。

export OTEL_EBPF_TRACE_PRINTER=text
export OTEL_EBPF_OPEN_PORT=8443

OBIは次の設定で実行する必要があります。

--privileged モード、または SYS_ADMIN ケーパビリティ(ただし、一部のコンテナ環境では SYS_ADMIN だけでは特権が不十分な場合があります)
--pid=host オプションを使用したホストのPID名前空間を使用

docker run --rm \
 -e OTEL_EBPF_OPEN_PORT=8443 \
 -e OTEL_EBPF_TRACE_PRINTER=text \
 --pid=host \
 --privileged \
 docker.io/otel/ebpf-instrument:main

OBIの実行後、ブラウザで https://localhost:18443 を開き、アプリを使用してテストデータを生成し、OBIが標準出力に次のようなトレースリクエストを出力することを確認します。

time=2023-05-22T14:03:42.402Z level=INFO msg="creating instrumentation pipeline"
time=2023-05-22T14:03:42.526Z level=INFO msg="Starting main node"
2023-05-22 14:03:53.5222353 (19.066625ms[942.583µs]) 200 GET / [172.17.0.1]->[localhost:18443] size:0B
2023-05-22 14:03:53.5222353 (355.792µs[321.75µs]) 200 GET /static/style.css [172.17.0.1]->[localhost:18443] size:0B
2023-05-22 14:03:53.5222353 (170.958µs[142.916µs]) 200 GET /static/img.png [172.17.0.1]->[localhost:18443] size:0B
2023-05-22 14:13:47.52221347 (7.243667ms[295.292µs]) 200 GET /entry/201710281345_instructions.md [172.17.0.1]->[localhost:18443] size:0B
2023-05-22 14:13:47.52221347 (115µs[75.625µs]) 200 GET /static/style.css [172.17.0.1]->[localhost:18443] size:0B

これで、OBIがターゲットのHTTPサービスをトレースするようになったので、OpenTelemetryエンドポイントにメトリクスとトレースを送信するか、Prometheusでメトリクスをスクレイプするように構成します。

OBIをスタンドアロンプロセスとして実行する

Mon, 08 Sep 2025 15:53:30 +0900

OBIは、他の実行中プロセスを検査できる昇格された権限を持つスタンドアロンのLinux OSプロセスとして実行できます。

ダウンロードとインストール

OBIの実行可能ファイルは、OBIリリースページからダウンロードできます。

OBIのセットアップ

構成オプションドキュメントに従って構成ファイルを作成します。
OBIを特権プロセスとして実行します。

sudo ./obi --config=<構成ファイルのパス>

構成例

構成ファイルの例(obi-config.yml)を示します。

# 基本設定
discovery:
 services:
 - name: my-service
 open_ports: [8080, 8090]
 exe_path: /usr/local/bin/my-service

# トレース構成
traces:
 # トレース有効化
 enabled: true

 # OpenTelemetryエンドポイント
 otlp_endpoint: http://localhost:4318

 # トレースフォーマット
 format: otlp

# メトリクス構成
metrics:
 # メトリクス有効化
 enabled: true

 # OpenTelemetryエンドポイント
 otlp_endpoint: http://localhost:4318

 # メトリクスフォーマット
 format: otlp

# ログ構成
log_level: info

OBIの実行

構成ファイルを使用してOBIを実行します。

OBI global configuration properties

Mon, 11 Aug 2025 21:58:16 +0200

OBI can be configured via environment variables or via a YAML configuration file passed either with the -config command-line argument or the OTEL_EBPF_CONFIG_PATH environment variable. Environment variables have priority over the properties in the configuration file. For example, in the following command line, the OTEL_EBPF_LOG_LEVEL option overrides any log_level settings inside config.yaml:

Config argument:

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

Config environment variable:

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

Refer to the example YAML configuration file for a configuration file template.

前提条件

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 を参照してください。

Migrating from OpenCensus

Tue, 27 May 2025 05:58:16 -0400

Migrating from OpenTracing

Fri, 21 Mar 2025 16:06:24 -0400

Backward compatibility with OpenTracing has been a priority for the OpenTelemetry project from the start. To ease migration, OpenTelemetry supports the use of both the OpenTelemetry and OpenTracing APIs in the same codebase. This allows OpenTracing instrumentation to be recorded using OpenTelemetry SDKs.

To accomplish this, each OpenTelemetry SDK provides an OpenTracing shim, which acts as a bridge between the OpenTracing API and the OpenTelemetry SDK. Note that OpenTracing shims are disabled by default.

OpenTelemetry

OBI Network Metrics configuration options

Measure traffic between Cloud availability zones

Add src.zone and dst.zone attributes to regular network metrics

ゲートウェイ

例

NGINXを「アウトオブボックス」のロードバランサーとして使用

ロードバランシングエクスポーター

はじめに

概要

準備

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

ログ

OpenTelemetry のログ

OpenTelemetry コレクターの OpenTelemetry のログ

アプリケーションの OpenTelemetry

言語サポート

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

コレクターなし

例

トレードオフ

はじめに

セットアップ

宣言的設定

エージェントの設定

仕様ステータスの概要

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

現在のステータス

トレーシング

メトリクス

バゲージ

ロギング

プロファイル

トレース

OBI network metrics quickstart

KubernetesにOBIをデプロイする

Kubernetesメタデータデコレーションを構成する

エージェント

例

Configure OBI export modes

Configure and run OBI

メトリクス

メータープロバイダー

メーター

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

メトリクス計装

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

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

Docker CLIの例

OBIをスタンドアロンプロセスとして実行する

ダウンロードとインストール

OBIのセットアップ

構成例

OBIの実行

OBI global configuration properties

前提条件

CNCF CLA に署名

行動規範

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

Migrating from OpenCensus

Migrating from OpenTracing

Add `src.zone` and `dst.zone` attributes to regular network metrics