Dintr-o conversație între doi webmasteri:

– Ieri am fost pe site-ul tău...

- Deci tu ai fost!...

Cu exceptia statistici generale site-ul web (numărul de vizitatori unici, numărul de pagini web deschise etc.), mare importanță webmasterii au și alte informații, de exemplu: ce pagini ale site-ului sunt vizitate cel mai des, care interogări de căutare aduceți vizitatori pe site, ce browsere și sisteme de operare folosesc vizitatorii, ce rezoluție a ecranului folosesc vizitatorii etc. și așa mai departe.

De regulă, pe fiecare site web este instalat un contor extern gratuit (mai puțin plătit). Resursa care a furnizat contorul păstrează statistici extinse privind vizitele la resursă (inclusiv toate informațiile de mai sus), care pot fi vizualizate în orice moment. Este deosebit de convenabil să lucrezi cu astfel de contoare pentru cei care își găzduiesc site-urile online. gazduire platita.

Majoritatea furnizorilor de găzduire (hosteri) de găzduire plătită oferă clienților lor oportunitatea de a folosi instrumente de analiză deja instalate. De exemplu, pentru servere Apache program folosit frecvent Webalizer, care este setat ca modul suplimentar server web.

Cei care sunt găzduiți pe găzduire plătită pot procesa, de asemenea, toate informațiile despre vizitarea site-ului în mod independent: la urma urmei, webmasterul are acces complet la fișierele jurnal ale site-ului dvs.

Ce este un fișier jurnal al site-ului web

Fișierul jurnal al site-ului web ( fișier jurnal, Buturuga-file, log file, log) este un fișier text în care sunt înregistrate toate solicitările către site, precum și toate erorile asociate acestor solicitări.

Cum sunt înregistrate evenimentele în fișierul jurnal al site-ului

Prin urmare, unul dintre obiectivele principale ale creării unui site web ar trebui să fie nu doar creșterea numărului de vizite, ci o creștere relevante vizite – adică nu este nevoie să înșeli vizitatorii cu nume false, promisiuni, cuvinte cheie etc. – vizitatorul trebuie să găsească ceea ce caută, are dreptul să o facă!..

Note

1. Conform estimărilor companiei de cercetare netcraft, în iunie 2009, pe Internet existau 238.027.855 de site-uri web. În același timp, cota de servere web Apache a fost de aproximativ 47%, Microsoft IIS – 24,80%, qq.com – 12,79%, Google – 4,98%, nginx – 3,69%, Soare – 0,30%.

2. Fișierele jurnal ale serverului Apache

Subiectul poate fi banal, dar atunci când un program începe să funcționeze ceva greșit și, în general, se comportă foarte ciudat, de multe ori trebuie să citiți jurnalele. Și o mulțime de jurnale, mai ales dacă nu există nicio modalitate de a depana programul și nu puteți reproduce eroarea. Probabil că toată lumea și-a dezvoltat anumite reguli despre ce, cum și când să se înregistreze. Mai jos vreau să mă uit la câteva reguli pentru scrierea mesajelor în jurnal și va exista și o mică comparație a bibliotecilor de jurnal pentru limbi php, rubin și du-te. Colectatorii de bușteni și sistemele de livrare nu vor fi luate în considerare în mod conștient (au fost discutate deja de multe ori).

