Web-Käyttöliittymä

Ota kaikki irti PHP-lokitiedostoistasi: Käytännön opas

Voidaan perustellusti sanoa, että tukit ovat yksi aliarvioiduista ja alikäytetyistä työkaluista a freelance php -kehittäjä Hävittäminen. Huolimatta runsaasta tiedosta, jota he voivat tarjota, ei ole harvinaista, että lokit ovat kestää paikka, jonka kehittäjä näyttää yrittäessään ratkaista ongelman.

Todellisuudessa PHP-lokitiedostojen pitäisi olla monissa tapauksissa ensimmäinen paikka etsiä vihjeitä ongelmien ilmetessä. Usein niiden sisältämät tiedot voivat vähentää huomattavasti aikaa, joka kuluu hiusten vetämiseen yrittäen jäljittää gnarly-vika.

Mutta ehkä vielä tärkeämpää on, että vähän luovuutta ja ennakointia käyttämällä lokitiedostosi voidaan hyödyntää palvelemaan arvokkaana käyttötietojen ja analytiikan lähteenä. Lokitiedostojen luova käyttö voi auttaa vastaamaan kysymyksiin, kuten: Mitä selaimia käytetään yleisimmin sivustollani vierailemiseen? Mikä on palvelimeni keskimääräinen vastausaika? Kuinka suuri prosenttiosuus sivuston juurille lähetetyistä pyynnöistä oli? Kuinka käyttö on muuttunut uusimpien päivitysten käyttöönoton jälkeen? Ja paljon, paljon muuta.



PHP-lokitiedostot

Tässä artikkelissa on useita vinkkejä miten määrität lokitiedostot , yhtä hyvin kuin miten käsitellä niiden sisältämiä tietoja maksimoidakseen niiden tarjoaman hyödyn.

Vaikka tässä artikkelissa keskitytään teknisesti PHP-kehittäjien kirjaamiseen, suuri osa tässä esitetystä tiedosta on melko teknologia-agnostista ja merkityksellistä myös muille kielille ja tekniikkapinoille.

Huomautus: Tässä artikkelissa oletetaan, että Unix-kuori on peruskokemuksella. Niille, joilla ei ole tätä tietoa, an Liite toimitetaan, joka esittelee joitain komentoja, joita tarvitaan lokitiedostojen käyttämiseen ja lukemiseen Unix-järjestelmässä.

PHP-lokitiedostomalliprojektimme

Otamme esimerkkiprojektin keskustelutarkoituksiin tässä artikkelissa Symfony Standard työprojektina ja asetamme sen Debian 7 Wheezylle rsyslogd, nginx ja PHP-FPM

composer create-project symfony/framework-standard-edition my '2.6.*'

Tämä antaa meille nopeasti toimivan testiprojektin mukavalla käyttöliittymällä.

Vinkkejä lokitiedostojen määrittämiseen

Tässä on joitain ohjeita lokitiedostojen määrittämisestä niiden arvon maksimoimiseksi.

Virhelokin määritys

Virhelokit edustavat kaikkein perustavanlaatuista kirjaamista. ts. kaappaamalla lisätietoja ja yksityiskohtia ongelmien ilmetessä. Joten ihanteellisessa maailmassa haluat, ettei virheitä ole ja että virhelokisi ovat tyhjät. Mutta kun ongelmia ilmenee (kuten aina tapahtuu), virhelokiesi tulisi olla yksi ensimmäisistä pysäkeistä, jotka teet virheenkorjausreitti .

Virhelokit on yleensä helppo konfiguroida.

Ensinnäkin kaikki virhe- ja kaatumisviestit voidaan kirjata virhelokiin täsmälleen samassa muodossa kuin ne muuten esitettäisiin käyttäjälle. Joillakin yksinkertaisilla määrityksillä loppukäyttäjän ei tarvitse koskaan nähdä näitä ruma virheiden jälkiä sivustollasi, kun taas devops pystyy edelleen seuraamaan järjestelmää ja tarkistamaan nämä virheilmoitukset kaikilla yksityiskohdillaan. Näin määrität tällaisen kirjautumisen PHP: hen:

