А ограничил в докере память 8 гигами - перестал и оказалось и с ними прекрасно работает

Чудеса

Но это вроде у старого проблема была

https://habr.com/ru/company/funcorp/blog/445370/
Несмотря на то, что есть возможность конфигурировать размер блока, не рекомендуется настраивать его вручную, поэтому вы поставлены перед необходимостью дать Prometheus столько памяти, сколько он попросит для вашей нагрузки.
https://github.com/coreos/prometheus-operator/issues/2196#issuecomment-444409703

Ну и вообще, когда гугли prometheus oom, не находишь никакого решения

Пытался под какие-то кеши tsdb память забрать и когда доходил до конца памяти в системе оживал oom и грохал его

гистограммы в прометеусе это обычные счетчики, где каждый бакет это счетчик и + 2 контрольных счетчика. Поэтому можно не переживать за их производительность - скорее всего всё будет достаточно быстро. С гистограммами нужно быть осторожным только с вариативностью лейблов для метрики, т.к. каждый новый лейбл или его значение будет порождать N новых рядов, где N -  кол-во бакетов. Т.е. для гистограм используйте всегда строго детерминированные наборы лейблов, чтобы измбежать неожиданного “взрыва” кардинальности.

спасибо, это исчерпывающий ответ
осталось научиться более менее этими метриками оперировать чтобы выводить красивый график

а вообще.. если у меня много микросервисов, но на них почти идентичные метрики - нормально ли на каждый микросервис заводить отдельный джоб? Или лучше во дной джобе все делать, но просто специальным тегом идентифицировать метрики с каждого сервиса?

или по барабану?

как уже рекомендовали - попробуйте обновиться до последней версии. Из доп опций есть следующие варианты:
- прометеус в основном потребляет память в зависимости от размера индекса во временным рядам. На размер этого индекса влияет кол-во метрик и их кардианльность. Посмотрите http://prometheus/status или http://prometheus/api/v1/status/tsdb чтобы найти самые “большие” метрики. Возможно, какие-то из них не нужны или используются неправильно (в лейблы пишется большое кол-во уникальных значений)
- можно попробовать снизить размер блока, если не используете танос (он работает только с 2ч afaik)
- можно понизить GOGC значение до 50% или меньше - контролирует частоту срабатывания GC в go. Это такой себе трейдофф CPU и памяти

в проме есть специальная ф-ция по работе с гистограммами - histogram_quantile. Так же в графане есть спец панель heatmap для гистограмм.
Еще одно преимущество гистограмм перед саммари - возможность комбинировать значения с разных сервисов/джоб (при условии что размерность бакетов идентична). Так вы сможете, например, построить один график по всем репликам ваших http-серверов.

О, спасибо. А какой параметр за размер блока отвечает, он storage.tsdb.min-block-duration?

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

>> а вообще.. если у меня много микросервисов, но на них почти идентичные метрики - нормально ли на каждый микросервис заводить отдельный джоб? Или лучше во дной джобе все делать, но просто специальным тегом идентифицировать метрики с каждого сервиса?

да, это нормальная практика. Обьединяйте джобы по типам микросервисов: job: nginx, job: node_exporter. Для прометеуса не будет разницы между вариативностью джоб или уникальных идентификаторов.

да, есть еще max-block-duration

Я их крутил, толку 0

Обновлюсь и посмотрим.  Если что pprof придется освоить

имеется в виду память? или вы проверяли частоту чекпоинтов?

@hagen1778
Спасибо!
На сколько я понимаю, гистограммы - это в принципе единственный способ строить даже линейный график, где Y - будет, например, размер запроса.
То есть если я сделаю градацию там.. 0б, 100б, 1кб, 5кб, 20кб, 100кб, 1мб, Inf+.

Вообще есть ли какие-то правила построения правильной градации бакетов? Я так понял это больше нужно для построения правильной “температуры” в heatmap, а для линейного графика - главное, какие градации мне удобней для мониторинга?

заранее спасибо за ответ

Я убавлял min-block до получаса(было 2 ч), в надежде что это снизит потребление памяти. Но видимо в другом дело

бакеты в гистограммах куммулятивны и именуются le => less or equal. Таким образом, получая значение, прометеусовская либа понимает какой из счетчиков выбрать для обновления - выбор происходит по диапазонам. Например, при получении значения 98КБ - будут выбраны все бакеты со значеним >98KB. И единственным необновленным бакетом будет 0. Исходя из этой логики вы можете прийти к выводу, что бакет 0 не имеет смысла и обойтись без него).

Основная сложность гистограмм - определение диапазонов бакетов, т.к. библиотека прометеуса ничего не знает о данных, которые вы хотите туда записывать. Поэтому задача понять диапазон значений ложится как раз на пользователя. Определите какие именно значения вам нужно покрыть и соответственно сделайте нужную градацию. Так же совершенно нормально время от времени “подкручивать” диапазоны бакетов, т.к. ваше приложение или поток данных могут меняться.

Имплементация гистограмм в VM умеет автоматически определять диапазоны бакетов в зависимости от входящих данных. Т.е. ее не нужно настраивать - просто пишите данные