Kust tulevad logid? Veeami logide uurimine

Jätkame meie sukeldumist põnevasse maailma logide tõrkeotsingust. eelnevas artiklis Oleme kokku leppinud põhiterminite tähenduses ja heitnud kiire pilgu Veeami kui ühe rakenduse üldstruktuurile. Käesolev ülesanne on mõista, kuidas logifailid vormitakse, millist teavet need sisaldavad ja miks need välja näevad just nii, nagu nad näevad.

Kuidas te arvate, mis need «logid» tegelikult on? Enamik arvab, et iga rakenduse logidele on määratud roll, nagu kõikvõimas olend, kes veedab suurema osa ajast kusagil varjatud, kuid õigel hetkel ilmub välja säravates raudsuitsides ja päästab kõik. See tähendab, et seal peaks olema kõik, alates väikestest vigadest igas komponendis kuni eraldi andmebaasi tehinguteni. Ja pärast viga peaks kohe olema kirjas, kuidas seda parandada. Ja see kõik peaks mahtuma paarimegabaiti, mitte rohkem. See on ju lihtsalt tekst! Tekstifailid ei saa ju kaaluda kümneid gigabaite, olen kuskil sellest kuulnud!

Nii et logid

Tegelikus maailmas on logid lihtsalt diagnoosimisteabe arhiiv. Ja mida seal talletada, kust teavet talletamiseks võtta ning kui detailne see peaks olema, otsustavad arendajad ise. Mõned lähevad minimaliismi teed, talletades ainult sisse-/väljalülituse tasemel märkmeid, samas kui teised koguvad kõike, mis käeulatusse ulatub. On ka vahevariant, kus saad valida nn logimis taseme, kui ütled ise, kui detailsed andmed sa soovid talletada ja kui palju sul järgmist paika on =) VBR-i puhul on neid tasemeid lausa kuus, muide. Ja uskuge, te ei taha näha, mis toimub maksimaalse detailiga logimise korral, kui teie kettaruumi on vähe.

Hea, me oleme umbes aru saanud, mida soovime salvestada, kuid kerkib seaduslik küsimus: kust seda teavet saada? Osa logimisüritustest genereerime me ise oma sisemiste protsesside kaudu. Kuid mida teha, kui toimub suhtlemine väliskeskkonnaga? Et mitte langeda täiesti meeletusse virvarri ja abivahendite hulka, järgib Veeam kalduvust mitte leiutuda, kui olemas on juba välja mõeldud lahendused. Iga kord, kui on olemas valmis API, süsteemi sisseehitatud funktsioon, teek jne, anname eelise valmis variantidele enne, kui hakkame välja mõtlema oma keerukaid lahendusi. Kuigi neid on kindlasti ka piisavalt. Seega, logide analüüsimisel on oluline mõista, et suur osa vigadest tuleneb kolmandate osapoolte API-delt, süsteemi kutsest ja muudest teekidest. Antud juhul on VBR-i roll nende vigade edasisaatmine logifailidesse nii nagu nad on. Peamine ülesanne kasutajal on õppida mõistma, milline rida on kellelt ja mille eest see “keegi” vastutab. Seega, kui VBR-i logi veakood viib teid MSDN-i lehele, on see normaalne ja õige.

Nagu me varem kokku leppesime: Veeam on nn SQL-põhine rakendus. See tähendab, et kõik seaded, kogu teave ja tegelikult kõik, mis on vajalik normaalseks toimimiseks – kõik on talletatud selle andmebaasis. Sealt tuleb lihtne tõde: seda, mida logides ei ole, on tõenäoliselt andmebaasis. Kuid see ei ole hõbekuul: mõningaid asju ei leia ei Veeami komponentide kohalikest logidest ega ka selle andmebaasist. Seetõttu tuleb õppida uurima hosti logisid, kohaliku masina logisid ja kõike, mis osaleb varundamise ja taastamise protsessis. Mõnikord ei ole vajalikku teavet kuskil. Tõeline tee. 

