OpenTelemetry（OTel）とは

OTelはプログラミング言語、インフラ、ランタイム環境に関係なくテレメトリー・データの収集方法を簡素化し、開発者があらゆるオブザーバビリティー・バックエンドの標準テレメトリー・データを生成、収集、エクスポートできるようにします。この標準フレームワークはオブザーバビリティー機能を強化および拡張し、IT部門やDevOps部門の柔軟性を高めます。

OTelはアプリケーション、システム、デバイス、バックエンド・ソリューション間で実装されます。ストレージと視覚化を意図的に他のツールに任せるので、組織は自社に最適なツールを自由に選択できます。

オブザーバビリティーとは、システムのアウトプットを分析することでシステム内部の仕組みに関する洞察を得る能力です。IT運用（ITOps）およびクラウド・コンピューティングでは、テレメトリー・データ（ログ、メトリクス、トレースなど）を利用してシステムのパフォーマンスと正常性を評価します。DevOpsの専門家は可観測可能なシステムを構築するために、インストルメンテーション（アプリケーションやシステムにコードを追加してテレメトリー・データを生成およ捕捉すること）に依存しています。

インストルメンテーションはハイブリッドクラウドやマルチクラウド環境、マイクロサービス・ベースのアプリケーション、Kubernetesコンテナ、その他新しいコンピューティング環境機能を備えた最新の環境で作業する場合、複雑になることがよくあります。これらの分散システム、そしてそこに組み込まれているさまざまなプログラミング言語とランタイムは、バックエンド・ストレージ、視覚化、分析用に計測、収集、エクスポートを行うための複雑な配列を提供します。

ネットワーク・サービスやアプリケーションのパフォーマンスを包括的に理解するために、エンジニアはインフラ全体にわたってアプリケーションやシステムにカスタム・インスツルメンテーションを設定する必要があります。OpenTelemetryは、この問題の解決に役立ちます。

OTelはオブザーバビリティー・データを収集および送信するための標準的な方法を提供し、分散システムにおける監視を簡素化するのに役立ちます。ベンダーに依存しない統一ライブラリとAPIを使用してテレメトリー・データを収集し、バックエンド・プラットフォームに送信します。チームでOpenTelemetryを採用することにより、管理しているアプリケーションや使用しているオブザーバビリティー・ツールに関係なく、複数の複雑なシステムにまたがって一律にテレメトリーを収集および処理できます。

インストルメンテーション・コードはかつてはさまざまに異なっていました。また、単一の商用プロバイダーでネットワーク上のすべてのアプリやサービスからデータを収集できるツールを提供することはなかったため、各企業は言語や形式が異なるデータの収集やバックエンドの変更に課題を抱えていました。

例えば開発部門がバックエンド・ツールを入れ替えたい場合、新しいサーバーにテレメトリー・データを送るためにコードを全面的に再構成し、新しいエージェントを設定しなければなりません。さらに、このようにアプローチが細分化されたことでデータのサイロ化と混乱が生じ、パフォーマンス問題の効果的なトラブルシューティングと解決が困難になりました。

OpenTelemetryはテレメトリー・データを収集、分析、バックエンド・プラットフォームに送信する方法を標準化したため、オブザーバビリティーに大きな進歩をもたらしました。これはシステムの挙動とセキュリティーに関するデータを収集するためにコミュニティー主導の規格に基づくオープンソースのソリューションを提供するので、チームが分散型エコシステム内で監視とオブザーバビリティーの効率を高めるのに役立ちます。そのため、OTelはネットワーク・アプリケーションとサービスから重要なデータを収集するためのオープンで一貫性あるアプローチを企業にもたらすのです。

OpenTelemetryは、OpenTracingとOpenCensusの分散トレーシング機能を1つのツールに統合することで作成されました。OpenTracingは、Cloud Native Computing Foundation（CNCF）によって設計されたオープンソース・プロジェクトで、エンジニアがアプリケーションに分散トレーシングのインスツルメンテーションを追加するためのベンダー中立のAPIを提供するものでした。また、テレメトリー・データの一貫性を確保するためのセマンティック規約を定めていました。

しかしOpenTracing自体はOpenTelemetryと異なり、トレーシングの実装ではありませんでした。むしろ、プラットフォーム間の互換性を最大化するためにトレーシングシステムが実装できるインターフェースを提供していました。OpenTracingは機能していないプロジェクトですが（現在ではOpenTelemetryへの移行が奨励されています）、さまざまなソフトウェアやトレース・ソリューションが依然としてそのAPIに依存しています。

OpenCensusは、Google社がアプリケーションのメトリクスと分散トレースを収集するために開発した一連のインストルメンテーション・ライブラリーで、さまざまなバックエンドにリアルタイムでデータをエクスポートできます。一貫したプロパゲーション・タグとメタデータを使用してデータを収集します。この概念は現在「リソース」としてOpenTelemetryに存在しています。

