Sentry モニタリング - 分散トレース

[[427023]]

この記事はWeChatの公開アカウント「Hacker Afternoon Tea」から転載したもので、著者はShaoです。この記事を転載する場合は、Hacker Afternoon Tea公式アカウントまでご連絡ください。

目次

• 追跡とは何ですか?
  • なぜ追跡するのですか?
  • トレース、トランザクション、スパン
  • 例: ページの読み込みが遅い場合の調査
  • その他の例
  • 追跡データモデル
  • 詳細情報
• データサンプリング
  • 追跡の一貫性

分散トレースは、ソフトウェア システム間の相互作用をキャプチャすることにより、関連するエラーとトランザクションの接続されたビューを提供します。 Sentry はトレースを通じてソフトウェアのパフォーマンスを追跡し、複数のシステムにわたるエラーの影響を表示できます。トレースバックの問題を提供して、フロントエンドをバックエンドに接続します。

• https://docs.sentry.io/product/sentry-basics/tracing/distributed-tracing/

パフォーマンス モニタリングを有効にして、既存のエラー データを拡張し、フロントエンドからバックエンドまでのインタラクションを追跡します。トレースを使用すると、Sentry はソフトウェアのパフォーマンスを追跡し、スループットやレイテンシなどのメトリックを測定し、複数のシステムにわたるエラーの影響を表示できます。トレースにより、Sentry はより完全な監視ソリューションとなり、問題をより迅速に診断し、アプリケーションの全体的な健全性を測定できるようになります。 Sentry でのトレースにより、次の情報が得られます。

• 特定のエラー イベントまたは問題に何が起こりましたか?
• アプリケーションのボトルネックや遅延の問題を引き起こす条件
• 最も時間を消費するエンドポイントまたは操作

追跡とは何ですか?

まず、追跡とは何かについて注意が必要です。追跡は分析ではありません。プロファイリングとトレースの目的にはかなりの重複があり、どちらもアプリケーションの問題を診断するために使用できますが、測定対象とデータの記録方法は異なります。

プロファイラーは、実行された命令の数、さまざまなプロセスで使用されるメモリの量、特定の関数呼び出しにかかる時間など、アプリケーションの操作のさまざまな側面を測定できます。結果として得られるプロファイルは、これらの測定値の統計的な要約です。

• https://en.wikipedia.org/wiki/Profiling_(コンピュータープログラミング)

一方、トレース ツールは、発生した回数や発生した時間ではなく、何が (いつ) 発生したかに重点を置いています。結果として得られるトレースは、多くの場合複数のシステムにわたってプログラムの実行中に発生するイベントのログです。ほとんどの場合、トレースにはタイムスタンプが含まれており、期間を計算できますが (Sentry のトレースの場合は常に)、パフォーマンスの測定だけがトレースの目的ではありません。また、相互接続されたシステムがどのように相互作用するか、また、あるシステムの問題が別のシステムの問題を引き起こす可能性があるかを示すこともできます。

• https://en.wikipedia.org/wiki/Tracing_(ソフトウェア)

なぜ追跡するのですか?

アプリケーションは通常、サービスとも呼ばれる相互接続されたコンポーネントで構成されます。例として、ネットワーク境界で分離された次のコンポーネントで構成される最新の Web アプリケーションを見てみましょう。

• フロントエンド（シングルページアプリケーション）フロントエンド
• バックエンド (REST API)
• タスクキュー
• データベースサーバー
• Cronジョブスケジューラ

これらの各コンポーネントは、異なるプラットフォーム上で異なる言語で記述できます。 Sentry SDK を使用してそれぞれを個別に計測し、エラー データやクラッシュ レポートをキャプチャできますが、各部分が個別に考慮されるため、この計測では完全な画像が得られません。追跡により、すべてのデータを結び付けることができます。

