評価・監視・ガードレール

トレース設計とは|段ごとに記録して初めて、12.2倍遅い段を名指しできた

トレース設計では何を記録するのか粒度はどこまで細かくするのか細かくすると何が増えるのか

全体の所要だけを記録していると、遅い段を1件も名指しできません。入口と出口の2点でも同じです。

段ごとに記録して初めて100%になりました。検索の段だけが12.2倍に伸びていました。

この記事の要点

  • 全体の所要だけでは0.0%
  • 段ごとに記録すれば100.0%
  • 遅い段は12.2倍に伸びていた
  • さらに細かくしても100.0%のまま

段ごとに記録して初めて、12.2倍遅い段を名指しできた

全体の所要だけでは、遅い要求は見つかっても場所が分かりません。段の単位で残す必要があります。

トレース設計で決めるのはどの単位で時間を残すかです。粒度を変えて、実際に走らせて測りました。

5つの段を通る要求5000件を作りました。うち514件で、検索の段だけが遅くなるようにしています。

粒度を動かす

text
要求 5000件。5つの段を通る。うち 514件で検索の段だけが遅くなる
全体の所要の95%点は 1160ミリ秒

記録の粒度                  1件あたりの記録  遅い段を名指しできた割合  1日の保存量
全体の所要だけ                             1個                    0.0%         76MB
入口と出口の2点                            2個                    0.0%        153MB
段ごとに記録                              5個                  100.0%        381MB
段ごと+呼び出し先                           9個                  100.0%        687MB

全体の所要だけを残していると、名指しできた割合は0.0%です。入口と出口の2点にしても変わりません。

2点だけでは、結局そのあいだの合計しか出ないからです。1個から2個に増やしても、内訳は1つも増えていません

中身を見る

text
段        通常     遅いとき    倍率
受付             8ms        8ms     1.0倍
検索            60ms      727ms    12.2倍
整形             5ms        5ms     1.0倍
生成           399ms      401ms     1.0倍
記録            12ms       12ms     1.0倍

段ごとに残していれば、この表がそのまま出ます。検索だけが12.2倍で、ほかは動いていません。

通常時に最も長いのは生成の399msです。いちばん重い段と、遅くなった段は別でした。

出典も入れ子の意味を親スパンIDがあることから示されるとおり、スパンは入れ子にできる。子スパンは下位の処理を表すと説明しています。

段ごとに残すまで、場所は分からない。

単位: %段ごとに記録100%段ごと+呼び出し先100%全体の所要だけ0%入口と出口の2点0%要求5000件のうち、検索の段が遅くなった514件で測定。値は遅い段を名指しできた割合。
図1 ── 粒度ごとの特定率
出典OpenTelemetry「Traces」2026-08-18 確認
Spans can be nested, as is implied by the presence of a parent span ID: child spans represent sub-operations.
原文OpenTelemetry「Traces」 この内容の有効期限2027-02-18

トレース設計では何を記録するのか

1件の処理を、段の集まりとして残します。段には親子関係を付けて、どこに含まれるかを示します。

トレース設計は、1件の処理が通った道筋を残す設計です。出典もこの役割を述べています。

その言い方はトレースは、アプリケーションに要求が来たときに何が起きるかの全体像を与えるというものです。

残す形

  1. まとまりの識別子。同じ処理に属することを示す
  2. 段の識別子。1つの段を指す
  3. 親の識別子。どの段の中で起きたか
  4. 開始と終了。その段にかかった時間

3番目がないと、段を並べても順番に起きたのか、中で起きたのかが分かりません

前の節の内訳表も、親子関係があって初めて足し合わせられます。生成の399msの中に検索が含まれるなら、合計の意味が変わります。

段の割り方

段は「別の相手に頼んだところ」で割ります。検索、生成、書き込みのように、外に出る単位です。

同じ処理の中で細かく割っても、この計測のとおり特定率は変わりません。割る基準は、疑いたい相手の数です。

