Grafana дашборды: метрики твоего приложения наглядно

Твоя игра или сайт уже работает, ей пользуются реальные люди, и однажды кто-то пишет «у вас всё тормозит». Открываешь UptimeRobot — там зелёная галочка, сервис доступен. И дальше начинается гадание: то ли база данных перегружена, то ли сервер отвечает медленнее обычного, то ли просто у одного человека плохой интернет. Простой проверки «жив или мёртв» здесь мало — нужны цифры за последний час, день, неделю. Grafana дашборды как раз и закрывают этот разрыв: превращают разрозненные числа из логов и баз данных в графики, по которым видно, что происходит с приложением на самом деле.

Что такое Grafana простыми словами

Grafana — бесплатный инструмент с открытым кодом для построения дашбордов: страниц с графиками, счётчиками и таблицами, которые собирают числовые данные из разных источников и показывают их в одном месте. Сама Grafana ничего не измеряет и не хранит данные — она подключается к базе данных, системе метрик или другому источнику и рисует из его цифр наглядную картину.

Подходящая бытовая аналогия — приборная панель автомобиля. Датчики в двигателе, коробке передач и топливном баке сами по себе просто измеряют значения и никому их не показывают. Панель забирает эти значения и превращает в стрелки, цифры и лампочки, по которым водитель за секунду понимает состояние машины, не разбирая её на части. Grafana играет ту же роль для приложения: собирает показания из разных «датчиков» проекта и выводит их на один экран.

Дашборд в Grafana собирается из панелей. Каждая панель — это один график, счётчик или таблица, настроенный на конкретный вопрос: сколько запросов в секунду обрабатывает сервер, сколько памяти занято, сколько людей одновременно на сайте. Панели можно расставлять на странице как угодно, группировать по смыслу и обновлять с нужной частотой — раз в несколько секунд для «живого» мониторинга или раз в час для более спокойных метрик.

Важно сразу разделить два слова, которые в разговорах о мониторинге часто путают. Метрика — это число, снятое в конкретный момент времени: температура процессора, число активных пользователей, время ответа запроса. Дашборд — это уже готовая визуальная композиция из таких чисел, собранная под конкретную задачу. Одну и ту же метрику можно показать десятком разных способов: линейным графиком, столбиками, тепловой картой или просто крупной цифрой на весь экран — выбор зависит от того, что удобнее читать глазами.

Чем Grafana отличается от UptimeRobot

Ты уже разбирался с UptimeRobot — сервисом, который раз в несколько минут стучится на твой сайт и отвечает на один простой вопрос: работает сервис прямо сейчас или нет. Это внешняя проверка доступности, и для базового контроля её достаточно: узнать о падении сайта раньше, чем о нём напишут пользователи.

Grafana решает другую задачу — она не проверяет «жив или мёртв», а показывает, что происходит внутри работающей системы. Разница похожа на разницу между градусником и полноценным медицинским обследованием. Градусник за секунду скажет, есть температура или нет. Обследование покажет динамику показателей за недели, найдёт закономерности и подскажет, где именно проблема, даже если внешне человек выглядит здоровым.

На практике это значит следующее. UptimeRobot ответит на вопрос «сайт доступен?» одним словом — да или нет. Grafana ответит на вопросы совсем другого уровня: сколько процентов процессора занято прямо сейчас, сколько запросов в секунду обрабатывает сервер, сколько времени база данных тратит на выполнение одного запроса, сколько ошибок произошло за последний час и в какое именно время суток нагрузка была максимальной.

Есть и техническая разница в устройстве. UptimeRobot работает сам по себе: указал адрес сайта — и сервис сам его проверяет. Grafana так не умеет — ей обязательно нужен источник данных, откуда брать цифры. Источником может быть Prometheus (система, которая специально собирает и хранит метрики), сама база данных проекта, например Postgres, на которой работает Supabase, или лог-файлы сервера. Без подключённого источника Grafana — это просто пустой конструктор дашбордов без единой цифры внутри.

Из этого следует практичный вывод: UptimeRobot и Grafana не конкурируют, а дополняют друг друга. UptimeRobot можно поставить за пять минут в самом начале и держать как сторожа на случай полного падения. Grafana подключают позже, когда одного «работает или нет» уже недостаточно и хочется понимать, почему сервис работает медленнее обычного или растёт ли нагрузка со временем.

