Turpinām mūsu ienirt aizraujošajā loģu problēmu risināšanas pasaulē. Mēs vienojāmies par pamatterminu nozīmi un ar vienu aci apskatījām Veeam kopējo struktūru kā vienotu lietotni. Uzdevums šim - noskaidrot, kā tiek veidoti loģu faili, kāda informācija tajos tiek attēlota un kāpēc tie izskatās tā, kā izskatās.
Kā jums šķiet, kas vispār ir šie "loģi"? Pēc daudzu domām, katra lietojumprogrammas loģiem vajadzētu būt visvarenai būtnei, kas lielāko daļu laika ir kaut kur aizmugurē, bet vajadzīgajos brīžos iznāk no nekurienes spožos bruņās un visus izglābj. Tas nozīmē, ka tajos jābūt visam, sākot no mazākajām kļūdām katrā komponentā, līdz atsevišķām datu bāzes transakcijām. Un, lai pēc kļūdas uzreiz būtu uzrakstīts, kā to vēl var labot. Un tam visam jāietilpst pāris megabaitos, ne vairāk. Tas taču ir tikai teksts! Teksta faili nevar aizņemt desmitiem gigabaitu, es kaut kur to esmu dzirdējis!
Tātad, loģi.
Reālajā pasaulē loģi ir tikai diagnostikas informācijas arhīvs. Un ko tajā uzglabāt, no kurienes ņemt informāciju uzglabāšanai un cik detalizētai tai jābūt, izlēmj paši izstrādātāji. Kāds iet minimālisma ceļu, uzglabājot ieslēgšanas/izslēgšanas līmeņa ierakstus, bet kāds centīgi sakrājas visam, ko vien var aizsniegt. Tomēr ir arī starpvariantu ar iespēju izvēlēties tā saukto Logging Level, kad jūs pats norādāt, cik detalizētu informāciju vēlaties uzglabāt un cik daudz lieka vieta jums ir diskos =) VBR ir pat seši šādi līmeņi, starp citu. Un, ticiet man, jūs nevēlaties redzēt, kas notiek, kad logi ir maksimāli detalizēti, ar brīvu vietu jūsu diskā.
Labi. Mēs aptuveni saprotam, ko vēlamies saglabāt, bet rodas likumīgas jautājums: no kurienes ņemt šo informāciju? Daļa notikumu, kas jāpiefiksē, protams, tiek veidota no mūsu iekšējiem procesiem. Bet kas jādara, kad notiek mijiedarbība ar ārējo vidi? Lai nenonāktu bezdibenī no pagaidu risinājumiem un velosipēdiem, Veeam mēdz neizgudrot jau izgudrotas lietas. Vienmēr, kad ir pieejams gatavs API, sistēmā iebūvēta funkcija, bibliotēka utt., mēs dosim priekšroku gatavajiem risinājumiem, pirms sākt veidot savas viltības. Tomēr pēdējo ir pietiekami daudz. Tāpēc, analizējot žurnālus, svarīgi saprast, ka lielākā daļa kļūdu nāk no trešo pušu API, sistēmas izsaukumiem un citām bibliotēkām. Šajā gadījumā VBR loma samazinās līdz šo kļūdu pārsūtīšanai žurnālos tādā veidā, kā tās ir. Bet galvenā lietotāja uzdevums ir iemācīties saprast, kura rindiņa no kura nāk un par ko šis “kāds” atbild. Tāpēc, ja VBR žurnāla kļūdas kods ved jūs uz MSDN lapu, tas ir normāli un pareizi.
Kā mēs iepriekš vienojāmies: Veeam ir tā sauktā SQL bāzes lietotne. Tas nozīmē, ka visas iestatījumi, visa informācija un vispār viss, kas nepieciešams normālai darbībai — viss tiek glabāts tās datubāzē. No tā izriet vienkārša patiesība: tas, kas nav žurnālos, visticamāk, ir datubāzē. Bet tas nav sudraba lode: dažas lietas nav ne lokālajos Veeam komponentu žurnālos, ne tā datubāzē. Tāpēc ir jāmācās izpētīt hosta žurnālus, lokālās mašīnas žurnālus un visus, kas piedalās rezerves kopēšanas un atjaunošanas procesā. Un dažreiz izrādās, ka nepieciešamā informācija vispār nav nekur. Šāds ir ceļš.
Daži piemēri šādiem API
Šis saraksts nenodrošina izsmeļu pilnīgumu, tāpēc nav jēgas meklēt tajā patiesību pēdējā instancē. Tās mērķis ir tikai parādīt visbiežāk izmantotos trešo pušu API un tehnoloģijas, kas tiek izmantotas mūsu produktos.
Sāksim ar VMware.
Pirmais sarakstā būs vSphere API. Izmanto autentifikācijai, hierarhijas lasīšanai, snapšotu izveidošanai un dzēšanai, informācijas pieprasīšanai par mašīnām un daudz ko (ļoti daudz) citu. Risinājuma funkcionalitāte ir ļoti plaša, tāpēc visiem interesentiem varu ieteikt VMware vSphere API Reference versijai un . Jaunākās versijas ir viegli sameklējamas, izmantojot meklētāju.
VIX API. Melnais burvība hipervizora, kam ir atsevišķs . VMware API, lai strādātu ar failiem uz mitinātāja bez piekļuves tiem tīklā. Beigu variants, kad jāievieto fails mašīnā, kurai nav labāka sakaru kanāla. Tas rada sāpes un ciešanas, ja fails ir liels, bet mitinātājs ir noslogots. Bet šeit darbojas likums, ka pat 56,6 Kb/s ir labāk nekā 0 Kb/s. Hyper-V šāds risinājums tiek saukts par PowerShell Direct. Bet tas bija spēkā tikai līdz
vSphere Web Services API . Sākot ar vSphere 6.0 (apmēram, jo šis API pirmo reizi tika ieviests versijā 5.5), to izmanto, lai strādātu ar viesu mašīnām, un tas jau praktiski visur ir nomainījis VIX. Patiesībā tas ir vēl viens API vSphere pārvaldībai. Interesentiem varu ieteikt izpētīt rokasgrāmatu.
VDDK （Virtual Disk Development Kit). Bibliotēka, par kuru daļēji runāts šajā . Tiek izmantota virtuālo diskus lasīšanai. Ka kādreiz tā bija VIX daļa, tomēr laika gaitā tā tika iznesta kā atsevišķs produkts. Tomēr kā mantinieks izmanto tos pašus kļūdu kodus kā VIX. Bet kāda iemesla dēļ pašā SDK nav neviena šī kļūdu apraksta. Tādēļ pieredzējuši ceļā bija noskaidrots, ka VDDK kļūdas ar citiem kodiem — ir tikai translācija no binārā uz desmito kodu. Tās sastāv no divām daļām – pirmā puse ir nedokumentēta informācija par kontekstu, bet otrā daļa — tradicionālās VIX/VDDK kļūdas. Piemēram, ja redzam:
VDDK kļūda: 21036749815809. Nezināma kļūda
, tad droši konvertējam to uz hex un iegūstam 132200000001. Neinformatīvu sākumu 132200 vienkārši izmetam, bet paliekošais būs mūsu kļūdas kods (VDDK 1: Nezināma kļūda). Par visbiežāk sastopamajām VDDK kļūdām nesen tika izveidota atsevišķa .
Tagad aplūkosim Windows.
. Šeit visu nepieciešamo un svarīgo var atrast standartā Event Viewer. Bet ir viena iedzimtība: pēc senas tradīcijas Windows neieraksta pilnu kļūdas tekstu, bet tikai tās numuru. Piemēram, kļūda 5 ir “Access denied”, bet 1722 — “RPC server is unavailable”, nu un 10060 — “Connection timed out”. Protams, tas ir lieliski, ja tu atceries vispazīstamākās, tomēr kā būt ar līdz šim neredzētām?
Un, lai dzīve nešķistu pārāk salda, kļūdas tiek glabātas arī heksadecimālā veidā, ar prefiksu 0x8007. Piemēram, 0x8007000e — tas patiesībā ir 14, Atmiņas trūkums. Kāpēc un kam tā tika izstrādāta — paliek noslēpums. Tomēr pilnu kļūdu sarakstu var lejupielādēt bez maksas un bez SMS no .
Jāatzīmē, ka dažreiz sastopami arī citi prefiksi, ne tikai 0x8007. Šādā skumjā situācijā, lai saprastu HRESULT (“result handle”), ir jāiedziļinās vēl dziļāk izstrādātājiem. Ikdienā to nevarētu ieteikt, bet ja nu gadītos stāvēt pie sienas vai vienkārši interesē, tagad jūs zināt, ko darīt.
Tomēr Microsoft kolēģi nedaudz sausoši ieteica mums un parādīja pasaulei rīku . Tas ir neliels konsoles prieks, kas spēj pārvērst kļūdu kodus cilvēku valodā, neizmantojot Google. Tas darbojas apmēram šādi.
C:UsersrootDesktop>err.exe 0x54f
# heksadecimālais 0x54f / decimālais 1359
ERROR_INTERNAL_ERROR winerror.h
# Iekšēja kļūda notika.
# kā HRESULT: Smagums: VEIKSME (0), FACILITY_NULL (0x0), Kods 0x54f
# heksadecimālais 0x54f / decimālais 1359
ERROR_INTERNAL_ERROR winerror.h
# Iekšēja kļūda notika.
# 2 sakritības atrastas "0x54f"Rodās pamatots jautājums: kāpēc mēs uzreiz neierakstām loģos atšifrējumu, bet atstājam šos noslēpumainos kodus? Atbilde ir trešās puses lietojumprogrammās. Kad jūs paši veicat kādu WinAPI izsaukumu, tā atšifrēšana nav grūta, jo tam ir pat speciāls WinAPI izsaukums. Bet, kā jau minēts, mūsu loģos nonāk viss, kas vien pienāk pie mums atbildēs. Un šeit jau atšifrēšanai būtu pastāvīgi jāmudina šis apziņas plūsmas straume, jāizvelk no tās gabali ar Windows kļūdām, jāatšifrē tos un jāievieto atpakaļ. Godīgi sakot, tas nav pats aizraujošākais darbs.
Windows failu pārvaldības API visādi tiek izmantots, strādājot ar failiem. Failu izveide, dzēšana, atvēršana rakstīšanai, darbs ar atribūtiem un tā tālāk.
Iepriekš minētais PowerShell Direct kā VIX API analoga Hyper-V pasaulē. Diemžēl ne tik elastīgs: daudzas funkcionalitātes ierobežojumi, nedarbojas ar katru hosta versiju un tālu ne ar visiem viesiem.
RPC (Remote Procedure Call) Manuprāt, nav neviena cilvēka, kurš būtu strādājis ar Windows un nebūtu saskāries ar RPC saistītām kļūdām. Neskatoties uz izplatītu maldīgo uzskatu, tā nav viena vienota protokola forma, bet jebkurš klienta-servera protokols, kas atbilst vairākām prasībām. Ja mūsu žurnālos ir RPC kļūda, 90% gadījumu tā būs Microsoft RPC kļūda, kas ir DCOM (Distributed Component Object Model) sastāvdaļa. Tīklā ir pieejama milzīga dokumentācija par šo tēmu, tomēr liela daļa no tās ir diezgan novecojusi. Ja ir spēcīga vēlme izpētīt šo tēmu, varu ieteikt rakstus. , un garš saraksts .
Galvenie cēloņi RPC kļūdu rašanās mūsu žurnālos ir neveiksmīgas mijiedarbības mēģinājumi starp VBR komponentiem (serveris > proxy, piemēram), un bieži vien tās ir saistītas ar sakaru problēmām.
Visizplatītākā kļūda ir The RPC server is unavailable (1722). Ja runājam vienkārši, klients nespēja izveidot savienojumu ar serveri. Nav vienotas atbildes par to, kāpēc tas notiek, bet parasti tas ir saistīts ar autentifikācijas problēmām vai piekļuves trūkumu portam 135. Tas ir raksturīgi infrastruktūrām ar dinamisku portu piešķiršanu. Par šo tēmu ir pat Un Microsoft ir pa cēloņu meklēšanu.
Otrā populārākā kļūda ir: There are no more endpoints available from the endpoint mapper (1753). RPC klients vai serveris nespēja piešķirt sev portu. Parasti tas notiek, kad serveris (mūsu gadījumā viesmašīna) ir iestatīts uz dinamisku portu piešķiršanu no ierobežota diapazona, kas ir beidzies. Bet, ja uz to raugāmies no klienta puses (mūsu gadījumā VBR servera), tas nozīmē, ka mūsu VeeamVssAgent vai nu nesāka darboties, vai netika reģistrēts kā RPC interfeiss. Par šo tēmu ir arī .
Un, lai pabeigtu Top-3 RPC kļūdas, atcerēsimies RPC function call failed (1726). Šī kļūda parādās, ja savienojums tika izveidots, bet RPC pieprasījumi netiek izpildīti. Piemēram, mēs pieprasām informāciju par VSS statusu (ja pēkšņi tur tieši tagad tiek veidota šedokopija, bet mēs cenšamies piekļūt), bet atbildes nav, tikai klusums un ignorēšana.
Windows Tape Backup API ir nepieciešams darbam ar lentiņbibliotēkām vai dzinējiem. Kā es minēju sākumā: rakstīt savus draiverus un pēc tam mocīties ar katra ierīces atbalsta organizēšanu nav nekādas baudas. Tāpēc vima nav savu draiveru. Viss notiek caur standarta API, kura atbalstu īsteno paši aparatūras piegādātāji. Tā ir daudz loģiskāk, vai ne?
SMB/CIFS Visi pieraduši tos rakstīt blakus, lai gan ne visi atceras, ka CIFS (Common Internet File System) ir vienkārši privāta SMB (Server Message Block) versija. Tāpēc nav nekā slikta šīs jēdzienu vispārināšanā. Šeit Samba ir Linux/Unix īstenojums, un tur ir savas īpatnības, bet es esmu novirzījies. Kas šeit ir svarīgi: kad Veeam lūdz ierakstīt kaut ko pa UNC ceļu (serverdirectory), serveris izmanto failu sistēmas draiveru hierarhiju, tostarp mup un mrxsmb, lai ierakstītu resursdatorā. Attiecīgi, kļūdas radīs arī šie draiveri.
Nemaz nevar iztikt bez Winsock API. Ja kaut kas jādara caur tīklu, VBR strādā caur Windows Socket API, tautā pazīstams kā Winsock. Tāpēc, ja logā redzam IP:Port pāri, tas ir tas. Oficiālajā dokumentācijā ir labs saraksts ar iespējamiem .
Iepriekš minētais WMI (Windows Management Instrumentation) — tas ir kaut kas visvarens API, lai pārvaldītu visu un visus Windows pasaulē. Piemēram, strādājot ar Hyper-V, gandrīz visi pieprasījumi uz hostu notiek tieši caur to. Vārdu sakot, tas ir pilnīgi neaizstājams un ļoti jaudīgs savās iespējās. Mēģinot palīdzēt noskaidrot, kur un kas ir salūzis, ļoti noder iebūvētais rīks WBEMtest.exe.
Un pēdējais sarakstā, bet absolūti ne mazāk svarīgs — VSS (Volume Shadow Storage). Šis temats ir tik bezgalīgs un noslēpumains, cik daudz par to ir uzrakstīts dokumentācijas. Shadow Copy visvieglāk ir saprast kā īpašu tipa snapšotu, ar ko tas faktiski ir. Pateicoties tam, VMware var veikt lietojumprogrammu saskaņotus dublējumus, bet Hyper-V vispār gandrīz visu. Man ir plānos izveidot atsevišķu rakstu ar kādu izvilkumu par VSS, bet pagaidām varat izmēģināt izlasīt . Tikai uzmanīgi, jo mēģināt saprast VSS no pirmā izskata var izraisīt smadzeņu traumas.
Uz šo, domāju, varam apstāties. Uzdevumu izskaidrot visus pamata aspektus uzskatu par izpildītu, tāpēc nākamajā nodaļā jau skatīsimies uz žurnāliem. Bet, ja ir palikuši jautājumi, tad nekautrējieties tos izteikt komentārā.
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish