De olho em 4.000 servidores do Discord: Grafana, PostHog e o que eles nos mostraram

O AlphaCloud roda em pouco mais de 4.000 servidores do Discord, distribuídos em quatro shards. São quatro processos, cada um atendendo uma parte dos servidores, todos conversando com a mesma API.

Nesse tamanho, um problema raramente aparece quebrando alguma coisa. Muito mais vezes tudo funciona, só que mais caro, mais lento ou mais barulhento do que deveria. Por isso, reconstruímos nosso monitoramento em setembro de 2026. Este artigo mostra como ele é e o que ele nos mostrou nas primeiras semanas.

Duas ferramentas, duas perguntas

O Grafana responde à pergunta: o que o bot está fazendo? O bot e a API enviam métricas para o Prometheus (requisições, tempos de resposta, taxas de erro, respostas do Discord, uso de IA), e os logs vão para o Loki. Cada nó de servidor tem sua própria stack, e o Grafana só é acessível por uma rede privada, não pela internet.

O PostHog responde à pergunta: o que as pessoas vivenciam nos nossos sites? Visualizações de página, erros no navegador, tempos de carregamento e, com consentimento, sessões gravadas. O PostHog só começa depois que você concorda no banner de cookies.

A divisão é intencional. O Grafana olha para máquinas, o PostHog para interfaces. Quem tenta enfiar os dois numa ferramenta só acaba com dados de usuários nos logs do servidor ou com carga do servidor na análise de produto.

O que ele encontrou

Um loop que gerava metade do tráfego

Enquetes com horário de término são encerradas por uma tarefa em segundo plano que verifica a cada minuto se algo expirou. Ela fazia isso para cada servidor individualmente. Com cerca de 1.000 servidores por shard e quatro shards, isso dava cerca de 70 requisições por segundo, quase todas respondendo "nada expirou".

Só percebemos no Grafana, quando dividimos as requisições do bot para a API por caminho: esse único endpoint era mais da metade de todo o tráfego. Tudo funcionava. Só carregava uma carga que ninguém tinha pedido.

Agora cada shard pergunta uma vez por minuto: "Quais servidores têm alguma enquete expirada?" e só busca os detalhes desses. Cerca de 4.200 requisições por minuto viraram umas quatro.

Três milhões de vezes "não configurado"

O mesmo padrão, em outro lugar: vários módulos (registros de suporte, ausências, lista da equipe, estatísticas do bot, newsletter) liam regularmente as configurações de cada servidor nos seus loops. Na maioria dos servidores, um determinado módulo nem está configurado, então a resposta era "não encontrado". Cerca de três milhões de vezes por dia.

A correção não tem nada de espetacular: um "não configurado" agora fica guardado por 30 minutos. Isso só é seguro porque cada um desses módulos envia uma atualização ao bot no momento em que é salvo no painel web, então configurar um módulo nunca significa esperar 30 minutos.

As falhas do Discord não são bugs nossos

Nosso canal de erros da equipe publicava toda ação que falhava como "Runtime Error", com referência única e tudo. Isso incluía momentos em que o próprio Discord respondia com um erro de servidor. Isso não é um bug nosso nem algo que possamos corrigir, e ficava no canal parecendo exatamente um defeito real.

Hoje isso é registrado como aviso, e o membro é orientado a tentar de novo em alguns segundos, em vez de receber um link para reportar um bug. Um canal de erros em que metade das mensagens não são erros acaba deixando de ser lido. Aí você perde o erro de verdade.

Um ataque que durou um minuto

Numa tarde no fim de setembro, nossa página inicial recebeu pouco mais de 500.000 requisições em um minuto, de vários países ao mesmo tempo. A maior parte foi barrada antes de chegar aos nossos servidores, e um minuto depois o tráfego estava normal de novo.

Não vimos isso porque algo caiu. Vimos porque o número não combinava com o resto do gráfico. Esse é o verdadeiro trabalho do monitoramento: não dar o alarme quando tudo está pegando fogo, mas mostrar onde algo foge do normal.

O que o nosso monitoramento deliberadamente não vê

As regras aqui importam tanto quanto os dashboards:

• Nenhum endereço IP de visitante nos logs. Nossa política de privacidade promete isso, então os removemos em dois lugares: quando o log de acesso é escrito e mais uma vez antes de ser armazenado.
• Nenhum ID de servidor, usuário ou mensagem nas métricas. Toda métrica só é dividida por atributos genéricos (módulo, classe de status, shard). Isso protege dados e mantém o banco de métricas pequeno.
• As gravações de sessão mostram a nossa interface, não o seu conteúdo. Só fica legível o texto que vem palavra por palavra dos nossos arquivos de tradução. Nomes de servidores, canais e usuários, entradas e prévias são mascarados. Se a lista de textos permitidos não puder ser carregada, tudo é mascarado.
• Tudo no site só depois do consentimento. O que também faz dos números de lá um limite inferior. Para contagens reais de páginas, olhamos os totais anônimos do nosso provedor de rede.

Os detalhes estão na política de privacidade.

O que levamos disso

O que custa caro raramente é o que está quebrado. Nenhuma das descobertas acima gerou um erro. Elas geraram carga, custo e ruído, e sem medir você nunca vê nada disso.

Perguntar por servidor não escala. As duas grandes descobertas eram o mesmo padrão: um loop sobre todos os servidores que pergunta sobre cada um individualmente. A resposta quase sempre é a mesma pergunta, feita uma vez para todos.

Um alerta tem que ser raro, senão não é alerta. Por isso só o Grafana avisa a equipe com um ping, e só em casos que precisam de alguém para intervir. Novos tipos de erro do PostHog chegam ao canal sem ping.

Se você administra um servidor do Discord e quer ver os módulos citados aqui: enquetes, registros de suporte e ausências estão no painel web e estão descritos na documentação.