Cómo alojar Grafana por tu cuenta en 2026: dashboards, alertas y estado persistente

Hay dos versiones de «ejecutar Grafana»: existe un contenedor o el servicio cumple su función real. Solo importa la segunda. Aquí, la prueba consiste en añadir una fuente de datos de solo lectura, guardar un panel, evaluar una regla de alerta y enviar una notificación de prueba mediante un contact point.

Grafana sirve para esto: dashboards y alertas sobre métricas, logs y trazas. El despliegue debe conservar los componentes que hacen posible ese comportamiento; un puerto, un volumen y un certificado son elementos de entrada, no el resultado.

La estructura de Grafana en producción

El proceso HTTP de Grafana escucha en el puerto 3000; mantén ese puerto en la red de la aplicación y publica únicamente la ruta de la plataforma. El contrato de red de Grafana requiere fuentes de datos accesibles y SMTP si se necesita entregar alertas. Mantén los endpoints privados en el DNS interno, permite solo las llamadas salientes necesarias y proporciona a Grafana una credencial de servicio con permisos limitados.

Deja constancia del límite con un contrato breve: quién es responsable del requisito, qué credencial se utiliza, qué timeout es aceptable y cómo se manifiesta un fallo. Después, ejecuta esta transacción: añade una fuente de datos de solo lectura, guarda un panel, evalúa una regla de alerta y envía una notificación de prueba mediante un contact point. Durante la ejecución, observa la distribución de consultas, los intervalos de actualización de los dashboards, la evaluación de alertas y la memoria de los plugins, en lugar de las propias métricas almacenadas por Grafana, porque esa carga ofrece un punto de partida más útil para dimensionar que un contenedor inactivo.

Inicia Grafana sin ocultar los componentes móviles

Inicia Grafana de forma que la ruta permanezca privada hasta completar el bootstrap.

docker run -d \
  --name grafana \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v grafana-data:/var/lib/grafana \
  -e GF_SECURITY_ADMIN_PASSWORD=replace-with-a-long-random-value \
  grafana/grafana:latest

Si el proceso entra en un bucle, compara el usuario esperado por la imagen con el propietario de cada ruta montada. Si permanece activo, prueba localmente el puerto 3000 y pasa directamente al flujo de trabajo: añade una fuente de datos de solo lectura, guarda un panel, evalúa una regla de alerta y envía una notificación de prueba mediante un contact point. Fija la versión de la imagen solo después de que esta comprobación de extremo a extremo se complete correctamente y registra la configuración exacta junto al servicio.

Proporciona a Grafana una única dirección canónica

La emisión de TLS es solo la mitad de la ruta de Grafana. Configura GF_SERVER_ROOT_URL con la URL HTTPS pública. Envía el tráfico internamente al puerto 3000 y reenvía el esquema externo para que las URL generadas y las cookies seguras sean coherentes.

Usa el escenario completo de Grafana desde una red limpia, no solo la página raíz. Un error 502 o de certificado puede aislarse con la configuración automática del dominio y TLS. Si el tráfico llega al proceso y los dashboards desaparecen junto con el archivo SQLite, o las callbacks de OAuth usan localhost, diagnostica esa condición en el punto donde se produce en lugar de encadenar redirecciones.

Diseña la restauración de Grafana antes del lanzamiento

El conjunto de recuperación duradero incluye la base de datos de Grafana, los plugins y la configuración aprovisionada. Monta /var/lib/grafana antes del bootstrap, escribe datos de ejemplo inofensivos y reemplaza el contenedor para demostrar que esa ruta es realmente persistente. Un volumen protege los datos frente al reemplazo del contenedor, pero no frente a la pérdida del host, el borrado accidental o la corrupción a nivel de aplicación.

Realiza copias de seguridad que entiendan la fuente de datos: usa dumps lógicos para bases de datos activas cuando sea necesario y copia archivos únicamente desde un estado coherente. Conserva una copia cifrada fuera del host de Grafana. El criterio de aceptación de una restauración debe ser específico: deben volver los usuarios, las carpetas, los dashboards, las reglas de alerta y los metadatos de las fuentes de datos, y la alerta de prueba debe evaluarse. La guía de copias de seguridad con restauraciones verificadas explica por qué el éxito del job, por sí solo, no es suficiente.

Cierra el acceso temporal de configuración

Un despliegue seguro de Grafana empieza eliminando privilegios. Evita mantener admin/admin o exponer el acceso anónimo de forma involuntaria; en su lugar, sustituye la contraseña del administrador de bootstrap, restringe la edición de fuentes de datos y mantén los tokens de las cuentas de servicio con permisos limitados.

Sustituye inmediatamente GF_SECURITY_ADMIN_PASSWORD de ejemplo, almacénalo fuera de la imagen y rótalo como una credencial de administrador si queda expuesto. Restringe las rutas administrativas, usa DNS privado para las dependencias y revisa cada bind mount. Cuando los logs se envíen de forma centralizada, filtra los secretos y el contenido privado antes de que abandonen el servidor.

