promql и metricsql лучше всего работают над временными рядами с регулярно записываемыми в них точками

Спасибо за ссылку. Нашел ее пару дней назад, но хотелось еще услышать мнение сообщества

Понятно, спасибо за ответ. Да,  регулярность, описанном мной кейсе, будет не очень.  Собственно и задача сводится к отслеживанию отклонений в регулярности.

спрошу странное =) про прометей гошный колектор.

wrapreg := prometheus.WrapRegistererWith(md, prometheus.DefaultRegisterer)              
wrapreg.MustRegister(                                                                   
  prometheus.NewProcessCollector(prometheus.ProcessCollectorOpts{}),                    
  prometheus.NewGoCollector(),                                                          
  opsCounter,                                                                           
  timeCounterSummary,                                                                   
  timeCounterHistogram,                                                                 
)                                                                                       
                                                                                        
prometheus.DefaultRegisterer = wrapreg

вот такой штукой я хочу всем метрикам назначить мои уникальные лейблы

(md = map[string]string)

такой вариант падает так как я регаю те же метрики с теми же именами только лейблы другие

могу создать свой регистр, но это не подходит.

можно ли как-то заставить экспортить все метрики (даже из под используемых других библиотек) с теми лейблами что я скажу? или это фантастика

вот допустим мне надо метрики elastic'а в пром, хотя "метрики" тут громко сказано... всё что мне надо это cluster status из _cluster/health?pretty ну и мб чёнить из _cat/nodes?v , короче просто для того, чтоб алерты сделать на случай если кластер развалится. Вот как бы вы в этой ситуации сделали: курлом эту одну/две метрики брать и, например, с помощью textfile.collector отправлять в пром, либо брать сразу чёнить типа elasticsearch_exporter?

коллектор выглядить более правильно, сразу с заделом на будущее

аппетит, как говорится, приходит во время еды

а если существует потребность в экономии места хранилща и прииходится вырезать метрики которые не нужны? Разумно ли ради одной-двух метрик тащить этот комбайн)

тогда проверку в нагиос запили)

я не знаю как в проме вырезать метрики, которые не нужны, но у нас в графите это делается не сильно сложно

так у меня сейчас она в заббиксе, в пром переезжаю))

эластик и экономия места

обычно как происходит - делаешь что-то базово, проходит время, хочется большего. Дак не лучше сразу к этому подготовится?

ну я понял, голос за экспортер, мб ещё мнения будут)