PromQL очень ограниченный имеет функционал в сравнении с InfluxDB

и интерполяция prometheus очень сильно расходится в требованиях к точности данных)

А как вы решаете проблемы с устареванием и поддержкой дашбордов?
Предположим, одна команда разработала дашборд. Как она шарит знания с другими командами?
Т.е. я например вижу команда А - создала дашборд А1, А2. Комадна Б открывает отчет и должна сделать какие то выводы по нему. Она должна как то пойти ногами в команду А? Или у вас есть стандарты оформления и шаринга информации?

это вопрос в разрезе баз и сборщиков данных или отдельно?

Это отдельный вопрос, уже относящийся к сбору, обработке и поддержке знаний.

Дашборд показывает какое то инфо, как выводы по имеющейся информации зависят от того как сделан дашборд если он оформлен понятно? (названия, какая то разбивка)

есть 2 большие проблемы в том, что высокого уровня компетенций на просторах мира НТ по визуализации данных - крайне мало, к примеру, чтобы поддерживать мои дашборды - надо потратить много времени на изучение, отсюда вытекает вторая проблема - сложные дашборды нельзя понимать без контекста, а контекст - это данные тестов.
теперь о конретном:
1. устаревание дашбордов не происходит, если оно функционировало на этих данных оно и будет функционировать, вопрос только в наличии необходимого функционала, а ради него можно разово все переделать снова на очень продолжительный срок (год+)
2. шарить знания можно элементарно, собрал встречу рассказал как работает дашборд и все, там ничего вундермощного написать нельзя, чтобы вышло за рамки пары часов шаринга экрана.

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

Механизм provisioning позволяет загружать доски из json-файлов с диска. Так получается гитовать их. И к сожалению общей Grafana нет на все команды. Я готовлю доклады и статьи, чтобы внутри поделиться информацией. Рассказываю на совещаниях, что готов поделиться опытом, а потом отвечаю на вопросы

Процесс небыстрый. Желающих дорабатывать доски - единицы так-то. Поэтому большой конкуренции среди команд не будет

😄 вот это точно

про отчет и дашборды вообще не понял, это не однозначно связанные сущности. отчет может быть с использованием графиков дашборда, но их интерпретация это ключевая компетенция нагрузочного тестера, то есть странно передавать компетенцию того, как понимать утилизацию CPU или очереди межпроцессорные команде других тестеров)

Для обмена знаниями - wiki, bitbucket и продвижение, на совещаниях эффективно получается

Предположим разработчики разрабатывают сервис отправки писем. Есть требования что сервис выдерживает отправку 100 писем в еденицу времени. Они подготовили дашборд для мониторинга с отображением этой информации (кол-во отправляемых писем). По этому дашборду другому человеку (разработчику из другой команды/ инженеру QA) нужно понять что происходит.
Сервис не статический, а постоянно дорабатываемый появляются новые графики/старые становятся не валидными. Как то надо донести информацию до других команд что это за графики, как их интерпретировать.

Учись работать с фиддлер.
Это МЕГАПОЛЕЗНАЯ тулза.

Делаешь название графика "отправляемые письма в секунду" и все

если по описанию это не понятно то запилить статейку в конфлюенсе например можно плюс в формате НТ прям такой супер быстрой доработки что все устаревает очень быстро нет

За квартал протухает

ты ищешь проблему там где её обычно нет) у графика помимо названия есть дескрипшон. добросовестные ребята сложные графики там подписывают.
все фиксы есть в бд самой графаны и можно как в гите посмотреть кто и что менял и что делал

это какой график так быстро устаревает?

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