Monitoreo como código: sus comprobaciones, en un pull request

Abra su panel de monitoreo y cuente las comprobaciones que nadie sabe explicar. La del intervalo de 47 segundos: ¿por qué 47? Las dos que siguen apuntando a una máquina de staging que se dio de baja en marzo. La comprobación HTTP que lleva tanto tiempo en ámbar que todo el equipo lee el ámbar como verde. Alguien creó cada una de ellas a propósito, en su momento. Luego cambió de equipo, o se fue, y el razonamiento se marchó con esa persona.

Eso es lo que hacer clic en botones le hace al monitoreo. La configuración es real, sostiene cosas importantes y no vive en ningún sitio donde se pueda leer. No puede compararla con un diff, no puede revisarla, no puede preguntarle a git blame quién fijó ese tiempo de espera y en qué estaba pensando. Se supone que el monitor es aquello en lo que confía cuando todo lo demás está en llamas, y lo ha construido sobre un montón de clics sin documentar.

Así que póngalo bajo control de versiones. No porque la infraestructura como código sea una virtud que coleccionar, sino porque un monitor es exactamente el tipo de configuración discreta y duradera que se convierte en un riesgo en cuanto deja de verse.

En resumen

Un monitor creado a clics en un panel no tiene diff, ni historial, ni constancia de por qué existe. Llévelo a un repositorio y cada cambio será un pull request revisado al que puede hacer git blame; una región nueva pasa a ser un solo apply en lugar de una tarde de clics. El precio es un archivo de estado que mantener. Uptimepage lo admite mediante Terraform, una API REST y MCP.

Lo que «como código» le aporta de verdad

No es escribir. Declarar un monitor en HCL exige más pulsaciones que hacer clic en «nueva comprobación», y quien le diga que escribir es lo importante nunca ha mantenido más de tres.

Lo importante es el pull request. Cuando un monitor vive en un repositorio, cambiarlo pasa a ser algo que una segunda persona mira antes de que sea real. «¿Por qué bajamos el intervalo a diez segundos en la comprobación de pagos?» es una conversación mucho mejor para un PR que para un postmortem. Obtiene un diff y obtiene un historial. Puede montar una región completamente nueva y reproducir cuarenta monitores con un solo apply en lugar de pasar cuarenta tardes haciendo clic. Y cuando la persona que fijó el umbral se va, el umbral y su motivo se quedan en el archivo.

Este es el ejemplo más pequeño que funciona, con el proveedor de Terraform de Uptimepage:

terraform {
  required_providers {
    uptimepage = {
      source = "uptimepage/uptimepage"
    }
  }
}

resource "uptimepage_target" "api" {
  name     = "api prod"
  interval = 60

  check = {
    type = "http"
    http = {
      url = "https://api.example.com/healthz"
      expected_status = {
        kind  = "exact"
        exact = 200
      }
    }
  }
}

Fíjese en que el bloque check está anidado, no es un montón plano de campos. Usted fija type = "http" y luego rellena un http = { ... }. Es una decisión de esquema deliberada, y acertada: un recurso plano con url, port, host, record_type y cert_days colgando todos del nivel superior le dejaría escribir disparates, como una comprobación TCP con un comparador de estado HTTP, y solo se enteraría al hacer el apply. La forma anidada hace imposible escribir esos estados inválidos. Solo puede fijar los campos http cuando el tipo es http. Se lee algo verboso, y le ahorra toda una categoría de errores que la versión plana invita a cometer.

Lo que se salta la guía de inicio rápido

Todos los tutoriales de Terraform se detienen en «y ahora ejecute apply». Hay tres cosas que no le cuentan, más o menos en orden de lo fuerte que le van a morder.

El estado, no el panel. Terraform registra lo que cree que existe. Cambie un intervalo en la interfaz web y Terraform no se entera; el siguiente plan le propondrá tan tranquilo revertir su cambio manual a lo que dice el código. Así está diseñado: una vez que un monitor está en código, manda el código, y tocar cosas en el panel se convierte en una deriva que Terraform deshará en silencio. Decídalo de antemano. Ejecute terraform plan -refresh-only para ver la deriva antes de que le sorprenda.

Si borra el bloque, borra el monitor. Quite esas ocho líneas de su archivo .tf, ejecute apply y la comprobación real deja de ejecutarse. En silencio. Con la mayoría de los recursos, eso da igual. Con lo que vigila su API de producción, «limpié un poco de configuración y dejamos de monitorear los pagos durante una semana» es una frase real que hay gente que ha dicho en voz alta. Yo he estado más cerca de decirla de lo que me gustaría. Trate un monitor eliminado con la misma desconfianza que una tabla borrada, porque el radio de impacto es el mismo: no lo nota hasta que se rompe lo que dejó de vigilar.