log_errors = On error_reporting = E_ALL error_log = /path/to/my/error/log

Kaksi muuta riviä, jotka on tärkeää sisällyttää live-sivuston lokitiedostoon, jotta estetään virheiden tarkkojen tasojen esittäminen käyttäjille, ovat:

display_errors = Off display_startup_errors = Off

Järjestelmäloki (syslog) Kokoonpano

syslog: Aa on monia yleisesti yhteensopivia toteutuksia demoni avoimen lähdekoodin maailmassa, mukaan lukien:

(Huomaa: Tässä artikkelissa käytämme rsyslogd esimerkkeihimme.)

Syslogin perusasetukset ovat yleensä riittävät lokiviestien sieppaamiseksi koko järjestelmän kattavaan lokitiedostoon (normaalisti /var/log/syslog; voi olla myös /var/log/messages tai /var/log/system.log käyttämästäsi jakelusta riippuen) .

Järjestelmäloki tarjoaa useita lokitiloja, joista kahdeksan (LOG_LOCAL0 kautta LOG_LOCAL7) on varattu käyttäjien käyttöön ottamille projekteille. Esimerkiksi, miten voit määrittää LOG_LOCAL0 kirjoittaa 4 erilliseen lokitiedostoon lokitason perusteella (ts. virhe, varoitus, tiedot, virheenkorjaus):

# /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

Nyt kun kirjoitat lokiviestin osoitteeseen LOG_LOCAL0 laitoksessa virheilmoitukset siirtyvät kohtaan /var/log/my/err.log, varoitusviestit siirtyvät kohtaan /var/log/my/warning.log ja niin edelleen. Huomaa kuitenkin, että syslog-daemon suodattaa viestit jokaiselle tiedostolle tämän tason ja korkeamman tason säännön perusteella. Joten yllä olevassa esimerkissä kaikki virheilmoitukset näkyvät kaikissa neljässä määritetyssä tiedostossa, varoitusviestit näkyvät kaikissa paitsi virhelokissa, infoviestit näkyvät tieto- ja virhelokin yhteydessä ja virheenkorjausviestit menevät vain debug.log.

Yksi tärkeä huomautus; - merkit ennen info- ja virheenkorjaustiedostoja yllä olevassa kokoonpanotiedostoesimerkissä osoittavat, että kirjoitukset näihin tiedostoihin tulisi suorittaa asynkronisesti (koska nämä toiminnot eivät ole estäviä). Tämä on tyypillisesti hieno (ja jopa suositeltavaa useimmissa tilanteissa) tieto- ja virhelokin yhteydessä, mutta on parasta, että virhelokiin (ja todennäköisimmin myös varoituslokiin) kirjoitettavat tiedostot ovat synkronisia.

Vähemmän tärkeän kirjautumistason sulkemiseksi (esim. Tuotantopalvelimella), voit yksinkertaisesti ohjata siihen liittyvät viestit /dev/null (eli mihinkään):

local0.debug /dev/null # -/var/log/my/debug.log

Yksi erityinen mukautus, joka on hyödyllinen, erityisesti tukemaan joitain PHP-lokitiedostojen jäsentämistä, josta keskustelemme myöhemmin tässä artikkelissa, on käyttää välilehteä erotinmerkkinä lokiviesteissä. Tämä voidaan tehdä helposti lisäämällä seuraava tiedosto /etc/rsyslog.d

# /etc/rsyslog.d/fixtab.conf $EscapeControlCharactersOnReceive off

Ja lopuksi, älä unohda käynnistää syslog-demonia uudelleen tekemällä kokoonpanomuutoksia, jotta ne tulevat voimaan:

service rsyslog restart

Palvelinlokin kokoonpano

