システムの内部状態をシステムの出力から理解する「オブザーバビリティ」。その実現に欠かせないテレメトリーデータを、言語やフレームワーク、ベンダーに依存しない標準的な方法で生成・収集するためのフレームワークがOpenTelemetryです。OpenTelemetryとは何か、何ができるのか、なぜ注目されているのか。基本概念から導入メリットまでわかりやすく解説します。
目次
- OpenTelemetryとは何か
- なぜOpenTelemetryが注目されるのか
- OpenTelemetryが扱う主要なシグナル
- OpenTelemetryの主な構成要素
- OpenTelemetryの始め方
- MackerelとOpenTelemetry
OpenTelemetryとは何か
オブザーバビリティとテレメトリーデータ
OpenTelemetryを理解するには、その背景にある オブザーバビリティ（可観測性） という考え方を押さえておくとスムーズです。オブザーバビリティとは、システムの出力を見ることでその内部状態を理解できる能力のことです。メトリック・トレース・ログといったテレメトリーデータはそうした出力の一例です。障害の検知だけでなく、「なぜ遅いのか」「どこでエラーが起きているのか」といった問いに答えるために、質の高いテレメトリーデータを収集する仕組みが欠かせません。
OpenTelemetryが目指すもの
OpenTelemetry（略称: OTel） は、このテレメトリーデータを生成・収集・エクスポートするためのフレームワーク、プロジェクトの総称です。Cloud Native Computing Foundation（CNCF）のプロジェクトとしてオープンソースで開発されています。
OpenTelemetryの本質は「計装の標準化」にあります。どのプログラミング言語やフレームワークを使っていても、どの監視ツールやオブザーバビリティバックエンド（以下、バックエンド）にデータを送る場合でも、アプリケーションからデータを集める方法を共通化する。つまり、オブザーバビリティを実現するための標準的な計装基盤——それがOpenTelemetryの目指すところです。データの保存や可視化はバックエンド側の役割であり、OpenTelemetryはそこまでは担いません。だからこそ、収集したデータをどのバックエンドに送るかを利用者が自由に選べる設計になっています。
では、この標準化によってどのようなメリットが得られるのでしょうか。
なぜOpenTelemetryが注目されるのか
OpenTelemetryが多くのエンジニアや組織に注目されている理由をまとめてみましょう。
- ベンダーロックインの回避: 計装が標準化されているため、特定のバックエンドやベンダーに依存しにくくなります。オブザーバビリティバックエンドを見直す際も、アプリケーション側の計装を大きく変えずに移行しやすいのが特長です。データの送り先の設定や、可視化、運用の設定を切り替えるだけで、異なるバックエンドに対応できるようになります。
- 計装の一元化: 1つのフレームワークでメトリック・トレース・ログを統一的に扱えます。計装の方法がバラバラで覚えきれない、といった負担がなくなり、学習コストや運用負荷が下がります。
- シグナル間の相関: シグナル（後述）に共通のコンテキスト（トレースIDなど）を埋め込める設計になっているため、相関分析の土台を整えやすくなっています。
OpenTelemetryが扱う主要なシグナル
OpenTelemetryでは、システムの状態や振る舞いを把握するために収集するデータの種類を シグナル と呼びます。主要なシグナルを見ていきましょう。
トレース
リクエストが複数のサービスをどのように流れたかを追跡するシグナルです。分散システムにおいて、1つのリクエストがどのサービスを通り、どこで時間がかかったのかを可視化できます。
トレースは スパン という単位で構成されます。各スパンは「HTTPリクエストの処理」「データベースへのクエリ」といった個別の処理を表し、共通の トレースID で紐づけられることでリクエスト全体の流れを把握できるようになります。
メトリック
CPU使用率、メモリ消費量、レスポンスタイムなど、システムの状態を表す数値データです。時系列で収集し、パフォーマンスの傾向把握やアラート設定に活用します。
ログ
アプリケーションやシステムが出力するイベントの記録です。エラーメッセージや処理の経過といった情報が含まれ、トラブルシューティングの際に重要な手がかりとなります。
OpenTelemetryの主な構成要素
OpenTelemetryは、いくつかのコンポーネントが連携してテレメトリーデータのパイプラインを構成しています。ここでは主要な要素を見ていきましょう。
OpenTelemetry全体の共通仕様
OpenTelemetryは、シグナルの定義や属性の命名規約など、全体で共通の仕様を定めています。これにより、異なる言語やフレームワークで計装しても、データの形式が揃うようになっています。
API・SDK
APIはアプリケーションに計装を組み込むための共通インターフェースで、SDKはそのAPIを実装し、テレメトリーデータの処理やエクスポートを行うための仕組みです。Java、Go、Node.js、PHPなど、主要なプログラミング言語に対応しています。
計装にはいくつかの方法があります。
- ゼロコード計装: アプリケーションのコードを変更せず、起動時パラメータや環境変数の設定だけでテレメトリーデータを取得する方法
- ライブラリ計装: ライブラリやフレームワーク向けの計装ライブラリを導入し、HTTPリクエストやデータベースクエリなどを自動的に記録する方法
- コードベース計装: APIを使って、アプリケーション固有のビジネスロジックやカスタムデータを計装する方法
まずはゼロコード計装から始めて、どんなデータが取れるのかを確認してみるのがおすすめです。コードの変更なしにテレメトリーデータを取得でき、導入のハードルがぐっと下がります。
OpenTelemetryコレクター
OpenTelemetryコレクター（以下、コレクター） は、テレメトリーデータの受信・処理・エクスポートを担うコンポーネントです。アプリケーションとオブザーバビリティバックエンドの間に配置して使います。
コレクターは3つのパーツで構成されるパイプライン構造を持っています。
- レシーバー: アプリケーションからデータを受け取る入口
- プロセッサー: フィルタリングやバッチ処理などの加工を行う中間処理
- エクスポーター: 加工済みデータをオブザーバビリティバックエンドに送り出す出口
以下は、トレースシグナルをエクスポートするコレクターの設定例です。
receivers: otlp: protocols: grpc: endpoint: "0.0.0.0:4317" http: endpoint: "0.0.0.0:4318" exporters: otlphttp/mackerel: endpoint: "https://otlp-vaxila.mackerelio.com" service: pipelines: traces: receivers: [otlp] processors: [] exporters: [otlphttp/mackerel]
このように、YAMLファイルでデータの流れを宣言的に定義できます。
OTLP（OpenTelemetry Protocol）
OTLP は、テレメトリーデータを転送するための標準プロトコルです。コレクターやバックエンドとの通信に使われ、OTLPに対応したバックエンドであれば、データの送り先を切り替えるだけで連携が可能です。
セマンティック規約（Semantic Conventions）
テレメトリーデータに付与する属性名やリソース名のルールを定めた共通の取り決めです。たとえばHTTPリクエストのメソッドは http.request.method、レスポンスのステータスコードは http.response.status_code のように、あらかじめ名前が決まっています。
この規約があることで、異なる言語やフレームワークで計装しても、データの形式が揃います。異なるサービスやコンポーネント間でデータを比較・分析しやすくなるのは、この標準化のおかげです。
OpenTelemetryの始め方
OpenTelemetryを導入する第一歩として、まずはゼロコード計装から試してみましょう。たとえばJavaアプリケーションの場合、OpenTelemetry Java Agentを使えば、JVMの起動オプションに以下のような設定を追加するだけでトレースデータの収集を始められます。
java -javaagent:opentelemetry-javaagent.jar \ -Dotel.service.name=my-service \ -Dotel.exporter.otlp.endpoint=http://localhost:4317 \ -jar my-app.jar
データの送り先としては、アプリケーションから直接バックエンドにエクスポートする方法と、コレクターを経由する方法があります。上の例は、同じホスト上で起動したコレクター（localhost:4317）にデータを送る構成です。本番環境では、データのバッファリングやリトライ、フィルタリングなどを柔軟に行えるコレクター経由の構成がおすすめです。
MackerelとOpenTelemetry
Mackerelは、OpenTelemetry形式のメトリックとトレースに対応しています。APM（アプリケーションパフォーマンスモニタリング）の機能として、分散システムにおけるリクエストフローの可視化やパフォーマンスのボトルネック分析が可能です。OpenTelemetryの標準的な計装をそのまま活用して導入できるため、既存の計装資産を活かしながらMackerelでの監視を始められます。
OpenTelemetryを使った監視を始めてみたい方は、以下の記事やドキュメントもあわせてご覧ください。
Mackerelは無料トライアルでお試しいただけます。ぜひOpenTelemetryを活用した監視を体験してみてください。
＼Mackerelを無料で体験／
Mackerelは、サーバーやアプリケーションの状態を可視化し、システム全体の状況を把握できるサービスです。
トライアルでは、メトリックやアラート、ダッシュボードなどの機能を実際の画面で確認しながら、Mackerelによる監視や可視化を体験できます。
14日間無料で、全機能をご利用いただけます。
