OpenTelemetryメトリクスとは

OpenTelemetryログやトレースと同様に、OTelメトリクスは、共通の言語に依存しないデータモデルと、異なるソース、システム、および形式からデータを正確に取り込み、オブザーバビリティー・バックエンドに送信するための伝送プロトコルであるOpenTelemetry Protocol（OTLP）を使用する標準化されたテレメトリー・シグナルを提供します。

OTelメトリクスは、アプリケーションおよびインフラストラクチャー・コンポーネントの実行中に、CPU、メモリ使用量、スループット、エラー率、リクエスト数、および応答時間などの時系列データを収集するために、OpenTelemetryインストルメンテーションに依存します。開発者が必要なメトリクスを記録するためにコードをインストルメント化した後、OTelを使用すると、インストルメンテーションを変更することなく、それらのメトリクスを集約し、保存、クエリ、および視覚化のために任意の（またはすべての）オブザーバビリティー・バックエンド・ツールへエクスポートできます。

メトリクスは通常、システムの問題を最初に明らかにするテレメトリー・シグナルです。OTelフレームワークでは、メトリクスは、同じ概念とメタデータに依存するログ（個々のシステム・イベントの不変の記録）およびトレース（データ・リクエストのエンドツーエンドの経路）と統合されています。

これらの動作により、開発者とサイト信頼性エンジニア（SRE）は、メトリクスを高レベルの早期警告システムとして使用できます。開発者とサイト信頼性エンジニアは、障害の完全な経路（障害が発生したコンポーネントがやり取りした各サービスのメトリクスを含む）を一貫した1つのビューで追跡し、根本原因分析のためにトレースとログへすばやく切り替えることができます。

実際には、これは、ITチームが「このエンドポイントは遅い」から「問題はこれらの特定のリクエストと依存関係である」へ、わずか数回のクリックで移行できることを意味します。

さらに、OTelの標準化プロトコルにより、オブザーバビリティー・ベンダー間でのシグナルの自動相関付けが容易になり、企業は必要に応じてオブザーバビリティー・ツールを切り替えたり、複数のツールを同時に使用したりする柔軟性を得られます。

OpenTelemetryメトリクスは、OpenTelemetryの基本コンポーネントです。OpenTelemetryは、アプリケーション、システム、およびデバイスのインストルメンテーションのための、オープンソースのオブザーバビリティー・フレームワークであり、ソフトウェア開発キット（SDK）、ベンダー中立のアプリケーション・プログラミング・インターフェイス（API）、およびその他のツールのコレクションが含まれています。

インストルメンテーション・コードはさまざまであり、ネットワーク上のすべてのアプリとサービスからデータを収集できるツールを提供する単一の商用プロバイダーは存在しませんでした。この機能のギャップにより、チームが異なるプログラミング言語、形式、およびランタイム環境からデータを収集することは困難（多くの場合は不可能）でした。

また、従来のオブザーバビリティーのアプローチでは、バックエンド・インフラストラクチャーとコンポーネントの変更が、時間と労力がかかるプロセスになっていました。

たとえば、ある開発チームがバックエンド・ツールを切り替えたいとします。その場合、コードを完全に再インストルメント化し、新しいサーバーへテレメトリー・データを送信するために、新しいエージェント（自動化されたビルド・タスクとリリース・タスクを実行するソフトウェア・コンポーネント）を構成する必要があります。断片化されたアプローチにより、データ・サイロと混乱が生じ、パフォーマンスの問題を効果的に解決することが困難になりました。

OpenTelemetryは、テレメトリー・データの収集、分析、およびバックエンド・プラットフォームへの送信方法を標準化することで、観測可能性ツールにおいて重要な進歩をもたらしました。コミュニティー主導の標準に基づくオープンソースのソリューションを提供し、システムの動作とセキュリティーに関するデータを収集して、分散エコシステムにおけるモニタリングとオブザーバビリティーの効率化をチームが図れるようにしました。

OpenTelemetryメトリクスは、メトリクスの生成、記述、およびオブザーバビリティー・バックエンドへの送信方法をまとめて定義する、関連するコンポーネントのグループに依存しています。次のようなものが挙げられます。

