Подскажите пожалуйста, а кто-то пользуется гистограмами с predefined бакетами? Я

знаю что в Java мире обычно используют HdrHistogram, которая сама авторесайзит бакеты в зависимости от данных.

Но тут мне нужно собирать метрики в Rust-овом бэкенде, и вижу что в опенсорц проектах используют predefined buckets. Например, для латенси (в секундах):
.1, .2, .4, .8, 1.6, 3.2, 6.4, 12.8, 25.6, 51.2, Inf+

или для подсчета кол-ва ошибок:
1.0, 2.0, 4.0, 8.0, 16.0, 32.0, 64.0, 128.0, 256.0, 512.0

Как-то так
Histogram::new(exponential_buckets(1.0, 2.0, 10))
или
Histogram::new(linear_buckets(0.0, 1.0, 10))

Таким образом задают upper_bound бакета, и потом смотрят в какой бакет попадает значение, и там делают counter += 1.

Я не большой специалист в матстате, так что прошу совета. Предзаданные бакеты - норм? Как потом убедиться что данные не bias-нулись из-за неправильного выбора бакетов?

зависит от задачи. если бакеты на границах вашего slo или apdex вам пофиг биаснулись они или нет. если вы по этим бакетом хотите считать квантили тогда их может быть не достаточно, да. в prometheus мире это болит довольно редко, но болит и разработчики уже несколько лет пытаются затащить более лучшие бакеты. но пока дальше дизайн доков сильно не ушли

Да, хочется персентили считать по латенси В расте есть реализация HdrHistogram, видимо надо её прикручивать к какой-нибудь из Прометеус либ.

Можешь попробовать воспользоваться statsd. Он будет считать нужные тебе персентили и отправлять результаты в виде метрик. См. https://github.com/avito-tech/bioyino

Ну я в целом к statsD и привык. Но все современные инструменты/библиотеки внезапно завязаны на прометеус/open metrics. И я так понимаю что summary у Prometheus считает персентили на клиенте примерно так же, как и statsD у себя. Но мб я ошибаюсь?

всё правильно понимаете

Если пром в твоем случае справляется с нагрузкой и всё устраивает, то может им и воспользоваться? У нас не справляется (и по функционалу не устраивает), и мы поэтому используем bioyino.

Понял, спасибо! Но я пока на стадии дизайна метрик, в перформанс прома еще долго не упрусь

как ни странно это довольно простая задача. надо всего лишь отдавать много лейблов и вариантов лейблов

главное - потом понимать, что за цифры пром показывает :)

Так можно продолжать использовать statsd,но сменить бэкнд с graphite на victoriametrics . Получите возможность делать запросы поверх собираемых в statsd данных как с помощью графит-запросов, так и с помощью promql (плюс metricsql) - см. https://docs.victoriametrics.com/#how-to-send-data-from-graphite-compatible-agents-such-as-statsd В качестве бонуса получите более эффективное сжатие метрик по сравнению с графитом и меньшую нагрузку на дисковую подсистему - см. успешный пример перехода с графита на вм - https://docs.victoriametrics.com/CaseStudies.html#grammarly

можешь поподробнее про вот этот бонус? не то чтобы у нас нагрузка прыгала выше 5% но все равно инетресно узнать на сколько нагрузка ниже в сравнеии с Графитом (с бекендом ClickHouse)

Имеется ввиду сравнение с классическим whisper-бэкендом. Не сравнивали с бэкендом графита на кликхаусе. Будет здорово, если сравните и поделитесь результатами :)