OpenTelemetry (OTel) は、共通の言語、データモデル、基盤となる伝播動作の統合である可観測性フレームワークおよびツールキットです。 OTel の設計はトレース、測定基準、ログなどのテレメトリデータの管理のために設計されており、オープンソースのため柔軟性も向上します。
OpenTelemetry は、OpenTracing と OpenCensus という 2 つの旧プロジェクトが合併して生まれたものです。 これらのプロジェクトはどちらも同じ問題、つまり、コードを計測してテレメトリデータを可観測性バックエンドに送信する方法の標準の欠如という問題を解決するために作成されました。 ところがどちらのプロジェクトも単独で問題を完全に解決できなかったため、2 つのプロジェクトを合併して OpenTelemetry が形成され、それぞれの強みを組み合わせて単一の標準を提供できるようになりました。
重要なのは、OpenTelemetry がベンダーやツールに依存しない点です。そのため、Jaeger や Prometheus などのオープンソースツールや商用オファリングなど、さまざまな可観測性バックエンドで使用できます。 OTel は Cloud Native Computing Foundation (CNCF) のプロジェクトです。堅牢かつポータブルで、さまざまな言語で測定しやすいソリューションとして機能するように構築されています。 API、ライブラリ、エージェント、コレクターサービスの単一セットを提供し、アプリケーションから分散トレースと測定基準を取得します。 OpenTelemetry は真の可観測性を実現します。
「可観測性 (オブザーバビリティ)」とは、ソフトウェアエンジニアリングとシステム管理の世界で大きな注目を集めている用語であり、もはやその言葉の意味が失われかけているほどです。 今では IT 業界で働く人でさえ、この用語をあらゆる種類のシステム可視性を示す言葉として大雑把に使う人が増えています。 しかし、可観測性とは厳密には何を指し、従来の監視とはどう異なるのでしょうか？
監視とは、システムのステータスを積極的に監視して確認するプロセスであり、通常は事前定義されたしきい値とアラートを使用します。 このアプローチでは問題が発生したときに影響を受けるシステムに注意を向けることができますが、監視では多くの場合、問題が発生している理由や問題を解決する最善の方法についてのインサイトは得られません。
一方、可観測性はより包括的なアプローチです。 外部出力を分析することで、システム内で何が起こっているかを理解する能力を指します。 可観測性では、事前に知りたいことを定義しておくことなく、発生したことについていつでもどのような質問でもできます。 基本的に、監視は問題が存在することが分かりますが、可観測性はその問題が発生した理由を理解するのに役立ちます。
可観測性に不可欠な 3 つの主要な柱があります。
- トレース
トレースは、システムを介した要求のジャーニーを表し、詳細なサービスインタラクション像を提供できます。 OpenTelemetry トレースは、属性とイベントを含むスパンに編成され、さまざまなプロセスやサービスで行われている作業を説明してコンテキスト化します。 - 測定基準
測定基準は、一定の時間間隔で測定されたデータの数値表現です。 測定基準によってシステムのパフォーマンスと動作を継続的に監視できます。 OpenTelemetry では、Metrics API を使用してシステム測定基準を記録、設定、追加でき、後で分析をフィルタリングして集計するためのツールを提供します。 - ログ
ログは、システムやアプリケーションによって生成されるテキストベースのレコードです。 イベントを時系列的に説明し、システムの動作をデバッグして理解するために不可欠です。
これら 3 つの要素は長い間、可観測性において最も重要な要素と考えられてきましたが、現代の分散システムは規模と複雑さが増しているため、この従来型モデルは進化を余儀なくされています。 実際に使用している人たちは、3 つの柱が孤立しているのではなく、本質的には相互につながっており、互いに連携して使用する必要があることを認識し始めています。
OpenTelemetry は、分散したマイクロサービスベースのシステムで可観測性を実現する上で重要な役割を果たします。 ポータビリティ、実装とソフトウェア開発キット (SDK) のほとんどの言語での可用性、特にエクスポーターとコレクターのモデルに重点を置いているため、システムに適したデータを収集して配布するための重要なツールとなっています。
OpenTelemetry を使用すると、チームはシステムの動作を分析するために必要な主要トレースデータと測定基準データを効率的に収集できます。 可観測性プラクティスとの連携により、システムパフォーマンスをより深く理解することができ、問題の診断と解決の能力が向上します。
トレースが可観測性の 3 つの柱の 1 つであるように、トレーシングはソフトウェア開発における重要なプラクティスであり、通常、専用デバッグツールによるアプリケーションコードのプロファイルと分析に使用されます。 OpenTelemetry のコンテキストでは、トレーシングは微妙に異なる意味を持ち、今日の複雑なアーキテクチャに不可欠な概念である「分散」トレーシングの意味で最もよく用いられます。
分散トレーシングは、従来のトレース技術を最新のマイクロサービス駆動型アプリケーションに適用したものです。 一体型アプリケーションは障害を診断するために単一のスタックトレースに従いますが、このアプローチで扱うには分散システムは複雑すぎます。1 つのアプリケーションを構成するサービスが数千件に及ぶ可能性があり、さらにそれらが実行されるホストも多数ある場合、個別トレースでは不十分になります。 分散トレーシングはこの問題を解決するため、要求が異なるサービスの境界を越えて移動するときにプロファイリングし、分析用の高品質データを生成します。 この方法は、次のような機能を提供します。
- 例外検出
- ワークロードモデリング
- 定常状態の問題診断
OpenTelemetry では、トレースはリンクされたスパンのコレクションであり、そのスパンとは要求内の作業単位を表す名前と時間が指定されたオペレーションです。 スパンは親がある場合もあれば、ルートスパンである場合もあります。ルートスパンでは、トレース全体のエンドツーエンドのレイテンシを表します。 子スパンは、トレース内のサブオペレーションを表します。
- ルートスパン
トレースの親または開始点。要求全体のレイテンシを表します。 - 子スパン
トレース内の特定のサブオペレーションです。
スパンは、スパン中に発生したオペレーションの名前、開始タイムスタンプと終了タイムスタンプ、イベント、属性などの基本情報をカプセル化します。 また、他のスパンとオペレーションのステータスへのリンクも含まれています。
分散システムのトレースデータが複雑であることを考えると、コンテキストやその他の関連する詳細情報にアクセスできることでデータ分析に大きなプラスの効果がもたらされます。 OpenTelemetry では、これらのタグは「属性」と「イベント」と呼ばれます。
- 属性
トレースデータの分析を支援するためにスパンに追加できるキーと値のペア (OpenTracing では「タグ」)。 - イベント
オプションの属性セットのあるタイムスタンプ付き文字列。詳細な説明を提供するため、より詳細な分析が可能になります。
OpenTelemetry のスパンは、トレーサーによって生成されます。トレーサーは、現在アクティブなスパンを追跡し、新しいスパンを作成できるオブジェクトです。 プロパゲーターオブジェクトは、プロセス境界を越えたコンテキストの転送をサポートします。これは分散システムにおけるトレースの重要な側面です。 トレーサーは、完了したスパンを OTel の SDK のエクスポーターにディスパッチします。エクスポーターは詳細な分析のためにスパンをバックエンドシステムに送信する責任を負います。
トレーシングは個々の要求とオペレーションに関する詳細なインサイトを提供する一方で、測定基準を含む OpenTelemetry 内の可観測性の幅広いコンテキストにも結びついています。 トレースデータを関連する測定基準と結び付けることで、組織はシステムの動作とパフォーマンスを包括的に把握できます。
OpenTelemetry のコンテキストでは、Metrics API は測定値の生データを継続的に処理して要約するように設計されています。 これにより、プロセスメモリの使用率、エラー率など、重要な運用評価指標の可視性が向上します。 測定基準は、集計と記録のためにさまざまな機器に送信できます。 OpenTelemetry Metrics API は、エクスポートする値の最終的なタイプではなく、セマンティックな意味に従って測定基準を分類します。
Metrics API には 6 つの異なる測定基準インストルメントが用意されており、それぞれが特定の機能を果たします。 これらのインストルメントは、SDK へのユーザーのエントリポイントである Meter API の呼び出しによって作成および定義されます。 測定基準インストルメントは「同期」または「非同期」のいずれかです。
同期インストルメントは要求内で呼び出され、関連する分散コンテキストを所有します。 同期インストルメントには以下が含まれます。
- カウンター
カウンターインストルメントは Add() 関数で正の値を受け入れます。 これは、受信バイト数、完了した要求、エラー発生率の測定などのデータをカウントするのに最適で、特にレート測定に適しています。 - UpDownCounter
カウンター機能の拡張である UpDownCounter は、Add() 関数を使用して正と負の両方の増分を処理します。 これは、アクティブな要求、使用中のメモリ、キューサイズなどの数量を監視する場合に便利です。 - ValueRecorder
ValueRecorder インストルメントは、Record() 関数を使用して離散イベントの値をキャプチャします。 これは、レイテンシー、要求サイズ、キューの長さをキャプチャし、値の分布を強調するために使用されます。
同期インストルメントとは異なり、非同期インストルメントには関連するコンテキストがありません。 これらのインストルメントは Callback によって報告され、収集間隔ごとに 1 回限り呼び出されます。 非同期インストルメントには次のものがあります。
- SumObserver
SumObserver インストルメントは、非同期の単調和に Observe() 関数を使用しており、キャッシュミスやシステム CPU などのデータに最適です。 - UpDownSumObserver
UpDownSumObserver は非同期の非単調なカウンターで、Observe() 関数で正と負の合計を受け入れます。 このインストルメントは、プロセスヒープサイズなど、合計の上昇と低下をキャプチャする測定に使用されます。 - ValueObserver
最後に、ValueObserver は、Observe() 関数を使用して非加法的測定をきめ細かく制御できるようにします。 これは、測定の焦点が分布である場合に理想的です。
任意のインストルメントによってキャプチャされる測定基準イベントは、タイムスタンプ、インストルメント定義 (名前、種類、説明、測定単位)、ラベルセット (キーと値)、値 (整数または浮動小数点数)、SDK に関連付けられたリソース、分散コンテキスト (同期イベントのみ) で構成されます。 幅広い測定基準インストルメントが利用可能なため、さまざまなタイプのデータを柔軟にキャプチャし、各種システム属性の分析と監視を支援します。
監視の対象がエラー率、レイテンシー、リソース使用率のいずれであっても、OpenTelemetry の測定基準インストルメントは、開発者がアプリケーションに関する重要なインサイトを得るための多様なオプションを提供します。
エクスポーターは、分析とアラートのためにテレメトリデータをバッチ処理し、バックエンドシステムに転送する責任を負います。 OpenTelemetry のエクスポーターモデルは、3 つの異なるレベルでインストルメンテーションの連携をサポートしています。
- サービスレベルの連携
これには、コード内の関連する OpenTelemetry パッケージへの依存関係を宣言し、それに応じて展開することが含まれます。 - ライブラリ依存関係
サービスレベルの連携に似ていますが、ライブラリに固有であり、通常は OpenTelemetry API への依存関係のみを宣言します。 - プラットフォームの依存関係
これらは、Envoy や Istio など、サービスをサポートする独立したソフトウェアコンポーネントです。 OpenTelemetry のコピーを展開し、サービスに役立つトレースコンテキストを発信します。
OpenTelemetry SDK によって実装されるエクスポーターインターフェイスは、データを送信する前に、テレメトリデータを特定のバックエンドシステムに必要な形式に変換するプラグインモデルを使用します。 また、このモデルはエクスポーターの構成とチェーンをサポートし、さまざまなプロトコル間で機能を共有しやすくします。
OpenTelemetry のアプローチの重要な利点の 1 つは、エクスポートコンポーネントの切り替えや追加が容易であることです。 この点が、システムを変更するためにトレーサーコンポーネント全体を交換する必要がある OpenTracing とは異なります。
エクスポーターモデルは非常に便利ですが、特定の組織的または技術的な制約により、新しいエクスポーターを追加するためのサービスの再展開が容易ではない場合があります。 OpenTelemetry コレクターは、複数のプロセスからのテレメトリデータの「シンク」として機能し、ServiceNow Cloud Observability、Jaeger、Prometheus などのさまざまなバックエンドシステムにエクスポートするように設計されています。 コレクターは、サービスと並行してエージェントとして、またはリモートアプリケーションとして展開できます。
- エージェント
サービスとともに展開され、個別のプロセスまたはサイドカーとして実行されます。 - リモートコレクター
コンテナまたは仮想マシンに個別に展開され、各エージェントからテレメトリデータを受信してバックエンドシステムにエクスポートします。
OpenTelemetry は、次の主要コンポーネントで構成されています。
- すべてのコンポーネントの仕様
- テレメトリデータの形状を定義する標準プロトコル
- 一般的なテレメトリデータタイプの標準的な命名スキームを定義するセマンティック規則
- テレメトリデータの生成方法を定義する API
- 一般的なライブラリやフレームワーク用のインストルメンテーションを実装するライブラリエコシステム
- コードを変更せずにテレメトリデータを生成する自動インストルメンテーションコンポーネント
- テレメトリデータの仕様、API、エクスポートを実装する言語 SDK
- テレメトリデータの受信、処理、エクスポートを行うプロキシである OpenTelemetry コレクター
- Kubernetes 向け OpenTelemetry Operator など、その他のさまざまなツール
幅広いオープンソースエコシステム統合と互換性がある OpenTelemetry は、多数のベンダーにもサポートされています。ベンダーの多くは、OpenTelemetry に商業サポートを提供し、プロジェクトに直接貢献しています。
OpenTelemetry は拡張可能な設計です。 拡張方法の例としては、次のようなものがあります。
- OpenTelemetry Collector にレシーバーを追加して、カスタムソースからのテレメトリデータをサポートする
- SDK へカスタムインストルメンテーションを読み込む
- 特定のユースケースに合わせて SDK またはコレクターの配布を作成する
- OpenTelemetry プロトコル (OTLP) をまだサポートしていないカスタムバックエンド用の新しいエクスポーターを作成する
- 非標準のコンテキスト伝播形式のカスタムプロパゲーターを作成する
ほとんどのユーザーは OpenTelemetry を拡張する必要はありませんが、このプロジェクトはほぼすべてのレベルで拡張可能になるように設計されています。
クラウドコンピューティング、マイクロサービスアーキテクチャの台頭、ビジネス要件の複雑化に伴い、可観測性に対するニーズはかつてないほど高まっています。
システムを観測可能にするには、インストルメンテーションが必要です。 つまり、コードはトレース、測定基準、ログを出力する必要があります。 インストルメンテーションされたデータは、可観測性バックエンドに送信する必要があります。
OpenTelemetry は、次の 2 つの重要なことを行います。
- 独自のデータ形式やツールに縛られることなく、生成したデータを所有できます。
- 単一の API セットと表記法を学習できます。
これら 2 つの要素を組み合わせることで、チームと組織は今日のモダンコンピューティングの世界で必要とされる柔軟性を得ることができます。
OpenTelemetry は、Jaeger、Prometheus、または商用ベンダーのような可観測性バックエンドではありません。 OpenTelemetry は、テレメトリデータの生成、収集、管理、エクスポートに重点を置いています。 そのデータの保存と可視化は、意図的に他のツールに委ねられます。
エンドツーエンドの可視性の必要性は、これまで以上に重要になっています。 OpenTelemetry は、さまざまなアプリケーションやプログラミング言語でテレメトリデータ収集の標準化されたアプローチを提供します。 OTel は、システムの動作に関する包括的なインサイトを提供することで、パフォーマンスの最適化、問題のトラブルシューティング、シームレスなユーザーエクスペリエンスの提供を可能にします。 しかし、可観測性に関しては、常に改善の余地があります。
ServiceNow Cloud Observability (旧称 Lightstep) は、要求がサービスやその他のインフラストラクチャを通過するときにテレメトリデータ (トレース、ログ、測定基準) を取得する方法として OpenTelemetry をサポートしています。 Cloud Observability は、ネイティブの OpenTelemetry Protocol (OTLP) を介して OpenTelemetry データを取り込みます。 OTLP データは、HTTP または gRPC を介して Cloud Observability にエクスポートできます。
クラウドネイティブ環境での可観測性とガバナンスをさらに強化するため、ServiceNow は Service Graph Connector for OpenTelemetry (SGC) も立ち上げました。 このソリューションは、OpenTelemetry データと ServiceNow Cloud Observability バックエンドを活用して、企業が自社のクラウドネイティブアプリケーションと Kubernetes インフラストラクチャについての可視性とインサイトを得る方法に革命をもたらします。 SGC は、サービスの依存関係を自動的に検出してマッピングし、正確で最新のサービストポロジを作成します。 このソリューションは、組織が変更の影響を評価し、インシデント管理を簡素化し、部門横断的なコラボレーションを促進できるようにすることで、効率性を向上させ、リスクを軽減し、複雑な IT 環境で可能な限り最高の可観測性を確保するのに役立ちます。
Service Graph Connector for OpenTelemetry の革新的な機能をご体験ください。今すぐ ServiceNow にお問い合わせください。