サンプリング

判断はルートで一度だけ行われます

トレースは、まるごと残すか、まるごと捨てるかです。判断はルートのスパンが始まるときに行われ、すべての子に受け継がれるので、実行が半分だけ記録されることはありません。

他のすべては、この規則から出てきます。スパンのうち無作為な 30% が欠けたトレースは、サンプリングされたトレースには読めません。観測している側のシステムの不具合に読めます。実行されなかったように見えるツール呼び出し、親のないモデル呼び出し、検索があるはずの場所の空白。その空白がエージェントではなく可観測性の道具のせいだと分かるまでに、午後を 1 つ使うことになります。

既定はすべてを残します

サンプリングを設定しなければポリシーは always で、量が問題になるまでは、それが正しい既定です。サンプリングは、あなたが後で読みたくなる実行を差し出す取引です。その代価は、ストレージか帯域がそうさせるときにだけ払ってください。

5 つの戦略

戦略	動作
`always`	すべてを残します。既定です。
`never`	何も残しません。
`ratio`	一定の割合を残します。ルートで、トレースごとに一度、無作為に引きます。
`deterministic`	一定の割合を残します。トレース id のハッシュで決めます。どのコレクターも、他のどれとも通信せずに同じ答えにたどり着きます。
`tail`	トレースが終わるまで判断を先送りし、その後は割合の設定にかかわらず、すべてのエラーとすべての遅い実行を残します。

割合を設定する

--sample、または MCPD_SAMPLE は 0.0 から 1.0 の割合を取り、決定的戦略を設定します。その範囲の外の値は、あなたが渡した値を示すメッセージとともに、起動時にデーモンを停止させます。範囲に丸めることはしません。打ち間違えた割合が黙って 1.0 になれば、それが分かるのは一か月後、ストレージの請求書によってだからです。

10 本に 1 本のトレースを残す

mcpd --sample 0.1

どの SDK も同じ割合を読みます。クライアント設定の sample、または環境変数の MCPD_SAMPLE です。クライアント側のサンプリングのほうが安く済みます。サンプリングされなかったスパンはキューに入らず、送出もされないので、帯域をまったく使いません。デーモン側のサンプリングは往復分の費用がかかりますが、割合を一か所にまとめられます。十数個のサービスが 1 つのインスタンスに送っている場合は、そちらが望ましいでしょう。

5 つの戦略のうち、デーモンから届くのは always と deterministic です。--sample と、設定ファイルのプロジェクトの sample は、どちらも deterministic 戦略を設定します。never、ratio、tail はポリシーの型の中に実装されていますが、このビルドではフラグからも設定ファイルからも届きません。

ハッシュで多数のインスタンスの判断がそろう理由

ロードバランサーの後ろで mcpd を複数動かすと、1 つのトレースのスパンが同じインスタンスに全部届くとはかぎりません。インスタンスごと、あるいはスパンごとにコインを投げるサンプラーは、トレースの一部を残して残りを捨てます。最初の規則は、まさにその失敗を防ぐためにあります。

決定的戦略は、トレース id を 64 ビットの範囲全体に写し、その値が割合の示すしきい値を下回るときにトレースを残します。どのインスタンスも同じ id から同じ数を計算するので、共有状態も、調整のためのプロトコルも、ずれる余地もないまま、全員の判断が一致します。同じ id はリトライでも同じ答えを返すので、再送されたバッチが半分だけ届くこともありません。

この写像を正直なものにしている細部が、2 つあります。1 つは、id の末尾 16 桁の 16 進を読むことです。OpenTelemetry はトレース id が乱数であることを求めていますが、先頭のバイトをタイムスタンプから作る生成側もあり、そこを読むサンプラーは、サンプリングではなく時刻との相関を取ってしまいます。もう 1 つは、id がそもそも 16 進でない場合の動きです。すべてを残す動作に退化するのではなく、仕上げの撹拌を伴う本物のハッシュにフォールバックするので、実際の割合は、あなたが指定した割合の近くにとどまります。

SDK では上流の判断が優先されます

SDK が受け取った W3C の traceparent からトレースを続ける場合、 ID と一緒に sampled フラグを引き継ぎ、自分の割合は適用しません。これは両方向に効きます。フラグが立っていればローカルの割合に関係なくトレースは残され、フラグが下りていればローカルの割合に関係なく捨てられます。

このビルドのデーモンはこれを行いません。OTLP で届いたスパンについて、デーモンはその trace-flags バイトを属性 mcpd.otlp.flags に残しますが、デーモンのサンプラーはそれを読みません。割合を設定したデーモンは、フラグが何を示していても、すべてのトレースにその割合を適用します。

そうしない場合の結果は、字面から受ける印象より深刻です。各サービスが自分の割合を適用すれば、4 つのサービスをまたぐトレースは、2 つで残されて 2 つで捨てられます。最後に手元に残るのは、分散トレースではありません。分散トレースの形をした穴の集まりです。

テールサンプリングは、読む価値のある実行を残します

ヘッドサンプラーは、何も分からないうちに判断します。安上がりですが、目が見えていません。10 分の 1 なら、失敗も 10 分の 1 しか残しません。あなたが実際に開くトレースはめったに起きないほうであり、めったに起きないものこそ、割合によるサンプラーが最も苦手とするものです。

レイテンシの記録は、こういう見た目になります。平らな基準線と、いくつかの逸脱です。量があるのは基準線のほうで、答えがあるのは逸脱のほうです。テールサンプリングはトレースが終わるまで保持し、その中で何かがエラーになっていれば残し、あなたが設定したしきい値より長く走っていれば残し、それ以外には先ほどと同じ決定的ハッシュを適用します。エラーを残す動作は既定で有効です。いちばん必要になるトレースはめったに起きないものであり、割合によるサンプラーは、それをいちばん捨てやすいからです。

代価はバッファリングです。テールサンプラーは、判断できるようになるまで、終わっていないトレースをすべてメモリーに保持しなければなりません。だからこれは既定ではなく、意図して選ぶものです。上に書いたとおり、テール戦略はポリシーの型の中に実装されており、このビルドではフラグからも設定ファイルからも届きません。デーモンの取り込み経路が適用するのは、ヘッドの判断です。

何が捨てられたかを知る

サンプラーが捨てたスパンは、そのつど mcpd_traces_sampled_out_total を増やします。この値は /metrics に Prometheus のテキスト形式で出ています。割合は、チームが読む場所に書いておいてください。サンプリング率が文書化されていれば、トレースが無いことには説明が付きます。説明の無いトレース欠落はサポート依頼になり、それを書くのは、たいていあなた自身です。

次に

保存する量を減らす、もう 1 つの方法：秘匿化と保持期間。
すべてのフラグと環境変数：設定。
/metrics と、デーモン自身のそのほかのシグナルを読む：運用。