Cum diagnosticați problemele de hosting cu Metrics din cPanel

Cum diagnosticați problemele de hosting cu Metrics din cPanel este, de fapt, o întrebare despre metodă: uneltele sunt cinci, toate în aceeași secțiune, iar diferența o face ordinea în care le deschideți și ce căutați în fiecare. Un site lent, o eroare 500 sau o factură de trafic neașteptată au aproape întotdeauna urme în Metrics, cu ora exactă.

Articolul descrie fiecare unealtă pe scurt, apoi metoda în cinci pași și trei diagnostice reale, de la simptom la remediere. Este gândit pentru administratorii de conturi pe găzduire partajată, fără acces la server.

Cum diagnosticați problemele de hosting cu Metrics din cPanel

Uneltele, pe scurt

• Visitors: ultimele cereri, pe domeniu, într-un tabel cu adresă IP, adresă cerută, cod de răspuns, dimensiune, referer și user agent. Are filtre și căutare; este locul primei priviri.
• Errors: ultimele 300 de rânduri din jurnalul de erori, cu erorile PHP, fișierele lipsă și blocările de securitate.
• Bandwidth: traficul pe ore, zile și luni, separat pe web, e-mail, FTP.
• Raw Access: jurnalele de acces complete, descărcabile, cu arhive lunare dacă ați bifat arhivarea.
• Resource Usage (sau CPU and Concurrent Connection Usage): consumul de procesor, memorie, procese și disc față de limitele contului, cu instantanee la depășiri.
• Awstats și Webalizer: statistici agregate, utile pentru tendințe, mai puțin pentru diagnostic.

Detaliile fiecărei unelte sunt în ghidurile dedicate: jurnalele de erori și acces și monitorizarea resurselor. Aici ne ocupăm de cum le combinați.

Metoda în cinci pași

1. Fixați simptomul în timp

Notați exact ce s-a întâmplat, când și pentru cine: „pagina de coș afișează eroare 500 de la 14:20, la toți clienții” este un simptom; „site-ul merge prost” nu. Dacă aveți monitorizare externă, luați ora primului eșec de acolo. Fără oră, jurnalele sunt inutilizabile.

2. Resource Usage: e limita contului?

Deschideți Resource Usage și uitați-vă la ora simptomului. Dacă graficul arată o limită atinsă (linie roșie, coloana faults peste zero), problema este consumul, iar instantaneele vă spun cine l-a produs. Dacă nu s-a atins nicio limită, cauza este în altă parte și treceți mai departe. Acest pas separă cele două familii mari de probleme: „prea mult” și „stricat”.

3. Errors: ce a raportat serverul

Căutați rândurile din intervalul simptomului. O eroare PHP Fatal cu fișier și linie este un diagnostic gata pus. Permission denied indică fișiere cu drepturi greșite după un transfer. ModSecurity indică o regulă de securitate care blochează o cerere legitimă (des la formulare cu HTML sau la salvarea articolelor). File does not exist, în masă, indică scanări sau resurse lipsă după o actualizare.

4. Visitors sau Raw Access: cine a cerut ce

Filtrați după intervalul de timp și după codul de răspuns. Rândurile cu 500 arată adresele care pică; rândurile cu 404 în masă arată scanări sau legături rupte; rândurile cu același IP la interval de o secundă arată un robot. Pentru intervale mai vechi de o zi sau pentru statistici (cele mai active adrese IP, cele mai cerute pagini), descărcați jurnalul din Raw Access și folosiți comenzile de numărare din ghidul jurnalelor.

5. Bandwidth: consumul se potrivește cu vizitele?

Un salt de trafic fără salt de vizitatori înseamnă descărcări repetate ale unor fișiere mari sau imagini încărcate de pe alte site-uri; soluția este în ghidul despre protecția anti-leech. Un salt de trafic pe e-mail înseamnă, de obicei, un cont care trimite spam; parola contului respectiv se schimbă imediat.

Trei diagnostice reale

Site lent între 9 și 11, în fiecare zi de lucru

Pasul 2: Resource Usage arăta Entry Processes la limită în acel interval, în fiecare zi. Instantaneele conțineau 15-18 procese PHP pentru adrese de tip /produse/?filtru=…, toate de la adrese IP dintr-un centru de date, cu user agent de browser. Pasul 4: în Raw Access, aceleași adrese cereau 30.000 de pagini pe zi. Diagnostic: un robot de colectare de prețuri parcurgea toate combinațiile de filtre. Remediere: blocarea blocului de adrese din IP Deny Manager, apoi reguli în robots.txt și noindex pe paginile de filtre. Consumul a scăzut la un sfert în aceeași zi.

Eroare 500 la salvarea articolelor, doar pentru un editor