Зачем это вайбкодеру на курсе skillmake

Пока приложением пользуешься только ты сам во время разработки, метрики не нужны — любую проблему видно сразу на глаз. Всё меняется, когда у проекта появляются реальные пользователи. Тогда вопрос «работает ли сайт» перестаёт быть единственным важным. На первый план выходят вопросы вроде «почему сегодня всё медленнее, чем вчера» или «сколько человек реально играет в моё приложение по вечерам».

Без метрик на такие вопросы приходится отвечать вслепую: перезапускать сервер на всякий случай, гадать по жалобам пользователей в чате, надеяться, что проблема сама рассосётся. С дашбордом ответ виден на графике: например, нагрузка на базу данных начала расти именно в тот момент, когда открылась игровая сессия у большой группы пользователей, или конкретный запрос к API стал выполняться в три раза дольше после последнего обновления кода.

Для проекта курса — игры «Змейка» на Supabase — это особенно ценно на этапе, когда рекорды и профили хранятся в общей базе данных, а не только в браузере пользователя. В этот момент у проекта впервые появляется настоящая нагрузка: одновременные запросы к базе, всплески активности в определённые часы, возможные узкие места в запросах. Дашборд с метриками превращает вопрос «почему приложение тормозит» из гадания в задачу, которую можно решить по конкретным цифрам.

Второй практичный повод — рост доверия к своему продукту. Когда видишь на графике, что сервис стабильно держит нагрузку и время ответа не скачет часами, появляется спокойствие: приложение не просто «вроде работает», а измеримо работает как надо. Это особенно важно, если проект уже показывают инвесторам, партнёрам или первым платящим пользователям — цифры убеждают лучше, чем слова «у нас всё стабильно».

Как это работает на практике

Схема работы Grafana всегда одна и та же: источник данных → запрос → панель на дашборде. Разберём каждый шаг.

Источник данных — это то место, откуда Grafana берёт цифры. Самый частый вариант для небольшого проекта — база данных, на которой он работает. Например, если проект использует Supabase, под капотом там лежит обычная база Postgres, и её можно подключить к Grafana напрямую как источник данных. Другой распространённый вариант — Prometheus, специализированная система, которая сама постоянно опрашивает сервер и приложение, собирает метрики (загрузка процессора, память, число запросов) и хранит их историю. Grafana в этой связке не собирает данные сама, а только читает то, что уже насобирал Prometheus.

После подключения источника нужно объяснить Grafana, какую именно цифру показать на графике. Для этого пишется запрос — команда на языке конкретного источника данных: для Postgres это обычный SQL-запрос вроде «посчитай количество новых записей в таблице рекордов за каждый час», для Prometheus — запрос на его собственном языке PromQL. Запрос возвращает числа, а Grafana превращает их в линию, столбик или счётчик на панели.

Собирать дашборд с нуля панель за панелью — не единственный путь. У Grafana есть готовые шаблоны дашбордов под популярные источники: например, стандартный набор панелей для мониторинга Postgres или для сервера на Linux. Такой шаблон можно импортировать целиком и сразу увидеть базовые метрики, а потом донастроить под свои задачи — убрать лишние панели, добавить нужные, изменить период обновления.

Что можно отслеживать на типичном дашборде для приложения:

• нагрузку на процессор и память сервера, где крутится приложение;
• количество запросов в секунду к API или сайту;
• время ответа сервера и отдельных запросов к базе данных;
• количество ошибок за выбранный период — по кодам вроде 500 или 429, о которых рассказано в статье про rate limit;
• число активных пользователей или сессий в реальном времени;
• размер базы данных и скорость её роста.

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

Источники данных: Prometheus, Postgres и другие

Выбор источника данных зависит от того, что именно хочется измерять. Если задача — следить за самим сервером: сколько занято процессора, памяти, диска — обычно ставят Prometheus. Это отдельная программа, которая работает рядом с приложением, регулярно опрашивает его и сервер, где оно крутится, и складывает результаты в свою базу данных, оптимизированную именно под хранение метрик во времени. Grafana в этом случае просто визуализирует то, что уже накопил Prometheus.

