Agentes en una flota

La página del agente de host trata de una máquina. Esta trata de muchas, y ahí cambian las preguntas: no cómo instalarlo, sino cómo desplegarlo de forma repetible, qué conjunto de monitores por host tiene sentido, y cómo mantener la imagen limpia cuando el hardware entra y sale.

Nada de esto depende de un tipo de carga. Un armario de servidores de base de datos, un conjunto de máquinas de build y unos nodos repartidos en el borde plantean los mismos tres problemas: poner el agente, decidir qué merece un incidente y limpiar detrás de una máquina que ya no está.

El despliegue

Dos propiedades hacen que esto se pueda automatizar.

Un token de alta reutilizable. El token por defecto es de un solo uso, lo cual está bien para una máquina y mal para veinte. Al crearlo, ponlo como reutilizable y dale una vida corta. Un token que vive una hora y cubre la ventana del despliegue se filtra con menos consecuencias que uno que vive un mes, y los tokens no se pueden retirar antes de que caduquen.

Un instalador que puedes repetir. El comando de instalación se puede ejecutar tantas veces como quieras. En un host que ya está dado de alta pasa a modo actualización: renueva el binario y el servicio, conserva la identidad existente y no necesita ningún token. Eso es justo lo que lo hace utilizable desde tu gestión de configuración, donde la misma línea se ejecuta en cada host en cada pasada.

La forma más simple, una vez tienes el comando desde la aplicación:

TOKEN=psag_…
for host in $(cat hosts.txt); do
  ssh "$host" "PERSTAT_TOKEN=$TOKEN sh -c \"\$(curl -fsSL https://agent.perstat.io/install.sh)\""
done

Pasar el token por el entorno lo mantiene fuera de los argumentos ordinarios y de la lista de procesos; un comando literal puede entrar en los logs del shell o la automatización. Inyéctalo desde tu almacén de secretos y aplica la política de historial/logs de la herramienta.

El instalador siempre comprueba SHA-256 y verifica Ed25519 si hay un OpenSSL 3 compatible. Si no, avisa y recurre a TLS más SHA-256. Como instalador y clave llegan del mismo origen, la primera instalación aún confía en ese origen; la autoactualización posterior falla de forma cerrada con una clave compilada.

Qué vigilar por host

Un monitor observa un valor, así que esto es una decisión y no algo automático. Un conjunto que funciona para casi todas las flotas:

Monitor	Por host	Por qué
availability	siempre	El único monitor de agente que salta cuando un host calla. Sin él, una máquina muerta es invisible.
disk	casi siempre	Cubre todos los puntos de montaje a la vez, porque el umbral se aplica al sistema de archivos más lleno.
service	uno por proceso crítico	La comprobación que atrapa el caso de que la máquina esté viva pero aquello para lo que existe no.
cpu, mem	rara vez como caída	En máquinas pequeñas un umbral en porcentaje es ruidoso o carece de sentido, y la presión de memoria real suele aparecer como un proceso muerto, que el monitor de servicio ya atrapa.

Si quieres CPU y memoria como contexto y no para que te despierten, pon "breach_severity": "degraded". Eso genera un aviso dentro de la aplicación, ningún incidente y ninguna notificación push.

Dale a cada agente un monitor de disponibilidad. Es el que sostiene la flota. Cuando un host deja de enviar datos, los demás monitores dejan de evaluarse por completo: no abren ni cierran nada y conservan el último valor mostrado. Por eso un host muerto produce un incidente y no uno por valor, y por eso el monitor de disponibilidad es el que hay que creer cuando un host calla.

Cuántos monitores son

Multiplica: monitores por host por número de hosts. Un host con disponibilidad, disco y cuatro procesos vigilados son seis monitores, así que veinte hosts son ciento veinte.

Tres reglas deciden si eso encaja:

• El número de agentes está limitado por plan: 2 en Free, 10 en Pulse, 50 en Sentinel, 200 en Command e ilimitado en Enterprise. Fuera de Enterprise, un agente puede llevar como máximo 25 monitores.
• Los monitores archivados liberan su plaza, los pausados no. Si estás en el límite y pausas monitores para hacer sitio, así no avanzas. Hay que archivar.
• Los límites de monitores por plan están en planes y límites.

