Quando un sito WordPress smette di funzionare un venerdì pomeriggio, inizia una corsa contro il tempo su due fronti: sistemare il sito e capire chi è stato a romperlo.
Il secondo problema richiede quasi sempre più tempo. Uno sviluppatore punta il dito contro la campagna appena lanciata. Il marketer punta il dito contro il server. L’agenzia riceve chiamate da entrambi e non ha dati propri su cui basarsi. Quando finalmente tutti si mettono d’accordo su dove cercare, l’interruzione ha già causato una perdita economica concreta, e lo stesso vale per la discussione.
Il problema di fondo non è che i team non siano d’accordo. È che ogni team lavora su una porzione diversa dei dati. Lo sviluppatore vede il codice. Il marketer vede il traffico. L’agenzia vede la coda dei ticket di assistenza. Nessuno vede la stessa cosa nello stesso momento, quindi nessuno può escludere nulla.
L’approccio di Kinsta è quello di mettere tutti i team sullo stesso piano diagnostico. I dati che i tecnici del supporto di Kinsta usano per indagare su un problema, come i codici di risposta, le prestazioni PHP, i rapporti di cache e i log delle richieste, sono gli stessi dati disponibili per ogni utente di MyKinsta con accesso alle statistiche. Quando tutti vedono gli stessi segnali, un sito malfunzionante diventa qualcosa che il team diagnostica insieme, invece che oggetto di discussione.
Questo cambia anche il modo in cui i team interagiscono con l’assistenza. Questa guida illustra gli strumenti diagnostici disponibili in MyKinsta, cosa mostra ciascuno di essi, quando usarli e come utilizzarli come parte di un flusso di lavoro condiviso anziché in una sessione di debug individuale.
Perché i problemi di prestazioni diventano problemi di responsabilità
In un sito WordPress moderno, raramente la responsabilità di tutto ricade su una sola persona. Gli sviluppatori gestiscono il codice. I marketer gestiscono le campagne. Le agenzie o i freelance si occupano dell’hosting. Ogni team fa il proprio lavoro; il problema è che la visibilità che ha ciascuno di loro non combacia.
Quando un sito smette di funzionare, quella lacuna nella visibilità trasforma silenziosamente un problema tecnico in un problema personale:
- Gli sviluppatori controllano il codice ma non il server. La loro visione si ferma al livello dell’applicazione, quindi una causa legata al server rimane invisibile ai loro occhi.
- I marketer vedono il traffico ma non il database. Un picco di traffico dovuto a una campagna sembra la causa più ovvia perché è l’unica variabile che possono misurare.
- Le agenzie gestiscono i reclami ma non dispongono di alcun dato. Diventano un tramite tra le parti piuttosto che una fonte di risposte.
Senza un punto di riferimento condiviso, ogni parte presume che la causa sia da attribuire a qualcun altro. Molte piattaforme di hosting rafforzano silenziosamente questo schema, tenendo i dati diagnostici all’interno del team di assistenza. Apri un ticket e aspetti mentre qualcun altro legge i log a cui tu non hai accesso.
Kinsta adotta l’approccio opposto. Vediamo ora quali strumenti utilizzare per primi e come usarli come flusso di lavoro condiviso, non individuale.
Cosa mostra la dashboard delle statistiche di MyKinsta quando qualcosa va storto
Quando un sito non funziona come dovrebbe, la prima cosa da fare è capire con che tipo di problema hai a che fare. Siti lenti, non funzionanti o sovraccarichi richiedono ciascuno una risposta diversa. Sbagliare la diagnosi, come trattare un problema di cache come se fosse un problema del server, o un picco di errori come se fosse un problema di traffico, fa perdere tempo a tutti.
La sezione Statistiche di MyKinsta è il punto di partenza per questa diagnosi.
Nella sezione Statistiche di MyKinsta trovi i dati a livello aziendale. Per un singolo sito, vai su Siti > nome del sito > Statistiche. In ogni caso, gli stessi report sono disponibili per tutti gli utenti con accesso alle statistiche.
Verificare se il sito sta davvero restituendo errori
Prima di tutto, verifica se il sito è davvero in errore o semplicemente lento. Queste situazioni hanno cause e soluzioni diverse, e confonderle è proprio ciò che dà inizio alle discussioni sulle responsabilità.
La scheda Risposta risponde a questa domanda. Il grafico centrale, la ripartizione dei codici di risposta, mostra la distribuzione dei codici di stato HTTP restituiti dal tuo sito nel periodo di tempo selezionato.
Pertanto, un picco di codici 5xx indica un problema a livello di server o dell’applicazione, mentre i codici 4xx indicano problemi di accesso alle risorse. Altri due grafici ti permettono di approfondire ulteriormente:
- La suddivisione degli errori 500 distingue un errore 500 generico da un errore 502 (Bad Gateway ) o da un errore 503 (Servizio non disponibile), che indicano cause diverse.
- La suddivisione degli errori 400 suddivide i codici lato client, distinguendo una valanga di 404 dalle altre risposte che segnalano problemi di autenticazione, autorizzazione o limitazione della frequenza.
Dato che tutti gli utenti con accesso alle statistiche vedono la stessa ripartizione, puoi iniziare a lavorare sul problema specifico invece di perdere tempo e tirare a indovinare.
Distinguere un sito lento da uno che non funziona
Un sito che si carica in sei secondi e uno che restituisce errori 500 sembreranno simili a un visitatore frustrato, ma hanno cause completamente diverse. La scheda Prestazioni è dove puoi distinguerli.
Ci sono diversi report qui che vale la pena controllare quando indaghi su un sito lento:
- Il tempo medio di risposta PHP-MySQL mostra quanto tempo impiega l’applicazione a elaborare e interrogare ogni richiesta non memorizzata nella cache. Un picco improvviso è solitamente il primo segnale di un calo delle prestazioni, piuttosto che di un problema di infrastruttura.
- Il throughput PHP mostra quante richieste sono state eseguite nel periodo. Se un rallentamento coincide con un picco di throughput piuttosto che con una modifica al codice, la causa probabile è il carico, non un bug.
- L’utilizzo di AJAX evidenzia picchi nell’attività di admin-ajax.php, un fattore comune e facilmente trascurabile che consuma risorse del back-end, causato da plugin e utenti connessi che eseguono attività in background.
- La sezione Principali tempi massimi di upstream elenca i singoli percorsi più lenti, così puoi individuare direttamente la pagina o l’endpoint che sta facendo salire la media del sito, invece di tirare a indovinare.
Tutte queste informazioni ti aiutano a capire se la mossa successiva è ottimizzare l’applicazione o segnalare un’interruzione del servizio.
Controlla quanta parte del sito viene memorizzata nella cache
Un sito può sembrare lento per motivi che non hanno nulla a che vedere con il codice o l’infrastruttura: semplicemente, troppo poco viene servito dalla cache. Quando la percentuale di cache cala, il server elabora richieste che non dovrebbe elaborare, aumentando così i tempi di risposta. Questa è una delle cause più comuni del dilemma “è colpa dell’host?”, ma quasi mai è colpa dell’host.
La sezione Cache mostra come vengono gestite le richieste attraverso i livelli di cache di Kinsta.
Ogni richiesta si risolve in uno dei tre stati seguenti:
HITsignifica che Kinsta serve la richiesta dalla cache, che è proprio quello che vuoi per la maggior parte del traffico.BYPASSsignifica che una regola o un conflitto impedisce alla richiesta di essere memorizzata nella cache.MISSsignifica che il contenuto non è ancora memorizzato nella cache, ma lo sarà dopo la prima richiesta.
Il grafico della cache di un sito in buona salute è dominato dagli HIT. Quando il tasso di BYPASS sale, il report Principali bypass della cache del server indica i percorsi specifici che saltano la cache.
Alcuni bypass non sono un problema (come la pagina di login di WordPress, che non viene mai memorizzata nella cache). Tuttavia, se in quell’elenco compare una pagina memorizzabile nella cache, significa che c’è un conflitto tra plugin o un problema con le regole di cache. Leggere questi report mentre controlli una pagina lenta permette di capire se la pagina è memorizzata nella cache, invece di dare per scontato che il problema sia l’host.
Individuare cosa sta consumando risorse
Se un sito non restituisce errori ma consuma più larghezza di banda o capacità di quanto dovrebbe, puoi individuarne la causa nel rapporto Richieste principali. I problemi relativi alle risorse sono i più difficili da individuare: un superamento della larghezza di banda o un rallentamento sotto carico in genere non generano alcun codice di errore.
Tre report trasformano queste supposizioni in nomi concreti:
- Larghezza di banda del server mostra quali URL prelevano più dati direttamente dal tuo server di origine.
- Larghezza di banda totale aggiunge i dati forniti dal CDN e dalla cache periferica, così puoi vedere il peso complessivo di ogni richiesta.
- Visualizzazioni mostra le risorse più richieste indipendentemente dalle dimensioni, mettendo in evidenza un endpoint sottoposto a carico costante piuttosto che un singolo file pesante.
Insieme, rivelano se un picco di risorse è dovuto a un file multimediale troppo grande, a un endpoint fuori controllo o a un crawler che visita lo stesso percorso migliaia di volte. A quel punto, la soluzione in genere consiste nell’ottimizzare la risorsa, instradarla tramite un CDN o intervenire sull’endpoint.
Se il picco è causato dal traffico di crawler o bot, la Protezione bot di Kinsta permette di identificare, classificare e bloccare il traffico non umano direttamente da MyKinsta, senza dover usare un plugin o aprire un ticket di assistenza.
Come l’APM rintraccia la causa di un problema di prestazioni
I report della Sezione Statistiche ti dicono cosa sta succedendo su un sito. Lo strumento APM di Kinsta ti spiega perché. Mentre le Statistiche ti mostrano che il tempo di risposta PHP ha avuto un picco alle 14:00, l’APM ti indica quale funzione di un plugin, quale query del database o quale chiamata API esterna l’ha causato.
L’APM è incluso in ogni piano Kinsta e funziona all’interno di MyKinsta.
Esegui l’APM come sessione, non in modo costante
A differenza della dashboard delle Statistiche, che registra continuamente in background, l’agente APM appesantisce la CPU e la memoria del tuo server mentre raccoglie i dati. Kinsta consiglia di eseguirlo solo mentre stai diagnosticando attivamente un problema.
Per avviare una sessione, vai su Siti > nome del sito > APM, clicca su Abilita APM, quindi seleziona una finestra di monitoraggio: 2, 4, 12 o 24 ore. APM si disattiva automaticamente al termine della finestra.
Questo significa che il flusso di lavoro è semplice:
- Avvia l’APM quando sospetti un problema o riesci a riprodurlo, così da evitare un sovraccarico sul tuo sito durante il normale funzionamento.
- Scegli un intervallo che copra il problema, poi riproduci il problema o aspetta che si ripresenti, così lo strumento lo rileva con i dati in tempo reale.
- Leggi i risultati una volta che i dati si sono accumulati, poi disattiva l’APM quando hai finito.
Come leggere i risultati di APM
APM organizza i dati raccolti in quattro schede: Transazioni, WordPress, Database ed Esterne.
Inizia dalla scheda Transazioni per individuare le richieste più lente. Cliccando su una transazione qualsiasi si apre una cronologia di tutti i processi coinvolti in quella richiesta e vengono evidenziati gli span più pesanti. Questo ti permette di capire se concentrare gli sforzi di ottimizzazione su una query del database lenta, su una funzione specifica di un plugin o su un’API di terze parti.
La scheda Esterne è particolarmente utile per escludere l’host. Se il rallentamento di una transazione deriva da una chiamata API esterna, i dati APM lo mostrano chiaramente. È questa la differenza tra un ticket di assistenza che dice “il sito è lento” e uno che dice “il rallentamento è nell’API del nostro provider di posta elettronica, non nel server”.
Come il visualizzatore di log e il registro delle attività ricostruiscono una cronologia
Risolvere un incidente di solito dipende dal sapere cosa è successo e in che ordine. Due registrazioni in MyKinsta aiutano a ricostruire la cronologia: il visualizzatore di log cattura ciò che fa il sito e il log delle attività cattura ciò che fanno gli utenti.
Il visualizzatore di log mostra cosa riporta il sito, non come funziona. Nella schermata Log di qualsiasi sito su MyKinsta sono disponibili tre file:
error.logregistra errori e avvisi PHP: è il primo posto dove cercare la causa di una pagina che non funziona.kinsta-cache-perf.logregistra le prestazioni della cache e mostra se le pagine vengono servite dalla cache o la bypassano.access.logregistra ogni richiesta HTTP che arriva al sito: è qui che puoi tracciare i modelli di traffico e gli errori 404 ricorrenti.
Il visualizzatore integrato carica fino a 20.000 righe e include un campo di ricerca per filtrare in base a qualsiasi stringa di testo. I log possono anche essere scaricati tramite il File Manager all’interno di MyKinsta se hai bisogno di lavorarci con uno strumento esterno.
Il log delle attività: cosa hanno fatto gli utenti
Il log delle attività registra ogni azione compiuta in MyKinsta su un sito da qualsiasi utente, in ordine cronologico.
Trovi i log delle attività in Siti > nome del sito > Attività utente. Ogni voce ti permette di vedere l’azione descritta in parole semplici, l’utente, la data e l’ora e un’icona di stato. Qui, un segno di spunta verde indica che l’operazione è andata a buon fine, mentre un punto esclamativo rosso segnala un errore.
Ti aiuta a diagnosticare i problemi se abbinato ad altri log. Ad esempio, con un file error.log compilato puoi aprire il registro delle attività, restringere la ricerca alla stessa finestra e individuare eventuali azioni correlate.
Come il monitoraggio dell’uptime crea consapevolezza condivisa
Gli strumenti sopra citati sono reattivi. Il monitoraggio dell’uptime rende il rilevamento proattivo: invece di venire a conoscenza di un problema tramite un reclamo del cliente, tu e Kinsta ne venite a conoscenza contemporaneamente.
Kinsta monitora ogni sito sulla piattaforma circa 480 volte al giorno. Se hai attivato le notifiche di monitoraggio in Impostazioni utente > Notifiche, riceverai un’e-mail in base alle aree che richiedono particolare attenzione:
- Gli Errori del sito segnalano un problema rilevato sul sito stesso.
- Gli Errori SSL segnalano un problema di certificato o di configurazione prima che allontani i visitatori.
- La Scadenza del dominio segnala un dominio in scadenza prima che scada.
Le email vengono inviate solo dopo tre controlli falliti consecutivi, anziché al primo, in modo da filtrare i picchi momentanei che altrimenti ti sommergerebbero di falsi allarmi.
SIX15 Solutions gestisce più di 30 siti di clienti con questo sistema di monitoraggio, dove il valore non sta tanto nel controllo in sé, quanto nella frequenza con cui i problemi vengono risolti prima che il cliente se ne accorga.
Al momento sto ospitando oltre 30 siti web di clienti con il mio piano Agency, da piccoli siti di marketing a veri e propri siti con iscrizione che contano migliaia di utenti, senza alcun problema né tempi di inattività.
Tuttavia, non tutti gli avvisi indicano un malfunzionamento. Gli avvisi sui limiti del piano ti avvisano quando stai raggiungendo i limiti di utilizzo del tuo piano, il che costituisce un efficace sistema di allerta precoce. Questo ti permette di capire, attraverso i tuoi dati analitici, perché stai raggiungendo un limite, ad esempio perché una campagna sta generando più traffico del previsto o a causa dell’attività di crawler o bot.
I dati condivisi mettono fine alle discussioni sulle responsabilità
Un sito non funzionante ti fa perdere più tempo a capire chi è responsabile e chi deve rispondere, piuttosto che a risolvere il problema. La sezione Statistiche di MyKinsta mostra se un sito è lento, non funzionante o sovraccarico. Grazie allo strumento APM, al visualizzatore di log, al registro delle attività, al monitoraggio dell’uptime e altro ancora, puoi assicurarti che tutti vengano a conoscenza di un problema e si mettano al lavoro senza rimanere bloccati in una coda di ticket.
L’obiettivo è considerare queste visualizzazioni come un flusso di lavoro condiviso. Con ogni membro del team che ha il giusto accesso alle analisi, potreste concordare su quali report utilizzare prima ancora che qualcuno apra un ticket. In questo modo, la conversazione rimane una diagnosi invece di trasformarsi in una discussione.
Se gestisci siti in cui più team condividono le responsabilità, l’ hosting WordPress gestito di Kinsta offre a ciascuno di questi team un posto al tavolo della diagnostica. Se gestisci siti di clienti su larga scala, vale la pena dare un’occhiata al Programma per Agenzie Partner per gli strumenti di accesso condiviso e co-gestione che offre.