Mõned näited sellistest API-dest

See nimekiri ei püüa olla täielik, seega ärge otsige sellest tõde viimase instantsina. Selle ülesanne on näidata kõige sagedamini kasutatavaid kolmandate osapoolte API-sid ja tehnoloogiaid, mida meie toodetes kasutatakse.

Alustame VMware. 

Esimene nimekirjas on vSphere API. Kasutatakse autentimiseks, hierarhia lugemiseks, lõplikest ja kustutamisest säilikute loomiseks, masinate teabe pärimiseks ja paljuks (väga paljuks) muuks. Lahenduse funktsionaalsus on väga ulatuslik, seega soovitan kõigil huvilistel tutvuda VMware vSphere API viidaga versioonile 5.5 ja 6.0. Kaasaegsete versioonide leidmine on lihtne, lihtsalt otsige Google'ist.

VIX APIMustuse hüperviisori must maagia, mille jaoks on eraldi veateade. VMware API failide haldamiseks hostis ilma nendega võrgus ühendamata. Viimane võimalus, kui on vaja fail masinasse sokutada, millele pole paremate ühendusteede leidmine õnnestunud. See on valu ja piin, kui fail on suur ja host on koormatud. Kuid siin kehtib reegel, et isegi 56,6 Kb/s on parem kui 0 Kb/s. Hyper-V puhul nimetatakse seda PowerShell Directiks. Kuid see oli nii ainult kuni

vSpehere Web Services API . Alates vSphere 6.0-st (umbes, kuna see API esitati esmakordselt versioonis 5.5) kasutatakse seda külgmiste masinate juhtimiseks ja see on praktikas enamiku VIX-i välja tõrjunud. Sisuliselt on see veel üks API vSphere'i haldamiseks. Huvi korral soovitan uurida suurepärast käsi- või õpetusraamatut. 

VDDK Virtuaalse pöördkäppide arendamise komplekt. Raamatukogu, millest on osaliselt räägitud sel artiklis. Kasutatakse virtuaalsete ketaste lugemiseks. Aegade alguses oli see osa VIX-ist, kuid aja jooksul isolatsiooni all, kuid kasutab sama veakoodide süsteemi nagu VIX. Kuid mingil põhjusel pole SDK-s nende vigade kirjeldust. Seega on katsetamise teel leitud, et VDDK vead koos teiste koodidega on tegelikult ainulaadne tõlgendus binaarsest kümnendsüsteemi. Koosneb kahest osast – esimene pool annab dokumenteerimata konteksti ja teine osa on traditsioonilised VIX/VDDK vead. Näiteks, kui näeme:

VDDK error: 21036749815809.Unknown error

Siis saame selle julgelt konverteerida heksades ja saame 132200000001. Silmapaistev algus 132200 visatakse lihtsalt kõrvale ja järelejäänud on meie veakood (VDDK 1: Unknown error). Just hiljuti oli eraldi artikkel.

Nüüd vaatame Windows.

. Siit saab kõige vajalikuma ja tähtsama leida standardsetest Sündmuste jälgijast. Kuid on üks probleem: vana traditsiooni kohaselt logib Windows mitte täielikku veateksti, vaid ainult selle numbri. Näiteks, viga 5 – on “Juhtimine keelatud”, viga 1722 – on “RPC server pole saadaval” ja 10060 – on “Ühenduse tähtaeg on ületatud”. Loomulikult on suurepärane, kui sa mäletad kõige tuntumaid, kuid kuidas olla sellistega, mida pole kunagi varem nähtud? 

Ja et elu liiga meeldiv ei tunduks, salvestatakse vead ka kuusnurksetes, prefiksiga 0x8007. Näiteks 0x8007000e tähendab tegelikult 14, mälu puudus. Miks ja kelle jaoks see tehti — jääb arusaamatuks. Küll aga saab täispaketti veakirju tasuta ja ilma SMS-ita alla laadida. arenduskeskusest.