サンプル Web アプリケーションでは、トレースとは、フロントエンドからバックエンドへ、そしてその逆方向へのリクエストを追跡し、リクエストによって作成されたバックグラウンド タスクまたは通知ジョブからデータを抽出できることを意味します。これにより、Sentry エラー レポートを相関させて、あるサービスのエラーが別のサービスにどのように伝播するかを確認できるだけでなく、どのサービスがアプリケーションの全体的なパフォーマンスに悪影響を与えている可能性があるかについて、より深い洞察が得られます。

アプリケーションでトレースを有効にする方法を学習する前に、いくつかの重要な用語とそれらの相互関係を理解し​​ておくと役立ちます。

トレース、トランザクション、スパン

トレースは、ページの読み込み、アプリケーション内でユーザーが何らかのアクションを完了したインスタンス、バックエンドの cron ジョブなど、測定または追跡する操作全体の記録を表します。トレースに、上記のサービスなど、複数のサービスにわたる作業が含まれる場合、トレースがこれらのサービス全体に分散されるため、分散トレースと呼ばれます。

各トレースは、トランザクションと呼ばれる 1 つ以上のツリー構造で構成され、そのノードはスパンと呼ばれます。ほとんどの場合、各トランザクションは呼び出されたサービスの単一のインスタンスを表し、そのトランザクション内の各スパンはそのサービス内で関数を呼び出すか、別のサービスを呼び出すかに関係なく、そのサービスによる単一の作業単位の実行を表します。以下は、トランザクションとスパンに分割されたサンプル トレースです。

トランザクションはツリー構造になっているため、最上位レベルのスパンは、関数が他の多くの小さな関数を呼び出す方法を反映して、より小さなスパンに分解できます。これは親子メタファーを使用して表現され、各スパンは複数の他の子スパンの親になることができます。さらに、すべてのツリーにはルートが必要なため、各トランザクション内の 1 つのスパンは常にトランザクション自体を表し、トランザクション内の他のすべてのスパンはこのルート スパンから派生します。以下は、上の画像のトランザクションの 1 つを拡大したビューです。

これをより具体的に理解するために、サンプルの Web アプリケーションをもう一度考えてみましょう。

例: ページの読み込みが遅い場合の調査

たとえば、Web アプリケーションの読み込みが遅く、その理由を知りたいとします。そもそも、アプリケーションを使用可能な状態にするには、バックエンドへの複数のリクエスト、応答が返される前のデータベースや外部 API への呼び出しなどの作業、返されたすべてのデータをユーザーにとって意味のあるものにレンダリングするためのブラウザーによる処理など、多くのことを行う必要があります。では、プロセスのどの部分が速度を低下させるのでしょうか?

この簡略化された例では、ユーザーがブラウザでアプリケーションを読み込むと、各サービスで次のことが起こると想定します。

• ブラウザ
  • HTML、CSS、JavaScript それぞれに 1 つのリクエスト
  • 1 つのレンダリング タスクが 2 つの JSON データ リクエストをトリガーします^
• バックエンド
  • 静的ファイル（HTML、CSS、JS）を提供するための 3 つのリクエスト
  • 2 つの JSON データ要求 - 1 つはデータベースを呼び出す必要があります - 1 つは外部 API を呼び出して結果を処理してからフロントエンドに返す必要があります^
• データベースサーバー
  • 1 認証を確認するためのクエリ
  • 1 データを取得するためのクエリ
  • 1 つのリクエストには 2 つのクエリが必要です

注: 外部 API は外部であるため、内部を確認できないため、正確にはリストされません。

この例では、ページ読み込みプロセス全体 (上記のすべてを含む) が 1 つのトレースで表されます。トレースは次のトランザクションで構成されます。

• 1 回のブラウザ トランザクション (ページの読み込み用)
• 5 つのバックエンド トランザクション (リクエストごとに 1 つ)
• 1 つのデータベース サーバー トランザクション (単一の DB 要求に対して)

各トランザクションは、次のようにスパンに分割されます。