OpenCensusでは、アプリケーションは特定の要件に基づいてデータをインポートおよびエクスポートでき、メトリクスやトレースをオブザーバビリティー・バックエンドに送信する方法に柔軟性を持たせることができます。OpenCensusはOpenTracingのように正式に廃止されたわけではなく、現在も定期的なメンテナンスやセキュリティー更新が行われています。しかし、積極的な開発は大部分がOpenTelemetryに移行しています。

両プロジェクトは、同じ課題に取り組むことを目的としていました。当時、開発チームにはコードにインスツルメンテーションを施し、テレメトリー・データをバックエンドのオブザーバビリティー・ツールに送信する標準的な方法がありませんでした。

しかし、どちらのプロジェクトも単独ではこの課題を解決できませんでした。そのためCNCFはOpenTelemetryプロジェクトを支援し、両ソリューションの優れた機能を統合しました。OpenTelemetryは、OpenTracingのAPI標準化とOpenCensusのデータ収集機能を統合し、テレメトリー・データをバックエンドのオブザーバビリティー・プラットフォームに送信、収集、転送するための単一の統合プラットフォームを提供します。

高速で可用性の高いネットワークとアプリケーションを運用する上で重要なのはFull Stack Observability（あるいは可視性）の実現です。そのためにはテレメトリー・データへのアクセスが必要となります。オブザーバビリティー・ソリューションは、テレメトリー・データを収集、監視、分析してシステムの正常性を判断し、修復と最適化のために実行可能な洞察をIT部門に与えます。

OpenTelemetryをより深く理解するために、テレメトリー・データとは何か、組織でそれをどのように使用できるかを詳しく見ていきましょう。OpenTelemetryは特定のデータ種類、すなわちログ、メトリクス、トレース（「オブザーバビリティーの3つの柱」と呼ばれることが多い）から収集されたアウトプットに対応しています。

メトリクスは、システムのパフォーマンスとリソースの使用状況の数値評価です。これらは、レイテンシー、パケット損失、帯域幅使用率、デバイスのCPU使用率といった主要業績評価指標（KPI）を取得することで、ネットワークの健全性を俯瞰的に示します。

メトリクスは、ダッシュボードなどの視覚化を使い要約されることが一般的です。これにより、多くの場合、システムまたはアプリケーションのパフォーマンスの問題がある可能性について兆候を受け取ることができます。

ログは、環境内で発生するすべてのイベントやアクションを詳細に記録したものです。ログは、何が、いつ、ネットワークのどこで発生したのかという詳細情報を提供し、トラブルシューティング、デバッグ、フォレンジック分析に役立つ有用な背景情報をチームに与えます。

ログには、デバイス構成の変更、認証の失敗、接続の切断などのシステムイベントの詳細が記録されるため、問題の根本的な原因を明らかにできます。

トレースはネットワーク全体のデータ・フローを取得し、複数のデバイスやシステムを通過するパケットのパスと動作についての知見を提供します。これらは、分散システムを理解し、レイテンシーの問題を診断するために不可欠です。

トレース・データにより、IT部門はトランザクションの全過程をエンドツーエンドで確認できるようになり、複雑な多層環境で発生する遅延や障害を正確に特定できるようになります。

OpenTelemetryはデータ収集を成功させるために、次のようなコンポーネントとプロセスに依存しています。

• アプリケーション・プログラミング・インターフェース（API）
• 言語ソフトウェア開発キット（SDK）
• コレクター
• エクスポーター
• 自動計装

APIとは、ソフトウェア・アプリケーションが相互に通信してデータ、機能、および機能を交換できるようにする一連のルールまたはプロトコルです。

OpenTelemetryは、Java、Ruby、JavaScript、Pythonなどの言語ごとにAPIを提供しており、開発者はこれを利用してアプリケーションにインスツルメンテーションを施し、テレメトリー・データを収集できます。OpenTelemetry APIはアプリケーションをネットワーク・インフラストラクチャーから切り離し、チームに対してインスツルメンテーション・コードに適合する任意のエンドポイントを利用できる柔軟性を提供します。

OpenTelemetry SDKにより、エンジニアはAPIの動作を設定し、カスタマイズできます。SDKはAPIとコレクターの橋渡しを行い、一般的なライブラリー向けの手動インスツルメンテーションをアプリケーションの手動インスツルメンテーションに接続できるようにします。

OTelは幅広いプログラミング言語向けにSDKを提供しており、開発者はOTel APIを使用して、選択した言語やバックエンドに対応したテレメトリー・データを生成・エクスポートできます。OTel SDKは、OpenTelemetryコミュニティーでまだ対象とされていない社内フレームワーク向けのカスタム・インスツルメンテーションもサポートしています。

コレクターとは、OpenTelemetryで計装されたアプリケーションからテレメトリー・データを収集するエージェントです。レシーバー、プロセッサー、集約、エクスポーターで構成されるコレクターはベンダーに依存しない仲介者として機能します。アプリケーションからデータを受信し、分析のためにオブザーバビリティー・プラットフォームやその他の宛先に転送します。

