Migration
Depuis une stack d’observabilité auto-hébergée
Des équipes qui font tourner leur propre combinaison TSDB + stockage de logs + backend de tracing + visualiseur + couche d’alerting.
Temps estimé: ~1–2 semaines pour une équipe de taille moyenne ; un week-end pour une petite
Pourquoi les équipes migrent
- →Cinq services à mettre à jour indépendamment — un seul binaire à la place
- →L’astreinte réveillée pour la stack de monitoring elle-même, pas pour le produit
- →Le rééquilibrage du stockage et le calcul de rétention sont le travail de quelqu’un
- →Auth, SSO, multi-tenant rajoutés à la main
Ce qui se transfère tel quel
- ✓Expressions PromQL — collez-les telles quelles
- ✓Configs de scrape existantes via un agent shim léger
- ✓Tableaux de bord via import JSON (les panels se mappent 1:1 dans les cas courants)
- ✓Règles d’alerte — le format YAML est compatible
Ce qu’il faut adapter
- •Recording rules — Unimoni les stocke dans la même DB, même syntaxe
- •Les plugins de dashboard de la longue traîne peuvent ne pas avoir de widget 1:1 — ouvrez une issue, on l’ajoute
Étapes de migration
- 1.Déployez Unimoni à côté de la stack existante (un binaire, docker-compose)
- 2.Pointez un agent dessus ; vérifiez que les mêmes séries apparaissent
- 3.Importez les tableaux de bord via /api/v1/dashboards/import
- 4.Basculez une équipe non critique pendant une semaine — gardez l’ancienne stack en vie
- 5.Quand la confiance est là, pointez tous les agents et décommissionnez