Header background

OpenTelemetryとは?  ログ、メトリクス、トレースのためのオープンソース標準


OpenTelemetryは、アナリストがソフトウェアのパフォーマンスと動作を理解するのを支援するツール、API、SDKからなるオープンソースのフレームワークです。OTelとも呼ばれるOpenTelemetryは、可観測性の世界における基盤ツールとしての地位を急速に確立しつつあります。

クラウドネイティブコンピューティング財団(CNCF)のオープンソースプロジェクトとして誕生したOpenTelemetryは、ログ、メトリクス、トレースを含むテレメトリデータの生成、収集、処理、エクスポートのための統一されたフレームワークを提供します。

OpenTelemetryを活用することで、ITチームはソフトウェアのパフォーマンスや動作をより深く理解するために、分析用のテレメトリデータの計測、生成、収集、エクスポートを行うことが可能となります。2020年にベータ版としてリリースされた際、OpenTelemetryは廃止されたOpenTracingおよびOpenCensusプロジェクトに取って代わりました。

OpenTelemetryは可観測性を実現します

OTelの役割を理解するには、まず可観測性について知っておくことが役立ちます。従来、可観測性とは、システムが生成する外部データ(通常はログ、メトリクス、トレース)から、システム内部で何が起きているかを把握する能力を指します。

しかし、データそのものの価値は、そこから何を学び、何ができるかによって決まります。Hazel Weakly氏の以下の定義これを端的に表しています:

「可観測性とは、意味のある質問を投げかけ、有用な回答を得て、得られた知見に基づいて効果的に行動する能力です。」

今日のシステムは、10年前、いや5年前と比べても指数関数的に複雑化しています。モノリシックから分散型ITアーキテクチャへの移行により、追跡すべき可動部分や相互作用が大幅に増加し、システムが予測不能な挙動を示すケースも生じています。可観測性は、発生している事象を理解し、その情報に基づいて行動することを可能にします。そしてOpenTelemetryは、この可観測性を実現する基盤を提供します。

一貫性と相互運用性を促進することで、OpenTelemetryは監視の実践を強化し、データ収集と活用の方法の合理化・標準化を通じて業界全体に利益をもたらします。

プロジェクト開始以来、Dynatraceを含む多くのベンダーが、豊富なデータ収集をより容易かつ活用しやすいものにするため、プロジェクトに貢献してまいりました。実際、DynatraceはOpenTelemetryへの主要な貢献組織の一つです。

OpenTelemetry のメリット

アプリケーションデータの収集自体は新しい概念ではありません。しかし、収集メカニズムやフォーマットがアプリケーション間で一貫していることは稀です。この不整合は、アプリケーションの健全性を把握しようとする開発者やサイト信頼性エンジニア(SRE)にとって、大きな課題となる可能性があります。

OTelはDynatraceを含む主要な可観測性ベンダーの大半に支持されており、その結果、クラウドネイティブアプリケーションの計測における事実上の標準となっています。可観測性ソリューション間の差別化要因は、適切な質問を導き出すためにデータをどのように活用するかです。適切な質問を投げかけることで理解のレベルが向上し、企業は成長の加速、イノベーションの推進、顧客が愛する体験の提供が可能となります。

これは、Kubernetesが コンテナオーケストレーションの標準となった経緯に似ています。この広範な採用により、組織は自社でエンタープライズグレードのオーケストレーションプラットフォームを構築する必要がなくなり、コンテナデプロイメントの導入が容易になりました。Kubernetesが将来的に果たし得る役割の類推として考えると、業界全体にもたらすメリットが容易に理解できるでしょう。

可観測性とOTelのアプローチがなぜこれほど重要なのかを理解するために、テレメトリデータそのものと、それが組織のビジネス手法の変革にどのように役立つのかを深く見ていきましょう。

テレメトリデータとは何か?

