著者: 伊藤雅博, 株式会社日立製作所

はじめに

本稿では、オブザーバビリティの標準化を実現するOpenTelemetryの概要を紹介します。

記事一覧：

オブザーバビリティの標準化を実現するOpenTelemetryの概要（本稿）
OpenTelemetry SDK/Collector/Operatorのアーキテクチャ

オブザーバビリティとは

オブザーバビリティの概要

クラウドサービスやコンテナ技術の普及、システムのマイクロサービス化により、システム構成は分散化・複雑化する傾向にあります。オブザーバビリティ（Observability、可観測性）とは、このような複雑化したシステムの内部状態を外部から把握・理解する能力を指します。

従来のシステム監視では、主にログ（テキストデータ）とメトリクス（数値データ）を収集・解析していました。しかし、分散システムでは1回のトランザクションが多数のサーバ・コンテナ・サービスにまたがるため、これらのデータだけではシステムの内部状態を把握することが困難です。そのため、トランザクションのトレース（処理経路）を追う分散トレーシングが普及しました。

オブザーバビリティでは、これらのデータを収集して相関関係を分析することで、分散システムの内部状態を把握します。これにより、ボトルネックの発見や障害発生時の原因特定を容易にします。

オブザーバビリティにおいて、システムを観測するために収集されるデータの種類を「シグナル」と呼びます。代表的なシグナルはログ、メトリクス、トレースの3種類ですが、他にもバゲッジ（トランザクション内で伝播されるメタデータ）、イベント（システム内の状態変化）、プロファイル（リソース利用状況）などがあります。そして、これらを総称して「テレメトリー」と呼びます。

オブザーバビリティの課題

従来の監視ツールでは、ログ、メトリクス、トレースはそれぞれ独立したツールで収集・解析されており、これらを結合して相関関係を把握するシステムの構築・運用は容易ではありませんでした。

そのため、これらを統合管理するオブザーバビリティ・サービスが登場しましたが、監視対象に組み込むコードや監視用エージェントは独自仕様であることが多く、ベンダーロックインのリスクがありました。

OpenTelemetryとは

OpenTelemetryの概要

OpenTelemetryは、テレメトリーの生成と伝送に関するオープンな標準仕様を提供するプロジェクトです。最近では、さまざまな監視ツールやオブザーバビリティ・サービスがOpenTelemetryをサポートしています。

OpenTelemetryを採用することで、ベンター独自仕様に影響されることなく、オブザーバビリティの共通課題に対して標準化された方式で対応することができます。これにより以下のようなメリットがあります。

テレメトリーの解析ツールやサービスの乗り換えが容易になり、ベンダーロックインを回避しやすくなる
厳格なバージョニングによって互換性が保たれるよう設計されているため、監視対象に一度組み込んだコードがバージョンアップなどで使えなくなるリスクを低減できる

OpenTelemetryでは以下を定義しています。

標準データフォーマット
- テレメトリーのデータ形式を定義
- テレメトリー間をリンクして相関関係を扱えるフォーマット
- 最近はログ、メトリクス、トレース以外のシグナル（バゲッジ、イベント、プロファイル）のサポートや仕様策定も進んでいる（参考：シグナル）
標準伝送プロトコル
- テレメトリーを伝送するプロトコル（OpenTelemetry Protocol: OTLP）を定義
- HTTPまたはgRPCを使用してテレメトリーを送信

OpenTelemetryはこの仕様をもとに、テレメトリーを作成・伝送する以下のコンポーネントを提供します。

OpenTelemetry SDK
- テレメトリーを生成・伝送するAPI（OpenTelemetry API）を実装したライブラリ
- このSDKを使用して、ユーザアプリケーション（サービス）にテレメトリーを生成するコード（Instrumentation、計装）を埋め込む
- 2025年9月現在、11種類の言語用SDKを提供（参考: 言語API & SDK）
- 一部の言語では、コードの埋め込み無しでも最低限のテレメトリーを生成可能なゼロコード計装が利用可能
OpenTelemetry Collector
- SDKが生成したテレメトリーを加工・集約し、オブザーバビリティ・バックエンドに転送する常駐プロセス
- OSやクラウド基盤など、SDK（ユーザアプリケーション）以外からのテレメトリー収集も可能