Instrumentは、コードがメトリクス値を記録するために使用するツールです。値は、同期的（コードの実行中に、実行パス内で直接）と非同期的（SDKがコードに値を要求するたび）の2つの方法で記録されます。

同期Instrumentは操作とインラインで実行されるため、現在のトレースコンテキストとイベントに関する属性を取得でき、収集したメトリクスをログやトレースと関連付けやすくします。

非同期Instrumentは、SDKがあらかじめ定められた収集間隔で呼び出すプルベースのコールバック関数によって更新されます。これらのInstrumentは、各ユーザーリクエストごとではなく、定期的にサンプリングされる値（CPU使用率やメモリなど）を記録するのに役立ちます。

OTelインストルメンテーションは、アプリケーション・ロジックとメトリクス・パイプラインの間に位置し、「HTTPリクエストが完了した」などのイベントを、SDKが集約してエクスポートできる構造化された測定値に変換します。メトリクスInstrumentの各種類は、特定の測定パターン向けに最適化されており、SDKが個々の測定値をどのように組み合わせてエクスポートされるメトリクスにするかを記述する、対応する集約ストラテジーを備えています。

一般的なInstrumentの種類は次のとおりです。

• Counterは、時間の経過とともに増加する増分（プロセス開始以降のリクエスト総数や送信バイト総数など）を記録する同期Instrumentです。Counterは単調増加でもあるため、新しい測定値を記録するたびに、既存の値を置き換えるのではなく、既存の値に加算します。

• UpDown Counterは、時間の経過とともに増加または減少する値（アクティブ・ユーザー数やキュー・サイズなど）を記録する同期Instrumentです。標準のCounterとは異なり、UpDown Counterは非単調であるため、既存の値を置き換えることで合計値を増減します。

• 非同期Counterと非同期UpDown Counterは、対応する同期Instrumentと似ていますが、コードの実行中に値を収集する代わりに、エクスポートごとに1回値を記録します。

• Gaugeは、データがプッシュされるたびに任意に増減する値を記録する同期Instrumentであり、コードから収集された時点の値を表します。同期Gaugeに加えて、メトリクスの収集にはObservable Gaugeが必要です。これは、メトリクス・バックエンドがデータを収集するたびに現在の値をプルする非同期Instrumentです。
  
  Gaugeは、カメラが撮影対象のスナップショットを撮影するのとほぼ同じ方法で、値のスナップショットを取得します。また、Gaugeは累積型ではないため、通常は、合計しても意味をなさない非加算値（メモリ使用量や温度など）に適用されます。

• Histogramは、単一の数値（合計値や現在値など）を追跡する代わりに、測定値が異なる値の範囲にいくつ入るかを取得する同期Instrumentです。Histogramは、値を「バケット」に分類することで、ITチームがパーセンタイルを計算し、リクエスト期間、レイテンシー、およびペイロード・サイズなどのメトリクスの値の分布を把握できるようにします。

OTelは、個々のメトリクス・イベントを、ITチームが可観測性プラットフォームに保存して分析できる、照会可能で時系列の整理された数値列に変換する、標準化されたメトリクス・データ・モデルと時系列を定義しています。

OpenTelemetryは、3つの関連するモデルを使用してメトリクスを記述します。すなわち、Eventモデル（Instrumentからの生の測定値）、OTLPストリーム・モデル（それらの測定値がどのようにまとめられて送信されるか）、および時系列モデル（バックエンドがそれらをどのように保存するか）です。

実際には、アプリケーション・コードはEventモデルを使用してイベントを記録し、SDK/CollectorはそれらをOTLPストリームに変換し、バックエンド・プラットフォームは「サービスXのステータス200の1秒当たりのリクエスト数」のような時系列として、それらを時間の経過にわたって保存します。

セマンティック規則（命名規則とも呼ばれます）は、異なるサービスやライブラリが一貫したテレメトリーを生成できるように、一般的なメトリクスの標準化された名前、単位、および属性キーを定義します。たとえば、規則では、HTTP Serverのリクエスト・レイテンシーにはhttp.server.durationのような名前を規定し、期間には秒やミリ秒などの単位を推奨しています。

