Septiembre de 2026

El provider Terraform de Pathly, en la práctica

APITras la escena

Está publicado en el registro. Estos son los ficheros que se escriben de verdad: el más pequeño que sirva de algo, un parque entero descrito como dato, y la recuperación de una vigilancia creada a mano.

Instalar

El provider se llama pathlyhq/pathly en el registro público. No hay nada que compilar ni que depositar en un espejo: basta con declarar la versión, y el comando de inicialización lo descarga. La restricción ~> 0.1 acepta correcciones y rechaza una eventual 0.2, que es el ajuste correcto mientras el esquema no esté congelado por un 1.0.

terraform {
  required_version = ">= 1.6"
  required_providers {
    pathly = {
      source  = "pathlyhq/pathly"
      version = "~> 0.1"
    }
  }
}

# Aucun argument : la clé vient de PATHLY_API_TOKEN.
provider "pathly" {}

El bloque provider está vacío, y no es un descuido. La clave se lee de la variable de entorno PATHLY_API_TOKEN. Pasada por una variable de Terraform, acabaría en claro en el fichero de estado, que siempre se olvida cifrar hasta después de haberlo subido a algún sitio. El provider además se niega a hablar http con algo que no sea localhost: la clave viaja en una cabecera de autorización y sería legible por todos los intermediarios.

El fichero más pequeño que sirva de algo

Un escenario, una dirección, un intervalo y un texto que se espera encontrar en la página. Ese último punto marca la diferencia entre vigilar un servidor y vigilar un sitio: una página de error de la aplicación responde perfectamente con HTTP 200, y solo el texto esperado la delata.

resource "pathly_scenario" "site" {
  name         = "Home page"
  url          = "https://shop.example.com"
  interval_sec = 300
  expect_text  = "Our products"
  tags         = ["prod"]
}

Un parque descrito como dato

A partir de tres o cuatro recorridos, un bloque por recurso se convierte en una lista que se relee en cada añadido. Describirlos en una variable y recorrerla cambia la naturaleza del fichero: añadir un recorrido pasa a ser una línea de datos, y las reglas de umbral, carpeta y etiqueta siguen siendo las mismas para todos sin pensarlo.

resource "pathly_scenario" "journey" {
  for_each = var.journeys

  name         = each.value.name
  url          = each.value.url
  interval_sec = each.value.interval_sec
  expect_text  = each.value.expect_text

  # Un seuil de latence par parcours : le paiement tolère
  # moins qu'une page d'accueil servie depuis le cache.
  max_latency_ms  = each.value.max_latency_ms
  expected_status = 200
  severity        = each.value.severity
  tags            = concat(["terraform", var.environment], each.value.tags)
}

# Un objectif de disponibilité par parcours critique, qui
# alerte à 80 % du budget d'erreur dépensé : au-delà, il
# reste trop peu de marge pour le reste du mois.
resource "pathly_sla_target" "objective" {
  for_each = {
    for key, j in var.journeys : key => j if j.severity == "critical"
  }

  scenario_id          = pathly_scenario.journey[each.key].id
  objective_pct        = 99.9
  window_days          = 30
  exclude_maintenance  = true
  warn_at_budget_ratio = 0.8
}

El objetivo de disponibilidad excluye las ventanas de mantenimiento, lo que solo tiene sentido si esas ventanas también existen en el código. Un mantenimiento declarado por un lado y un objetivo que lo ignora por otro producen un presupuesto de error gastado por un corte anunciado, es decir, una alerta que castiga una operación planificada.

# Sauvegarde hebdomadaire : les échecs dans cette fenêtre
# ne dépensent pas le budget d'erreur.
resource "pathly_maintenance_window" "backup" {
  weekday      = 7 # dimanche
  start_minute = 3 * 60
  duration_min = 120
  reason       = "Weekly backup"
}

Detectar lo creado a mano

Es el uso más útil de la fuente de datos, y en el que menos se piensa. Relee el inventario tal como lo ve la API. Comparado con lo que declara el código, la diferencia nombra los escenarios creados en la consola y ausentes de los ficheros: los que nadie revisa, y que nadie eliminará al desmantelar un entorno.

data "pathly_scenarios" "prod" {
  filter_tag = var.environment
  depends_on = [pathly_scenario.journey]
}

output "scenarios_outside_terraform" {
  value = [
    for s in data.pathly_scenarios.prod.scenarios : s.name
    if !contains([for j in pathly_scenario.journey : j.id], s.id)
  ]
}

El mismo razonamiento vale para los valores que la API nunca devuelve. El destino de un webhook se escribe y no se relee: en su lugar, una huella de doce caracteres, que cambia en cuanto cambia la dirección. No permite reconstruir el destino, y basta para ver en un plan que fue modificado en otro sitio.

output "webhook_fingerprint" {
  value = pathly_webhook.alerts.url_fingerprint
}

Recuperar una vigilancia existente

Nadie rehace su parque para pasar al código, y el provider no lo pide. Cada recurso se importa por su identificador, el que lleva la dirección del escenario en la consola. Tras la importación, el plan muestra la diferencia entre lo existente y lo que describe el fichero: mientras no esté vacío, aplicar modificará el escenario en su sitio en lugar de crear un segundo.

terraform import pathly_scenario.checkout mon_01H8ZK…

El criterio que decide si todo esto es utilizable cabe en una frase: tras una aplicación, el siguiente plan debe estar vacío. Un provider que propone un cambio en cada pasada enseña muy rápido a sus usuarios a dejar de leer sus planes, y el día en que el plan dice algo cierto, nadie lo ve. Es el trabajo menos visible del provider, y en el que más insisten sus pruebas.

Lo que el provider nunca hará

Emitir o revocar una clave de API: una clave capaz de eso anula los alcances de todas las demás, y un fichero de configuración no debe poder ampliarse a sí mismo.
Invitar a un miembro: la misma escalada por un rodeo, ya que la cuenta creada emitirá luego las claves que quiera.
Cambiar de plan o tocar la facturación: un pipeline de integración continua no debe poder comprometer un gasto recurrente.

Esas ausencias no son funcionalidades atrasadas. Un provider que lo cubre todo acaba exigiendo una clave que puede todo, y esa clave queda luego en las variables de un pipeline que leen más personas de las que se cree. Lo que falta aquí falta a propósito, y se hace en la interfaz, por un humano identificado.