ユースケース

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

セール中に問われるのはエラー率ではありません。どの顧客がカートを失い、何がそれを止めたのかが問題です。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 · orderorder_8421

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

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

トレースはStripeで止まる

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

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

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

結果

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

できること

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