Но - не работают в проме)

Недавно имел боль по миграции таких метрик из инфлюкса, с дэшами в качестве разделителей. Причем vm их спокойно принимает, а графана их не видит.

так графана или пром?

я чот запутался

прому значение лейбла не важно. job="gcp_node_exporter_web-prod=Node6_fast" отлично съестся

а вот j-ob="node_exporter" нет

Ага

Спасибо за ответ, Александр, вопрос был вполне себе без подколок, имхо "бред" это довольно сильное утверждение и должно быть пояснено.

> - Идея позволить пользователям задавать разрешающую способность бакетов. Это приведет к бессмысленным спорам, какая разрешающая способность лучше. Также это приведет к несовместимым гистограммам, которые нельзя группировать.
> - Идея позволить задавать верхнюю границу zero bucket. Проблемы те же, что указаны выше.
Тут два момента. Первый - это все таки драфт. Если он дойдет то практической реализации то я более чем уверен в дефолтах будет зашито какое то значение, которое естроит 99% пользователей. То же касается и зиро бакета - выберут 10^-100 какой нить и все.
Но второй момент - то что 1% пользователей могут это поменять с моей точки зрения очень хорошо. Это давний вопрос и спор чего именно хотят пользователи, можно припомнить и Форда и Джобса, но это про технику а не маркетинг и я тут за разнообразие.
Мне такой подход нравится больше чем "18 бакетов хватит на всех".

> - Предложенные форматы экспорта новых гистограмм слишком сложны и запутанны. Ппоэтому есть большие сомнения, что они получат широкое распространение.
> - Предложенная схема хранения для новых гистограмм не обеспечит хорошее сжатие данных, а лишь усложнит реализацию.  Видно, что у Бьорна нет практического опыта в этой области.
Тут я пас. Идея назвать Бьорна теоретиком это сильно конечно, но он не голливудская звезда чтоб я его защищал, пусть сам отдувается. Имхо как раз наоборот -
я не сталкивался с ситуацией когда парсинг текстового протокола влиял на Пром, это должна быть очень специфическая инсталляция, все мои Промы дохли гораздо раньше по памяти из за кардиналити.
Но он столкнулся и намудрил странную схему передачи, плюс есть результаты тестов и предложение расширить тест на данные с других источников. Но опять таки, это драфт.
С хранением я не могу предметно обсуждать, возможно все так.

> - Идея о периодическом сбросе бакетов в ноль, лишена практического  смысла. Это не уменьшит количество сохраняемых рядов и не улучшит сжатие данных.
Эм. "Нет, ты". 🙂 Бьорн утверждает что не лишена, и это позволит бороться с энтропией, причем утверждает что это результат практических испытаний. Тут я на стороне практики - опять таки, из за разнообразия.
Если кто то не сталкивался с проблемой Х это не означает что проблемы не существует и если в протокол зашита возможность теоретически с Х бороться - я выберу этот протокол.

> - Мысли про то, как правильно запрашивать данные из новых гистограмм - слишком сложны для понимания  среднестатистичекским пользователем. Видно, что Бьорн - больше теоретик, а не практик.
Тоже спорный вопрос. Кому надо - гребитесь со старыми гистограммами, они простые, бгг. Хотя Бьорн сам же пишет про обертку которая в принципе решит проблему.
Имхо это как с rate/irate и прочими scalar/vector. Оно работает как должно в теории, но теория сложна, юзерам пофиг и они путаются.
Приходит ВМ и говорит - а давайте поменяем дефолтное поведение а то юзеры путаются. "Нафиг" - говорит Брайан, "это сломает теорию и существующее поведение, пусть не путаются а читают доки".
"Пофиг" - говорят ВМ и запиливает несовместимое решение вместо того чтобы реализовать отдельное, при этом называет все это еще PromQL, чем вызывает в разрабов прома бугурт, жопное горение и угрозы лоерами.
Так вижу. 🙂 Имхо если опять таки сохранить совместимость но дать пользователям _выбор_ (тем,кому этот выбор нужен конечно) то можно решить обе проблемы.

Попробуйте завернуть весь запрос в count(...) by (node) . Если пользуетесь victoriametrics, то там есть функция label_keep() для того, чтобы оставлять только указанные лейблы. См. https://victoriametrics.github.io/MetricsQL.html

спасибо, но мое это решение оказалось костыльным, обошёл через external_labels

Спасибо за развернутые комментарии :) Попатыюсь объяснить, почему периодическое обнуление бакетов в гистограммах не улучшает сжатие данных. Кау только в бакет попадает хотя бы одно значение, для этого бакета создается временной ряд в бд, который уже занимает дополнительное место на диске. Этот ряд никуда не денется и место на диске не освободится, если по нему перестанут приходить новые значения после обнуления бакета. Это лишь приведет к неравномерным интервалам времени между сохраняемыми значениями для бакетов, в которые попадают редкие значения. У рядов с неравномерными интервалами между занчениями есть две проблемы:
- они не очень хорошо вписываются в модель данных прометеуса, который ожидает одинаковые интервалы времени между значениями. Из-заэтого могут вылазить косяки при запросах.
- такие ряды обычно хуже сжимаются из-за неравномерности интервалов, т.к. она добавляет лишнюю энтропию.

👍

Найти в кластере где много прометеусов такие которые настроены неоптимально с точки зрения pvc, когда они или слишком большие или слишком маленькие

Всем привет. А может кто посоветовать почитать что на русском про Графану доступно для ПМа? А то поднял прометея, настроил себе алерты, сделал бизнес-метрики на аппе накопительные, показал как их смотреть в explore  а теперь хотят дашборды с графиками странными типа продажи по дням разбитые. Я-то разберуь но совсем не хочется быть отвественным ещё и за красоту графиков

ну если не вы то кот?

😹

ПМ )

я и так басфактор=1 по куче тем (

так может это отдать человеку который должен этим заниматься?

ему какую-никакую инструкцию надо, на русском