高スループットのサービスでは、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 になるため、サンプリングされていないデータでは元のクエリと同じ結果になります。
次に、クエリビルダーが集計を書き換えます。
| 集計 | 変更前 | 変更後 (サンプル補正後) |
|---|---|---|
| count | count() |
sum(weight) |
| count + 条件 | countIf(cond) |
sumIf(weight, cond) |
| avg | avg(col) |
sum(col * weight) / sum(weight) |
| sum | sum(col) |
sum(col * weight) |
| quantile(p) | quantile(p)(col) |
quantileTDigestWeighted(p)(col, weight) |
| min / max | 変更なし | 変更なし |
| count_distinct | 変更なし | 変更なし |
サンプルレート式の設定
トレースソースの ソース設定 を開き、各スパンのサンプルレートとして評価される ClickHouse 式を サンプルレート式 フィールドに入力します。
たとえば、OpenTelemetry tail-sampling processor がそのレートを SpanAttributes['SampleRate'] に書き込む場合:

設定すると、すべてのチャート、ダッシュボード、アラート、サービスダッシュボードのパネルで、サンプルレートに基づく重み付き集計が自動的に適用されます。個々のクエリを変更する必要はありません。