Integración de Prometheus y Grafana que detecta los problemas

Publicado el 6 de octubre de 2026

La integración de Prometheus y Grafana permite aprovechar las métricas del servidor: muestra qué está cambiando, te avisa antes de que un límite provoque una interrupción y aporta pruebas cuando un servicio parece lento. Prometheus recopila y almacena los datos numéricos. Grafana los convierte en paneles de control y alertas que tu equipo puede entender de un vistazo. Juntos, reemplazan las conjeturas por una visión operativa más tranquila.

Para un VPS, un servidor dedicado, una plataforma SaaS o una tienda en línea con mucho tráfico, esta configuración es más valiosa antes de que algo falle. Un disco lleno, la memoria agotada, el aumento de los tiempos de respuesta o un grupo de conexiones a la base de datos cerca de su límite suelen dejar señales primero en las métricas. Puede que el servicio siga funcionando, pero el gráfico ya está contando lo que ocurrirá después.

Qué hace Prometheus y qué hace Grafana

Prometheus es un sistema de supervisión de series temporales. Recopila métricas de los objetivos a intervalos regulares, etiqueta esas mediciones y las mantiene disponibles para realizar consultas. Es especialmente adecuado para supervisar servidores y aplicaciones, porque métricas como el uso de CPU, la presión de memoria, las tasas de solicitudes, la latencia y la capacidad del sistema de archivos se adaptan de forma natural a su modelo.

Grafana es la capa de visualización y alertas. Se conecta a Prometheus como origen de datos, permite crear paneles a partir de consultas PromQL y organiza esos paneles en paneles de control. Un buen panel de control de Grafana no tiene por qué ser decorativo. Su objetivo es responder rápidamente a preguntas prácticas: ¿Está en buen estado el servidor? ¿Qué servicio está usando recursos? ¿Está empeorando el rendimiento? ¿Cambió algo con el despliegue de las 14:00?

Prometheus puede evaluar por sí mismo las reglas de alerta, mientras que Alertmanager se encarga de agrupar, enrutar y silenciar las notificaciones. Grafana también puede crear alertas a partir de consultas de los paneles de control. Cualquiera de los dos enfoques puede funcionar. Para las alertas de toda la infraestructura gestionadas mediante código, las reglas de Prometheus junto con Alertmanager suelen ser más fáciles de estandarizar. Para un panel de control de un servicio específico, las alertas gestionadas por Grafana pueden resultar prácticas. Evita usar ambos para la misma condición exacta, a menos que las notificaciones duplicadas a las 3 a. m. formen parte del plan.

Integración de Prometheus y Grafana: una arquitectura práctica

Una arquitectura inicial razonable es sencilla. Si es posible, ejecuta Prometheus y Grafana en un VPS de supervisión, separado del servidor o la aplicación que se está supervisando. Instala exportadores en los sistemas supervisados. Los exportadores exponen métricas en un punto de conexión HTTP, y Prometheus las recopila según una programación.

Para los servidores Linux, Node Exporter suele ser la primera opción. Expone mediciones del host, como CPU, memoria, promedio de carga, uso del disco, tráfico de red y estadísticas del sistema de archivos. Los exportadores de bases de datos pueden ofrecer visibilidad de MySQL, PostgreSQL, Redis y otros servicios. Las métricas de las aplicaciones pueden provenir de un punto de conexión nativo de Prometheus, de una biblioteca del framework o de un exportador seleccionado cuidadosamente.

El flujo de datos básico es sencillo:

• Un exportador expone métricas de un servidor, una base de datos o una aplicación.
• Prometheus recopila los datos del punto de conexión y almacena los datos de series temporales.
• Grafana consulta Prometheus y muestra los resultados.
• Las reglas de alerta evalúan los umbrales o los comportamientos anómalos y envían notificaciones a través del canal seleccionado.

Este esquema sencillo también facilita la resolución de problemas. Si un panel de Grafana está vacío, comprueba si Grafana puede consultar Prometheus. Si Prometheus no tiene datos, comprueba la página del objetivo y el punto de conexión del exportador. Si el objetivo no está disponible, comprueba el acceso a la red, las reglas del firewall, el estado del servicio y la configuración del exportador. A estas alturas, los registros suelen contar la misma historia.