Secretos en el estado. Si su comprobación necesita autenticación básica o un token, ese valor tiene que llegar al proveedor de alguna forma, y lo que le pase se escribe en el archivo de estado en texto plano, al alcance de cualquiera con acceso de lectura al backend. El proveedor marca la contraseña como sensitive, y conviene ser preciso sobre lo que eso le da: sensitive mantiene el valor fuera de la salida de plan y de los logs. No lo mantiene fuera del estado. Terraform 1.11, allá por febrero de 2025, añadió la solución real, los argumentos de solo escritura: valores que pasan al proveedor durante el apply y nunca se guardan en el estado. Hasta que el proveedor de Uptimepage los adopte, trate el propio archivo de estado como un secreto:

variable "admin_password" {
  type      = string
  sensitive = true
}

resource "uptimepage_target" "admin" {
  name     = "admin panel"
  interval = 120

  check = {
    type = "http"
    http = {
      url = "https://admin.example.com/"
      expected_status = {
        kind = "range"
        range = {
          min = 200
          max = 299
        }
      }
      basic_auth = {
        username = "uptime"
        password = var.admin_password
      }
    }
  }
}

La contraseña llega a la API y no aparece en su terminal, pero sigue acabando en el estado. Use un backend que cifre en reposo y piense bien quién puede leerlo. Cuando el proveedor adopte los argumentos de solo escritura, la contraseña dejará de tocar el estado por completo; hasta entonces, el backend cifrado es lo que de verdad la protege.

No reconstruya lo que ya tiene

Si ya tiene monitores creados a mano, y los tiene, no hace falta volver a introducirlos. La importación basada en configuración existe en Terraform desde la 1.5: escriba el bloque del recurso como lo quiere, añada un bloque import que apunte al id del monitor existente, y apply lo adopta en lugar de crear un duplicado.

import {
  to = uptimepage_target.api
  id = "the-existing-monitor-id"
}

Ejecute plan y léalo con lupa. Una importación limpia no muestra cambios. Si el plan quiere modificar algo, su HCL todavía no coincide con la realidad, así que corrija el código, no el monitor, hasta que el diff quede vacío. Después borre el bloque import; ya cumplió su función. Un detalle de la sección anterior: un secreto como esa contraseña de autenticación básica no se puede leer de vuelta desde la API, así que una importación no lo recupera. Lo fija usted en la configuración, una vez, y a partir de ahí se encarga Terraform.

Un flujo de trabajo que no le saque de la cama

La estructura que aguanta: estado remoto con bloqueo (para que dos personas no puedan hacer apply a la vez y corromperlo), terraform plan ejecutándose automáticamente en cada pull request para que los revisores vean el diff, y apply condicionado a un merge en su rama principal. Nadie ejecuta apply desde su propia máquina a las 2 de la madrugada. La misma disciplina que querría en torno a una migración de base de datos, aplicada a lo que le avisa de que la base de datos está caída.

Los monitores, las páginas de estado y los canales de notificación son aquí simples recursos (uptimepage_status_page, uptimepage_notification_channel y compañía), así que toda la cara pública de su monitoreo (qué página muestra qué, a quién se avisa por qué canal) acaba siendo revisable en el mismo PR que las propias comprobaciones.

El mismo truco funciona en la otra dirección: un servidor MCP también es algo que se cae, y monitorear uno es un monitor más que puede declarar aquí junto con el resto.

Y esos mismos monitores que declara en código, un asistente de IA puede leerlos de vuelta por MCP: «¿qué está roto ahora mismo, y desde cuándo?», respondido en lenguaje natural a partir de la configuración exacta que está en su repositorio. Declarados en un pull request por un lado, consultados por un asistente por el otro. Los mismos datos, los mismos alcances.

Aburrido, también en código

Ya hemos defendido que su monitor debería ser lo más aburrido y fiable que tiene. La configuración forma parte de eso, y conviene tenerla en cuenta al elegir una herramienta: entre las opciones de código abierto y autoalojadas, las que guardan su configuración en un archivo que puede versionar envejecen mejor que las que la esconden detrás de clics. También conviene comprobar quién mantiene de verdad el proveedor, porque muchas herramientas dicen admitir Terraform y lo dejan en manos de un voluntario; los proveedores de Terraform para monitoreo, comparados muestra quién publica qué. Un monitor cuya definición puede leer, revisar, comparar y revertir es un monitor más aburrido que uno montado a base de clics que nadie recuerda, y aburrido, aquí, es el mayor elogio.

Ponga la configuración en el repositorio. Deje que una segunda persona lea el diff. Su yo del futuro, entornando los ojos ante un intervalo de 47 segundos dentro de dieciocho meses, al menos podrá ejecutar git blame y descubrir que fue usted.