EL
"better promql"
VMQL
Size: a a a
2019 November 19
W
VMQL: A visual language for ad-hoc model querying
N
v-pro-mql
AV
Evgeny Lazin
Это очень странное поведение. У вас там consistent prefix не гарантируется что-ли?
В чем странное поведение? Не совсем понял вопрос про связь consistent prefix с search.latencyOffset
EL
В чем странное поведение? Не совсем понял вопрос про связь consistent prefix с search.latencyOffset
Что значит "неполные данные" и "могли не доехать" в этом случае?
AV
несколько прометеусов пишут данные в вм. У всех этих данных выставлены таймстемпы. Некоторые прометеусы могут запаздывать с записью данных в вм по разным причинам - далеко находятся, медленный канал связи, неточно выставленное время. В итоге ВМ будет делать запрос за последнюю секунду по неполным данным. Если сделать такой же запрос на том же интервале времени спустя некоторое время, то получим другие результаты, т.к. в базу подъедут недостающие данные. Может, стоит уменьшить значение по умолчанию для latencyOffcet, т.к. одна минута выглядит слишком пессимистично
EL
Ну так это как раз то, о чем я писал. Если ТСБД поддерживает consistent prefix, то это все не нужно. Ты сделал запрос, получил набор данных с первой меткой времени Т0 и последней меткой времени Т1 (Т1 может быть меньше метки времени из запроса, т.к. данные ещё не прососались полностью). Если сделать ещё один запрос, то данные на интервале Т0-Т1 не поменяются.
AV
К сожалению, в promql эту инфу нельзя вытянуть, чтобы ее можно было использовать в алертах. Также что будет, если для одного ряда данные придут с out of order таймстемпами?
EL
К сожалению, в promql эту инфу нельзя вытянуть, чтобы ее можно было использовать в алертах. Также что будет, если для одного ряда данные придут с out of order таймстемпами?
База данных должна просто хранить и отдавать данные. Скрывать данные попадающие в скользящее окно глубиной в одну минуту можно и на стороне клиента, если очень хочется.
AS
это же вы про staleness чуток
AS
и там тоже получается задержка существенная из-за цепочки федераций например
2019 November 20
AS
я про вот эту зубодропительную фигню https://www.youtube.com/watch?v=GcTzd2CLH7I
G
influxdata/telegraf tagged: 1.12.6
Link: https://github.com/influxdata/telegraf/releases/tag/1.12.6
Release notes:
Link: https://github.com/influxdata/telegraf/releases/tag/1.12.6
Release notes:
Telegraf 1.12.6
A
https://docs.datadoghq.com/developers/metrics/custom_metrics/
"A custom metric refers to a unique combination of metric name, host, and tag values."
предположем, есть гистограмма http_requests_bucket{method, service, statuscode, le}
правильно ли я понял что это (method * service * statuscode * le) метрик?
"A custom metric refers to a unique combination of metric name, host, and tag values."
предположем, есть гистограмма http_requests_bucket{method, service, statuscode, le}
правильно ли я понял что это (method * service * statuscode * le) метрик?
A
и если "да" - есть ли варианты сделать это некастомным, а то там ценник конский?
AS
нет ведь еще надо умножить на саму метрику ибо она имеет лейбл
__name__=http_requests_bucketAS
сделай это квантилем аггрегируй по статус кодам которые приемлимы
AS
видишь как много у тя есть вариантов (нет)
A
идея в том что мои коллеги топят за saas с метриками а я не могу ничего найти чтобы делать SLA гранулированого уровня (500 сервисов + 1к разных метрик на каждый) на который не надо почку продавать, варианты велком :(
AS
а тебе точно столько надо с учётом APM ?