• ブラウザページ読み込みトランザクション: 7スパン
  • 2 つの子スパン (JSON リクエストごとに 1 つ)
  • 1つのルートスパンはページ全体の読み込みを表します
  • HTML、CSS、JS それぞれ 1 つのリクエスト (合計 3 つ)
  • レンダリングタスクの1スパン。これには以下が含まれます。

ここで重要な点を指摘しておきます。ここにリストされているブラウザ トランザクションのスパンの一部 (すべてではありません) は、前にリストされているバックエンド トランザクションと直接対応しています。具体的には、ブラウザ トランザクション内の各リクエスト スパンは、バックエンド内の個別のリクエスト トランザクションに対応します。この場合、あるサービスのスパンが後続のサービスのトランザクションを引き起こす場合、元のスパンをトランザクションの親スパンおよびそのルート スパンと呼びます。下の図では、波線がこの親子関係を表しています。

この例では、最初のブラウザ ページ読み込みトランザクションを除くすべてのトランザクションは、別のサービスのスパンの子です。つまり、ブラウザ トランザクション ルートを除くすべてのルート スパンには、親スパンがあります (ただし、別のサービス内です)。

完全にインストルメント化されたシステム (すべてのサービスでトレースが有効になっているシステム) では、このパターンが常に適用されます。親のないスパンは、最初のトランザクションのルートのみになります。他のすべてのスパンには親が存在します。さらに、親と子は常に同じサービス内に存在します。ただし、子スパンが子トランザクションのルートである場合は、親スパンは呼び出し元サービス内に存在し、子トランザクション/子ルート スパンは呼び出されたサービス内に存在することになります。

言い換えると、完全にインストルメント化されたシステムは、それ自体が接続されたツリーであるトレースを作成します。各トランザクションはサブツリーであり、サブツリー/トランザクション間の境界は、まさにサービス間の境界です。上の図は、この例の完全なトレース ツリーのブランチを示しています。

さて、完全を期すために、スパンに戻りましょう。

• バックエンド HTML/CSS/JS リクエストトランザクション: それぞれ 1 スパン
  • リクエスト全体を表す 1 つのルート スパン (ブラウザ スパンの子)^
• データベース呼び出しトランザクションを含むバックエンド要求: 2 スパン
  • リクエスト全体を表す 1 つのルート スパン (ブラウザ スパンの子)
  • データベースを照会するための 1 つのスパン (データベース サーバー トランザクションの親)^
• API 呼び出しトランザクションを含むバックエンド リクエスト: 3 スパン
  • リクエスト全体を表す 1 つのルート スパン (ブラウザ スパンの子)
  • API リクエスト用の 1 つのスパン (データベース呼び出しとは異なり、API は外部であるため、これは親スパンではありません)
  • APIデータを処理するための1つのスパン^
• データベースサーバ要求トランザクション: 3スパン
  • リクエスト全体を表す 1 つのルート スパン (上記のバックエンド スパンの子)
  • 1 つのスパンは認証クエリに使用されます
  • 取得したデータをクエリするための 1 つのスパン

この例を要約すると、すべてのサービスをインストルメント化した後、何らかの理由で、データベース サーバー内の認証クエリが速度低下の原因であり、ページ読み込みプロセス全体の完了にかかる時間の半分以上を占めていることが分かる場合があります。追跡してもなぜこのようなことが起こったのかはわかりませんが、少なくともどこを調べればよいかはわかりました。

その他の例

このセクションには、トランザクションとスパンに分かれた、さらに多くのトレースの例が含まれています。

特定のユーザーアクションの測定

アプリケーションに電子商取引が含まれる場合は、支払い処理業者への料金の送信や注文確認メールの送信の追跡を含め、ユーザーが「注文を送信」をクリックしてから注文確認が表示されるまでの時間を測定することをお勧めします。プロセス全体がトレースであり、通常は次のトランザクション (T) とスパン (S) があります。

• ブラウザプロセス全体（TとルートスパンS）
  • バックエンドへのXHRリクエスト* (S)
  • レンダリング確認画面(S)^
