Понял, спасибо большое

Я уже мойру попробовать решил для начала)

Мойра топ!

этот запрос используется для построения графика в графане или для алертов? Если для графика в графане, то покажите, что возвращают  запросы count(count_over_time(nginx_vts_server_requests_total{code=~"(1|2|3|4|5)xx",host!="*"}[1h]) и count(count_over_time(nginx_vts_server_requests_total{code=~"(1|2|3|4|5)xx",host!="*"}[5m]) в проме и в вм? Первый запрос вернет количество рядов, которые затрагиваются при выполнении запроса за последний час (см. [1h] в запросе. Второй - количество затронутых рядов за последние 5 минут (см. [5m] в запросе. Если эти значения сильно отличаются, то это означает, что старые ряды постоянно заменяются на новые (aka high churn rate). Так может происходить, если в метрике nginx_vts_server_requests_total часто меняется какой-нибудь лейбл. Ряд однозначно идентифицируется его именем плюс набором его лейблов. Если значение хотя бы одного лейбла меняется, то создается новый ряд. При high churn rate может получиться, что в каждом ряду содержится совсем маленькое количество точек (до 100 на ряд, т.е. если ряды меняются чаще, чем раз в час для 30-секундного scrape interval'а - 30с*100точек=3000 секунд). ВМ оптимизирована под хранение и обработку рядов со сравнительно большим количеством точек (более 100 на ряд). Если в большинстве рядов, участвующих в запросе, содержится маленькое количество точек, то вм может работать не очень эффективно из-за накладных расходов, связанных с распаковкой данных для каждого ряда. Подозреваю, что это ваш случай.

Для определния количества новых рядов, созданных за последний час, можно выполнить запрос vm_new_timeseries_created_total[1h]) (предполагается, что для вм уже настроен мониторинг https://victoriametrics.github.io/#monitoring ). Для определения лейблов, приводящих к high churn rate, можно посмотреть на страницу /api/v1/status/tsdb .

На практике все зависит от желаемого результата. Если важно знать распределение значений метрики (например, если значения распределены не по нормальному закону, а имеют несколько "всплесков" и эти "всплески" могут перемещаться по шкале значений с течением времени), то лучше использовать гистограммы с бакетами, покрывающими с хорошим разрешением большинство возможных значений метрики. Если же важно знать максимальное значение метрики для какого-то процента измерений (например, максимальное время ответа для 95% пользователей aka 95-й персентиль), то тогда используйте summary.

спасибо за подробное разъяснение!
а вот реальными примерами про гистограммы можно?
толковых материалов по реальным применениям мало - поэтому сложно сориентироваться когда их применять

Надеюсь, что Prometheus без Брайана не превратится в какашку

Обычно гистограммы используют вместо саммари, если нужна возможность объединения гистограмм по нескольким метрикам. Например, у вас есть кластер микросервисов, и вы измеряете время выполнения запроса на каждом микросервисе. Если вам нужно подсчитать время выполнения запроса по всем микросервисам (минимальное, максимальное, какой-нибудь квантиль), либо построить heatmap по времени выполнения запроса по всем микросервисам, то тут без гисторграмм не обойтись, т.к. квантили по отдельным сервисам нельзя объединять. Гистограммы же легко объединять путем сложения бакетов. После объединения можно легко подсчитать нужные квантили или посторить heatmap. Единственный момент - объединение работает только для гистограмм, содержащих одинаковый набор бакетов с одинаковыми границами.

Всем привет! Стоит задача собрать через прометеус информацию о уникальных юзерах за определенный промежуток времени, но столкнулся с проблемой в реализации.
На данный момент метрика выглядит как СounterVec unique_client{platform, client_id} и конечно же любая кверя в promql относительно времени сейчас и сколько-то минут назад будет показывать постоянную константу так как количество юзеров только растет каунтер же. Если пытаться прикрутить метрике лейбл timestamp то количество данных возрастет неимоверно и прометеус просто падает. Как решают подобные вопросы?

вроде и на русском, но понятнее не становится :) квантили бакеты :)

👌ага вот где собака порылась!
я по простоте своей решил все саммариз покрыть и сводить их потом в одну диаграмму - а оно то не сводимое! спасибо!такого нигде не читал

Подскажите еще одну вещь - насколько затратно потом считать все квантили по гистограммам - в доке пугают что это может стать узким местом в мониторинге

Правильно ли я понимаю что гистограммы лучше использовать для измерения времени?
(я например не могу себе даже представить какие и сколько корзин я должен описать для размеров запросов/ответов - настолько it depends of user data)

https://prometheus.io/docs/practices/histograms/#errors-of-quantile-estimation попробуй тут на английском

это я уже раза 3 с лупой читал! :)

понимаю. я 2 недели в голову укладывал. но после того как уложил понял что без этого вообще в мониторинге делать нечего

уговорили, сегодня с микроскопом перепрочту )

эта проблема не решается в прометеусе. Вам нужен кликхаус, чтобы сохранять события с уникальными айдишками пользователей и потом делать выборки за любой промежуток времени с помощью unique(user_id)

2 недели?

так и думал, спасибо!

ну ладно ладно. месяца

немного не в тему (в канале по логам не ответили)
как на практике в логах расследовать инциденты с юзерами если в логах нет конфиденциальной и идентифицирующей информации о юзерах?
(из соображений безопасности в приличных публичных организациях такая инфа не должна попадать в логи)