Error logovi - korisni kada se prate, problematični ako se zanemare - ContraTeam

kako ugasiti error logove

Error logovi – korisni kada se prate, problematični ako se zanemare

Objavljeno: januar 10, 2019 10:56 am U kategoriji:

Tokom pisanja koda svaki programer greši iznova i iznova, sve dok kod ne postane funkcionalan, a potom ga brusi poput dijamanta, dok ne postane validan, čitljiv, lepo formatiran…

 

U ovom procesu programerima mnogo pomažu logovi u koje se zapisuju greške do kojih tokom razvoja koda dolazi.

 

1xx – Informacioni odgovori

Status kodovi grupe 1xx (100, 101, 102, 103) ukazuju na to da je zahtev prihvaćen i da je potrebno da klijentska strana sačeka finalni odgovor.

 

2xx – Uspešnosti zahteva

Statusni kodovi grupe 2xx (200, 201, 202, 203…) služe da ukažu na to da je zahtev koji je server primio prihvaćen i da ga je server “razumeo”.

 

3xx – Kodovi redirekcije

Statusni kodovi grupe 3xx (300, 301, 302, 303… ) načelno ukazuju na to da klijentska strana mora da izvrši dodatnu akciju da bi se zahtev uspešno izvršio. Najveći deo statusnih kodova ove grupe koristi se za URL redirekciju.

 

4xx – Greške na klijentskoj strani

Statusni kodovi grupe 4xx (400, 401, 402, 403, 404…) ukazuju na to da je došlo do greške na klijentskoj strani. Najčešće da je zahtev koji je upućen pogrešan (400 – Bad request), neuautorizovan (401 – Unauthorized), da stranica nije pronađena (404 – Page not found) i drugi.

 

5xx – Greške na serverskoj strani

Statusni kodovi grupe 5xx (500, 501, 502, 503…) ukazuju na to da je došlo do greške na serverskoj strani usled nedostupnosti servera, preduge obrade poslatog zahteva ili sličnih situacija.

 

Više o HTTP statusnim kodovima možete pročitati na sledećem linku:
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

 

Sada kada znamo koje grupe statusnih kodova postoje, osvrnimo se na one koje server loguje svaki put kada se dese, ukoliko mu nije drugačije rečeno.

 

Dakle, server kao udaljeni računar koji ima osnovnu namenu da opsluži pristigle zahteve zadužen je za logovanje grešaka iz grupe 5xx, odnosno grešaka do kojih je došlo na serverskoj strani.

 

Kao što smo naveli, logovanje grešaka je tokom razvoja koda veoma korisno, ali ako se ono nastavi i kada je razvoj koda prestao (ili ako se zanemaruje), često ume da postane problematično.

 

Komercijalna CMS rešenja kao i frejmvorci imaju predviđena mesta na koja loguju greške, a to su najčešće neki fajlovi smešteni u direktorijumima koji se zovu “logs” “errors” i sl.

 

Osim njih, serveri su najčešće podešeni da sve serverske greške (pa i upozorenja) beleže unutar error_log fajla. Dešava se da na sajtu/aplikaciji postoji nekakav problem koji generiše nove linije u error_logu, a da sve funkcioniše normalno. Takođe, najčešće će se u error_logu pojaviti novi zapis i onda kada se sajt ne učita, odnosno, kada se učita bela (prazna) stranica.

 

Kada zanemarivanje error_log fajla postaje problematično?

Najčešći scenario uglavnom je taj da korisnik hosting usluge nije ujedno i programer, već je angažovao firmu da mu napravi web sajt/servis koji nakon izrade prestane da se održava pa:

  • korišćeni plugini/dodaci zastare ili postanu kompromitovani,
  • korišćena platforma, jezici ili frejmvorci zastare ili postanu kompromitovani,
  • softver i verzije jezika na serveru se ažuriraju pa prestanu da podržavaju određene funkcije i dr.

 

…a sve ove stvari server zabeleži u error_log, i to prilikom svake posete.

… i error_log raste…

… i raste…

 

Kako rešiti beskrajno generisanje error_log fajla?

Svakako, najbolja opcija je da se urade ažuriranja platforme, frejmvorka, jezika i plugina koji su korišćeni i na taj način, osim što će se zaustaviti ova neželjena aktivnost, imaće pozitivnog odraza i na bezbednost sajta/servisa. Ipak, postoji i nekoliko načina da se stvari koliko-toliko dovedu u normalu.

 

Automatsko brisanje error_log fajla

Ukoliko greške koje se loguju ipak nije moguće rešiti u ovom momentu, možete kreirati i jedan php fajl koji će svakog dana brisati error_log. Njegov sadržaj može izgledati ovako:

 

<?php

// ovo će obrisati error_log fajl unutar foldera u kom se skripta nalazi

$path = ‘error_log’;

if (is_file($path))

{

   unlink($path);

}

?>

 

Ovaj fajl možete nazvati recimo error_delete.php i potom kreirati “cron job” koji će svake noći pokretati ovaj fajl. Linija koju treba da upišete u polje “Command:”

 

lynx -lss=““ -dump http://www.nazivdomena.com/error_delete.php

 

Ovakva konfiguracija će u podešeno vreme posetiti fajl error_delete.php (koji je, na primer, smešten unutar public_html foldera) i pokrenuti ga, a fajl će potom obrisati error_log fajl, ukoliko postoji.

 

U slučaju da se error_log generiše na više mesta, fajl možete dopuniti tako da ukazuje i na još neke foldere. Na primer:

 

<?php

// ovo će obrisati error_log fajl unutar foldera u kom se skripta nalazi

$path = ‘error_log’;

if (is_file($path))

{

   unlink($path);

}

// ovo će obrisati error_log fajl i unutar wp-admin foldera

$path = ‘wp-admin/error_log’;

if (is_file($path))

{

   unlink($path);

}

// ovo će obrisati error_log fajl i unutar wp-content foldera

$path = ‘wp-content/error_log’;

if (is_file($path))

{

   unlink($path);

}

?>

 

Savetujemo da ovaj način koristite isključivo kao privremeno rešenje dok ne rešite svaku grešku koja se loguje pojedinačno, jer hosting provajder može zahtevati da uklonite ovo rešenje ukoliko ono postane prezahtevno ili ukoliko generisanje loga krene da troši veće količine serverskih resursa.

 

Isključivanje generisanja error_log fajla

Generisanje error_loga se može i isključiti. Plastično rečeno, do greške će doći svakako, ali je server neće nigde zabeležiti.

 

Kako da to uradite?

Unutar .htaccess fajla (najčešće u okviru public_html folder) smestite sledeće linije (poželjno na dno fajla):

 

php_flag log_errors Off

 

Savetujemo da ne pribegavate ni ovom rešenju jer se može desiti da vam u budućnosti zatreba logovanje grešaka kako biste nastavili sa razvojem koda, a da eventualno zaboravite da ste ga na ovaj način isključili.

PODELITE