テレメトリとは、システムコンポーネント内の計測コードから発信される信号(データ)を収集・送信するプロセスです。トレース、メトリクス、ログがテレメトリデータの大部分を構成します。

  • トレースは、プロセス(APIリクエストやその他のシステム活動など)を最初から最後まで追跡した結果であり、サービス間の接続方法を示します。この経路を監視することは、エコシステムがどのように機能しているか、効果的に動作しているか、トラブルシューティングが必要かどうかを理解する上で極めて重要です。トレースは、スパンと呼ばれる個々の操作で構成されており、操作名、タイムスタンプ、コンテキスト、属性、イベント、ステータスなどの一意の識別子を含みます。
  • メトリクスとは、カウント値や時間経過に伴う計算・集計結果として表される数値データポイントです。インフラストラクチャ、ホスト、サードパーティソースなど、複数の発生源から生成されます。ログは常にアクセス可能とは限りませんが、ほとんどのメトリクスはクエリによって取得可能です。タイムスタンプ、値、さらにはイベント名さえも、事前に対処が必要な問題の兆候を明らかにすることがあります。
  • ログは、システム全体における顕著な異常をイベントベースで記録する手段として重要です。構造化、非構造化、プレーンテキストを問わず、これらの可読性のあるファイルは、マルチクラウド環境内のエンドポイントに関わるあらゆるトランザクションの結果を明らかにします。ただし、すべてのログが本質的に確認可能というわけではありません。この課題が、外部ログ分析ツールの必要性を生み出しています。

前述のように、テレメトリデータは「意味のある質問をし、有用な回答を得て、その情報に基づいて効果的に行動できる」状態になったときに、可観測性データとなります。これらすべてを理解するには、可観測性バックエンドが必要です。

OpenTelemetry の仕組みについて

OTelは、以下の図に示すようにいくつかのコンポーネントで構成されています。左から右へ、各コンポーネントの概要を見ていきましょう:

OpenTelemetry Components
OpenTelemetry コンポーネント(出典:OpenTelemetry: beyond getting started に基づく)
  • 仕様。標準的なテレメトリデータ形式を定義し、計測機能の構築方法を記述します。これにより、ユーザーが使用する言語に関わらず、同様の体験が保証されます。
  • データモデル。各シグナルのフィールドとそれらの相互作用を定義します。シグナルにはトレース、ログ、メトリクスが含まれます。
  • API。アプリケーション計測に使用されるメソッドを定義し、計測のエントリポイントとして機能します。OpenTelemetryがサポートする各言語には、独自のAPI実装があります。
  • SDK。APIを実装するとともに、テレメトリの生成方法と相関付け方法を決定します。OpenTelemetryがサポートする各言語には、独自のSDKが存在します。APIとSDKの両方は仕様で定義されており、実装間での体験が同一であることを保証します。
    API は、実装を最小限に抑え、テレメトリ生成コードから分離されるように設計されています。これにより、アプリケーションやライブラリはAPIパッケージのみで動作させることが可能ですが、テレメトリデータはバックエンドに送信されません。この設定は、SDKを統合する準備が整うまでのプレースホルダーとして機能します。準備が整い次第、OpenTelemetryのSDK、ベンダー固有のSDK、またはカスタム構築のSDKなど、ニーズに最適なSDKを選択できます。この柔軟性により、大幅なコード変更なしに機能を追加することが保証されます。
  • コレクター。ベンダーに依存しないバイナリであり、データの取り込み、変換、および1つ以上の可観測性バックエンドへのエクスポートに使用されます。
  • OpenTelemetry Protocol (OTLP)。ベンダーおよびツールに依存しない仕様であり、OpenTelemetryデータのエンコード、送信、配信を可能にします。SDKから送信されるテレメトリデータはOTLPを使用し、多くの監視バックエンドが現在OTLP形式でのデータ取り込みをサポートしています。対応していないバックエンド向けには、OTLPデータをツール固有の形式に変換するエクスポーターが用意されています。OTLPはHTTPとgRPCの両方をサポートします。
  • 監視バックエンド。OpenTelemetryによって収集されたテレメトリデータが送信、保存、分析されるシステムまたはツールです。これにより、組織はテレメトリデータから有意義な知見を導き出し、一貫性のある方法で理解することが可能となります。

OpenTelemetryの今後の展望は?

