Exporters Prometheus para game servers: checklist
En pocas palabras: Un exporter de Prometheus para game servers consulta el protocolo nativo (A2S, RCON o JSON), traduce las métricas de jugadores a tipos Gauge y Counter y las expone en un endpoint /metrics. Según el checklist de Oleksandr Kuryzhev del 17 de julio de 2026, los errores recién aparecen bajo carga real.
Tu dashboard de Prometheus está todo en verde, el CPU tranquilo al 20%, y mientras tanto los jugadores se van puteando en Discord porque el juego lagea. Ese desfasaje pasa por una razón concreta: node_exporter y blackbox_exporter no tienen la menor idea de lo que ocurre adentro del protocolo UDP de tu game server. Los exporters Prometheus para servidores de juegos son la única forma de cerrar ese hueco, y según el checklist publicado el 17 de julio de 2026 por Oleksandr Kuryzhev, es fácil arruinarlos de maneras que recién aparecen bajo carga real.
Un exporter de Prometheus para game servers es un servicio intermedio (glue code) que consulta el protocolo nativo del servidor de juego por A2S, RCON o JSON propietario, traduce la respuesta a tipos de métrica que Prometheus entiende (Gauge y Counter) y la expone en un endpoint HTTP /metrics para que Prometheus la scrapee. Sin él, tu monitoreo ve el host pero no ve al jugador.
En 30 segundos
- node_exporter no alcanza: mide CPU y RAM, pero el jugador siente
player_countyquery_latency, que son los SLI reales. - El error #1 es de tipos: poner un Counter donde va un Gauge deja el dashboard inservible porque el valor nunca baja.
- Los game servers hablan A2S, RCON o JSON propietario: Prometheus no entiende ninguno de forma nativa.
- Timeout del exporter siempre menor al scrape_interval: si no, servís métricas viejas (stale) o rompés el scrape.
- Cuando reportan lag, mirá primero
query_latency, no CPU: un server al 20% de CPU igual puede tener la cola de matchmaking rota.
¿Por qué node_exporter y blackbox_exporter no alcanzan para un game server?
Porque miden el host, no la experiencia del jugador. node_exporter te da CPU, memoria y disco. blackbox_exporter te dice si el puerto responde. Ninguno de los dos sabe cuántos jugadores hay conectados ni cuánto tarda el protocolo de consulta en contestar. Y esas dos métricas, player_count y query_latency, son los SLI que el jugador siente en carne propia.
El autor del checklist lo resume sin vueltas: “un servidor puede estar al 20% de CPU y aún así tener la cola de matchmaking rota o el protocolo de consulta con timeout bajo carga”. Cualquiera que haya administrado infra de gaming se topó con esto. Los gráficos de host verdes, los tickets de soporte diciendo “el juego se siente lento”. Relacionado: pipelines de CI/CD en 2026.
El host está sano. El jugador no.
¿Qué protocolos usan los game servers: A2S, RCON o JSON propietario?
La mayoría de los motores de juego no exponen métricas amigables con Prometheus de fábrica. Según la fuente original, los servidores de Source engine, los dedicados de Unreal y los protocolos UDP custom hablan A2S, RCON o JSON propietario. Prometheus no entiende ninguno.
- A2S: el protocolo de consulta del Source engine (CS:GO, TF2, Garry’s Mod). Devuelve nombre del server, mapa, players y max_players por UDP.
- RCON: consola remota. Te deja correr comandos administrativos y leer estado, pero cada juego lo implementa un poco distinto.
- JSON propietario: los engines custom suelen exponer su propio endpoint. Flexible, pero sin estándar que valga.
Por eso necesitás el glue code: algo que consulte el protocolo nativo del server y lo traduzca a formato Prometheus. Ese “algo” es el exporter.
Gauge vs Counter: ¿qué tipo de métrica va en cada caso?
Un Gauge es un valor que sube y baja (jugadores conectados ahora, latencia actual). Un Counter solo sube y se reinicia a cero cuando el proceso arranca (queries totales, errores acumulados). Este es el error #1 según el checklist: poner un Counter donde correspondía un Gauge. ¿El resultado? Un dashboard inutilizable, porque player_count como Counter nunca baja cuando un jugador se desconecta.
| Métrica | Tipo correcto | Por qué | Ejemplo |
|---|---|---|---|
| player_count | Gauge | Sube y baja según conexiones | 42 ahora, 38 en un rato |
| query_latency_seconds | Histogram | Se agrega en buckets para medir la distribución de latencia | buckets ajustados al género (FPS/MMO) |
| queries_total | Counter | Solo acumula, nunca baja | 1.240.331 |
| connection_errors_total | Counter | Suma errores desde el arranque | 57 |
| server_up | Gauge | Estado binario 1/0 | 1 (arriba) |
Si querés la referencia canónica de cada tipo, está en la documentación oficial de tipos de métrica de Prometheus. Regla mental rápida: ¿el número puede bajar? Gauge. ¿Solo crece? Counter.
¿Cuáles son los componentes de un exporter Prometheus?
Un exporter tiene tres piezas: el polling al game server por su protocolo nativo, el parsing de la respuesta y la exposición HTTP en formato Prometheus. El flujo completo va así: Prometheus scrapea por HTTP el endpoint /metrics del exporter, el exporter consulta por UDP al game server via A2S o RCON, recibe la respuesta, la parsea y devuelve las métricas registradas. Más contexto en elegir herramientas de automatización.
Ojo con dos detalles que la fuente marca como recurrentes. Uno: falta de timeout en el polling UDP, que deja al exporter colgado esperando un server que no contesta. Dos: labels inconsistentes, que rompen la agregación cuando querés sumar players de todos los servers. La guía oficial de exporters tiene la lista de convenciones que conviene respetar desde el día cero.
Checklist: ¿qué validar en cada métrica de jugador?
Este es el corazón práctico. Cada fila valida uno de los errores que la fuente detectó revisando exporters de estudios distintos.
| Métrica | Tipo | Label recomendado | Timeout máx. | Unidad |
|---|---|---|---|---|
| player_count | Gauge | server, region | < scrape_interval | jugadores |
| query_latency | Histogram | server, protocol | < scrape_interval | segundos |
| matchmaking_queue | Gauge | region, gamemode | < scrape_interval | en cola |
| server_status | Gauge | server | < scrape_interval | 1/0 |
| connection_errors | Counter | server, error_type | N/A | errores |
Regla de oro del timeout: siempre menor al scrape_interval. Si Prometheus scrapea cada 15 segundos y tu polling tarda 20, el scrape se pisa con el siguiente y empezás a servir datos viejos.
¿Cómo crear tu primer exporter paso a paso?
Estos son los cuatro pasos mínimos, sin importar si lo hacés en Go o Python. La lógica es la misma. Complementá con configurar soporte multiidioma.
- Setup: registrá tus métricas. Gauge para player_count, Histogram para query_latency, Counter para queries_total y connection_errors_total. Definí los labels una sola vez y respetalos siempre.
- Polling loop: abrí el socket UDP contra el server, mandá la query A2S o el comando RCON, y clavá un timeout explícito (2 segundos alcanza). Si no contesta, incrementá el Counter de errores y seguí.
- Registro de métricas: parseá la respuesta y actualizá cada Gauge con el valor actual. Nunca “acumules” un Gauge, sobreescribilo.
- Servidor HTTP: exponé
/metricsen formato Prometheus. Prometheus scrapea ese endpoint, no consulta el game server directo.
Subís el exporter, lo probás en local con un server de test, lo mandás a producción y de repente los números no cierran porque el timeout era más largo que el scrape_interval, los labels cambiaron entre dos servers y la agregación de Grafana quedó partida en dos series que nadie sabe reconciliar. Testeá con carga antes de confiar.
Errores comunes al crear exporters de Prometheus
Estos son los que hacen que el dashboard quede verde mientras los jugadores se van.
- Counter en player_count: el valor nunca baja, así que ves 500 jugadores cuando quedan 12. El dashboard miente. Fix: Gauge.
- Timeout faltante en el polling UDP: el exporter se cuelga esperando un server caído y sirve métricas stale. Fix: timeout explícito menor al scrape_interval.
- Labels inconsistentes: un server usa
region="us"y otroregion="US", y la suma se parte en dos. Fix: normalizá los labels en el parsing. - Vigilar CPU en vez de query_latency: mirás el gráfico equivocado. El CPU baja no te dice nada del matchmaking. Fix: alertá sobre latency y cola.
- Confundir polling A2S con scraping de Prometheus: son dos cosas distintas. Prometheus scrapea al exporter por HTTP; el exporter poll-ea al server por UDP. Mezclarlas te desorganiza los intervalos.
¿Qué métrica mirar cuando reportan lag en Discord?
Primero query_latency, no CPU. Cuando entra un ticket de “lag”, el reflejo de mirar el gráfico de CPU es una trampa: un server al 20% igual puede tener el protocolo de consulta con timeout. El triage rápido va así: revisá query_latency y latencia de red, después connection_drops y matchmaking_queue, y recién al final el CPU. Te puede servir nuestra cobertura de ejecutar agentes sin dependencias externas.
Separá dos cosas que se confunden: “server roto” (no responde, connection_errors subiendo) de “server lento” (responde, pero query_latency por las nubes). Son problemas distintos con fixes distintos.
Si además estás montando la infra del game server sobre un VPS o servidor dedicado, tené a mano un proveedor con buena latencia regional en Latinoamérica como donweb.com, porque de nada sirve un exporter afinado si el hop de red ya te come 80 ms.
Preguntas Frecuentes
¿Qué es un exporter de Prometheus?
Un exporter es un servicio que traduce métricas de un sistema que Prometheus no entiende de forma nativa a un endpoint HTTP en formato Prometheus. Para game servers, consulta el protocolo A2S, RCON o JSON del server y expone player_count, query_latency y demás en /metrics.
¿Cuál es la diferencia entre Gauge y Counter?
Un Gauge sube y baja (jugadores conectados, latencia actual). Un Counter solo crece y se reinicia al arrancar el proceso (queries totales, errores acumulados). Usar Counter para player_count es el error más común y deja el dashboard inutilizable porque el valor nunca refleja las desconexiones.
¿Por qué node_exporter no sirve para un game server?
node_exporter mide CPU, memoria y disco del host, pero no ve adentro del protocolo UDP del juego. Un server puede estar al 20% de CPU con la cola de matchmaking rota. Los SLI que el jugador siente son player_count y query_latency, y esos requieren un exporter dedicado.
¿Qué timeout debe tener el exporter?
Siempre menor al scrape_interval de Prometheus. Si Prometheus scrapea cada 15 segundos, tu polling UDP no puede tardar 20, porque servís métricas viejas o rompés el scrape. Un timeout de 2 segundos suele alcanzar para A2S o RCON.
¿Prometheus es gratuito para monitorear game servers?
Sí, Prometheus es open source y gratuito bajo licencia Apache 2.0, igual que la mayoría de los exporters de la comunidad. El costo real es el tiempo de escribir y mantener el glue code que traduce el protocolo de tu game server a formato Prometheus.
Conclusión
El dashboard verde con jugadores enojados es un problema de instrumentación, no de infraestructura. Lo que cambió con el checklist de julio de 2026 es que ahora hay una lista concreta de los errores que se repiten estudio tras estudio: Counter donde va Gauge, timeout faltante, labels inconsistentes y mirar CPU en lugar de query_latency. Si arrancás un exporter esta semana, validá cada métrica contra la tabla de checklist, poné el timeout por debajo del scrape_interval y alertá sobre latencia y cola, no sobre CPU. Es más fácil hacerlo bien la primera vez que reconciliar dos series de Grafana rotas a las tres de la mañana.
