Astăzi revenim cu un articol din domeniul IT și vom încerca să vorbim puțin despre jurnalele (sau log-urile) unei aplicații web / desktop / mobile. Sunt ele utile în viața unui programator?
Răspunsul, pe scurt, este că sunt foarte utile. Dar, de ce sunt importante jurnalele unei aplicații? De ce log-urile ne ajută? Pentru că programatorii sunt și ei oameni și mai greșesc. Nimeni nu scrie cod perfect, fără defecte sau regresii. Bug-urile sunt la ordinea zilei. Ca și o mică paranteză, o să scriu puțin despre buguri și de ce apar ele, într-un articol separat. Nu de alta, dar e mult de povestit…
Revenim. Ce vei face atunci când ai un bug și îl descoperi fix în producție? Ca și programator, vei încerca să îl înțelegi, să îl reproduci în non-prod și de ce mai multe ori să îl fixezi. Asta, dacă nu cedezi nervos și îl pasezi mai departe unui alt coleg din echipa :D. Cu alte cuvinte, începi să investighezi problema. În acest moment, de entuziasm maxim, îți dai seama cât de utile sau inutile sunt logurile, care ce să vezi, tot tu le-ai implementat?! Ăsta e momentul în care îți dai seama, că anumite lucruri lipsesc și investigația ta va avea de suferit. E momentul ăla în care te apuci și mai deschizi un tichet în JIRA: “Improve monitoring”. Nu vă speriați, mi se îmtâmplă și mie…
Având în vedere toate aceste observații, ce e de făcut? Va trebui să ne asigurăm că înainte de a livra ceva în producție, avem toate log-urile necesare in place. Cu alte cuvinte, orice s-ar întâmpla pe planeta numită Producție, noi vom fi capabili să descifrăm usecase-ul și să nu ne mai surprindă nimic. Bineînțeles, aceste lucruri sunt ideale.
Acum, dacă folosești Java în viața ta de programator, poți folosi Logback ca și framework de logging. Cu ajutorul unui simplu fișier de configurare, scris în format XML, vei putea configura framework-ul să funcționeze așa cum îți dorești. Dar de ce trebuie să ții musai cont atunci când îl configurezi?
- Este indicat să loghezi totul asincron, mai ales dacă lucrezi la o aplicație pentru care performanța este un aspect de luat un calcul. Atenție: atunci când loghezi asincron, este recomandat să ai și un field timestamp ce te va ajuta să identifici exact momentul în care aplicația a generat evenimentul respectiv! Un bun exemplu poți găsi aici.
- Folosește mai multe nivele de logging. Nu loga totul pe info! Într-adevăr nu e bine să ai prea puține loguri, dar nici prea multe pentru că va îngreuna foarte mult investigația. În plus, dacă vei genera câte 1 MB de date pentru fiecare acțiune pe care aplicația o va face, s-ar putea să te trezești că spațiul pe disk nu va mai ajunge…
- Nu scrie toate logurile într-un singur fișier. Cel mai bine este să ai un fișier pe zi. În acest fel, dacă mâine dimineața vei afla că în seara aceasta a fost o problemă, vei căuta fix în fișierul în care trebuie. Punct ochit, punct lovit. Iată și un exemplu.
- Apoi, dacă vei avea un fișier diferit pentru fiecare zi în parte, vei putea să mai faci ceva interesant. Vei putea arhiva acel fișier. De obicei, în aceste tipuri de fișiere, compresia funcționează foarte bine, un fișier de 1 GB (plain text), putând să fie redus la doar câțiva MB pentru că conține foarte multe date duplicate. În acest fel, vei reduce costul cu infrastructura pentru că vei reduce spațiul necesar pe disk. Un simplu exemplu vei găsi aici.
- Asigură-te că ai un mecanism de rolling in place. Ce înseamna asta? Este indicat să păstrezi doar log-urile din ultimile X zile, unde X poste să fie de exemplu 30. Ține cont de acest lucru, dacă nu vrei ca după 6 luni de producție să nu te trezești cu “No more free space”. Iată și un exemplu.
Cam atât pentru astăzi. Promit să revin și cu câteva sfaturi mai funcționale despre ce ar trebui să loghezi și ce nu ar trebui să loghezi și bineînțeles pe ce nivele. Până atunci, lasă-mi comentariul tău dacă informația prezentată a fost utilă pentru tine.
