Check dell’host agent

Cosa verifica

Un monitor dell’host agent si lega a un agent installato su uno dei tuoi host e osserva una metrica. availability osserva se l’agent si fa ancora vivo. cpu, mem e disk confrontano l’uso in percentuale con una soglia, e service verifica che un processo indicato per nome sia in esecuzione. L’agent riporta al control plane, e il server giudica l’ultimo rapporto circa ogni 30 s. Una violazione apre un incident, con un push secondo notify_push, oppure genera solo un avviso in-app, come stabilisce breach_severity. Un agent porta più monitor, uno per metrica o processo.

Da usare quando

• Un host esegue qualcosa senza una porta da sondare, oppure la porta risponde ancora mentre l’host ha esaurito memoria o disco.
• Un processo deve restare in esecuzione: un database, un worker di coda o un reverse proxy. Un riavvio più breve della tolleranza non conta come violazione.
• Un host deve dare l’allarme quando smette del tutto di riportare, con una tolleranza tale che un reboot entro quel tempo non apra un incident.

Il check non misura nulla via rete. La raggiungibilità di una porta o di un URL da internet richiede il check ping, TCP o HTTP(S). Un job cron o un batch senza un processo da osservare richiede il check heartbeat.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Configurazione

Agent. Nessun target di rete. Il monitor si lega a un host agent della tua organizzazione tramite il suo agent_id, e il modulo elenca gli agent registrati. Il rapporto arriva dall’host, quindi il check non ha regioni, famiglie IP né un intervallo proprio.

Come si svolge un check

1. L’agent sull’host riporta al control plane. Circa ogni 30 s il server carica l’ultimo rapporto dell’agent per questo monitor. Nessuna regione di sonda partecipa, e il check non tocca mai l’host via rete.
2. availability: il server confronta l’età dell’ultimo rapporto con grace_seconds. Un rapporto più vecchio della tolleranza è una violazione.
3. cpu, mem, disk: giudicati solo finché l’ultimo rapporto ha al massimo 180 s, e un valore sopra threshold è una violazione. Senza un valore recente la passata non registra alcun risultato, invece di un falso allarme. L’host muto è compito della metrica availability.
4. service: giudicato solo con un rapporto recente e una voce recente per il processo indicato. Un processo che non è in esecuzione da più di grace_seconds è una violazione.
5. Una violazione diventa un check fallito con gravità critica oppure un check degradato, come stabilisce breach_severity. La gravità critica apre un incident con un push secondo notify_push, quella degradata genera solo un avviso in-app. Allarme e ripristino sono fissi a 1 valutazione ciascuno, quindi decide la passata successiva.

Cosa contiene un risultato

Stato e gravità

passed, degraded o failed, con gravità ok, degraded o critical. La regione è agent, il marcatore di un check lato server.

Riga di dettaglio

Una riga con il fatto giudicato. Mostra l’età dell’ultimo rapporto rispetto alla tolleranza, il valore rispetto alla soglia (CPU 95% > 90%), oppure il processo con il numero di processi e la quota di CPU.

Latenza e codice di risposta

Nulla viene misurato via rete, quindi un risultato non porta né un tempo di risposta né un codice di stato.

Stati e gravità

• okL’ultimo rapporto è entro la tolleranza, il valore è pari o inferiore alla soglia, oppure il processo è in esecuzione.
• degradatoUna violazione con breach_severity impostato su degraded. Viene registrata e mostrata come avviso in-app, senza incident e senza push.
• downUna violazione con breach_severity impostato su critical, il default. L’agent è rimasto muto oltre la tolleranza, un valore ha superato la soglia oppure il processo si è fermato per più della tolleranza. Apre un incident, con un push secondo notify_push.
• erroreCompare solo in un’esecuzione di prova. Quando la metrica non può essere giudicata, per esempio senza un rapporto recente, l’esecuzione risponde errore con una diagnosi. Nulla viene memorizzato e nessun incident si apre.
• in attesaNessun risultato ancora, subito dopo la creazione o finché l’agent non ha inviato un valore recente per la metrica. La passata non registra nulla invece di un falso allarme.

Il segnale arriva dal tuo host o dal tuo job, senza regioni né quorum, quindi conta anche un solo report mancato. Allarme e ripristino sono fissi a 1 valutazione ciascuno. La passata che vede la violazione apre l’incident, e una valutazione superata conta come ripristino.

Piani e limiti

Host agent

2 in Free, 10 in Pulse, 50 in Sentinel e 200 in Command. Le quote di Enterprise sono su misura. Un pacchetto aggiuntivo aggiunge 10 agent per 19 €.

Monitor per agent

25 in Free, Pulse, Sentinel e Command. Le quote di Enterprise sono su misura. Un monitor dell’host agent conta qui, non nella quota dei monitor di sonda.

Intervallo e regioni

Non applicabili. Il server valuta circa ogni 30 s, e i minimi di intervallo e il numero di regioni dei piani non valgono per questo tipo.

Confronta tutti i limiti

Dalla pipeline o da un agente

La stessa config funziona nello step di deploy, in un client MCP come Claude Code e nel modulo qui sopra. create_monitor richiede una chiave API valida per tutta l’organizzazione. Se ometti regions, il piano sceglie il suo default.

{
  "name": "web-01 CPU",
  "type": "agent",
  "config": {
    "agent_id": "agt_...",
    "metric": "cpu",
    "threshold": 90,
    "breach_severity": "degraded",
    "notify_push": true
  }
}

Ogni interfaccia, con il suo limite

Limiti

• L’agent riporta quattro metriche (disponibilità, CPU, memoria e disco) e lo stato di un processo indicato per nome. Altre metriche e valori personalizzati non sono disponibili.
• CPU, memoria e disco non vengono giudicati mentre l’agent è muto. Affianca a un monitor con soglia un monitor availability sullo stesso agent per intercettare l’host muto.
• grace_seconds si imposta tramite API o MCP. Il modulo mantiene il valore memorizzato quando modifichi.
• Il tipo non ha intervallo, regioni o regola di alert propri, e il modulo li nasconde tutti e tre. Il server valuta tutti i monitor agent in una sola passata circa ogni 30 s e ignora regions in una richiesta. interval_seconds viene memorizzato a una modifica e mostrato nel monitor, ma la valutazione non legge né quel valore né i 60 s impostati alla creazione.
• agent_id deve indicare un agent già registrato nella tua organizzazione. L’ID arriva dalla registrazione dell’agent, e il monitor non lo crea.

Tipi di check correlati

• Check heartbeatUn URL segreto che il tuo job chiama secondo la sua pianificazione. Il silenzio oltre periodo più tolleranza, o un fallimento riportato, lo mette in down.
• Check pingRaggiungibilità di un host via ICMP echo: risposte, perdita e round trip medio da ogni regione.
• Check della porta TCPSe una porta accetta una connessione, a scelta con il certificato servito su di essa.

Tutti i tipi di check