Crear paneles de Grafana para infraestructuras de alojamiento

De un conjunto de métricas a una visión clara del panel de control

Un panel de control no empieza por la selección de paneles de colores, sino por una cuestión operativa: ¿debe un equipo reaccionar ahora ante un fallo en el registro de datos, una falta de memoria o una carga prolongada? Grafana representa las consultas a las fuentes de datos en paneles y puede visualizarlas en función de la cuestión que se plantee. La interfaz es, por tanto, una herramienta para la toma de decisiones, no una prueba automática del estado de un servicio.

El nivel superior, por ejemplo, „Estado del alojamiento“, solo debería agrupar unas pocas señales: la accesibilidad desde el punto de vista de Prometeo, la carga de la CPU, la memoria disponible y el tráfico de red. Su finalidad es establecer prioridades: ¿qué área merece ser revisada? Sin embargo, esto aún no explica por qué un servidor web va lento ni qué volumen de datos provoca una alerta de capacidad.

Entre otras cosas, ayudan a Vistas de roles para sistemas web, de bases de datos, de caché, de correo electrónico o de virtualización. Allí se pueden comparar instancias similares utilizando métricas relevantes para su función. Por ejemplo, un rol de base de datos necesita valores detallados distintos a los de un proxy inverso; una página de resumen común no tiene por qué ocultar estas diferencias en un único indicador.

La vista de diagnóstico ofrece, en última instancia, series temporales por instancia, resúmenes de puntos de montaje o dispositivos y eventos operativos. Un panel de control de gran tamaño con todos los hosts y servicios dificulta la identificación. Los paneles de control de Grafana pueden combinar diferentes visualizaciones y fuentes de datos; sin embargo, no todas las cuestiones detalladas deben responderse en la misma página.

Comprobar minuciosamente la base de datos de Prometheus y las etiquetas

Antes de crear el panel de control, es necesario que se pueda acceder a Prometheus y a los destinos de exportación previstos, y Grafana necesita una fuente de datos de Prometheus configurada. Prometheus define en su configuración las tareas de recopilación, las instancias de destino y los archivos de reglas que se deben leer. Aunque los cambios en la configuración se pueden recargar, una configuración errónea no se aplicará.

Lo fundamental es una Estructura de etiquetas. Las discográficas job y instance identificar el origen y el destino; etiquetas complementarias como environment o role permiten una separación clara entre la producción, el entorno de pruebas y la función del servidor. Sin estas reglas, una misma variable podría mezclar hosts que, aunque tengan nombres similares, tengan diferentes ventanas de mantenimiento, responsabilidades o límites de capacidad.

Los puntos finales de exportación no deben ser accesibles públicamente sin control. Las métricas pueden revelar nombres de host, puntos de montaje, interfaces de red u otros detalles de la infraestructura. Comprueba también si Grafana tiene permiso para consultar Prometheus y si las series temporales existentes realmente proporcionan datos durante el periodo previsto; un panel vacío no se puede corregir con una visualización más atractiva.

• Comprueba en Prometheus o en la sección «Explore» los nombres de métricas, las etiquetas y los valores de las etiquetas que realmente existen.
• Para cada destino, comprueba si los «scrapes» se están realizando correctamente y si la instancia esperada está identificada de forma unívoca.
• Para las métricas del sistema de archivos y de red, delimitar los puntos de montaje o las interfaces en función del entorno propio.
• Los ejemplos del panel de control solo se transferirán a la estructura local de métricas y etiquetas una vez realizada esta comprobación.

Node Exporter documenta los colectores que recopilan, entre otras cosas, información sobre el sistema de archivos, la red y los dispositivos de almacenamiento. Sin embargo, las filas que aparecen durante el funcionamiento dependen del sistema operativo, el núcleo, los contenedores, los puntos de montaje y los colectores activados. Además, el archivo README de la rama de desarrollo no describe automáticamente las capacidades de una versión estable ya instalada.

Por lo tanto, comprueba la versión instalada de Node Exporter y sus métricas observables, independientemente de la documentación de desarrollo. En el momento de la investigación, Node Exporter 1.12.1 se publicó el 14 de julio de 2026; esta información sobre la versión no sustituye a la comprobación de qué compilación se está ejecutando en un host concreto. Las plantillas de paneles de control de terceros son puntos de referencia, no un inventario fiable de la propia infraestructura.

