Es lunes por la mañana. Alguien del equipo tocó un panel de Grafana durante el fin de semana para investigar un incidente. Cambió umbrales, añadió queries nuevas, reorganizó visualizaciones. El problema se resolvió, pero nadie documentó qué cambió exactamente en ese panel. Tres semanas después, las alertas se disparan por umbrales que ya no tienen sentido, y nadie recuerda qué configuración había antes ni por qué funcionaba mejor.
Esta situación se repite en equipos de todo el mundo. Los paneles de observabilidad, las alertas y los SLOs suelen vivir en interfaces gráficas, configurados a mano, modificados sobre la marcha, y documentados —cuando se documentan— en wikis que nadie actualiza. Funciona hasta que deja de funcionar. Y cuando falla, reconstruir el estado anterior es arqueología.
La observabilidad como código propone algo distinto: que toda esa configuración viva en archivos de texto, versionados en Git, revisados como cualquier otro cambio de infraestructura, y desplegados de forma automatizada. No es una idea nueva —la infraestructura como código lleva años demostrando su valor—, pero aplicarla a la observabilidad tiene particularidades que vale la pena entender.
Qué significa realmente tratar la observabilidad como código
Cuando hablamos de observabilidad como código, nos referimos a definir paneles, alertas, SLOs, reglas de agregación y políticas de retención en archivos declarativos que describen el estado deseado del sistema de observabilidad. Esos archivos se almacenan en un repositorio, se revisan mediante pull requests, y se aplican automáticamente mediante pipelines de CI/CD.
La diferencia con el enfoque tradicional no es solo técnica. Es cultural. En lugar de que cualquier persona del equipo pueda modificar alertas directamente en producción, los cambios pasan por el mismo flujo que cualquier otro cambio de infraestructura: propuesta, revisión, aprobación, despliegue. Esto no significa burocracia innecesaria. Significa trazabilidad.
Imagina que una alerta empieza a generar falsos positivos. Con observabilidad como código, puedes hacer un git diff y ver exactamente qué cambió, cuándo y quién lo aprobó. Puedes revertir el cambio con un comando. Puedes entender por qué alguien configuró ese umbral en 95% y no en 90%. La historia está ahí, no en la memoria de quien estaba de guardia hace seis meses.
El problema que resuelve (y el que no)
La observabilidad como código resuelve problemas concretos que aparecen cuando los equipos crecen o cuando la infraestructura se vuelve compleja. Si tu equipo tiene tres personas y gestionáis diez servicios, probablemente no necesites esto todavía. Pero si tenéis veinte servicios, cinco equipos tocando la misma infraestructura de monitorización, y cada semana alguien pregunta «¿quién cambió esta alerta?», entonces sí.
El valor principal es la consistencia. Cuando defines tus alertas como código, puedes aplicar patrones comunes a todos los servicios. Si decides que todos los SLOs de latencia deben medirse con percentil 99 en ventanas de 30 días, escribes esa definición una vez y la reutilizas. Si necesitas cambiar la política, cambias el código y se propaga automáticamente. Sin tener que recordar en qué panel de qué servicio configuraste qué cosa.
También resuelve el problema de los entornos múltiples. Si tienes staging, preproducción y producción, mantener paneles y alertas sincronizados entre entornos es tedioso cuando se hace a mano. Con código, despliegas la misma definición en cada entorno, ajustando solo los parámetros específicos como umbrales o destinos de notificación.
Lo que NO resuelve es la complejidad inherente de decidir qué observar. Si no sabes qué métricas importan, qué umbrales tienen sentido o cómo estructurar tus SLOs, convertir esa confusión en código no la elimina. La observabilidad como código es una herramienta de gestión, no un sustituto del criterio operativo.
Cómo se materializa en la práctica
La implementación varía según las herramientas que uses, pero el patrón general es similar. Defines tus recursos de observabilidad en archivos de configuración —JSON, YAML, o lenguajes más expresivos como Jsonnet o CUE—, los almacenas en Git, y usas herramientas de aprovisionamiento para aplicarlos.
Para paneles de Grafana, puedes exportar la definición JSON de un panel existente, almacenarla en Git, y usar el proveedor Terraform de Grafana para gestionarla. Cada vez que alguien quiere modificar un panel, edita el JSON, abre una pull request, y tras la revisión se despliega automáticamente. Grafana también soporta aprovisionamiento nativo: lee archivos de configuración del sistema de archivos al arrancar, o en caliente cuando los archivos cambian, lo que encaja bien con despliegues en contenedores. Con Grafana 12 —lanzado en GrafanaCON 2025— el equipo ha ido más lejos, introduciendo el Foundation SDK para definir dashboards en código tipado (Go, TypeScript, Python) y nuevos recursos Terraform con validación de esquema. Es la apuesta más clara de Grafana Labs por hacer de la observabilidad como código un flujo de primera clase.
Las alertas de Prometheus se definen en archivos YAML que contienen grupos de reglas —tanto de alerta como de agregación—. Estos archivos se referencian en la configuración principal de Prometheus y pueden recargarse en caliente sin reiniciar el proceso. Prometheus Operator, en entornos Kubernetes, permite definir esas reglas como recursos nativos del clúster (PrometheusRule), integrándolos con el mismo flujo de GitOps que usas para el resto de la infraestructura.
Los SLOs son más interesantes porque requieren definir múltiples componentes: el indicador base, la ventana de tiempo, el objetivo y las alertas asociadas. Herramientas como Sloth generan automáticamente reglas de alerta y paneles a partir de definiciones de SLO en YAML, siguiendo la estrategia multi-window multi-burn-rate del libro de SRE de Google. Defines que tu servicio debe responder en menos de 500 ms el 99,9% del tiempo en ventanas de 30 días, y Sloth genera todas las reglas de Prometheus necesarias para medirlo y alertar cuando se incumple.
Dynatrace tiene su propio enfoque con Monaco, una CLI open source que permite gestionar la configuración de Dynatrace como código. El nombre viene de «Monitoring as Code», su foco original, aunque hoy cubre toda la superficie de configuración de la plataforma. Funciona con manifests YAML que referencian templates JSON —el formato nativo de la API de Dynatrace—, y se integra en pipelines de CI/CD para mantener sincronizadas múltiples instancias o entornos. Es especialmente útil en organizaciones grandes donde varios equipos comparten el mismo tenant y necesitan mantener configuraciones consistentes sin pisarse entre ellos. Para quienes ya trabajan con Terraform, Dynatrace también mantiene un proveedor oficial como alternativa.
Cuando el código se convierte en el problema
La observabilidad como código introduce su propia fricción. Editar un archivo JSON de 500 líneas que define un panel de Grafana no es intuitivo. La interfaz gráfica existe por algo: permite explorar, probar, iterar rápidamente. Cuando estás investigando un incidente, lo último que quieres es abrir un editor de texto, modificar JSON, hacer commit, push, esperar a que pase la CI, y que se despliegue el cambio.
Por eso muchos equipos adoptan un enfoque híbrido. Los paneles y alertas de producción —los que forman parte de la operativa estándar— viven como código. Pero se mantiene un espacio para paneles temporales y experimentales donde la gente puede crear visualizaciones ad-hoc sin pasar por todo el proceso. Estos paneles no se versionan, no se despliegan automáticamente, y se eliminan periódicamente. Es el equivalente a tener un entorno de desarrollo donde puedes romper cosas sin consecuencias.
Otro problema es la verbosidad de los formatos. Los JSON de Grafana o los templates de Monaco pueden ser difíciles de mantener a mano. Aquí es donde lenguajes de configuración como Jsonnet o CUE aportan valor: permiten definir plantillas, reutilizar componentes y generar configuraciones complejas a partir de definiciones más simples. Pero añaden una capa de abstracción y con ella una curva de aprendizaje adicional.
La revisión de cambios como salvavidas
El mayor beneficio de la observabilidad como código no es técnico. Es humano. Cuando un cambio en una alerta pasa por revisión, otra persona tiene que leerlo y entenderlo. Eso obliga a quien propone el cambio a explicar el razonamiento. «Subo el umbral de esta alerta de 80% a 95% porque hemos mejorado el rendimiento del servicio y el umbral anterior genera falsos positivos» es información valiosa que, sin código, se perdería.
Las revisiones también detectan errores antes de que lleguen a producción. Es fácil equivocarse con un cero de más en un umbral, o configurar una alerta para que se dispare cada minuto en lugar de cada hora. En una interfaz gráfica, ese error solo se descubre cuando la alerta empieza a inundar el canal de Slack. En una pull request, alguien lo ve y comenta antes de que se despliegue.
Además, el historial de Git se convierte en documentación viva. Cuando te preguntas por qué existe una alerta específica, buscas el commit que la introdujo y lees la descripción. Puedes ver qué incidente motivó su creación, qué discusión hubo en la revisión, qué alternativas se consideraron. Esa información es oro cuando, dos años después, alguien propone eliminar esa alerta porque «parece que no sirve para nada».
Empezar sin reescribir todo desde cero
Adoptar observabilidad como código no requiere una migración masiva. Puedes empezar con las alertas críticas, las que más impacto tienen en la operativa. Exportas sus definiciones, las versionas en Git, y estableces que a partir de ahora cualquier cambio en esas alertas pasa por pull request. El resto puede seguir gestionándose como hasta ahora.
Con el tiempo, a medida que el equipo se acostumbra al flujo, puedes ir incorporando más recursos: paneles de servicios clave, SLOs, reglas de agregación. No hay prisa. Lo importante es que el proceso aporte valor, no que sea exhaustivo desde el primer día.
También ayuda empezar con herramientas que ya conoces. Si tu equipo usa Terraform para gestionar infraestructura, extenderlo para gestionar recursos de observabilidad es natural. Si usáis Kubernetes y Helm, definir alertas como recursos del clúster encaja con vuestro flujo existente. La clave es reducir la fricción, no añadir más herramientas solo porque sí.
Cuando no tiene sentido
La observabilidad como código tiene un coste: añade pasos, requiere disciplina, y ralentiza cambios urgentes. Si tu equipo es pequeño, si la infraestructura es simple, o si los cambios en observabilidad son poco frecuentes, ese coste puede no justificarse. Hay contextos donde la agilidad de modificar una alerta directamente en la interfaz vale más que la trazabilidad de versionarla en Git.
También hay situaciones donde el enfoque declarativo choca con la realidad. Si tus paneles cambian constantemente porque estás explorando nuevos servicios o experimentando con métricas, forzar todo a pasar por código puede ser contraproducente. En esos casos, es mejor mantener la flexibilidad y consolidar en código solo lo que se estabiliza.
La observabilidad como código es una herramienta, no un dogma. Funciona cuando resuelve problemas reales que tu equipo tiene hoy, no cuando se adopta porque «es lo que se hace». Si tus alertas funcionan bien, si los cambios son raros, si el equipo está contento con el flujo actual, no hay razón para cambiarlo. Pero si estás perdiendo tiempo reconstruyendo configuraciones, si los cambios no documentados causan problemas, o si la falta de consistencia entre servicios te está costando incidentes, entonces sí: es hora de considerar este enfoque.
Para seguir aprendiendo
- Implementing Service Level Objectives — Alex Hidalgo, O’Reilly. El libro de referencia sobre SLOs, incluyendo cómo definirlos e implementarlos de forma práctica.
- Documentación de Prometheus sobre reglas — Formato de definición de recording rules y alerting rules, con ejemplos y mejores prácticas.
- Sloth en GitHub — Generador de SLOs para Prometheus con soporte para multi-window multi-burn-rate, Kubernetes CRDs y OpenSLO.
- Grafana as code — documentación oficial — Suite de herramientas de Grafana Labs para gestionar dashboards y datasources como código, incluyendo Foundation SDK, Terraform provider y aprovisionamiento nativo.
- Dynatrace Monaco — documentación oficial — Guía completa de la CLI de configuración como código de Dynatrace, con ejemplos de manifests y casos de uso multi-entorno.
