Monitoraggio endpoint

Che cos'è un "endpoint"?

L'endpoint è qualsiasi cosa sia indirizzabile su Internet e possa essere interrogata per verificarne la disponibilità. Il caso classico è l'URL di una pagina web — ma nelle infrastrutture moderne le cose di cui ti prendi cura sono molto più varie: REST API, endpoint GraphQL, server di posta, listener di database, code di messaggi, porte di health-check dei container, pannelli admin interni, destinatari dei webhook. Il monitoraggio dell'Uptime di DiagnoSEO li tratta tutti allo stesso modo: definisci cosa significa "salute" per quell'endpoint, imposti il programma dei controlli e ricevi un avviso in caso di guasto.

Questa pagina descrive ogni tipo di endpoint che lo strumento supporta, a cosa serve ciascuno e quali segnali fornisce il monitoraggio.

Endpoint HTTP / HTTPS (siti web)

Il caso predefinito. Inserisci https://example.com e il monitor esegue una richiesta GET ad un intervallo specificato (1 minuto, 5, 10, 30 o 60 minuti a seconda del piano). Un check riuscito significa: avvenuta connessione TCP, handshake TLS completato (per HTTPS), risposta HTTP ricevuta con lo status code atteso (predefinito: 2xx o 3xx), e opzionalmente presenza (o assenza) di una parola chiave nel body della risposta. Il controllo registra il Time To First Byte, il tempo di risposta totale, la dimensione del contenuto, la catena dei redirect e l'intero set di header della risposta.

Gli endpoint HTTP sono la scelta appropriata per: siti marketing, blog, negozi e-commerce, dashboard SaaS, portali di documentazione — ovunque le persone accedono tramite browser.

Endpoint API (REST / GraphQL / JSON-RPC)

Le API hanno bisogno di qualcosa in più di "ha risposto": serve sapere "ha risposto correttamente". Configuri il monitor con metodo HTTP personalizzato (GET, POST, PUT, DELETE, PATCH), header personalizzati (token di autenticazione, content-type), body della richiesta (payload JSON per POST/PUT) e asserzioni JSON sulla risposta (data.status deve essere uguale a "ok", result.count deve essere maggiore di 0, errors[] deve essere vuoto). Un'API che restituisce HTTP 200 con un payload danneggiato è il peggior tipo di guasto — sembra in salute per un monitor ingenuo, ma fallisce per ogni client. Le asserzioni JSON permettono di rilevare questi casi.

Consulta la guida dedicata al monitoraggio delle API per dettagli di configurazione e sintassi delle asserzioni.

Endpoint di porte TCP

Per i servizi non-HTTP: SMTP (porta 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), listener di database (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), porte custom delle applicazioni. Il monitor apre una connessione TCP verso host:port e segnala successo se la connessione viene accettata entro la finestra di timeout. Senza handshake di protocollo — semplicemente "il demone sta ascoltando".

Questo è il monitor giusto per ogni servizio basato su TCP dove ti interessa la disponibilità e non hai bisogno di controllare il protocollo. Per la verifica del banner SMTP, o per check a livello di query sul database, usa il monitor heartbeat (il tuo servizio ci fa ping quando è in salute, vedi cron-job / monitoraggio heartbeat).

Endpoint ping (ICMP)

Check di disponibilità a livello 3. Il monitor invia una richiesta ICMP echo all'hostname o IP di destinazione e attende una risposta. Utile per router, switch, dispositivi IoT, tutto ciò che risponde al ping ma non esegue HTTP. Ricorda che molti provider cloud (AWS, GCP, Azure) bloccano di default l'ICMP a livello di security group anche se l'host è per il resto sano — per carichi di lavoro in cloud, preferisci check HTTP o porte TCP.

Endpoint hostname / DNS