Seleccionar los tipos de paneles según su descripción

El tipo de panel depende de la pregunta. Un panel de estadísticas es adecuado para un valor clave actual y claramente identificado. Puede mostrar un único valor calculado y, opcionalmente, una pequeña línea de tendencia. La etiqueta debe indicar con precisión qué métrica y qué punto de control técnico se representan; no se debe generalizar a partir de un único valor registrado para deducir el estado de un sitio web o una aplicación.

En cuanto a la carga, el crecimiento y las relaciones, son series temporales más adecuadas. Muestran, por ejemplo, si la carga de la CPU solo aumenta brevemente durante una implementación o si se mantiene alta durante horas. Solo el intervalo de tiempo, una unidad correcta y la comparación con otras señales convierten un valor aislado en una observación fiable. Grafana ofrece para ello diversas visualizaciones, cuya interpretación depende de la consulta y la representación.

Las tablas son adecuadas para muchas entidades similares. Los hosts, los puntos de montaje o los dispositivos se pueden comparar línea por línea con los valores medidos y el contexto operativo, sin necesidad de colocar todas las series en un gráfico temporal común. Por el contrario, para las relaciones temporales, suele ser más adecuado utilizar una serie temporal. Por lo tanto, elige la representación en función de si deseas comparar entidades o analizar una evolución.

Cada panel debe llevar una leyenda precisa que permita identificar la unidad, el alcance del filtro y el límite de interpretación. „Espacio disponible según el sistema de archivos por punto de montaje“ es más significativo que „disco“, ya que las cuotas, los bloques reservados o la falta de inodos pueden provocar problemas de escritura. Del mismo modo, un porcentaje en rojo no indica ni la disponibilidad ni la causa; los colores llaman la atención, pero no sustituyen al diagnóstico.

No establezcas umbrales operativos solo por estética. Un color de advertencia puede resultar útil cuando se conocen la función del servicio, el crecimiento, la redundancia y el posible tiempo de respuesta. Si falta este contexto, el panel debería mostrar el valor de forma neutra y dirigir al usuario a la vista detallada correspondiente. De este modo, se mantiene Declaración del panel y que los límites técnicos sean comprensibles para todas las partes implicadas.

Cómo crear paso a paso una guía sobre alojamiento web

Una página de resumen no comienza con todas las métricas disponibles, sino con unas pocas preguntas que deben poder resolverse de inmediato durante el funcionamiento: ¿se están alcanzando los objetivos previstos?, ¿aumenta la carga del servidor?, ¿se está agotando un volumen relevante? o ¿se observan cambios notables en el tráfico de datos? Para ello, crea en un primer momento solo cuatro grupos de paneles. Grafana agrupa las consultas y representaciones en paneles; por lo tanto, cada visualización debería responder a una pregunta operativa concreta.

Para empezar, basta con un resumen claro del estado de registro, una serie temporal de la carga de la CPU, una tabla o serie temporal de la memoria disponible por punto de montaje y una serie temporal del rendimiento de la red. Los paneles de estadísticas son adecuados para mostrar un único valor actual y pueden mostrar una pequeña evolución. Sin embargo, no sustituyen a la serie temporal cuando son relevantes la duración, la frecuencia y el momento en que se produce una anomalía.

La tabla es una base de planificación, no una plantilla rígida: Node Exporter documenta las áreas de los colectores para sistemas de archivos, redes y otros datos del host, pero las métricas y etiquetas visibles dependen del sistema, los montajes, los contenedores y los colectores activados. Añade después los paneles específicos de la aplicación, por ejemplo, para errores HTTP, conexiones a bases de datos o colas. Una descripción general más detallada sobre el Pila de monitorización para alojamiento web Puede profundizar así en la clasificación de las métricas de infraestructura y de servicio.

Las expresiones PromQL de este artículo son expresamente Ejemplos que hay que adaptar. Antes de aplicar los cambios, comprueba los nombres de las métricas, los valores de las etiquetas y el número de series resultantes en el área «Explore». Asigna a cada panel un título que se ajuste lo más posible a su contenido concreto. La unidad, el alcance del filtro seleccionado y las interfaces o los pseudo-sistemas de archivos excluidos también deben figurar de forma visible en la configuración o la descripción del panel.

