メインコンテンツへスキップ
高スループットのサービスでは、1 秒あたり数百万ものスパンが生成されることがあります。すべてのスパンを保存するのはコストが高いため、通常、チームは OpenTelemetry Collector の tail-sampling processor を実行し、N 個に 1 個のスパンだけを保持します。保持された各スパンには、N を記録する SampleRate 属性が付与されます。 ひとたびデータがサンプリングされると、単純な集計では正しい結果になりません。count() は実際に発生したイベント数より N 倍少ない値を返し、sum()avg() には偏りが生じ、パーセンタイルもずれます。その結果、ダッシュボードにはリクエスト数、スループット、エラー率が実際より低く表示され、誤解を招きます。 ClickStack は、サンプリングを考慮したクエリエンジンでこれを解決します。トレースソースでサンプルレート式を設定すると、クエリビルダーが SQL の集計を書き換え、ダッシュボード、アラート、アドホック検索全体で各スパンをそのサンプルレートに基づいて重み付けします。

仕組み

トレースソースに sampleRateExpression が設定されている場合、ClickStack はこれを次のようにラップします:
greatest(toUInt64OrZero(toString(expr)), 1)
SampleRate 属性がないスパンは重みがデフォルトで 1 になるため、サンプリングされていないデータでは元のクエリと同じ結果になります。 次に、クエリビルダーが集計を書き換えます。
集計変更前変更後 (サンプル補正後)
countcount()sum(weight)
count + 条件countIf(cond)sumIf(weight, cond)
avgavg(col)sum(col * weight) / sum(weight)
sumsum(col)sum(col * weight)
quantile(p)quantile(p)(col)quantileTDigestWeighted(p)(col, weight)
min / max変更なし変更なし
count_distinct変更なし変更なし
サンプリング時のパーセンタイルには、近似的な T-Digest スケッチである quantileTDigestWeighted を使用します。結果は元の値に近くなりますが、厳密に一致するわけではありません。

サンプルレート式の設定

トレースソースの ソース設定 を開き、各スパンごとのサンプルレートを返す ClickHouse 式を サンプルレート式 フィールドに入力します。 たとえば、OpenTelemetry tail-sampling processor がそのレートを SpanAttributes['SampleRate'] に書き込む場合: 設定すると、すべてのチャート、ダッシュボード、アラート、サービスダッシュボードのパネルで、サンプルレートで重み付けされた集計が自動的に適用されます。個々のクエリを変更する必要はありません。
最終更新日 2026年6月10日