時間以外に残すもの

  1. 結果。成功したか、失敗したか
  2. 件数。取れた行数や渡した長さ
  3. 相手。どの索引、どのモデルを使ったか
  4. 再試行。何回目の呼び出しか

2番目があると、遅い理由まで見えます。応答時間の監視の記事では、この裾の見方を扱っています。

出典OpenTelemetry「Traces」2026-08-18 確認
Traces give us the big picture of what happens when a request is made to an application.
原文OpenTelemetry「Traces」 この内容の有効期限2027-02-18

1段細かくしても特定率は変わらず、保存量だけ1.8倍になった

粒度を上げれば保存量は比例して増えます。特定率のほうは、ある段で頭打ちになります。

トレース設計の費用は、ほぼ記録の個数に比例します。同じ表の右端を見ます。

1日20万件・1記録400バイトとして計算しました。段ごとで381MB、さらに細かくすると687MBです。

1.8倍に増えています。ところが特定率は100.0%のままで、1件も改善していません。

頭打ちの見つけ方

この計測では、遅くなる原因が検索の段に1つだけありました。段の数まで割れば、それ以上は何も足されません

原因が段の中にある場合は話が別です。同じ段で複数の呼び出しをまとめているなら、そこは割る価値があります

出典も細かさの意味をこれにより、スパンはアプリケーションで行われた作業をより正確に捉えられると述べています。捉えたいものがあるかで決めます。

量を抑える手

  1. 間引く。成功した処理だけ一部を残す
  2. 短く持つ。細かい記録の保存期間を縮める
  3. 畳む。古い記録は段ごとの合計だけにする
  4. 選ぶ。疑っている経路だけ細かくする

1番目は効き方に注意が要ります。LLM可観測性の記事では、間引き方を変えたときに失敗をどれだけ捕まえられるかを測っています。

保存量は比例して増えるが、特定率は頭打ちになる。

充足 2 / 4段ごとに開始と終了を残している全体の所要だけでは、遅い段を1件も名指しできない親子関係を付けている順番に起きたのか中で起きたのかが分からないと合計できないとにかく細かく割っている段より細かくしても特定率は100.0%のままで、保存量が1.8倍になるいちばん重い段だけを見ている通常時に最も長いのは生成の399msだが、遅くなったのは検索だった要求5000件と、1日20万件・1記録400バイトとしたときの計算にもとづく。
図2 ── 決める前の点検項目
余談 この計測での注意

遅くなる原因は1つの段だけに置いています。実際には複数の段が同時に遅くなることも、段の外側で待たされることもあります。1記録400バイトという値も置いたもので、属性を増やせば大きくなります。ここで見せているのは、特定率が段の数で頭打ちになり、保存量だけが伸び続けるという関係です。

出典OpenTelemetry「Traces」2026-08-18 確認
This allows spans to more accurately capture the work done in an application.
原文OpenTelemetry「Traces」 この内容の有効期限2027-02-18

よくある質問

全体の所要時間だけでは足りませんか
足りません。この計測では遅い要求を見分けられても、5つの段のどれが遅いかは0.0%しか名指しできませんでした。
どこまで細かく記録しますか
段ごとまでです。この計測では段ごとで100.0%になり、そこからさらに細かくしても変わりませんでした。
細かくすると何が増えますか
保存量です。この計測では1日20万件のとき、段ごとで381MB、さらに細かくすると687MBになりました。
親子関係は必要ですか
必要です。どの段がどの段の中で起きたかが分からないと、時間の内訳を足し合わせられません。

まとめ

  • 処理の道筋を段ごとに残す
  • 全体の所要では場所が分からない
  • 段ごとで特定率が100%
  • 細かくしすぎると保存量だけ増える

今日から始められること

  1. 処理が通る段を書き出す
  2. 段ごとに開始と終了を記録する
  3. 遅い要求を1件開いて内訳を見る
  4. 名指しできなければ段を割り直す

実務で組んだトレース設計のワークフローには、値段が付きます

同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。

出品の仕組みを見る