Koll på 4 000 Discord-servrar: Grafana, PostHog och vad de visade oss

AlphaCloud körs på drygt 4 000 Discord-servrar, fördelade på fyra shards. Det är fyra processer, där var och en betjänar en del av servrarna och alla pratar med samma API.

I den storleken visar sig ett problem sällan genom att något går sönder. Betydligt oftare fungerar allt, bara dyrare, långsammare eller mer högljutt än det borde. Därför byggde vi om vår övervakning i september 2026. Den här artikeln visar hur den ser ut och vad den visade oss de första veckorna.

Två verktyg, två frågor

Grafana besvarar frågan: vad gör boten? Bot och API rapporterar mätvärden till Prometheus (förfrågningar, svarstider, felfrekvenser, Discord-svar, AI-användning), och loggarna går till Loki. Varje servernod har sin egen stack, och Grafana nås bara via ett privat nätverk, inte från internet.

PostHog besvarar frågan: vad upplever människor på våra webbplatser? Sidvisningar, webbläsarfel, laddningstider och, med samtycke, inspelade sessioner. PostHog startar först när du har godkänt det i cookie-bannern.

Uppdelningen är medveten. Grafana tittar på maskiner, PostHog på gränssnitt. Den som klämmer in båda i ett verktyg får antingen användardata i serverloggarna eller serverbelastning i produktanalysen.

Vad den hittade

En loop som skapade halva trafiken

Omröstningar med en sluttid stängs av en bakgrundsuppgift som varje minut kontrollerar om något har löpt ut. Det gjorde den för varje server separat. Med ungefär 1 000 servrar per shard och fyra shards blev det runt 70 förfrågningar per sekund, nästan alla med svaret "inget har löpt ut".

Vi märkte det först i Grafana, när vi delade upp botens förfrågningar till API:t per sökväg: just den här endpointen stod för mer än hälften av all trafik. Allt fungerade. Den bar bara en belastning som ingen hade bett om.

Nu frågar varje shard en gång i minuten: "Vilka servrar har över huvud taget en omröstning som har löpt ut?" och hämtar bara detaljer för dem. Ungefär 4 200 förfrågningar per minut blev ungefär fyra.

Tre miljoner gånger "inte konfigurerad"

Samma mönster, ett annat ställe: flera moduler (supportposter, frånvaro, teamlista, botstatistik, nyhetsbrev) läste regelbundet varje servers inställningar i sina loopar. På de flesta servrar är en given modul inte konfigurerad alls, så svaret var "hittades inte". Ungefär tre miljoner gånger om dagen.

Fixen är odramatisk: svaret "inte konfigurerad" sparas nu i 30 minuter. Det är bara säkert eftersom var och en av de här modulerna skickar en uppdatering till boten i samma stund som den sparas i webbpanelen, så att konfigurera en modul innebär aldrig att man får vänta i 30 minuter.

Discords avbrott är inte våra buggar

Vår felkanal för teamet postade varje misslyckad åtgärd som ett "Runtime Error", med unik referens och allt. Det gällde även tillfällen då Discord självt svarade med ett serverfel. Det är varken en bugg hos oss eller något vi kan åtgärda, och det låg i kanalen och såg ut exakt som ett riktigt fel.

I dag loggas det som en varning, och medlemmen uppmanas att försöka igen om några sekunder i stället för att få en länk för att rapportera en bugg. En felkanal där hälften av meddelandena inte är fel slutar till slut att läsas. Då missar du det riktiga.

En attack som varade en minut

En eftermiddag i slutet av september fick vår startsida drygt 500 000 förfrågningar inom en minut, från många länder samtidigt. Det mesta stoppades innan det nådde våra servrar, och en minut senare var trafiken tillbaka på normal nivå.

Vi såg det inte för att något gick ned. Vi såg det för att siffran inte passade med resten av diagrammet. Det är övervakningens egentliga uppgift: inte att slå larm när allt brinner, utan att visa var något avviker från det normala.

Vad vår övervakning medvetet inte ser

Reglerna här är lika viktiga som dashboarderna:

• Inga besökares IP-adresser i loggar. Det lovar vår integritetspolicy, så vi tar bort dem på två ställen: när åtkomstloggen skrivs och en gång till innan den sparas.
• Inga server-, användar- eller meddelande-ID:n i mätvärden. Varje mätvärde delas bara upp efter grova egenskaper (modul, statusklass, shard). Det skyddar data och håller mätvärdesdatabasen liten.
• Sessionsinspelningar visar vårt gränssnitt, inte ditt innehåll. Bara text som kommer ordagrant från våra översättningsfiler förblir läsbar. Server-, kanal- och användarnamn, inmatningar och förhandsvisningar maskeras. Om listan över tillåtna texter inte kan laddas maskeras allt.
• Allt på webbplatsen först efter samtycke. Vilket också gör siffrorna där till en undre gräns. För verkliga sidvisningar tittar vi på de anonyma totalsiffrorna från vår nätverksleverantör.

Detaljerna finns i integritetspolicyn.

Vad vi tar med oss

Det dyra är sällan det trasiga. Inget av fynden ovan gav ett fel. De gav belastning, kostnader och brus, och utan att mäta ser du aldrig något av det.

Att fråga per server skalar inte. Båda de stora fynden var samma mönster: en loop över varje server som frågar om var och en separat. Svaret är nästan alltid samma fråga, ställd en gång för alla.

Ett larm måste vara sällsynt, annars är det inget larm. Därför pingar bara Grafana teamet, och bara för sådant som kräver att någon ingriper. Nya feltyper från PostHog hamnar i kanalen utan ping.

Om du själv driver en Discord-server och vill se modulerna som nämns här: omröstningar, supportposter och frånvaro finns i webbpanelen, och de beskrivs i dokumentationen.