Muide, vahel võivad esineda ka teised prefiksid, mitte ainult 0x8007. Sellises kurvas olukorras HRESULT-i (“tulemuse käepide”) mõistmiseks tuleb sügavamale sukelduda. dokumentatsioon arendajatele. Tavalises elus ei soovita ma seda teile teha, kuid kui oled nurgas kinni või lihtsalt huvitub, nüüd tead, mida teha.

Kuid Microsofti tooted on meie üle armu saanud ja tutvustasid utiliiti ERR. See on väike tükk konsooli õnne, mis suudab tõlgendada veakoodid inimkeelde ilma Google'ita. See töötab umbes nii.

C:UsersrootDesktop>err.exe 0x54f
# hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# Siseserveri tõrge tekkis.
# HRESULT-ina: Tõsidus: EDU (0), KERGE_NULL (0x0), Kood 0x54f
# hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# Siseserveri tõrge tekkis.
# "0x54f" jaoks leiti 2 vasteid.

Küsimus on seaduslik: miks me ei kirjuta logidesse kohe tõlgendusi, vaid jätame need salapärased koodid? Vastus on kolmandates rakendustes. Kui sa ise kutsud esile mõne WinAPI kõne, siis selle vastuse dešifreerimine ei ole keeruline, kuna selleks on isegi oma spetsiaalne WinAPI kõne. Kuid nagu juba mainitud, jõuab meie logidesse kõik, mis meile vastustes tuleb. Ja siin oleks juba dešifreerimisel pidevalt jälgida seda teadlikkuse voogu, valida sealt välja Windowsi vead, dešifreerida neid ja tagasi sisestada. Ütleme ausalt, see ei ole kõige köitvam tegevus.

Windowsi file management API kasutatakse failidega töötamisel igasugusteks toiminguteks. Failide loomine, eemaldamine, kirjutamiseks avamine, atribuutidega töötamine ja muud sellised asjad.

Ülaltoodud PowerShell Direct on analoog VIX API-le Hyper-V maailmas. Kahjuks mitte nii paindlik: palju funktsionaalsuse piiranguid, ei tööta igas hosti versioonis ja kaugel mitte kõikide külalistega.

RPC (Remote Procedure Call) Ma arvan, et ei ole ühtegi inimest, kes oleks töötanud Windowsiga ja ei oleks näinud RPC-ga seotud vigu. Vaatamata laialdaselt levinud ekslikule arusaamale, ei ole see ühtne protokoll, vaid igaüht, mis vastab teatud kriteeriumitele kliendi-serveri protokoll. Kui meie logides on RPC viga, on 90% juhtudest tegemist Microsoft RPC veaga, mis on osa DCOM-st (Distributed Component Object Model). Internetis on sellele teemale tohutult dokumentatsiooni, kuid suurem osa on üsna vana. Kuid kui on suur huvi teema uurimise vastu, siis võin soovitada artikleid Mis on RPC?, Kuidas RPC töötab ja pikk nimekiri RPC vigadest.

Peamised põhjused, miks RPC vigu meie logides esineb, on nurjunud katsed suhelda VBR komponentidega (server > vaheline süsteem, näiteks) ja enamasti suhtluse probleemide tõttu.

Kõige levinum viga on The RPC server is unavailable (1722). Lihtsalt öeldes, ei suutnud klient luua ühendust serveriga. Ükski vastus selle miks ja kuidas ei ole ühtne, kuid tavaliselt on see autentimise või võrguühenduse probleem sadamasse 135. Viimane on iseloomulik infrastruktuuridele, kus sadamate dünaamiline määramine toimub. Selle teema kohta on isegi eraldi KVA. Ja Microsoftil on mahukas juhend rikete leidmise kohta.