Если задача — следить за данными самого приложения: сколько пользователей зарегистрировалось, сколько рекордов сохранено, как быстро выполняются запросы к таблицам — источником становится сама база данных проекта. Для проекта на Supabase это означает подключение к его базе Postgres напрямую. Grafana умеет работать с Postgres из коробки: указываешь адрес базы, логин и пароль, и дальше можно строить графики прямо по содержимому таблиц — например, «количество новых игроков по дням» или «средний счёт за неделю».

Есть и третий частый вариант — облачные платформы, на которых развёрнуто приложение, сами предоставляют метрики в форматах, которые Grafana умеет читать напрямую, без промежуточного Prometheus. В этом случае настройка сводится к тому, чтобы указать Grafana адрес и ключ доступа к такому источнику.

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

Бесплатный вариант — Grafana Cloud

Ставить Grafana на собственный сервер для первого знакомства необязательно. У проекта есть облачная версия — Grafana Cloud, куда можно зарегистрироваться и начать работать в браузере, не разворачивая ничего у себя. В бесплатном варианте доступен ограниченный объём хранения метрик и логов — конкретные цифры лимитов и условия лучше смотреть на официальном сайте сервиса, они периодически меняются.

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

Второй плюс облачного варианта — не нужно самому следить за работоспособностью Grafana. Если поставить её на своём сервере, придётся отдельно заботиться, чтобы сама Grafana не упала, не переполнился диск от накопленных метрик и обновления устанавливались вовремя. В облаке этим занимается сервис, а тебе остаётся только настройка дашбордов и источников данных.

Типы панелей и как их читать

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

Линейный график — основной рабочий формат для показателей, которые меняются во времени: нагрузка на процессор, число запросов в секунду, время ответа сервера. По линии сразу видно тренд — растёт показатель, падает или держится ровно, — и заметны резкие всплески, которые стоит разобрать отдельно.

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

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

Тепловая карта показывает распределение значений — например, как время ответа запросов группируется по диапазонам: большинство укладывается в полсекунды, но есть заметная доля запросов, которые тянутся по нескольку секунд. Такой формат сложнее читать с ходу, но он полезен, когда среднее значение обманчиво — единичные медленные запросы прячутся за хорошим средним временем ответа.

Таблица нужна там, где важны не тренды, а конкретные записи: список последних ошибок с временем и текстом, топ самых медленных запросов за сутки. Графику такие данные показать неудобно, а таблица даёт возможность сразу увидеть детали.

Правило для новичка простое: не пытаться сразу освоить все типы панелей. На первом дашборде хватает линейного графика для одной-двух ключевых метрик и пары счётчиков с текущими значениями — остальные форматы добавляются по мере того, как появляются конкретные вопросы, на которые обычный график не отвечает.

Пример: дашборд для «Змейки» на Supabase

Разберём на учебном проекте, как это выглядит не в теории, а на практике. Допустим, игра уже прошла модуль про Supabase: рекорды и профили игроков хранятся в общей базе данных, а не только в localStorage браузера. Приложение выросло из личного эксперимента в проект, которым пользуются посторонние люди, и вопрос «что там происходит с базой» стал не праздным.

Первый шаг — подключить Postgres от Supabase как источник данных в Grafana, указав данные подключения из настроек проекта. Второй шаг — решить, какие три-четыре метрики действительно важны прямо сейчас, а не пытаться охватить всё сразу.

Разумный стартовый набор панелей для такого проекта:

• Новые рекорды за сутки — линейный график по количеству новых записей в таблице рекордов, сгруппированных по часам. Показывает, в какое время суток игра активнее всего.
• Всего игроков в базе — крупный счётчик с общим количеством уникальных профилей. Простая, но приятная метрика роста.
• Среднее время ответа запросов к базе — линейный график, который сигнализирует, если база начинает работать медленнее обычного, например при резком наплыве игроков.
• Ошибки за последний час — счётчик с количеством неудачных запросов. Ноль или близко к нулю — хороший знак, рост — повод посмотреть логи внимательнее.

Такой набор из четырёх панелей собирается за один вечер, даже если раньше ты никогда не писал SQL-запросы вручную — конкретные запросы под эти четыре метрики вполне по силам сформулировать вместе с ИИ-ассистентом, описав задачу простыми словами: «посчитай количество новых строк в таблице records за каждый час последних суток». Дальше дашборд можно донастраивать: добавлять панели под новые вопросы по мере того, как они возникают, и убирать те, на которые никто не смотрит месяцами.

Ограничения для новичка