OTelのセマンティック規則を使用すると、チームは、特定のスキーマを前提とする事前構築済みのダッシュボードやアラート・システムにメトリクスを組み込むことができ、カスタム構成作業に費やす時間を削減できます。また、マイクロサービス全体で全員が同じ「メトリクス言語」を使用するため、チーム間のコラボレーションも容易になります。

さらに、コンテキスト伝播機能では、トレースIDやスパンIDなどの共有コンテキストをサービス境界を越えて引き継ぐことにより、メトリクスを、関連するトレース（エグザンプラーを使用）やログと関連付けることができます。

たとえば、OTelプロパゲーターは、リクエスト・ハンドラーから受信コンテキストを抽出し、それを使用してトレース・スパンを開始し、同じコンテキストを使用してレイテンシ－・メトリクスを記録し、ログ・エントリーを書き込むことができます。これにより、メトリクス・ポイントとログ行の両方に現在のトレースがタグ付けされます。

アプリ・コードがダウンストリーム呼び出しを行うと、プロパゲーターは同じコンテキストを送信リクエストに挿入します。コードはそのコンテキストを抽出し、独自の子スパンを開始して、そのコンテキストを独自のメトリクスとログに使用します。これにより、両方のサービスのすべてが同じエンドツーエンドのトレースに関連付けられたままになります。

属性（ラベル、タグ、またはディメンションとも呼ばれます）は、個々の測定値または集約されたデータポイントに付加されるキーと値のペアです。属性は、メトリクス名、集約タイプ、および単位とともに、時系列を完全または部分的に定義します。属性がなければ、メトリクスのすべての測定値は区別のない1つの時系列にまとめられます。

属性（サービス名、エンドポイント、HTTPステータス・コード、リージョン、テナントIDなど）を追加すると、単純なメトリクスは、チームが可観測性ツールでさまざまな切り口から分析できる、多次元の専用メトリクスストリームになります。チームは、任意に選択したディメンションでフィルター処理またはグループ化された高解像度ビューを取得できます。

適切な属性設計では、詳細さとメトリクスのカーディナリティー（属性が取り得る一意の値の数）のバランスも取るため、チームはラベルの爆発を回避しながら、有用なクエリを実行できます。

測定値は、特定の時点でInstrumentによって取得される単一のイベント・レベルの測定値であり、多くの場合、属性が伴います。たとえば、あるHTTPリクエストが完了したとき、ルートとステータス・コードを表すroute="/login"やstatus_code=200などの属性とともに、120ミリ秒のレイテンシーを記録できます。

個々の記録はそれぞれ、その1回の操作中に何が起こったかを表す個別の測定値です。

測定値はSDK内に一時的に保存され、その後、SDKによって生の測定値はより大きなメトリクスストリーム内のデータ・ポイントに変換されます。個々のリクエストをすべて表示する代わりに、集約されたデータポイントには、「ルート/login、ステータス200については、10:00:00～10:00:10の間に、合計継続時間25秒のリクエストが500件ありました」と表示される場合があります。最終的にオブザーバビリティー・バックエンドにエクスポートされ、保管されるのはこれらのデータ・ポイントです。

OpenTelemetryメトリクスAPIは、アプリケーション・コードがメトリクスを生成するために呼び出す一連のインターフェースです。これはベンダーに依存しないように設計されており、インストルメンテーションを具体的なSDK実装から切り離します。ITチームは、インストルメンテーションを一度（標準APIを使用して）記述すれば、追加の手順を実行することなく、SDK、エクスポーター、およびバックエンドを切り替えることができます。

OTelメトリクスAPIは、Meter Provider、Meter、およびメトリクスInstrumentという3つの中核インターフェイスで構成されています。

Meter Providerは、APIのエントリ－・ポイントであり、Meterインスタンスの作成を担当します。メトリクス・リーダーとエクスポーターの使用対象、適用するビューと集約、およびデータを収集してエクスポートする頻度を決定します。Meter Providerは通常、アプリケーションの起動時に1回だけロードされ（多くの場合はグローバル・プロバイダーとして）、すべてのMeterとInstrumentが一貫したリソース定義とエクスポート・パイプラインを共有します。

