OpenTelemetryとは？

OpenTelemetryの定義、利点、主要コンポーネント

OpenTelemetry（OTel）は、テレメトリデータ（ログ、メトリクス、トレース）を単一の統一形式で収集、処理、エクスポートするためのオープンソースのオブザーバビリティフレームワークです。

Cloud Native Computing Foundation（CNCF）によって、テレメトリデータを収集し、オブザーバビリティバックエンドに送信する方法を標準化するために開発されました。OpenTelemetryはベンダーに依存しないSDK、API、ツールを提供しており、データはOpenTelemetryに準拠した分析のために任意のオブザーバビリティバックエンドに送信できます。

OpenTelemetryは、急速にクラウドネイティブアプリケーションにおける主要なオブザーバビリティテレメトリ標準になりつつあります。OpenTelemetryの採用は、特定のベンダーや既存のテクノロジーの限界に縛られることなく、将来のデータ需要に備えたい組織にとって、きわめて重要であると考えられています。

マイクロサービスのオブザーバビリティのためのElasticとのOpenTelemetry統合を示す図

テレメトリデータ（ログ、メトリック、トレース）の理解

テレメトリデータは現代のオブザーバビリティの基盤です。ログ、メトリック、トレースの3つの柱により、開発者、DevOps、ITチームはシステムの動作、パフォーマンス、健全性に関する深い洞察を得ることができます。

  • ログ：特定の時刻における個別イベントのテキスト記録
    • 例：タイムスタンプ、ユーザーID、IPアドレスで記録されたログイン試行
    • 最適な用途：トラブルシューティング、デバッグ、コード実行の検証
  • 指標：システムのパフォーマンスを反映する時系列データとしての数値測定
    • 例： CPU使用率が85％またはHTTPリクエストレートが1,200/秒
    • 最適な用途：リアルタイムモニタリング、アラート、トレンド分析
  • トレース： 複数のシステムコンポーネントを通るリクエストまたはトランザクションのパスで、スパンの集合
    • 例：eコマースプラットフォームのマイクロサービス全体でチェックアウトプロセスの追跡
    • 最適な用途：分散アーキテクチャにおけるパフォーマンスのボトルネックの特定とリクエストフローの理解

OpenTelemetryを使用して各テレメトリタイプを収集するための詳細な設定ガイダンスについては、ElasticでのOpenTelemetryの利用開始に関するドキュメントをご覧ください。

OpenTelemetryの略歴

OpenTelemetry以前、業界はOpenTracingとOpenCensusに依存していました。これらは、異なる実装で類似の目的を果たす2つの重複するプロジェクトでした。断片化を解消するために、CNCFはこれらを単一のプロジェクト「OpenTelemetry」に統合しました。

主要なレガシーコンポーネント：

  • OpenTracing：テレメトリデータを送信するためのベンダーニュートラルなAPI
  • OpenCensus：メトリクス/トレース収集のための言語固有のライブラリ

統合結果： OTelは両者を統合し、以下の機能を持つ単一のフレームワークを提供します。

  • API
  • SDK
  • インストゥルメンテーションのオプション
  • コレクターサービス

OpenTelemetry は、OpenTracing と OpenCensus の統合から生まれ、それぞれの強みを組み合わせて、オブザーバビリティの単一のグローバルスタンダードを確立しました。

OpenTelemetryにより、開発者はOpenTracingとOpenCensusのどちらかを選択する必要がなくなりました。OpenTelemetryは、データの収集と転送のための統一されたライブラリ、API、エージェント、コレクターサービスのセットを提供します。

OpenTelemetryの動作原理

OpenTelemetryは、テレメトリデータを収集し、選択したオブザーバビリティバックエンドに送信するための標準化されたパイプラインを提供します。ベンダーに依存せず、拡張可能なように設計されています。

  • API：テレメトリデータを生成するための言語固有のインターフェース
  • SDK：APIを実装し、データ処理、バッチ処理、エクスポートを実行
  • インストルメンテーション：自動（コード変更なし）または手動（カスタムメトリクス/イベント）
  • エクスポータ： 処理済みデータをOTLPなどの標準プロトコルを使用して1つ以上の宛先に送信

