Tenere d'occhio 4.000 server Discord: Grafana, PostHog e cosa ci hanno mostrato

AlphaCloud gira su poco più di 4.000 server Discord, distribuiti su quattro shard. Sono quattro processi, ognuno serve una parte dei server, e tutti parlano con la stessa API.

A queste dimensioni un problema raramente si manifesta rompendo qualcosa. Molto più spesso tutto funziona, solo in modo più costoso, più lento o più rumoroso di quanto dovrebbe. Per questo a settembre 2026 abbiamo ricostruito il nostro monitoraggio. Questo articolo mostra com'è fatto e cosa ci ha mostrato nelle prime settimane.

Due strumenti, due domande

Grafana risponde alla domanda: cosa sta facendo il bot? Bot e API inviano metriche a Prometheus (richieste, tempi di risposta, tassi di errore, risposte di Discord, uso dell'IA), e i log finiscono in Loki. Ogni nodo server ha il proprio stack, e Grafana è raggiungibile solo tramite una rete privata, non da internet.

PostHog risponde alla domanda: cosa vivono le persone sui nostri siti web? Visualizzazioni di pagina, errori del browser, tempi di caricamento e, con il consenso, sessioni registrate. PostHog parte solo dopo che hai acconsentito nel banner dei cookie.

La divisione è voluta. Grafana guarda le macchine, PostHog le interfacce. Infilare entrambe le cose in un solo strumento ti porta o dati degli utenti nei log del server o carico del server nelle statistiche di prodotto.

Cosa ha trovato

Un loop che produceva metà del traffico

I sondaggi con una scadenza vengono chiusi da un'attività in background che ogni minuto controlla se qualcosa è scaduto. Lo faceva per ogni server singolarmente. Con circa 1.000 server per shard e quattro shard, si arrivava a circa 70 richieste al secondo, quasi tutte con la risposta "niente di scaduto".

Ce ne siamo accorti solo in Grafana, una volta suddivise per percorso le richieste del bot all'API: questo singolo endpoint era più della metà di tutto il traffico. Tutto funzionava. Solo che portava un carico che nessuno aveva chiesto.

Ora ogni shard chiede una volta al minuto: "Quali server hanno un sondaggio scaduto?" e recupera i dettagli solo per quelli. Circa 4.200 richieste al minuto sono diventate circa quattro.

Tre milioni di volte "non configurato"

Stesso schema, posto diverso: diversi moduli (voci di supporto, assenze, lista team, statistiche bot, newsletter) leggevano regolarmente nei loro loop le impostazioni di ogni server. Sulla maggior parte dei server un dato modulo non è configurato affatto, quindi la risposta era "non trovato". Circa tre milioni di volte al giorno.

La correzione è poco spettacolare: un "non configurato" ora viene ricordato per 30 minuti. È sicuro solo perché ognuno di questi moduli invia al bot un aggiornamento nel momento in cui viene salvato nel pannello web, quindi configurare un modulo non significa mai aspettare 30 minuti.

I guasti di Discord non sono bug nostri

Il canale errori del nostro team pubblicava ogni azione fallita come "Runtime Error", con tanto di riferimento univoco. Compresi i momenti in cui era Discord stesso a rispondere con un errore del server. Non è né un bug da parte nostra né qualcosa che possiamo correggere, e stava nel canale con l'aspetto identico a un vero difetto.

Oggi viene registrato come avviso, e al membro viene detto di riprovare tra qualche secondo invece di proporgli un link per segnalare un bug. Un canale errori in cui metà dei messaggi non sono errori prima o poi smette di essere letto. E allora ti sfugge quello vero.

Un attacco durato un minuto

Un pomeriggio di fine settembre la nostra home page ha ricevuto poco più di 500.000 richieste in un minuto, da molti paesi contemporaneamente. La maggior parte è stata fermata prima di raggiungere i nostri server, e un minuto dopo il traffico era tornato normale.

Non l'abbiamo visto perché qualcosa è andato giù. L'abbiamo visto perché il numero non si accordava con il resto del grafico. È questo il vero compito del monitoraggio: non dare l'allarme quando tutto va a fuoco, ma mostrare dove qualcosa non rientra nella normalità.

Cosa il nostro monitoraggio volutamente non vede

Qui le regole contano quanto le dashboard:

• Nessun indirizzo IP dei visitatori nei log. La nostra informativa sulla privacy lo promette, quindi li rimuoviamo in due punti: quando viene scritto il log degli accessi e un'altra volta prima che venga salvato.
• Nessun ID di server, utente o messaggio nelle metriche. Ogni metrica è suddivisa solo per attributi generici (modulo, classe di stato, shard). Questo protegge i dati e mantiene piccolo il database delle metriche.
• Le registrazioni delle sessioni mostrano la nostra interfaccia, non i tuoi contenuti. Resta leggibile solo il testo che proviene parola per parola dai nostri file di traduzione. Nomi di server, canali e utenti, input e anteprime vengono mascherati. Se l'elenco dei testi consentiti non si può caricare, viene mascherato tutto.
• Sul sito web tutto solo dopo il consenso. Il che rende anche i numeri lì un limite inferiore. Per il numero reale di pagine visualizzate guardiamo i totali anonimi del nostro fornitore di rete.

I dettagli sono nell'informativa sulla privacy.

Cosa ne ricaviamo

La cosa costosa raramente è la cosa rotta. Nessuno dei problemi sopra ha prodotto un errore. Hanno prodotto carico, costi e rumore, e senza misurare non vedi niente di tutto questo.

Chiedere server per server non scala. Entrambi i problemi più grandi erano lo stesso schema: un loop su ogni server che chiede di ciascuno singolarmente. La risposta è quasi sempre la stessa domanda, posta una volta sola per tutti.

Un allarme deve essere raro, altrimenti non è un allarme. Per questo solo Grafana avvisa il team con un ping, e solo per cose che richiedono l'intervento di qualcuno. I nuovi tipi di errore da PostHog arrivano nel canale senza ping.

Se gestisci tu stesso un server Discord e vuoi vedere i moduli citati qui: sondaggi, voci di supporto e assenze sono nel pannello web, e sono descritti nella documentazione.