Monitoraggio della risoluzione DNS. Lo strumento risolve periodicamente i record A, AAAA, MX, NS, TXT e CNAME del tuo dominio, fa uno snapshot dei risultati e invia un avviso se uno di essi cambia. Rileva: takeover DNS non autorizzati, errori di configurazione accidentali durante la migrazione del provider DNS, servizi esterni che aggiornano i loro endpoint senza avvisare (ad esempio il tuo CDN che cambia i blocchi IP), record MX cancellati per un typo.

Il monitoraggio DNS non serve alla disponibilità — il tuo provider DNS è quasi sicuramente più affidabile dell'origine. Serve a rilevare cambiamenti. Vedi il monitoraggio delle modifiche DNS per la descrizione completa.

Endpoint dei certificati SSL

Ogni endpoint HTTPS riceve automaticamente il monitoraggio SSL sopra il suo check di uptime. Lo strumento legge il certificato, ne analizza durata e issuer e invia un avviso 30, 14, 7, 3 e 1 giorno prima della scadenza. Vedi il monitoraggio dei certificati SSL per i dettagli.

Endpoint della scadenza del dominio

Per ogni URL monitorato, lo strumento interroga anche WHOIS una volta al giorno e tiene traccia della data di scadenza della registrazione del dominio. Gli avvisi vengono inviati agli stessi intervalli dello SSL (30/14/7/3/1 giorni). I mancati rinnovi sono catastrofici — il dominio diventa senza proprietario e qualcuno può registrarlo al termine del periodo di grazia. Vedi il monitoraggio della scadenza del dominio.

Scegliere il tipo di endpoint giusto

Se non sai quale tipo di monitor usare, inizia con HTTP/HTTPS per tutto ciò che ha un'interfaccia web, la porta TCP per il resto, e aggiungi check heartbeat per i job batch che non espongono alcuna superficie di rete. Puoi monitorare lo stesso obiettivo con più tipi — ad esempio, il controllo porta TCP su 443 rileverà "il server è attivo, ma l'handshake TLS è rotto", cosa che anche il check HTTP sullo stesso URL segnalerà, mentre il heartbeat dal tuo agente interno confermerà che la logica della tua applicazione funziona davvero.

Domande frequenti

• Che cos'è un endpoint?

  Tutto ciò che è indirizzabile su Internet: URL HTTP/HTTPS, REST API, porte TCP (SMTP, MySQL, custom), hostname da pingare, record DNS, certificati SSL e registrazioni di domini. Configura un monitor per ogni tipo di endpoint.

• Meglio usare un check HTTP o una porta TCP?

  HTTP è una buona scelta di default per qualsiasi servizio web. La porta TCP è migliore per servizi non-HTTP (database, mail server, protocolli personalizzati) dove ti interessa solo "se il demone accetta connessioni". Usa TCP per la disponibilità di basso livello, HTTP per "l'applicazione risponde correttamente".

• In cosa differiscono i monitor heartbeat (cron-job)?

  Heartbeat è invertito — invece di interrogare noi il tuo servizio, il tuo servizio pingha un URL noto. Se non riceviamo il ping nella finestra prevista, inviamo un avviso. Usato per cron job, processi batch e tutto ciò che gira su pianificazione senza alcuna superficie di rete da controllare.

• Un URL può avere più monitor?

  Sì. Puoi monitorare lo stesso obiettivo con diversi tipi di check — ad esempio, check HTTP per la disponibilità totale più check TCP sulla porta 443 che rileva problemi di handshake TLS. Ogni monitor funziona e invia avvisi in modo indipendente.

• Devo monitorare SSL e dominio separatamente?

  No — ogni endpoint HTTPS riceve automaticamente il monitoraggio SSL sopra il suo check di uptime, e ogni URL monitorato riceve il monitoraggio quotidiano della scadenza del dominio. Entrambi inclusi, senza configurazione aggiuntiva. Il monitoraggio del dominio è per dominio — più monitor sullo stesso dominio condividono i dati WHOIS.