言語固有のOpenTelemetry APIは、システム全体のテレメトリデータ収集を調整し、コードをインストルメントします。OpenTelemetry SDKは、データ収集、処理、エクスポートを支援するライブラリを通してAPIを実装し、サポートします。また、OpenTelemetryはサービスの自動インストルメンテーションを提供し、カスタムインストルメンテーションをサポートします。テレメトリデータは、ベンダーが提供するエクスポートツールまたはOpenTelemetryプロトコル（OTLP）のいずれかを使用してエクスポートできます。

OpenTelemetryのコアコンポーネント

OpenTelemetryのコアコンポーネントには、次のコンポーネントがあります。

コンポーネント目的使用例
コレクター複数の形式でテレメトリデータを受信、処理、エクスポート、ベンダー中立Elasticに送信する前にKubernetesクラスタからログ、メトリクス、トレースを集約
言語SDK特定のプログラミング言語向けにOpenTelemetry APIを実装Python SDKを使用してPythonで記述されたアプリケーションをインストルメント
インストルメンテーションライブラリテレメトリ生成のための一般的なフレームワークとライブラリを自動インストルメントSpring BootからHTTPリクエストメトリクスを自動的に収集
自動インストルメンテーションコードを変更せずにテレメトリー機能を追加しますJVMベースのマイクロサービスを監視するためにJavaエージェントを注入
エクスポートツール収集したデータを1つまたは複数のオブザーバビリティバックエンドに送信トレースをJaegerに、メトリクスをPrometheusにエクスポート

 

これらのコンポーネントにより、バックエンドの選択に依存せず、柔軟で標準化されたデータ収集が可能になります。

Elasticを使用したOpenTelemetryコレクターのセットアップに関するドキュメントには、完全なインストール手順が含まれています。

OpenTelemetryの利点

OpenTelemetryの利点は、データの標準化と将来を見据えた柔軟性です。その結果、オブザーバビリティが改善され、効率が向上し、コストが削減されます。

  1. 標準化
    1. Elastic、Splunk、Datadogなどの複数のバックエンドに対して、単一の収集方法を使用してください。
    2. ログ、メトリクス、トレースのための単一の拡張可能なフレームワークを使用して、パイプラインの複雑さを軽減します。
  2. ベンダーの中立性
    1. アプリケーションを再インスツルメンテーションせずにバックエンドを切り替えます。
    2. 完全なリプレースを行わずに、新しいオブザーバビリティツールを簡単に導入できます。
    3. テクノロジースタックの進化に合わせて柔軟性を維持します。
  3. 一貫性のあるデータ
    1. 統一された共通スキーマにより、処理と分析が容易になります。
    2. さまざまなソースのデータに対して分析、クエリ、機械学習などを実行します。

OpenTelemetryを使えば、成長のためのスケーラビリティ、プラットフォーム間の互換性、そして既存の監視およびオブザーバビリティツールと容易に統合できます。

OpenTelemetryとElasticの統合

Elasticは長年オープンスタンダードの支持者として、積極的な貢献と協力を通じて業界全体でOpenTelemetryの採用推進に尽力しています。

Elastic Observability は、OpenTelemetryデータをシームレスに統合し、大規模な強力な検索、分析、機械学習、可視化を追加します。2023年、Elasticはテレメトリーデータ形式の統一を支援するためにECSをOpenTelemetryに提供しました。

Elastic Distributions of OpenTelemetry (EDOT) は、SREと開発者に安定したOTelエコシステムを提供します。ElasticのOTelファーストアプローチでは、OpenTelemetryネイティブのスキーマ規則が保持されるため、スキーマ変換は必要ありません。EDOTには、さらに、OTelリリースサイクルを超えた修正と、独自のアドオンのないエンタープライズグレードのサポートが含まれています。

