Миграция платформ наблюдаемости редко бывает простой задачей. Вам по-прежнему приходится балансировать между рисками (не нарушить работу дежурных служб), масштабом (не пытаться перенести всё сразу) и организационными изменениями (побудить команды проверить и внедрить новые рабочие процессы). Цель этой статьи — поделиться типичными подходами, которые помогут вам справиться с этой задачей, когда вы будете готовы к миграции с использованием инструментов на основе открытых стандартов.
Мы сосредоточимся на миграциях, при которых метрики, трассировки и журналы уже проходят через инструменты с открытым исходным кодом и открытыми стандартами, такие как Prometheus, OpenTelemetry (OTLP) и Fluent Bit. В таких средах миграцию обычно можно осуществить путем перенаправления конвейеров, переноса только самых важных панелей мониторинга и оповещений, а также параллельного запуска до тех пор, пока вы не будете уверены в переходе.
«Открытые стандарты могут упростить процесс миграции, но переход к открытым стандартам может стать отдельной волной миграции».
Если у вас сегодня нет инструментария на основе открытых стандартов, потребуется дополнительный шаг: перенастройка инструментария. При использовании проприетарных агентов, SDK или закрытых форматов сбора данных переход на другую платформу часто означает замену инструментария во всех сервисах — это может занять недели или даже месяцы в зависимости от размера парка, частоты релизов и требований к охвату. Другими словами, открытые стандарты могут упростить процесс миграции, но переход к ним может стать отдельной волной миграции.
Далее мы рассмотрим наиболее надежные пошаговые шаблоны, которые команды используют для безопасной миграции, сохраняя при этом полную видимость на протяжении всего процесса.
Как выполнить миграцию с помощью инструментов с открытым исходным кодом
Планирование: определите, что означает «успех»
Перед началом миграции задокументируйте три вещи:
- Какие сервисы входят в сферу охвата первой волны миграции (в идеале — сначала сервисы с меньшим воздействием)?
- Какие команды владеют этими сервисами и будут отвечать за валидацию и утверждение?
- Какие панели мониторинга и оповещения являются обязательными для повседневной работы; все остальное второстепенно.
Эта документация станет вашим ориентиром при расстановке приоритетов в работе между командами.
Этапы миграции
Шаг 1: Расставьте приоритеты по тому, что действительно важно
Прежде чем проводить инвентаризацию всего, определите, что вам действительно нужно перенести.
Составьте целенаправленный список:
- Определите, какие дашборды инженеры дежурной службы действительно используют во время инцидентов, на какие ссылаются инженеры по надежности сайта (SRE) при проверке целевых показателей уровня обслуживания (SLO) или на какие полагается руководство на еженедельных совещаниях. Часто остается 10–20 дашбордов.
- Задокументируйте оповещения, которые вызывают кого-то ночью, фигурируют в руководствах по эксплуатации или защищают сервисы, критичные для доходов. Обычно остается 20–50 оповещений.
Рассматривайте их как артефакты первой фазы миграции. Все остальное может подождать.
Для каждой панели мониторинга и каждого оповещения задокументируйте:
- Где он находится на вашей текущей платформе (URL, папка, владелец).
- Какие команды владеют им и полагаются на него.
- Любые известные особенности («этот оповещение слишком часто срабатывает», «мы игнорируем эту панель»), чтобы нужные люди могли проверить и утвердить их во время миграции.
Критически важно понимать, какие данные на самом деле лежат в основе решений. Команды часто обнаруживают, что платят за хранение огромных объемов телеметрии, которой никто не пользуется.
Шаг 2: Проведите инвентаризацию вашей телеметрии
Вы не сможете перенести то, что не задокументировали. Для сервисов, входящих в сферу охвата, задокументируйте, откуда берется телеметрия и как она проходит через вашу существующую инфраструктуру с открытым исходным кодом.
- Метрики: как настроена ваша система Prometheus? Задокументируйте, какие сервисы сканируются напрямую серверами Prometheus, а какие используют экспортеры (узел, Kubernetes, база данных, облако). Составьте схему того, как метрики попадают на вашу текущую платформу — используете ли вы нативную удаленную запись, несколько конечных точек удаленной записи или федерацию между экземплярами Prometheus?
- Трейсы: Проверьте вашу инструментацию OpenTelemetry. Какие сервисы используют SDK OpenTelemetry, а какие — автоматическую инструментацию? Составьте схему потока от инструментированных сервисов через ваши коллекторы OpenTelemetry к вашему текущему бэкенду. Задокументируйте любые процессоры, сэмплеры или преобразования в ваших конвейерах коллекторов.
- Логи: Задокументируйте свою конфигурацию Fluent Bit. Откуда собираются логи и какие плагины вывода используются в настоящее время? Если вы используете централизованный конвейер или маршрутизатор логов, поймите, как данные проходят через эту архитектуру.
«Поймите свою текущую маршрутизацию данных, чтобы вы могли уверенно добавить новый бэкэнд в качестве параллельного пункта назначения, не нарушая существующих потоков».
Цель здесь — понять текущую маршрутизацию данных, чтобы вы могли уверенно добавить новый бэкэнд в качестве параллельного пункта назначения, не нарушая существующих потоков.
Шаг 3: Добавьте новый бэкэнд в качестве второго пункта назначения
Вместо того чтобы полностью отказываться от текущей платформы, внедрите новый бэкэнд в качестве теневого пункта назначения для поднабора сервисов. Оставьте обе системы в рабочем состоянии, чтобы ваша команда сохраняла видимость на протяжении всего процесса миграции. Кроме того, перед полным переходом необходимо накопить достаточное количество исторических данных в новой платформе наблюдаемости. Объем исторических данных варьируется в зависимости от компании и должен быть ключевым фактором при принятии решения.
Метрики
Если вы используете удаленную запись Prometheus, добавьте второй конечный пункт удаленной записи, указывающий на новый бэкэнд (или сначала перенаправьте некритические сервисы). Если вы используете серверы Prometheus для сбора данных, либо перенастройте их для записи в новый бэкэнд, либо зеркалируйте собранные данные с помощью удаленной записи или федерации.
Если ваша новая платформа совместима с Prometheus, это в основном вопрос настройки; вы перенаправляете существующий трафик на другой конечный пункт, а не перестраиваете свой конвейер.
Трейсы
С помощью OpenTelemetry Collector добавьте дополнительный конвейер экспортера, который параллельно отправляет трассировки в новый бэкэнд (протокол OpenTelemetry → новый бэкэнд). Сохраняйте конфигурации максимально похожими на ваш существующий конвейер трассировок для прямого сравнения во время двойного запуска.
Платформы, которые изначально поддерживают протокол OpenTelemetry (OTLP), упрощают эту задачу; вы повторно используете те же экспортеры и процессоры OpenTelemetry, которым уже доверяете.
Логи
Если вы используете Fluent Bit, добавьте еще один выход, который отправляет журналы на конечную точку приема нового бэкэнда. Если у вас уже есть централизованный конвейер журналов или маршрутизатор, распределите данные оттуда, а не затрагивайте каждый поди приложения.
Шаг 4: Преобразование запросов и панелей мониторинга
Сначала сосредоточьтесь на основных запросах
Большинство проприетарных платформ либо используют язык, подобный PromQL, либо запускают собственный DSL на сериях и метках в стиле Prometheus. Ваш новый бэкэнд должен обеспечивать совместимость с PromQL или четкое сопоставление.
Начните с 80% сценариев использования:
- Простые временные ряды
: отдельные метрики с фильтрами, такими как
1`{env="prod", service="api"`} - Базовые агрегации:
1`sum`, `avg`, `max`, `histogram_quantile` - Сопоставление тегов и меток:
1`env:prod`→ `{env="prod"}`
Только после того, как это будет надежно работать, переходите к следующему:
- Арифметика между метриками
- Соединения и выражения с несколькими рядами
- Функции, специфичные для поставщика, или «магические» функции
Пересоздайте только критически важные дашборды
Используйте список приоритетов из шага 3 в качестве области охвата.
Для каждой панели инструментов:
- Экспортируйте определение панели (JSON/YAML/Terraform и т. д.) с вашей платформы.
- Воссоздайте его в новом бэкенде, используя переведенные запросы и эквивалентные типы панелей (временные ряды, таблицы, отдельные статистические данные).
- Сохраните макет и названия, чтобы инженерам, работающим по вызову, не приходилось заново осваивать навыки во время инцидентов.
Чтобы избежать разовой работы, определите несколько «золотых» шаблонов для каждого типа сервиса (API, задание, конвейер данных) и параметризуйте их с помощью меток/переменных (сервисы, среда, регион) для повторного использования.
Результат: ваши самые важные панели и запросы ведут себя одинаково в новом бэкенде, что сводит к минимуму неожиданности для тех, кто на них полагается.
Шаг 5: Перенос оповещений без потери охвата
Оповещения — это источник риска, поэтому к ним нужно относиться с осторожностью. Большинство платформ представляют оповещения в виде запроса, окна оценки и целей уведомления.
Переведите запросы для обеспечения поведенческой паритетности
Используйте результаты работы из шага 4. Для каждого оповещения преобразуйте запрос PromQL (или его эквивалент), описывающий условие. Сопоставьте пороговые значения и окна. Если старое оповещение гласит «срабатывать, если > 80 в течение 5 минут», убедитесь, что новое правило выражает ту же логику с использованием векторов диапазона или окон оповещения.
На данном этапе ваша цель — обеспечить поведенческую эквивалентность, а не перепроектировать систему.
Сначала сделайте маршрутизацию простой
Сопоставьте существующие пункты назначения Slack/PagerDuty/электронной почты с эквивалентными каналами в новом бэкенде. Максимально точно отразите текущее поведение, чтобы команды могли сравнивать оповещения один к одному. Отложите переработку маршрутизации или эскалации до тех пор, пока параллельный запуск не станет стабильным.
Начните с обязательных оповещений. Как только они будут работать стабильно и без сбоев в режиме двойного запуска, вы сможете решить, какие оповещения с более низким приоритетом вообще стоит переносить.
Шаг 6: Параллельная работа и проверка
На этом этапе службы, входящие в сферу охвата, отправляют одинаковую телеметрию в оба бэкенда, а ваши критически важные дашборды и оповещения существуют в новой системе. Теперь вы проводите проверку в реальных условиях.
Сохраните текущую платформу в качестве основного источника достоверной информации. Поощряйте инженеров, находящихся на дежурстве, открывать новые панели мониторинга наряду со старыми. Когда срабатывает оповещение, проверьте, сработало ли соответствующее оповещение в новом бэкенде, и сравните временные рамки и уровень серьезности. Эта фаза проверки имеет решающее значение. Правильная оценка поставщика решений для наблюдаемости означает подтверждение того, что они работают в реальных производственных условиях, а не только в тестовых сценариях.
На этом этапе вы в основном проверяете:
- Пробелы: оповещения, которые срабатывают в старой системе, но не в новой
- Лишний шум: оповещения, которые срабатывают чаще или с меньшей релевантностью в новой системе
- Проблемы с пользовательским интерфейсом: панели, которые трудно найти или интерпретировать в условиях стресса
Записывайте проблемы в общий документ или очередь тикетов, чтобы вы могли их систематически исправлять. Проводите параллельную работу достаточно долго, чтобы увидеть несколько реальных инцидентов, а не только синтетические тесты. Как только в новом бэкенде все будет проходить без происшествий, а ответственные команды проведут валидацию и одобрят этот этап, вы будете готовы двигаться дальше.
Шаг 7: Постепенный переход на новую систему
Как только команды освоятся, обновите руководства и документацию, чтобы ссылки и скриншоты указывали на новый бэкенд. Сделайте новый интерфейс пользователя стандартным видом для дежурств, рассматривая старую платформу как резервную.
Затем отключите оповещения в старой системе:
- Сначала отключите или понизьте уровень информационных оповещений.
- После нескольких инцидентов без проблем отключите оповещения на пейджер, чтобы вам не приходилось получать два оповещения по одной и той же проблеме.
- Наконец, сократите, а затем прекратите прием данных для полностью перенесенных сервисов.
Многие команды оставляют старый бэкэнд в режиме «только для чтения» на определенный период времени, а затем выводят его из эксплуатации, когда содержащиеся в нем данные больше не нужны. На этом этапе новая платформа становится вашим операционным источником достоверной информации.
Создайте основу для наблюдаемости с помощью открытых стандартов
В этой статье мы рассмотрели основные этапы миграции с одной платформы наблюдаемости на другую — без рискованной полной замены. Подход намеренно поэтапный: определите, что означает «успех», расставьте приоритеты только для тех дашбордов и оповещений, которые действительно важны, сопоставьте потоки телеметрии, добавьте новый бэкэнд в качестве параллельного пункта назначения, перенесите самое необходимое, запустите параллельную работу для проверки в реальных производственных условиях, а затем постепенно перенесите трафик и ответственность.
В Chronosphere мы также создали внутренние инструменты, помогающие автоматизировать ключевые части этого процесса — благодаря чему миграции проходят быстрее, становятся более повторяемыми и менее разрушительными для инженерных команд. Работая с Chronosphere, вы получаете оптимизированный процесс миграции, а также первоклассное сопровождение, помогающее планировать этапы, проверять соответствие и уверенно переходить на новую платформу.
Самое главное, что Chronosphere создана для работы с той открытой экосистемой, которую вы уже используете. Мы полностью совместимы с OpenTelemetry, Prometheus и другими открытыми стандартами — так что вы можете сохранить существующие инструменты и конвейеры, модернизируя при этом свой бэкенд на своих условиях.
Начните работу: [Скачайте полное руководство по миграции инструментов наблюдаемости] | [Запланируйте 30-минутную демонстрацию] | [Узнайте, как мигрировать инструменты наблюдаемости]
Подписывайтесь на наш канал в Телеграм
⚡ Подписаться