ユースケース

決済が失敗している。どの注文が、なぜ。

セール中に問われるのは、どの顧客がカートを失い、何がそれを止めたのかです。1つの注文IDが、3つの画面すべてで答えを運びます。

signal POST /checkout error rate 8.4% · threshold 1%

経路

1つの注文を、アラートからタイムアウトまで

order_8421は実際に失敗した注文です。以下のすべての画面はこの注文に絞り込まれているため、2つのツール間でタイムスタンプを突き合わせる必要はありません。

order order_8421 /alerts /traces /errors T+0:00 T+0:25 T+2:10

alert T+0:00 · order order_8421

アラートはcheckoutルートだけで発報する

サイト全体は持ちこたえている一方で、POST /checkoutのエラー率がしきい値を超えます。この絞り込みが最初の事実です。セールのトラフィックは問題なく、決済経路が失敗しています。
trace T+0:25 · order order_8421

トレースはStripeで止まる

失敗した注文を1つ開けば、ウォーターフォールは明白です。3回のリトライが最下部に赤く並び、いずれもちょうど1.75秒、クライアント自身の期限でタイムアウトしています。
logs T+2:10 · order order_8421

ログはプールが空だったと語る

それらのスパン中に書き込まれた行は、同じトレースIDを持ちます。リトライ予算の枯渇、続いてコネクションプールの上限到達。タイムアウトは接続待ちの症状でした。

結果

プールを拡張し、リトライ予算を2回に削減。checkoutのエラー率は1評価ウィンドウ以内にベースラインへ戻りました。

できること

業務IDもただの属性: スパンにorder.idを一度設定すれば、トレース一覧、エラーissue、ログ検索など、スパンが存在するあらゆる場所で絞り込めます。別途インデックスを維持する必要はありません。
外部呼び出しもスパン: Stripeへの呼び出しは、固有の所要時間とステータスを持つクライアントスパンです。サードパーティのタイムアウトは、自社のエラー率から推測するのではなく実測されます。
ログはスパンに結合される: スパンの裏にある行には、同じ分に手作業で絞り込んだテキスト検索ではなく、スパンから直接たどり着けます。通常もっとも時間を食うのがこの工程です。