Migrer ses projets Sentry vers GlitchTip en moins d'une heure

En août 2026, trois issues ont accumulé suffisamment de rapports dans le dépôt getsentry/self-hosted pour constituer un signal de migration clair. L'issue #4301 documente un deadlock du consumer Kafka ingest-monitors après mise à jour vers 26.4.1 : le groupe consumer reste joint, mais CURRENT-OFFSET cesse d'avancer. Conséquence directe — tous les moniteurs de crons basculent en erreur avec un backfill manqué, et la fonction Crons devient inopérante à l'échelle de l'organisation entière. Le problème se manifeste uniquement sur des instances avec données accumulées (plus de 1,2 million de lignes dans sentry_monitorcheckin) ; un redémarrage des containers n'apporte qu'un répit de quelques minutes. L'issue #4306 signale que tous les consumers Snuba impriment en boucle l'erreur 'Failed to read directory /etc/sentry-options/values: No such file or directory' — fermée sans correctif officiel avec le statut 'not planned'. L'issue #4321 concerne la version 26.4.2 : les containers seaweedfs-1 et web-1 sont déclarés unhealthy au démarrage sur des installations x86_64, rendant Sentry impossible à démarrer de façon fiable. Ces trois régressions combinées forment un argument solide pour sortir du cycle de mises à jour Sentry self-hosted, au moins temporairement.

Ce guide suppose que GlitchTip est déjà déployé et opérationnel sur votre VPS. Si ce n'est pas le cas, l'article 'Héberger GlitchTip v6 sur VPS avec Docker Compose' couvre l'installation de zéro — consultez-le en premier. Pour la migration elle-même, vous avez besoin de trois éléments concrets : un accès administrateur à votre instance Sentry self-hosted (pour lire les DSN existants et exporter la configuration des alertes), un accès administrateur à votre instance GlitchTip (pour créer les projets équivalents et récupérer les nouveaux DSN), et la liste des variables d'environnement ou fichiers de configuration de chaque application qui contient la valeur SENTRY_DSN ou équivalent. La migration s'effectue projet par projet. Si vous avez cinq projets Sentry, vous aurez cinq projets GlitchTip à créer et cinq variables à permuter. Prévoyez environ dix minutes par projet, la première fois ; les suivantes prennent deux à trois minutes chacune.

GlitchTip ne réimplémente pas les SDK : il consomme le même protocole fil que Sentry, ce qui signifie que tout SDK officiel Sentry fonctionne sans modification. Les langages et frameworks les plus courants sont couverts nativement. En Python, sentry-sdk s'intègre avec Django, Flask, FastAPI et Celery. En JavaScript et TypeScript, @sentry/browser, @sentry/node, @sentry/nextjs et @sentry/vue fonctionnent directement. En Ruby, sentry-rails et sentry-ruby sont supportés. Go dispose de getsentry/sentry-go. PHP peut utiliser sentry/sentry-laravel ou sentry/sentry-symfony. Java et Android ont leurs SDK officiels. La seule option à désactiver dans certains SDK est auto_session_tracking — GlitchTip ne supporte pas le suivi de session en temps réel, mais cette fonctionnalité n'affecte pas la remontée d'erreurs. Le paramètre traces_sample_rate pour le tracing de performance est pris en charge depuis GlitchTip v6.1 avec DuckDB activé.

Les événements n'arrivent pas dans GlitchTip. Vérifiez d'abord que le DSN est syntaxiquement correct : la forme attendue est https://<clé>@votre-domaine.com/<id>. Si votre instance GlitchTip est derrière un reverse proxy, assurez-vous que les en-têtes X-Forwarded-For et X-Forwarded-Proto sont transmis — un proxy mal configuré peut renvoyer des erreurs 400 ou 413 silencieuses du côté applicatif. Consultez les logs du container GlitchTip (docker compose logs web) pour confirmer la réception. Le DSN est rejeté avec une erreur 401 ou 403. Le plus souvent, la clé publique dans le DSN ne correspond pas au projet GlitchTip cible. Chaque projet a sa propre clé — vérifiez que vous avez copié le DSN depuis le bon projet. Si l'erreur persiste, vérifiez que l'organisation et le projet existent bien et que le compte utilisé a les droits d'écriture. Le groupement des erreurs ne ressemble pas à Sentry. GlitchTip utilise son propre algorithme de fingerprinting. Les erreurs du même type seront groupées, mais la correspondance avec les groupes Sentry n'est pas garantie — surtout pour les exceptions avec des stacktraces dynamiques. C'est un comportement attendu, pas un bug. Si vous avez des règles de fingerprinting personnalisées dans Sentry, recréez-les dans GlitchTip via l'option 'Fingerprinting' du projet.

Si vous n'avez pas encore d'instance GlitchTip en production et que vous souhaitez sortir de Sentry self-hosted sans repartir sur un autre outil complexe à opérer, un VPS 2 Go de RAM suffit pour démarrer GlitchTip v6 en configuration tout-en-un. L'installation complète — Docker Compose, nginx en reverse proxy, certificat TLS, variables d'environnement — est documentée dans l'article dédié 'Héberger GlitchTip v6 sur VPS avec Docker Compose'. Une fois l'instance en place, la migration depuis Sentry se fait selon la procédure décrite dans cet article : créer les projets, récupérer les DSN, permuter les variables. Le temps total entre la création du VPS et la réception du premier événement dans GlitchTip est généralement inférieur à une heure, en comptant l'installation et la migration de deux à trois projets. Pour les équipes qui suivent plusieurs applications en production, c'est une fenêtre de migration réaliste — sans interruption de service côté applicatif, puisque le seul geste visible est un redémarrage du process après le changement de variable.