OpenTelemetryは成熟期を迎え、CNCFプロジェクトとしての卒業を間近に控えています。トレース、ログ、およびメトリクスの大部分は現在一般提供(GA)とみなされています。OpenTelemetryプロジェクトの目標は、現在の提供範囲をはるかに超えています。デジタル体験の向上や、コードレベルのプロファイリングによるアプリケーションパフォーマンスの詳細な洞察の実現など、さらに幅広いユースケースへの道を開く、エキサイティングな取り組みが進められています。OpenTelemetryの注目すべき取り組みのハイライトをいくつかご紹介いたします。これらはすべて、可観測性を次のレベルへ引き上げるために設計されています。

  • デジタルエクスペリエンスモニタリング。開発者やプロダクトチームは、まもなくユーザー向けアプリケーションから直接テレメトリデータを収集できるようになります。これにより、組織はユーザーがラグや問題に直面している箇所を特定し、アプリケーション全体のパフォーマンス向上を図ることが可能となります。
  • コードレベルのプロファイリング。OpenTelemetryは、アプリケーションコードをリアルタイムでプロファイリングする機能も進化させています。これにより、本番環境におけるコードの特定セクションの動作に関する深い洞察が得られ、エンジニアがアプリケーションの重要な部分を最適化するのに役立ちます。
  • AIエージェント。近年、AIシステムの監視ニーズが急増しております。OpenLLMetryはコードをOpenTelemetryプロジェクトへ寄贈する予定です。採用されれば、まもなくOpenTelemetryエコシステムの拡張機能となる見込みです。

OTelコミュニティへの貢献方法について

OpenTelemetry(OTel)への貢献に興味をお持ちでありながら、どこから始めればよいかお悩みの方へ、様々な参加方法がございます。初心者の方から経験豊富な実践者の方まで、OpenTelemetryコミュニティでは、様々な興味やスキルレベルに合わせた多様な機会を提供しております。

OpenTelemetryプロジェクトへの貢献方法としては、OpenTelemetryドキュメント、OpenTelemetryブログ、エンドユーザーSIG(特別関心グループ)、OpenTelemetryデモ、あるいは言語やコンポーネントに特化したSIGなどが挙げられます。貢献の規模に関わらず、皆様の取り組みは大きな違いを生み、深く感謝されています。

さっそく始めてみませんか?当プロジェクトのベテランメンバーであるアドリアナ・ヴィレラが、入門に役立つ素晴らしい記事を執筆しています。

DynatraceはOtelコミュニティにどのように貢献していますか?

DynatraceはOpenTelemetryコミュニティの積極的なメンバーです。Dynatraceのスタッフは、以下のグループにおいてプロジェクトのメンテナや承認者といった重要なリーダーシップの役割を担っています:

  • OpenTelemetry技術委員会
  • OpenTelemetry仕様(メトリクス、セマンティック規約)
  • JavaScript向けOpenTelemetry
  • OpenTelemetry Collector
  • OpenTelemetry デモプロジェクト
  • OpenTelemetry エンドユーザー SIG

実際、DynatraceにはOpenTelemetryへの貢献と、DynatraceプラットフォームがOpenTelemetryデータと円滑に連携することを保証する専任チームが存在します。

DynatraceとOpenTelemetryの連携により、さらなる価値を提供できます

OpenTelemetryは、テレメトリデータ収集のための統一フレームワークを提供する、可観測性分野における重要な基盤技術です。しかし、このデータの潜在能力を最大限に引き出し、実用的な知見に変えるためには、データを効果的に管理、分析、可視化する強力なプラットフォームが不可欠です。

Dynatraceは、OpenTelemetryの機能を強化するために特別に設計されています。データとコンテキストの両方が可観測性を強化する上で重要であり、Dynatraceでは単なるデータ収集にとどまらず、システムの動作原理や最適化方法に関する深い理解を得ることができます。シームレスな統合、テレメトリデータ全体の高度な分析、ビジネス成果への洞察、スタック全体にわたる予測分析により、DynatraceはOpenTelemetryデータをシステム最適化のための実用的な知見へと変換します。

DynatraceがOpenTelemetryデータを革新とビジネス成功の強力な推進力へと変革する方法をご覧ください。DynatraceとOpenTelemetryの導入に関するこの動画シリーズで詳細をご確認ください。