Empieza con métricas que permitan actuar

Recopilar todas las métricas disponibles genera ruido, consume almacenamiento y produce paneles de control que nadie consulta. Empieza con métricas que respalden una decisión operativa clara. En la mayoría de los servidores, esto significa supervisar el uso de CPU y la carga, la memoria disponible, la actividad de intercambio, el espacio en disco y el uso de inodos, la latencia de E/S del disco, los errores de red, la disponibilidad de los procesos y el tiempo de actividad del sistema.

En las aplicaciones web, añade la tasa de solicitudes HTTP, la tasa de errores, la duración de las solicitudes, las conexiones activas y la profundidad de la cola, cuando corresponda. En las bases de datos, supervisa el número de conexiones, las consultas lentas, el estado de la replicación, la eficiencia de la caché, los bloqueos y el crecimiento del almacenamiento. A un sitio de comercio electrónico pueden preocuparle mucho los errores en el proceso de pago y la latencia de la base de datos; una agencia de desarrollo quizá priorice el tiempo de actividad de los entornos de sus clientes y el éxito de las copias de seguridad. Depende de la carga de trabajo, no de qué panel de control sea más impresionante.

Usa las etiquetas con cuidado. Las etiquetas permiten filtrar por entorno, función del servidor, cliente, región o aplicación. También pueden generar un gran volumen de series temporales distintas si incluyen valores que cambian constantemente, como los ID de usuario, los ID de pedido, los tokens de sesión o las rutas de solicitud con parámetros dinámicos. Las etiquetas de alta cardinalidad son una forma discreta de hacer que Prometheus trabaje mucho más de lo necesario.

Configura la recopilación sin crear nuevos riesgos

Prometheus necesita una lista de objetivos en su configuración. Un objetivo básico de Node Exporter podría tener este aspecto:

``\`yaml scrape_configs:

• job_name: node

static_configs:

• targets: ['10.0.0.15:9100']

labels: environment: production role: web ``\`

En un entorno pequeño, los objetivos estáticos son claros y fiables. A medida que crece la infraestructura, el descubrimiento de servicios suele ser una opción más adecuada, ya que los objetivos se añaden y eliminan automáticamente. Sea cual sea el método que elijas, mantén privados los puntos de conexión de supervisión siempre que sea posible. No dejes los puertos de los exportadores ampliamente expuestos a Internet solo porque un panel de control necesite datos.

Usa redes privadas, listas de direcciones permitidas en el firewall, una VPN o un proxy inverso con autenticación, según corresponda. Cifra el tráfico cuando las métricas atraviesen redes no confiables. Las métricas de Prometheus pueden revelar nombres de host, nombres de servicios internos, patrones de carga de trabajo y detalles de versiones. Son datos operativos, no un elemento decorativo público.

Define el periodo de retención según tus necesidades de respuesta a incidentes y planificación de capacidad. Entre quince y treinta días bastan en muchas instalaciones pequeñas para identificar cambios recientes y tendencias a corto plazo. Una retención más prolongada ayuda a detectar la demanda estacional y el crecimiento gradual de la capacidad, pero aumenta los requisitos de espacio en disco. Para generar informes históricos durante periodos prolongados, considera el almacenamiento remoto en lugar de mantener una retención ilimitada en el mismo VPS que ejecuta Grafana.

Crea paneles de control que faciliten el diagnóstico rápido

Primero, crea un panel de control general. Debe mostrar el estado de los sistemas más importantes, no todas las métricas del catálogo. Un panel general útil suele incluir la disponibilidad del servidor, CPU, memoria, uso del disco, tráfico de red, tasa de errores HTTP y latencia de las solicitudes. Usa variables para el host, el entorno y el servicio, de modo que un mismo panel de control sirva para varios sistemas sin convertirse en un museo de copias y pegados.

Después, crea paneles de control específicos para cada servicio. Un panel de control de una base de datos necesita paneles distintos de los de un servidor web. Un panel de control para un proceso en segundo plano debería mostrar la profundidad de la cola, el tiempo de procesamiento, los reintentos y los errores. Usa títulos directos para los paneles: «Espacio libre en /var», «Tasa de HTTP 5xx» y «Conexiones activas de PostgreSQL» son mejores que nombres ingeniosos que requieren descifrarse en el peor momento.

Vale la pena añadir anotaciones para los despliegues, las ventanas de mantenimiento y los cambios de configuración. Cuando la latencia aumenta poco después de una publicación, una anotación convierte un gráfico sospechoso en un punto de partida útil para conversar. No demuestra que haya una relación causal, pero ofrece un punto de partida razonable para la investigación.

Genera alertas ante los síntomas, no ante cada cifra

Una alerta de CPU al 80 % puede ser útil para un servidor y no tener sentido para otro. Un nodo de procesamiento por lotes puede funcionar al máximo durante horas por diseño, mientras que un aumento repentino de la latencia de la API puede afectar de inmediato a los clientes, aunque el uso de CPU sea moderado. Las reglas de alerta deben reflejar el impacto y el comportamiento esperado.

Empieza con alertas para las condiciones que requieren una respuesta: un exportador o servicio no está disponible, el espacio en disco se agotará pronto, fallan los trabajos de copia de seguridad, la presión de memoria provoca el uso de intercambio, aumentan las tasas de error, se acercan las fechas de vencimiento de los certificados o la replicación de la base de datos no funciona correctamente. Añade una duración para evitar que los picos breves despierten a alguien innecesariamente. Por ejemplo, una falta de espacio en disco que se mantenga durante quince minutos suele requerir más atención que una caída de cinco segundos.

Toda alerta debe responder a tres preguntas: ¿qué ocurre?, ¿dónde ocurre? y ¿qué debería comprobar primero la persona responsable de responder? Incluye el nombre del servidor, el entorno, el servicio y una instrucción breve del manual de operaciones en la anotación de la alerta. «Poco espacio en disco» no basta cuando hay veinte servidores y alguien lee el mensaje desde el teléfono.

Los silencios y las ventanas de mantenimiento forman parte de una gestión de alertas saludable; no sirven para ocultar problemas. Úsalos para los trabajos planificados y elimínalos cuando terminen. Un silencio olvidado tiene muy mal sentido de la oportunidad.

Mantén la pila de supervisión fácil de mantener

Trata los paneles de control, las reglas de alerta y la configuración de Prometheus como activos operativos. Haz copias de seguridad, revísalos después de los incidentes y guarda la configuración en el control de versiones, si tu equipo puede hacerlo de forma segura. Prueba las alertas de vez en cuando. Un canal de notificación que nunca se ha probado no es más que una hipótesis optimista.

Supervisa también el sistema de supervisión. Prometheus necesita suficiente memoria y almacenamiento, Grafana necesita copias de seguridad de su configuración y base de datos, y los exportadores deben seguir siendo accesibles después de los cambios en el firewall o la red. Vigila la duración de la recopilación, las recopilaciones fallidas, la capacidad de almacenamiento y los errores en la entrega de alertas. Si el servidor de supervisión está sobrecargado, sus gráficos pueden parecer tranquilos mientras deja pasar silenciosamente las pruebas que necesitas.

Para los equipos que prefieren contar con asistencia operativa para su infraestructura, kodu.cloud puede ayudar con entornos de VPS y servidores supervisados, mientras tú mantienes la visibilidad mediante las métricas importantes para tu negocio. El objetivo no es convertir la supervisión en un misterio. Se trata de que el próximo problema sea más pequeño, aparezca antes y sea más fácil de resolver.

Una configuración bien ajustada de Prometheus y Grafana no elimina los incidentes. Le da a tu equipo avisos más tempranos, un contexto más claro y menos decisiones a ciegas cuando se produce un incidente. Empieza con un servidor, un panel de control y un conjunto breve de alertas ante las que la gente realmente vaya a actuar. A partir de ahí, el servicio vuelve a la calma.

Andres Saar, ingeniero de atención al cliente