Ensaya el cambio de Grafana más arriesgado

Un contenedor en estado correcto es necesario, pero no suficiente. El indicador de nivel de servicio es completar correctamente «añadir una fuente de datos de solo lectura, guardar un panel, evaluar una regla de alerta y enviar una notificación de prueba mediante un contact point», mientras que las señales de presión más probables son la distribución de consultas, los intervalos de actualización de los dashboards, la evaluación de alertas y la memoria de los plugins, no las propias métricas almacenadas por Grafana.

El control de cambios es importante porque las migraciones de la base de datos de Grafana y la compatibilidad de los plugins requieren una actualización escalonada con los mismos archivos de aprovisionamiento. Conserva la imagen anterior, prueba las migraciones con una copia del estado y documenta si se admite el rollback después de mover el esquema. Si los dashboards desaparecen junto con el archivo SQLite o las callbacks de OAuth usan localhost, diagnostica el primer límite que difiera del entorno operativo.

Registra un despliegue de Grafana conocido como válido

Para Grafana, define una transacción conocida como válida antes del lanzamiento: añade una fuente de datos de solo lectura, guarda un panel, evalúa una regla de alerta y envía una notificación de prueba mediante un contact point. Guarda sus requisitos previos, la respuesta esperada y los pasos de limpieza en el control de versiones, sin valores secretos. Fija la imagen utilizada para establecer esa referencia.

Usa la transacción para validar un reemplazo y una restauración independiente. El servicio restaurado solo será aceptable cuando vuelvan los usuarios, las carpetas, los dashboards, las reglas de alerta y los metadatos de las fuentes de datos, y la alerta de prueba se evalúe. Al mismo tiempo, observa la distribución de consultas, los intervalos de actualización de los dashboards, la evaluación de alertas y la memoria de los plugins, en lugar de las propias métricas almacenadas por Grafana, y convierte la parte más lenta o más limitada en una alerta de nivel de servicio.

El gate también necesita un caso negativo: deniega temporalmente a la identidad de prueba el acceso a las fuentes de datos accesibles y a SMTP si se requiere entregar alertas. Confirma que Grafana produce un error accionable sin perder datos, restaura la condición válida y repite la transacción conocida como válida. Conservar ambos resultados evita que un endpoint de health superficial se convierta en la única evidencia en producción.

Cómo Dockup elimina trabajo con Grafana

El routing, los certificados, el reemplazo del servicio y el almacenamiento asociado son objetivos razonables de automatización. Dockup se ocupa de ellos para Grafana y puede aprovisionar la base de datos gestionada relacionada o conectarse a servicios en el servidor del propio cliente.

Lo que no debería inventar es la política de confianza de Grafana. Después del despliegue, configura GF_SERVER_ROOT_URL con la URL HTTPS pública, aplica este límite —sustituye la contraseña del administrador de bootstrap, restringe la edición de fuentes de datos y mantén los tokens de las cuentas de servicio con permisos limitados— y verifica el resultado de este escenario: añade una fuente de datos de solo lectura, guarda un panel, evalúa una regla de alerta y envía una notificación de prueba mediante un contact point. El resultado es una infraestructura de un solo clic con una prueba de aceptación específica de la aplicación.

Preguntas frecuentes

¿Qué necesita Grafana para un despliegue en producción?

Enruta el contenedor de Grafana en el puerto 3000 a través de un único origen HTTPS. El requisito de red adicional consiste en disponer de fuentes de datos accesibles y SMTP si se necesita entregar alertas. No consideres que Grafana está listo hasta que puedas añadir una fuente de datos de solo lectura, guardar un panel, evaluar una regla de alerta y enviar una notificación de prueba mediante un contact point.

¿Qué datos de Grafana deben incluirse en una copia de seguridad?

Haz persistir /var/lib/grafana e incluye la base de datos de Grafana, los plugins y la configuración aprovisionada en el mismo manifiesto de recuperación. Una restauración limpia de Grafana solo es válida cuando vuelven los usuarios, las carpetas, los dashboards, las reglas de alerta y los metadatos de las fuentes de datos, y la alerta de prueba se evalúa.

¿Grafana necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de Grafana y mantén el puerto 3000 en la ruta interna. Aplica correctamente la configuración de Grafana: establece GF_SERVER_ROOT_URL con la URL HTTPS pública. En Grafana, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

¿Cómo debe probarse una actualización de Grafana?

Restaura el estado actual de Grafana en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque las migraciones de la base de datos de Grafana y la compatibilidad de los plugins requieren una actualización escalonada con los mismos archivos de aprovisionamiento. Conserva la imagen anterior de Grafana hasta comprender sus límites de migración de datos y rollback.