Son las 3:14 de la madrugada. El checkout de tu tienda online lleva diez minutos con la latencia disparada y el SRE de guardia abre el dashboard de siempre, ese que lleva años clavado como fuente de verdad del equipo. El panel de latencia marca verde. Todo en orden… salvo que los usuarios no pueden pagar. ¿Qué ha pasado? Que durante el incidente de la semana pasada alguien cambió la consulta del panel de p99 a p50 para «ver mejor» una cosa puntual, no lo revirtió y nadie se enteró. El dashboard mentía. Y lo peor: no había forma sencilla de saber quién lo tocó, cuándo ni por qué.
Si esa escena te resulta familiar, no estás solo. La gestión de dashboards es uno de esos problemas que damos por resuelto hasta que nos estalla en la cara durante un incidente. Y es justo el problema que un proyecto de la CNCF, Perses, intenta atacar de raíz con una idea sencilla de enunciar y difícil de implementar bien: dashboards as code.
Cuando los dashboards se convierten en un dolor de cabeza
Si alguna vez has mantenido dashboards en Grafana o Kibana, sabes que el proceso puede ser frustrante. El escenario típico: alguien crea un panel con métricas críticas, otro lo modifica para un incidente, un tercero clona el dashboard «para no tocar el bueno» y, al final, nadie sabe qué versión es la fiable. El control de cambios es débil, la documentación escasa y la colaboración limitada. Y en entornos donde todo se despliega con GitOps, tener que editar dashboards a mano rompe el flujo: el resto de la infraestructura vive en Git, pero la capa de visualización sigue siendo un clic manual sin trazabilidad.
El problema no es solo la gestión, sino la reproducibilidad y la trazabilidad. ¿Cómo aseguras que un dashboard refleja exactamente lo que quieres en producción? ¿Cómo evitas que un cambio urgente provoque un desastre visual o, peor, que el panel acabe mostrando algo distinto de lo que todos creen que muestra? Ahí es donde Perses propone un cambio de enfoque.
Perses: dashboards as code en el ecosistema CNCF
Perses nació en 2021 como un proyecto interno de Amadeus, el gigante tecnológico del sector de los viajes. Su creador, Augustin Husson —que además es mantenedor de Prometheus—, se enfrentaba a un problema muy concreto: gestionar más de 5.000 dashboards a escala. La conclusión fue que el modelo de «abrir la UI y crear paneles a mano» no aguanta cuando hablas de cientos de microservicios y miles de paneles.
Pero hay una segunda capa en esta historia que conviene conocer, porque explica buena parte del por qué de Perses. En 2021, Grafana relicenció su producto principal de Apache 2.0 a la más restrictiva AGPLv3. Aquello generó inquietud en una parte de la comunidad cloud-native, que buscaba una herramienta de visualización con una licencia permisiva y gobernanza neutral. De esa preocupación surgió la comunidad CoreDash, primero bajo la Linux Foundation, y Perses como su materialización: un framework de dashboards declarativo, Apache-2.0, nativo de Kubernetes y pensado desde el primer día para GitOps. En agosto de 2024, Perses fue aceptado en la CNCF como proyecto sandbox, junto a nombres como Prometheus, Kubernetes u OpenTelemetry.
Esto es importante por dos motivos. El primero: Perses no es un fork ni una capa por encima de Grafana; es un stack de visualización independiente, con su propio modelo de datos y su propio frontend. El segundo: ser proyecto sandbox significa que es maduro como concepto pero joven como producto. Tenlo presente antes de plantear migraciones.
La filosofía es la que ya conoces de otros ámbitos: igual que tenemos infrastructure as code o policy as code, aquí los dashboards se definen como código —revisable, testeable y desplegable mediante pipelines— y se almacenan en Git como cualquier otro recurso. La fuente de verdad deja de ser la base de datos interna de una herramienta y pasa a ser tu repositorio.
¿Cómo funciona Perses en la práctica?
Aquí es donde Perses se aleja del «exporta el JSON y rézale a los dioses del versionado». El proyecto ofrece varias formas de trabajar los dashboards como código de verdad:
- Un modelo de datos declarativo (en JSON o YAML) que sigue las convenciones de Kubernetes. Es la base, pero escribir YAML a mano para decenas de paneles es tedioso y propenso a errores.
- SDKs en Go y en CUE para definir dashboards programáticamente. Aquí está la gracia: puedes crear bibliotecas de componentes reutilizables —desde una paleta de colores hasta plantillas de paneles completas— y aplicar el mismo cambio a decenas de dashboards de una tacada, sin copiar y pegar.
- Una CLI,
percli, que permite validar dashboards de forma estática y ejecutar acciones dentro de pipelines de CI/CD. Puedes cazar un dashboard mal formado en la propia pull request, antes de que llegue a producción. - Un operator que gestiona despliegues y dashboards de Perses como CRDs dentro del clúster, con descubrimiento de datasources incluido.
Con esto, el flujo se parece mucho al de cualquier cambio de código. Supón que tu equipo ha instrumentado una nueva métrica para un servicio web. En lugar de abrir la UI y montar el panel a mano, modificas la definición del dashboard en el SDK, abres una pull request, un compañero la revisa, la CLI valida que el formato es correcto y, al hacer merge, un pipeline despliega el dashboard actualizado. El que ves en la interfaz de Perses es siempre el resultado de una versión concreta en Git. Si algo falla, vuelves atrás, comparas versiones o auditas quién cambió qué y por qué.
En la parte de visualización, Perses no se queda corto para los casos habituales: soporte de Prometheus con paneles especializados para métricas, un explorador de métricas integrado y un depurador de PromQL que replican la experiencia de la UI nativa de Prometheus. Y no se limita a las métricas: el proyecto ya cubre las cuatro grandes señales con Prometheus (métricas), Tempo (trazas), Loki (logs) y Pyroscope (profiling).
¿Perses frente a Grafana? No es una cuestión de reemplazo
Conviene desmontar el titular fácil. Grafana sigue siendo la herramienta de facto para dashboards en la mayoría de entornos, y con razón: es potente, flexible y tiene una comunidad y un ecosistema de plugins enormes. Perses no pretende ser un reemplazo directo, sino una alternativa para casos donde la gestión declarativa, la trazabilidad y una licencia permisiva son prioritarias.
La diferencia de fondo es que Perses pone el dashboards as code y la integración con GitOps en el centro del diseño, no como un añadido. Y lo hace con un stack propio y vendor-neutral. Eso es especialmente atractivo para organizaciones que ya han adoptado GitOps en sus despliegues y quieren extender esa disciplina a la observabilidad sin atarse a la base de datos interna de una herramienta concreta.
Ahora bien, seamos honestos: Perses todavía es un proyecto joven. No tiene la madurez, la variedad de plugins, las fuentes de datos ni el soporte comercial de Grafana. No es la opción si buscas una herramienta lista para todo con respaldo empresarial amplio. Pero si tu objetivo es meter los dashboards en tus pipelines, mejorar la trazabilidad de los cambios y estandarizar la visualización, merece la pena tenerlo en el radar.
¿Cuándo usar Perses y cuándo no?
Perses brilla en entornos Kubernetes donde GitOps es la norma y la reproducibilidad es clave. Si tu equipo ya gestiona configuraciones, despliegues y políticas con Git y pipelines, añadir dashboards as code es un paso natural que reduce fricción y mejora la colaboración.
También es buena opción si quieres evitar la «deriva» visual: dashboards que cambian sin control, que nadie sabe quién modificó o que no se pueden replicar fácilmente en entornos de prueba o desarrollo. Justo el problema del incidente de las 3 de la madrugada del principio.
Por otro lado, si tu entorno es pequeño, con pocos dashboards o sin una cultura GitOps consolidada, Perses puede añadir complejidad innecesaria. En esos casos, seguir con Grafana y su interfaz tradicional suele ser más rápido y efectivo.
Y si necesitas una solución con soporte comercial fuerte, un catálogo enorme de plugins o conectores con multitud de fuentes de datos exóticas, Perses todavía no está ahí. Es un proyecto muy interesante para seguir y probar en un laboratorio, pero no para reemplazar herramientas maduras en producción sin pruebas exhaustivas.
Un vistazo al futuro de los dashboards as code
La idea de gestionar dashboards como código no es nueva, pero Perses es de los primeros proyectos CNCF que la lleva a la práctica con integración nativa en Kubernetes y GitOps, y con un modelo de gobernanza vendor-neutral detrás. Esto abre la puerta a una observabilidad más disciplinada, donde la visualización se gestiona y se audita igual que el propio código de la aplicación.
En el futuro no sería raro ver que herramientas consolidadas adopten funcionalidades similares o que Perses madure hasta cubrir más casos y ampliar su ecosistema. De momento es una propuesta reciente que invita a repensar cómo gestionamos la observabilidad en entornos modernos. Y, sobre todo, a no volver a fiarte de un dashboard que igual lleva semanas mintiéndote.
Para seguir aprendiendo
- Documentación oficial de Perses (perses.dev): para entender su arquitectura, el modelo de datos y las fuentes soportadas (Prometheus, Tempo, Loki y Pyroscope).
- Repositorio de Perses en GitHub (github.com/perses/perses): código, estado actual del proyecto y la guía de Dashboard-as-Code con los SDKs de Go y CUE.
- «PromCon recap: unveiling Perses» en el blog de la CNCF (cncf.io): la historia de origen del proyecto, contada de primera mano, incluido el contexto de la relicencia de Grafana.
- OpenGitOps (opengitops.dev): los principios de GitOps definidos por el grupo de trabajo de la CNCF, para entender el modelo que Perses lleva a la capa de visualización.
- «GitOps Cookbook», de Natale Vinto y Alex Soto Bueno (O’Reilly): recetas prácticas para integrar despliegues y configuraciones con Git en entornos Kubernetes.
- «Observability Engineering», de Charity Majors, Liz Fong-Jones y George Miranda (O’Reilly): para profundizar en la observabilidad y en cómo gestionarla en equipos modernos.