Toisin kuin sovelluslokit ja virhelokit, joihin voit kirjoittaa, palvelinlokit ovat yksinomaan vastaavien palvelindemonien (esim. Verkkopalvelin, tietokantapalvelin jne.) Kirjoittamia jokaisessa pyynnössä. Ainoa 'hallinta', jota sinulla on näitä lokeja kohtaan, on siinä määrin, että palvelin antaa sinun määrittää sen lokitoiminnot. Vaikka näissä tiedostoissa voi olla paljon seulottavaa, ne ovat usein ainoa tapa saada selkeä käsitys siitä, mitä palvelimesi 'hupun alla' tapahtuu.

Asennetaan Symfony Standard -sovellussovelluksemme nginx-ympäristöön MySQL-tallennusohjelman kanssa. Tässä on nginx-isäntäkonfiguraatio, jota käytämme:

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; }

Kahden edellisen direktiivin osalta: access_log edustaa yleistä pyyntölokia, kun taas error_log on virheitä varten, ja kuten sovelluksen virhelokien kohdalla, kannattaa asettaa ylimääräinen valvonta, joka ilmoittaa ongelmista, jotta voit reagoida nopeasti.

Huomautus: Tämä on tarkoituksella liian yksinkertaistettu nginx-määritystiedosto, joka toimitetaan vain esimerkiksi. Se ei kiinnitä juurikaan huomiota turvallisuuteen ja suorituskykyyn, eikä sitä tule käyttää sellaisenaan missään 'todellisessa' ympäristössä.

Tähän pääsemme /var/log/nginx/my_access.log kirjoittamisen jälkeen http://my.log-sandbox/app_dev.php/ selaimessa ja lyödä 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'

Tämä osoittaa, että selain suorittaa yhden sivun palvelemista varten 9 HTTP-puhelua. Seitsemän näistä on kuitenkin staattisen sisällön pyyntöjä, jotka ovat selkeitä ja kevyitä. He kuitenkin käyttävät edelleen verkkoresursseja, ja tämä voidaan optimoida käyttämällä erilaisia spritit ja pienentämistekniikat.

Vaikka näistä optimoinnista on keskusteltava toisessa artikkelissa, tässä on merkitystä, että voimme kirjata pyynnöt staattiseen sisältöön erikseen käyttämällä toista location heille annettu direktiivi:

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; }

Muista, että nginx | ​​_ + _ | suorittaa yksinkertaisen säännöllisen lausekkeen vastaavuuden, joten voit sisällyttää niin monta staattista sisältölaajennusta kuin odotat lähettävän sivustollesi.

Tällaisten lokien jäsentäminen ei ole eroa kuin sovelluslokien jäsentäminen.

Muut mainitsemisen arvoiset lokit

Kaksi muuta mainitsemisen arvoista PHP-lokia ovat virheenkorjausloki ja tietojen tallennusloki.

Virheenkorjausloki

Toinen kätevä asia nginx-lokeissa on virheloki. Voimme kytkeä sen päälle korvaamalla location config-rivi seuraavasti (edellyttää, että nginx-virheenkorjausmoduuli on asennettu):

error_log

Sama asetus koskee Apachea tai muuta käyttämääsi verkkopalvelinta.

Ja muuten virheenkorjauslokit ovat ei liittyvät virhelokeihin, vaikka ne on määritetty error_log /var/log/nginx/my_error.log debug; direktiivi.

Vaikka virheenkorjausloki voi todellakin olla täsmällinen (esimerkiksi yksi nginx-pyyntö tuotti 127 kt lokitietoja!), Se voi silti olla erittäin hyödyllinen. Lokitiedoston kahlaaminen voi olla hankalaa ja tylsiä, mutta se voi usein tarjota nopeasti vihjeitä ja tietoja, jotka nopeuttavat suuresti virheenkorjausprosessia.

Erityisesti virheenkorjausloki voi todella auttaa nginx-kokoonpanojen, erityisesti monimutkaisimpien osien, kuten error_log ja location ketjut.