Haz la multiplicación antes del despliegue y no después. Llegar al límite a mitad de camino deja una flota vigilada a medias, y eso es peor que una sin vigilar: parece cobertura.

Nombres

Los nombres de monitor son únicos dentro de un proyecto, así que una flota necesita un esquema en lugar de improvisación. Algo que ponga el host delante y el valor detrás se lee bien en listas y ordena de forma sensata:

web-07 · disponibilidad
web-07 · disco
web-07 · nginx

Al agente se le identifica por el nombre de host que envía. Si reconstruyes máquinas con el mismo nombre de host, ten en cuenta que la máquina reconstruida se da de alta como agente nuevo y el antiguo permanece hasta que lo quites.

Encontrar los nombres de proceso correctos

service_name casa con un nombre de proceso, no con una unidad de systemd, y en una flota quieres los nombres reales y no los que supones. Dos caminos:

Ejecuta ps -eo comm= | sort -u en un host representativo.

O activa el inventario de procesos para un agente, que viene desactivado. Transmite únicamente nombres de procesos y de ejecutables, nunca líneas de comando, rutas, usuarios ni PID, y el formulario del monitor sugiere después esos nombres. Activarlo en un solo host representativo suele bastar para configurar toda la flota, y luego puedes volver a desactivarlo.

Fíjate en los servicios que arrancan como script. Aparecen como python3, sh o node y no se distinguen por el nombre, lo que pesa más en una flota porque el error se repite entonces en cada host.

Reemplazar una máquina

Dos pasos forman la misma rutina de retirada.

1. Quita el agente en la aplicación. Su token deja de valer al instante; los monitores vinculados se archivan, sus incidentes abiertos se resuelven y liberan plazas sin borrar el historial.
2. Quita el software del host con uninstall.sh, que además lo da de baja. Si la máquina ya no está, basta con el paso 1.

Cuando caen varios hosts a la vez

Un fallo correlacionado, un armario que se queda sin corriente o un segmento de red que desaparece, abre un incidente por cada monitor afectado. Tres cosas lo amortiguan.

Las notificaciones push de una organización se agrupan en un solo mensaje en lugar de una por incidente, así que un fallo correlacionado no te vacía la batería.

Silenciar deja un incidente callado para ti sin confirmarlo para el equipo, que es el gesto correcto cuando ya lo sabes y estás en ello.

Las alarmas dependientes permiten que un monitor nombre los monitores de los que depende. Mientras un origen nombrado esté demostradamente caído, el monitor dependiente retiene su cadena de avisos, así que el router caído no te despierta una vez por cada máquina que hay detrás. Ni el incidente ni la página de estado se ven afectados, solo el aviso espera. Se configura a conciencia por monitor y merece la pena en una flota con topología conocida.

Qué puedes automatizar hoy

La API REST es solo de lectura: sus claves leen exactamente 7 endpoints. Las escrituras programáticas sobre monitores pasan por MCP. La segunda mitad de un despliegue, crear y gestionar los monitores adecuados para cada host, se automatiza mediante MCP; REST aporta la parte de lectura.

Dar de alta a los agentes en sí, no. El token de alta se crea en la aplicación, y la identidad del agente nace en el host al darse de alta y no con una llamada a la API. En la práctica eso deja un gesto manual por ventana de despliegue en lugar de uno por máquina: crea un token reutilizable y deja que la gestión de configuración haga el resto.

El punto ciego que conviene conocer

Una máquina muerta y una máquina sana que no consigue alcanzarnos producen la misma señal, porque la marca de tiempo con la que trabajamos es la de la recepción. En una flota repartida entre sedes o redes, esa diferencia suele ser lo primero que quieres saber.

Si te importa, acompaña cada monitor de disponibilidad con una comprobación externa de la misma máquina, un monitor ping o tcp sobre una dirección que llegue a ella directamente. Agente en silencio y comprobación externa en verde significa que hemos perdido de vista un host que funciona. Agente en silencio y comprobación externa en rojo significa que el host ya no está.