Monitora prima gli endpoint rivolti ai clienti
Ogni prodotto SaaS ha endpoint con cui gli utenti interagiscono direttamente. Questi sono la tua massima priorità di monitoraggio.
Inizia con la dashboard dell’app. Se gli utenti accedono a app.tuaazienda.com, monitora quell’URL. Poi aggiungi l’endpoint di autenticazione. Se gli utenti non possono accedere, il resto del monitoraggio non ha importanza.
Aggiungi gli endpoint API principali. Se il tuo prodotto ha un’API REST che i clienti integrano, monitora gli endpoint che chiamano di più. Un endpoint /v1/health va bene, ma può restituire 200 mentre i tuoi endpoint dati reali generano errori 500. Monitora gli endpoint che i tuoi utenti raggiungono effettivamente.
Aggiungi il flusso di fatturazione e pagamenti. Se i webhook di Stripe o Paddle smettono di arrivare, o il tuo endpoint di gestione abbonamenti va giù, stai perdendo denaro. Monitora gli endpoint che toccano i ricavi.
Controlla i tuoi job in background
Il tuo server è attivo. La tua API restituisce 200. La dashboard si carica. Sembra tutto a posto. Ma il backup notturno del database sta fallendo silenziosamente da due settimane. La tua coda email è bloccata con 8.000 messaggi non consegnati. La pipeline di esportazione dati si è fermata tre giorni fa.
Questo è il gap di monitoraggio che coglie la maggior parte dei team. Il monitoraggio dell’uptime copre il percorso richiesta-risposta. Non copre le attività pianificate, i worker in background o le pipeline asincrone.
Il monitoraggio heartbeat colma questo gap. Ogni attività pianificata riceve un URL univoco. Quando l’attività viene eseguita con successo, invia un ping a quell’URL. Se il ping non arriva entro la finestra prevista, ricevi un avviso. La configurazione è un singolo comando curl alla fine dello script cron.
Monitora almeno questi job:
- Backup del database
- Code di consegna email
- Fatturazione e generazione di fatture
- Sincronizzazioni ed esportazioni dati
- Rotazione e pulizia dei log
- Automazione del rinnovo dei certificati
Scopri di più sul monitoraggio heartbeat e come rileva ciò che i controlli di uptime perdono.
Scegli l’intervallo di controllo giusto
Non tutti gli endpoint necessitano della stessa frequenza di controllo. Allinea gli intervalli con l’impatto aziendale del downtime.
Controlli ogni 30 secondi per gli endpoint critici per i ricavi: il flusso di checkout, l’API principale, il servizio di autenticazione. Se questi vanno giù, perdi denaro o blocchi gli utenti. Devi saperlo il più velocemente possibile.
Controlli ogni minuto funzionano per la maggior parte dei servizi di produzione. La dashboard dell’app, le API secondarie, gli endpoint di stato. Abbastanza veloci da rilevare problemi reali, abbastanza lenti da evitare falsi allarmi.
Controlli ogni 5 minuti vanno bene per endpoint a priorità inferiore: pagine marketing, siti di documentazione, strumenti interni. Se il sito marketing è giù per 4 minuti, l’impatto aziendale è basso.
Più veloci sono i controlli, prima lo sai. Ma controlli più veloci significano anche più dati, più rumore e potenzialmente costi più alti. Abbina l’intervallo all’impatto.
Imposta avvisi che non esauriscano il tuo team
La fatica da alert è il killer silenzioso del monitoraggio. Quando ogni piccolo inconveniente attiva una notifica, il team smette di prestare attenzione. Silenziano il canale. Ignorano le email. Poi accade un incidente reale e nessuno se ne accorge.
Usa soglie di escalation degli avvisi. Richiedi 2 o 3 fallimenti consecutivi prima che un avviso venga attivato. Questo filtra i problemi di rete transitori che si risolvono da soli in pochi secondi. Un singolo controllo fallito non è un incidente. Tre di fila lo sono.
Instrada gli avvisi per gravità. I monitor critici vanno a PagerDuty o ai telefoni di reperibilità. I monitor di livello avviso vanno a un canale Slack. I monitor informativi vanno via email o a una dashboard. Non inviare tutto nello stesso posto.
Usa ore di silenzio per la manutenzione. Se fai il deploy ogni martedì alle 2 del mattino, sopprimi gli avvisi sui monitor interessati durante quella finestra. Il team sa del deploy. Non ha bisogno di essere avvisato perché l’app si è riavviata.
Separa i canali di avviso dai canali di discussione. Il tuo canale #avvisi dovrebbe contenere solo messaggi di avviso automatizzati. La discussione umana avviene in #ops o #engineering. Questo mantiene il feed degli avvisi pulito e scansionabile.
Costruisci una pagina di stato che i tuoi utenti controlleranno davvero
La tua pagina di stato non è solo una casella da spuntare. È uno strumento di comunicazione che riduce il carico di supporto durante gli incidenti.
Mettila sul tuo dominio (stato.tuaazienda.com). Personalizzala con il tuo marchio. Collegala dal footer dell’app, dalla documentazione di supporto e dalle pagine di errore.
Quando si verifica un incidente, pubblica aggiornamenti. “Stiamo indagando su segnalazioni di errori API elevati” è meglio del silenzio. “Il problema è stato identificato come esaurimento del pool di connessioni al database. Stiamo scalando.” dice agli utenti che sai cosa c’è che non va. “Monitoraggio del ripristino. La latenza API è tornata alla normalità.” chiude il ciclo.
Una pagina di stato che si aggiorna automaticamente dai dati di monitoraggio significa che non devi azionare manualmente interruttori durante un incidente. La pagina riflette la realtà. Tu ti concentri sulla risoluzione del problema. Scopri di più sulle pagine di stato PingWatchdog.
Rivedi i tuoi incidenti
Dopo ogni incidente, dedica 10 minuti a rivedere cosa è successo. Guarda la timeline. Quanto tempo per rilevare? Quanto per rispondere? Quanto per risolvere?
Questi tre numeri sono le tue metriche fondamentali di affidabilità: tempo medio di rilevamento (MTTD), tempo medio di risposta (MTTR) e tempo medio di risoluzione (MTTResolve). Tienine traccia nel tempo. Stai diventando più veloce? Più lento?
Usa i dati degli incidenti per giustificare miglioramenti. Se il 40% dei tuoi incidenti è causato da problemi di connessione al database, è un segnale per investire nel connection pooling o nelle repliche di lettura. Se la scadenza dei certificati SSL causa incidenti ogni 90 giorni, automatizza il rinnovo dei certificati.
PingWatchdog crea automaticamente incidenti quando i monitor vanno giù e li risolve automaticamente quando i servizi si riprendono. Ottieni una timeline completa senza lavoro manuale. Scopri di più sulla gestione degli incidenti.
Stratifica il tuo monitoraggio
Un solo strumento non può coprire tutto. Usa PingWatchdog per il monitoraggio esterno: uptime, SSL, heartbeat, pagine di stato. Usa strumenti di monitoraggio delle prestazioni applicative (APM) come Datadog o Sentry per le metriche interne. Usa l’aggregazione dei log per il debugging.
La vista esterna ti dice se gli utenti possono raggiungere il tuo servizio. La vista interna ti dice perché. Entrambe contano.
Confronta gli strumenti di monitoraggio per trovare lo stack giusto per il tuo team.