OpenTelemetryはテレメトリーの収集部分を標準化・共通化するものであり、収集したテレメトリーの蓄積や可視化については仕様の範囲外です。オブザーバビリティを実現するには、OpenTelemetryのデータフォーマットに対応したテレメトリーを蓄積・検索できるオブザーバビリティ・バックエンドと、テレメトリーを可視化・分析するオブザーバビリティ・フロントエンドが別途必要となります。

OpenTelemetryの構成例

OpenTelemetryの各コンポーネントはさまざまな配置が可能ですが、一般的には以下のように配置することが多いです。Kubernetes環境の場合は、アプリケーションサーバがWorkerノード、ユーザアプリとCollectorがコンテナであると想定してください。

OpenTelemetry SDKはユーザアプリケーションに組み込み、SDKのAPIを使用した計装用のコードをビジネスロジックに直接追加します（コードベース計装）。最近は計装済みのフレームワークやライブラリ（Webサーバ、HTTPクライアントなど）も増えており、これらもAPI経由でSDKを利用します（ネイティブ計装）。そのため、SDKの組み込みは必須となります。

また、一部の言語ではOpenTelemetryが提供するエージェントや拡張機能を利用して、外部から計装を注入できます（ゼロコード計装）。例えばJavaの場合、Javaエージェントの機能でJVMのテレメトリー収集とOpenTelemetry SDKの組み込みが可能です。エージェント/拡張機能の利用は任意です。

OpenTelemetry Collectorは、ユーザアプリケーションからの迅速なテレメトリー収集やOSのテレメトリー収集のため、サーバ単位でローカルに配置することを推奨します（ローカルCollector）。Collectorの利用は任意であり、SDKからOTLPで直接オブザーバビリティ・バックエンドにテレメトリーを送信することも可能ですが、推奨はされていません。

大量のテレメトリーを処理する場合は、Collectorを増やして多段のテレメトリーパイプラインを構築することも可能です。以下のように、テレメトリーの加工・集約などの重い処理をローカルCollectorから移譲したり、Collectorを水平スケールして負荷分散および冗長化したり、複数のオブザーバビリティ・バックエンドにテレメトリーを振り分けたりすることができます。

OpenTelemetryのオブザーバビリティ・バックエンド

2025年9月現在、OpenTelemetryに対応するオブザーバビリティ・バックエンド/フロントエンドは多数ありますが、ここでは主要なものを以下に示します。

名称	プラットフォーム	概要・特徴
Elastic Stack	OSS/クラウドサービス	Elasticsearch (トレース・メトリクス・ログ蓄積)、Kibana (可視化)
Grafana Stack	OSS/クラウドサービス	Tempo (トレース蓄積), Mimir/Prometheus (メトリクス蓄積), Loki (ログ蓄積), Grafana (可視化)
Zipkin	OSS	トレース専用、軽量でシンプルな構成（小～中規模向け）
Jaeger	OSS	トレース専用、高機能で大規模環境にも対応
AWS Monitoring and Observability	クラウドサービス	X-Ray (トレース), Managed Prometheus (メトリクス), Grafana (可視化), CloudWatch (メトリクス・ログ)
Google Cloud Observability	クラウドサービス	Cloud Trace (トレース), Cloud Monitoring (メトリクス), Cloud Logging (ログ)
Azure Monitor	クラウドサービス	Application Insights (トレース・メトリクス・ログ)
Dynatrace	クラウドサービス	トレース・メトリクス・ログのフルスタック対応
Datadog	クラウドサービス	トレース・メトリクス・ログのフルスタック対応
New Relic	クラウドサービス	トレース・メトリクス・ログのフルスタック対応
Splunk	クラウドサービス	トレース・メトリクス・ログのフルスタック対応

おわりに

本稿ではOpenTelemetryの全体像を紹介しました。OpenTelemetryを採用することで、オブザーバビリティにおけるテレメトリーの収集部分を標準化・共通化できます。

オブザーバビリティ・バックエンドに依存しないテレメトリー収集基盤を構築できるため、将来オブザーバビリティ・バックエンドの移行が発生しても、監視対象に組み込んだコードの書き換えが発生するリスクを抑制できます。また、開発者はOpenTelemetryの使い方を覚えるだけで、さまざまなオブザーバビリティ・バックエンドの開発に対応できるようになります。

次回はOpenTelemetryの主要コンポーネントであるSDK、Collector、Operatorのアーキテクチャを紹介します。また、複数サービスをまたがるトランザクションにおけるコンテキスト伝搬（Context Propagation）について説明します。

第2回: OpenTelemetry SDK/Collector/Operatorのアーキテクチャ