OpenTelemetryコレクターは、OpenTelemetry Protocol（OTLP）、Prometheus、Jaegerなど複数の形式でデータを取り込み、さまざまなバックエンドにエクスポートできるcontribパッケージをサポートしており、場合によっては冗長性のために同時にエクスポートすることも可能です。Contribパッケージは、開発チームにインスツルメンテーション、サンプラー、プロパゲーター、リソース・ディテクターをサブモジュール形式で提供するサードパーティー拡張機能です。

コレクターは、テレメトリー・データをエクスポートする前に処理およびフィルタリングして最も重要なデータの配信を優先し、トラブルシューティングとデバッグのプロセスを加速させることもできます。

エクスポーターはコレクターの一部であり、アプリケーションのテレメトリー・データを複数の指定オブザーバビリティー・バックエンドに送信する役目を負います。コレクターがデータ・フロー全体を管理するのに対し、エクスポーターはデータの外部送信を優先します。

OpenTelemetryデータ・エクスポーターは、インストルメンテーションをバックエンド構成から切り離し、各オブザーバビリティー・プラットフォームに合わせてデータを適切な形式に変換します（トレースをZipkinプロトコルに変換するなど）。この仕組みにより、コレクターは同じテレメトリー・データを複数のバックエンドに送信でき、コードのインストルメンテーション・ロジックを変更せずに送信先を切り替えることが容易になります。

自動インストルメンテーションは、最小限のコード変更または全くコード変更をせずに、アプリがテレメトリー・データを自動生成できるようにする既製のライブラリーとフレームワークを提供します。このプロセスのおかげで開発者のインストルメンテーションが簡素化され、手作業によるコーディング・タスクが減り、場合によっては完全になくなります。

ただし、自動計測は手動計測に比べて特定の種類のデータ収集を細かく制御することが難しくなる場合があります。自動計測の範囲も、言語ランタイム、コンピューティング環境、オブザーバビリティー・フレームワークのコミュニティサポート・レベルによっても異なります。

OpenTelemetryは、API、SDK、コレクター、自動計測プロセスを組み合わせてデータを収集し、ターゲット・システムに送信します。

まず、DevOpsチームは、OTel APIを使用してアプリケーション・コードを計測し、収集対象のメトリクス、トレース、ログとその収集方法を指定します。OTel SDKコレクターは、データを収集して処理とエクスポート用に準備し、データをサンプリング、フィルターし、依存関係やその他のデータ・ソースと関連付けます。

処理済みデータが適切にフォーマットされると、SDKはそれを時間ベースのバッチにグループ化し（必要に応じてさらにフィルタリングを行う）、指定のバックエンド・システムに送信します。

OpenTelemetryの主な目標は、テレメトリー・データを収集、エクスポートするとともにオブザーバビリティーを高め、ベンダーに対する中立性およびプラットフォームとツールの統合を促進するツールを組織にもたらすことです。これにより、DevOps部門とサイト信頼性エンジニアリングを実践するエンジニア（SRE）はアプリケーションとシステムの管理とデバッグを行うことができるため、より多くの情報に基づいた意思決定が可能になり、ビジネス・ニーズが変化しても敏捷性を維持できるのです。

OTelのメリットは次のとおりです。

• 一貫したデータ収集の実施
• ベンダー・ロックインの回避
• オブザーバビリティーの効率化
• 将来を見据えたITエコシステム
• リソースの使用状況の追跡
• データ要求の優先順位付け
• モニタリング・データへのアクセスの拡大

一貫したデータ収集の実施

OpenTelemetryを使うことで、チームはさまざまなアプリ、システム、ユースケースにわたり、一貫してテレメトリー・データを収集できます。

ベンダー・ロックインの回避

OTelはベンダーに依存しないソリューションです。開発者がインストルメンテーション・コードに大きな変更を加えることなく、バックエンドのオブザーバビリティー・ツールやプロバイダーを切り替えることができます。

オブザーバビリティーの効率化

OTelは、IT担当者がソースコードやメタデータを変更することなくテレメトリー・データを収集できるため、オブザーバビリティーを簡素化します。また、使用するオブザーバビリティー・バックエンドやベンダーに関係なく、開発者がフルスタックの可視性を維持できるようにします。

将来を見据えたITエコシステム

OpenTelemetryはオープンソースのコミュニティーとCNCFに支えられているため、コンピューティング技術とオブザーバビリティーのニーズの変化に合わせて進化するように作られています。例えばOTelは最近、主要なテレメトリー信号群に継続的プロファイリングを追加しました。¹

リソースの使用状況の追跡

OpenTelemetryはサーバー間のデータ要求を捕捉してリソースの使用状況をグループごとに分類できるので、IT部門が共有システム間の使用状況を追跡するのに役立ちます。

データ要求の優先順位付け

OpenTelemetryは、アーキテクチャー内でデータ要求の優先順位付けパイプラインを作成でき、重要度に応じて競合する要求がネットワークを通過するようにします。

モニタリング・データへのアクセスの拡大

OTelを使うことで、開発者はテレメトリー・データを監視し、どのようなWebブラウザーやデバイスでもアラートを受け取ることができるため、ソフトウェアのパフォーマンスやシステム全体の正常性を簡単にリアルタイムで追跡できます。