Există unul utilitar linux, și, de asemenea, part-time protocol de rețea numit syslog. Și există un întreg set de RFC-uri dedicate syslog-ului, unul dintre ele descrie nivelurile de înregistrare https://en.wikipedia.org/wiki/Syslog#Severity_level (https://tools.ietf.org/html/rfc5424). Conform rfc 5424, sunt definite 8 niveluri de înregistrare pentru syslog, pentru care scurta descriere. Aceste niveluri de înregistrare au fost adoptate de mulți loggeri populari pentru limbi diferite programare. De exemplu, http://www.php-fig.org/psr/psr-3/ definește aceleași 8 niveluri de înregistrare, iar loggerul standard Ruby folosește un set ușor redus de 5 niveluri. În ciuda indicației oficiale în care cazuri ar trebui utilizat unul sau altul nivel de jurnal, este adesea folosită o combinație precum debug/info/fatal - prima pentru înregistrare în jurnal în timpul dezvoltării și testării, al doilea și al treilea pentru producție. Apoi, la un moment dat, ceva de neînțeles începe să se întâmple în producție și dintr-o dată se dovedește că nu există suficiente jurnale de informații - rulăm pentru a activa depanarea. Și dacă nu încarcă puternic sistemul, ele rămân adesea pornite în mediul de producție. De fapt, mai sunt două scenarii când trebuie să aveți jurnalele:

• ceva se întâmplă și trebuie să știi ce
• ceva s-a rupt și trebuie să activați suplimentar declanșatorul

În limbajul Go, în care totul este simplificat la limită, loggerul standard a fost, de asemenea, rupt decent și au rămas următoarele opțiuni:

• Fatal - ieșire în jurnal și ieșire imediată în sistemul de operare.
• Panică - ieșire în jurnal și inițierea unei „panică” (analog cu o excepție)
• Imprimare - imprimă pur și simplu un mesaj în jurnal

Când scriu un program de la zero, folosesc adesea nivelul de depanare pentru înregistrarea peste tot, cu așteptarea ca în producție nivelul de înregistrare să fie setat la informații și, prin urmare, să reducă zgomotul mesajelor. Dar cu această abordare, apare adesea o situație în care dintr-o dată nu există destui bușteni. Este greu de ghicit de ce informații vei avea nevoie pentru a prinde un bug rar. Este posibil să utilizați întotdeauna în mod rațional nivelul de informații în mod implicit, iar în manipulatorii de erori nivelul de eroare și mai mare. Dar dacă aveți sute sau mai multe mesaje de jurnal pe secundă, atunci probabil că are sens reglaj finîntre info/debug. În astfel de situații, are sens să folosești soluții specializate pentru a nu risipi performanța.

Există, de asemenea, un punct subtil atunci când scrieți ceva de genul logger.debug(entity.values) - atunci dacă nivelul de înregistrare este setat mai mare decât debug, conținutul entity.values ​​nu va ajunge în jurnal, dar va fi calculat de fiecare dată, consumând resurse. În Ruby, puteți transmite un bloc de cod către logger în loc de un șir de mesaj: Logger.debug ( entity.values ​​​​) . În acest caz, calculele vor avea loc numai atunci când este setat nivelul de jurnal corespunzător. În limbajul Go, pentru a implementa evaluarea leneșă, puteți transmite un obiect care acceptă interfața Stringer către logger.

După ce v-ați dat seama de utilizarea nivelurilor de jurnal, mai trebuie să puteți conecta mesaje disparate, acest lucru este valabil mai ales pentru aplicații cu mai multe fire sau înrudite servicii individuale, când toate mesajele din jurnale sunt amestecate.

Formatul tipic al unei linii de mesaj dintr-un jurnal poate fi împărțit în următoarele componente:

+ +
Unde:

• informații de sistem: marca temporală, id-ul procesului, id-ul firului și alte informații despre serviciu
• mesaj: textul mesajului
• context: oricare Informații suplimentare, contextul poate fi comun mesajelor din cadrul unei anumite operațiuni.

Dar cu un singur context în cadrul unei cereri, apare o problemă cu diferite ORM-uri, clienți http sau alte servicii\biblioteci care își trăiesc propriile vieți. Și este, de asemenea, bine dacă oferă posibilitatea de a-și redefini loggerul standard cel puțin la nivel global, dar setarea contextului pentru logger în cadrul solicitării nu este adesea realistă. Această problemă relevante în principal pentru procesarea multi-threaded, atunci când un proces servește mai multe solicitări. Dar, de exemplu, în cadrul Rails există o integrare foarte strânsă între toate componentele și cererile ActiveRecord pot fi scrise în jurnal împreună cu contextul global pentru cererea curentă de rețea. Și în limbajul Go, unele biblioteci de înregistrare vă permit să creați dinamic un nou obiect de înregistrare cu contextul necesar, arată cam așa:

