OpenTelemetry（オープンテレメトリー、略称OTel）とは、アプリケーションやインフラからトレース、メトリクス、ログなどのテレメトリーデータを生成・収集し、分析先へ転送するためのオープンソースの仕組みです。障害を自動で直す製品や監視画面そのものではなく、異なるサービスや監視製品の間で観測データを扱いやすくする共通基盤として利用します。
1. OpenTelemetryとは何か
テレメトリーデータを扱う共通の枠組み
OpenTelemetryは、システムの内部で何が起きているかを調べるためのデータを、共通の方法で扱うための枠組みです。主にトレース、メトリクス、ログを対象とし、計装、生成、収集、転送に必要なAPI、SDK、ツール、仕様を提供します。
ここでいうテレメトリーとは、離れた場所にあるシステムの状態を観測するために送られるデータの総称です。たとえばAPIの処理時間、エラー件数、リクエストが通過したサービス、アプリケーションが出力したログなどが該当します。
OpenTelemetryを使うと、言語やフレームワークごとにばらばらだった観測方法をそろえやすくなります。ただし、すべてのデータが自動的に有用になるわけではありません。何を計測するか、どの属性を付けるか、どこへ送るかはシステムに合わせて設計する必要があります。
ベンダー中立であることの意味
OpenTelemetryは、特定のクラウドや監視サービスだけに依存しないベンダー中立なプロジェクトです。同じ形式で収集したデータを、オープンソースのバックエンドや商用の監視サービスへ送れることが大きな特徴です。
監視製品ごとに専用の計装コードを埋め込むと、製品を変更するときにアプリケーション側の修正が増えます。OpenTelemetryのAPIや標準的な転送方式を境界に置けば、送信先の変更をアプリケーションから切り離しやすくなります。
もっとも、バックエンドを切り替えるだけで完全に同じ画面やアラートが再現されるわけではありません。クエリ言語、保持期間、料金、可視化機能は製品ごとに異なります。ベンダー中立とは、製品差がなくなることではなく、データを生成・転送する部分の結合を弱められるという意味です。
OpenTelemetryは監視製品ではない
OpenTelemetry自体は、テレメトリーデータを長期間保存したり、ダッシュボードで表示したりする監視バックエンドではありません。データを観測可能な形で作り、Collectorやバックエンドへ渡すところが中心です。
役割を混同すると、「OpenTelemetryを入れたのに画面がない」「データを検索できない」という誤解が生じます。実際の構成では、アプリケーションの計装に加えて、必要に応じてOpenTelemetry Collectorと、保存・検索・可視化を担うバックエンドを組み合わせます。
最小構成では、アプリケーションからバックエンドへ直接送ることも可能です。一方、本番環境ではCollectorを間に置き、転送先の切り替え、データ加工、機密情報の除去などを集約する構成がよく検討されます。
2. 可観測性と監視の違い
監視は既知の異常を見つける
監視は、あらかじめ決めた条件を継続的に確認し、異常を検知する活動です。CPU使用率が80％を超えた、エラー件数が一定数を超えた、ヘルスチェックに失敗した、といった条件で通知するのが代表例です。
既知の故障パターンを素早く検知するうえで、監視は欠かせません。正常・異常の基準を決められる項目には特に有効です。一方、原因が想定外だった場合、アラートだけでは「なぜ起きたのか」まで説明できないことがあります。
そのため、アラート項目を増やすだけでは調査が難しいケースもあります。監視は可観測性に置き換わるものではなく、異常を知らせる入口として引き続き重要です。
可観測性は出力から内部状態を推測する
可観測性（Observability）は、システムが外部へ出す情報を基に、内部で何が起きているかを理解できる性質を指します。発生条件を事前に知らない問題でも、複数の観測データを組み合わせて原因へ近づけることが目的です。
たとえば「決済APIが一部の利用者だけ遅い」という問題では、サーバー全体のCPU使用率は正常かもしれません。リクエスト単位のトレース、接続先ごとの処理時間、エラーログを関連付けられれば、特定の外部APIやDBクエリで待ち時間が発生していることを調べられます。
ただし、データを大量に集めれば自動的に可観測性が高まるわけではありません。サービス名、環境名、HTTPルートなど、調査に必要な属性を一貫した形で付けることが重要です。
OpenTelemetryは可観測性を作る手段の一つ
OpenTelemetryは、可観測性を高めるための計装とデータ流通を支援します。異なる言語やサービスから出るデータを共通の考え方で扱い、同じリクエストに関係する情報を結び付けやすくします。
一方で、OpenTelemetryを導入するだけで運用体制や調査手順まで完成するわけではありません。どの異常をアラートにするか、誰が確認するか、どの期間データを保持するかといった運用設計は別途必要です。
導入目的は「流行しているから」ではなく、現在の調査で何が不足しているかから決めます。複数サービス間の経路が追えない、ログの形式が統一されていない、監視製品への依存が強い、といった課題が判断材料になります。
3. OpenTelemetryが扱う主なシグナル
Tracesはリクエストの経路を表す
Traceは、一つのリクエストや処理がシステム内をどのように通過したかを表します。フロントエンド、API、認証サービス、DBなど、複数の処理を一つの流れとして確認できる点が特徴です。
Traceは、処理単位を表すSpanの集合として構成されます。各Spanには処理名、開始・終了時刻、属性、状態などを持たせられます。親子関係を使うことで、どの処理から次の処理が呼ばれたかを表現します。
分散システムでは、サービス間でトレースの識別情報を引き継ぐ必要があります。この仕組みはContext Propagationと呼ばれます。
Metricsは時間とともに変化する数値を表す
Metricsは、一定期間のシステム状態を数値で把握するためのデータです。リクエスト数、エラー率、レスポンスタイム、メモリ使用量などを継続的に記録します。
個々のリクエストを詳しく追うTraceに対し、Metricsはシステム全体の傾向をつかむことに向いています。たとえば「直近5分でエラー率が上昇した」「特定APIの95パーセンタイル応答時間が悪化した」といった変化を検知できます。
属性を細かく付けすぎると、時系列の組み合わせが増えて保存量や料金が膨らみます。ユーザーIDや取引IDのように値の種類が非常に多い情報を、安易にメトリクス属性へ入れない判断が必要です。
Logsは個別の出来事を記録する
Logsは、特定の時点で起きた出来事を記録します。例外メッセージ、処理結果、外部APIから返されたステータスなど、調査に必要な詳細情報を残す用途に向きます。
ログだけでも多くの問題を調査できますが、複数サービスにまたがると、同じリクエストに関係するログを集めることが難しくなります。Trace IDやSpan IDをログへ含めると、トレース画面から関連ログを探しやすくなります。
機密情報の扱いには注意が必要です。認証情報、個人情報、カード情報などを属性やログへ出力しないよう、計装時とCollectorでの加工時の両方で確認します。
4. データが届くまでの基本構成
Instrumentationで観測データを作る
Instrumentation（計装）は、アプリケーションからテレメトリーデータを生成できるようにする作業です。SDKを使ってコードへ明示的に追加する手動計装と、エージェントやライブラリで一般的な処理を取得する自動計装があります。
自動計装は導入が速く、HTTP通信やDBアクセスなどを広く取得できます。一方、業務上重要な処理名や取引種別まで自動で理解することはできません。必要に応じて手動計装を追加し、調査に意味のある境界を表現します。
最初からすべてを計装する必要はありません。障害時に経路が見えず困っているAPIなど、効果を確認しやすい範囲から始める方が現実的です。
SDKとExporterがデータを送り出す
SDKは、APIを通じて作られたテレメトリーデータを処理し、サンプリングやバッチ化などを行います。Exporterは、処理済みのデータをCollectorやバックエンドへ送信します。
OpenTelemetryでは、データ転送にOTLPを利用できます。OTLPはOpenTelemetry Protocolの略で、トレース、メトリクス、ログを転送するためのプロトコルです。
送信処理がアプリケーション本体を圧迫しないよう、キューやバッチ設定、タイムアウトを確認します。また、バックエンド障害時にテレメトリー送信が業務処理を止めない設計が重要です。
Collectorとバックエンドは役割が異なる
OpenTelemetry Collectorは、テレメトリーデータを受信し、加工して、別の送信先へ転送するコンポーネントです。Receiver、Processor、Exporterなどを組み合わせてパイプラインを構成します。
Collectorを使えば、アプリケーションから送信先の認証情報を分離したり、不要な属性を削除したり、複数のバックエンドへデータを振り分けたりできます。ただし、小規模な検証ではCollectorを使わず直接送信する構成も可能です。
バックエンドは、転送されたデータの保存、検索、可視化、アラートを担当します。ここでは「中継・加工」と「保存・分析」が別の役割であることを押さえます。
5. OpenTelemetryが役立つシステム
複数サービスをまたぐ処理
OpenTelemetryは、マイクロサービスや外部API連携のように、一つの処理が複数の境界を越えるシステムで特に役立ちます。個別のサーバーログだけでは、どの呼び出しで時間がかかったかを追いにくいためです。
たとえば振込受付APIが、認証、残高確認、取引登録、通知の順に複数サービスを呼ぶ場合、トレースによって各処理の所要時間と成否を一つの流れとして確認できます。
ただし、すべての外部サービスがトレース情報を引き継ぐとは限りません。その場合でも、自システム側の外部呼び出しSpanまで記録すれば、待ち時間やエラーの発生箇所を把握しやすくなります。
複数の言語や実行環境が混在するシステム
Java、JavaScript、Pythonなど複数言語で構成されたシステムでは、各言語の監視ライブラリが異なり、データ形式がそろわないことがあります。OpenTelemetryは言語別のAPIやSDKを提供しながら、共通の概念と転送方式を利用できます。
共通化によって、サービス名やHTTP属性の付け方を統一しやすくなります。運用担当者が言語ごとの独自形式を覚える負担も減らせます。
一方、言語SDKごとに機能の成熟度や設定方法は異なります。導入前に対象シグナルの対応状況を公式ドキュメントで確認する必要があります。
小規模システムでは課題から判断する
単一アプリケーションでログだけで十分に原因を追える場合、最初から大規模なCollector構成を導入すると運用負担が増える可能性があります。OpenTelemetryは規模だけで機械的に導入を決めるものではありません。
判断基準は、障害調査に時間がかかっているか、サービス間の関連を追えないか、監視製品の変更に弱いか、計装を共通化したいかです。課題が明確なら、小規模でもトレース導入の価値があります。
検証では、重要なAPIを一つ選び、トレースが調査時間を短縮するかを確認します。得られる効果と、データ保存量、設定管理、運用教育のコストを比較して範囲を広げます。
6. 導入前に決めておくこと
何を調査できるようにしたいか
最初に決めるべきなのは、収集ツールではなく調査したい問題です。「決済APIの遅延箇所を特定したい」「サービス間のエラー伝播を追いたい」のように、観測の目的を具体化します。
目的が曖昧なままデータを増やすと、費用が増えても必要な情報が見つからない状態になりがちです。対象となるユーザーフローと、調査時に必要なサービス・属性を整理します。
最初の成功条件として、原因特定までの時間、追跡できるサービス数、手作業でのログ突合回数などを決めておくと効果を評価しやすくなります。
収集範囲とコストを管理する
テレメトリーデータは、リクエスト数や属性数に応じて増えます。特に全リクエストの詳細なTraceや、大量のログを長期間保存すると、ネットワーク、ストレージ、監視サービスの料金へ影響します。
取得対象、サンプリング率、保持期間、除外するエンドポイントを設計し、重要度に応じてデータ量を調整します。ヘルスチェックのように頻度が高く調査価値が低い通信は、除外候補になります。
ただし、費用を減らすために必要なエラーまで失わないよう注意します。
機密情報を送らない
テレメトリーデータは、複数のコンポーネントや外部サービスを通る可能性があります。URL、SQL、HTTPヘッダー、例外メッセージに機密情報が含まれていないか確認が必要です。
特に金融・業務システムでは、口座番号、氏名、認証トークン、入力本文などをそのまま属性へ記録しない設計が重要です。必要な識別情報は、用途に応じてマスキング、ハッシュ化、分類値への置き換えを検討します。
計装する開発者だけでなく、Collector設定とバックエンド権限も含めて管理します。収集後に削除するより、最初から送らない方が安全です。
まとめ
OpenTelemetryは、トレース、メトリクス、ログなどのテレメトリーデータを、共通の方法で生成・収集・転送するためのベンダー中立な仕組みです。監視画面や保存先ではなく、アプリケーションと観測バックエンドをつなぐ標準的な基盤として位置付けられます。
監視は既知の異常を検知することに強く、可観測性は出力されたデータから内部状態を理解することを目指します。OpenTelemetryは後者を支える手段ですが、導入するだけで運用が完成するわけではありません。調査したい問題、収集範囲、コスト、機密情報を先に整理し、小さな範囲から効果を確認することが重要です。