Una vista general eficaz se mantiene deliberadamente sencilla. Si se muestran al mismo tiempo todos los hosts, dispositivos, puntos de montaje y etiquetas de contenedores, se pierde la capacidad de establecer prioridades. Las páginas de detalle se encargan posteriormente del diagnóstico: allí se pueden examinar por separado instancias, volúmenes o servicios concretos. De este modo, la página de inicio sigue siendo una herramienta de orientación, en lugar de una recopilación visualmente saturada de indicadores inconexos.

Combinar correctamente PromQL y las variables

Una consulta debe expresar al mismo tiempo la métrica y su límite. Comprueba primero en Prometheus o Grafana Explore qué series y etiquetas existen realmente en tu propio entorno. Las variables de Grafana pueden sustituir posteriormente a los valores fijos de las etiquetas. Si se ha activado una selección múltiple, su contenido se utiliza como expresión regular; por lo tanto, el comparador de etiquetas debe =~ en lugar de = uso.

En el caso de la carga de la CPU, un contador acumulado no es directamente significativo. El siguiente ejemplo calcula un porcentaje por instancia a partir del tiempo de CPU no dedicado al modo inactivo. Para ello, se requiere que node_cpu_seconds_total y que las etiquetas utilizadas estén disponibles, así como las variables de Grafana $job y $instance se hayan definido adecuadamente.

100 - (
  avg by (instance) (
    rate(node_cpu_seconds_total{mode="idle", job=~"$job", instance=~"$instance"}[$__rate_interval])
  ) * 100
)

Comprueba la serie temporal resultante en varios intervalos de tiempo y compárala con las muestras registradas realmente. Una ventana de intervalo inadecuada puede dar lugar a resultados incompletos o poco significativos. Además, para el análisis con PromQL es importante que:, rate() que se debe aplicar antes de la agregación, para que se puedan tener en cuenta los reinicios de los contadores en el cálculo.

En la vista de almacenamiento, el siguiente ejemplo calcula la parte disponible por cada elemento seleccionado Punto de montaje. Comprueba previamente ambas métricas y sus conjuntos de etiquetas. Si el numerador y el denominador se limitan a series diferentes debido a filtros distintos, la división puede dar lugar a resultados vacíos o inesperados.

100 * node_filesystem_avail_bytes{job=~"$job", instance=~"$instance", mountpoint=~"$mountpoint"}
/ node_filesystem_size_bytes{job=~"$job", instance=~"$instance", mountpoint=~"$mountpoint"}

Filtra los pseudo-sistemas de archivos por instalación, en lugar de sumarlos a ciegas. El recopilador de sistemas de archivos proporciona estadísticas sobre los sistemas de archivos, pero no todas las series visibles son relevantes para la decisión sobre la capacidad. Las cuotas, los bloques reservados, los inodos y los derechos de escritura siguen siendo comprobaciones independientes. Por lo tanto, el panel solo debería indicar la parte disponible según las métricas del sistema de archivos seleccionadas.

En el ejemplo de red, se calcula la tasa de cambio de un contador de bytes, se suma por cada instancia y, a continuación, se convierte a bits por segundo. La suma solo tiene sentido si las interfaces incluidas pertenecen al mismo ámbito funcional. Por ello, en tu propio entorno, añade un filtro de interfaces comprensible, en lugar de sumar sin comprobar todas las interfaces visibles.

sum by (instance) (
  rate(node_network_receive_bytes_total{job=~"$job", instance=~"$instance"}[$__rate_interval])
) * 8

El multiplicador ocho convierte la velocidad calculada a partir de un contador de bytes en bits por segundo. Las interfaces de bucle cerrado, de contenedor y de túnel pueden generar una suma que no ofrece información fiable sobre la conexión física o un servicio concreto. Por lo tanto, documenta en el panel qué interfaces se tienen en cuenta o se excluyen.

Mantén las variables claras y en cascada: primero $environment, entonces $job y a continuación $instance; los paneles relacionados con el almacenamiento pueden $mountpoint Completar. Grafana puede generar variables de forma dinámica a partir de la fuente de datos y hacer que dependan unas de otras. Sin embargo, las consultas exhaustivas de valores de etiqueta en cada carga pueden ralentizar la inicialización del panel.

Clasificar los valores umbral basándose en los conocimientos operativos

