Monitoraggio dei tempi di risposta

Perché il tempo di risposta merita un proprio alert

Gli alert standard di uptime si basano su un segnale binario: up o down. La zona grigia nel mezzo - up, ma lento - è dove vive realmente la maggior parte dei guasti moderni. Una query di database mal configurata inizia a durare 4 secondi invece di 50ms. Una perdita di memoria provoca spike nella garbage collection. Una API esterna a cui si collega il backend inizia a vacillare. Nessuna di queste cose rompe completamente il sito, ma lo rende inutilizzabile - e sono segnali precoci di un guasto in arrivo tra un'ora o due.

Il monitoraggio del tempo di risposta rileva il rallentamento prima che diventi un crash. Configuri una soglia per ogni monitor, e quando il tempo di risposta la supera in diversi controlli consecutivi, ricevi un alert. Prima che scatti l'alert, hai ancora margine per indagare, scalare, limitare la chiamata problematica o annullare il deploy che lo ha attivato.

Come funzionano le soglie in DiagnoSEO Uptime Monitoring

Ogni monitor può essere configurato con due parametri: rt_threshold_ms e rt_threshold_breaches. Il primo è il tempo di risposta in millisecondi che consideri accettabile. Il secondo quanti controlli consecutivi devono superare questa soglia perché venga inviato un alert. Di default la soglia è disattivata e il numero di violazioni è tre.

Il design a doppio parametro protegge dai falsi positivi. Il jitter di rete accade. Le pause della garbage collection accadono. Un singolo spike a 1 secondo su una media di 200ms non vale una chiamata al pager alle 3 di notte. Ma tre risposte consecutive di 1 secondo sì - quello è un rallentamento persistente, non un lampo. Scegli la soglia in base al comportamento normale osservato più un margine ragionevole: se il p95 è normalmente 400ms, soglia 1000ms. Se il p95 è 50ms (API interna), soglia 200ms.

Con cosa si abbina bene

Gli alert sul tempo di risposta funzionano meglio in combinazione con altri segnali del monitor. Il quadro completo: la soglia di tempo di risposta segnala una degradazione; il codice HTTP indica quando c'è veramente un errore; gli avvisi SSL/dominio per i guasti guidati dall'orologio; gli alert per variazioni DNS segnalano il drift di configurazione. Quattro segnali insieme nello stesso monitor trasformano il binario "funziona o no" in una piena osservabilità.

Anche la dashboard aiuta. Ogni monitor mostra uno sparkline degli ultimi tempi di risposta - un rapido indicatore visivo di pattern di degradazione. La vista espansa mostra le medie su 24h, 7d e 30d. Se vedi la media aumentare lentamente settimana dopo settimana - è un segnale precoce da indagare prima che superi la soglia dell'alert.

Soglie pratiche per tipologia di sito

• Landing page di marketing: 1500ms è ragionevole. Sono pesanti per immagini e script di tracciamento; la velocità assoluta conta meno della stabilità.
• Pagine prodotto/categorie ecommerce: 800-1200ms. Ecommerce lento uccide la conversione; soglie più strette fanno emergere prima i problemi.
• Dashboard applicative: 500-800ms. Gli utenti si aspettano reattività. Dashboard lenti fanno sembrare il prodotto difettoso.
• API pubbliche: 200-400ms per endpoint semplici, più alto per quelli complessi. Suddividili in livelli.
• Health check dei microservizi interni: 50-100ms. Dovrebbero essere quasi istantanei; la lentezza significa quasi sempre un vero problema.

Qualunque sia la soglia scelta, non fissarla una volta sola per poi dimenticartene. Rivaluta ogni trimestre in base ai trend reali che osservi. Se continui a ricevere alert di soglia che non rappresentano veri problemi - la soglia è troppo stretta. Se ricevi un crash senza alert precedente - la soglia era troppo larga.

Instradamento degli alert

Gli alert per superamento soglia viaggiano attraverso gli stessi canali degli alert down/recovery: Email, Telegram, Slack, Discord, SMS. Rispettano lo stesso silenzio notturno. Sono loggati nella stessa tabella degli alert. L'unica differenza è il tipo di evento ("threshold" invece di "down") e il contenuto del messaggio - che riporta il tempo di risposta attuale e la soglia configurata, quindi vedi subito l'entità del superamento.

Configurazione

Modifica qualsiasi monitor. Nel form imposta "Soglia tempo di risposta (ms)" sul valore scelto. Facoltativamente regola "superamenti consecutivi" se il valore predefinito (3) non corrisponde alla tua tolleranza. Salva. Dal ciclo successivo ogni controllo confronterà il tempo di risposta con la soglia, e dopo il numero configurato di superamenti consecutivi riceverai una notifica.

Domande frequenti

• Quali metriche di tempo di risposta vengono registrate?

  Time To First Byte (TTFB) — millisecondi tra l’invio della richiesta e la ricezione del primo byte della risposta. Più il tempo totale per scaricare la risposta completa. Il TTFB è la metrica singola più utile per la salute di un server.

• Qual è un “buon” tempo di risposta?

  Dipende da localizzazione e contenuti. Per un sito statico con CDN: sotto i 100ms è ottimo, sotto i 300ms va bene. Per applicazioni dinamiche: sotto i 500ms va bene, sotto i 1000ms è accettabile, sopra i 2000ms è lento. Confronta con il tuo storico invece che con numeri assoluti.

• Posso ricevere un alert se il tempo di risposta supera la soglia?

  Sì. Ogni monitor ha una soglia di tempo di risposta opzionale. Se 3 controlli consecutivi superano la soglia, ricevi un alert “risposta lenta”. Il requisito dei 3 controlli evita falsi allarmi dovuti a una singola perdita di rete.

• Da dove viene misurato il tempo di risposta?

  Dai nostri 13 punti geografici di controllo (Europa, Nord America, Asia, Sud America, Oceania). Per monitor single-region i tempi provengono dalla regione più vicina. Nei multi-region ogni regione viene misurata indipendentemente — utile per individuare problemi CDN regionali.

• La dashboard mostra le tendenze nel tempo di risposta?

  Sì — media mobile a 30 giorni, massimo/minimo giornaliero e percentili (p50, p95). Utile per il capacity planning: se il p95 passa da 800ms a 1500ms in un mese, i tuoi server sono sotto pressione anche se l’uptime % resta al 100%.