OpenTelemetry: 最新のテレメトリーの標準
オープンテレメトリー (OTel) そして、オープンソースでベンダー中立的なフレームワークを生成します。 テレメトリデータの収集とエクスポート。以前の 2 つのプロジェクトを統合して誕生しました (OpenTracing と OpenCensus)、OTel は現在、世界で 2 番目に活発なプロジェクトです。 クラウド ネイティブ コンピューティング財団 (CNCF) Kubernetes 以降、1,000 人以上の貢献者が参加 すべての主要な可観測性ベンダーからのサポート。
OTel は可観測性バックエンドではありません。データを保存せず、ダッシュボードも提供しません。そして 1 つ 計装規格 メトリクス、ログ、トレースを収集する方法を定義します。 アプリケーション コードから取得し、互換性のあるバックエンド (Jaeger、Prometheus、Datadog、 New Relic、Grafana Cloud、その他多数)。
このベンダー中立のアプローチにより、コードを一度だけインストルメントできるという重大な問題が解決されます。 OTel API を使用すると、アプリケーション コードの行に触れることなく可観測性バックエンドを変更できます。
この記事で学べること
- OpenTelemetry アーキテクチャ: API、SDK、コレクター、OTLP
- API と SDK の基本的な違い
- 3 つの OTel シグナル: トレース、メトリック、ログ
- 意味上の規則とそれが重要な理由
- OTLP (OpenTelemetry Protocol) プロトコル
- 成熟度マトリックスと各コンポーネントのステータス
OpenTelemetry アーキテクチャ
OTel アーキテクチャは、連携して機能する 4 つの主要コンポーネントで構成されています。 コード計測からエクスポートまでの完全なテレメトリ パイプライン ストレージと視覚化のバックエンド。
1. API: インストルメンテーションコントラクト
L'API もう 1 つは、アプリケーション コードがテレメトリを生成するために使用する抽象化レイヤーです。 具体的な実装を行わずにインターフェイスと型を定義します。 SDKを使わずにAPIだけをインストールした場合、 すべての呼び出しは次のようになります ノーオペ (空の操作)、オーバーヘッドゼロを保証 テレメトリが必要ない環境では。
この分離は、 図書館: を備えたライブラリ OTel API は、それを使用するアプリケーションに特定の SDK の採用を強制しません。アプリケーション SDK を登録してテレメトリを収集するかどうか、および収集する方法を決定します。
2. SDK: 具体的な実装
L'SDK 収集、処理の具体的なロジックを備えた API インターフェイスを実装します。 そして輸出する。 SDK は以下を管理します。
- サンプリング: どのトラックを収集し、どのトラックを破棄するかを決定します
- バッチ処理: 効率的に送信するためにテレメトリ データをグループ化します。
- リソースの検出：環境（ホスト、コンテナ、クラウド）を自動的に識別します
- 輸出: 構成されたエクスポーターを介してバックエンドにデータを送信します。
# Setup completo dell'SDK OpenTelemetry in Python
from opentelemetry import trace, metrics
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.sdk.resources import Resource
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
# 1. Definire la Resource (identità del servizio)
resource = Resource.create({
"service.name": "order-service",
"service.version": "1.2.0",
"deployment.environment": "production",
"service.instance.id": "order-service-pod-abc123"
})
# 2. Configurare il TracerProvider con exporter OTLP
tracer_provider = TracerProvider(resource=resource)
otlp_trace_exporter = OTLPSpanExporter(
endpoint="http://otel-collector:4317",
insecure=True
)
tracer_provider.add_span_processor(
BatchSpanProcessor(otlp_trace_exporter)
)
trace.set_tracer_provider(tracer_provider)
# 3. Configurare il MeterProvider con exporter OTLP
otlp_metric_exporter = OTLPMetricExporter(
endpoint="http://otel-collector:4317",
insecure=True
)
metric_reader = PeriodicExportingMetricReader(
otlp_metric_exporter,
export_interval_millis=60000
)
meter_provider = MeterProvider(
resource=resource,
metric_readers=[metric_reader]
)
metrics.set_meter_provider(meter_provider)
3. コレクター: テレメトリ ルーター
L'オーテルコレクター データを受信、処理、エクスポートするスタンドアロン コンポーネント テレメトリー。アプリケーションとバックエンドの間のインテリジェントなプロキシとして機能し、以下を提供します。 バッチ処理、再試行、フィルタリング、およびデータ変換機能。
コレクターはオプションです。アプリケーションはバックエンドに直接エクスポートできます。ただし、 実稼働環境では、アプリケーションを バックエンドの構成とテレメトリ管理を一元化します。
4. OTLP: トランスポートプロトコル
L'OTLP (OpenTelemetry プロトコル) テレメトリ転送用のネイティブ プロトコル オーテルで。 gRPC (デフォルト、高パフォーマンス)、HTTP/protobuf の 3 つのトランスポート モードをサポートします。 (ファイアウォールの互換性) と HTTP/JSON (デバッグとテスト)。 3 つすべてが同じデータを保持します 異なるエンコーディングで。
OTel アーキテクチャ: データ フロー
応用 (API + SDK) → 輸出業者 (OTLP) → コレクタ (受信者 → プロセッサー → エクスポーター) → バックエンド (イェーガー、プロメテウス、グラファナクラウドなど)
OpenTelemetry の 3 つのシグナル
OTel は、それぞれ成熟度の異なる 3 種類のテレメトリ信号をサポートしています。
トレース (安定)
OTel の最も成熟した信号。分散トレースはリクエストのパスを表します 属性、イベント、リンクを含むスパンで構成されるサービス全体。トレース API は安定しています すべての主要言語で。
メトリクス (安定)
OTel Metrics は、カウンター、ヒストグラム、ゲージの 3 種類のツールをサポートしています。メトリクス API 安定しており、構成可能な集計、一時性 (累積およびデルタ)、およびカーディナリティをサポートしています。 ビュー経由で制御されます。
ログ (安定版)
トレースやメトリックとは異なり、OTel はロギング用の新しい API を導入しません。代わりに、それは提供します ある ログブリッジAPI 既存のロギング フレームワーク (Log4j、SLF4J、 Python ロギング、Winston) を OTel パイプラインに追加し、トレース コンテキストでログを自動的に強化します。
OTel 信号の成熟度マトリックス
| 信号 | API | SDK | OTLP | 自己計測 |
|---|---|---|---|---|
| 痕跡 | 安定した | 安定した | 安定した | 安定した (Java、Python、.NET) |
| メトリクス | 安定した | 安定した | 安定した | 安定した (Java、.NET) |
| ログ | 安定した | 安定した | 安定した | 安定版 (Java) |
意味上の規則: 共有語彙
Le 意味上の規則 属性の標準化された名前のセットです。 異なるライブラリ、フレームワーク、バックエンド間の相互運用性を保証するメトリクスとスパン。 意味上の規則がなければ、各チームは同じ概念に対して異なる名前を使用することになり、 サービス間の相関と分析は不可能です。
# Esempi di Semantic Conventions per HTTP
# Tutte le librerie HTTP usano gli stessi nomi di attributi
# Attributi per span HTTP server
span.set_attribute("http.request.method", "POST")
span.set_attribute("url.path", "/api/v1/orders")
span.set_attribute("http.response.status_code", 201)
span.set_attribute("server.address", "api.example.com")
span.set_attribute("server.port", 443)
span.set_attribute("network.protocol.version", "1.1")
span.set_attribute("http.route", "/api/v1/orders")
# Attributi per span Database
span.set_attribute("db.system", "postgresql")
span.set_attribute("db.namespace", "orders_db")
span.set_attribute("db.operation.name", "SELECT")
span.set_attribute("db.query.text", "SELECT * FROM orders WHERE id = ?")
span.set_attribute("server.address", "db.internal")
span.set_attribute("server.port", 5432)
# Attributi per span Messaging
span.set_attribute("messaging.system", "kafka")
span.set_attribute("messaging.destination.name", "order-events")
span.set_attribute("messaging.operation.type", "publish")
span.set_attribute("messaging.message.id", "msg-12345")
セマンティック規約は、HTTP、データベース、メッセージング、RPC、クラウド プロバイダー、 コンテナ ランタイムやその他多数。これらに従うことで、バックエンドが確実に解釈できるようになります。 テレメトリを正しく実行し、事前構成されたダッシュボードと分析を提供します。
言語用 SDK: 多言語エコシステム
OTel は、主要なプログラミング言語用の公式 SDK を提供しています。各SDKが実装するのは、 同じ API を言語固有のイディオムを使用してネイティブ エクスペリエンスを保証します。
// Setup OTel SDK in Java con Spring Boot
// build.gradle.kts
// implementation("io.opentelemetry:opentelemetry-api:1.36.0")
// implementation("io.opentelemetry:opentelemetry-sdk:1.36.0")
// implementation("io.opentelemetry:opentelemetry-exporter-otlp:1.36.0")
import io.opentelemetry.api.OpenTelemetry;
import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.api.trace.Span;
import io.opentelemetry.api.metrics.Meter;
import io.opentelemetry.api.metrics.LongCounter;
import io.opentelemetry.context.Scope;
public class OrderService {
private final Tracer tracer;
private final LongCounter orderCounter;
public OrderService(OpenTelemetry openTelemetry) {
this.tracer = openTelemetry.getTracer("order-service", "1.0.0");
Meter meter = openTelemetry.getMeter("order-service", "1.0.0");
this.orderCounter = meter.counterBuilder("orders.created")
.setDescription("Number of orders created")
.setUnit("1")
.build();
}
public Order createOrder(OrderRequest request) {
Span span = tracer.spanBuilder("create-order")
.setAttribute("order.type", request.getType())
.setAttribute("order.items_count", request.getItems().size())
.startSpan();
try (Scope scope = span.makeCurrent()) {
Order order = processOrder(request);
orderCounter.add(1);
span.setAttribute("order.id", order.getId());
return order;
} catch (Exception e) {
span.recordException(e);
span.setStatus(StatusCode.ERROR, e.getMessage());
throw e;
} finally {
span.end();
}
}
}
正式にサポートされている SDK
- ジャワ: 自動インストルメンテーション エージェントを備えた成熟した SDK (最も完全なもの)
- パイソン: 安定した SDK、Django、Flask、FastAPI の自動インスツルメンテーション
- Go: 安定した SDK、ネイティブ コンテキストの伝播を備えた慣用的な設計
- 。ネット: 安定した SDK、ASP.NET Core との緊密な統合
- JavaScript/Node.js: 安定した SDK、Express、Fastify の自動インスツルメンテーション
- さび: SDK は成熟しており、活発なコミュニティ
- C++: 安定した SDK、高パフォーマンスのシナリオで使用されます
- 迅速: iOS および macOS アプリケーション用の新しい SDK
リソース: サービス ID
La リソース テレメトリを生成するエンティティを識別する一連の属性。 すべての信号 (トレース、メトリック、ログ) によって共有され、必要な環境コンテキストを提供します。 データを関連付けます。リソースは SDK の起動時に一度設定され、一定のままになります。 プロセスの全期間中。
# Resource attributes tipici in un ambiente Kubernetes
resource:
attributes:
# Identita del servizio
service.name: "order-service"
service.version: "2.1.0"
service.namespace: "ecommerce"
service.instance.id: "order-service-7d8f9b-xk2mp"
# Ambiente di deployment
deployment.environment: "production"
deployment.region: "eu-west-1"
# Kubernetes metadata
k8s.namespace.name: "ecommerce-prod"
k8s.pod.name: "order-service-7d8f9b-xk2mp"
k8s.deployment.name: "order-service"
k8s.node.name: "worker-node-03"
# Cloud provider
cloud.provider: "aws"
cloud.region: "eu-west-1"
cloud.availability_zone: "eu-west-1a"
導入ロードマップ: ゼロから本番環境まで
OpenTelemetry を段階的な組織とプロセスに導入します。計器を付ける必要はありません 初日からのすべてのコード。現実的なロードマップには 3 つのフェーズが含まれます。
OTel 導入ロードマップ
フェーズ 1 (第 1 ～ 2 週目): コレクタの展開、コア サービスの自動インストルメンテーション、
バックエンド構成 (Jaeger + Prometheus)。結果: トレースとメトリクスの基本的な可視性。
フェーズ 2 (3 ～ 6 週目): クリティカル スパン、設定にカスタム属性を追加する
サンプリング、ログトレース相関統合。結果: コア ストリームの効果的なデバッグ。
フェーズ 3 (月 2 ～ 3): ビジネス指標の手動計測、Grafana ダッシュボード
カスタマイズされた SLO ベースのアラート。結果: 実稼働グレードの可観測性。
結論と次のステップ
OpenTelemetry は、モジュール式でベンダー中立的なアーキテクチャを提供し、明確に分離します。 インストルメンテーション (API)、コレクション (SDK)、ルーティング (コレクター)、およびエクスポート (OTLP)。 セマンティック規約により相互運用性が保証され、同時に複数言語がサポートされます。 OTel をあらゆるテクノロジー スタックに採用できます。
API/SDK の分離とアーキテクチャの鍵: ライブラリは API を使用します (SDK なしでオーバーヘッドはゼロ)。 アプリケーションは適切なエクスポーターを使用して SDK を構成します。このデザインにより、次のことが可能になります。 強制的な依存関係を作成せずにエコシステム全体を計測します。
次回の記事ではさらに詳しく掘り下げていきます 分散トレーシング、詳細に分析 スパン、トレース コンテキスト、W3C トレース コンテキスト プロトコル、および親子関係 分散トレースのグラフを形成します。