Публичное демо без регистрации: как показать живой мониторинг и сохранить безопасность
В Grafana можно опубликовать дашборд для просмотра без учётной записи. Система формирует специальный токен, а посетитель получает доступ только к визуализациям и данным, без прав на редактирование. На первый взгляд настройка выглядит элементарно: достаточно включить пару параметров в интерфейсе. На практике именно за этими двумя переключателями скрывается множество нюансов.
Проблемы возникают с переменными, идентификаторами панелей, лимитами запросов, аннотациями и служебными метками. Поэтому публичный дашборд Grafana без регистрации нельзя воспринимать как обычную копию рабочего экрана. Это отдельная витрина, которую нужно подготовить, ограничить и протестировать. Практический разбор подобной архитектуры можно найти в материале о том, как организовать публичный мониторинг Grafana без раскрытия внутренних данных.
Сначала стоит оценить реальную нагрузку
Публичный дашборд отдаёт описание через обычный GET-запрос. Это позволяет оценить его состав снаружи, не авторизуясь в Grafana. В демонстрационной конфигурации девять экранов содержали 245 панелей, из которых 217 выполняли запросы к источникам данных.
К примеру, на дашборде Linux-серверов было 133 панели, 117 из них обращались к данным. Kubernetes занимал 36 панелей, Windows-серверы - 21, кластер 1С - 19, журналы - 11, SNMP-сеть - 7. Остальные экраны были посвящены Docker, сайтам, порталам и периферийным устройствам.
Разница между общим количеством панелей и числом запросов объясняется текстовыми блоками, строками-разделителями и элементами, которые не обращаются к базе. Но даже 217 запросов при интервале в шесть часов и обновлении раз в 30 секунд - значительная нагрузка. Поэтому при попытке настроить публичный мониторинг Grafana важно считать не только количество дашбордов, но и число реальных обращений к источникам.
Почему отдельный тенант безопаснее обезличивания
Изначально можно пойти по простому пути: взять рабочий экран и заменить имена серверов, подсетей и баз. Однако такой подход быстро превращается в ручную проверку сотен элементов. Недостаточно скрыть hostname: в панелях могут остаться адреса сетевых узлов, названия баз 1С, имена внутренних сервисов, списки процессов и фрагменты логов.
Даже одна забытая подпись способна раскрыть больше, чем планировалось. Поэтому демо лучше размещать в отдельной организации Grafana. Например, для витрины можно создать тенант `demo-retail` со своим `accountID`, собственными дашбордами и изолированным набором временных рядов. Рабочие данные в такую организацию физически не попадают.
Название `demo` само по себе ничего не гарантирует. В тестовой организации вполне могут находиться настоящие адреса серверов и продуктивные метрики. Именно поэтому Grafana публичный доступ к дашборду следует включать только после проверки состава отдельного тенанта, а не на уже существующей тестовой площадке.
Генерация вместо ручной поддержки
Отдельные "красивые" дашборды для презентаций быстро устаревают: меняется продукт, появляются новые панели, переименовываются метрики. Более устойчивый вариант - автоматически собирать витрину из тех же шаблонов, которые используются для клиентских установок.
Специальный скрипт может брать шаблоны `tpl-*`, удалять неподдерживаемые функции, назначать идентификаторы панелям и публиковать результат. Важное свойство такого процесса - идемпотентность. При повторной сборке существующие публичные ссылки должны сохраняться, иначе каждый релиз будет требовать рассылки новых адресов.
Что приходится менять в публичном режиме
Главное ограничение касается переменных. В публичной публикации Grafana не поддерживает переменные и запросы, зависящие от них. Если рабочий дашборд строится вокруг `$host`, в открытой версии нельзя рассчитывать на выпадающий список серверов.
Обычно остаются два варианта: показать агрегированные данные по всем узлам или зафиксировать значения непосредственно в запросах. Проверить результат можно через JSON публичного дашборда: список `templating.list` должен быть пустым.
Особого внимания требуют LogsQL-запросы. Простая подстановка символа `*` внутрь фильтра может привести к конструкции, которую VictoriaLogs не принимает, например `host:in(.*) level:in(*)`. В результате панели журналов становятся пустыми. Фильтры переменных нужно удалять полностью, оставляя корректное общее условие, а не механически заменять каждое значение звёздочкой.
Параметр `hide: true` тоже способен вызвать неожиданный эффект. В рабочем экране скрытый target часто используется как промежуточный ряд для трансформации. В публичном режиме такой target может исчезнуть вместе с данными, поэтому перед публикацией необходимо проверить, какие скрытые запросы участвуют в построении графика.
У каждой панели должен быть корректный `panel id`. Публичный API обращается к данным через адрес `/panels/
Аннотации и другие ограничения
С аннотациями ситуация ещё сложнее. Поддерживается только источник Grafana с типом `Annotations & Alerts`; организационные аннотации недоступны. Кроме того, запрос по тегам может вернуть совпадения со всех дашбордов организации, а не только с опубликованной витриной.
Если в одной организации находятся рабочие и демонстрационные экраны, наружу теоретически могут попасть подписи к внутренним инцидентам. Раздельный тенант устраняет этот риск одновременно с проблемой доступа к настоящим метрикам.
В публичной публикации также ограничены exemplars, library panels, Grafana Live, потоковые обновления, фронтенд-источники и источники данных через Reverse Proxy. Поэтому отдельные панели могут выглядеть корректно в авторизованной Grafana, но не работать после выдачи гостевой ссылки.
Нагрузка и защита от случайного отказа
Публичный экран - это не статичная веб-страница. При автообновлении каждый посетитель создаёт новые запросы. Если 217 панелей обновляются раз в 30 секунд, один открытый экран уже генерирует значительный поток обращений. При нескольких зрителях нагрузка увеличивается почти линейно.
Полезно ограничить диапазон времени, увеличить интервал обновления и сократить число тяжёлых таблиц и логовых панелей. Для презентаций часто достаточно обновления раз в минуту, а некоторые блоки можно заменить агрегированными значениями.
Отдельно следует контролировать инфраструктуру перед Grafana. Даже безопасная конфигурация может стать недоступной из-за nginx, если прокси ограничивает число соединений, размер ответа или частоту запросов. В демонстрационной системе именно собственный nginx способен положить витрину, хотя сама Grafana продолжает работать.
Что проверить перед публикацией
Финальная проверка должна выполняться в режиме анонимного пользователя. Нужно открыть ссылку в приватном окне браузера, проверить отсутствие авторизации, просмотреть исходный JSON и убедиться, что в нём нет внутренних адресов, имён серверов и рабочих идентификаторов.
Затем стоит проверить все панели, включая журналы, таблицы, аннотации и элементы с трансформациями. Важно убедиться, что данные действительно обновляются, ошибки API не скрываются интерфейсом, а отключённые функции не оставляют пустые блоки.
Такой подход превращает публичный дашборд из случайно открытого рабочего экрана в управляемую демонстрационную витрину. При грамотной изоляции, автоматической генерации и ограничении нагрузки можно обеспечить Grafana демонстрацию мониторинга онлайн, не раскрывая инфраструктуру и не создавая лишних рисков для продуктивной системы. паалийәт
