Agentes en una flota

La página del agente de host trata de una máquina. En una flota cambian las preguntas: cómo desplegar el agente de forma repetible, qué conjunto de monitores por host tiene sentido y cómo mantener la imagen limpia cuando el hardware entra y sale.

El enfoque sirve para cualquier carga de trabajo. Un armario de servidores de base de datos, un conjunto de máquinas de build y unos nodos repartidos en el borde comparten las mismas tres tareas: 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 mantiene la exposición corta, porque un token sigue siendo válido hasta que caduca.

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 corta, 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 de la automatización, así que inyecta el token desde tu almacén de secretos y aplica la política de historial y de logs de tu herramienta. Ansible, Salt o Puppet ejecutan la misma línea tal cual, porque el instalador se puede repetir.

El instalador siempre comprueba SHA-256 y verifica Ed25519 si hay un OpenSSL 3 compatible. En los demás sistemas, avisa y verifica mediante TLS más SHA-256. Como instalador y clave llegan del mismo origen, la primera instalación confía en ese origen. Las autoactualizaciones posteriores son fail-closed con una clave compilada.

Qué vigilar por host

Un monitor observa un valor, así que eliges el conjunto por host. Un conjunto que funciona para casi todas las flotas:

Monitor	Por host	Por qué
availability	siempre	El monitor de agente que salta cuando un host calla. Hace visible una máquina muerta.
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	como contexto	En máquinas pequeñas un umbral en porcentaje suele ser ruidoso, y la presión de memoria real suele aparecer como un proceso muerto, que el monitor de servicio 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, sin incidente ni 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 pausan su evaluación: 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:

• Agentes por plan: 2 en Free, 10 en Pulse, 50 en Sentinel, 200 en Command e ilimitado en Enterprise. Fuera de Enterprise, un agente lleva hasta 25 monitores.
• Archivar libera la plaza, pausar la conserva. Para hacer sitio en el límite, archiva monitores.
• Los paquetes amplían ambas cuotas sin cambiar de plan. Los límites por plan y los paquetes están en planes y límites.

Haz la multiplicación antes del despliegue, y cada host recibe su conjunto completo desde el principio.

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 comparten nombre, lo que pesa más en una flota, donde una elección de nombres se repite 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, mientras el historial sigue las reglas de retención aplicables.
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, un segmento de red que desaparece) abre un incidente por cada monitor afectado. Tres funciones lo mantienen bajo control.

Las notificaciones push de una organización se agrupan en un solo mensaje en lugar de una por incidente, así que tu batería queda a salvo en un fallo correlacionado.

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 te despierta una vez en lugar de una vez por cada máquina que hay detrás. El incidente y la página de estado siguen como siempre, solo el aviso espera. Configúralo por monitor: merece la pena en una flota con topología conocida.

Automatiza el despliegue

La API REST crea, modifica y borra monitores con una clave de API, y lista y quita agentes. Con MCP, un agente de IA crea y gestiona esos mismos monitores. La segunda mitad de un despliegue, crear los monitores adecuados para cada host, sale así de tus scripts o de tu agente.

El alta empieza en la aplicación: allí creas el token, y cada host crea su propia identidad al darse de alta. Un despliegue de flota necesita así 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.

Distingue un host caído de una conexión perdida

En una flota repartida entre sedes o redes, la primera pregunta durante una caída suele ser si un host ha muerto o ha perdido la conexión. Desde el lado del agente, las dos cosas se parecen, porque Perstat trabaja con la hora de llegada de cada envío.

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: el host funciona y su conexión con Perstat está interrumpida. Agente en silencio y comprobación externa en rojo: el host ya no está.

Siguientes pasos

• Agente de host: qué mide el agente, en detalle.
• API: claves de API para monitores y agentes.