Los umbrales se vuelven fiables cuando se comparan los eventos operativos con la evolución temporal. Las anotaciones de Grafana pueden señalar operaciones de mantenimiento, lanzamientos o cambios en la infraestructura en los paneles y hacer referencia a variables del panel de control. Esto permite, por ejemplo, comprobar si un cambio en la carga coincide en el tiempo con una implementación, en lugar de deducir precipitadamente que se trata de un fallo a partir de una línea gráfica.

Es normal que se produzca un pico de uso de la CPU a corto plazo durante una copia de seguridad, el precalentamiento de la caché o un procesamiento de datos programado. Sin embargo, solo es motivo de preocupación si se prolonga, coincide con tiempos de espera o errores y no existe una explicación prevista para el rol del servicio. El porcentaje de uso de la CPU por sí solo no demuestra ni una disminución de la disponibilidad ni la causa de la lentitud de una aplicación.

El aumento del consumo de almacenamiento requiere un enfoque diferente. Son factores decisivos el punto de montaje afectado, su función, la tasa de crecimiento y el momento en el que se puede ampliar la capacidad. Un volumen de datos con poco espacio libre puede ser más urgente que un volumen de archivo con un nivel de ocupación similar; además, las ventanas de copia de seguridad, la redundancia y las vías de recuperación modifican la prioridad operativa.

El tráfico de red inusual tampoco es motivo de alarma en sí mismo. Un aumento del tráfico puede deberse a un lanzamiento, un evento de un cliente, una replicación o una interfaz virtual incorporada de forma errónea. Por lo tanto, compara la instancia, la dirección, el filtro de interfaz y el contexto de servicio simultáneo. Solo esta combinación permite determinar si conviene profundizar en las métricas de la web, la base de datos o la red.

En el caso de los servidores de correo, la vista del host rara vez basta como única explicación. La CPU, la memoria y la red pueden poner de manifiesto anomalías, pero no evalúan ni la calidad del envío ni la capacidad de entrega. El Relación operativa entre el alojamiento de correo electrónico y la reputación Para ello, complementa las señales y dependencias específicas.

En lugar de establecer límites generales, debes documentar, para cada función, qué reacción debe desencadenar cada situación: observar, planificar la capacidad, informar al servicio de guardia o comprobarlo de inmediato. Esto Contexto operativoLa regla evita que los porcentajes visualmente idénticos se traten de la misma manera. Permite ajustar los valores límite de forma transparente cuando cambian el crecimiento, las ventanas de mantenimiento o la redundancia del entorno.

Mantener la escalabilidad de las consultas y los paneles de control

Un panel de control se vuelve difícil de leer y puede ralentizarse si cada panel consulta un gran número de filas durante largos periodos de tiempo y realiza varias veces los mismos cálculos complejos. Por lo tanto, limita la selección y la visualización a las entidades que sean relevantes para la cuestión operativa en cuestión. Para determinar qué consulta supone realmente una carga, hay que tener en cuenta su tiempo de ejecución y el volumen de resultados, y no solo su complejidad visual.

Las variables también merecen una comprobación de carga. Una lista de valores que ejecute consultas extensas de etiquetas al abrir el panel de control puede retrasar la inicialización. Lo más recomendable es seguir una secuencia en cascada: primero el entorno o el rol, luego el trabajo y, solo después, la instancia o el punto de montaje. De este modo, los conjuntos de selección se reducen y el panel de control general no intenta proporcionar todos los valores de etiquetas históricos y temporales al mismo tiempo.

Para las expresiones PromQL que se utilizan con frecuencia y requieren un gran esfuerzo de cálculo, existen Normas de grabación una opción específica. Prometheus evalúa una regla y almacena su resultado como una nueva serie temporal. A continuación, los paneles consultan esta serie precalculada en lugar de la expresión de salida completa. Esto puede acelerar las consultas recurrentes en los paneles de control, pero no sustituye la comprobación de si la selección, la agregación y el tiempo de retención son adecuados desde el punto de vista técnico.

Las reglas se ejecutan en grupos con intervalos de evaluación fijos. Si la evaluación de un grupo dura más que su intervalo, se pueden omitir algunas iteraciones. Por lo tanto, el cálculo previo no debe considerarse una solución universal para todas las consultas: comprueba primero qué paneles se utilizan realmente con frecuencia, cuántas filas procesa una expresión y si una vista basada en roles ya limita suficientemente la consulta.