Virheenkorjauslokeja ei tietenkään tule koskaan ottaa käyttöön tuotantoympäristössä. Myös heidän käyttämänsä tilan määrä ja tallentamansa tiedon määrä tarkoittaa paljon I / O-kuormitusta palvelimellasi, mikä voi heikentää koko järjestelmän suorituskykyä merkittävästi.

Tietojen tallennuslokit

Toinen palvelinlokilaji (hyödyllinen virheenkorjauksessa) on tietojen tallennuslokit. MySQL: ssä voit ottaa ne käyttöön lisäämällä seuraavat rivit:

rewrite

Nämä lokit sisältävät yksinkertaisesti luettelon järjestelmän suorittamista kyselyistä palvellessaan tietokantapyyntöjä aikajärjestyksessä, mikä voi olla hyödyllistä erilaisissa virheenkorjaus- ja jäljitystarpeissa. Niiden ei kuitenkaan pitäisi pysyä käytössä tuotantojärjestelmissä, koska ne tuottavat ylimääräistä tarpeetonta I / O-kuormitusta, mikä vaikuttaa suorituskykyyn.

Kirjoittaminen lokitiedostoihisi

PHP itse tarjoaa toimintoja lokitiedostojen avaamiseen, kirjoittamiseen ja sulkemiseen ( [mysqld] general_log = 1 general_log_file = /var/log/mysql/query.log , openlog() ja syslog() ).

Siellä on myös lukuisia kirjauskirjastoja PHP-kehittäjälle, kuten Monologi (suosittu Symfony ja Laravel käyttäjät) sekä erilaiset kehyskohtaiset toteutukset, kuten sisäänrakennetut lokiominaisuudet KakkuPHP . Monologin kaltaiset kirjastot eivät yleensä kääri vain closelog() puhelut, mutta sallivat myös muiden taustajärjestelmien ja työkalujen käytön.

Tässä on yksinkertainen esimerkki lokiin kirjoittamisesta:

syslog()

Kutsumme tänne :

  • määrittää PHP: n määrittämään yksilöllisen tunnisteen kullekin järjestelmän lokiviestille komentosarjan elinkaaren aikana
  • asettaa sen viivyttämään syslog-yhteyden avaamista ensimmäiseen openlog puhelu on tapahtunut
  • sarjat syslog() oletuskirjaustoimintona

Lokitiedoston sisältö näyttäisi tältä yllä olevan koodin suorittamisen jälkeen:

LOG_LOCAL0

PHP-lokitiedostojesi arvon maksimointi

Nyt kun olemme kaikki hyviä teorian ja perusteiden suhteen, katsotaanpa, kuinka paljon voimme saada lokeista, jotka tekevät mahdollisimman vähän muutoksia Symfony Standard -malliprojektiimme.

Luo ensin komentosarjat # cat /var/log/my/info.log Mar 2 00:23:29 log-sandbox 54f39161a2e55: It works! (lokien avaamiseksi ja määrittämiseksi oikein) ja src/log-begin.php (kirjata tietoja onnistuneesta valmistumisesta). Huomaa, että yksinkertaisuuden vuoksi kirjoitamme kaikki viestit tietolokiin.

src/log-end.php

Ja vaaditaan näitä komentosarjoja # src/log-begin.php # src/log-end.php :

app.php

Kehitysympäristölle haluamme vaatia nämä komentosarjat yhtä hyvin. Koodi, jolla se tehdään, olisi sama kuin yllä, paitsi että asetamme app_dev.php kohteeseen MODE pikemminkin kuin DEV

Haluamme myös seurata, mitä ohjaimia käytetään, joten lisätään vielä yksi rivi PROD, suoraan AcmeDemoBundleEventListenerControllerListener menetelmä:

ControllerListener::onKernelController()

Huomaa, että nämä muutokset sisältävät vain 15 ylimääräistä koodiriviä, mutta ne voivat yhdessä tuottaa runsaasti tietoa.

Lokitiedostojen tietojen analysointi

Ensinnäkin, katsotaanpa, kuinka monta HTTP-pyyntöä tarvitaan sivun lataamiseen.