Grafana — не инструмент вида «поставил и забыл». В отличие от UptimeRobot, где после одной настройки всё работает само, Grafana требует понимания того, откуда берутся данные и как их правильно спросить.

Первая сложность — язык запросов. Чтобы построить полезный график, нужно написать запрос к источнику данных: SQL для базы данных или PromQL для Prometheus. Без базового понимания того, как устроены таблицы в базе или что такое временной ряд метрик, запросы придётся собирать методом проб и ошибок, часто с помощью подсказок от ИИ-ассистента.

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

Третья сложность — интерпретация того, что видно на графике. Сам по себе всплеск на графике ничего не говорит о причине: нужно уметь сопоставить его с другими событиями — деплоем новой версии, ростом числа пользователей, ошибкой в коде. Grafana показывает данные, но объяснять их по-прежнему приходится человеку.

Из-за этого Grafana — инструмент, который нужно настраивать под конкретный проект и периодически пересматривать по мере его роста, а не разовая установка. Это нормально: как и с базой данных, разобраться с первым дашбордом обычно проще, чем кажется на старте, если начинать с одной-двух метрик, а не пытаться сразу построить панель на десятки показателей.

Когда Grafana избыточна

Для учебного проекта вроде «Змейки» с несколькими десятками пользователей полноценный дашборд Grafana, скорее всего, не нужен. На таком масштабе достаточно простых логов и стандартных инструментов платформы, где размещён проект: они и так покажут, сколько было запросов и не падал ли сервер. Настраивать источник данных, разбираться с языком запросов и строить панели ради нескольких десятков посетителей в день — трата времени, которое пригодится на что-то более важное для проекта на этом этапе.

Момент, когда Grafana становится оправданной, наступает не по календарю, а по конкретным признакам. Первый — когда пользователей становится достаточно много, чтобы нагрузка на сервер и базу данных заметно колебалась в течение дня, и хочется понимать эту динамику, а не гадать по ощущениям. Второй — когда появляются жалобы на скорость работы и нужно точно понять, в каком именно месте цепочки происходит задержка: в самом сервере, в базе данных или где-то ещё. Третий — когда проект вырастает настолько, что за его стабильностью следит уже не один человек, и общий дашборд становится удобным способом всей команде смотреть на одни и те же цифры.

До этого момента разумнее держать простую связку: UptimeRobot для контроля доступности и обычные логи для разбора конкретных инцидентов. Grafana имеет смысл добавлять, когда эта связка перестаёт отвечать на вопросы, которые реально возникают по ходу работы над проектом.

Частые ошибки новичка при первом дашборде

Первая ошибка — пытаться построить сразу большой дашборд на двадцать панелей. Такой дашборд трудно поддерживать, половина панелей быстро устаревает или дублирует друг друга, а найти на нём действительно важную цифру в момент проблемы становится сложнее, а не проще. Лучше начать с трёх-четырёх метрик, которые отвечают на конкретные вопросы, и расширять дашборд постепенно.

Вторая ошибка — открыть базу данных для Grafana без ограничений доступа, чтобы «не разбираться с настройками». Источник данных стоит подключать с отдельным пользователем базы, у которого есть права только на чтение, а не на изменение данных — тогда даже ошибка в запросе на панели не сможет случайно испортить таблицы проекта.

Третья ошибка — ставить слишком частое обновление панелей там, где это не нужно. Обновление дашборда каждые несколько секунд оправдано для мониторинга в реальном времени во время инцидента, но для повседневного наблюдения достаточно интервала в несколько минут — это меньше нагружает и источник данных, и саму Grafana.

Четвёртая ошибка — реагировать на любой скачок на графике как на катастрофу. Отдельный всплеск нагрузки может быть совершенно нормальным событием — например, реакцией на пост в соцсетях или обычным пиком вечерней активности. Прежде чем что-то чинить, стоит посмотреть на график за более длинный период и понять, разовое это событие или начало устойчивой проблемы.

Пятая ошибка — забыть про дашборд сразу после того, как он собран. Метрики полезны только тогда, когда на них действительно смотрят хотя бы изредка, а ещё лучше — когда на самые важные из них настроены оповещения. Дашборд, который никто не открывает месяцами, ничем не отличается от его отсутствия.

Как подключить Grafana к своему проекту

Если решил попробовать, порядок действий примерно такой.

