Vazhdojmë zhytjen tonë në botën e fascinante të troubleshooting përmes log-eve. Në ne u dakorduam për kuptimin e termave bazikë dhe shikuam me një sy strukturën e përgjithshme të Veeam, si një aplikacion të vetëm. Detyra për këtë — të merremi me mënyrën se si formohen skedarët e log-ut, çfarë informacioni është në to dhe pse ato duken si duken.
Çfarë mendoni, çfarë janë këto «log-e»? Sipas shumicës, logëve të çdo aplikacioni duhet t'u jepet roli i një entiteti të gjithëfuqishëm, i cili shumicën e kohës ndodhet diku në prapavijë, por në momentin e duhur shfaqet nga askund me armaturë të ndritshme dhe shpëton të gjithë. Do thotë se në to duhet të jetë gjithçka, duke filluar nga gabimet më të vogla në çdo komponent, deri te transaksionet e veçanta të bazës së të dhënave. Dhe që pas një gabimi, të shkruhet menjëherë se si duhet të rregullohet. Gjithçka duhet të mbushet në disa megabajt, s’ka më shumë. Kjo është thjesht tekst! Nuk mund të jenë skedarët e tekstit që zënë dhjetëra gigabajt, kam dëgjuar diku këtë!
Pra, log-ët
Në botën reale log-ët janë thjesht një arkiv i informacionit diagnostik. Dhe çfarë të ruhet aty, nga të merret informacioni për ruajtje dhe sa i detajuar duhet të jetë, vendosin vetë zhvilluesit. Disa ndjekin rrugën e minimalizmit duke ruajtur vetëm regjistrime të nivelit ON/OFF, ndërsa disa tjerë mbledhin gjithçka që mund të arrijnë. Megjithatë, ka edhe një variant të ndërmjetëm me mundësinë për të zgjedhur të ashtuquajturin Logging Level, kur ti vetë tregon sa të detajuar do të doje të ruaje informacionin dhe sa hapësirë të zbrazët ke në disqet =) Në VBR ka gjashtë nivele të tilla, për më tepër. Besoni, nuk dëshironi të shihni se çfarë ndodh në rastin e logimit maksimalisht të detajuar me hapësirë të lirë në disqet tuaja.
Mirë. Ne e kuptuam paksa se çfarë dëshirojmë të ruajmë, por bëhet një pyetje e ligjshme: nga ku ta marrë këtë informacion? Një pjesë e ngjarjeve për regjistrimin, sigurisht, krijohet nga proceset tona të brendshme. Por çfarë të bëjmë kur ndodh ndërveprimi me ambientin e jashtëm? Për të mos rënë në një ferr të vërtetë të zgjidhjeve të gushtra dhe biçikletave, Veeam ka tendencë të mos shpikë shpikje të tashme. Gjithmonë, kur ka një API të gatshme, një funksion të integruar në sistem, një bibliotekë etj., ne do t'i japim përparësi variantet e gatshme, përpara se të fillojmë të krijojmë zgjidhjet tona të sofistikuara. Megjithatë, ka shumë nga ato. Prandaj, gjatë analizës së logeve është e rëndësishme të kuptohet se ndikimi më i madh i gabimeve ka të bëjë me mesazhet nga API të jashtme, thirrjeve sistemike dhe bibliotekave të tjera. Në këtë rast, roli i VBR është të përçojë këto gabime në skedarët e logeve ashtu siç janë. Dhe detyra kryesore e përdoruesit është të mësojë të kuptojë se cila rresht është nga kush, dhe për çfarë përgjigjet ky “kush”. Prandaj, nëse kodi i gabimit nga logu VBR ju çon në faqen e MSDN, është normale dhe e saktë.
Siç u dakorduam më parë: Veeam është një aplikacion i quajtur SQL-based. Kështu që të gjitha parametrat, të gjitha informacionet dhe në përgjithësi gjithçka që është e nevojshme për funksionimin normal - gjithçka ruhet në bazën e të dhënave të saj. Nga kjo, e vërteta e thjeshtë: ajo që nuk është në loge, shumë mund të jetë në bazë. Por as kjo nuk është një plumb argjendi: disa gjëra nuk gjenden as në logeat lokale të komponenteve të Veeam, e as në bazën e të dhënave të saj. Prandaj, duhet të mësohemi të studiojmë loget e hostit, loget e makinës lokale dhe loget e gjithçkaje që është e përfshirë në procesin e backup-it dhe restaurimit. Dhe ndodh ndonjëherë që informacioni i nevojshëm nuk gjendet askund. Kjo është rruga.
Disa shembuj të tillë të API-ve
Ky listë nuk ka për qëllim të jetë plotësisht i plotë, prandaj nuk duhet të kërkoni të vërtetën në instancën e fundit aty. Detyra e tij është vetëm të tregojë API-të dhe teknologjitë më të shpeshta të jashtme që përdoren në produktet tona.
Të fillojmë me VMware.
E para në listë do të jetë vSphere API. Përdoret për identifikimin, leximin e hierarkisë, krijimin dhe fshirjen e snapshtotëve, kërkimin e informacionit mbi makinat dhe shumë (shumë) gjëra të tjera. Funksionaliteti i zgjidhjes është mjaft i gjerë, prandaj për të gjithë ata që janë të interesuar, mund të rekomandoj VMware vSphere API Reference për versionin dhe . Për versionet më aktuale, gjithçka kërkohet në Google.
VIX API. Magjia e zezë e hipervizorit, për të cilën ka një listë të veçantë . VMware API për të punuar me skedarët në host pa u lidhur me ta përmes rrjetit. Një opsion i fundit kur duhet të vendosësh një skedar në makinë, për të cilën nuk ka një kanal më të mirë lidhjeje. Paraqet dhimbje dhe vuajtje, nëse skedari është i madh dhe host-i është i ngarkuar. Por këtu zbatohen rregulli se edhe 56.6 Kb/s është më mirë se 0 Kb/s. Në Hyper-V, gjë e ngjashme quhet PowerShell Direct. Por kjo ka qenë deri në shfaqjen e
vSphere Web Services API Duke filluar nga vSphere 6.0 (afro, pasi për herë të parë ky API u paraqit në versionin 5.5) përdoret për të punuar me makinat virtuale dhe tashmë pothuajse kudo ka zëvendësuar VIX. Në thelb, ky është një tjetër API për menaxhimin e vSphere. Ata që janë të interesuar mund të rekomandojnë studimin e manuali të shkëlqyer.
VDDK (Virtual Disk Development Kit). Biblioteka, për të cilën është folur pjesërisht në këtë . Përdoret për të lexuar disqet virtuale. Disa kohë më parë ishte pjesë e VIX, megjithatë me kalimin e kohës u nxor në një produkt të veçantë. Megjithatë, me të drejtat e pasardhësit, përdor të njëjtat kode gabimi që edhe VIX. Por për një arsye të panjohur, në vetë SDK nuk ka asnjë përshkrim të këtyre gabimeve. Prandaj, përmes përvojës u zbuluar se gabimet e VDDK me kode të tjera janë në fakt një translacion nga binar në kod decimal. Konsiston në dy pjesë – gjysma e parë përbën informacione të pa dokumentuara në kontekst, ndërsa pjesa e dytë janë gabimet tradicionale të VIX/VDDK. Për shembull, nëse shohim:
Gabim VDDK: 21036749815809.Gabim i panjohur
Atëherë e konvertojmë këtë në hex dhe marrim 132200000001. Fillimi që nuk jep informacion 132200 thjesht e lëmë mënjanë, ndërsa pjesa tjetër do të jetë kodi ynë i gabimit (VDDK 1: Gabim i panjohur). Për gabimet më të zakonshme të VDDK, në të vërtetë, së fundmi u bë një artikull të veçantë .
Tani do të shqyrtojmë Windows.
Këtu gjithçka e nevojshme dhe e rëndësishme për ne mund të gjendet në standardin Event Viewer. Por ka një pengesë: sipas traditës së vjetër, Windows regjistron jo tekstin e plotë të gabimit, por vetëm numrin e tij. Për shembull, gabimi 5 është 'Qasja është e mohuar', ndërsa 1722 është 'Shërbimi RPC nuk është i disponueshëm', dhe 10060 është 'Koha e lidhjes ka skaduar'. Sigurisht, është e shkëlqyer nëse e mban mend më të njohurit, por si të veprosh me ato që nuk ke parë ndonjëherë deri tani?
Dhe që të mos duket gjithçka si mjaltë, gabimet ruhen gjithashtu në formë hexadecimal, me prefiksin 0x8007. Për shembull, 0x8007000e në të vërtetë është 14, Out of Memory. Pse dhe për kë është bërë kështu — është një mister i mbuluar me errësirë. Megjithatë, lista e plotë e gabimeve mund të shkarkohet falas dhe pa SMS nga .
Për më tepër, ndonjëherë hasen edhe prefikse të tjera, jo vetëm 0x8007. Në këtë situatë të trishtueshme për të kuptuar HRESULT (“result handle”) duhet të zbresim edhe më thellë në për zhvilluesit. Në jetën e zakonshme nuk ju rekomandoj ta bëni këtë, por nëse ndodhet në presion ose thjesht jeni kurioz, tani e dini se çfarë të bëni.
Por shokët në Microsoft na panë me mëshirë dhe na ofruan një utilitar . Ky është një copë konsoli e lumtur që di të përkthejë kodet e gabimeve në gjuhën e zakonshme pa përdorur Google. Funksionon rreth kështu.
C:UsersrootDesktop>err.exe 0x54f
# për hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Ndodhi një gabim i brendshëm.
# si një HRESULT: Serious: SUCCESS (0), FACILITY_NULL (0x0), Kodi 0x54f
# për hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Ndodhi një gabim i brendshëm.
# 2 ndeshje të gjetura për "0x54f"Nje pyetje legjitime shfaqet: përse ne nuk shkruajmë menjëherë shpjegim në log, por i lë këto kode të mistershme? Përgjigjja është në aplikacione të palëve të treta. Kur ju vetë bëni thirrje për ndonjë WinAPI, shpjegimi i përgjigjes nuk është i vështirë, sepse për këtë ekziston një thirrje speciale WinAPI. Por siç u tha, në log-un tonë mbërrin gjithçka që vjen në përgjigjet tona. Dhe këtu për shpjegim do të duhej të monitoronim vazhdimisht këtë rrjedhë mendimesh, të nxirrnim copëza me gabime të Windows-it, t’i shpjegonim ato dhe t’i vendosnim prapa. Le të themi se nuk është një aktivitet shumë argëtues.
Windows File Management API përdoret në mënyrë të ndryshme gjatë punës me skedarë. Krijimi i skedarëve, fshirja, hapja për shkruar, puna me atributet dhe shumë të tjera.
Të përmendurit më lart PowerShell Direct si një analog i VIX API në botën e Hyper-V. Fatkeqësisht, nuk është aq fleksibël: ka shumë kufizime në funksionalitet, nuk punon me çdo version të host-it dhe aspak me të gjithë mysafirët.
RPC (Remote Procedure Call) Mendoj se nuk ka njeri që ka punuar me Windows dhe nuk ka parë gabime të lidhura me RPC. Pavarësisht një keqkuptimi të zakonshëm, kjo nuk është një protokoll i vetëm, por çdo protokoll klient-server që përmbush një sërë parametrash. Megjithatë, nëse në log-et tona ka një gabim RPC, në 90% të rasteve do të jetë një gabim nga Microsoft RPC, i cili është pjesë e DCOM (Distributed Component Object Model). Në internet mund të gjeni një sasi të madhe dokumentacioni mbi këtë temë, megjithatë pjesa më e madhe e saj është e tejkaluar. Por nëse ka një dëshirë të fortë për të studiuar temën, mund të rekomandoj artikuj , dhe një listë të gjatë .
Krahasimi kryesor i arsyeve për shfaqjen e gabimeve RPC në log-et tona është përpjekjet e dështuara për të komunikuar midis komponentëve VBR (serveri > proxy, për shembull) dhe shpesh për shkak të problemeve të komunikimit.
Gabimi më i njohur është The RPC server is unavailable (1722). Thjesht, klienti nuk mundi të krijonte një lidhje me serverin. Si dhe pse - nuk ka një përgjigje të vetme, por zakonisht është një problem me autentifikimin ose me qasjen rrjetore në portin 135. Kjo është tipike për infrastrukturat me caktimin dinamik të porteve. Madje ka edhe . Dhe Microsoft ka për gjetjen e shkaqeve të defekteve.
Gabimi i dytë më i njohur: There are no more endpoints available from the endpoint mapper (1753). Klienti ose serveri RPC nuk mundën të caktuan një port për veten e tyre. Zakonisht ndodh kur serveri (në rastin tonë, makina e gazdës) është konfiguruar për caktimin dinamik të porteve nga një gamë të ngushtë, e cila ka përfunduar. Ndërsa nga ana e klientit (në rastin tonë, serveri VBR), kjo do të thotë se VeeamVssAgent tonë ose nuk është nisur, ose nuk është regjistruar si një ndërfaqe RPC. Për këtë temë ka gjithashtu .
Dhe për të përfunduar Top-3 gabimeve RPC, le të përmendim RPC function call failed (1726). Ky gabim shfaqet nëse lidhja është krijuar, por kërkesat RPC nuk përpunohen. Për shembull, ne kërkojmë informacion mbi statusin e VSS (ndoshta aty po bëhet një kopje kaq shpejt, ndërsa ne po mundohemi ta marrim informacionin), dhe në përgjigje marrim heshtje dhe injorim.
Windows Tape Backup API nevojnë për të punuar me bibliotekat ose diskët kasetë. Siç e kam përmendur në fillim: të shkruash driverët e tu dhe të vuash më pas me mbështetjes e çdo pajisjeje nuk na jep asnjë kënaqësi. Prandaj, Veeam-nuk ka asnjë driver të tij. Të gjitha kalojnë përmes API-t standard, mbështetje të cilit realizojnë vetë prodhuesit e pajisjeve. Ka shumë logjikë në këtë, apo jo?
SMB/CIFS Të gjithë zakonisht i shkruajnë ato afër, megjithëse nuk janë të gjithë që e mbajnë mend se CIFS (Common Internet File System) është thjesht një version privat i SMB (Server Message Block). Prandaj nuk ka asgjë të keqe në përgjithësimin e këtyre koncepteve. Samba, për shembull, është një realizim në Linux/Unix dhe ka karakteristikat e saj, por kjo është një devijim. Ajo që është e rëndësishme këtu: kur Veeam kërkon të shkruajë diçka përmes rrugës UNC (serverdirectory), serveri përdor hierarkinë e driverëve të sistemit të skedarëve, duke përfshirë mup dhe mrxsmb, për të shkruar në ndarjen. Për rrjedhojë, këta driverë do të gjenerojnë gjithashtu gabime.
Nuk mund të kalojmë pa Winsock API. Nëse duhet të bëjmë diçka përmes rrjetit, VBR punon përmes Windows Socket API, i njohur si Winsock. Pra, nëse shohim në log bashkimin IP:Port, është kjo. Në dokumentacionin zyrtar ka një listë të mirë të mundësive .
Të përmendurit më lart WMI (Windows Management Instrumentation) është një API gjithëpërfshirës për menaxhimin e gjithçkaje në botën Windows. Për shembull, gjatë punës me Hyper-V, pothuajse të gjitha kërkesat për hostin zhvillohen përmes tij. Në një fjalë, është një gjë krejtësisht e pandashme dhe shumë e fuqishme në mundësitë e saj. Në përpjekjet për të ndihmuar të kuptohet ku dhe çfarë ka dështuar, instrumenti i integruar WBEMtest.exe është shumë i dobishëm.
Dhe i fundit në listë, por aspak më pak të rëndësishëm — VSS (Volume Shadow Storage). Tema është aq e pasur dhe misteroze saqë është shkruar shumë dokumentacion për të. Kopja e Hijes është më e lehtë për t'u kuptuar si një tip i veçantë i snapshot-it, me të cilin praktikisht është. Falë saj, në VMware mund të bëhen backup-e të konsistente me aplikacionin, ndërsa në Hyper-V, gati gjithçka. Kam plane për të bërë një artikull të veçantë me një përmbledhje mbi VSS, por deri atëherë mund të provoni të lexoni . Vetëm me kujdes, sepse përpjekja për të kuptuar VSS me një shikim mund të çojë në lëndime të trurit.
Në këtë pikë, mund të ndalojmë. E kam konsideruar të përfunduar detyrën për të shpjeguar gjërat më themelore, kështu që në kapitullin e ardhshëm do të shikojmë në loge. Por nëse keni pyetje të mbetura, mos hezitoni t'i përmendni ato në komentet.
Burimi: habr.com
