分散トレーシングは、トレースデータを使用してアプリケーションのインフラストラクチャの複雑な動作を明らかにし、リクエストとトランザクションの細部に焦点を当てます。分散システム全体にわたるイベントの記録を統合することで、根本原因を診断し、パフォーマンスの異常を特定する上で非常に役に立ちます。しかし、その豊富な詳細情報は、最初は非常に貴重ですが、時間の経過とともにコストが増大し、費用対効果が減少するため、持続的な長期的な監視には課題をもたらします。

メトリクスは、時間の経過に伴うデータ集約により、システムの健全性とパフォーマンスの包括的なスナップショットが得られ、同時に長期にわたる監視コスト効率を大幅に向上させます。この変化は効率性を約束するだけでなく、システムダイナミクスに対する持続的でより広い視点を保証します。

トレースデータを、永続的で洞察力に富んだメトリクスに変換する機能を活用することを想像してみてください。これは、トレースによる即時の詳細な洞察と、メトリクスの長期的で集約された視点を組み合わせた変換です。

このブログ記事では、OpenTelemetryを使用してトレースをメトリクスに変換するプロセスをガイドし、トレースデータから長期にわたる価値あるメトリクスを取得する簡単な方法を説明します。

トレースとメトリクスの両方を使って、問題をより適切に解決する

コスト最適化

オブザーバビリティソリューションのコストは、使用するベンダーとインフラストラクチャの規模によって異なりますが、オブザーバビリティが高額になる可能性があることは周知の事実です。包括的なオブザーバビリティソリューションの場合、個々のリクエストとトランザクションがインフラストラクチャ内をどのように流れるかを理解するための分散トレーシング、システムの健全性とパフォーマンスを長期的に把握するためのメトリクス、システム内の特定のイベントやエラーに関する詳細なコンテキスト情報を提供するログが必要です。

トレースは非常に粒度が高く詳細であるため、処理と分析にかなりのストレージ容量と計算リソースを必要とします。このデータをメトリクスに集約することで、組織は保存および処理されるデータの量を大幅に削減でき、インフラストラクチャのコストを削減できます。


たとえば、7スパンで3,000トレースを取り込むと、0.0176GBの取り込みが生成されます。比較すると、同じ量のトレースに対してコレクターによって送信および変換されたメトリクスでは、取り込み量は0.0095GBのみになりました。つまり、変換されたメトリクスの取り込みが50%近く減少しています。このリポジトリを使用して、取り込みのベンチマークを試してみてください。

キャパシティプランニングとリソース割り当て

トレースデータを使用すると、ボトルネックを特定し、依存関係を理解することで、キャパシティプランニングに情報を提供できます。リソースが不足している可能性がある場所を特定し、ある領域の変更が他の領域にどのような影響を与えるかを予測できます。効果的な容量計画のために、メトリクスは使用傾向とリソース消費に関する非常に貴重なインサイトを提供し、拡張性とリソース割り当てに関する情報に基づいた意思決定を容易にします。この先見性は、コストを最適化し、システムが将来の需要に確実に対応できるようにします。

アラートと異常検知

メトリクスは、効率的なアラートシステムを設定する上で不可欠です。メトリクスデータに基づいて閾値を確立することで、異常や通常の動作からの逸脱をチームに即座に通知し、迅速な是正措置が可能になります。CPU使用率やレスポンスタイムの閾値を簡単に設定できます。トレースは非常に詳細で個々のリクエストに固有であるため、アラートのための効果的な説得値を作成するのは容易ではありません。

パフォーマンスのボトルネックの特定

トレースを使用すると、個々のトランザクションやリクエストを可視化できますが、大幅な集計と分析がなければ、全体的な使用パターンを把握することはできません。メトリクスは、詳細なビュー(サービスやコンテナ別のメトリクスなど)と集計ビュー(クラスタ全体の合計CPU使用率など)の両方を提供します。この柔軟性により、特定の懸念領域を掘り下げたり、システムの健全性の広範な概要を維持したりすることができます。

OpenTelemetryコレクターを介したトレースのメトリクスへの変換

OpenTelemetryは、トレース、メトリクス、ログを生成、収集、管理するためのツールキットを備えた堅牢なオープンソースのオブザーバビリティフレームワークです。フレームワークのコアコンポーネントは、これらのテレメトリータイプのデータパイプラインのオーケストレーションを簡素化する、多用途ツールであるOpenTelemetryコレクターです。コレクターなどのOTelエージェントを介してメトリクス、トレース、ログを収集した後、抽出、変換、ロード(ETL)パイプラインを介してデータを変換できます。各パイプラインは、レシーバー、プロセッサ、コネクター、エクスポーターという4つの主要コンポーネントで構成されます。今日は、スパンメトリクスプロセッサ、スパンメトリクスコネクター、およびスパンメトリクスコネクターがプロセッサに比べてどのような利点があるかについて説明します。

スパンメトリクスプロセッサ

