SampleRate, в котором записано значение N.
После сэмплирования данных наивные агрегации дают неверный результат: count() возвращает в N раз меньше событий, чем произошло на самом деле, sum() и avg() оказываются смещёнными, а процентильные значения сдвигаются. Панели мониторинга показывают заниженные значения числа запросов, пропускной способности и частоты ошибок, что вводит в заблуждение.
ClickStack решает эту проблему с помощью движка запросов, учитывающего сэмплирование. Когда вы настраиваете выражение коэффициента выборки для источника трассировки, конструктор запросов переписывает SQL-агрегации так, чтобы вес каждого спана учитывался по его коэффициенту выборки — в панелях мониторинга, оповещениях и ad-hoc поисковых запросах.
Как это работает
sampleRateExpression, ClickStack оборачивает его в следующую конструкцию:
SampleRate по умолчанию назначается вес 1, поэтому данные без сэмплирования дают те же результаты, что и исходные запросы.
Затем конструктор запросов переписывает агрегации:
| Aggregation | Before | After (sample-corrected) |
|---|---|---|
| count | count() | sum(weight) |
| count + condition | 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 | unchanged | unchanged |
| count_distinct | unchanged | unchanged |
Для перцентилей при сэмплировании используется
quantileTDigestWeighted — приблизительный эскиз T-Digest. Результаты близки к точным, но не совпадают с ними полностью.Настройка выражения коэффициента выборки
SpanAttributes['SampleRate']:
После настройки все графики, панели мониторинга, оповещения и панели мониторинга сервисов автоматически применяют агрегации с учетом коэффициента выборки. Изменять отдельные запросы не нужно.