Ipinagpapatuloy namin ang aming paglulubog sa kamangha-manghang mundo ng paghula ... pag-troubleshoot sa pamamagitan ng mga log. SA napagkasunduan namin ang kahulugan ng mga pangunahing termino at tiningnan ang kabuuang istraktura ng Veeam bilang isang solong aplikasyon na may isang mata. Ang gawain para sa isang ito ay upang malaman kung paano nabuo ang mga file ng log, kung anong uri ng impormasyon ang ipinapakita sa kanila at kung bakit ganito ang hitsura ng mga ito.
Ano sa palagay mo ang mga "log" na ito? Ayon sa karamihan, ang mga log ng anumang aplikasyon ay dapat na italaga ang papel ng isang uri ng makapangyarihang nilalang na kadalasang nagtatanim sa isang lugar sa likod-bahay, ngunit sa tamang sandali ay lumilitaw nang wala saanman sa nagniningning na baluti at nagliligtas sa lahat. Iyon ay, dapat silang maglaman ng lahat, mula sa pinakamaliit na pagkakamali sa bawat bahagi hanggang sa mga indibidwal na transaksyon sa database. At upang pagkatapos ng error ay isinulat kaagad kung paano pa ayusin ito. At ang lahat ng ito ay dapat magkasya sa isang pares ng mga megabytes, hindi na. Text lang yan! Ang mga text file ay hindi maaaring tumagal ng sampu-sampung gigabytes, narinig ko ito sa isang lugar!
Kaya ang mga log
Sa totoong mundo, ang mga log ay isang archive lamang ng diagnostic na impormasyon. At kung ano ang iimbak doon, kung saan kukuha ng impormasyon para sa pag-iimbak at kung gaano ito dapat maging detalyado, ang mga developer mismo ang magpapasya. Sinusundan ng isang tao ang landas ng minimalism sa pamamagitan ng pag-iingat ng mga talaan ng antas ng ON / OFF, at may masigasig na kumukuha ng lahat ng maaabot nila. Bagaman mayroon ding intermediate na opsyon na may kakayahang piliin ang tinatawag na Logging Level, kapag ikaw mismo ang nagpahiwatig kung gaano ka detalyadong impormasyon ang nais mong iimbak at kung gaano karaming dagdag na espasyo sa disk ang mayroon ka =) Ang VBR ay may anim na ganoong antas, sa pamamagitan ng paraan. At, maniwala ka sa akin, hindi mo gustong makita kung ano ang mangyayari sa pinakadetalyadong pag-log na may libreng espasyo sa iyong disk.
ayos lang. Halos naunawaan namin kung ano ang gusto naming i-save, ngunit lumitaw ang isang lehitimong tanong: saan kukuha ng impormasyong ito? Siyempre, bahagi tayo ng mga kaganapan para sa pag-log sa ating sarili sa pamamagitan ng ating mga panloob na proseso. Ngunit ano ang gagawin kapag may pakikipag-ugnayan sa panlabas na kapaligiran? Upang hindi dumausdos sa impiyerno ng mga saklay at bisikleta, ang Veeam ay may posibilidad na hindi mag-imbento ng mga imbensyon na naimbento na. Sa tuwing mayroong handa na API, built-in na function, library, atbp., bibigyan namin ng kagustuhan ang mga handa na pagpipilian bago simulan ang pagbabakod sa aming mga kagamitan. Bagama't ang huli ay sapat din. Samakatuwid, kapag nagsusuri ng mga log, mahalagang maunawaan na ang malaking bahagi ng mga error ay nahuhulog sa mga mensahe mula sa mga third-party na API, system call, at iba pang mga library. Sa kasong ito, ang papel ng VBR ay bumaba sa pagpapasa ng mga error na ito sa bilang ng mga log file. At ang pangunahing gawain ng gumagamit ay upang malaman upang maunawaan kung aling linya ay mula kanino, at kung ano ang "sino" na ito ay responsable para sa. Kaya kung ang isang error code mula sa VBR log ay magdadala sa iyo sa isang MSDN page, iyon ay mabuti at tama.
Gaya ng napagkasunduan namin kanina: Ang Veeam ay isang tinatawag na SQL-based na application. Nangangahulugan ito na ang lahat ng mga setting, lahat ng impormasyon at sa pangkalahatan lahat ng bagay na kailangan lamang para sa normal na paggana - lahat ay naka-imbak sa database nito. Kaya ang simpleng katotohanan: kung ano ang wala sa mga log ay malamang na nasa database. Ngunit hindi rin ito isang pilak na bala: ang ilang mga bagay ay wala sa mga lokal na log ng mga bahagi ng Veeam, o sa database nito. Samakatuwid, kailangan mong matutunan kung paano pag-aralan ang mga log ng host, ang mga log ng lokal na makina at ang mga log ng lahat ng bagay na kasangkot sa proseso ng pag-backup at pagpapanumbalik. At nangyayari rin na ang kinakailangang impormasyon ay hindi magagamit kahit saan. Iyon ang paraan.
Ilang halimbawa ng mga naturang API
Ang listahang ito ay hindi naglalayong maging lubos na kumpleto, kaya hindi na kailangang hanapin ang tunay na katotohanan dito. Ang layunin nito ay ipakita lamang ang pinakakaraniwang mga third-party na API at teknolohiyang ginagamit sa aming mga produkto.
Magsimula tayo VMware.
Una sa listahan ay magiging vSphere API. Ginagamit para sa pagpapatunay, pagbabasa ng hierarchy, paggawa at pagtanggal ng mga snapshot, paghiling ng impormasyon tungkol sa mga makina, at marami pa (napakarami). Ang pag-andar ng solusyon ay napakalawak, kaya maaari kong irekomenda ang VMware vSphere API Reference para sa bersyon ΠΈ . Para sa higit pang mga kasalukuyang bersyon, lahat ay na-google lang.
VIX API. Ang black magic ng hypervisor, kung saan mayroong isang hiwalay . VMware API para sa pagtatrabaho sa mga file sa host nang hindi kumokonekta sa kanila sa network. Isang pagpipilian sa huling paraan kapag kailangan mong maglagay ng isang file sa isang makina kung saan walang mas mahusay na channel ng komunikasyon. Ito ay sakit at paghihirap kung ang file ay malaki at ang host ay na-load. Ngunit dito gumagana ang panuntunan na kahit na 56,6 Kb / s ay mas mahusay kaysa sa 0 Kb / s. Sa Hyper-V, ang bagay na ito ay tinatawag na PowerShell Direct. Pero dati lang yun
vSpehere Web Services API Simula sa vSphere 6.0 (humigit-kumulang, mula noong unang ipinakilala ang API na ito sa bersyon 5.5) ito ay ginagamit upang gumana sa mga guest machine at pinalitan ang VIX halos lahat ng dako. Sa katunayan, ito ay isa pang API para sa pamamahala ng vSphere. Para sa mga interesado, inirerekomenda kong mag-aral manwal.
VDDK (Virtual Disk Development Kit). Ang aklatan, na bahagyang tinalakay dito . Ginagamit upang basahin ang mga virtual na disk. Noong unang panahon ito ay bahagi ng VIX, ngunit sa paglipas ng panahon ay inilipat ito sa isang hiwalay na produkto. Ngunit bilang tagapagmana, gumagamit ito ng parehong error code gaya ng VIX. Ngunit sa ilang kadahilanan, walang paglalarawan ng mga error na ito sa SDK mismo. Samakatuwid, empirically nalaman na ang mga error sa VDDK sa iba pang mga code ay isang pagsasalin lamang mula sa binary hanggang decimal code. Binubuo ito ng dalawang bahagi - ang unang kalahati ay undocumented na impormasyon tungkol sa konteksto, at ang pangalawang bahagi ay ang tradisyonal na VIX / VDDK error. Halimbawa, kung nakikita natin:
VDDK error: 21036749815809.Unknown error
Pagkatapos ay buong tapang naming iko-convert ito sa hex at makakuha ng 132200000001. Itatapon lang namin ang hindi nakakaalam na simula ng 132200, at ang natitira ay ang aming error code (VDDK 1: Hindi kilalang error). Tungkol sa pinakamadalas na mga error sa VDDK, kamakailan lamang ay nagkaroon ng hiwalay .
Ngayon tingnan natin MgaIndows.
Dito, lahat ng bagay na pinakakailangan at mahalaga para sa atin ay matatagpuan sa pamantayan Viewer ng Kaganapan. Ngunit mayroong isang catch: ayon sa isang mahabang tradisyon, hindi ini-log ng Windows ang buong teksto ng error, ngunit ang numero lamang nito. Halimbawa, ang error 5 ay "Tinanggihan ang pag-access", at ang 1722 ay "Hindi available ang RPC server", at ang 10060 ay "Nag-time out ang koneksyon." Siyempre, maganda kung naaalala mo ang mga pinakasikat, ngunit paano ang mga hindi nakikita hanggang ngayon?
At upang ang buhay ay hindi magmukhang pulot sa lahat, ang mga error ay naka-imbak din sa hexadecimal form, na may prefix na 0x8007. Halimbawa, ang 0x8007000e ay talagang 14, Out of Memory. Kung bakit at para kanino ito ginawa ay isang misteryong nababalot ng kadiliman. Gayunpaman, ang kumpletong listahan ng mga error ay maaaring ma-download nang libre at walang SMS mula sa .
Siyanga pala, minsan may iba pang prefix, hindi lang 0x8007. Sa ganitong malungkot na sitwasyon, upang maunawaan ang HRESULT ("result handle"), kailangan mong pag-aralan nang mas malalim ang para sa mga developer. Sa ordinaryong buhay, hindi ko ipinapayo sa iyo na gawin ito, ngunit kung bigla kang pinindot sa dingding o nakikiusyoso lang, ngayon alam mo na kung ano ang gagawin.
Ngunit ang mga kasama sa Microsoft ay medyo naawa sa amin at ipinakita sa mundo ang isang utility . Ito ay isang maliit na bahagi ng console happiness na maaaring magsalin ng mga error code sa tao nang hindi gumagamit ng Google. Ito ay gumagana tulad nito.
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"Ang isang lehitimong tanong ay lumitaw: bakit hindi namin agad isulat ang decryption sa mga log, ngunit iwanan ang mga mahiwagang code na ito? Ang sagot ay nasa mga application ng third-party. Kapag hinila mo ang ilang WinAPI na tawag sa iyong sarili, hindi mahirap tukuyin ang tugon nito, dahil mayroong kahit isang espesyal na tawag sa WinAPI para dito. Ngunit tulad ng nabanggit na, lahat ng bagay na dumarating lamang sa amin bilang mga tugon ay pumapasok sa aming mga tala. At dito, para ma-decrypt ito, kailangang patuloy na subaybayan ang daloy ng kamalayan na ito, bunutin ang mga piraso na may mga error sa Windows mula dito, i-decrypt ang mga ito at i-paste ang mga ito pabalik. Maging tapat tayo, hindi ang pinakakapana-panabik na aktibidad.
Windows File Management API ginagamit sa lahat ng posibleng paraan kapag nagtatrabaho sa mga file. Paglikha ng mga file, pagtanggal, pagbubukas para sa pagsulat, pagtatrabaho sa mga katangian, at iba pa at iba pa.
binanggit sa itaas Direktang PowerShell bilang isang analogue ng VIX API sa mundo ng Hyper-V. Sa kasamaang palad, hindi masyadong nababaluktot: maraming mga paghihigpit sa pag-andar, hindi ito gumagana sa bawat bersyon ng host at hindi sa lahat ng mga bisita.
RPC (Remote Procedure Call) Sa palagay ko ay walang isang taong nagtrabaho sa WIndows na hindi nakakita ng mga error na nauugnay sa RPC. Sa kabila ng tanyag na maling kuru-kuro, hindi ito iisang protocol, ngunit anumang protocol ng client-server na nakakatugon sa isang bilang ng mga parameter. Gayunpaman, kung mayroong error sa RPC sa aming mga log, 90% ng oras ay magiging error ito mula sa Microsoft RPC, na bahagi ng DCOM (Distributed Component Object Model). Maaari kang makahanap ng isang malaking halaga ng dokumentasyon sa paksang ito sa net, ngunit ang bahagi ng leon nito ay medyo lipas na. Ngunit kung may matinding pagnanais na pag-aralan ang paksa, maaari akong magrekomenda ng mga artikulo , at mahabang listahan .
Ang mga pangunahing sanhi ng mga error sa RPC sa aming mga log ay ang mga nabigong pagtatangka na makipag-ugnayan sa pagitan ng mga bahagi ng VBR (server > proxy, halimbawa) at kadalasan dahil sa mga problema sa komunikasyon.
Ang nangungunang tuktok sa lahat ng tuktok ay ang error Ang RPC server ay hindi magagamit (1722). Sa simpleng mga termino, ang kliyente ay hindi makapagtatag ng isang koneksyon sa server. Paano at bakit - walang iisang sagot, ngunit kadalasan ito ay isang problema sa pagpapatunay o sa network access sa port 135. Ang huli ay tipikal para sa mga imprastraktura na may dynamic na port assignment. Sa paksang ito, mayroong kahit na . At mayroon ang Microsoft upang mahanap ang sanhi ng kabiguan.
Pangalawa sa pinakasikat na error: Wala nang available na mga endpoint mula sa endpoint mapper (1753). Nabigo ang RPC client o server na magtalaga ng sarili nitong port. Karaniwang nangyayari kapag ang server (sa aming kaso, ang guest machine) ay na-configure upang dynamic na maglaan ng mga port mula sa isang makitid na hanay na natapos na. At kung mag-log in ka mula sa panig ng kliyente (sa aming kaso, ang VBR server), nangangahulugan ito na ang aming VeeamVssAgent ay hindi nagsimula o hindi nakarehistro bilang isang interface ng RPC. Mayroon din sa paksang ito .
Well, para makumpleto ang Top 3 RPC errors, tandaan natin nabigo ang RPC function call (1726). Lumalabas kung naitatag na ang koneksyon, ngunit hindi pinoproseso ang mga kahilingan sa RPC. Halimbawa, humihiling kami ng impormasyon tungkol sa katayuan ng VSS (biglang sa ngayon ay may ginagawang shadow mine doon, at sinusubukan naming umakyat), at bilang tugon sa amin, tumahimik at huwag pansinin.
Windows Tape Backup API kailangan upang gumana sa mga tape library o drive. Tulad ng nabanggit ko sa simula: wala kaming kasiyahan sa pagsulat ng aming sariling mga driver at pagkatapos ay nagdurusa sa suporta ng bawat aparato. Samakatuwid, ang vim ay walang sariling mga driver. Lahat sa pamamagitan ng isang karaniwang API, ang suporta nito ay ipinapatupad mismo ng mga vendor ng hardware. Kaya mas lohikal, tama?
SMB / CIFS Dahil sa nakagawian, lahat ay nagsusulat ng mga ito nang magkatabi, bagaman hindi lahat ay naaalala na ang CIFS (Common Internet File System) ay isang pribadong bersyon lamang ng SMB (Server Message Block). Kaya walang masama sa pag-generalize ng mga konseptong ito. Ang Samba ay isa nang pagpapatupad ng LinuxUnix, at mayroon itong sariling mga kakaiba, ngunit lumihis ako. Ano ang mahalaga dito: kapag humiling si Veeam na magsulat ng isang bagay sa landas ng UNC (serverdirectory), ginagamit ng server ang hierarchy ng mga driver ng file system, kabilang ang mup at mrxsmb, para sumulat sa bola. Alinsunod dito, ang mga driver na ito ay bubuo din ng mga error.
Hindi magagawa nang wala Winsock API. Kung may kailangang gawin sa network, gumagana ang VBR sa pamamagitan ng Windows Socket API, na kilala bilang Winsock. Kaya kung makakita tayo ng isang bungkos ng IP:Port sa log, ito na. Ang opisyal na dokumentasyon ay may magandang listahan ng posible .
binanggit sa itaas WMI (Windows Management Instrumentation) ay isang uri ng makapangyarihang API para sa pamamahala ng lahat at lahat ng tao sa mundo ng Windows. Halimbawa, kapag nagtatrabaho sa Hyper-V, halos lahat ng mga kahilingan sa host ay dumaan dito. Sa isang salita, ang bagay ay ganap na hindi mapapalitan at napakalakas sa mga kakayahan nito. Sa pagtatangkang tumulong na malaman kung saan at kung ano ang sira, ang built-in na tool na WBEMtest.exe ay nakakatulong nang malaki.
At huli sa listahan, ngunit hindi gaanong mahalaga - VSS (Imbakan ng Dami ng Shadow). Ang paksa ay hindi mauubos at mahiwaga tulad ng maraming dokumentasyon na nakasulat dito. Ang Shadow Copy ay pinakasimpleng nauunawaan bilang isang espesyal na uri ng snapshot, na sa esensya ito ay. Salamat sa kanya, maaari kang gumawa ng application-consistent backups sa VMware, at halos lahat ng bagay sa Hyper-V. Mayroon akong mga plano na gumawa ng isang hiwalay na artikulo na may ilang mga squeeze sa VSS, ngunit sa ngayon maaari mong subukan na basahin . Ingat ka na lang, kasi. Ang pagsisikap na maunawaan ang VSS sa isang iglap ay maaaring humantong sa pinsala sa utak.
Dito, marahil, maaari tayong tumigil. Isinasaalang-alang ko ang gawain ng pagpapaliwanag sa mga pinakapangunahing bagay na natapos, kaya sa susunod na kabanata ay titingnan na natin ang mga tala. Ngunit kung mayroon kang anumang mga katanungan, huwag mag-atubiling tanungin sila sa mga komento.
Pinagmulan: www.habr.com