Grafana Cloud на свои VPS: какие данные и настройки можно перенести

Экспортированный дашборд выглядит почти оскорбительно скромно. Один JSON-файл, пара сотен строк, иногда несколько тысяч. Открываешь его и думаешь: вот и весь мониторинг, берём и несём на новый сервер. Но в этом файле нет ни одной точки данных. Есть описание: какой запрос выполнить, каким цветом закрасить порог, как назвать ось и в какой источник за этим всем идти. А сами наблюдения лежат в других системах, и у каждого графика на панели путь к ним свой.

Поэтому вопрос «что можно забрать из Grafana Cloud» на самом деле состоит из нескольких вопросов. Что из описания переедет почти без потерь? Что придётся собрать заново? Какую часть прошлого вообще стоит тащить с собой? Разберём это на одной воображаемой панели «Состояние сервиса заказов».

Одна панель, три дороги к данным

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

• Метрики. График ошибок строится запросом к источнику метрик. В типичной связке это Prometheus-совместимое хранилище и язык запросов PromQL. Данные тут — числовые ряды с метками.
• Логи. Таблица строк обращается к источнику логов, например к Loki. Данные тут — текст с набором меток, а запрос устроен совсем иначе, чем для метрик.
• Трассы. Список медленных операций берётся из источника трасс, например Tempo. Данные тут — деревья спанов с длительностями.

Когда вы экспортируете дашборд, Grafana умеет отдать его в формате JSON, а кроме этого есть отдельные способы поделиться панелью и сделать снимок. Об этом говорит документация Grafana по совместному использованию дашбордов и панелей. Но экспорт в JSON переносит описание панели, а не содержимое трёх хранилищ. Снимок, к слову, тоже не заменяет живой источник: это зафиксированная картинка момента, а не работающий график.

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

Почему график пуст, хотя импорт прошёл успешно

Самое частое разочарование выглядит так. Вы импортируете JSON в новую Grafana на своём сервере. Панели на месте, заголовки на месте, раскладка та же. И все графики пустые или с красной плашкой ошибки. Импорт ведь «удался». Что не так?

Причинная цепочка обычно такая, и её стоит пройти по шагам.

1. Панель ссылается на источник данных. В JSON записан не адрес сервера, а ссылка на источник: имя или уникальный идентификатор. Это удобно, потому что адрес живёт отдельно от дашборда.
2. В новой Grafana такого источника нет. Идентификатор из облачной организации не существует на вашем сервере. Импортёр принимает файл, потому что структура верна, но привязать запрос ему не к чему.
3. Даже если источник создан, он может называться иначе. Панель ищет ссылку по старому имени или идентификатору. Совпадения нет — запрос уходит в никуда или в источник по умолчанию, который вообще не про то.
4. Источник найден, но он пуст. Вы поставили новое хранилище метрик, но ещё ничего в него не пишете. Запрос корректен, ответ корректен, просто рядов ноль. График пуст честно.
5. Данные пишутся, но метки другие. Старый запрос фильтровал по метке, которую проставляла прежняя схема сбора, например по названию кластера или окружения. Новый сборщик такой метки не ставит. Запрос выбирает пустое множество.
6. Пропали имена метрик. Если вы меняли способ сбора, часть метрик может называться по-другому или вообще не собираться, и тогда выражение ссылается на несуществующий ряд.

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

Полезная привычка до импорта: открыть JSON и найти, на какие источники он ссылается. Их обычно мало, а перечень сразу показывает, что нужно создать на новой стороне и под какими именами.

Что принадлежит визуализации, а что — истории

Теперь разделим весь груз переезда на две кучки. В первой лежит то, что описывает, как смотреть. Во второй — то, на что смотреть.

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

Оповещения: три предмета и два формата

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

Второй нюанс — форматы. HTTP API оповещений и файловый провижининг описывают ресурсы по-разному, поэтому выгрузку из одного места нельзя слепо подсунуть другому. Выберите заранее, каким способом вы будете загружать правила на новом сервере, и экспортируйте в подходящем виде.

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

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

Источники данных и права: тихая смена правил

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

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

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

Люди и права. В документации отмечено, что права просмотра дашборда и доступность данных зависят от модели доступа. Из этого стоит сделать практический вывод: перенос дашборда не переносит автоматически ни тех, кто его смотрел, ни тех, кому разрешено видеть данные под ним. Пользователей, команды и разрешения на папки придётся продумать заново. Хороший момент для небольшой уборки: вспомнить, кто реально пользуется мониторингом, и не воспроизводить заодно пять лет накопленных исключений.

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

Срок хранения: считаем диск по сигналам, а не по дашбордам