• バックエンドのリクエスト処理（T およびルートスパン S）
  • 関数呼び出しの合計回数を計算する（S）
  • 店舗注文データベース（DB）呼び出し*（S）
  • 支払い処理業者への API 呼び出し
  • メール確認キュー* (S) ^
• データベースは顧客の注文履歴を更新します（TおよびルートスパンS）
  • 単一のSQLクエリ^
• 電子メールを送信するためのキューに入れられたタスク (T およびルート スパン S)
  • 電子メールテンプレートに入力するために使用される関数呼び出し
  • メール送信サービスへのAPI呼び出し(S)

注: アスタリスクの付いたスパンは、後続のトランザクション (およびそのルート スパン) の親であるスパンを示します。

バックグラウンドプロセスの監視

バックエンドが定期的に外部サービスにデータをポーリングし、それを処理し、キャッシュしてから内部サービスに転送する場合、この発生の各インスタンスがトレースとなり、通常は次のトランザクション (T) とスパン (S) が発生します。

• プロセス全体を完了する cron ジョブ (T およびルート スパンの S)
  • 外部サービスへのAPI呼び出し(S)
  • 処理機能(S)
  • コールキャッシュサービス* (S)
  • 内部サービスへのAPI呼び出し* (S) ^
• キャッシュ サービスで行われた作業 (T およびルート スパン S)
  • キャッシュ内の既存データを確認する(S)
  • 新しいデータをキャッシュに保存する(S) ^
• 内部サービスによるリクエストの処理 (T およびルートスパン S)
  • サービスがリクエストを処理するために行う可能性のあるあらゆること

注: アスタリスクの付いたスパンは、後続のトランザクション (およびそのルート スパン) の親であるスパンを示します。

追跡データモデル

「フローチャートを見せて、表を隠しても、私はまだ混乱します。表を見せれば、フローチャートは不要になります。あまりにも明白だからです。」

フレッド・ブルックス『神話の人月』

理論は興味深いものですが、最終的には、あらゆるデータ構造はそこに含まれるデータのタイプによって定義され、データ構造間の関係はそれらの間のリンクがどのように記録されるかによって定義されます。トレース、トランザクション、スパンも例外ではありません。

痕跡

痕跡はそれ自体では実体ではありません。代わりに、トレースは、trace_id 値を共有するすべてのトランザクションのコレクションとして定義されます。

取引

トランザクションは、そのプロパティのほとんど (開始時間と終了時間、タグなど) をルート スパンと共有するため、以下で説明するスパンの同じオプションがトランザクションでも使用でき、どちらの場所で設定しても同じです。

