Logging-ul (înregistrarea) și auditul (verificarea) sunt obligatorii pentru toate aplicațiile. Fără aceste informații, echipa de monitorizare și suport nu ar putea să știe dacă sistemul funcționează corect și să aniticipe anumite stări de fapt. În plus, din perspectiva siguranței, trebuie verificate la diferite niveluri ale sistemului cine vă accesează sistemul, care este acțiunea și când se manifestă ea.
Există multe soluții de-a gata pe piață, care ne ajută să facem logging și audit în sistemul nostru. Presupun că fiecare dintre noi am utilizat măcar o dată în viață log4net sau NLog. Sunt situații în care aveți nevoie de log-uri persistente în memorie, care nu se află pe același aparat pe care rulează sistemul vostru. De exemplu, un caz comun de utilizare poate fi scrierea tuturor acestor informații pe:
SQL instance,
Azure Blob Storage,
Dar v-ați întrebat vreodată ce se întâmplă când nu se poate ajunge la această memorie. Acest articol va analiza acest caz. Ce se întâmplă dacă memoria pe care sunt păstrate log-urile și auditul nu poate fi accesată?
Să ne imaginăm un sistem care scrie toate log-urile pe Azure Blob Storage iar informațiile de audit sunt trimise direct în Azure Event Hub, de unde sunt analizate în timp real, pentru a detecta problemele de securitate sau instabilitatea sistemului.
Pentru a reduce încărcătura din rețea, a îmbunătăți performanța (viteza) și a controla costurile, fiecare component are un buffer de unde sunt scrise log-urile și datele de audit. Odată ce un buffer a ajuns la o dimensiune specificată, conținutul este expediat în mod automat. Aceasta ar funcționa perfect atâta timp cât Azure Blob Storage (pentru loguri) și Azure Event Hub (pentru audit) sunt disponibile.
Observații: Vom continua cu situația în care utilizați log4net, dar menționăm că un comportament similar se manifestă și la alte framework-uri de logging.
Ce se întâmplă când una dintre aceste memorii nu poate fi accesată? Ce credeți? …
Buffer-ul va deveni din ce în ce mai mare. În mod normal, acest buffer este ținut în memorie, deoarece doriți să aveți latență scăzută pentru operațiile de scriere.
Veți începe să consumați din ce în ce mai multă memorie și există o mare probabilitate să sfârșiți prin a rămâne fără memorie, ceea ce nu doar vă va bloca componentele sau aplicația, dar vă va face să pierdeți și log-urile curente și datele de audit.
Pierderea acestor date nu vă va ajuta prea mult când veți avea nevoie să descoperiți de ce componenta sau aplicația nu funcționează sau de ce log-urile și datele de audit nu s-au păstrat.
Un alt lucru pe care trebuie să îl luăm în considerare este că atunci când scrii pentru o destinație diferită de cea default (în special locații externe), trebuie să te gândești la cum ar trebui să gestionezi această situație.
Există trei operații importante pe care ar trebui să le faceți:
Ar trebui să vă asigurați că toate excepțiile și comportamentele ciudate care apar la nivelul înregistrărilor de date sunt scrise în Event Logger. Scrierea excepțiilor în această locație vă va garanta faptul că puteți identifica orice tip de probleme ale mecanismului vostru de logging.
O altă posibilitate este să scrieți direct pe disc, ca fișiere, dar Event Logger este un instrument foarte puternic, iar echipa de monitorizare și suport poate strânge în mod automat toate log-urile evenimentelor, poate defini alerte pentru ele și așa mai departe.
Aceasta ar trebui să fie ultima voastră protecție când sistemul vostru de logging nu funcționează cum v-ați așteptat. Nu uitați să vă gândiți unde să înregistrați datele din momentul în care componenta sau aplicația voastră pornește până în momentul în care componenta voastră de logging este inițializată - ce se întâmplă dacă aceasta eșuează și cum puteți detecta asta. Acestea sunt două întrebări pe care ar trebui să vi le puneți.
În momentul în care mecanismul de logging vrea să facă o expediere, dar detectează că memoria îndepărtată nu poate fi accesată, ar trebui să fie declanșată o acțiune. O posibilitate ar fi să avem un mecanism care să încerce din nou să expedieze datele, dar:
Pentru cât timp?
Cât timp ar trebui să reîncercați? Nu există un răspuns de-a gata. Eu recomand să încercați numai de câteva ori și, după aceea, aveți nevoie de o soluție de rezervă. De exemplu, eu aș face trei încercări (1s, 2s și 4s). Dacă memoria de logging sau audit tot nu răspunde, atunci aș trece la soluția de rezervă, pe care o voi prezenta mai jos.
Nu puteți stoca date în buffer, deoarece buffer-ul vostru este deja plin. S-ar putea să fie posibil să faceți asta timp de câteva secunde sau minute, dar aceasta nu se poate realiza timp de o oră sau patru ore. În această situație, ar trebui să expediați toate datele pe care le aveți în buffer către discul vostru local.
În acest fel, vă veți curăța buffer-ul, iar noile înregistrări și date de audit pot fi păstrate fără a avea probleme cu cazul de utilizare excepție, în care ați rămas fără memorie. În plus, ar trebui să vă asigurați că, odată ce reușiți să scrieți log-uri sau audit pe sisteme de stocare externă - în cazul nostru a fost blob și event hub-, ar trebui să scrieți toate datele care au fost stocate în memoria locală pe memoria externă.
Cu această soluție, va trebui să luați în considerare cazul în care memoria externă nu funcționează o perioadă lungă de timp, iar voi veți rămâne fără spațiu în memoria voastră locală. Ar trebui să aveți un mecanism de curățare pentru aceste situații. Soluția cea mai simplă, care poate fi implementată cu succes, este ca toate înregistrările sau fișierele de audit mai vechi de X ore sau zile să fie șterse.
Utilizând un asemenea mecanism de curățare, spațiul local necesar sistemului vostru poate fi estimat ușor și nu vor mai exista cazurile speciale în care log-urile și fișierele de audit utilizează spațiul disponibil care ar trebui să fie folosit de către alte sisteme care rulează pe același aparat.
În comparație cu soluțiile anterioare, aceasta este o soluție opțională, care ar trebui utilizată numai atunci când este crucial să primiți log-uri sau date de audit într-un interval de timp anume. Această soluție vine cu costuri suplimentare și poate de asemenea să adauge puțină complexitate sistemului care procesează și analizează urmele log-urilor și auditului.
Această soluție nu le exclude pe cele dinainte, deoarece ambele tipuri de stocare, activă și pasivă, pot să nu funcționeze.
Această soluție implică utilizarea a două tipuri diferite de stocare: una activă, care este folosită tot timpul și una secundară, pasivă, care este folosită numai când prima nu este disponibilă.
În concluzie, vă recomand cu căldură să considerați acest caz, pentru întregul vostru sistem. Cel puțin, scrieți în Event Logger orice eroare sau comportament ciudat al mecanismului vostru de logging.