Tässä on yhden pyynnön lokien tiedot perustuen tapaan, jolla olemme määrittäneet lokimme.

syslog(LOG_INFO, 'CONTROLLER ' . get_class($event->getController()[0]));

Joten nyt tiedämme, että jokainen sivu latautuu tosiasiallisesti kahdella HTTP-pyynnöllä.

Itse asiassa tässä on kaksi mainitsemisen arvoista asiaa. Ensinnäkin, kaksi pyyntöä sivua kohti on tarkoitettu Symfony-sovelluksen käyttämiseen dev-tilassa (jonka olen tehnyt koko artikkelissa). Voit tunnistaa dev-tilan puhelut etsimällä 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 URL-palat. Toiseksi oletetaan, että jokainen sivu latautuu kahdella seuraavalla pyynnöllä Symfony-sovellukseen. Kuten näimme aiemmin nginx-pääsylokeista, HTTP-puheluja on itse asiassa enemmän, joista osa on staattista sisältöä varten.

Selvä, nyt selataan vähän demosivustolla (kerätään lokitiedostojen tiedot) ja katsotaanpa, mitä muuta voimme oppia näistä lokeista.

Kuinka monta pyyntöä on palveltu lokitiedoston alusta lähtien?

/app-dev.php/

Eikö kukaan heistä epäonnistunut (sulkeutuiko käsikirjoitus loppuun saamatta)?

# grep -c BEGIN info.log 10

Näemme, että # grep -c END info.log 10 ja BEGIN tietueet vastaavat, joten tämä kertoo meille, että kaikki puhelut onnistuivat. (Jos PHP-komentosarjaa ei olisi suoritettu onnistuneesti, se ei olisi saavuttanut END komentosarjaa.)

Kuinka suuri prosenttiosuus sivuston juurille lähetetyistä pyynnöistä oli?

src/log-end.php

Tämä kertoo meille, että sivuston juuressa oli 2 sivulatausta. Koska saimme aiemmin tietää, että (a) sovellukselle on 2 pyyntöä sivulatausta kohden ja (b) kaikkiaan 10 HTTP-pyyntöä, sivuston juuripyyntöjen prosenttiosuus oli 40% (eli 2x2 / 10).

Mikä ohjainluokka vastaa sivuston juuripyyntöjen tarjoamisesta?

# `grep -cE 's/app_dev.php/$' info.log` 2

Tässä käytimme pyynnön yksilöivää tunnusta tarkistamaan kaikki tähän yksittäiseen pyyntöön liittyvät lokiviestit. Pystyimme siten selvittämään, että ohjainluokka, joka vastaa pyynnöistä sivuston juurelle, on # 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

Mitkä asiakkaat, joilla on aliverkon IP-osoitteet AcmeDemoBundleControllerWelcomeController olet päässyt sivustoon?

192.168.0.0/16

Kuten tässä yksinkertaisessa testitapauksessa odotettiin, vain isäntätietokoneeni on päässyt sivustoon. Tämä on tietysti hyvin yksinkertaistettu esimerkki, mutta sen osoittama kyky (pystyä analysoimaan sivustosi liikenteen lähteitä) on tietysti melko voimakas ja tärkeä.

Kuinka suuri osa sivustoni liikenteestä on tullut Firefoxista?

# grep CLIENT info.log | cut -d':' -f4 | cut -f2 | sort | uniq 192.168.56.1 Firefox-käyttäjäagenttini hashina voin vastata tähän kysymykseen seuraavasti:

1b101cd

Vastaus: 80% (ts. 8/10)

Kuinka suuri prosenttiosuus pyynnöistä saatiin hitaasti?

Tässä esimerkissä määritellään 'hidas' siten, että vastauksen antamiseen kuluu yli 5 sekuntia. Asianmukaisesti:

# grep -c 1b101cd info.log 8 # grep -c CLIENT info.log 10

Vastaus: 20% (eli 2/10)

Toimittiko kukaan koskaan GET-parametreja?

# grep 'DISPATCH TIME' info.log | grep -cE 's[0-9]{2,}.|s[5-9].' 2

Ei, Symfony-standardi käyttää vain URL-etanoita, joten tässä kerrotaan myös, että kukaan ei ole yrittänyt hakkeroida sivustoa.

Nämä ovat vain kourallinen suhteellisen alkeellisia esimerkkejä tavoista, joilla lokitiedostoja voidaan luovasti hyödyntää tuottamaan arvokasta käyttötietoa ja jopa perustiedot.

Muita mielessä pidettäviä asioita

Pidä asiat turvassa

Toinen heads-up on turvallisuuteen. Voit ajatella, että lokipyynnöt on hyvä idea, useimmiten se onkin. On kuitenkin tärkeää olla erittäin varovainen mahdollisesti arkaluontoisten käyttäjätietojen poistamisessa ennen niiden tallentamista lokiin.

Taistelu lokitiedoston paisumisesta

Koska lokitiedostot ovat tekstitiedostoja, joihin olet aina liitä tietoa, ne kasvavat jatkuvasti. Koska tämä on hyvin tunnettu asia, lokitiedostojen kasvun hallitsemiseksi on joitain melko tavanomaisia ​​lähestymistapoja.

Helpoin on pyöritä tukkeja . Pyörivä tukki tarkoittaa:

  • Korvaa loki säännöllisesti uudella tyhjällä tiedostolla jatkokirjoittamista varten
  • Vanhan tiedoston tallentaminen historiaa varten
  • Riittävästi 'vanhentuneiden' tiedostojen poistaminen levytilan vapauttamiseksi
  • Varmista, että sovellus voi kirjoittaa lokiin keskeytyksettä, kun nämä tiedostomuutokset tapahtuvat

Yleisin ratkaisu tähän on # grep URI info.log | grep ? , joka toimitetaan esiasennettuna useimmilla * nix-jakeluilla. Katsotaan yksinkertainen määritystiedosto lokien kääntämistä varten:

logrotate

Toinen, edistyneempi lähestymistapa on tehdä /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 } itse kirjoittaa viestejä tiedostoihin, jotka on luotu dynaamisesti nykyisen päivämäärän ja kellonajan perusteella. Tämä edellyttäisi edelleen mukautettua ratkaisua vanhempien tiedostojen poistamiseen, mutta antaa devopsin hallita tarkasti kunkin lokitiedoston aikakehyksiä. Esimerkiksi:

rsyslogd

Tällä tavalla $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 luo yksilöllisen lokitiedoston joka tunti, eikä niitä tarvitse kiertää ja käynnistää daemon uudelleen. Näin voit poistaa yli 5 päivää vanhat lokitiedostot tämän ratkaisun toteuttamiseksi:

rsyslog

Etälokit

Kun projekti kasvaa, lokien tietojen jäsentäminen tarvitsee yhä enemmän resursseja. Tämä ei tarkoita vain ylimääräisen palvelinkuorman luomista; se tarkoittaa myös huippu kuormituksen luomista suorittimelle ja levyasemille lokien jäsentämisen aikana, mikä voi heikentää palvelimen vasteaikaa käyttäjille (tai pahimmassa tapauksessa voi jopa tuoda sivuston alas).

Voit ratkaista tämän harkitsemalla a keskitetty kirjauspalvelin . Tarvitset vain toisen laatikon, jossa UDP-portti 514 (oletus) on auki. Tee find /var/log/my/ -mtime +5 -print0 | xargs -0 rm kuuntele yhteyksiä, lisää seuraava rivi sen määritystiedostoon:

rsyslogd

Tämä on asiakkaan asettaminen niin helppoa kuin:

$UDPServerRun 514

(missä *.* @HOSTNAME:514 on etäkirjauspalvelimesi isäntänimi).

Johtopäätös