Antes de implementar un archivo de reglas, es posible comprobar su sintaxis de forma local. El siguiente comando de terminal comprueba el archivo especificado, pero no modifica ninguna configuración actual de Prometheus ni activa ninguna regla.

promtool check rules /path/to/example.rules.yml

Además, ten en cuenta el tiempo de ejecución y la utilidad de cada regla. Cada nueva serie temporal debe guardarse y consultarse por separado. Para un pequeño panel de control con pocos hosts, una representación claramente filtrada puede resultar más sencilla y fácil de mantener; el cálculo previo merece la pena sobre todo cuando se necesita realizar el mismo cálculo, que supone una carga, varias veces de forma fiable.

Por lo tanto, la escalabilidad no se consigue únicamente mediante la optimización técnica. Un número reducido de paneles significativos, una selección limitada de etiquetas y vistas detalladas independientes también evitan que un panel de control resulte ilegible en caso de fallo. La velocidad y la información especializada deben evaluarse conjuntamente.

Planifica los cambios en las consultas, como un cambio operativo: comprueba el resultado en una copia del panel de control, compáralo con los periodos conocidos y solo entonces aplícalo al resumen. De este modo, los tiempos de carga anómalos, las series que faltan o los totales involuntarios se pueden rastrear, en lugar de que solo se hagan visibles cuando se produce una incidencia.

Sin embargo, una consulta concisa no garantiza que responda a la pregunta correcta. La reducción de filas no debe dar lugar a que queden ocultos roles, puntos de montaje o interfaces decisivos. Por lo tanto, documenta de forma consciente qué entidades incluye un panel y cuáles excluye para obtener una vista detallada.

Interpretar los paneles vacíos y las señales erróneas

Un panel vacío es, en primer lugar, una indicación de diagnóstico, no una indicación de si un servicio funciona correctamente o está inactivo. Comprueba lo siguiente en este orden: ¿existe la métrica en Prometheus?, ¿coinciden las etiquetas y los filtros utilizados?, ¿contiene datos el intervalo de tiempo seleccionado? y ¿proporciona la variante del exportador instalada esta serie de datos? Prometheus no aplica las configuraciones erróneas al recargarse; por lo tanto, un estado de destino o de configuración inesperado también puede ser relevante.

Si un panel muestra un estado de recopilación inesperado, comprueba primero el destino de recopilación configurado y el conjunto de datos real en Prometheus. Comprueba el exportador, la ruta de red, los certificados o los datos de acceso únicamente como posibles puntos de fallo, no como una causa ya confirmada. Para determinar la disponibilidad de un sitio web o una aplicación se requieren indicadores propios y adecuados desde el punto de vista técnico; un panel de monitorización por sí solo no basta para llegar a esa conclusión.

A menudo, el número inesperadamente elevado de series temporales se debe a un comparador demasiado amplio o a etiquetas adicionales que se han tomado de una plantilla. Comprueba primero la consulta sin procesar, sin agregación y sin variables de Grafana. De este modo, podrás determinar si, por ejemplo, la instancia, el dispositivo o el punto de montaje deben mostrarse por separado de forma deliberada. La agregación solo debe realizarse cuando quede claro qué entidades son comparables desde el punto de vista técnico.

En el caso de los valores del sistema de archivos, los pseudo-sistemas de archivos, los montajes de contenedores o las rutas temporales pueden distorsionar la tabla y una suma. Node Exporter documenta un colector para estadísticas del sistema de archivos, pero las series que se muestran realmente dependen del sistema y de la configuración del colector. Por lo tanto, filtra únicamente según una regla documentada de forma clara y comprueba los puntos de montaje incluidos en el entorno concreto.

Lo mismo ocurre con el rendimiento de la red. Una suma de todas las interfaces puede incluir interfaces de bucle cerrado, de túnel, virtuales o de contenedores, lo que puede generar una cifra sin relevancia operativa. Determina qué interfaces pertenecen a la ruta de tráfico en cuestión. Si esta decisión varía en función del rol del host, suele ser más comprensible utilizar una vista por roles que un filtro global.

