Homelab 17 : vos erreurs vous trouvent, avec GlitchTip au lieu de Sentry

Niveau IntermédiaireTemps estimé 1 hÀ lire avant Homelab 1 : Proxmox, la base sous chaque serviceUn mot inconnu ? Lexique

Quand un service plante à 3 h du matin, vous l'apprenez des jours plus tard, par hasard, dans un journal. Un traqueur d'erreurs renverse ça : chaque service envoie ses erreurs au même endroit, regroupées pour que mille plantages identiques fassent une ligne, avec le moment où ça a commencé et la dernière fois. Sentry est la référence ; auto-hébergé, il demande une douzaine de conteneurs et 16 Go de RAM. GlitchTip parle le même protocole avec trois.

Chaque service signale ses propres erreurs au traqueur avec le même SDK que Sentry ; un script peut en envoyer une d'un seul curl. Les erreurs sont regroupées en tickets : mille plantages identiques font une ligne, avec la première et la dernière fois qu'ils sont arrivés.

Un peu d'histoire

Sentry a commencé en 2008 comme un petit greffon pour Django qui collectait les erreurs du code en production ; il est devenu la référence du suivi d'erreurs, et sa licence a changé par la suite. GlitchTip, lancé en 2020, est une alternative libre qui parle le protocole de Sentry, si bien que les bibliothèques officielles de Sentry lui envoient leurs erreurs sans rien changer à votre code.

1. Le lancer

GlitchTip tourne en un conteneur web, PostgreSQL et Valkey (ou Redis). Suivez l'installation Docker Compose officielle, épinglez les versions, et fermez les inscriptions une fois votre compte créé. Deux réglages nous ont évité une panne silencieuse :

GLITCHTIP_EMBED_WORKER=true sur le conteneur web si vous ne lancez pas de worker séparé. Sans worker, les événements sont acceptés et jamais traités.
un service migrate ponctuel dans le fichier compose : la base n'est pas migrée toute seule au démarrage.

Gardez-le sur votre réseau domestique ou votre réseau privé (Homelab 6) : vos erreurs décrivent vos points faibles.

2. Brancher vos services

Créez un projet par service ; chacun reçoit son propre DSN, l'adresse à laquelle son SDK signale. N'importe quel SDK Sentry marche : réglez le DSN et initialisez-le au démarrage. Un script shell sans SDK peut signaler par une seule requête vers la route d'enregistrement du projet, par exemple quand une tâche de nuit échoue.

Pièges

Prouvez-le de bout en bout le jour de l'installation : envoyez un événement de test depuis chaque service et voyez-le arriver en ticket. Un traqueur qui perd des événements en silence est pire que rien, parce que vous croyez que personne n'a planté.

Gardez les DSN hors de vos dépôts : mettez-les dans l'environnement de chaque service. Un DSN permet à n'importe qui d'inonder votre traqueur.

Sources

Utile ? Dites-nous ce qu'il faut mesurer ensuite.