入口で1%だけ残す設定では、その日の失敗の2.2%しか記録に残りませんでした。
出口で選ぶ形に変えると、保存量はほぼ同じまま残り率が100%になります。
入口で決める方式は、中身を見ずに捨てます。稀なものほど、まるごと残らなくなります。
OpenTelemetryには、入口で早く決める間引き方があります。公式は入口での間引きは、できるだけ早い段階で残すか捨てるかを決める手法であると述べています。
中身を見ずに決めます。では稀な出来事はどれだけ残るのか。1万日ぶん観察して数えました。
1日に何回か起きる出来事を、入口で間引きながら 10,000 日ぶん観察する その日の分が1件も残らなかった日を数える 1日の発生回数 0.1%残す 1.0%残す 5.0%残す 10.0%残す 100.0%残す 1回 99.9% 99.1% 94.7% 89.7% 0.0% 3回 99.7% 97.3% 85.8% 72.9% 0.0% 10回 99.0% 90.2% 60.5% 35.2% 0.0% 100回 90.6% 36.6% 0.7% 0.0% 0.0%
1日3回の出来事を1%で間引くと、97.3%の日は1件も残りません。調べようとしても手がかりが出てきません。
10%まで上げても72.9%です。10倍の量を保存しても、まだ空振りのほうが多いという結果でした。
表の下に行くほど改善します。1日100回なら、5%で0.7%まで下がります。
つまり入口での間引きは、よく起きるものを見る用途に向いています。稀なものを追う用途とは相性が悪くなります。
この「見たいものほど見えない」という形は、Prometheusの記事で扱った短い山の見逃しとも同じ構図です。
残す割合を10倍にしても、空振りの日は半分にもならない。
Head sampling is a sampling technique used to make a sampling decision as early as possible.原文OpenTelemetry 公式ドキュメント「Sampling」 この内容の有効期限2027-02-18
出口で選べば、同じ量で残るものが変わります。代わりに、判断まで持っておく仕組みが要ります。
OpenTelemetryには、記録の中身を見てから決める間引き方もあります。公式は出口での間引きは、記録に含まれる点の全部かほとんどを踏まえて、残すかどうかを決めるものであると述べています。
同じ保存量で、どれだけ違うのか。2つの方式を並べて数えました。
1日 1,000,000 件。うち失敗は 92 件（0.009%） 入口で一律に間引く場合と、出口で失敗だけ全部残す場合を比べる 選び方 残した件数 残った失敗 失敗の残り率 入口で 0.1% 残す 1,036件 0件 0.0% 入口で 1.0% 残す 9,979件 2件 2.2% 入口で 10.0% 残す 99,890件 8件 8.7% 出口で失敗＋成功 0.1% 1,070件 92件 100.0% 出口で失敗＋成功 1.0% 10,109件 92件 100.0% 出口で失敗＋成功 10.0% 100,233件 92件 100.0%
1行目と4行目を比べます。保存量は1,036件と1,070件でほぼ同じです。
それでも失敗の残り率は0.0%と100.0%です。量ではなく、選び方だけで変わっています。
失敗はもともと92件しかありません。全部残しても、100万件のうちの0.009%にすぎません。
ただし出口で決めるには、決まるまで1件ぶんの点を持っておく必要があります。入口で決めるなら、その置き場は要りません。
この置き場をどこに用意するかは、トレース設計の記事で扱った収集役の配置と同じ判断になります。
Tail sampling is where the decision to sample a trace takes place by considering all or most of the spans within the trace.原文OpenTelemetry 公式ドキュメント「Sampling」 この内容の有効期限2027-02-18
1件の重さは呼び出しの階層で決まります。サービスを分けるほど、記録の量が増えます。
OpenTelemetryでは、入口で決める場合は全体を見ません。公式は残すか捨てるかの判断は、記録の全体を調べることでは行われないと述べています。
全体は、複数の点に分かれています。呼び出しの形で何点になるのか、形を変えて数えました。
1日 200,000 件。1件の記録が何個の点に分かれるかで、量がどう変わるかを見る 1点あたり 400 バイトとして計算する 呼び出しの形 1件あたりの点数 1日の点数 1日の量 1%だけ残す場合 入口のみ 1点 200,000点 0.07GB 0.8MB 入口＋DB 2点 400,000点 0.15GB 1.5MB 3階層 5点 1,000,000点 0.37GB 3.8MB 6サービス 16点 3,200,000点 1.19GB 12.2MB
入口だけなら1点です。6サービスをまたぐと16点になり、量は16倍になります。
同じ件数でも、構成を分けた分だけ記録が増えます。分割の判断が、そのまま保存量の判断になっています。
3番目が要点です。量から先に決めると、最初の節で見たとおり稀なものが消えます。
3つの計測はいずれも手元で書いた模型で、実際のOpenTelemetryを動かしたものではありません。出来事が独立に起きると置いており、まとまって起きる場合の結果は違います。失敗92件は0.01%の割合から作った値で、実際の失敗率とは関係ありません。1点400バイトも置いた値です。ここで見せているのは、入口で間引くと稀なものが消えるという点と、保存量をほとんど変えずに選び方だけで残るものが変わるという点の2つです。
A decision to sample or drop a span or trace is not made by inspecting the trace as a whole.原文OpenTelemetry 公式ドキュメント「Sampling」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る