Garder un œil sur 4 000 serveurs Discord : Grafana, PostHog et ce qu'ils nous ont montré

AlphaCloud tourne sur un peu plus de 4 000 serveurs Discord, répartis sur quatre shards. Ce sont quatre processus, chacun servant une partie des serveurs, et tous parlent à la même API.

À cette taille, un problème se manifeste rarement en cassant quelque chose. Bien plus souvent, tout fonctionne, simplement de façon plus coûteuse, plus lente ou plus bruyante que nécessaire. C'est pourquoi nous avons reconstruit notre monitoring en septembre 2026. Cet article montre à quoi il ressemble et ce qu'il nous a montré pendant les premières semaines.

Deux outils, deux questions

Grafana répond à la question : que fait le bot ? Le bot et l'API envoient des métriques à Prometheus (requêtes, temps de réponse, taux d'erreur, réponses de Discord, utilisation de l'IA), et les logs vont dans Loki. Chaque nœud serveur a sa propre pile, et Grafana n'est accessible que par un réseau privé, pas depuis Internet.

PostHog répond à la question : que vivent les gens sur nos sites ? Pages vues, erreurs du navigateur, temps de chargement et, avec consentement, sessions enregistrées. PostHog ne démarre qu'après ton accord dans la bannière des cookies.

La séparation est voulue. Grafana regarde les machines, PostHog les interfaces. Faire entrer les deux dans un seul outil, c'est se retrouver soit avec des données utilisateurs dans les logs serveur, soit avec la charge serveur dans l'analyse produit.

Ce qu'il a trouvé

Une boucle qui produisait la moitié du trafic

Les sondages avec une heure de fin sont clôturés par une tâche de fond qui vérifie chaque minute si quelque chose a expiré. Elle le faisait pour chaque serveur individuellement. Avec environ 1 000 serveurs par shard et quatre shards, cela faisait environ 70 requêtes par seconde, presque toutes répondant « rien n'a expiré ».

Nous ne l'avons remarqué que dans Grafana, une fois que nous avons ventilé les requêtes du bot vers l'API par chemin : ce seul endpoint représentait plus de la moitié de tout le trafic. Tout fonctionnait. Il portait simplement une charge que personne n'avait demandée.

Désormais, chaque shard demande une fois par minute : « Quels serveurs ont un sondage expiré, tout simplement ? » et ne récupère les détails que pour ceux-là. Environ 4 200 requêtes par minute sont devenues à peu près quatre.

Trois millions de fois « pas configuré »

Même schéma, autre endroit : plusieurs modules (entrées de support, absences, liste de l'équipe, statistiques du bot, newsletter) lisaient régulièrement les réglages de chaque serveur dans leurs boucles. Sur la plupart des serveurs, un module donné n'est pas configuré du tout, la réponse était donc « introuvable ». Environ trois millions de fois par jour.

La correction n'a rien de spectaculaire : un « pas configuré » est maintenant mémorisé pendant 30 minutes. C'est sûr uniquement parce que chacun de ces modules envoie une mise à jour au bot dès qu'il est enregistré dans le panel web, configurer un module ne veut donc jamais dire attendre 30 minutes.

Les pannes de Discord ne sont pas nos bugs

Le salon d'erreurs de notre équipe publiait chaque action échouée comme « Runtime Error », avec une référence unique et tout le reste. Y compris les moments où Discord lui-même répondait par une erreur serveur. Ce n'est ni un bug de notre côté ni quelque chose que nous pouvons corriger, et cela s'affichait dans le salon exactement comme un vrai défaut.

Aujourd'hui, c'est enregistré comme un avertissement, et on dit au membre de réessayer dans quelques secondes au lieu de lui proposer un lien pour signaler un bug. Un salon d'erreurs où la moitié des messages ne sont pas des erreurs finit par ne plus être lu. Et là, on rate la vraie.

Une attaque qui a duré une minute

Un après-midi de fin septembre, notre page d'accueil a reçu un peu plus de 500 000 requêtes en une minute, depuis de nombreux pays à la fois. La plupart ont été arrêtées avant d'atteindre nos serveurs, et une minute plus tard le trafic était revenu à la normale.

Nous ne l'avons pas vue parce que quelque chose est tombé. Nous l'avons vue parce que le chiffre ne collait pas avec le reste du graphique. C'est le vrai travail du monitoring : non pas donner l'alerte quand tout brûle, mais montrer où quelque chose ne correspond pas à la normale.

Ce que notre monitoring ne voit volontairement pas

Les règles ici comptent autant que les tableaux de bord :

• Aucune adresse IP de visiteur dans les logs. Notre politique de confidentialité le promet, nous les retirons donc à deux endroits : quand le log d'accès est écrit et une nouvelle fois avant qu'il soit stocké.
• Aucun ID de serveur, d'utilisateur ou de message dans les métriques. Chaque métrique n'est ventilée que par des attributs grossiers (module, classe de statut, shard). Cela protège les données et garde la base de métriques légère.
• Les enregistrements de session montrent notre interface, pas ton contenu. Seul le texte qui vient mot pour mot de nos fichiers de traduction reste lisible. Les noms de serveurs, de salons et d'utilisateurs, les saisies et les aperçus sont masqués. Si la liste des textes autorisés ne peut pas être chargée, tout est masqué.
• Tout sur le site seulement après consentement. Ce qui fait aussi des chiffres de ce côté une borne inférieure. Pour le vrai nombre de pages vues, nous regardons les totaux anonymes de notre fournisseur réseau.

Les détails se trouvent dans la politique de confidentialité.

Ce que nous en retenons

Ce qui coûte cher est rarement ce qui est cassé. Aucune des découvertes ci-dessus n'a produit d'erreur. Elles ont produit de la charge, des coûts et du bruit, et sans mesurer on ne voit rien de tout cela.

Interroger serveur par serveur ne passe pas à l'échelle. Les deux grandes découvertes suivaient le même schéma : une boucle sur chaque serveur qui interroge chacun individuellement. La réponse est presque toujours la même question, posée une seule fois pour tous.

Une alerte doit être rare, sinon ce n'en est pas une. C'est pourquoi seul Grafana notifie l'équipe, et seulement pour ce qui demande une intervention. Les nouveaux types d'erreurs de PostHog arrivent dans le salon sans ping.

Si tu gères toi-même un serveur Discord et que tu veux voir les modules mentionnés ici : les sondages, les entrées de support et les absences se trouvent dans le panel web, et ils sont décrits dans la documentation.