4.000 Discord servers in de gaten houden: Grafana, PostHog en wat ze ons lieten zien

AlphaCloud draait op iets meer dan 4.000 Discord servers, verdeeld over vier shards. Dat zijn vier processen die elk een deel van de servers bedienen en allemaal met dezelfde API praten.

Op die schaal laat een probleem zich zelden zien doordat er iets kapotgaat. Veel vaker werkt alles, alleen duurder, trager of luidruchtiger dan zou moeten. Daarom hebben we in september 2026 onze monitoring opnieuw opgebouwd. Dit artikel laat zien hoe die eruitziet en wat hij ons in de eerste weken liet zien.

Twee tools, twee vragen

Grafana beantwoordt de vraag: wat doet de bot? Bot en API melden metrics aan Prometheus (verzoeken, responstijden, foutpercentages, antwoorden van Discord, AI gebruik), en de logs gaan naar Loki. Elke servernode heeft een eigen stack, en Grafana is alleen bereikbaar via een privénetwerk, niet vanaf het internet.

PostHog beantwoordt de vraag: wat ervaren mensen op onze websites? Paginaweergaven, browserfouten, laadtijden en, met toestemming, opgenomen sessies. PostHog start pas nadat je in de cookiebanner akkoord gaat.

De scheiding is bewust. Grafana kijkt naar machines, PostHog naar interfaces. Wie beide in één tool propt, krijgt óf gebruikersgegevens in de serverlogs óf serverbelasting in de productanalyse.

Wat hij vond

Een loop die de helft van het verkeer veroorzaakte

Polls met een eindtijd worden gesloten door een achtergrondtaak die elke minuut controleert of er iets is verlopen. Dat deed hij voor elke server afzonderlijk. Met ongeveer 1.000 servers per shard en vier shards kwam dat neer op zo'n 70 verzoeken per seconde, bijna allemaal met het antwoord "niets verlopen".

We merkten het pas in Grafana, toen we de verzoeken van de bot aan de API per pad uitsplitsten: dit ene endpoint was meer dan de helft van al het verkeer. Alles werkte. Het droeg alleen een last waar niemand om had gevraagd.

Nu vraagt elke shard één keer per minuut: "Welke servers hebben überhaupt een verlopen poll?" en haalt alleen voor die servers details op. Ongeveer 4.200 verzoeken per minuut werden er zo'n vier.

Drie miljoen keer "niet ingesteld"

Hetzelfde patroon, een andere plek: meerdere modules (supportregistraties, afwezigheden, teamlijst, botstatistieken, nieuwsbrief) lazen in hun loops regelmatig de instellingen van elke server. Op de meeste servers is een bepaalde module helemaal niet ingesteld, dus het antwoord was "niet gevonden". Ongeveer drie miljoen keer per dag.

De fix is onspectaculair: een "niet ingesteld" wordt nu 30 minuten onthouden. Dat is alleen veilig omdat elk van deze modules de bot een update stuurt op het moment dat er in het webpanel wordt opgeslagen, dus een module instellen betekent nooit 30 minuten wachten.

Storingen bij Discord zijn niet onze bugs

Ons foutkanaal voor het team plaatste elke mislukte actie als "Runtime Error", met een unieke referentie en al. Dat gold ook voor momenten waarop Discord zelf met een serverfout antwoordde. Dat is geen bug aan onze kant en ook niets wat wij kunnen oplossen, en het stond in het kanaal er precies zo uit te zien als een echt defect.

Vandaag wordt het als waarschuwing gelogd, en krijgt het lid te horen dat hij het over een paar seconden opnieuw moet proberen, in plaats van een link om een bugmelding te doen. Een foutkanaal waarin de helft van de berichten geen fouten zijn, wordt op een gegeven moment niet meer gelezen. Dan mis je de echte.

Een aanval die één minuut duurde

Op een middag eind september kreeg onze homepage iets meer dan 500.000 verzoeken binnen één minuut, uit veel landen tegelijk. Het meeste werd tegengehouden voordat het onze servers bereikte, en een minuut later was het verkeer weer normaal.

We zagen het niet omdat er iets uitviel. We zagen het omdat het getal niet paste bij de rest van de grafiek. Dat is de eigenlijke taak van monitoring: niet alarm slaan als alles in brand staat, maar laten zien waar iets niet bij het normale past.

Wat onze monitoring bewust niet ziet

De regels zijn hier net zo belangrijk als de dashboards:

• Geen IP adressen van bezoekers in logs. Dat belooft onze privacyverklaring, dus we verwijderen ze op twee plekken: bij het schrijven van de access log en nog een keer voordat hij wordt opgeslagen.
• Geen server, gebruikers of bericht ID's in metrics. Elke metric wordt alleen gesplitst op grove kenmerken (module, statusklasse, shard). Dat beschermt gegevens en houdt de metricsdatabase klein.
• Sessieopnames tonen onze interface, niet jouw inhoud. Alleen tekst die woord voor woord uit onze vertaalbestanden komt, blijft leesbaar. Namen van servers, kanalen en gebruikers, invoer en voorbeelden worden gemaskeerd. Kan de lijst met toegestane teksten niet worden geladen, dan wordt alles gemaskeerd.
• Alles op de website pas na toestemming. Waardoor de cijfers daar ook een ondergrens zijn. Voor echte paginatellingen kijken we naar de anonieme totalen van onze netwerkprovider.

De details staan in de privacyverklaring.

Wat we eruit meenemen

Het dure is zelden het kapotte. Geen van de bevindingen hierboven leverde een fout op. Ze leverden belasting, kosten en ruis op, en zonder te meten zie je daar niets van.

Per server vragen schaalt niet. Beide grote bevindingen waren hetzelfde patroon: een loop over elke server die over elke server afzonderlijk een vraag stelt. Het antwoord is bijna altijd dezelfde vraag, één keer voor allemaal gesteld.

Een alarm moet zeldzaam zijn, anders is het er geen. Daarom pingt alleen Grafana het team, en alleen voor dingen waarbij iemand moet ingrijpen. Nieuwe fouttypes uit PostHog komen zonder ping in het kanaal terecht.

Run je zelf een Discord server en wil je de modules zien die hier genoemd worden: polls, supportregistraties en afwezigheden staan in het webpanel, en ze worden beschreven in de documentatie.