Vigilar 4000 servidores de Discord: Grafana, PostHog y lo que nos enseñaron

AlphaCloud funciona en algo más de 4000 servidores de Discord, repartidos en cuatro shards. Son cuatro procesos, cada uno atiende una parte de los servidores, y todos hablan con la misma API.

A ese tamaño, un problema rara vez se manifiesta rompiendo algo. Mucho más a menudo todo funciona, solo que más caro, más lento o con más ruido del que debería. Por eso rehicimos nuestra monitorización en septiembre de 2026. Este artículo muestra cómo es y qué nos enseñó en las primeras semanas.

Dos herramientas, dos preguntas

Grafana responde a la pregunta: ¿qué está haciendo el bot? El bot y la API envían métricas a Prometheus (peticiones, tiempos de respuesta, tasas de error, respuestas de Discord, uso de IA), y los logs van a Loki. Cada nodo de servidor tiene su propio stack, y Grafana solo es accesible a través de una red privada, no desde internet.

PostHog responde a la pregunta: ¿qué experimentan las personas en nuestras webs? Visitas a páginas, errores del navegador, tiempos de carga y, con consentimiento, sesiones grabadas. PostHog solo arranca después de que aceptes en el banner de cookies.

La separación es deliberada. Grafana mira máquinas, PostHog mira interfaces. Meter ambas cosas en una sola herramienta te da o bien datos de usuarios en los logs del servidor, o bien carga del servidor en la analítica de producto.

Lo que encontró

Un bucle que producía la mitad del tráfico

Las encuestas con hora de cierre las cierra una tarea en segundo plano que comprueba cada minuto si algo ha caducado. Lo hacía para cada servidor por separado. Con unos 1000 servidores por shard y cuatro shards, eso sumaba unas 70 peticiones por segundo, casi todas con la respuesta «no ha caducado nada».

Solo nos dimos cuenta en Grafana, cuando desglosamos las peticiones del bot a la API por ruta: ese único endpoint era más de la mitad de todo el tráfico. Todo funcionaba. Simplemente cargaba con un peso que nadie había pedido.

Ahora cada shard pregunta una vez por minuto: «¿Qué servidores tienen alguna encuesta caducada?», y solo pide detalles de esos. Unas 4200 peticiones por minuto se convirtieron en unas cuatro.

Tres millones de veces «no configurado»

El mismo patrón en otro sitio: varios módulos (entradas de soporte, ausencias, lista del equipo, estadísticas del bot, boletín) leían con regularidad en sus bucles los ajustes de cada servidor. En la mayoría de los servidores un módulo dado no está configurado en absoluto, así que la respuesta era «no encontrado». Unos tres millones de veces al día.

La solución no tiene nada de espectacular: un «no configurado» se recuerda ahora durante 30 minutos. Eso solo es seguro porque cada uno de estos módulos envía al bot una actualización en el momento en que se guarda en el panel web, así que configurar un módulo nunca significa esperar 30 minutos.

Las caídas de Discord no son bugs nuestros

Nuestro canal de errores del equipo publicaba cada acción fallida como un «Runtime Error», con su referencia única y todo. Eso incluía momentos en los que el propio Discord respondía con un error de servidor. Eso no es un bug nuestro ni algo que podamos arreglar, y estaba en el canal con exactamente el mismo aspecto que un defecto real.

Hoy se registra como aviso, y al miembro se le dice que lo intente de nuevo en unos segundos en lugar de ofrecerle un enlace para reportar un bug. Un canal de errores en el que la mitad de los mensajes no son errores acaba por no leerse. Y entonces se te escapa el de verdad.

Un ataque que duró un minuto

Una tarde de finales de septiembre, nuestra página de inicio recibió algo más de 500.000 peticiones en un minuto, desde muchos países a la vez. La mayor parte se detuvo antes de llegar a nuestros servidores, y un minuto después el tráfico había vuelto a la normalidad.

No lo vimos porque algo se cayera. Lo vimos porque la cifra no encajaba con el resto del gráfico. Esa es la verdadera tarea de la monitorización: no dar la alarma cuando todo arde, sino mostrar dónde algo no encaja con lo normal.

Lo que nuestra monitorización deliberadamente no ve

Las reglas aquí importan tanto como los dashboards:

• Ninguna dirección IP de visitantes en los logs. Nuestra política de privacidad lo promete, así que las eliminamos en dos sitios: al escribir el log de acceso y otra vez antes de guardarlo.
• Ningún ID de servidor, usuario o mensaje en las métricas. Cada métrica solo se desglosa por atributos generales (módulo, clase de estado, shard). Eso protege los datos y mantiene pequeña la base de datos de métricas.
• Las grabaciones de sesión muestran nuestra interfaz, no tu contenido. Solo sigue legible el texto que viene palabra por palabra de nuestros archivos de traducción. Los nombres de servidores, canales y usuarios, las entradas y las vistas previas se enmascaran. Si la lista de textos permitidos no se puede cargar, se enmascara todo.
• Todo en la web, solo tras el consentimiento. Lo que además hace que las cifras de ahí sean un límite inferior. Para el número real de visitas miramos los totales anónimos de nuestro proveedor de red.

Los detalles están en la política de privacidad.

Lo que nos llevamos

Lo caro rara vez es lo roto. Ninguno de los hallazgos de arriba produjo un error. Produjeron carga, coste y ruido, y sin medir no ves nada de eso.

Preguntar servidor por servidor no escala. Los dos grandes hallazgos eran el mismo patrón: un bucle sobre todos los servidores que pregunta por cada uno individualmente. La respuesta casi siempre es la misma pregunta, hecha una sola vez para todos.

Una alerta tiene que ser rara o no es una alerta. Por eso solo Grafana avisa al equipo, y solo por cosas que necesitan que alguien intervenga. Los nuevos tipos de error de PostHog llegan al canal sin ping.

Si tú también tienes un servidor de Discord y quieres ver los módulos mencionados aquí: las encuestas, las entradas de soporte y las ausencias están en el panel web, y se describen en la documentación.