Vaikka tämä artikkeli on osoittanut joitain luovia tapoja, joilla lokitiedostot voivat tarjota paljon arvokkaampaa tietoa kuin olet ehkä aiemmin kuvitellut, on tärkeää korostaa, että olemme vain raaputtaneet mahdollisen pintaa. Lokien laajuus, laajuus ja muoto on melkein rajaton. Tämä tarkoittaa sitä, että jos lokistasi halutaan poimia käyttö- tai analyysitietoja, sinun on yksinkertaisesti kirjattava ne tavalla, joka on helppo jäsentää ja analysoida myöhemmin. Lisäksi analyysi voidaan usein suorittaa tavallisilla Linux-komentorivityökaluilla, kuten HOSTNAME, grep tai sed

PHP-lokitiedostot ovat todellakin tehokkain työkalu, josta voi olla valtava hyöty.

Resurssit

Koodi GitHubissa: https://github.com/isanosyan/toptal-blog-logs-post-example

Liite: Lokitiedostojen lukeminen ja käsittely Unix-kuoressa

Tässä on lyhyt esittely joihinkin yleisempiin * nix-komentorivityökaluihin, jotka haluat tuntea lokitiedostojen lukemiseen ja käsittelyyn.

  • awk on ehkä yksinkertaisin. Se tulostaa koko tiedoston lähtövirtaan. Esimerkiksi seuraava komento tulostaa cat konsoliin:

    logfile1

  • cat logfile1 -merkin avulla käyttäjä voi ohjata ulostuloa esimerkiksi toiseen tiedostoon. Avaa kohdevirran kirjoitustilassa (mikä tarkoittaa kohteen sisällön pyyhkimistä). Näin korvaamme > -sisällön sisällön kanssa tmpfile:

    logfile1

  • cat logfile1 > tmpfile ohjaa lähdön ja avaa kohdevirran liitetilassa. Kohdetiedoston nykyinen sisältö säilytetään, alaosaan lisätään uusia rivejä. Tämä lisää >> sisältö logfile1:

    tmpfile

  • cat logfile1 >> tmpfile suodattaa tiedoston joidenkin kuvioiden mukaan ja tulostaa vain vastaavat rivit. Alla oleva komento tulostaa vain grep -rivit sisältää logfile1 viesti:

    Bingo

  • grep Bingo logfile1 tulostaa yhden sarakkeen sisällön (numerolla alkaen 1). Oletusarvon mukaan hakee sarkaimen välisiä sarkainmerkkejä. Esimerkiksi, jos tiedosto on täynnä aikaleimoja muodossa cut, tämä antaa sinun tulostaa vain vuosia:

    YYYY-MM-DD HH:MM:SS

  • cut -d'-' -f1 logfile1 näyttää vain tiedoston ensimmäiset rivit

  • head näyttää vain tiedoston viimeiset rivit

  • tail lajittelee rivit ulostulossa

  • sort suodattaa päällekkäiset rivit

  • uniq laskee sanat (tai rivit, kun niitä käytetään wc lipun kanssa)

  • -l (ts. 'putki' -symboli) toimittaa yhden komennon lähdön seuraavaksi. Pipe on erittäin kätevä komentojen yhdistämiseen. Esimerkiksi näin voimme löytää kuukausia 2014, jotka tapahtuvat aikaleimojen joukossa:

    |

Tässä sovitetaan ensin linjat säännöllistä lauseketta vastaan ​​'alkaa vuodesta 2014', sitten leikataan kuukausia. Lopuksi käytämme grep -E '^2014' logfile1 | cut -d'-' -f2 | sort | uniq -yhdistelmää ja sort tulostaa esiintymät vain kerran.

Lisätty todellisuus vs. virtuaalitodellisuus vs. sekatodellisuus - johdanto-opas

Ux-Suunnittelu

Lisätty todellisuus vs. virtuaalitodellisuus vs. sekatodellisuus - johdanto-opas
Internetin saavutettavuus: Miksi W3C-standardeja ei oteta huomioon?

Internetin saavutettavuus: Miksi W3C-standardeja ei oteta huomioon?

Tietojenkäsittely Ja Tietokannat