Как с Prometheus собирать метрики, не искаженные привязкой ко времени

[oraclehome]

Сталкнулся недавно с подобной проблемой при обработке инкрементального счётчика: rate показывал довольно сомнительные результаты (видимо он делал именно то, что я его попросил). В итоге сейчас использую increase вместе rate — что дало более приближенный к правде результат. Хотя, полагаться на точность в prometheus не приходится, но в целом он даёт хорошую общую картину.

Вот тоже интересная статья которая помогла в понимании обработки снятых метрик: www.innoq.com/en/blog/prometheus-counters

[aml]

Изначально был выбран неправильный тип метрики для решения задачи. Стандартный джентльменский набор для веб-сервисов:

1. cumulative counter для числа обработанных запросов, отображать как rate
2. cumulative counter для числа ошибок (с разбивкой по типу ошибки), отображать как rate
3. histogram для времени обработки запросов, отображать как процентили
4. gauge для requests in flight, отображать, как есть

Сочетание 3 и 4 дало бы вам совершенно четкую картину вашей аварии: рост latency и рост числа запросов in flight.

[ggo]

В дополнение — если речь идет о воркерах и их аналогах, собирать статистику об их количестве, общем и активных.
Помимо процентилей, полезно собирать max. На большом трафике редкие аномалии по длительности на процентилях могут быть не видны. Чем раньше замечаем аномалии, тем лучше.

[fessmage]

Тот случай, когда комментарий полезнее статьи. Собирайте правильные метрики и тогда не будет проблем с их интерпретацией.