ReqLog:= log.WithField(„requestID”, requestID)
După aceasta, o astfel de instanță de înregistrare poate fi transmisă ca dependență altor obiecte. Dar lipsa unei interfețe de logare standardizate (de exemplu, cum ar fi psr-3 în PHP) îi determină pe creatorii de biblioteci să codifice implementările incompatibile de logger. Prin urmare, dacă vă scrieți biblioteca în Go și are o componentă de logare, nu uitați să furnizați o interfață pentru înlocuirea logger-ului cu una personalizată.

A rezuma:

• Logare excesiv. Nu știi niciodată dinainte cât și ce informații din jurnal vor fi necesare într-un moment critic.
• Opt niveluri de înregistrare - chiar ai nevoie de atât de mult? Pe baza experienței, un maxim de 3-4 ar trebui să fie suficient și numai dacă pentru ei sunt configurați handlere de evenimente.
• Ori de câte ori este posibil, utilizați evaluarea leneșă pentru a trimite mesaje în jurnal
• Adăugați întotdeauna contextul curent la fiecare mesaj de jurnal, cel puțin requestID.
• Dacă este posibil, configurați biblioteci terțe astfel încât acestea să utilizeze loggerul cu contextul de solicitare curent.

Dacă, ca răspuns la un eveniment, un program adaugă intrări într-un fișier, de obicei identificând evenimentul și sursa acestuia, atunci fișierul se numește fișier jurnal. Surse posibile evenimente:

• Rezultatul anumitor acțiuni ale utilizatorului.
• Întreruperile care vin în program de la echipament.
• Evenimente generate de programele în sine (de exemplu, obținute ca rezultat al calculelor).
• Evenimente generate erori de software(așa-numitele „excepții”).
• Evenimente din sistem de operare sau alt program, precum și evenimente care au orice altă sursă.

Intr-un cuvant, despre care vorbim despre schimbarea stărilor într-un program care rulează și rulează. Cea mai simplă opțiune fișier jurnal – un fișier text obișnuit cu intrări de rând. Toate informațiile din fișierele jurnal sunt înregistrate într-un format specific, ceea ce face posibilă înțelegerea ulterioară a motivelor apariției evenimentelor.

Unde sunt folosite fișierele jurnal?

Lista de utilizări pentru fișierele jurnal este uriașă. Fișiere de acest tip folosit oriunde este necesar pentru a trasa istoria a ceva proces software, păstrați o evidență a stării dispozitivelor și mașinilor, monitorizați acțiunile utilizatorului, incl. și în scopul asigurării siguranței. Și în multe alte cazuri. Pentru a căuta și analiza datele din fișierele jurnal, de regulă, se utilizează un software independent, care vă permite să studiați rapid și vizual datele de lucru înregistrate sistem software. Multe fișiere jurnal sunt foarte dimensiuni mari, așa că trebuie fie să suprascrieți în mod regulat conținutul lor învechit, fie să creați colecții întregi de fișiere jurnal cu nume, inclusiv, de exemplu, data. În multe cazuri, ei preferă să se ocupe de baze de date în loc de fișiere jurnal.

Exemple utile

Să dăm câteva exemple de utilizare a fișierelor jurnal. Dacă în programul depanat apar o mulțime de excepții neașteptate, atunci acestea pot fi înregistrate într-un fișier jurnal pentru analiza ulterioară a erorilor. Ca un alt exemplu, putem indica înregistrarea datelor despre utilizatorii conectați în sistemele client-server multi-utilizator. Acest lucru vă permite să urmăriți tranzacțiile neautorizate pe care le efectuează.

Concept

Jurnalele de server (fișiere jurnal, jurnal de server)- fișiere stocate pe server care conțin informatii despre sistem servere, precum și înregistrarea tuturor datelor posibile despre vizitatorul resursei web.

