Сообщить об ошибкеКороткий ответ
Единого безопасного пути миграции нет — решение зависит от совместимости форматов данных, допустимого даунтайма видимости и критичности сохранения полной истории; типичный безопасный подход — параллельный запуск обоих стеков (dual write/dual scrape) в течение переходного периода, постепенный перенос дашбордов и алертов с верификацией эквивалентности, и только затем отказ от старой системы.
Как это работает подробнее
на переходный период оба стека работают одновременно — например, одни и те же цели scrape-ятся и старым, и новым Prometheus-совместимым решением, либо экспортёр логов пишет в оба хранилища параллельно. Это даёт возможность сравнивать результаты (одни и те же PromQL-запросы к старой и новой системе должны давать близкие значения) и постепенно, сервис за сервисом, переключать источник правды для дашбордов и алертов, оставляя старую систему как fallback до полной уверенности в новой.
Компромисс: длительный период параллельной работы двух стеков безопаснее, но удваивает затраты на инфраструктуру и требует синхронизации конфигурации в двух местах на время перехода; быстрая миграция "одним прыжком" дешевле и быстрее, но рискованнее с точки зрения пропуска инцидентов и потери данных. Длительность параллельного периода и объём переносимой истории должны определяться исходя из критичности сервисов и реальной частоты обращения к историческим данным, а не фиксированным дедлайном проекта миграции.
Пример кода
Неделя 1–2: новый стек scrape-ит те же target'ы параллельно со старым; дашборды "side-by-side" для сверки
Неделя 3: критичные SLO-алерты продублированы в обоих стеках; верификация на историческом инциденте
Неделя 4: алерты в старом стеке переведены в silent-режим (только логирование), новый стек — основной канал
Неделя 6: старый стек выключен; данные старого стека остаются доступны в режиме read-only до истечения retentionЧто использовать на практике
- Практика. критичные алерты переносятся последними и только после верификации, что новая система ловит те же случаи, что и старая (можно специально воспроизвести известный исторический инцидент и проверить, что новый стек бы его обнаружил); исторические данные (если формат несовместим напрямую) переносятся через batch-экспорт/импорт или просто остаются доступными в старой системе в режиме "только для чтения" до истечения их retention, без необходимости полной миграции старых данных в новый формат немедленно.
- Практика. Такой план даёт команде возможность на каждом этапе откатиться на старую систему при обнаружении расхождений, прежде чем полностью довериться новому стеку как единственному источнику алертинга.
Подводные камни
- Частые ошибки. выключать старую систему сразу после включения новой без периода параллельной работы, рискуя пропустить инцидент из-за недонастроенного алерта в новой системе или потерять доступ к истории; переносить все алерты и дашборды одним большим релизом вместо постепенной, проверяемой миграции по сервисам, что затрудняет локализацию проблем, если новая система ведёт себя иначе на каких-то запросах; не планировать явно судьбу исторических данных, из-за чего при аудите выясняется отсутствие данных за период миграции.