Prometheus y Grafana en un VPS: tres métricas que vale la pena monitorear
Publicado el 2026-10-26 por frfrand
CPU, memoria, disco y alertas para aplicaciones en producción
Cuando una web se pone lenta, el número de visitas no alcanza para explicar qué pasó. Tres métricas básicas pueden darte un panorama útil: memoria disponible, CPU utilizada y espacio en disco. Prometheus recolecta series temporales y Grafana las presenta.
Vamos a bajarlo a tierra: qué significa, cómo se prueba y qué pasa cuando lo usás con clientes o información real. La mayoría de los problemas no se arregla con un botón mágico, sino con pasos que podés repetir y medir.
Qué es Prometheus y Grafana en VPS y por qué importa
Prometheus consulta métricas expuestas por exporters y servicios, mientras Grafana construye paneles y alertas con fuentes de datos. Para infraestructura Linux suele utilizarse node_exporter, con acceso a su endpoint restringido a la red de monitoreo.
Una cosa es que una demo funcione cinco minutos y otra es sostener un servicio todos los días. Para eso necesitás límites, permisos, registros de actividad y procedimientos para resolver fallos sin improvisar.
Ejemplo de implementación o diagnóstico
# Ejemplo de consultas PromQL, adaptar job/labels
100 * (1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])))
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100
(node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100
# Reglas/umbrales deben considerar volúmenes y exclusionesEs una referencia didáctica, no una plantilla que debas ejecutar a ciegas en producción. Sustituí los valores de ejemplo, elegí identidades con permisos mínimos y asegurate de que ninguna clave sensible termine en un log o repositorio.
Cómo lo pondría a funcionar
- Instalá un exporter en el VPS y protegé su endpoint; no lo abras a Internet por costumbre.
- Configurá Prometheus para recolectar métricas con etiquetas claras por servidor.
- Creá un panel Grafana con CPU, memoria disponible y disco por volumen.
- Añadí una señal de aplicación: latencia HTTP, tasa de errores o cola de jobs.
- Configurá alertas accionables y comprobá qué información recibirás antes de una caída.
Después de cada paso, verificá un resultado concreto: una acción autorizada, un estado HTTP, una tarea procesada, un costo registrado o una métrica estable. Si algo no funciona, comprobá cuál fue el primer fallo antes de reintentar en bucle.
Un ejemplo que puede aparecer en un proyecto real
Una API FastAPI atiende reservas con Celery. El dashboard muestra RAM agotándose cuando se inicia el worker, mientras las consultas de PostgreSQL siguen rápidas. Ese dato te orienta a revisar concurrencia de tareas, no DNS.
Si esa aplicación tiene varios clientes, separá contextos y recursos. Es especialmente importante cuando un chatbot o un agente puede consultar datos: la facilidad de conectar herramientas no debe saltarse los límites de privacidad y autorización.
El error más común
Un dashboard bonito no significa que haya alertas. Evitá mostrar exporters sin autenticación ni registrar métricas de cada URL con IDs privados; pueden causar cardinalidad excesiva.
Una configuración con buenos defaults ayuda, pero no elimina la necesidad de pruebas. Para servicios que escriben datos o disparan acciones, contemplá reintentos, duplicados y fallos a mitad de camino.
¿Dónde entra ArduMaker?
ArduMaker te permite administrar el VPS y sus procesos. Una capa de métricas con Prometheus/Grafana ayuda a dimensionar y detectar incidencias antes de que usuarios se quejen.
Con ArduMaker podés alojar el backend en un VPS, desplegar desde Git, configurar dominio HTTPS y utilizar herramientas de bases, servicios y MCP según el proyecto. Eso facilita reunir operaciones en un entorno, aunque las reglas de negocio y de seguridad siguen siendo responsabilidad del software.
Qué mediría para saber si mejoró
No mediría sólo «funciona/no funciona». También revisaría consumo de recursos, errores, tiempos de respuesta o gasto de API, según la funcionalidad. Definí una medida de éxito antes del cambio y compará con el mismo escenario después.
Si un dato parece extraño, comprobá la muestra y la ventana temporal. Un promedio puede esconder casos extremos, y una única ejecución exitosa no demuestra que una automatización soporte miles de solicitudes.
Preguntas frecuentes
¿Necesito una infraestructura grande para empezar? No necesariamente. Primero resolvé el problema con una arquitectura simple y medí el punto donde empieza a quedarse corta.
¿Qué pasa si falla el proveedor externo? Necesitás timeouts, política de reintentos y una respuesta útil para el usuario. No asumas que las APIs externas están siempre disponibles.
¿Cómo mantengo el control? Registrá eventos importantes, separá permisos y conservá un procedimiento probado para deshacer cambios o recuperar información.
Referencias para seguir
La idea final: automatizar y medir vale la pena cuando también sabés detectar un error, limitar sus efectos y recuperarte.