Teine populaarne viga: There are no more endpoints available from the endpoint mapper (1753). RPC klient või server ei suutnud endale sadamat määrata. See juhtub tavaliselt, kui server (meie juhul virtuaalmachine) on seadistatud sadamate dünaamiliseks jaotamiseks kitsas vahemikus, mis on lõppenud. Kui vaadata kliendi poolt (meie juhul VBR-server), tähendab see, et meie VeeamVssAgent ei ole kas käivitatud või ei ole registreeritud RPC liidese jaoks. Selle teema kohta on samuti eraldi KVA.

Ja lõpetades RPC kolme peamise vea hulga, tuletame meelde RPC function call failed (1726). See ilmneb, kui ühendus on loodud, kuid RPC päringud ei toimi. Näiteks küsime VSS staatuse kohta teavet (äkki parasjagu luuakse šedou koopiat, samas kui meie üritame vahele minna), ja vastuseks on vaikus ja ignoreerimine.

Windows Tape Backup API on vajalik lintraamatukogudega või draivega töötamiseks. Nagu mainisin alguses: oma draiverite kirjutamine ja hiljem iga seadme toe haldamine ei ole meile mingit rõõmu. Seetõttu ei ole Veeamil oma draivereid. Kõik toimub läbi standardse API, mille toe rakendavad seadme tarnijad ise. On ju palju loogilisem, eks?

SMB\/CIFS Kõik harjumusest kirjutavad neid kõrvuti, kuigi kaugelki mitte kõik ei tea, et CIFS (Common Internet File System) on lihtsalt SMB (Server Message Block) eriversioon. Nii et üldistamisel ei ole midagi halba. Samba on seevastu Linuxi-Unixi rakendus ja seal on oma eripärad, aga kaldun teemast kõrvale. Oluline on see, et kui Veeam palub midagi UNC tee kaudu (serverdirectory) kirjutada, siis server kasutab failisüsteemi draiverite hierarhiat, sealhulgas mup ja mrxsmb, kirjutamiseks jagusse. Seega genereerivad vead ka need draiverid.

Ilma ei saa läbi Winsock API. Kui on vaja midagi võrgu kaudu teha, töötab VBR Windows Socket API kaudu, tuntud rahva seas kui Winsock. Nii et kui logis näeme IP:Port paari, siis see ongi see. Ametlikus dokumentatsioonis on hea nimekiri võimalike vigu.

Ülaltoodud WMI (Windows Management Instrumentation) — see on üks kõikvõimas API, mis haldab kõike ja kõiki Windowsi maailmas. Näiteks Hyper-V töö käigus toimub peaaegu kõik päringud hostile just selle kaudu. Ühesõnaga, asi on täiesti asendamatu ja väga võimekas oma võimalustes. Probleemide tuvastamisel aitab palju sisseehitatud tööriist WBEMtest.exe.

Ja viimane nimekirjas, kuid mitte vähem tähtis — VSS (Volume Shadow Storage). Teema on sama ammendamatu ja salapärane kui palju selle kohta on dokumentatsiooni kirjutatud. Shadow Copy on kõige lihtsam mõista kui eriline snäpšoti tüüp, millega ta oma olemuselt ongi. Tänu sellele on VMware-s võimalik teha rakenduse konsistentseid varukoopiaid ja Hyper-V-s on see peaaegu, et kõik. Plaanin kirjutada eraldi artikli mingi kokkuvõttega VSS-ist, aga seni võite proovida lugeda seda kirjeldust. Olge ettevaatlik, kuna VSS-i mõistmine pinnapealselt võib põhjustada peaprobleeme.

Selle peale võibki peatuda. Peamine ülesanne kõige põhialuste selgitamine on täidetud, nii et järgmisel peatükil vaatame juba logisid. Aga kui küsimusi on, siis ärge kartke neid kommentaarides esitada.

Allikas: habr.com