Los valores de bytes o de CPU que aumentan de forma constante no suelen corresponder a un pico de carga, sino que Contador. Estas métricas registran un valor acumulado. Para el rendimiento o el uso de la CPU se requiere una tasa a lo largo de un intervalo de tiempo adecuado; Prometheus recomienda, cuando se combinan con agregaciones rate() que se debe aplicar antes de la agregación. Una ventana demasiado corta acentúa las oscilaciones, mientras que una demasiado larga puede ocultarlas.

Si un resultado sigue sin ser plausible, compáralo con una sola instancia, un único punto de montaje o una única interfaz y un intervalo de tiempo más reducido. Solo entonces se debe modificar una fórmula. Esta delimitación gradual evita que un problema de visualización quede oculto tras filtros cada vez más complejos.

Las plantillas de paneles importadas son solo un punto de partida. Los nombres de las métricas y las etiquetas pueden variar en función del sistema operativo, la versión del exportador, la contenedorización y los colectores activados. Por lo tanto, comprueba siempre las filas existentes y no te limites a revisar la sintaxis de una consulta importada.

De una visión general a una decisión empresarial bien fundamentada

Un panel de control de infraestructura sencillo es suficiente si lo que el equipo necesita principalmente es identificar qué host o qué función requiere atención. La accesibilidad de los scrapes, la carga, la memoria disponible y el tráfico de red proporcionan las primeras pistas al respecto. Sin embargo, no ofrecen una respuesta fiable sobre por qué una aplicación responde con lentitud o si un servicio específico está disponible para los usuarios. Grafana puede visualizar diferentes fuentes de datos, pero una interfaz común no sustituye al análisis de las causas.

En cuanto una anomalía se repita o afecte a varias funciones del sistema, la visión general necesita un Desglose . Las vistas de roles vinculadas o independientes pueden centrarse, por ejemplo, en servidores web, bases de datos, servidores de caché o de correo electrónico, según las métricas relevantes en cada caso. Una vista de diagnóstico complementa las series temporales por instancia, las tablas de dispositivos o puntos de montaje, así como la referencia temporal a los cambios. De este modo, la página de inicio sigue estando orientada a la acción, sin perder detalles técnicos relevantes.

Amplía la base de datos de forma gradual. Tras las métricas estables del host, pueden seguir valores específicos de la aplicación, como tasas de error, tiempos de respuesta, colas o estados de la base de datos. Los registros y los rastros resultan especialmente útiles cuando una evolución de las métricas delimita una causa, pero no la explica. No todas las vistas tienen que incluir todos los tipos de datos: cada serie adicional requiere una pregunta concreta y una decisión responsable sobre su mantenimiento.

Establece las responsabilidades para los paneles de control: ¿quién se encarga de actualizar las etiquetas y las variables, quién comprueba los filtros tras los cambios en la infraestructura, quién decide los valores límite y quién evalúa los paneles en desuso? Las reglas de registro también forman parte de esta tarea de mantenimiento, ya que complementan los archivos de reglas y las series temporales almacenadas. Sus intervalos fijos por grupo forman parte del flujo de datos y deben tenerse en cuenta a la hora de determinar la periodicidad esperada.

El seguimiento distingue entre la observación y los compromisos. Un panel verde no garantiza ni la seguridad ni el estado de los parches, ni la integridad de los datos ni la disponibilidad general. Los procesos de parches y seguridad, las copias de seguridad, los permisos y los procedimientos ante incidentes requieren controles propios. El panel de control puede proporcionar indicaciones y ayudar en la toma de decisiones, pero no debe sustituir estas tareas operativas por porcentajes calculados.

En entornos pequeños, un conjunto manejable de paneles de infraestructura con etiquetado coherente suele ser el punto de partida adecuado. A medida que aumenta el número de hosts, roles o clientes, las etiquetas claras, las vistas de roles y las consultas precalculadas cobran más importancia que una página de inicio cada vez más grande. Lo fundamental es que cada vista permita realizar una comprobación posterior y deje patentes sus límites de interpretación.

Revisa periódicamente el modelo operativo para detectar implementaciones, nuevos exportadores o cambios en las funciones de los servidores. Eliminar paneles y variables que ya no sean necesarios mejora la claridad, al igual que añadir nuevas métricas. Un panel de control sigue siendo eficaz cuando su presentación evoluciona al mismo ritmo que la arquitectura real y las responsabilidades.