Привет!
А почему может не работать max by (node) rate(errors[5m])? Отдельно рейт конечно рисуется, но у меня получается несколько таймсерий от разных процессов, хочу сократить

Потому что скобки надо ещё ставить -_-
max by (node) (rate(errors[60m]))

Вроде не должны требоваться

Должны конечно

Должны, даже в доке есть про это

Ребят, кто-нибудь пытался экспортировать метрики из Prometheus в Metabase?

jmx_exporter помогает немного

Или вам нужно именно запросы к бд?

А вариант с динамическим формированием словарей (КМ мапов)  для лейблов и их значений не прокатит?  
Грубо:
экспортер копит словарь id=hash(metricName,labelName,labelValue) -> tuple{ metricName,labelName,labelValue}, а значения  метрик шлёт с соответствующими id.
Сам словарь (id- > tuple) мог бы посылаться прому как вместе с метриками целиком или как update с прошлого скрейпа, так и забираться промом отдельно.
Если при каждом скрейпе словарь не тащить, то трафик сильно пожмётся.
В какой то сепени похоже на шаблоны в netflow v9 и в ipfix.

Такая схема могла бы неплохо лечь на протобуф.

Главный минус - запихивать такое в каждый экспортёр - оверкиль и для инструментирования в приложениях малопригодно.

Akumuli поддерживает похожий протокол, все что передается в БД сразу после установки соединения сначала интерпретируется как словарь, если это не прокатывает, то фолбэк на обычный протокол, если словарь передан, то можно потом отправлять метрики используя id вместо лэйблов, либо указывать лэйблы полностью. Это обратно совместимо с ранними версиями протокола.
Главных минусов два: может быть дорого хранить большой словарь на каждое TCP соединение; непонятно что делать если нужно изменить словарь (либо разрешить передавать его в любое время и усложнить тем самым протокол для всех, либо передавать только в начале, но на клиенте нужно больше логики в некоторых случаях).
Для прома скорее всего можно было бы что-то похожее придумать, только для pull модели это не так просто, кмк.

Не знал, надо посмотреть.

В моём примере с netflow v9 рутеры периодически шлют шаблоны с описанием полей (шаблонов может быть несколько разных, каждому рутер даёт какой-то уникальный id) , а большую часть времени шлют просто data records, которые в себе несут id шаблона, по которому их надо декодировать.  И это всё в push модели. Т.е. пока коллектор не получит шаблона он не знает, что делать с data. Всякие опимизации типа кеширования на стороне коллектора и персистентности между рестартами отданы на откуп коллектору.

В pull модели пром сам рулит в каком порядке что получать, так что логика может и не сложнее быть. Но в любом случае получается, что и на стороне прома и на стороне экспортёра надо стейт поддерживать...
Плюс, это работает только если надор лейблов и их значений  относительно редко/мало меняются по сравнению с  значениями метрик. Иначе весь смысл теряется.

из-за сложности в реализации и дебаге такая штука вряд ли приживется

Можно написать в поддержку и мы вышлем триал.

Спасибо

Речь о Dynatrace саппорте или grafana саппорте?

О Grafana, мы же плагин делаем.

Согласен. Экономить на байтах и городить ради этого сложный, а то и stateful протокол - перебор.
В snmp вон биты экономили - и в итоге он такой "simple" :-) получился.