ElasticのOpenTelemetryファーストソリューションを探索

OpenTelemetryとElasticを用いたCI/CDのオブザーバビリティユースケース

Elastic は、Jenkins、Ansible、Mavenなどの一般的なCI/CDプラットフォームと連携して、OpenTelemetryを使用してパイプラインを計測します。

これにより、次のことが可能になります。

  • エンドツーエンドのパイプライン可視性
  • ライブモニタリングダッシュボード
  • 自動アラートと異常検知
  • ビルド/テストの問題のトラブルシューティングを迅速化

OpenTelemetryをElastic CI/CDモニタリングと共に使用するためのセットアップ手順については、公式ドキュメントをご覧ください。

OpenTelemetry FAQ

OpenTelemetryは標準ですか？

はい。OpenTelemetryはオープンソースプロジェクトであり、ログ、トレース、メトリックの統一規格です。

テレメトリの例とは？

テレメトリデータの例としては、システム監視とオブザーバビリティで使用されるログ、メトリック、トレースがあります。

OpenTelemetryとJaegerの違いとは？

OpenTelemetryは、さまざまなオープンソースや商用バックエンドへのデータ処理とエクスポートを支援しますが、Jaegerなどのオブザーバビリティバックエンドではありません。OpenTelemetryがテレメトリデータの生成と管理を支援するAPI、SDK、ツールのセットを提供するのに対して、Jaegerはオープンソースの分散トレーシングツールです。ITチームは、マイクロサービスアーキテクチャーに基づくアプリケーションの監視とトラブルシューティングにJaegerを使用しています。Jaegerはログとメトリックをサポートしていません。

OpenTelemetry APIとSDKの違いとは？

OpenTelemetry API（アプリケーションプログラミングインターフェース）は、システム全体のテレメトリデータ収集を調整し、コードをインストルメントします。APIは言語固有のものなので、コードの言語と一致している必要があります。OpenTelemetry SDK（ソフトウェア開発キット）は、データ収集、処理、オブザーバビリティバックエンドへのエクスポートを支援するライブラリを通してAPIを実装し、サポートします。

OpenTelemetryを開発したのは誰ですか？また、その理由は何ですか？

OpenTelemetry は、テレメトリデータを収集およびエクスポートする方法を統一・標準化するために、Cloud Native Computing Foundation（CNCF）の下で開発されました。断片化を解消するために、以前のOpenTracingとOpenCensusプロジェクトを統合しました。

OpenTelemetry Protocol（OTLP）とは何ですか？なぜ重要なのですか？

OTLPは、コンポーネントとバックエンド間でテレメトリデータを送信するための、OpenTelemetry のデフォルトのベンダーニュートラルプロトコルです。これにより、すべてのデータ（ログ、メトリック、トレース）が一貫した形式で送信され、ツール間の統合がより簡単で信頼性が向上します。

OpenTelemetry Collector とは何ですか？

OpenTelemetry Collectorは、複数のソースからテレメトリデータを受信し、処理（フィルタリング、集約、変換）して、1つ以上のバックエンドにエクスポートするベンダーニュートラルなサービスです。単一の導入内でさまざまなプロトコルとフォーマットをサポートしています。

OpenTelemetryはどのようにElasticと統合されますか？

OTelネイティブのトレース、ログ、メトリクスをサードパーティのOTelツールから、またはカスタムプロセッサーやエクスポーターを使用して自社のOTelコレクターからElasticに取り込んで、Elasticで分析と可視化を行うことができます。ElasticはOpenTelemetryからのOTLPデータをネイティブに取り込み、スケーラブルな検索、インタラクティブな可視化、リアルタイムモニタリング、機械学習ベースの異常検知などの高度な機能を提供します。スキーマ変換は必要ありません。

ElasticのOpenTelemetryリソース