Сначала регистрируешься в Grafana Cloud и заходишь в панель управления. Дальше в разделе источников данных добавляешь свой — например, Postgres, указав адрес базы, порт, имя пользователя и пароль. Для проекта на Supabase эти данные обычно можно найти в настройках проекта в разделе, связанном с подключением к базе данных.

После того как источник подключён и Grafana успешно проверила соединение, переходишь к дашборду. Проще всего начать не с пустой страницы, а с готового шаблона под Postgres из встроенной библиотеки — он сразу покажет базовые метрики вроде числа активных подключений к базе и времени выполнения запросов. Дальше добавляешь собственные панели под конкретные вопросы своего проекта: например, график числа новых записей в таблице рекордов за последние сутки.

Каждая новая панель настраивается одинаково: выбираешь источник данных, пишешь запрос, который возвращает нужные числа, выбираешь тип визуализации — линию, столбики или крупный счётчик — и даёшь панели понятное название. Если запрос написать самостоятельно сложно, можно попросить ИИ-ассистента сформулировать SQL-запрос под конкретную задачу — точно так же, как ты обычно ставишь ему задачи по коду проекта, только здесь задача звучит как «посчитай количество записей за каждый день последней недели».

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

Оповещения можно направить не только на почту, но и в мессенджер — многие сервисы, включая Grafana Cloud, поддерживают отправку уведомлений в Telegram через бота. Для проекта, где уже есть привычка следить за уведомлениями в Telegram, это удобнее, чем регулярно проверять почту вручную: сообщение о проблеме приходит туда же, где и остальные рабочие уведомления.

Отдельно стоит подумать о правах доступа для пользователя базы данных, от имени которого Grafana подключается к Postgres. Разумная практика — завести отдельного пользователя только с правом на чтение таблиц, без права их изменять или удалять. Тогда даже неудачно составленный запрос на панели дашборда не сможет случайно повредить данные проекта, а сама Grafana останется исключительно инструментом наблюдения, а не точкой риска для боевой базы.

Частые вопросы

Grafana — это то же самое, что UptimeRobot?

Нет. UptimeRobot отвечает только на вопрос, доступен ли сервис прямо сейчас, простой периодической проверкой. Grafana строит детальные графики по метрикам — нагрузке, времени ответа, количеству запросов — и для этого нуждается в источнике данных вроде базы данных или Prometheus. Подробнее про принцип работы внешней проверки — в статье про UptimeRobot.

Нужен ли отдельный сервер, чтобы начать пользоваться Grafana?

Нет, для старта подходит облачная версия Grafana Cloud — регистрируешься и работаешь через браузер, без установки чего-либо на свой сервер. Свой сервер под Grafana имеет смысл разворачивать позже, если облачного варианта перестанет хватать.

Какой источник данных выбрать для проекта на Supabase?

Проще всего подключить напрямую базу Postgres, на которой работает Supabase — она уже содержит все нужные данные о таблицах проекта. Для метрик самого сервера, где крутится приложение, отдельно подключают Prometheus.

Нужно ли знать SQL, чтобы пользоваться Grafana?

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

Заменяет ли Grafana логи приложения?

Нет, это разные инструменты для разных целей. Логи — это подробная текстовая запись событий, полезная для разбора конкретного инцидента. Grafana — это агрегированные числовые метрики за период времени, полезные для наблюдения за общей динамикой. На практике их обычно используют вместе.

Стоит ли новичку настраивать Grafana сразу, ещё до первых пользователей?

Обычно нет смысла. Пока проектом пользуешься только ты сам во время разработки, любые проблемы видно и без дашбордов. Grafana становится полезной, когда появляется заметная реальная нагрузка и вопросы вроде «почему сегодня медленнее обычного» начинают возникать регулярно.

Заключение

Grafana дашборды закрывают ту часть мониторинга, до которой не дотягивается простая проверка доступности: они показывают не факт «сайт работает», а картину того, как именно он работает — под какой нагрузкой, с какой скоростью и в какие моменты возникают проблемы. Для учебного проекта это, скорее всего, преждевременно, а вот для приложения с реальными пользователями и растущей базой данных — законный следующий шаг после UptimeRobot. Начинать стоит с одного источника данных и пары понятных панелей, а не с попытки сразу построить дашборд на все случаи жизни: инструмент раскрывается постепенно, вместе с ростом самого проекта.