Upravičeno bi lahko rekli, da so dnevniki eno najbolj podcenjenih in premalo izkoriščenih orodij na samostojni razvijalec php - Odstranjevanje. Kljub bogastvu informacij, ki jih lahko ponudijo, niso redki primeri, da so to dnevniki zadnji mesto razvijalca, ko poskuša rešiti težavo.
V resnici bi morale biti datoteke dnevnika PHP pogosto najprej kraj za iskanje namigov, ko se pojavijo težave. Informacije, ki jih vsebujejo, lahko pogosto zmanjšajo čas, ko ste izvlekli lase in poskušali izslediti kašaste hrošče.
Morda pa je še pomembneje, da lahko z nekaj kreativnosti in premišljevanja vaše dnevniške datoteke izkoristite za dragocen vir informacij o uporabi in analitike. Kreativna uporaba dnevniških datotek lahko pomaga odgovoriti na vprašanja, kot so: Kateri brskalniki se najpogosteje uporabljajo za obisk mojega spletnega mesta? Kakšen je povprečni odzivni čas mojega strežnika? Kolikšen je bil odstotek zahtev za koren strani? Kako se je spremenila uporaba, odkar smo uvedli najnovejše posodobitve? In še veliko, veliko več.
Ta članek vsebuje številne nasvete o kako konfigurirati svoje dnevniške datoteke , tako dobro, kot kako obdelati informacije, ki jih vsebujejo , da bi kar najbolj povečali koristi, ki jih zagotavljajo.
Čeprav se ta članek tehnično osredotoča na beleženje za razvijalce PHP, je večina informacij, predstavljenih v tem dokumentu, precej agnostična za tehnologijo in je pomembna tudi za druge jezike in tehnološke sklade.
Opomba: Ta članek predpostavlja osnovno poznavanje lupine Unix. Za tiste, ki jim tega znanja primanjkuje, je Dodatek je na voljo, ki predstavlja nekatere ukaze, potrebne za dostop in branje dnevniških datotek v sistemu Unix.
Kot primer bomo uporabili projekt za razpravo v tem članku Symfony Standard kot delovni projekt in ga bomo postavili na Debian 7 Wheezy z rsyslogd
, nginx
in PHP-FPM
.
composer create-project symfony/framework-standard-edition my '2.6.*'
To nam hitro omogoči delujoč testni projekt z lepim uporabniškim vmesnikom.
Tu je nekaj napotkov o tem, kako konfigurirati svoje dnevniške datoteke, da bi povečali njihovo vrednost.
Dnevniki napak predstavljajo najosnovnejšo obliko dnevnika; tj. zajemanje dodatnih informacij in podrobnosti ob težavah. Torej bi v idealnem svetu želeli, da ne bi bilo napak in da bi bili vaši dnevniki napak prazni. Ko pa se težave pojavijo (kot se to vedno zgodi), bi morali biti dnevniki napak eden prvih postankov na vašem pot za odpravljanje napak .
Dnevnike napak je običajno precej enostavno konfigurirati.
Na primer, vsa sporočila o napakah in zrušitvah se lahko zabeležijo v dnevnik napak v popolnoma enaki obliki, v kateri bi bila sicer predstavljena uporabniku. Z nekaj preproste konfiguracije končnemu uporabniku nikoli ne bo treba videti teh grdih napak na vašem spletnem mestu, medtem ko bo devops še vedno lahko spremljal sistem in pregledal ta sporočila o napakah v vseh njihovih krvavih podrobnostih. Tukaj je opisano, kako nastaviti to vrsto prijave v PHP:
log_errors = On error_reporting = E_ALL error_log = /path/to/my/error/log
Še dve vrstici, ki sta pomembni za vključitev v dnevniško datoteko spletnega mesta v živo, da bi preprečili, da bi se krvave stopnje podrobnosti napak prikazovale uporabnikom, sta:
display_errors = Off display_startup_errors = Off
syslog
) KonfiguracijaObstaja veliko splošno združljivih izvedb syslog
demon v odprtokodnem svetu, vključno z:
syslogd
in sysklogd
- najpogosteje viden na sistemih družine BSD, CentOS , Mac OS X , in drugisyslog-ng
- privzeto za moderno Gentoo in SuSE gradirsyslogd
- se pogosto uporablja na Debian in Fedora družine operacijskih sistemov(Opomba: V tem članku bomo za primere uporabili rsyslogd
.)
Osnovna konfiguracija sistemskega dnevnika je na splošno ustrezna za zajemanje vaših dnevniških sporočil v sistemski dnevniški datoteki (običajno /var/log/syslog
; lahko je tudi /var/log/messages
ali /var/log/system.log
odvisno od distribucijskega sistema, ki ga uporabljate) .
Sistemski dnevnik ponuja več možnosti dnevnika, od katerih je osem (LOG_LOCAL0
do LOG_LOCAL7
) rezerviranih za uporabniško uvedene projekte. Tukaj je na primer, kako lahko nastavite LOG_LOCAL0
za zapisovanje v 4 ločene dnevniške datoteke glede na raven beleženja (tj. napaka, opozorilo, informacije, odpravljanje napak):
# /etc/rsyslog.d/my.conf local0.err /var/log/my/err.log local0.warning /var/log/my/warning.log local0.info -/var/log/my/info.log local0.debug -/var/log/my/debug.log
Zdaj, kadar koli napišete sporočilo dnevnika v LOG_LOCAL0
objekt, sporočila o napakah bodo /var/log/my/err.log
, opozorilna sporočila bodo /var/log/my/warning.log
itd. Upoštevajte pa, da demon syslog filtrira sporočila za vsako datoteko na podlagi pravila »ta raven in več«. Torej, v zgornjem primeru bodo vsa sporočila o napakah prikazana v vseh štirih konfiguriranih datotekah, opozorilna sporočila bodo prikazana v vseh, razen v dnevniku napak, informativna sporočila se bodo pojavila v dnevnikih informacij in odpravljanju napak, sporočila o odpravljanju napak pa bodo šla samo na debug.log
.
Še ena pomembna opomba; The -
znaki pred datotekami na ravni informacij in odpravljanjem napak v zgornjem primeru konfiguracijske datoteke kažejo, da je treba zapise v te datoteke izvajati asinhrono (ker te operacije ne blokirajo). To je običajno v redu (in v večini primerov celo priporočljivo) za dnevnike informacij in odpravljanja napak, vendar je najbolje, da so zapisi v dnevnik napak (in verjetno tudi dnevnik opozoril) sinhroni.
Če želite zaustaviti manj pomembno raven beleženja (npr. Na delovnem strežniku), lahko preprosto preusmerite povezana sporočila na /dev/null
(tj. nikamor):
local0.debug /dev/null # -/var/log/my/debug.log
Posebna prilagoditev, ki je koristna, zlasti za podporo nekaterih razčlenitvah datotek dnevnika PHP, o katerih bomo razpravljali kasneje v tem članku, je uporaba zavihka kot ločilnega znaka v sporočilih dnevnika. To lahko enostavno naredite tako, da v /etc/rsyslog.d
dodate naslednjo datoteko:
# /etc/rsyslog.d/fixtab.conf $EscapeControlCharactersOnReceive off
In končno, ne pozabite znova zagnati demona syslog, ko izvedete kakršne koli spremembe konfiguracije, da bodo lahko začele veljati:
service rsyslog restart
Za razliko od dnevnikov aplikacij in dnevnikov napak, v katere lahko pišete, se na strežniške dnevnike na vsaki zahtevi zapisujejo izključno ustrezni demoni strežnika (npr. Spletni strežnik, strežnik baz podatkov itd.). Edini 'nadzor', ki ga imate nad temi dnevniki, je, kolikor vam strežnik omogoča konfiguriranje njegovih funkcij beleženja. Čeprav je v teh datotekah mogoče veliko prebiti, so pogosto edini način, da dobite jasen občutek, kaj se dogaja 'pod pokrovom' vašega strežnika.
Uvedimo našo primerno aplikacijo Symfony Standard v okolju nginx z zaledjem MySQL za shranjevanje. Tukaj je konfiguracija gostitelja nginx, ki jo bomo uporabili:
server { server_name my.log-sandbox; root /var/www/my/web; location / { # try to serve file directly, fallback to app.php try_files $uri /app.php$is_args$args; } # DEV # This rule should only be placed on your development environment # In production, don't include this and don't deploy app_dev.php or config.php location ~ ^/(app_dev|config).php(/|$) { fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_split_path_info ^(.+.php)(/.*)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param HTTPS off; } # PROD location ~ ^/app.php(/|$) { fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_split_path_info ^(.+.php)(/.*)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param HTTPS off; # Prevents URIs that include the front controller. This will 404: # http://domain.tld/app.php/some-path # Remove the internal directive to allow URIs like this internal; } error_log /var/log/nginx/my_error.log; access_log /var/log/nginx/my_access.log; }
Glede zadnjih dveh direktiv zgoraj: access_log
predstavlja splošni dnevnik zahtev, medtem ko error_log
je za napake in tako kot pri dnevnikih napak v programu je vredno nastaviti dodatno spremljanje, da boste opozorjeni na težave, da boste lahko hitro reagirali.
Opomba: To je namerno poenostavljena konfiguracijska datoteka nginx, ki je na voljo samo za namene. Skoraj nič pozornosti ne namenja varnosti in zmogljivosti in je ne bi smeli uporabljati takšno, kakršna je v nobenem 'resničnem' okolju.
To dobimo v /var/log/nginx/my_access.log
po vnosu http://my.log-sandbox/app_dev.php/
v brskalniku in pritisnete Enter
.
192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /app_dev.php/ HTTP/1.1' 200 6715 '-' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /bundles/framework/css/body.css HTTP/1.1' 200 6657 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /bundles/framework/css/structure.css HTTP/1.1' 200 1191 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /bundles/acmedemo/css/demo.css HTTP/1.1' 200 2204 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /bundles/acmedemo/images/welcome-quick-tour.gif HTTP/1.1' 200 4770 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /bundles/acmedemo/images/welcome-demo.gif HTTP/1.1' 200 4053 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /bundles/acmedemo/images/welcome-configure.gif HTTP/1.1' 200 3530 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:28 +0300] 'GET /favicon.ico HTTP/1.1' 200 6518 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36' 192.168.56.1 - - [26/Apr/2015:16:13:30 +0300] 'GET /app_dev.php/_wdt/e50d73 HTTP/1.1' 200 13265 'http://my.log-sandbox/app_dev.php/' 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36'
To kaže, da brskalnik za strežbo ene strani dejansko izvede 9 klicev HTTP. 7 od teh pa je zahtev za statične vsebine, ki so preproste in lahke. Vendar še vedno jemljejo omrežne vire in prav to je mogoče optimizirati z uporabo različnih sprite in tehnike minifikacije.
Čeprav bo o teh optimizacijah razpravljati v drugem članku, je tukaj pomembno to, da lahko zahteve za statične vsebine ločimo ločeno z uporabo drugega location
zanje:
location ~ .(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js)$ { access_log /var/log/nginx/my_access-static.log; }
Ne pozabite, da je nginx | _ + _ | izvaja preprosto ujemanje regularnih izrazov, tako da lahko na svoje spletno mesto vključite toliko razširitev statične vsebine, kot pričakujete.
Razčlenjevanje takšnih dnevnikov se ne razlikuje od razčlenjevanja dnevnikov aplikacij.
Dva druga dnevnika PHP, vredna omembe, sta dnevnik odpravljanja napak in dnevnik hrambe podatkov.
Druga priročna stvar v dnevnikih nginx je dnevnik odpravljanja napak. Vklopimo ga lahko tako, da zamenjamo location
vrstico konfiguracije z naslednjim (zahteva namestitev modula za odpravljanje napak nginx):
error_log
Ista nastavitev velja za Apache ali kateri koli drug spletni strežnik, ki ga uporabljate.
In mimogrede, dnevniki za odpravljanje napak so ne povezane z dnevniki napak, čeprav so konfigurirani v error_log /var/log/nginx/my_error.log debug;
direktive.
Čeprav je dnevnik odpravljanja napak resnično glasen (na primer ena sama zahteva nginx ustvari 127 KB podatkov dnevnika!), Pa je vseeno lahko zelo koristen. Brskanje po dnevniški datoteki je lahko okorno in dolgočasno, vendar pogosto lahko hitro poišče namige in informacije, ki močno pripomorejo k hitrejšemu postopku odpravljanja napak.
Dnevnik odpravljanja napak lahko resnično pomaga pri odpravljanju napak v konfiguracijah nginx, zlasti najbolj zapletenih delov, na primer error_log
ujemanje in location
verige.
Dnevnikov odpravljanja napak v proizvodnem okolju ne bi smeli nikoli omogočiti. Količina prostora, ki ga uporabljajo, in količina informacij, ki jih shranijo, pomenijo veliko I / O obremenitev vašega strežnika, kar lahko znatno poslabša delovanje celotnega sistema.
Druga vrsta dnevnika strežnika (uporabna za odpravljanje napak) so dnevniki shranjevanja podatkov. V MySQL jih lahko vklopite tako, da dodate te vrstice:
rewrite
Ti dnevniki preprosto vsebujejo seznam poizvedb, ki jih sistem zažene med kroženjem zahtev po zbirki podatkov v kronološkem vrstnem redu, kar je lahko v pomoč pri različnih potrebah po odpravljanju napak in sledenju. Vendar v proizvodnih sistemih ne bi smeli ostati omogočeni, saj bodo ustvarili dodatno nepotrebno V / I obremenitev, ki vpliva na zmogljivost.
PHP sam ponuja funkcije za odpiranje, pisanje in zapiranje dnevniških datotek ( [mysqld] general_log = 1 general_log_file = /var/log/mysql/query.log
, openlog()
, in syslog()
).
Tukaj so tudi številne knjižnice sečnje za razvijalca PHP, kot je Monolog (priljubljeno med Symfony in Laravel uporabniki), pa tudi različne izvedbe, specifične za okvir, kot so vgrajene zmogljivosti beleženja CakePHP . Na splošno knjižnice, kot je Monolog, ne samo zavijajo closelog()
klici, vendar omogočajo tudi uporabo drugih zalednih funkcij in orodij.
Tu je preprost primer, kako zapisati v dnevnik:
syslog()
Naš klic tukaj
openlog
je prišlo do klicasyslog()
kot privzeta naprava za beleženjeEvo, kako bi izgledala vsebina dnevniške datoteke po zagonu zgornje kode:
LOG_LOCAL0
Zdaj, ko smo vsi dobro s teorijo in osnovami, poglejmo, koliko lahko dobimo od dnevnikov, ki v čim manj sprememb spremenijo naš vzorčni projekt Symfony Standard.
Najprej ustvarimo skripte # cat /var/log/my/info.log Mar 2 00:23:29 log-sandbox 54f39161a2e55: It works!
(za pravilno odpiranje in konfiguriranje naših dnevnikov) in src/log-begin.php
(za beleženje informacij o uspešnem zaključku). Upoštevajte, da bomo zaradi enostavnosti vsa sporočila samo zapisali v informacijski dnevnik.
src/log-end.php
In zahtevajmo te skripte v # src/log-begin.php
app.php
Za razvojno okolje želimo te skripte zahtevati v app_dev.php
do MODE
namesto DEV
.
Prav tako želimo slediti, kateri krmilniki se prikličejo, zato dodajte še eno vrstico v PROD
, takoj na začetku AcmeDemoBundleEventListenerControllerListener
metoda:
ControllerListener::onKernelController()
Upoštevajte, da te spremembe sestavljajo zgolj 15 dodatnih vrstic kode, vendar lahko skupaj dajo veliko informacij.
Za začetek poglejmo, koliko zahtev HTTP je potrebnih za nalaganje posamezne strani.
Tu so informacije v dnevnikih za eno zahtevo glede na način, kako smo konfigurirali beleženje:
syslog(LOG_INFO, 'CONTROLLER ' . get_class($event->getController()[0]));
Zdaj vemo, da je vsakemu nalaganju strani dejansko vročeno dve zahtevi HTTP.
Pravzaprav je treba omeniti dve točki. Prvič, dve zahtevi na nalaganje strani sta za uporabo Symfonyja v načinu za razvijalce (kar sem počel v tem članku). Klice v načinu za razvijanje lahko prepoznate tako, da poiščete Mar 3 12:04:20 log-sandbox 54f58724b1ccc: BEGIN Mar 3 12:04:20 log-sandbox 54f58724b1ccc: URI /app_dev.php/ Mar 3 12:04:20 log-sandbox 54f58724b1ccc: CLIENT 192.168.56.1 1b101cd Mar 3 12:04:20 log-sandbox 54f58724b1ccc: MODE DEV Mar 3 12:04:23 log-sandbox 54f58724b1ccc: CONTROLLER AcmeDemoBundleControllerWelcomeController Mar 3 12:04:25 log-sandbox 54f58724b1ccc: DISPATCH TIME 4.51 Mar 3 12:04:25 log-sandbox 54f58724b1ccc: END Mar 3 12:04:25 log-sandbox 54f5872967dea: BEGIN Mar 3 12:04:25 log-sandbox 54f5872967dea: URI /app_dev.php/_wdt/59b8b6 Mar 3 12:04:25 log-sandbox 54f5872967dea: CLIENT 192.168.56.1 1b101cd Mar 3 12:04:25 log-sandbox 54f5872967dea: MODE DEV Mar 3 12:04:28 log-sandbox 54f5872967dea: CONTROLLER SymfonyBundleWebProfilerBundleControllerProfilerController Mar 3 12:04:29 log-sandbox 54f5872967dea: DISPATCH TIME 4.17 Mar 3 12:04:29 log-sandbox 54f5872967dea: END
Kosi URL-jev. Drugič, recimo, da je vsakemu nalaganju strani na voljo dve poznejši zahtevi za aplikacijo Symfony. Kot smo že videli v dnevnikih dostopa nginx, je dejansko več klicev HTTP, od katerih so nekateri namenjeni statični vsebini.
V redu, zdaj pobrskajmo na predstavitvenem spletnem mestu (za zbiranje podatkov v dnevniških datotekah) in poglejmo, kaj se še lahko naučimo iz teh dnevnikov.
Koliko zahtev je bilo vročenih skupaj od začetka dnevniške datoteke?
/app-dev.php/
Je kdo od njih odpovedal (se je scenarij zaprl, ne da bi prišel do konca)?
# grep -c BEGIN info.log 10
Vidimo, da je število # grep -c END info.log 10
in BEGIN
zapisov se ujema, zato nam to pove, da so bili vsi klici uspešni. (Če se skript PHP ne bi uspešno končal, ne bi dosegel izvedbe END
skripta.)
Kolikšen je bil odstotek zahtev za koren strani?
src/log-end.php
To nam pove, da je bilo koren strani naloženih 2 strani. Ker smo že izvedeli, da (a) obstajata dve zahtevi za aplikacijo na nalaganje strani in (b) je bilo skupaj 10 zahtev HTTP, je bil odstotek zahtev za koren spletnega mesta 40% (tj. 2x2 / 10).
Kateri razred krmilnika je odgovoren za vročanje zahtev korenu spletnega mesta?
# `grep -cE 's/app_dev.php/$' info.log` 2
Tu smo uporabili enolični ID zahteve za preverjanje vseh dnevniških sporočil, povezanih s to eno samo zahtevo. S tem smo lahko ugotovili, da je razred krmilnika, odgovoren za vročanje zahtev korenu spletnega mesta, # grep -E 's/$|s/app_dev.php/$' info.log | head -n1 Mar 3 12:04:20 log-sandbox 54f58724b1ccc: URI /app_dev.php/ # grep 54f58724b1ccc info.log | grep CONTROLLER Mar 3 12:04:23 log-sandbox 54f58724b1ccc: CONTROLLER AcmeDemoBundleControllerWelcomeController
.
Kateri odjemalci z IP-ji podomrežja
AcmeDemoBundleControllerWelcomeController
ste dostopali do spletnega mesta?
192.168.0.0/16
Kot je bilo pričakovano v tem preprostem testnem primeru, je spletno mesto dostopal samo moj gostiteljski računalnik. To je seveda zelo poenostavljen primer, vendar je sposobnost, ki jo kaže (zmožnost analiziranja virov prometa na vašem spletnem mestu), očitno zelo močna in pomembna.
Koliko prometa na mojem spletnem mestu je prispeval FireFox?
Ob # grep CLIENT info.log | cut -d':' -f4 | cut -f2 | sort | uniq 192.168.56.1
kot razpršilnik mojega uporabniškega agenta Firefox lahko na to vprašanje odgovorim na naslednji način:
1b101cd
Odgovor: 80% (tj. 8/10)
Kolikšen je odstotek zahtev, ki so se počasi odzvale?
Za namene tega primera bomo opredelili izraz »počasi« kot odziv, ki traja več kot 5 sekund. V skladu s tem:
# grep -c 1b101cd info.log 8 # grep -c CLIENT info.log 10
Odgovor: 20% (tj. 2/10)
Je kdo kdaj ponudil parametre GET?
# grep 'DISPATCH TIME' info.log | grep -cE 's[0-9]{2,}.|s[5-9].' 2
Ne, standard Symfony uporablja samo URL polže, zato nam to tudi tukaj pove, da nihče ni poskušal vdreti v spletno mesto.
To je le peščica razmeroma osnovnih primerov načinov, kako lahko datoteke dnevnikov ustvarjalno izkoristite, da dobite dragocene informacije o uporabi in celo osnovno analitiko.
Še ena napoved je za varnost. Morda mislite, da je prijava zahtev dobra ideja, v večini primerov pa res. Vendar je pomembno, da ste izjemno previdni pri odstranjevanju morebitnih občutljivih podatkov o uporabniku, preden jih shranite v dnevnik.
Ker so dnevniške datoteke besedilne datoteke, ki jim vedno priloži informacije, nenehno rastejo. Ker gre za dobro znano težavo, obstaja nekaj precej standardnih pristopov k nadzoru rasti dnevniških datotek.
Najlažje je zavrtite hlode . Vrteči se dnevniki pomenijo:
Najpogostejša rešitev za to je # grep URI info.log | grep ?
, ki je prednameščen z večino distribucij * nix. Poglejmo preprosto konfiguracijsko datoteko za vrtenje naših dnevnikov:
logrotate
Drug, naprednejši pristop je ustvariti /var/log/my/debug.log /var/log/my/info.log /var/log/my/warning.log /var/log/my/error.log { rotate 7 daily missingok notifempty delaycompress compress sharedscripts postrotate invoke-rc.d rsyslog rotate > /dev/null endscript }
sam zapisuje sporočila v datoteke, ki so dinamično ustvarjene glede na trenutni datum in čas. To bi še vedno zahtevalo rešitev po meri za odstranjevanje starejših datotek, vendar omogoča, da devops natančno upravlja časovne okvire za vsako datoteko dnevnika. Za naš primer:
rsyslogd
Na ta način, $template DynaLocal0Err, '/var/log/my/error-%$NOW%-%$HOUR%.log' $template DynaLocal0Info, '/var/log/my/info-%$NOW%-%$HOUR%.log' $template DynaLocal0Warning, '/var/log/my/warning-%$NOW%-%$HOUR%.log' $template DynaLocal0Debug, '/var/log/my/debug-%$NOW%-%$HOUR%.log' local1.err -?DynaLocal0Err local1.info -?DynaLocal0Info local1.warning -?DynaLocal0Warning local1.debug -?DynaLocal0Debug
bo vsako uro ustvaril posamezno datoteko dnevnika in jih ne bo treba zasukati in znova zagnati demona. Za rešitev te rešitve je mogoče odstraniti dnevniške datoteke, starejše od 5 dni:
rsyslog
Ko projekt raste, razčlenjevanje informacij iz dnevnikov postaja vedno bolj lačno. To ne pomeni samo ustvarjanja dodatne obremenitve strežnika; to pomeni tudi ustvarjanje največje obremenitve CPU in diskovnih pogonov v času razčlenjevanja dnevnikov, kar lahko poslabša odzivni čas strežnika za uporabnike (ali v najslabšem primeru lahko celo zruši spletno mesto).
Da bi to rešili, razmislite o nastavitvi a strežnik za centralizirano beleženje . Za to potrebujete samo še eno okence z odprtimi vrati UDP 514 (privzeto). Če želite find /var/log/my/ -mtime +5 -print0 | xargs -0 rm
poslušajte povezave, dodajte naslednjo vrstico v svojo konfiguracijsko datoteko:
rsyslogd
Potem je nastavitev odjemalca tako enostavna kot:
$UDPServerRun 514
(kjer je *.* @HOSTNAME:514
ime gostitelja vašega oddaljenega dnevnika).
Čeprav je ta članek predstavil nekaj ustvarjalnih načinov, na katere lahko dnevniške datoteke ponujajo dragocenejše informacije, kot ste si morda prej predstavljali, je pomembno poudariti, da smo samo opraskali površino tega, kar je mogoče. Obseg, obseg in oblika zapisa, ki ga lahko prijavite, je skoraj neomejen. To pomeni, da - če obstajajo podatki o uporabi ali analitiki, ki jih želite izvleči iz svojih dnevnikov - jih preprosto prijavite na način, ki bo olajšal naknadno razčlenitev in analizo. Poleg tega je to analizo pogosto mogoče izvesti s standardnimi orodji ukazne vrstice Linux, kot so HOSTNAME
, grep
ali sed
.
Dejansko so datoteke dnevnika PHP najmočnejše orodje, ki ima lahko izjemno korist.
Koda na GitHub: https://github.com/isanosyan/toptal-blog-logs-post-example
Tu je kratek uvod v nekatera najpogostejša orodja ukazne vrstice * nix, ki jih boste želeli poznati pri branju in upravljanju z vašimi dnevniškimi datotekami.
awk
je morda najbolj preprost. Natisne celotno datoteko v izhodni tok. Na primer, naslednji ukaz bo natisnil cat
na konzolo:
logfile1
cat logfile1
znak uporabniku omogoča preusmeritev izhoda, na primer v drugo datoteko. Odpre ciljni tok v načinu pisanja (kar pomeni brisanje ciljne vsebine). Evo, kako nadomestimo vsebino >
z vsebino tmpfile
:
logfile1
cat logfile1 > tmpfile
preusmeri izhod in odpre ciljni tok v načinu dodajanja. Trenutna vsebina ciljne datoteke bo ohranjena, nove vrstice bodo dodane na dno. To bo dodano >>
vsebina do logfile1
:
tmpfile
cat logfile1 >> tmpfile
filtrira datoteko po nekaterih vzorcih in natisne samo ujemajoče se vrstice. Spodnji ukaz bo natisnil samo vrstice grep
ki vsebuje logfile1
sporočilo:
Bingo
grep Bingo logfile1
natisne vsebino enega stolpca (s številko od 1). Privzeto išče znake zavihkov kot ločila med stolpci. Če imate na primer datoteko, polno časovnih žigov v obliki cut
, bo to omogočilo tiskanje le let:
YYYY-MM-DD HH:MM:SS
cut -d'-' -f1 logfile1
prikaže samo prve vrstice datoteke
head
prikaže samo zadnje vrstice datoteke
tail
razvrsti vrstice v izhodu
sort
filtrira podvojene vrstice
uniq
šteje besede (ali vrstice pri uporabi z zastavico wc
-l
(tj. simbol »cev«) daje izhod iz enega ukaza kot vhod v drugega. Cev je zelo priročna za kombiniranje ukazov. Tako lahko na primer poiščemo mesece leta 2014, ki se pojavijo v določenem časovnem žigu:
|
Tu najprej primerjamo vrstice z regularnim izrazom »začne se z letom 2014«, nato odrežemo mesece. Na koncu uporabimo kombinacijo grep -E '^2014' logfile1 | cut -d'-' -f2 | sort | uniq
in sort
samo enkrat natisniti pojavitve.