вот тут добросовестные ребята пишут заметки по фиксам, когда это многокомандная история

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

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

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

пишите тайтлы и описания, это всё что для этого нужно

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

Надо рассказывать о доске, поддерживать ее. Я вот забросил доску для Gatling, она умирает сейчас

Influxdb + grafana настраивать намного проще - весьма широкие возможности есть в gui и запросы накликиваются без знания синтаксиса запросов.

С прометеусом не так - нужно именно писать запросы текстом,

и плюс ещё там зачастую используются накопительные данные для всего подряд (то есть в метрике «утилизация cpu» цифрка всегда увеличивается, и нужно считать разницу между значениями. Это немного неочевидно, но когда привыкнешь - пофиг.


С другой стороны, мне показалось, что prometheus как средство мониторинга более широко распространён, чем телеграф (напихивающий данные в influxdb).
То есть для произвольно взятой системы ты скорее найдёшь экспортёр для прометея, чем окажется, что по ней встроен плагин телеграфа

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

Я думаю тут сразу стоит разделить весь этот мониторинг на 2 группы:
1 - метрики самого теста которые мы можем собрать с генератора нагрузки (персентили, нагрузку по подаваемым интерфейсам и т.д.).
2 - метрики самого приложения

Первое очень часто делается в связке influx + grafana самой командой НТ так как это быстро и удобно.
Второе обычно делается поддержкой, и тут уже легко используется prometheus (ну или что хотите), и тут уже задача сделать гибкость в самих дашбордах чтобы при добавлении интеграционной точки не надо было бежать и перепиливать все.

метрики приложения тоже запихиваются в инфлюкс, мб конечно что то типа логов лучше в кибану

Кирилл, так вот и вопрос :). Удобный способ передачи информации и поддержания ее в АКТУАЛЬНОМ состоянии 🙂

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

Люди ведь все разные, одним удобно смотреть видео, с другим читать, третим слушать аудио. Хочется понять те МИНИМАЛЬНЫЕ (чтобы командам это было не сложно) но НЕОБХОДИМЫЕ требования к оформлению информации и что не менее важно ее ПОДДЕРЖАНИЕ, т.к. не актуальная информация это тоже плохо.

>поддерживаете дашборд по необходимости... нет?
Но тут же как с лимитами и алертами. Команде нужно понимать когда уже время пришло и как то проконтролировать их в случае если они «забыли» обновить

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

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

И все что коллеги тут предложили - есть:
1. Есть дашборды (часто настроенные только на прод, а не на тестовые окружения)
2. Есть информация в Confluence актуальная, часто не очень
3. Из минусов редко проводим совещания.

Человек умер, уволился, не отвечает на звонок 🙂

Угодить не всем, а общему большенству. И не угодить, а помочь.