Grafana observability dashboards теперь настраиваются без выхода из приложения. Это меняет контроль над наблюдаемостью на уровне сервисов и инстансов.
Пока команды живут на дефолтных дашбордах, всё выглядит приемлемо. Но при росте числа сервисов и сценариев эксплуатации стандартные представления начинают расходиться с реальными workflow. Возникает разрыв между тем, как система показывает данные, и тем, как инженеры принимают решения. Особенно это заметно в Cloud Provider Observability: есть быстрый старт с готовыми панелями для AWS, Azure и GCP, но глубина настройки ограничена, а drill-down на уровне инстанса часто не отражает нужные метрики и запросы.
Решение в Grafana 13 — дать контроль над точкой входа и детализацией, не ломая готовые шаблоны. Появляется возможность подключать существующие дашборды, генерировать новые через AI и переопределять instance drill-down. Это компромиссное решение: сохраняется ценность out-of-the-box представлений, но добавляется слой кастомизации. Ключевая идея — единая конфигурация на уровне сервиса, которая затем используется во всех поверхностях: сервисные страницы, Database Observability, entity graph и переходы из алертов. Такой подход снижает фрагментацию и убирает дублирование логики.
Реализация завязана на configure-страницу конкретного сервиса. На вкладке Services можно выбрать нужный сервис и определить, какой дашборд будет основным. Если уже есть проверенный внутренний дашборд, его можно подключить как quick link и сделать дефолтным. При этом стандартный дашборд не исчезает — он остаётся доступным как альтернатива. Если дашборда нет, используется генерация через AI: система создаёт шаблон с переменными и панелями в стиле RED/USE. Это ускоряет старт, но оставляет ответственность за финальную валидацию за командой.
Отдельный слой — настройка drill-down для инстансов. Здесь можно менять состав панелей, запросы, порядок отображения, единицы измерения и формат легенд. Важный момент: эта конфигурация применяется консистентно во всех точках входа. Независимо от того, пришёл ли пользователь из Cloud Provider Observability, Database Observability или из алерта, он увидит одинаковое представление. Это снижает когнитивную нагрузку и упрощает онбординг.
Результаты носят архитектурный характер, а не количественный — метрики улучшений не указаны. Но причинно-следственная связь очевидна: единая конфигурация уменьшает расхождение между командами, кастомные дашборды повышают релевантность сигналов, а AI-генерация снижает время до первого полезного представления. При этом остаются trade-offs. Чем больше кастомизации, тем выше риск расхождения стандартов внутри организации. Также AI-генерация ускоряет создание, но не гарантирует корректность запросов и интерпретации метрик.
В индустриальном контексте это выглядит как эволюционное улучшение. Наблюдаемость (observability) давно смещается от статичных дашбордов к адаптивным представлениям, ближе к задачам команды. Grafana делает шаг в сторону “config-as-a-view”, где сервис определяет, как именно его нужно наблюдать. Это снижает трение между платформенной командой и продуктовыми командами, но требует дисциплины в управлении конфигурацией.
С практической точки зрения, подход оправдан там, где есть разнообразие сервисов и разные модели эксплуатации. Если же инфраструктура однородна, стандартные дашборды могут оставаться достаточными. Новая модель не отменяет базовые представления, а добавляет слой управления. И именно этот слой становится точкой, где проявляется зрелость SRE-практик.