Вот где чаще всего ошибаются в расчётах. Спрашивают: «У нас сорок дашбордов, сколько нужно диска?» Но дашборды занимают килобайты. Диск занимают наблюдения, а их объём определяется совсем другими величинами.

• Метрики: число активных рядов, частота сбора и срок хранения. Много меток с высокой кардинальностью — много рядов, и дашборды тут вообще ни при чём.
• Логи: сколько строк в сутки пишут сервисы, какой у них средний размер и как хорошо они сжимаются. Одно слишком разговорчивое приложение способно перевесить десяток тихих.
• Трассы: сколько запросов проходит через систему и какую долю вы сохраняете. Если сохранять всё, объём растёт вместе с трафиком; если выборочно, вы платите потерей редких случаев.

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

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

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

Что делать со старой историей

Теперь про вторую кучку, ту самую историю. У вас три честных варианта, и ни один не универсален.

1. Не переносить. Начать с чистого листа в день переключения. Самый простой путь. Если вы оставляете облачный доступ на время параллельной работы, старые данные остаются доступными там, пока вы его не отключите.
2. Держать облако в режиме чтения на переходный период. Новая система собирает свежие данные, старая служит архивом для расследований. Срок перехода равен сроку хранения, который вам нужен: прошло четырнадцать дней — старый архив можно закрывать. Важно заранее проверить условия своего тарифа и сроки хранения на стороне облака, чтобы не потерять доступ раньше времени.
3. Снять нужное вручную. Для отдельных важных периодов можно сохранить снимки панелей, отчёты разборов инцидентов или выгрузки результатов запросов. Это точечные артефакты, а не полноценная миграция хранилища, и ожидать от них возможности продолжить графики нельзя.

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

Минимальный стек вокруг нужных сигналов

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

Каркас получается таким:

• Grafana — витрина: дашборды, оповещения, пользователи.
• Хранилище метрик — в простом варианте Prometheus, который сам же и опрашивает цели. Пошаговая установка связки описана в материале как установить и настроить Grafana и Prometheus на VPS.
• Хранилище логов — когда понадобится, например Loki с агентом, который доставляет строки.
• Хранилище трасс — если действительно разбираете медленные запросы по трассам, например Tempo.

Порядок работ, который снижает риск:

1. Составьте список сигналов, которые используют дашборды и правила оповещений. Для каждого запишите источник, ключевые метки и нужный срок хранения.
2. Поднимите хранилища и убедитесь, что в них поступают данные. Только затем создавайте источники в Grafana под нужными именами.
3. Импортируйте дашборды и пройдите по каждому цепочкой проверки пустого графика из начала статьи.
4. Загрузите правила оповещений выбранным способом, настройте контактные точки и политики, отправьте тестовое уведомление.
5. Поработайте параллельно с облаком, сравнивая показания на одних и тех же панелях. Расхождение здесь обычно подсказывает, что не хватает метки или изменилась частота сбора.
6. Только после этого отключайте облачную сторону.

Что до железа. Эта нагрузка в основном дисковая и оперативная: хранилища любят быстрый диск и память под активные ряды и индексы. Быстрый NVMe здесь по делу, а root-доступ нужен, чтобы настроить службы, тома и правила файрвола. Среди тарифов VPS MAATRIX есть конфигурации от 1 vCPU, 2 ГБ памяти и 40 ГБ NVMe до 16 vCPU, 32 ГБ памяти и 320 ГБ. Но это только перечень ресурсов, а не обещание ёмкости: подходящий размер определяется вашим расчётом по сигналам, и лучше всего проверить его на пробном периоде работы с реальным потоком данных. Для небольшого проекта с одним-двумя сервисами и коротким сроком хранения может хватить скромной конфигурации, а нагруженные логи и трассы быстро потребуют больше диска и памяти. Локации выбирайте, исходя из того, где находятся ваши сервисы-источники и пользователи панелей: чем ближе агент к хранилищу, тем меньше забот с сетью.

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

Возвращаемся к панели заказов

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

• Раскладка, заголовки, пороги и стиль графиков — переехали вместе с JSON и теперь живут в вашей Grafana.
• График ошибок — работает после того, как создан источник метрик с ожидаемым именем и в хранилище пишутся ряды с теми же метками.
• Таблица логов — оживёт, когда появится хранилище логов и агент начнёт доставлять строки с прежними метками.
• Список медленных трасс — заработает, когда сервис начнёт отправлять трассы в новое хранилище.
• Правила оповещений по этой панели — загружены выбранным способом, а каналы доставки заведены заново с новыми секретами.
• Доступ — теперь определяется вашими пользователями и ролями, а не облачной организацией.

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