スパンメトリクスプロセッサは当初、OpenTelemetryトレースのスパンデータからメトリクスを集計し、テレメトリーデータとメトリクス分析をブリッジするために考案されました。しかし、OpenTelemetryデータモデルとPrometheusメトリクスや属性の命名規則を組み合わせたその設計により、エクスポーターロジックに依存しない機能が誤って削除されてしまいました。このアプローチは、さまざまなツールやプラットフォーム間でテレメトリーデータを標準化するという、OpenTelemetryの中核的な使命と衝突することになりました。これらの課題を認識して、OpenTelemetryコミュニティはそれ以来、スパンメトリクスプロセッサを廃止し、スパンメトリクスコネクターを採用しました。

では、コネクターとは何でしょうか?

コネクターは、異なるコレクターパイプラインを接続することにより、それらの間でテレメトリーデータを送信する手段として機能します。コネクターは、あるパイプラインへのエクスポーターとして機能し、別のパイプラインへのレシーバーとして機能します。コネクターコンポーネントのもう1つの利点は、2つのテレメトリーパイプラインを結合することでコレクターの設定を簡素化できることです。プロセッサを使用する場合、2つのパイプラインで作業する場合は、レシーバーとエクスポーターを手動で設定する必要があります。

スパンメトリクスコネクター

スパンメトリクスコネクターは、スパンメトリクスプロセッサのポートであり、プロセッサで見つかった問題の一部を改善するために作成されました。改善点の一部は、OTelデータモデルに合わせて命名規則を変更することでした。OTel指数ヒストグラム、およびスパンリソーススコープの数に対応するメトリクスリソーススコープの生成をサポートします。つまり、より多くのメトリクスが生成されるようになりました。

コレクターの設定

スパンメトリクスコネクターの基本的な設定は非常に簡単です。以下に、スパンメトリクスコネクターをデモンストレーションするために作成したデモアプリケーションで使用した設定を示します。スパンメトリクスコネクター自体を設定したら、それをトレースパイプラインのエクスポーターとメトリクスパイプラインのレシーバーとして含める必要があります。この設定には、元のトレースデータと、そのデータから変換されたメトリクスの両方がオブザーバビリティバックエンド(ここではNew Relic)に送信されます。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  otlphttp:
    endpoint: https://otlp.nr-data.net:4318
headers:
      api-key: <set your api-key>
connectors:
  spanmetrics:
    histogram:
      explicit:
    dimensions: 
      - name: http.method
        default: "GET"
      - name: http.status_code
      
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp, spanmetrics]
    metrics:
      receivers: [spanmetrics]
      exporters: [otlphttp]

この設定の例はこちら

サンプリング

分散トレーシングを使用している場合は、何らかの形式のサンプリングを使用している可能性が高くなります。ヘッドサンプリング、テールサンプリング、またはその両方を使用しているかどうかに関係なく、このプロセスの価値を最大化する方法を理解することが重要です。

headベースサンプリングを使用したスパンメトリクスコネクターの実装

OpenTelemetryのデフォルトサンプラーは、2つのサンプラーの複合体です。ParentBasedサンプラーには、ルートスパンにどのサンプラーを使用するかを指定する必須パラメーターがあります。この場合、デフォルトはAlwaysOnサンプラーです。その名前が示すように、AlwaysOnサンプラーは常に親スパンを使用してスパンをサンプリングします。デフォルトでは、スパンメトリクスコネクターの使用時にコレクターに送信されたすべてのトレースからメトリクスを取得します。デフォルトのサンプラー設定を調整すると、サンプリングされたトレースデータから変換されたメトリクスの精度に影響します。すべてのトレースからメトリクスを取得し、なおかつトレースデータをサンプリングしたい場合は、確率的サンプリングプロセッサを実装できます。このプロセッサは、デフォルトで、traceIdハッシュに基づいた割合でトレースデータをサンプリングします。

この設定の例はこちら

テールベースサンプリングを使用したスパンメトリクスコネクターの実装

テールサンプリングでは、トレースのさまざまな部分から派生した特定の基準に基づいてトレースをサンプリングするオプションが提供されます。この手法を使用すると、すべてのトレースをメトリクスに変換し、興味があるトレースのみをサンプリングできます。この結果、コストを最大限に制御できますが、制御するとテールサンプリングの実装と操作が困難になります。提供されているデモでは、別のコネクターを使用します。フォワードコネクターは、あるパイプラインから別のパイプラインにデータを転送するために使用します。これにより、すべてのトレースからメトリクスを取得し、オブザーバビリティバックエンドにエクスポートする前に、サンプリングポリシーが適用される2番目のトレースパイプラインにメトリクスを転送できます。

この設定の例はこちら

まとめ

分散トレーシングのメトリクスへの変換は、オブザーバビリティと監視戦略を強化するための強力な方法を提供します。この実践により、テレメトリーデータをより効率的に管理する方法が提供されるだけでなく、組織が高レベルのシステムパフォーマンスと信頼性を維持できるようになります。このアプローチを採用すると、大幅なコスト削減とシステムパフォーマンスの理解が深まり、最終的にはサービス品質と顧客満足度が向上します。

オブザーバビリティ戦略に関しては、分散トレーシングとメトリクスの両方が重要な役割を果たします。これらの固有の長所と短所を活用する方法を学ぶことは、テレメトリーデータから最大限の価値を引き出すのに役立ちます。