RK
Gregory Tsvetkov
Я убавлял min-block до получаса(было 2 ч), в надежде что это снизит потребление памяти. Но видимо в другом дело
скорее всего
Size: a a a
2020 January 14
як
так странно, сегодня говоря с менеджерами разных уровней понял что одни говоря SLA имеют ввиду agreement, а другие availability... еще один плюс в сторону важности создания определений при начале работы )
SLA - это Service Level Agreement и в ITIL/ITSM и в SRE, если носители другой трактовки не юристы - увольняйте их
IL
бакеты в гистограммах куммулятивны и именуются
Основная сложность гистограмм - определение диапазонов бакетов, т.к. библиотека прометеуса ничего не знает о данных, которые вы хотите туда записывать. Поэтому задача понять диапазон значений ложится как раз на пользователя. Определите какие именно значения вам нужно покрыть и соответственно сделайте нужную градацию. Так же совершенно нормально время от времени “подкручивать” диапазоны бакетов, т.к. ваше приложение или поток данных могут меняться.
Имплементация гистограмм в VM умеет автоматически определять диапазоны бакетов в зависимости от входящих данных. Т.е. ее не нужно настраивать - просто пишите данные
le => less or equal. Таким образом, получая значение, прометеусовская либа понимает какой из счетчиков выбрать для обновления - выбор происходит по диапазонам. Например, при получении значения 98КБ - будут выбраны все бакеты со значеним >98KB. И единственным необновленным бакетом будет 0. Исходя из этой логики вы можете прийти к выводу, что бакет 0 не имеет смысла и обойтись без него).Основная сложность гистограмм - определение диапазонов бакетов, т.к. библиотека прометеуса ничего не знает о данных, которые вы хотите туда записывать. Поэтому задача понять диапазон значений ложится как раз на пользователя. Определите какие именно значения вам нужно покрыть и соответственно сделайте нужную градацию. Так же совершенно нормально время от времени “подкручивать” диапазоны бакетов, т.к. ваше приложение или поток данных могут меняться.
Имплементация гистограмм в VM умеет автоматически определять диапазоны бакетов в зависимости от входящих данных. Т.е. ее не нужно настраивать - просто пишите данные
Точно
Теперь понял, большое спасибо!
VM надо будет почитать, видел что можно подкрутить в прометеус, но наверное в данный момент мне не критично, больше важны линейные метрики.
Теперь понял, большое спасибо!
VM надо будет почитать, видел что можно подкрутить в прометеус, но наверное в данный момент мне не критично, больше важны линейные метрики.
2020 January 15
AV
а вообще summary более тяжелый для расчетов чем histogram?
Summary считает для каждой метрики заранее заданный набор квантилей на заранее заданном интервале времени. Этот расчет происходит на стороне клиента, который потом экспортит результат для сбора прометеусом.
Для historgram на стороне клиента создается набор счетчиков по заданным интервалам значений. При попадании значения метрики в заданный интервал соответствующий счетчик инкрементируется. В стандартной библиотеке метрик от прометеуса набор интервалов для каждой метрики нужно задавать самому. В библиотеке метрик от вм набор интервалов фиксированный для всех метрик. Это позволяет производить одновременные расчеты поверх любых метрик, по которым собраны гистограммы, а также динамически вычислять произвольный набор квантилей за любой интервал времени, что невозможно для стандартных гистограмм прометеуса. См. https://medium.com/@valyala/improving-histogram-usability-for-prometheus-and-grafana-bc7e5df0e350
Основные отличия гистограмм от summary:
- персентили из summary нельзя агрегировать
- из summary метрик нельзя подсчитать отсутствующие персентили. То же самое касается существующих персентилей, но за интервалы времени, отличные от сконфигурированных в приложении, экспортирующем метрики в прометеус.
- вычисления по гистограммам сильнее нагружают проц на стороне базы данных во время запроса, в то время как вычисления по summary сильнее грузят приложение, экспортирующее метрики.
Для historgram на стороне клиента создается набор счетчиков по заданным интервалам значений. При попадании значения метрики в заданный интервал соответствующий счетчик инкрементируется. В стандартной библиотеке метрик от прометеуса набор интервалов для каждой метрики нужно задавать самому. В библиотеке метрик от вм набор интервалов фиксированный для всех метрик. Это позволяет производить одновременные расчеты поверх любых метрик, по которым собраны гистограммы, а также динамически вычислять произвольный набор квантилей за любой интервал времени, что невозможно для стандартных гистограмм прометеуса. См. https://medium.com/@valyala/improving-histogram-usability-for-prometheus-and-grafana-bc7e5df0e350
Основные отличия гистограмм от summary:
- персентили из summary нельзя агрегировать
- из summary метрик нельзя подсчитать отсутствующие персентили. То же самое касается существующих персентилей, но за интервалы времени, отличные от сконфигурированных в приложении, экспортирующем метрики в прометеус.
- вычисления по гистограммам сильнее нагружают проц на стороне базы данных во время запроса, в то время как вычисления по summary сильнее грузят приложение, экспортирующее метрики.
AV
Gregory Tsvetkov
Привет, у меня Пром жрет 32 гига памяти и вырубается от oom каждые 5 мин, как фиксить, кто сталкивался? Метрик не много, на гитхабе говорят "дай Прому скока хочет", я крайне несогласен с этим
Попробуй пром 2.15.2 - его оптимизировали по потреблению памяти. Говорят, что ест до 1.5-2 раз меньше предыдущих версий
AG
Summary считает для каждой метрики заранее заданный набор квантилей на заранее заданном интервале времени. Этот расчет происходит на стороне клиента, который потом экспортит результат для сбора прометеусом.
Для historgram на стороне клиента создается набор счетчиков по заданным интервалам значений. При попадании значения метрики в заданный интервал соответствующий счетчик инкрементируется. В стандартной библиотеке метрик от прометеуса набор интервалов для каждой метрики нужно задавать самому. В библиотеке метрик от вм набор интервалов фиксированный для всех метрик. Это позволяет производить одновременные расчеты поверх любых метрик, по которым собраны гистограммы, а также динамически вычислять произвольный набор квантилей за любой интервал времени, что невозможно для стандартных гистограмм прометеуса. См. https://medium.com/@valyala/improving-histogram-usability-for-prometheus-and-grafana-bc7e5df0e350
Основные отличия гистограмм от summary:
- персентили из summary нельзя агрегировать
- из summary метрик нельзя подсчитать отсутствующие персентили. То же самое касается существующих персентилей, но за интервалы времени, отличные от сконфигурированных в приложении, экспортирующем метрики в прометеус.
- вычисления по гистограммам сильнее нагружают проц на стороне базы данных во время запроса, в то время как вычисления по summary сильнее грузят приложение, экспортирующее метрики.
Для historgram на стороне клиента создается набор счетчиков по заданным интервалам значений. При попадании значения метрики в заданный интервал соответствующий счетчик инкрементируется. В стандартной библиотеке метрик от прометеуса набор интервалов для каждой метрики нужно задавать самому. В библиотеке метрик от вм набор интервалов фиксированный для всех метрик. Это позволяет производить одновременные расчеты поверх любых метрик, по которым собраны гистограммы, а также динамически вычислять произвольный набор квантилей за любой интервал времени, что невозможно для стандартных гистограмм прометеуса. См. https://medium.com/@valyala/improving-histogram-usability-for-prometheus-and-grafana-bc7e5df0e350
Основные отличия гистограмм от summary:
- персентили из summary нельзя агрегировать
- из summary метрик нельзя подсчитать отсутствующие персентили. То же самое касается существующих персентилей, но за интервалы времени, отличные от сконфигурированных в приложении, экспортирующем метрики в прометеус.
- вычисления по гистограммам сильнее нагружают проц на стороне базы данных во время запроса, в то время как вычисления по summary сильнее грузят приложение, экспортирующее метрики.
А там hdrhistogram под капотом или своя реализация?
GT
Попробуй пром 2.15.2 - его оптимизировали по потреблению памяти. Говорят, что ест до 1.5-2 раз меньше предыдущих версий
Да, обновил вчера, не падал весь вечер. Сегодня ещё не смотрел
A
Summary считает для каждой метрики заранее заданный набор квантилей на заранее заданном интервале времени. Этот расчет происходит на стороне клиента, который потом экспортит результат для сбора прометеусом.
Для historgram на стороне клиента создается набор счетчиков по заданным интервалам значений. При попадании значения метрики в заданный интервал соответствующий счетчик инкрементируется. В стандартной библиотеке метрик от прометеуса набор интервалов для каждой метрики нужно задавать самому. В библиотеке метрик от вм набор интервалов фиксированный для всех метрик. Это позволяет производить одновременные расчеты поверх любых метрик, по которым собраны гистограммы, а также динамически вычислять произвольный набор квантилей за любой интервал времени, что невозможно для стандартных гистограмм прометеуса. См. https://medium.com/@valyala/improving-histogram-usability-for-prometheus-and-grafana-bc7e5df0e350
Основные отличия гистограмм от summary:
- персентили из summary нельзя агрегировать
- из summary метрик нельзя подсчитать отсутствующие персентили. То же самое касается существующих персентилей, но за интервалы времени, отличные от сконфигурированных в приложении, экспортирующем метрики в прометеус.
- вычисления по гистограммам сильнее нагружают проц на стороне базы данных во время запроса, в то время как вычисления по summary сильнее грузят приложение, экспортирующее метрики.
Для historgram на стороне клиента создается набор счетчиков по заданным интервалам значений. При попадании значения метрики в заданный интервал соответствующий счетчик инкрементируется. В стандартной библиотеке метрик от прометеуса набор интервалов для каждой метрики нужно задавать самому. В библиотеке метрик от вм набор интервалов фиксированный для всех метрик. Это позволяет производить одновременные расчеты поверх любых метрик, по которым собраны гистограммы, а также динамически вычислять произвольный набор квантилей за любой интервал времени, что невозможно для стандартных гистограмм прометеуса. См. https://medium.com/@valyala/improving-histogram-usability-for-prometheus-and-grafana-bc7e5df0e350
Основные отличия гистограмм от summary:
- персентили из summary нельзя агрегировать
- из summary метрик нельзя подсчитать отсутствующие персентили. То же самое касается существующих персентилей, но за интервалы времени, отличные от сконфигурированных в приложении, экспортирующем метрики в прометеус.
- вычисления по гистограммам сильнее нагружают проц на стороне базы данных во время запроса, в то время как вычисления по summary сильнее грузят приложение, экспортирующее метрики.
Мне кажется, что надо делать неофициальную документацию по прометею и типам данных с разжёвыванием разницы
A
Половина твоих сообщений туда уйдёт как есть
AV
А там hdrhistogram под капотом или своя реализация?
Своя реализация, похожая на hdrhistogram, но с меньшим набором бакетов - компромисс между практичностью и точностью расчетов. Imho, количество бакетов в hdrhistogram - слишком большое. Это увеличивает накладные расходы на сбор, передачу и хранение этих бакетов, без какой-либо пользы для большинства практических применений.
IL
Summary считает для каждой метрики заранее заданный набор квантилей на заранее заданном интервале времени. Этот расчет происходит на стороне клиента, который потом экспортит результат для сбора прометеусом.
Для historgram на стороне клиента создается набор счетчиков по заданным интервалам значений. При попадании значения метрики в заданный интервал соответствующий счетчик инкрементируется. В стандартной библиотеке метрик от прометеуса набор интервалов для каждой метрики нужно задавать самому. В библиотеке метрик от вм набор интервалов фиксированный для всех метрик. Это позволяет производить одновременные расчеты поверх любых метрик, по которым собраны гистограммы, а также динамически вычислять произвольный набор квантилей за любой интервал времени, что невозможно для стандартных гистограмм прометеуса. См. https://medium.com/@valyala/improving-histogram-usability-for-prometheus-and-grafana-bc7e5df0e350
Основные отличия гистограмм от summary:
- персентили из summary нельзя агрегировать
- из summary метрик нельзя подсчитать отсутствующие персентили. То же самое касается существующих персентилей, но за интервалы времени, отличные от сконфигурированных в приложении, экспортирующем метрики в прометеус.
- вычисления по гистограммам сильнее нагружают проц на стороне базы данных во время запроса, в то время как вычисления по summary сильнее грузят приложение, экспортирующее метрики.
Для historgram на стороне клиента создается набор счетчиков по заданным интервалам значений. При попадании значения метрики в заданный интервал соответствующий счетчик инкрементируется. В стандартной библиотеке метрик от прометеуса набор интервалов для каждой метрики нужно задавать самому. В библиотеке метрик от вм набор интервалов фиксированный для всех метрик. Это позволяет производить одновременные расчеты поверх любых метрик, по которым собраны гистограммы, а также динамически вычислять произвольный набор квантилей за любой интервал времени, что невозможно для стандартных гистограмм прометеуса. См. https://medium.com/@valyala/improving-histogram-usability-for-prometheus-and-grafana-bc7e5df0e350
Основные отличия гистограмм от summary:
- персентили из summary нельзя агрегировать
- из summary метрик нельзя подсчитать отсутствующие персентили. То же самое касается существующих персентилей, но за интервалы времени, отличные от сконфигурированных в приложении, экспортирующем метрики в прометеус.
- вычисления по гистограммам сильнее нагружают проц на стороне базы данных во время запроса, в то время как вычисления по summary сильнее грузят приложение, экспортирующее метрики.
большое спасибо за исчерпывающий ответ!
AV
Мне кажется, что надо делать неофициальную документацию по прометею и типам данных с разжёвыванием разницы
Что-то типа этого, только по метрикам? https://medium.com/@valyala/prometheus-storage-technical-terms-for-humans-4ab4de6c3d48 ?
A
Про детали
A
Особенно про составление запросов
A
Чёткое описание видов метрик и как их можно использовать
A
С примерами
A
Вот чего точно не хватает
AV
Думаю, лучший способ для этого - создать wiki или репозиторий с доками на гитхабе, и обновлять его с помощью community
IL
да… полюбому надо
очень сложно по интернету собирать информацию по крупицам
я смотрел и доклады с dockerconf, и доклады самих разработчиков прометеуса чтобы собрать воедино какие-то зерна
большое спасибо этому сообществу, в процессе диалога я очень сильно пополнил свое понимание метрик в принципе
очень сложно по интернету собирать информацию по крупицам
я смотрел и доклады с dockerconf, и доклады самих разработчиков прометеуса чтобы собрать воедино какие-то зерна
большое спасибо этому сообществу, в процессе диалога я очень сильно пополнил свое понимание метрик в принципе