Jätkame sukeldumist põnevasse arvamise ... logide abil tõrkeotsingu maailma. IN leppisime kokku põhimõistete tähenduses ja vaatasime ühe silmaga Veeami üldist ülesehitust kui ühtset rakendust. Selle ülesandeks on välja selgitada, kuidas logifailid moodustatakse, millist teavet neis kuvatakse ja miks need välja näevad.
Mis te arvate, mis need "palgid" on? Enamiku arvates tuleks mistahes rakenduse logidele omistada omamoodi kõikvõimsa olendi roll, kes enamasti vegeteerib kuskil tagaaias, kuid õigel hetkel ilmub eikusagilt säravas soomusrüüs ja päästab kõik. See tähendab, et need peaksid sisaldama kõike, alates iga komponendi väikseimatest vigadest kuni üksikute andmebaasi tehinguteni. Ja nii, et peale viga pandi kohe kirja, kuidas veel parandada. Ja see kõik peaks mahtuma paari megabaidi sisse, mitte rohkem. See on lihtsalt tekst! Tekstifailid ei mahu kümneid gigabaite, ma kuulsin seda kuskil!
Nii et palgid
Reaalses maailmas on logid vaid diagnostilise teabe arhiiv. Ja mida seal hoida, kust salvestamiseks infot saada ja kui detailne see peaks olema, on arendajate endi otsustada. Keegi järgib minimalismi teed, pidades arvestust SISSE / VÄLJAS taseme kohta ja keegi rehab usinalt kõike, mis ulatub. Kuigi on olemas ka vahepealne võimalus nn Logging Level valimise võimalusega, kui annad ise märku, kui detailset infot soovid salvestada ja kui palju sul kettaruumi lisa on =) VBR-l on muide kuus sellist taset. Ja uskuge mind, te ei taha näha, mis juhtub kõige üksikasjalikuma logimisega, millel on teie ketta vaba ruumi.
Hästi. Saime umbkaudu aru, mida päästa tahame, kuid tekib õigustatud küsimus: kust seda infot hankida? Loomulikult oleme me osa sündmustest, mille käigus logime end sisse oma sisemiste protsesside kaudu. Mida aga teha, kui toimub suhtlus väliskeskkonnaga? Et mitte libiseda karkude ja jalgrataste põrgusse, ei kipu Veeam juba leiutatud leiutisi välja mõtlema. Kui on olemas valmis API, sisseehitatud funktsioon, teek jne, eelistame enne oma seadmete tarastamist valmisvalikuid. Kuigi piisab ka viimasest. Seetõttu on logide analüüsimisel oluline mõista, et lõviosa vigadest langeb kolmandate osapoolte API-de, süsteemikõnede ja muude teekide sõnumitele. Sel juhul taandub VBR-i roll nende vigade edastamisele logifailidesse. Ja kasutaja põhiülesanne on õppida mõistma, milline rida on kellelt ja mille eest see "kes" vastutab. Nii et kui VBR-logi veakood viib teid MSDN-i lehele, on see hea ja õige.
Nagu varem kokku leppisime: Veeam on nn SQL-põhine rakendus. See tähendab, et kõik seaded, kogu teave ja üldiselt kõik, mis on vajalik ainult normaalseks toimimiseks - kõik on salvestatud selle andmebaasi. Siit ka lihtne tõde: mida logides pole, on suure tõenäosusega andmebaasis. Kuid see pole ka hõbekuul: mõnda asja pole Veeami komponentide kohalikes logides ega ka andmebaasis. Seetõttu peate õppima, kuidas uurida hosti logisid, kohaliku masina logisid ja kõigi varundus- ja taastamisprotsessiga seotud logisid. Ja juhtub sedagi, et vajalikku infot pole üldse kuskilt saada. See on viis.
Mõned näited sellistest API-dest
Selle loetelu eesmärk ei ole olla erakordselt täielik, seega pole vaja otsida sellest lõplikku tõde. Selle eesmärk on ainult näidata meie toodetes kasutatavaid levinumaid kolmandate osapoolte API-sid ja tehnoloogiaid.
Alustame VMware.
Esimene nimekirjas saab olema vSphere API. Kasutatakse autentimiseks, hierarhia lugemiseks, hetktõmmiste loomiseks ja kustutamiseks, masinate kohta teabe küsimiseks ja paljuks (väga) muuks. Lahenduse funktsionaalsus on väga lai, seega võin soovitada versiooni jaoks VMware vSphere API Reference и . Uuemate versioonide jaoks on kõik lihtsalt googeldatud.
VIX API. Hüpervisori must maagia, mille jaoks on eraldi . VMware API hostis olevate failidega töötamiseks ilma nendega võrgu kaudu ühendust loomata. Viimase võimaluse variant, kui peate faili panema masinasse, millele pole paremat sidekanalit. See on valu ja kannatust, kui fail on suur ja host on laaditud. Kuid siin töötab reegel, et isegi 56,6 Kb / s on parem kui 0 Kb / s. Hyper-V-s nimetatakse seda asja PowerShell Directiks. Aga see oli alles varem
vSpehere Web Services API Alates versioonist vSphere 6.0 (ligikaudu alates sellest, kui see API esmakordselt kasutusele võeti versioonis 5.5), kasutatakse seda külalismasinatega töötamiseks ja see on peaaegu kõikjal asendanud VIX-i. Tegelikult on see teine API vSphere'i haldamiseks. Huvilistel soovitan õppida manuaal.
VDDK (Virtual Disk Development Kit). Raamatukogu, millest oli siin osaliselt juttu . Kasutatakse virtuaalsete ketaste lugemiseks. Kunagi oli see osa VIX-ist, kuid aja jooksul viidi see eraldi tooteks. Kuid pärijana kasutab see samu veakoode, mis VIX. Kuid millegipärast pole SDK-s endas nende vigade kirjeldust. Seetõttu selgus empiiriliselt, et VDDK vead teiste koodidega on vaid tõlge kahendkoodilt kümnendkoodile. See koosneb kahest osast - esimene pool on dokumenteerimata teave konteksti kohta ja teine osa on traditsioonilised VIX / VDDK vead. Näiteks kui näeme:
VDDK error: 21036749815809.Unknown error
Seejärel teisendame selle julgelt kuueteistkümnendikuks ja saame 132200000001. Jätame lihtsalt ära 132200 mitteinformatiivse alguse ja ülejäänud osa on meie veakood (VDDK 1: Tundmatu viga). Kõige sagedasemate VDDK vigade kohta ilmus hiljuti eraldi .
Nüüd vaatame Aknad.
Siit leiab standardist kõik, mis meile kõige vajalikum ja olulisem Event Viewer. Kuid sellel on üks konks: pika traditsiooni kohaselt ei logi Windows tõrke täisteksti, vaid ainult selle numbrit. Näiteks tõrge 5 on "Juurdepääs keelatud" ja 1722 on "RPC-server pole saadaval" ja 10060 on "Ühendus aegus". Muidugi on tore, kui mäletad kuulsamaid, aga kuidas on lood seninägematutega?
Ja et elu ei tunduks üldse mesine, salvestatakse vead ka kuueteistkümnendsüsteemis, eesliitega 0x8007. Näiteks 0x8007000e on tegelikult 14, mälu otsas. Miks ja kelle jaoks seda tehti, on pimedusse mähitud mõistatus. Täieliku vigade loendi saab aga tasuta ja ilma SMS-ita alla laadida aadressilt .
Muide, mõnikord on ka muid eesliiteid, mitte ainult 0x8007. Sellises kurvas olukorras tuleb HRESULT-i („tulemuse käepide“) mõistmiseks veelgi rohkem süveneda arendajatele. Tavaelus ma ei soovita teil seda teha, kuid kui surusite ootamatult vastu seina või olete lihtsalt uudishimulik, teate nüüd, mida teha.
Kuid Microsofti seltsimehed halastasid meie peale veidi ja näitasid maailmale kasulikkust . See on väike tükk konsooliõnne, mis suudab veakoodid inimeseks tõlkida ilma Google'it kasutamata. See toimib nii.
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"Tekib õigustatud küsimus: miks me ei kirjuta kohe dekrüpteerimist logidesse, vaid jätame need salapärased koodid alles? Vastus on kolmanda osapoole rakendustes. Kui tõmbate ise mõne WinAPI kõne, pole selle vastuse dešifreerimine keeruline, sest selle jaoks on isegi spetsiaalne WinAPI kutse. Kuid nagu juba mainitud, satub kõik, mis meile vastusena jõuab, meie logidesse. Ja siin tuleks selle dekrüpteerimiseks seda teadvuse voogu pidevalt jälgida, sealt Windowsi vigadega jupid välja tõmmata, need lahti krüpteerida ja tagasi kleepida. Olgem ausad, mitte just kõige põnevam tegevus.
Windowsi failihalduse API kasutatakse failidega töötamisel igal võimalikul viisil. Failide loomine, kustutamine, kirjutamiseks avamine, atribuutidega töötamine jne ja nii edasi.
eespool mainitud PowerShell Direct VIX API analoogina Hyper-V maailmas. Kahjuks mitte nii paindlik: funktsionaalsusele on palju piiranguid, see ei tööta iga hosti versiooniga ja mitte kõigi külalistega.
RPC (Remote Procedure Call) Ma arvan, et pole ühtegi inimest, kes oleks töötanud WIndowsiga, kes poleks näinud RPC-ga seotud vigu. Vaatamata levinud eksiarvamusele ei ole tegemist üheainsa protokolliga, vaid mis tahes kliendi-serveri protokolliga, mis rahuldab mitmeid parameetreid. Kui aga meie logides on RPC-viga, siis 90% juhtudest on see viga Microsofti RPC-lt, mis on osa DCOM-ist (Distributed Component Object Model). Netist võib leida tohutul hulgal selleteemalist dokumentatsiooni, kuid lõviosa sellest on üsna vananenud. Aga kui on terav soov teemat uurida, siis võin artikleid soovitada , ja pikk nimekiri .
Peamised RPC-vigade põhjused meie logides on ebaõnnestunud katsed suhelda VBR-komponentide vahel (näiteks server > puhverserver) ja enamasti sideprobleemide tõttu.
Kõigi tippude hulgas on tõrge RPC-server pole saadaval (1722). Lihtsamalt öeldes ei saanud klient serveriga ühendust luua. Kuidas ja miks - ühest vastust pole, kuid tavaliselt on see probleem autentimise või võrgu juurdepääsuga pordile 135. Viimane on tüüpiline dünaamilise pordi määramisega infrastruktuuridele. Sellel teemal on isegi . Ja Microsoftil on rikke põhjuse leidmiseks.
Teine populaarseim viga: lõpp-punktide kaardistajast (1753) pole enam ühtegi lõpp-punkti saadaval. RPC klient või server ei suutnud endale porti määrata. Tavaliselt juhtub see siis, kui server (meie puhul külalismasin) on konfigureeritud dünaamiliselt eraldama porte kitsast lõppenud vahemikust. Ja kui logite sisse kliendi poolelt (meie puhul VBR-server), tähendab see, et meie VeeamVssAgent kas ei käivitunud või ei registreeritud RPC liidesena. Sellel teemal on ka .
Noh, 3 parima RPC-vea lõpetamiseks meenutagem, et RPC-funktsiooni kõne ebaõnnestus (1726). Ilmub, kui ühendus on loodud, kuid RPC päringuid ei töödelda. Näiteks küsime infot VSS-i oleku kohta (äkitselt tehakse seal praegu varjumiini ja me üritame ronida) ning vastuseks meile vaikimine ja ignoreerimine.
Windows Tape Backup API vaja lindiraamatukogude või draividega töötamiseks. Nagu alguses mainisin: meil pole mingit naudingut oma draivereid kirjutada ja siis iga seadme toel kannatada. Seetõttu pole vimil oma draivereid. Kõik läbi standardse API, mille toe rakendavad riistvaramüüjad ise. Nii palju loogilisem, eks?
SMB / CIFS Harjumuse tõttu kirjutavad kõik need kõrvuti, kuigi mitte kõik ei mäleta, et CIFS (Common Internet File System) on vaid SMB (Server Message Block) privaatversioon. Seega pole nende mõistete üldistamisel midagi halba. Samba on juba LinuxUnixi rakendus ja sellel on oma eripärad, kuid ma kaldun kõrvale. Siin on oluline: kui Veeam palub midagi UNC teele (serverikataloogi) kirjutada, kasutab server palli kirjutamiseks failisüsteemi draiverite hierarhiat, sealhulgas mup ja mrxsmb. Sellest tulenevalt tekitavad need draiverid ka vigu.
Ilma ei saa Winsocki API. Kui midagi on vaja teha üle võrgu, töötab VBR Windows Socket API kaudu, mida rahvasuus tuntakse Winsocki nime all. Nii et kui näeme logis hunnikut IP:Port, siis see on see. Ametlikus dokumentatsioonis on hea nimekiri võimalikest .
eespool mainitud WMI (Windows Management Instrumentation) on omamoodi kõikvõimas API kõige ja kõigi haldamiseks Windowsi maailmas. Näiteks Hyper-V-ga töötades läbivad peaaegu kõik päringud hostile selle kaudu. Ühesõnaga, asi on täiesti asendamatu ja oma võimalustelt väga võimas. Sisseehitatud WBEMtest.exe tööriist aitab palju aidata välja selgitada, kus ja mis on katki.
Ja nimekirjas viimane, kuid mitte sugugi vähemtähtis - VSS (Volume Shadow Storage). Teema on sama ammendamatu ja salapärane, kui palju selle kohta on dokumentatsiooni kirjutatud. Shadow Copy all mõistetakse kõige lihtsamalt erilist hetktõmmise tüüpi, mida see sisuliselt ka on. Tänu temale saate VMware'is teha rakendustele vastavaid varukoopiaid ja Hyper-V-s peaaegu kõike. Mul on plaanis teha eraldi artikkel VSS-i kohta, kuid praegu võite proovida lugeda . Lihtsalt ole ettevaatlik, sest. VSS-i välkkiire mõistmine võib viia ajukahjustuseni.
Sellega seoses võime ehk peatuda. Pean kõige elementaarsemate asjade selgitamise ülesande lõpetatuks, nii et järgmises peatükis vaatame juba logisid. Kuid kui teil on küsimusi, küsige neid kommentaarides.
Allikas: www.habr.com