Миграция
С self-hosted-стека мониторинга
Команды, которые держат собственную связку TSDB + хранилище логов + tracing-бэкенд + визуализатор + слой алертинга.
Примерное время: ~1–2 недели для средней команды; одни выходные для небольшой
Почему команды переходят
- →Пять сервисов, которые обновляются по отдельности — вместо них один бинарь
- →On-call будят из-за самого стека мониторинга, а не из-за продукта
- →Ребалансировка хранилища и расчёт retention — чья-то постоянная работа
- →Auth, SSO, multi-tenancy прикручены руками
Что переносится как есть
- ✓PromQL-выражения — вставляются как есть
- ✓Текущие scrape-конфиги через тонкий shim-агент
- ✓Дашборды через JSON-импорт (для типовых случаев панели мапятся 1:1)
- ✓Правила алертов — формат YAML совместим
Что придётся адаптировать
- •Recording rules — Unimoni хранит их в той же БД, синтаксис тот же
- •Редкие dashboard-плагины из длинного хвоста могут не иметь виджета 1:1 — заведите issue, добавим
Шаги миграции
- 1.Поднимите Unimoni рядом с текущим стеком (один бинарь, docker-compose)
- 2.Направьте на него один агент; убедитесь, что появляются те же серии
- 3.Импортируйте дашборды через /api/v1/dashboards/import
- 4.Переведите одну некритичную команду на неделю — старый стек оставьте живым
- 5.Когда появится уверенность, направьте все агенты и выведите старый стек из эксплуатации