Monitores y tipos de check

Los 13 tipos

http, http_headers, tcp, dns, dns_hygiene, domain, ssl_cert, smtp, imap, ping, traceroute, agent y heartbeat. La referencia de tipos de check explica cada uno en lenguaje llano. Las secciones de abajo cubren la configuración.

Monitores HTTP

• Assertions: código de estado esperado, una palabra clave que el cuerpo de la respuesta debe contener o una expresión regular sobre ese cuerpo.
• Subchecks incorporados: un monitor http ya trae subchecks del certificado TLS (caducidad, emisor, detección de autofirmados), de las cabeceras de seguridad y de la higiene DNS. Un solo monitor cubre lo que antes exigía cuatro.
• Redirecciones: se siguen hasta 5 saltos. Antes de pedir cada salto, Perstat comprueba que no apunte a un destino SSRF: rangos privados, link-local, endpoints de metadatos.

Comportamiento dual-stack

Un check recorre todos los registros A y AAAA y devuelve un resultado por familia de direcciones y por IP. Si un fallo que solo afecta a IPv6 cuenta como degradado o como caída, lo decides tú, monitor a monitor. El dns_ms se muestra aparte de la latencia total.

El DNS en detalle

Un monitor dns compara el conjunto de respuestas con lo que esperas y además puede contrastarlo con el de otro monitor. Si algo diverge, pasa por el mismo flujo de incidentes que todo lo demás. dns_hygiene comprueba SPF, DMARC y CAA como configuración. domain vigila NS, SOA, DNSSEC y la caducidad WHOIS.

Preguntar a un servidor de nombres concreto. Sin más indicaciones, un monitor dns pregunta al resolutor de Perstat, de modo que mide la zona en conjunto, caché incluida. Si rellenas server (un nombre como a.example-ns.net o una IP), el check pregunta directamente a ese servidor, sin caché de por medio. Así ves cuándo un servidor de nombres del grupo falla o responde de forma distinta a sus hermanos, algo que una comprobación contra la zona entera no puede mostrar. Junto con un contraste entre dos monitores de este tipo, una divergencia entre dos servidores se convierte en incidente.

Con anycast, cada región de comprobación alcanza el nodo más cercano, así que varias regiones cubren varios nodos físicos de la misma dirección. La dirección realmente alcanzada queda registrada con el resultado. Si el servidor publica NSID o id.server, ves también qué nodo respondió.

Intervalos

El intervalo se ajusta monitor a monitor, hasta el mínimo de tu plan: Free 300 s, Pulse 60 s, Sentinel 30 s, Command 15 s, Enterprise 10 s. El formulario web ofrece de 30 segundos a 1 hora. La API REST y MCP fijan cualquier intervalo entre el mínimo de tu plan y 24 horas, también 15 s en Command y 10 s en Enterprise. Las tablas completas de límites están en planes y límites.

Monitores de agente

El tipo agent engancha un monitor a un agente de host: disponibilidad con periodo de gracia, CPU, memoria y disco contra umbrales, y servicios designados por nombre con margen de gracia contra el flapping. Si faltan datos, el estado queda pendiente, nunca en falsa alarma. Un agente que calla cuenta como caído.

Monitores de heartbeat

El tipo heartbeat invierte el sentido: en lugar de que Perstat llame a tu servicio, es tu tarea la que llama a Perstat. Es el tipo adecuado para un cron, una importación por lotes, una copia de seguridad, cualquier cosa sin dirección a la que llamar.

Cada heartbeat tiene dos endpoints, y tu tarea decide a cuál llama:

https://api.perstat.io/ping/<token>        # terminó limpiamente
https://api.perstat.io/ping/<token>/fail   # se ejecutó, pero algo va mal

Ambos aceptan GET y POST, así que basta un curl en un script de shell. La URL exacta de un monitor está en su página de detalle en la aplicación y en la API, y un agente la recibe por MCP al crear el monitor. Conéctala a la tarea justo después de crear el monitor: la cobertura empieza con el primer ping.

Dos ajustes deciden cuándo salta. period_seconds es cada cuánto esperas la señal, de 30 segundos a 30 días. grace_seconds es la tolerancia por encima, para que una copia de seguridad que a veces tarda más no despierte a nadie. Dale a la tolerancia una fracción real del periodo y no un minuto simbólico.

• El silencio más allá del periodo más la tolerancia hace saltar el monitor.
• Una llamada al endpoint de fallo lo hace saltar en la siguiente evaluación, en torno a medio minuto, sin esperar a que pase el periodo.

Un heartbeat queda en desconocido hasta que llega su primer ping, porque un calendario empieza a contar cuando tu tarea lo ha confirmado.

Informar de una condición que evalúa tu tarea

Como es tu lado el que elige el endpoint, un heartbeat lleva cualquier condición que un script pueda decidir, más allá de “la tarea se ejecutó”. Un temporizador que comprueba la longitud de una cola, un número de registros o el tamaño de un directorio y luego llama al endpoint que corresponde convierte una medición local en un incidente:

if [ "$(records)" -ge 1000 ]; then
  curl -fsS -m 10 "https://api.perstat.io/ping/$TOKEN" >/dev/null
else
  curl -fsS -m 10 "https://api.perstat.io/ping/$TOKEN/fail" >/dev/null
fi

Eso expresa lo que un umbral sobre una medición del host no puede, por ejemplo un recuento que ha caído por debajo de su objetivo. Un heartbeat lleva una condición, así que dale a cada afirmación su propio monitor.

Siguientes pasos

• Quórum y regiones: cómo los resultados regionales se convierten en un estado confirmado.
• Alertas y guardias: a quién se despierta, y cómo.