Meterは、アプリケーション・コードがCounter、Histogram、およびGaugeを作成するために使用するオブジェクトです。各Meterには通常、ライブラリまたはサービスの名前（たとえば、"bank.payment"）が付けられます。これにより、そのコードから生成されるメトリクスを一貫してグループ化し、識別できます。

Meter自体はデータを保存しません。代わりに、Instrumentのファクトリーとして機能し、記録された測定値を集約とエクスポートのために基盤となるSDKへ渡します。MeterはMeter Providerから取得されるため、常にProviderによって定義された構成、ビュー、およびExporterを使用して動作します。

Instrumentは、コードが属性を含む測定値を報告できるようにするための指示を提供します。

OpenTelemetry SDKは、API呼び出しを実際のテレメトリ－・データ・ポイントに変換するOpenTelemetry APIの具体的な実装です。メトリクス・データを収集、集約し、エクスポート用に準備する、言語固有のライブラリ（Java™やPythonなど）を提供します。

SDKは、インストルメンテーションのライフサイクルを管理し、測定値のインメモリ・ストレージを処理し、非同期Instrumentのコールバックを実行し、構成済みの集約とビューを適用し、メトリクスの収集間隔（通常は10～60秒）を制御します。

SDK内では、プロセッサーが、集約や、フィルタリング、レート制限、またはメトリクス・ストリームの変換などの追加のロジックを適用してから、それらを次へ送信します。

Exporterは、処理済みのメトリクス・データ・ポイントをバックエンド固有の形式に変換し、サポートされているプロトコル（OTLPなど）を使用して、外部バックエンドまたは可観測性プラットフォームへ送信します。

チームは、高可用性と冗長性が求められる環境で複数のバックエンドをサポートするために、SDK内で複数のExporterを連結して使用することがあります。このような場合、OpenTelemetry Collectorは、メトリクスを複数のバックエンドへ同時に送信したり、エクスポートを再試行したり、大規模にデータを認証したりできるスマート・プロキシとして機能します。

集約は、生の個々の測定値を、バックエンドが時系列データ・ポイントとして保存およびクエリする要約統計に数学的に結合する方法を定義します。未加工データは、SDKのアグリゲーターによって、一意の時系列ごとに、収集間隔ごとに1つのデータポイントへ集約されます。

一般的な集約パターンは次のとおりです。

• Sum。累積量（転送されたバイト数など）のすべての値を合計します。

• LastValue。最新の測定値のみを保持し、それ以前の測定値は破棄します。

• Histogram aggregation。値をバケットにグループ化し、チームがパーセンタイルを計算して外れ値を検出できるようにします。

• Drop。高カーディナリティデータ（一意の値の数が多いデータ）から保護するために、すべての値を破棄します。

集約には時間特性メタデータも含まれ、バックエンドに対して、メトリクス値を時間の経過にわたってどのように解釈するかを伝えます。主な種類は次の2つです。

• 累積値は、プロセスの開始以降の合計値を表します。これらの値はプロセスが再起動する場合にのみリセットされ、バックエンドはデータ・ポイントを差分してレートを計算します。

• デルタ値は、前回のデータ収集以降の変化を表します。バックエンドは、デルタ値を直接合計してレートを算出できます。

SDKは、Instrumentの種類に基づいて適切な集約を自動的に適用します。また、インストルメンテーションを変更することなく、単純な合計から、より詳細なHistogramやその他のアルゴリズムへ切り替えることもできます。

メトリクスは傾向を示してアラートを送信し、トレースはリクエストの経路を明らかにし、ログは豊富なイベントレベルのコンテキストを提供します。メトリクスをトレースおよびログと関連付けることで、3つの主要なオブザーバビリティー・シグナル（「オブザーバビリティー性の柱」と呼ばれます）が結び付けられ、チームはシステム動作を階層的に把握できます。

