Urang neruskeun immersion urang kana dunya matak tina guessing ... troubleshooting ku log. DI kami sapuk kana harti istilah dasar sarta nempo struktur sakabéh Veeam salaku aplikasi tunggal kalawan hiji panon. Tugas pikeun ieu nyaéta pikeun terang kumaha file log kabentuk, inpormasi naon anu dipidangkeun dina éta sareng kunaon aranjeunna katingalina.
Kumaha saur anjeun "log" ieu? Numutkeun paling, log tina aplikasi nu mana wae nu kudu ditugaskeun peran hiji jenis éntitas omnipotent nu lolobana waktu vegetates wae di backyard nu, tapi dina momen katuhu némbongan kaluar tina nowhere dina bersinar armor sarta ngaheéat dulur. Hartina, maranéhanana kudu ngandung sagalana, ti kasalahan slightest dina unggal komponén pikeun transaksi database individu. Sareng supados saatos kasalahan éta langsung ditulis kumaha cara ngalereskeunana. Sareng sadaya ieu kedah pas dina sababaraha megabyte, henteu langkung. Ieu ngan téks! File téks henteu tiasa nyandak puluhan gigabyte, kuring ngupingkeun waé!
Jadi log
Di dunya nyata, log ngan ukur arsip inpormasi diagnostik. Sareng naon anu kedah disimpen di dinya, dimana kéngingkeun inpormasi pikeun neundeun sareng kumaha detilna kedahna, terserah pamekar sorangan mutuskeun. Aya anu nuturkeun jalan minimalism ku ngajaga catetan tingkat ON / OFF, sareng aya anu rajin ngagaleuh sadayana anu tiasa dicapai. Sanajan aya ogé hiji pilihan panengah jeung kamampuhan pikeun milih nu disebut Logging Level, mun anjeun sorangan nunjukkeun kumaha rinci informasi rék nyimpen jeung sabaraha spasi disk tambahan anjeun gaduh =) VBR boga genep tingkat misalna, ku jalan. Sareng, percanten ka kuring, anjeun henteu hoyong ningali naon anu kajantenan kalayan logging anu paling detil sareng rohangan bébas dina disk anjeun.
muhun. Kami kasarna ngartos naon anu urang hoyong simpen, tapi timbul patarosan anu sah: dimana kéngingkeun inpormasi ieu? Tangtosna, urang janten bagian tina acara pikeun logging diri ku prosés internal urang. Tapi naon anu kudu dipigawé lamun aya interaksi jeung lingkungan éksternal? Dina raraga teu geser kana naraka pitch of crutches jeung sapédah, Veeam condong teu invent pamanggihan nu geus nimukeun. Iraha wae aya API siap-dijieun, fungsi diwangun-di, perpustakaan, jeung sajabana, urang bakal masihan leuwih sering dipake tinimbang pilihan siap-dijieun saméméh dimimitian pager contraptions urang. Sanajan dimungkinkeun ogé cukup. Ku alatan éta, nalika analisa log, hal anu penting pikeun ngarti yén bagian singa ngeunaan kasalahan ragrag dina pesen ti API pihak katilu, nelepon sistem, sarta perpustakaan lianna. Dina hal ieu, peran VBR turun pikeun neraskeun kasalahan ieu kana file log. Sareng tugas utama pangguna nyaéta diajar ngartos garis mana ti saha, sareng naon tanggung jawab "saha" ieu. Janten upami kode kasalahan tina log VBR mawa anjeun ka halaman MSDN, éta saé sareng leres.
Salaku urang sapuk saméméhna: Veeam mangrupakeun aplikasi basis SQL disebut. Ieu ngandung harti yén sadaya setélan, sadaya inpormasi sareng sacara umum sadayana anu dipikabutuh pikeun fungsi normal - sadayana disimpen dina database na. Lantaran kitu kabeneran basajan: naon anu teu aya dina log anu paling dipikaresep dina database. Tapi ieu sanés pélor pérak ogé: sababaraha hal henteu aya dina log lokal komponén Veeam, atanapi dina database na. Ku alatan éta, anjeun kudu diajar kumaha carana diajar log host, log tina mesin lokal jeung log sagalana nu kalibet dina cadangan tur malikkeun prosés. Sareng éta ogé kajadian yén inpormasi anu diperyogikeun henteu sayogi di mana waé. Éta jalan.
Sababaraha conto API sapertos
Daptar ieu teu boga tujuan pikeun jadi exceptionally lengkep, jadi teu perlu néangan bebeneran pamungkas dina eta. Tujuanana ngan ukur pikeun nunjukkeun API sareng téknologi pihak katilu anu paling umum anu dianggo dina produk urang.
Hayu urang mimitian ku VMware.
Kahiji dina daptar bakal vSphere API. Dipaké pikeun auténtikasi, maca hirarki, nyieun jeung mupus snapshots, requesting informasi ngeunaan mesin, sarta loba (pisan) leuwih. Pungsi solusina lega pisan, ku kituna kuring tiasa nyarankeun Rujukan VMware vSphere API pikeun versi na. и . Pikeun langkung seueur versi anu ayeuna, sadayana ngan ukur google.
API VIX. The magic hideung tina hypervisor, nu aya misah . VMware API pikeun gawé bareng file dina host tanpa nyambungkeun ka aranjeunna dina jaringan. Pilihan anu terakhir nalika anjeun kedah nempatkeun file dina mesin anu teu aya saluran komunikasi anu langkung saé. Éta nyeri sareng sangsara upami filena ageung sareng hostna dimuat. Tapi di dieu aturan dianggo yén sanajan 56,6 Kb / s leuwih hade tinimbang 0 Kb / s. Dina Hyper-V, hal ieu disebut PowerShell Direct. Tapi éta ngan sateuacan
vSpehere Web Services API Dimimitian ti vSphere 6.0 (kira-kira, saprak API ieu mimiti diwanohkeun dina versi 5.5) dipaké pikeun gawé bareng mesin tamu sarta geus diganti VIX ampir unggal madhab. Kanyataanna, ieu téh API sejen pikeun ngatur vSphere. Pikeun anu resep, kuring nyarankeun pikeun diajar manual.
VDDK (Virtual Disk Development Kit). Perpustakaan, anu sawaréh dibahas dina ieu . Dipaké pikeun maca disk virtual. Sakali kana waktu éta bagian tina VIX, tapi kana waktu eta dipindahkeun kana produk misah. Tapi salaku ahli waris, éta ngagunakeun kode kasalahan anu sami sareng VIX. Tapi pikeun sababaraha alesan, teu aya pedaran ngeunaan kasalahan ieu dina SDK sorangan. Ku alatan éta, éta kapanggih kaluar émpiris yén kasalahan VDDK kalawan kode sejenna ngan tarjamahan tina binér kana kode decimal. Éta diwangun ku dua bagian - satengah munggaran mangrupikeun inpormasi anu teu didokumentasikeun ngeunaan kontéks, sareng bagian kadua nyaéta kasalahan VIX / VDDK tradisional. Contona, upami urang ningali:
VDDK error: 21036749815809.Unknown error
Teras we boldly ngarobah ieu hex tur meunangkeun 132200000001. Urang saukur Piceun awal uninformative 132200, sarta sésana bakal kode kasalahan urang (VDDK 1: Kasalahan kanyahoan). Ngeunaan kasalahan VDDK paling sering, aya ngan anyar misah .
Ayeuna hayu urang tingali Windows.
Di dieu, sadayana anu paling penting sareng penting pikeun urang tiasa dipendakan dina standar acara Viewer. Tapi aya hiji nyekel: nurutkeun tradisi lila, Windows teu log téks lengkep kasalahan, tapi ngan jumlah na. Salaku conto, kasalahan 5 nyaéta "Aksés ditolak", sareng 1722 mangrupikeun "Server RPC henteu sayogi", sareng 10060 mangrupikeun "Koneksi parantos kaluar". Tangtosna, éta saé upami anjeun émut anu paling kasohor, tapi kumaha upami anu teu katingali?
Sareng supados kahirupan henteu siga madu, kasalahan ogé disimpen dina bentuk héksadesimal, kalayan awalan 0x8007. Contona, 0x8007000e sabenerna 14, Out of Memory. Naha sareng kanggo saha ieu dilakukeun mangrupikeun misteri anu diselimuti gelap. Tapi, daptar lengkep kasalahan tiasa diunduh gratis sareng tanpa SMS ti .
Ku jalan kitu, kadang aya awalan sejen, teu ngan 0x8007. Dina kaayaan hanjelu sapertos kitu, supados ngartos HRESULT ("hasil cecekelan"), anjeun kedah langkung jero. pikeun pamekar. Dina kahirupan biasa, kuring henteu mamatahan anjeun ngalakukeun ieu, tapi upami anjeun ujug-ujug pencét témbok atanapi ngan panasaran, ayeuna anjeun terang naon anu kudu dilakukeun.
Tapi comrades di Microsoft nyandak karunya ka urang saeutik tur némbongkeun dunya utiliti a . Ieu sapotong leutik kabagjaan konsol nu bisa narjamahkeun Konci kasalahan kana manusa tanpa ngagunakeun Google. Gawéna kawas kieu.
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"Patarosan anu sah timbul: naha urang henteu langsung nyerat dekripsi kana log, tapi ngantepkeun kodeu misterius ieu? Jawabanna aya dina aplikasi pihak katilu. Lamun anjeun narik sababaraha WinAPI nelepon diri, teu hese decipher respon na, sabab aya malah hiji panggero WinAPI husus pikeun ieu. Tapi sakumaha anu parantos disebatkeun, sadayana anu ngan ukur sumping ka urang dina réspon asup kana log urang. Sareng di dieu, pikeun ngadekrip éta, anjeun kedah terus-terusan ngawas aliran kasadaran ieu, narik potongan-potongan tina kasalahan Windows, ngadekrip aranjeunna sareng nempelkeun deui. Jujur, sanés kagiatan anu paling seru.
Windows File Manajemén API dianggo dina sagala cara anu mungkin nalika damel sareng file. Nyiptakeun file, ngahapus, muka tulisan, damel sareng atribut, sareng saterasna.
disebutkeun di luhur PowerShell Direct salaku analog tina API VIX di dunya Hyper-V. Hanjakal, teu jadi fléksibel: loba larangan dina pungsionalitasna, teu jalan kalawan unggal vérsi host teu jeung sakabeh tamu.
RPC (Telepon Prosedur Jauh) Ku teu sangka aya hiji jalma anu geus digarap kalawan Windows anu teu katempo kasalahan nu patali RPC. Sanajan misconception populér, ieu lain protokol tunggal, tapi sagala protokol klien-server nu satisfies sababaraha parameter. Nanging, upami aya kasalahan RPC dina log urang, 90% waktos éta mangrupikeun kasalahan tina Microsoft RPC, anu mangrupikeun bagian tina DCOM (Model Objék Komponen Terdistribusi). Anjeun tiasa mendakan jumlah ageung dokuméntasi dina topik ieu dina net, tapi bagian singa tina éta rada luntur. Tapi upami aya kahayang anu parah pikeun diajar topik, maka kuring tiasa nyarankeun tulisan , jeung daptar panjang .
Anu jadi sabab utama kasalahan RPC dina log urang gagal pikeun komunikasi antara komponén VBR (server> proxy, contona) jeung paling sering alatan masalah komunikasi.
Puncak luhur diantara sadaya puncak nyaéta kasalahan The RPC server teu sadia (1722). Dina istilah basajan, klien nu teu bisa nyieun sambungan kalawan server. Kumaha jeung naha - euweuh jawaban tunggal, tapi biasana mangrupa masalah jeung auténtikasi atawa kalayan aksés jaringan ka port 135. Kiwari dimungkinkeun has pikeun infrastruktur kalawan ngerjakeun port dinamis. Dina topik ieu, aya malah . Sareng Microsoft gaduh pikeun manggihan sabab gagalna.
Kasalahan anu paling populér kadua: Henteu aya deui titik tungtung anu sayogi ti mapper titik tungtung (1753). Klién atanapi server RPC gagal netepkeun port sorangan. Biasana lumangsung nalika server (dina hal urang, mesin tamu) geus ngonpigurasi pikeun dinamis allocate palabuhan ti rentang sempit nu geus réngsé. Sareng upami anjeun log in ti sisi klien (dina kasus urang, server VBR), ieu hartosna VeeamVssAgent kami henteu ngamimitian atanapi henteu kadaptar salaku antarmuka RPC. Aya ogé dina topik ieu .
Nya, pikeun ngarengsekeun kasalahan RPC Top 3, hayu urang émut yén panggero fungsi RPC gagal (1726). Nembongan lamun sambungan geus ngadegkeun, tapi requests RPC teu diolah. Salaku conto, urang nyuhunkeun inpormasi ngeunaan status VSS (ujug-ujug ayeuna aya tambang kalangkang didinya, sareng urang nyobian nanjak), sareng ngaréspon ka urang, tiiseun sareng teu malire.
Windows Tape Nyadangkeun API diperlukeun pikeun digawe sareng perpustakaan tape atawa drive. Sakumaha anu kuring nyarios di awal: urang henteu resep nyerat supir urang nyalira teras sangsara kalayan dukungan unggal alat. Ku alatan éta, vim teu boga supir sorangan. Sadayana ngalangkungan API standar, dukungan anu dilaksanakeun ku padagang hardware sorangan. Janten langkung logis, leres?
SMB / CIFS Kusabab kabiasaan, unggal jalma nyeratna babarengan, sanaos henteu sadayana émut yén CIFS (Common Internet File System) mangrupikeun versi pribadi tina SMB (Server Message Block). Janten teu aya anu lepat sareng ngageneralisasikeun konsép-konsép ieu. Samba geus mangrupa palaksanaan LinuxUnix, sarta eta boga peculiarities sorangan, tapi kuring digress. Anu penting di dieu: nalika Veeam naroskeun nyerat kana jalur UNC (serverdirectory), server nganggo hirarki supir sistem file, kalebet mup sareng mrxsmb, pikeun nyerat kana bal. Sasuai, supir ieu ogé bakal ngahasilkeun kasalahan.
Teu bisa ngalakukeun tanpa Winsock API. Upami aya anu kedah dilakukeun dina jaringan, VBR tiasa dianggo ngalangkungan Windows Socket API, anu katelah Winsock. Janten upami urang ningali sakumpulan IP: Port dina log, ieu mangrupikeun. Dokuméntasi resmi ngagaduhan daptar kamungkinan anu saé .
disebutkeun di luhur WMI (Windows Management Instrumentation) mangrupikeun jinis API anu maha kawasa pikeun ngatur sadayana sareng sadayana di dunya Windows. Salaku conto, nalika damel sareng Hyper-V, ampir sadaya pamundut ka host ngalangkunganana. Dina kecap, hal ieu kacida irreplaceable sarta pohara kuat dina kamampuhan na. Dina usaha pikeun mantuan manggihan dimana jeung naon nu pegat, diwangun-di WBEMtest.exe alat mantuan pisan.
Sareng anu terakhir dina daptar, tapi henteu penting pisan - VSS (Jilid Panyimpenan Kalangkang). Topikna teu kaampeuh sareng misterius sakumaha seueur dokuméntasi anu ditulis dina éta. Shadow Copy paling saukur dipikaharti salaku tipe husus tina snapshot, nu dina panggih téh. Hatur nuhun ka anjeunna, anjeun tiasa ngadamel cadangan aplikasi-konsisten di VMware, sarta ampir sagalana di Hyper-V. Kuring boga rencana pikeun nyieun artikel misah kalawan sababaraha squeeze on VSS, tapi pikeun ayeuna anjeun tiasa nyobian maca . Ngan ati-ati, sabab. nyobian ngartos VSS dina lampu kilat bisa ngakibatkeun tatu otak.
Dina ieu, meureun, urang bisa eureun. Kuring nganggap tugas ngajelaskeun hal-hal anu paling dasar parantos réngsé, janten dina bab salajengna urang bakal ningali log. Tapi lamun anjeun mibanda patalékan, ngarasa Luncat nanya dina komentar.
sumber: www.habr.com