Pasul 2: nicio limită atinsă. Pasul 3: Errors arăta ModSecurity: Access denied with code 403, cu un id de regulă, la fiecare încercare de salvare a editorului respectiv. Pasul 4: cererile POST spre pagina de editare primeau 403, apoi aplicația afișa 500 fiindcă nu știa ce să facă cu răspunsul. Diagnostic: articolul conținea un fragment de cod pe care regula îl considera injecție SQL. Remediere: dezactivarea acelei reguli pentru domeniu, din unealta ModSecurity, așa cum arătăm în ghidul despre ModSecurity din cPanel, fără să oprim restul regulilor.

Trafic dublu față de luna trecută, vizite la fel

Pasul 5: Bandwidth arăta creșterea doar pe web, uniform, fără vârfuri. Pasul 4: în jurnalul de acces, un singur fișier PDF de 40 MB, un catalog, apărea de 2.000 de ori pe zi, cerut de adrese diverse, cu referer de pe un forum. Diagnostic: catalogul fusese legat direct de pe alt site. Remediere: mutarea fișierului într-o pagină proprie cu legătură, protecția anti-hotlink pentru extensia PDF și o redirecționare a vechii adrese spre pagină. Traficul a revenit la normal, iar pagina a adus vizitatori în loc de descărcări anonime.

Ce nu vedeți în Metrics

Metrics arată contul dumneavoastră, nu serverul. Când un server partajat are probleme (disc plin, bază de date căzută, atac asupra altui cont), simptomele apar la dumneavoastră fără nicio urmă în jurnalele contului: pagini lente fără consum, erori 503 fără erori PHP. Semnul este lipsa oricărei explicații după cei cinci pași. În acest caz, scrieți furnizorului cu ora exactă și cu ce ați verificat deja; un tichet care spune „Resource Usage fără depășiri, Errors fără rânduri la 14:20, dar toate cererile din Visitors au 503 timp de 12 minute” primește răspuns despre server, nu o cerere de a goli cache-ul.

Al doilea lucru pe care nu îl vedeți sunt cererile oprite înainte de server: de un serviciu precum Cloudflare, de un firewall de rețea sau de un blocaj DNS. Dacă vizitatorii raportează erori pe care nu le găsiți în niciun jurnal, verificați stratul din față, așa cum explicăm în articolul despre Cloudflare și cPanel.

Cum citiți un instantaneu de consum

Instantaneul este cea mai densă sursă din Metrics și cea mai puțin folosită. Are trei tabele. Procesele: fiecare rând cu utilizatorul, procentul de procesor, memoria și comanda, unde comanda unui proces PHP arată scriptul, deci adresa cerută. Interogările MySQL: cele aflate în execuție la momentul instantaneului, cu durata; o interogare de 20 de secunde pe o tabelă de jurnal este un diagnostic în sine. Cererile HTTP: adresele deschise în acel moment, cu adresele IP ale clienților. Citirea începe cu tabelul de cereri (cine), continuă cu procesele (ce rulează) și se încheie cu interogările (de ce durează). Dacă aceleași două-trei adrese apar în toate instantaneele de peste zi, aveți cauza.

Când simptomul e „uneori”

Problemele intermitente sunt cele mai greu de prins, fiindcă la momentul verificării totul merge. Metoda: nu căutați cauza, căutați tiparul. Descărcați jurnalul de acces pentru o săptămână întreagă din Raw Access, numărați cererile pe ore și pe coduri de răspuns, și comparați zilele. O creștere de 503 în fiecare zi la 3:10 este o copie de siguranță sau un cron; una în fiecare duminică seara este o reindexare programată; una fără nicio regularitate, dar mereu însoțită de un vârf de cereri de la adrese noi, este un robot care schimbă adresele. Odată găsit tiparul, cauza se confirmă cu Errors și cu Resource Usage la ora respectivă, exact ca la pașii 2 și 3.

Obiceiuri care fac diagnosticul rapid

1. Arhivarea jurnalelor din Raw Access, bifată o dată, pentru totdeauna.
2. O adresă de e-mail activă în Contact Information, ca avertismentele de resurse și de spațiu să ajungă la cineva.
3. Un serviciu de monitorizare externă, care verifică o pagină la câteva minute și vă dă ora primului eșec.
4. O notă cu fiecare schimbare făcută pe site (actualizări, module noi, schimbări de PHP), cu data; jumătate dintre probleme încep la o schimbare.
5. O privire de cinci minute pe Errors și pe Resource Usage în fiecare luni.

Pentru cazurile în care diagnosticul arată o eroare a aplicației, lista cu remedii este în ghidul erorilor din cPanel; pentru cele în care arată un consum firesc, dar prea mare pentru plan, comparația dintre optimizare și upgrade este în ghidul despre monitorizarea resurselor. Iar dacă totul e curat în Metrics, dar site-ul e lent pentru vizitatori, problema este în pagină, nu pe server, și o măsurați cu PageSpeed Insights.

Surse

• Documentația cPanel, Metrics: descrierea uneltelor Visitors, Errors, Bandwidth, Raw Access și Resource Usage.
• Documentația cPanel: interfața și secțiunile panoului.