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; aquí van los detalles de 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 se 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), la comprobación pregunta directamente a ese servidor, sin caché de por medio. Solo así se advierte que un servidor de nombres del grupo falla o responde de forma distinta a sus hermanos; una comprobación contra la zona nunca lo mostrará. Junto con un contraste entre dos monitores de este tipo, una divergencia entre dos servidores se convierte en incidente.

Con anycast la pregunta sigue siendo honesta, pero la respuesta es local: 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. Distinguir qué nodo respondió solo es posible si el servidor publica NSID o id.server.

Intervalos

El intervalo se ajusta monitor a monitor; hasta dónde puede bajar depende del plan: free 300 s, pulse 60 s, sentinel 30 s, command 15 s, enterprise 10 s. 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 nosotros llamemos a tu servicio, es tu tarea la que nos llama. 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. La conectas a la tarea después de crear el monitor, y conviene hacerlo enseguida: un heartbeat al que nadie llama parece cobertura sin serlo.

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. Es intencionado: un calendario que nadie ha confirmado no se puede incumplir.

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, no solo “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 cubre lo que un umbral sobre una medición del host no puede expresar, por ejemplo un recuento que ha caído por debajo de lo que debería. Un heartbeat lleva una condición, así que dale monitores distintos a afirmaciones distintas en lugar de plegarlas en un solo ping.