たとえば、メトリクスは「午後2時15分にエラー率が急上昇した」のような集約された傾向を示すことはできますが、どのリクエストが失敗したのか、またその理由までは明らかにできません。トレースは、サービス間の問題のある個々のリクエスト経路を明らかにしますが、メトリクスがなければ、不正なリクエストが外れ値なのか、それともシステム全体の問題なのかをチームが判断することはできません。ログは詳細なエラー・メッセージとイベントを提供しますが、コンテキストがなければ単なるノイズです。

3つすべてのシグナルを関連付けることで、ITチームは、高レベルのメトリクスの傾向から、影響を受けたトレースや関連するログへ数秒でシームレスに移行できます。

OTelメトリクスは、従来のメトリクスとは根本的に異なります。従来のメトリクスは通常、リソース使用量について、単純で事前定義されたCounterに重点を置く従来のモニタリング・アプローチを指します。これらのメトリクスは、ホスト・レベルまたはアプリケーション固有の測定値を重視します。

これに対して、OpenTelemetryメトリクスは、分散IT環境におけるトレース、ログ、およびメトリクス全体での収集を標準化する、統合されたベンダーに依存しないオブザーバビリティー・フレームワークの一部を構成します。OpenTelemetryメトリクスは、双方向の変化に対応するUpDownCounterや指数バケットをサポートするHistogramなど、より柔軟なデータ・モデルとインストルメンテーションを提供することで、従来のメトリクスを拡張しています。また、メトリクスを充実させるための明示的な属性、単位、およびタイムスタンプも提供します。

OTelメトリクスは、その設計、収集方法、および最新システムへの適用性の点でも、従来のメトリクスとは異なります。

従来のメトリクスは、収集、保存、およびクエリーを密接に結び付ける硬直的なフルスタックモデルを採用しており、多くの場合、基本的なCounter、Gauge、Summary、および明示的なバケット（手動でのバケット化が必要）を使用するHistogramの累積値のみを使用します。

OpenTelemetryメトリクスは、シグナルの生成を処理およびエクスポートから分離する、API、SDK、およびプロトコルで構成されるモジュール式の3層設計を採用しています。この構成により、OTelメトリクスは、Delta temporality、整数値、Histogramの最小値および最大値のメタデータ、ならびに動的なスケーリングのためのExponential Histogramなどの高度な機能をサポートできます。

従来のアプローチは、主に独立したメトリクスを対象として、公開されたAPIエンドポイントからのプルベースのデータ・スクレイピングに依存しています。これらは手動のインストルメンテーションを使用し、トレースやログのサポートは限定的であるため、テレメトリーとオブザーバビリティーのパイプラインが断片化します。

OpenTelemetryは、プッシュベースのデータ収集にOTLP（バイナリプロトコル）を使用し、自動および手動のインストルメンテーションを通じて、トレース、メトリクス、およびログを統合的に収集できるようにします。OTelは、データの変換、バッチ処理、およびバックエンド・ツールへのルーティングを容易にするCollectorも提供しており、これによりITチームはアプリケーション・ストレージに関する懸念に対処できます。

従来のテレメトリー・データは、シンプルなモノリシック構成では適切に機能します。しかし、マイクロサービス環境では、トレース機能の不足、ベンダー・ロックインの問題、および依存関係を見えにくくし、連鎖的な障害を明らかにできないサイロ化されたシグナルのため、十分に機能しません。

OpenTelemetryは、サービス間のリクエストフロー、レイテンシーのボトルネック、およびリソース診断をエンドツーエンドで可視化するための、相関付けされたベンダーに依存しないテレメトリーを提供するため、クラウドネイティブの分散環境で優れた効果を発揮します。OTelは、サンプリングとハイブリッド・ツールの統合もサポートしており、これによりテレメトリーとインストルメンテーションをIT環境に合わせて拡張できます。

OpenTelemetryメトリクスは、最新のアーキテクチャーにおけるオブザーバビリティーの向上に役立つ、標準化された定量的な測定値を提供します。システム・パフォーマンスに関する詳細な分析情報を提供し、開発者やエンジニアがプロアクティブな問題解決と最適化の戦略を実施できるようにします。

その他の主なメリットは次のとおりです。