Jurnalele sunt folosite de administratorii de sistem pentru a analiza vizitatorii, studiind modele de comportament anumite grupuri utilizatorii, precum și primirea diverse informatii despre acestea, cum ar fi: browserul utilizat, adresa IP, date despre locația geografică a clientului și multe altele. Pe lângă analiză, în acest fel puteți afla despre acces neautorizat pe site, aflați mai precis de cine a fost produs și transferați date despre în acest caz, către autoritățile competente.

Datele din fișierul jurnal, în formă pură, nu va fi clar pentru utilizatorii obișnuiți, care vor vedea în toate acestea doar un set de personaje într-o ordine de neînțeles. Dar pentru administratorii de sistemși dezvoltatorii web, asta este destul de text lizibil, și destul Informatii utile.

De fiecare dată când un client accesează o resursă web, sunt declanșate simultan mai multe evenimente, despre a căror secvență vom vorbi.

1. Efectuarea unei cereri de pagină. Când introduceți o adresă în linia browserului sau când urmăriți un link web activ, de exemplu, dintr-o pagină rezultatele cautarii, browserul caută și se conectează la serverul pe care se află pagina și face o solicitare pentru aceasta. În același timp, transmite următoarele informații către server:
- adresa IP a computerului client care solicită pagina (dacă utilizați un server proxy, adresa IP a proxy-ului dvs.);
- adresa paginii de Internet solicitata de utilizator (adresa IP);
- timpul exactși data la care a fost făcută cererea;
- date despre locația reală a clientului (dacă se folosește un server proxy, atunci adresa proxy reală);
- informatii despre browserul utilizat de client (nume, versiune etc.);
- date despre pagina web de pe care clientul a transferat.

2. Transferul datelor solicitate. Datele solicitate (pagina web, fișiere, cookie-uri etc.) sunt transferate de pe server pe computerul utilizatorului.

3. Scrieți în jurnalul serverului. După toate, apare o intrare de jurnal, care indică toate datele care au apărut în ultimele două evenimente. Acestea sunt toate informațiile transmise în primul paragraf, precum și informații despre datele transmise.

Cum să vizualizați jurnalele serverului

Fișierele jurnal sunt stocate într-un fișier acces.log indiferent de tipul de server web pe care îl utilizați (Apache, Nginx, server proxy squid etc.) Acest fișier este document text, pe fiecare rând din care este scris o contestație. Formate de înregistrare în acces.log destul de mult, dar cel mai popular este combinat, în care intrarea are următoarea vedereși secvența:

Cod: %h %l %u %t \"%r\" %>s %b \"%(Referer)i\" \"%(User-Agent)i\"
Unde:

%h- gazda/adresa IP de la care a fost facuta cererea;
%t- ora solicitării către server și fusul orar al serverului;
%r- versiunea, continutul si tipul cererii;
%s- cod de stare HTTP;
%b- numărul de octeți trimiși de server;
%(Referer)- URL sursa cererii;
%(Agent utilizator)- Antet HTTP cu informații despre cerere ( aplicație client, limba etc.);
%(Gazdă)- numele gazdei virtuale care este accesată.

în formă finită linie dată arata cam asa:

127.0.0.1 - - "GET /index.php HTTP/1..0 (compatibil; MSIE 7.0; Windows NT 5.1)"

Citirea manuală a jurnalelor va necesita destul de mult timp și efort. Prin urmare, webmasterii experimentați folosesc un software special numit „Analizoare de fișiere jurnal”. Ei analizează toate datele, care este destul de dificil de citit de oameni, și produc date structurate. Acestea sunt programe precum: Analog, WebAnalizer, Webalizer, Awstats, Webtrends etc. Tipuri de special software destul de multe, printre ele sunt ca programe cu plată, și gratuit. Prin urmare, sunt sigur că fiecare va găsi ceva pe placul său.

Unde găsiți jurnalele site-ului

