La noi la Veeam ne plac jurnalele. Și deoarece majoritatea soluțiilor noastre sunt modulare, acestea generează un număr considerabil de jurnale. Având în vedere că domeniul nostru de activitate este asigurarea siguranței datelor dumneavoastră (adică un somn liniștit), jurnalele trebuie nu doar să înregistreze fiecare mic detaliu, ci și să o facă într-un mod destul de detaliat. Este necesar pentru a înțelege ce s-a întâmplat în cazul unei probleme, cine este de vină și ce trebuie să facem în continuare. Aici este ca în criminalistică: niciodată nu știi ce detaliu te va ajuta să găsești criminalul.
Așadar, am decis să mă apuc de o serie de articole în care voi relata în mod secvențial ce anume scriem în jurnale, unde le stocăm, cum să nu înnebunim din cauza structurii lor și ce trebuie să căutăm în interiorul lor.
De ce o serie de articole și de ce să nu descriu totul deodată?
Pur și simplu să enumeri fiecare jurnal și ce conține acesta este o idee destul de grea. Iar a menține aceste informații actualizate este cu adevărat o provocare. O simplă enumerare a tuturor tipurilor posibile de jurnale în Veeam Backup & Replication ar rezulta într-un tabel de câteva pagini cu caractere mici. De asemenea, aceasta va fi valabilă doar la momentul publicării, deoarece cu fiecare patch nou pot apărea jurnale noi, poate că se va schimba logica informațiilor stocate în cele vechi etc. Așadar, este mult mai benefic să explicăm structura acestora și esența informațiilor conținute. Aceasta va permite o mai bună orientare decât o simplă memorare a denumirilor.
Prin urmare, pentru a nu ne arunca direct în abisul textelor, haideți să facem într-o oarecare măsură o pregătire. Așadar, în acest articol nu ne vom ocupa de jurnalele în sine, ci vom lua un drum mai lung: vom elabora un glosar și vom discuta puțin despre structura Veeam din perspectiva generării jurnale.
Glosar și jargon
Aici, în primul rând, trebuie să-mi cer scuze în fața susținătorilor purității limbii române și a martorilor dicționarului lui Ojelov. Cu toții iubim foarte mult limba noastră maternă, dar marea industrie IT funcționează în engleză. Ei bine, nu noi am inventat asta, așa s-a întâmplat istoric. Nu mi-e vină, a venit de la sine (c)
În domeniul nostru, problema anglicismelor (și a jargonului) are specificitățile sale. Când cuvinte aparent nevinovate precum „host” sau „guest” sunt deja înțelese în întreaga lume în moduri foarte concrete, în ⅙ din lume continuă o eroică confuzie și ezitare prin consultarea dicționarelor. Și argumentul strict obligatoriu „Dar la noi la muncă…” este mereu invocat.
În plus, există o terminologie specifică, care aparține în mod special produselor Veeam, deși unele cuvinte și expresii au ajuns să fie utilizate pe scară largă. Prin urmare, acum vom conveni asupra semnificației fiecărui termen, iar în continuare, când mă refer la „guest”, voi avea în vedere exact ceea ce este scris în acest capitol, nu ceea ce ați obșinuit voi în cadrul muncii voastre. Și da, aceasta nu este o preferință personală, ci termeni consacrați în industrie. A lupta cu aceștia este oarecum lipsit de sens. Totuși, sunt mereu pentru un schimb de opinii în comentarii.
Din păcate, termenii din munca noastră și produsele sunt extrem de mulți, așa că nu voi încerca să îi enumăr pe toți. Doar cei mai de bază și necesari pentru a supraviețui în marea de informații despre backupuri și loguri. Pentru cei interesați, pot de asemenea de la colegii mei despre benzile de backup, unde a fost inclusă o listă de termeni corelati cu acea parte a funcționalității.
Host (Host): În lumea virtualizării, acesta este un sistem cu hipervizor. Fie că este fizic, virtual sau cloud — nu contează. Dacă pe ceva este pornit un hipervizor (ESXi, Hyper-V, KVM etc.), atunci acel „ceva” se numește host. Fie că este un cluster de zece rack-uri sau laptopul tău cu o laboratorie de o jumătate de virtuale — dacă ai pornit hipervizorul, atunci ai devenit host. Pentru că hipervizorul găzduiește mașini virtuale. Există chiar o legendă cum că VMware voia odată să obțină o asociere fermă a cuvântului host cu ESXi. Dar nu a reușit.
În lumea modernă, conceptul de „host” s-a confundat practic cu cel de „server”, ceea ce introduce o anumită confuzie în comunicare, mai ales când vine vorba despre infrastructura Windows. Așadar, orice sistem pe care se află un serviciu de interes poate fi numit cu ușurință host. De exemplu, în logurile WinSock, cuvântul host este folosit pentru a marca totul. Clasicul „Host not found” este un exemplu. Așadar, ne bazăm pe context, dar ținem minte — în lumea virtualizării, host-ul este ceea ce găzduiește guest-urile (despre aceasta urmează să discutăm în câteva rânduri mai jos).
Din jargonuri locale (mai degrabă acronime în acest caz) îmi amintesc că VMware este VI, vSphere este VC, iar Hyper-V este HV.
Guest (Gazdă): O mașină virtuală care funcționează pe un host. Aici nu este nevoie de explicații, totul este atât de logic și simplu. Totuși, mulți se străduiesc să aducă aici alte înțelesuri.
De ce? Nu știu.
Guest OS, prin urmare, sistemul de operare al mașinii gazdă. Și așa mai departe.
Backup/Replication Job (job-ul de Back-up): Pur și simplu un jargon VMware, care se referă la o sarcină specifică. Backup job == Job de Backup. Nimeni nu a găsit o modalitate frumoasă de a traduce acest termen în română, așa că toată lumea spune „job”. Cu accent pe ultima silabă.
Da, așa pur și simplu spun „job”. Și chiar așa scriu în e-mailuri, și este în regulă.
Fel de lucrări de Backup, Sarcini de Backup etc., mulțumesc, dar nu este nevoie. Doar job, și vă vor înțelege. Ceea ce contează este să puneți accentul pe ultima silabă.
Backup (Back-up, bекап. Pentru adevărații vechi se acceptă și backup): Pe lângă sensul evident (o copie de rezervă a datelor care se află undeva), se referă și la job-ul în sine (cele trei rânduri de mai sus, în cazul în care ați uitat), din care se creează acel fișier de backup. Probabil, domnii vorbitori de engleză sunt prea lenți pentru a spune de fiecare dată I ran my backup job, așa că spun pur și simplu I ran my backup, și toată lumea se înțelege perfect. Propun să susținem această inițiativă minunată.
Consolidate (Consolidare): Termen apărut în ESXi 5.0 Opțiune din meniul de lucru cu snapshot-uri, care declanșează procesul de ștergere a așa-numitelor snapshot-uri orphaned. Adică snapshot-uri care există fizic, dar care au ieșit din structura logică afișată. Teoretic, acest proces nu ar trebui să afecteze fișierele afișate în managerul de snapshot-uri, dar se întâmplă de toate. Esența procesului de consolidare este că datele din snapshot (child disk) sunt scrise pe discul principal (parent disk). Procesul de unire a discurilor se numește m mergere (merge). Dacă a fost dată comanda de consolidare, atunci înregistrarea snapshot-ului poate fi ștearsă din bază mai devreme decât snapshot-ul este îmbinat și șters. Și dacă snapshot-ul nu a putut fi șters din orice motiv, atunci apar aceste așa-numite snapshot-uri orphaned. Despre lucrul cu snapshot-uri, VMware are . Și noi de asemenea am scris despre ele .
Datastore (Stora sau stocare): Un concept foarte larg, dar în lumea virtualizării se referă la locul unde sunt stocate fișierele mașinilor virtuale. În orice caz, este foarte important să înțelegem contextul și, în cazul celor mai mici îndoieli, să clarificăm ce a vrut să spună interlocutorul dumneavoastră.
Proxy (Punct de acces): Este important să înțelegem de la început că Veeam Proxy nu este exact același lucru cu ceea ce suntem obișnuiți pe câmpurile internetului. În cadrul produselor Veeam, aceasta este o entitate care se ocupă de transferul de date dintr-un loc în altul. Fără a intra în detalii, VBR este serverul de comandă, iar proxy-ul sunt muncitorii săi. Așadar, proxy-ul este mașina prin care trece traficul și pe care sunt instalate componentele VBR, care ajută să gestionăm acest trafic. De exemplu, transferând date dintr-un canal în altul sau pur și simplu conectându-ne la discuri (modul HotAdd).
Repository (Depozit): Tehnic, este pur și simplu o înregistrare în baza de date VBR, care indică locul unde sunt stocate backup-urile și cum să ne conectăm la acest loc. În practică, acest lucru poate fi atât o simplă partajare CIFS, cât și un disc separat, un server sau un bucket în cloud. Din nou, ne aflăm în context, dar înțelegem că depozitul este doar locul unde stochezi backup-urile tale.
Snapshot (Instantaneu): Cei care iubesc gramatica oxfordiană preferă să zică cine este snÉpșot, cine este snEпșot, însă majoritatea care nu respectă regulile gramaticale câștigă datorită masei mai mari. Dacă cineva nu știe — aceasta este o tehnologie care permite restaurarea stării unui disc într-un moment specific. Acest lucru se face fie prin redirecționarea temporară a operațiunilor I/O de la discurile principale — atunci se va numi instantaneu RoW (Redirect on Write) — fie prin mutarea blocurilor care sunt suprascrise de pe discul dumneavoastră pe altul — acesta va fi numit instantaneu CoW (Copy on Write). Datorită posibilităților largi de aplicare a acestor funcții, Veeam poate realiza magia backup-urilor sale. Stricte, nu doar pentru el, dar aceasta este o chestiune pentru versiunile viitoare.
În documentația și jurnalele ESXi există o confuzie în jurul acestui termen, iar în contextul menționării snapshot-urilor, putem întâlni atât snapshot-urile, cât și redo log-ul și chiar delta disk-ul. În documentația Veeam nu există această confuzie, iar snapshot-ul este un snapshot, iar redo log-ul este fișierul REDO, creat de un disc non-persistent independent. Fișierele REDO sunt șterse la oprirea virtual machine-ului, așa că a le confunda cu snapshot-urile este drumul către eșec.
Synthetic (Sintetic): Backup-urile sintetice se referă la backup-urile reverse incremental și forever forward. Dacă nu ați întâlnit vreodată acest termen, este pur și simplu unul dintre mecanismele utilizate pentru construirea transformării lanțului de backup. Totuși, în jurnale poate fi întâlnită și noțiunea de Transform, care este utilizată în cadrul creării de copii complete din incremente (sintetice complete).
Task (Taskă): Este procesul de prelucrare a fiecărei mașini în cadrul unui job. Asta înseamnă: ai un job de backup care include trei mașini. Așadar, fiecare mașină va fi procesată într-o taskă separată. În total, vor fi patru jurnale: unul principal pentru job și trei pentru task-uri. Cu toate acestea, există o nuanță importantă: de-a lungul timpului, cuvântul „taskă” a devenit excesiv de ambiguu. Când vorbim despre jurnale generale, ne referim la faptul că taska este, de fapt, VM. Dar există și „task-uri” pe proxy și pe repository. Acolo poate însemna fie un disc virtual, fie o mașină virtuală, fie întregul job. Este important să nu pierdem contextul.
Veeam %name% Service (Serviciul): Pentru succesul backup-urilor contribuie mai multe servicii, lista cărora poate fi găsită în instrumentul standard. Numele lor reflectă destul de clar esența acestora, totuși printre ele există cel mai important — Veeam Backup Service, fără de care celelalte nu vor funcționa.
VSS: Tehnic, VSS ar trebui să desemneze întotdeauna Microsoft Volume Shadow Copy Service. Este folosit, de fapt, de mulți ca sinonim pentru Application-Aware Image Processing. Ceea ce, desigur, este categoric greșit, dar asta este o poveste de genul „Orice SUV poate fi numit Jeep și te vor înțelege”.
Jurnale fantastice și locurile în care acestea trăiesc
Vreau să încep acest capitol prin a dezvălui o mare taină — ce oră este afișată în jurnale?
Rețineți:
- ESXi scrie întotdeauna jurnalele în UTC+0.
- vCenter își ține jurnalele conform fusului său orar.
- Veeam își ține jurnalele conform timpului și fusului orar al serverului pe care rulează.
- Și doar evenimentele Windows în format EVTX nu sunt legate de nimic. La deschidere, timpul se recalibrează pentru mașina pe care sunt deschise. Este cea mai convenabilă opțiune, deși uneori pot apărea dificultăți și cu aceasta. Singura dificultate semnificativă este diferența de locale. Acesta este aproape un drum garantat către jurnale ilizibile. Da, există variante pentru a remedia acest lucru, dar să nu discutăm despre faptul că totul în IT funcționează în engleză și să ne înțelegem să setăm întotdeauna serverele pe locale în engleză. Te rog.
Acum să discutăm despre locurile unde se află jurnalele și cum le putem obține. În cazul VBR există două abordări.
Prima opțiune se potrivește dacă nu ești dornic să cauți în marea de fișiere, cele care se leagă de problema ta. Pentru asta avem un wizard separat, căruia îi poți indica un anumit job și o anumită perioadă pentru care ai nevoie de jurnale. Apoi, acesta va căuta prin foldere și va strânge tot necesarul într-un singur arhiv. Despre unde să îl găsești și cum să lucrezi cu el este descris detaliat în .
Totuși, wizardul nu adună jurnalele tuturor sarcinilor și, de exemplu, în cazul în care trebuie să studiezi jurnalele restaurantului, failover-ului sau failback-ului, drumul tău se îndreaptă către folderul %ProgramData%/Veeam/Backup. Acesta este principalul depozit de jurnale VBR, iar %ProgramData% este un folder ascuns și este normal. Apropo, locația implicită poate fi realocată printr-o cheie de registru de tip REG_SZ: LogDirectory în ramura HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication.
Pe mașinile Linux, jurnalele agenților de lucru trebuie căutate în /var/log/VeeamBackup/, dacă se folosește un cont root sau sudo. Dacă nu ai astfel de privilegii, caută jurnalele în /tmp/VeeamBackup.
Pentru Veeam agent for %OS_name% jurnalele trebuie căutate în %ProgramData%/Veeam/Endpoint (sau %ProgramData%/Veeam/Backup/Endpoint) și /var/log/veeam corespunzător.
Dacă folosești Application-Aware Image Processing (și cel mai probabil îl folosești), atunci situația se complică puțin. Vei avea nevoie de jurnalele helper-ului nostru, care sunt stocate în interiorul mașinii virtuale, și jurnalele VSS. Despre cum și unde să obții aceste informații, este detaliat descris în . Și, bineînțeles, există pentru adunarea jurnalele sistemului necesare.
Evenimentele Windows sunt convenabil de adunat conform . Dacă folosești Hyper-V, lucrurile se complică, deoarece vei avea nevoie și de toate jurnalele sale din ramura Applications and Service Logs > Microsoft > Windows. Deși întotdeauna poți merge pe un drum mai direct și pur și simplu să iei toate obiectele din %SystemRoot%System32winevtLogs.
Dacă aveți o problemă în timpul instalării/upgrade-ului, tot ce aveți nevoie poate fi găsit în folderul %ProgramData%/Veeam/Setup/Temp. Deși nu voi ascunde că în evenimentele OS-ului se poate găsi informații mai utile decât în aceste jurnale. Ceva interesant se află în %Temp%, dar acolo sunt în principal jurnale de instalare pentru software-urile auxiliare, cum ar fi baza de date, bibliotecile .Net și altele. Rețineți că Veeam este instalat dintr-un fișier msi, iar toate componentele sale sunt, de asemenea, instalate ca pachete msi separate, chiar dacă acest lucru nu a fost afișat în GUI. Prin urmare, dacă instalarea uneia dintre componente eșuează, întreaga instalare VBR va fi oprită. Așa că trebuie să mergeți în jurnale și să verificați ce anume s-a stricat și în ce moment.
Și un truc de final: dacă primiți o eroare la instalare, nu vă grăbiți să apăsați OK. Mai întâi, salvați jurnalele, apoi apăsați OK. Astfel veți obține un jurnal care se termină la momentul erorii, fără mizerie la sfârșit.
Și se întâmplă uneori să fie nevoie să căutăm în jurnalele vSphere. Este o activitate foarte neplăcută, dar, cu mânecile suflecate, trebuie să facem și asta. În varianta cea mai simplă, ne vor trebui jurnalele cu evenimentele virtualului vmware.log, care se află lângă fișierul său .vmx. Într-un caz mai complicat, deschidem Google și întrebăm unde se află jurnalele pentru versiunea dvs. de host, deoarece VMware adoră să schimbe această locație de la o versiune la alta. Iată, de exemplu, , iar acesta este pentru . Pentru jurnalele vCenter repetăm procedura . Dar, în general, ne vor interesa jurnalele de evenimente ale hostului hostd.log, evenimentele hosturilor gestionate de vCenter vpxa.log, jurnalele nucleului vmkernel.log și jurnalele de autentificare auth.log. Și în cele mai avansate cazuri, jurnalul SSO, care se află în folderul SSO, poate fi util.
Complicat? Confuz? Înfricoșător? Dar aceasta nu este nici măcar jumătate din informațiile cu care suportul nostru lucrează zilnic. Așa că sunt cu adevărat foarte buni.
Componentele Veeam
Și ca o concluzie a acestui articol introductiv, să discutăm puțin despre componentele Veeam Backup & Replication. Pentru că atunci când cauți cauza durerilor, ar fi bine să înțelegi cum este construit pacientul.
Astfel, așa cum se știe, Veeam Backup este o aplicație bazată pe SQL. Cu alte cuvinte, toate setările, informațiile și tot ceea ce este necesar pentru funcționarea normală se găsesc în baza sa de date. Mai precis, în două baze, dacă vorbim despre legătura VBR și EM: VeeamBackup și VeeamBackupReporting, respectiv. Așa a fost stabilit: instalăm o altă aplicație — apare o altă bază. Pentru a nu depozita toate ouăle într-un singur cofraj.
Dar pentru ca tot acest sistem să funcționeze armonios, avem nevoie de un set de servicii și aplicații care să lege toate componentele împreună. Exclusiv ca exemplu, iată cum arată în una dintre laboratoarele mele:
În rolul principalului dirijor se află Veeam Backup Service. Acesta este responsabil pentru schimbul de informații cu bazele de date. De asemenea, se ocupă cu lansarea tuturor sarcinilor, se ocupă de orchestrarea resurselor alocate și funcționează ca un centru de comunicații pentru diverse console, agenți și tot ce este necesar. Cu alte cuvinte, fără el nu se poate, dar asta nu înseamnă că el face totul singur.
În realizarea celor planificate, el este ajutat de Veeam Backup Manager. Acesta nu este un serviciu, ci o entitate care se ocupă cu lansarea joburilor și monitorizarea procesului lor de realizare. Mâinile de lucru ale backup service-ului, care se conectează la gazde, creează snapshot-uri, monitorizează retenția și multe altele.
Dar să ne întoarcem la lista serviciilor. Veeam Broker Service. A apărut în v9.5 (și nu este un miner de criptomonede, așa cum au crezut atunci unii). Se ocupă cu colectarea informațiilor despre gazdele VMware și menținerea lor actualizate. Dar nu vă grăbiți să scrieți comentarii furioase că noi vă spionăm și vă furăm toate loginurile/parolele către tașmaior. Totul este un pic mai simplu. Când lansați un backup, mai întâi trebuie să vă conectați la gazdă și să actualizați toate datele despre structura acesteia. Este o poveste destul de lentă și complicată. Doar amintiți-vă cât durează operațiunea de login prin interfața web și amintiți-vă că acolo se consideră doar stratul superior. Apoi, mai trebuie să desfășurați întreaga ierarhie până la locul dorit, de altfel. Cu alte cuvinte, este groaznic. Dacă lansați o duzină de backupuri, atunci fiecare job trebuie să treacă prin această procedură. Dacă este vorba despre infrastructuri mari, atunci acest proces poate dura zece minute sau mai mult. De aceea s-a luat decizia de a crea un serviciu separat pentru acest lucru, prin care se va putea obține întotdeauna informații actualizate. Acesta, la start, verifică și scanează întreaga infrastructură adăugată și apoi încearcă să opereze doar la nivelul modificărilor incrementale. Așa că, chiar dacă aveți o sută de backupuri care se lansează simultan, toate vor solicita informații de la brokerul nostru, în loc să tortureze gazdele cu cererile lor. Dacă sunteți îngrijorați pentru resurse, conform calculelor noastre, pentru 5000 de virtualizări sunt necesari doar aproximativ 100 Mb de memorie.
Următorul este Veeam Console. De asemenea, Veeam Remote Console, cunoscut și sub numele de Veeam.Backup.Shell. Este interfața GUI pe care o vedem în capturi de ecran. Totul este simplu și evident — consola poate fi lansată de oriunde, atâta timp cât este Windows și există conectivitate la serverul VBR. Singurul lucru pe care îl pot spune: procesul FLR va monta punctele local (adică pe mașina pe care este lansată consola). Iar diversele Veeam Explorers vor fi, de asemenea, lansate local, deoarece sunt parte din consolă. Dar asta mă duce deja în detalii...
Următorul serviciu interesant este Veeam Backup Catalog Data Service. În lista serviciilor este cunoscut ca Veeam Guest Catalog Service. Acesta se ocupă cu indexarea sistemelor de fișiere de pe mașinile gazdă și completează cu aceste informații folderul VBRCatalog. Este utilizat doar acolo unde este activată opțiunea de indexare. Aceasta ar trebui activată doar dacă aveți Enterprise Manager. Așadar, un sfat prietenesc: nu activați indexarea fără motiv, dacă nu aveți EM. Protejați-vă nervii și timpul echipei de suport.
De asemenea, din alte servicii importante merită menționate Veeam Installer Service, prin intermediul căruia se realizează livrarea și instalarea componentelor necesare pe proxy, repozitorii și alte gateway-uri. Practic, acesta transportă pachetele necesare .msi pe servere și le instalează.
Veeam Data Mover — prin intermediul agenților auxiliari rulați pe proxy-uri (și nu numai) se ocupă de transferul datelor. De exemplu, în timpul backup-ului un agent va citi fișier despre datastorul gazdei, iar al doilea va scrie cu atenție în backup.
Este important să subliniem un aspect pe care clienții îl observă adesea — diferența de versiuni ale serviciilor și informațiile din instrumentul Programs and Features. Da, lista va fi identică, dar versiunile pot fi complet diferite. Aceasta nu este foarte plăcut din punct de vedere vizual, dar este complet normal dacă totul funcționează stabil. De exemplu, la serviciul Installer, numărul versiunii este mult în urma celor adiacente. E un coșmar? Nu, deoarece acesta nu este reinstalat complet, ci pur și simplu DLL-ul său este actualizat. În patch-ul v9.5 U4 a apărut cosmarul echipei de suport: la actualizare toate serviciile au primit versiuni noi, cu excepția celui mai important. În patch-ul U4b, serviciul de transport a depășit toate celelalte cu două versiuni (dacă ne raportăm la numere). Și asta este de asemenea normal — în el a fost descoperită o eroare serioasă, așa că a primit o actualizare bonus în raport cu celelalte. Așadar, concluzionând: diferența de versiuni poate fi o problemă, dar dacă există o diferență și totul funcționează corespunzător, atunci cel mai probabil așa și trebuie. Dar nimeni nu vă împiedică să clarificați acest lucru cu suportul tehnic.
Acestea au fost așa-numitele servicii obligatorii sau Mandatory services. Există și o întreagă serie de servicii auxiliare, precum Tape Service, Mount Service, vPowerNFS Service și așa mai departe.
Pentru Hyper-V, în general, este la fel, doar că există un Veeam Backup Hyper-V Integration Service și un driver specific pentru a lucra cu CBT.
Și la final, vom discuta cine lucrează pe mașinile virtuale în timpul backup-ului. Pentru a rula scripturi pre- și post-freeze, pentru a crea copii shadow, a colecta metadate, a lucra cu jurnalele de tranzacții SQL și altele, se folosește Veeam Guest Helper. Și dacă se face indexarea sistemelor de fișiere, Veeam Guest Indexer . Acestea sunt servicii temporare, desfășurate pe durata backup-ului și eliminate după aceasta.
În cazul mașinilor Linux, totul este mult mai simplu datorită numeroaselor biblioteci încorporate și capacităților sistemului. De exemplu, indexarea se face prin mlocate.
Asta e tot deocamdată
Nu mă îndoiesc că vă voi mai răni și o scurtă introducere în spațiul sub capotă al Veeam este considerată încheiată. Da, nici măcar nu ne-am apropiat de jurnalele propriu-zise, dar credeți-mă, pentru ca informațiile prezentate în ele să nu pară un flux de conștiință nestructurat, o astfel de introducere este cu siguranță necesară. Planific să trec la jurnale în articolul trei, iar planul pentru următorul este să explic cine generează jurnalele, ce anume este afișat în ele și de ce anume așa și nu altfel.
Sursa: habr.com