トランザクションには、スパンに含まれていない transaction_name という追加のプロパティがあり、UI でトランザクションを識別するために使用されます。 transaction_name値の一般的な例としては、バックエンドがトランザクションを要求するエンドポイントパス（/store/checkout/やapi/v2/users/など）が挙げられます。 /)、cron ジョブ トランザクションのタスク名 (data.cleanup.delete_inactive_users など)、およびページ読み込みトランザクションの URL (https://docs.sentry.io/performance-monitoring/distributed-tracing/ など) が含まれます。

スパン

トランザクション内のデータのほとんどは、トランザクション内に含まれる単一のスパンに存在します。スパン データには以下が含まれます。

• parent_span_id: スパンをその親スパンに関連付けます
• op: スパンが測定している操作の種類またはカテゴリを識別する短い文字列
• start_timestamp: スパンのオープン時
• end_timestamp: スパンが閉じられたとき
• 説明: スパンを一意に識別し、スパンインスタンス間で一貫性を保つスパン操作のより長い説明 (オプション)
• ステータス: 操作のステータスを示す短いコード (オプション)
• tags: スパンに関する追加データを保持するキーと値のペア (オプション)
• データ: スパンに関する任意の構造の追加データ (オプション)

op 属性と description 属性を一緒に使用する例は、op: sql.query と description: SELECT * FROM users WHERE last_active < %s です。ステータス属性は通常、スパン操作の成功または失敗、または HTTP 要求の場合は応答コードを示すために使用されます。最後に、タグとデータを使用すると、関数呼び出しの function: middleware.auth.is_authenticated や、HTTP リクエストの request: {url: ..., headers: ..., body: ...} など、より多くのコンテキスト情報をスパンに添付できます。

詳細情報

トレース、トランザクション、スパンとそれらの相互関係に関する重要なポイントをいくつか示します。

トレース期間

トレースは単なるトランザクションの集合であるため、トレースには独自の開始時間と終了時間はありません。代わりに、トレースはその最も古いトランザクションの開始時に始まり、最新のトランザクションの終了時に終了します。したがって、トレースを明示的に直接開始または終了することはできません。代わりに、そのトレースの最初のトランザクションを作成してトレースを作成し、そこに含まれるすべてのトランザクションを完了してトレースを完了します。

非同期トランザクション

非同期処理の可能性があるため、子トランザクションは、親スパンを含むトランザクションよりも何桁も長く存続する可能性があります。たとえば、バックエンド API 呼び出しによって長時間実行される処理タスクが開始され、すぐに応答が返される場合、バックエンド トランザクションは非同期タスク トランザクションが完了するずっと前に完了します (そのデータは Sentry に送信されます)。非同期性とは、トランザクションが Sentry に送信される順序 (および Sentry から受信される順序) が、トランザクションが作成された順序とは関係がないことも意味します。 (対照的に、同じトレースのトランザクションが受信される順序は、それらが完了するときの順序と相関しますが、転送時間の変動などの要因により、相関は完全にはほど遠いものです。)

孤立したトランザクション

理論上、完全にインストルメント化されたシステムでは、各トレースに 1 つのトランザクションと 1 つのスパン (トランザクションのルート) のみが含まれ、親、つまり元のサービス内のトランザクションは含まれません。ただし、実際には、すべてのサービスでトレースを有効にできない場合や、ネットワークの停止やその他の予期しない状況により、インストルメント化されたサービスがトランザクションを報告できない場合があります。このような状況が発生すると、追跡階層にギャップが生じる可能性があります。具体的には、親スパンが既知のトランザクションの一部としてまだ記録されていないスパンの途中でトランザクションが表示される場合があります。このような開始されていない親のないトランザクションは、孤立トランザクションと呼ばれます。

ネストされたスパン

上記の例では階層に 4 つのレベル (トレース、トランザクション、スパン、子スパン) がありますが、スパンをネストできる深さに制限はありません。ただし、実際的な制限があります。Sentry に送信されるトランザクション ペイロードには最大許容サイズがあり、あらゆる種類のログ記録と同様に、データの粒度とその可用性の間でバランスを取る必要があります。

ゼロ期間スパン

スパンの開始時間と終了時間が同じである場合、時間がかからないものとして記録されます。これは、スパンがマーカーとして使用されているため (ブラウザのパフォーマンス API で行われるような)、または操作にかかった時間が測定解像度よりも短かったため (サービスによって異なります) である可能性があります。

https://developer.mozilla.org/en-US/docs/Web/API/Performance/mark

クロックスキュー

複数のマシンからトランザクションを収集する場合、あるトランザクションのタイムスタンプが別のトランザクションのタイムスタンプと一致しないクロック スキューが発生する可能性があります。たとえば、バックエンドがデータベース呼び出しを行う場合、バックエンド トランザクションは論理的にデータベース トランザクションの前に開始する必要があります。ただし、各マシン (それぞれバックエンドとデータベースをホストしているマシン) のシステム時間が共通の標準に同期されていない場合は、この限りではありません。順序は正しいものの、2 つのレコードの時間範囲が実際に発生したことを正確に反映するような配置になっていない可能性もあります。この可能性を減らすには、ネットワーク タイム プロトコル (NTP) またはクラウド プロバイダーのクロック同期サービスを使用することをお勧めします。

データの送信方法

個々のスパンは Sentry に送信されません。代わりに、トランザクション全体が 1 つの単位として送信されます。つまり、Sentry サーバーは、スパン データが属するトランザクションが終了してディスパッチされるまで、スパン データを記録しません。ただし、その逆は当てはまりません。スパンはトランザクションなしでは送信できませんが、トランザクションは依然として有効であり、含まれているスパンがルート スパンのみであっても送信されます。

データサンプリング

追跡設定でサンプリングを有効にすると、収集されたトランザクションのうち Sentry に送信するトランザクションの割合を選択できます。たとえば、1 分あたり 1,000 件のリクエストを受信するエンドポイントがある場合、サンプリング レートが 0.25 の場合、1 分あたり約 250 件のトランザクション (25%) が Sentry に送信されます。 (この数値は概算です。各リクエストは独立して、確率 25% で疑似ランダムにトレースされるかトレースされないかのいずれかになります。したがって、100 枚の公平なコインを投げたときに約 50 回表が出るのと同じように、SDK は約 250 のケースでトレースを収集することを「決定」します。) サンプリング率がわかっているため、合計トラフィックを推測できます。

トレースを収集する場合、次の 2 つの理由からデータをサンプリングすることをお勧めします。まず、単一のトレースをキャプチャする場合のオーバーヘッドは最小限ですが、ページの読み込みや API リクエストごとにトレースをキャプチャすると、システムに望ましくない量の負荷がかかる可能性があります。 2 番目に、サンプリングを有効にすると、Sentry に送信されるイベントの量をより適切に管理できるため、組織のニーズに合わせて調整できます。

サンプリング レートを選択する際の目標は、(上記の理由により) 過剰なデータを集めることではなく、意味のある結論を導き出せるだけの十分なデータを集めることです。どのレートを選択すればよいかわからない場合は、低い値から始めて、トラフィック パターンとボリュームについて理解を深めながら、パフォーマンスとボリュームとデータの精度のバランスが取れるレートが見つかるまで、徐々に値を増やしていくことをお勧めします。

追跡の一貫性

複数のトランザクションが関係するトレースの場合、Sentry は「ヘッドベース」のアプローチを使用します。つまり、サンプリングの決定は元のサービスで行われ、その決定は後続のすべてのサービスに渡されます。これがどのように機能するかを理解するために、上記の Web アプリの例に戻りましょう。それぞれのブラウザでアプリケーションを読み込む 2 人のユーザー A と B を考えてみましょう。 A がアプリをロードすると、SDK は疑似ランダムにトレースを収集することを「決定」し、B がアプリをロードすると、SDK はトレースを収集しないことを「決定」します。各ブラウザがバックエンドにリクエストを行うと、そのリクエストのヘッダーに「はい、トランザクションを収集してください」または「いいえ、今回はトランザクションを収集しません」という決定が含まれます。

バックエンドが A ブラウザからのリクエストを処理すると、「はい」の決定を確認し、トランザクションとスパンのデータを収集して、Sentry に送信します。さらに、後続のサービス (データベース サーバーなど) へのリクエストにも「はい」の決定が含まれ、同様にデータが収集され、Sentry に送信され、呼び出されるすべてのサービスに決定が渡されます。このプロセスを通じて、A のトレースのすべての関連トランザクションが収集され、Sentry に送信されます。

一方、バックエンドがブラウザ B からのリクエストを処理する場合、「いいえ」の決定が下されるため、トランザクションとスパンのデータは収集されず、Sentry に送信されません。ただし、後続のサービスに決定を伝播し、データの収集や送信を行わないように指示するという点では、A の場合と同じことを行います。次に、呼び出すサービスにデータを送信しないように指示し、B のトレースのトランザクションが収集されないようにします。

簡単に言うと、このヘッドベースのアプローチの結果、元のサービスで一度決定が行われ、その後のすべてのサービスに渡されて、特定のトレースのすべてのトランザクションを収集するか、まったく収集しないかが決定されるため、不完全なトレースは発生しません。