Daca ai gazduire regulata, atunci cel mai probabil va trebui să-i scrieți hoster-ului și să-i cereți jurnalele. De asemenea, destul de des, le puteți solicita prin intermediul panoului de găzduire. Diferiți hosteri o fac diferit. De exemplu, pentru a solicita de la hosterul meu, faceți clic pe pagina principala panouri:

Jurnal de erori error.log

Error.log- un fișier în care se păstrează și jurnalele. Dar nu vizitatori, ci erori care au apărut pe server. Așa cum este cazul cu acces.log, fiecare linie a fișierului este responsabilă pentru o eroare care a apărut. Înregistrarea se efectuează luând în considerare informații precum: data exactași ora în care a apărut eroarea, adresa IP la care a fost emisă eroarea, tipul de eroare, precum și motivul apariției acesteia.

Concluzie

Jurnalele sunt un instrument destul de puternic și informativ cu care să lucrați. Dar în zilele noastre, acestea sunt înlocuite cu instrumente precum Yandex.Metrica, Google Analytics etc., simplificându-ne astfel viața. Cu toate acestea, dacă intenționați să vă dezvoltați, să creșteți și să învățați ceva nou, vă recomand cu siguranță să cunoașteți mai bine acest subiect.

ACȚIUNE

TWEETĂ

Fără titlu

Un invitat 16 ianuarie 2017 335 Niciodată

Ce este jurnalul de joc?=

„Jurnal” este un fișier care conține o listă detaliată a evenimentelor din aplicații, performanța sistemului sau acțiunile utilizatorului ordine cronologica. Jurnalul sau jurnalele pot fi utile pentru identificarea erorilor din joc. În rezervoarele X sunt stocate busteni dosar special numit „output_log”. Pentru a vizualiza jurnalul, trebuie să mergeți în folderul jocului, apoi în folderul „tankix_Data”.

Cum se oferă jurnalul de joc?=

Dacă aveți probleme cu jocul, blocări frecvente, întârzieri etc., atunci dezvoltatorii vă pot cere să le furnizați jurnalele de joc. Cum să o facă:

*În folderul jocului tankix_data există un fișier output_log.txt

*Salvați fișierul în orice moment Stocare in cloud(Yandex.Disk, documente Google, Dropbox, unde puteți vizualiza fișierul fără a-l descărca). Sau puteți copia conținutul fișierului și îl puteți posta pe resursa http://site/

*Crea subiect nou pe site-ul http://echo.tankix.com/ (sau adăugați jurnalul dvs. la subiectul unui alt jucător cu o problemă identică) împreună cu descriere detaliata Probleme.

Principalul lucru este să nu reporniți clientul după ce apare eroarea, altfel jurnalele vor fi șterse.

RAW Paste Data

Ce este un jurnal de joc?= „„Jurnal”” este un fișier care conține o listă detaliată a evenimentelor din aplicații, performanța sistemului sau acțiunile utilizatorului, în ordine cronologică. Jurnalul sau jurnalele pot fi utile pentru identificarea erorilor din joc. Jurnalele pentru Tanks X sunt stocate într-un fișier special numit „output_log”. Pentru a vizualiza jurnalul, trebuie să mergeți în folderul jocului, apoi în folderul „tankix_Data”. =Cum se oferă un jurnal de joc?= Dacă aveți probleme cu jocul, blocări frecvente, întârzieri și așa mai departe, atunci dezvoltatorii vă pot cere să le furnizați jurnalele de joc. Cum se face asta: *În folderul jocului tankix_data există un fișier output_log.txt *Salvați fișierul în orice spațiu de stocare în cloud (Yandex.Disk, Google Docs, Dropbox, unde puteți vizualiza fișierul fără a-l descărca)..tankix. com/ (sau adăugați jurnalul dvs. la subiectul unui alt jucător cu o problemă identică) împreună cu o descriere detaliată a problemei. Principalul lucru este să nu reporniți clientul după ce apare eroarea, altfel jurnalele vor fi șterse.