नोंदी कुठून येतात? Veeam लॉग डायव्हिंग

आम्ही अंदाज लावण्याच्या आकर्षक जगात आमचे विसर्जन सुरू ठेवतो ... लॉगद्वारे समस्यानिवारण. IN मागील लेख आम्ही मूलभूत अटींच्या अर्थावर सहमत झालो आणि वीमची एकंदर रचना एका डोळ्याने एकच अनुप्रयोग म्हणून पाहिली. लॉग फाइल्स कशा तयार होतात, त्यामध्ये कोणत्या प्रकारची माहिती प्रदर्शित केली जाते आणि ते जसे दिसतात तसे का दिसतात हे शोधणे हे यासाठीचे कार्य आहे.

हे "लॉग" काय आहेत असे तुम्हाला वाटते? बहुतेकांच्या मते, कोणत्याही अनुप्रयोगाच्या नोंदींना सर्वशक्तिमान घटकाची भूमिका नियुक्त केली पाहिजे जी बहुतेक वेळा घरामागील अंगणात कुठेतरी वनस्पती करते, परंतु योग्य क्षणी चमकदार चिलखत कोठेही दिसते आणि प्रत्येकाला वाचवते. म्हणजेच, त्यामध्ये प्रत्येक घटकातील किरकोळ त्रुटींपासून वैयक्तिक डेटाबेस व्यवहारांपर्यंत सर्व काही असले पाहिजे. आणि म्हणून त्रुटी नंतर ते कसे दुरुस्त करायचे ते लगेच लिहिले गेले. आणि हे सर्व काही मेगाबाइट्समध्ये बसले पाहिजे, आणखी नाही. तो फक्त मजकूर आहे! मजकूर फाइल्स दहापट गीगाबाइट घेऊ शकत नाहीत, मी ते कुठेतरी ऐकले आहे!

त्यामुळे नोंदी

वास्तविक जगात, लॉग हे फक्त निदान माहितीचे संग्रहण आहेत. आणि तिथे काय साठवायचे, स्टोरेजसाठी माहिती कोठे मिळवायची आणि ती किती तपशीलवार असावी, हे विकसकांनी स्वतः ठरवायचे आहे. कोणीतरी चालू/बंद पातळीच्या नोंदी ठेवून मिनिमलिझमचा मार्ग अवलंबतो, आणि कोणीतरी आपल्यापर्यंत पोहोचू शकतील अशा सर्व गोष्टी परिश्रमपूर्वक तयार करतो. तथाकथित लॉगिंग स्तर निवडण्याच्या क्षमतेसह एक मध्यवर्ती पर्याय देखील आहे, जेव्हा तुम्ही स्वतः सूचित करता की तुम्हाला किती तपशीलवार माहिती संग्रहित करायची आहे आणि तुमच्याकडे किती अतिरिक्त डिस्क जागा आहे =) VBR मध्ये असे सहा स्तर आहेत. आणि, माझ्यावर विश्वास ठेवा, आपल्या डिस्कवरील मोकळ्या जागेसह सर्वात तपशीलवार लॉगिंगसह काय होते ते आपण पाहू इच्छित नाही.

दंड. आम्हाला काय वाचवायचे आहे हे आम्हाला अंदाजे समजले आहे, परंतु एक कायदेशीर प्रश्न उद्भवतो: ही माहिती कोठून मिळवायची? अर्थात, आम्ही आमच्या अंतर्गत प्रक्रियांद्वारे स्वतःला लॉग इन करण्यासाठी इव्हेंटचा भाग बनवतो. पण जेव्हा बाह्य वातावरणाशी संवाद साधला जातो तेव्हा काय करावे? क्रॅच आणि सायकलींच्या नरकात सरकू नये म्हणून, Veeam आधीच शोध लावलेले शोध लावू नये. जेव्हा जेव्हा एखादे रेडीमेड API, अंगभूत फंक्शन, लायब्ररी इ. असेल तेव्हा आम्ही आमच्या कॉन्ट्रॅप्शनला कुंपण घालण्याआधी रेडीमेड पर्यायांना प्राधान्य देऊ. जरी नंतरचे देखील पुरेसे आहे. म्हणून, लॉगचे विश्लेषण करताना, हे समजून घेणे महत्त्वाचे आहे की त्रुटींचा मोठा वाटा तृतीय-पक्ष API, सिस्टम कॉल आणि इतर लायब्ररींच्या संदेशांवर येतो. या प्रकरणात, VBR ची भूमिका या त्रुटींना लॉग फाइल्समध्ये अग्रेषित करण्यासाठी खाली येते. आणि वापरकर्त्याचे मुख्य कार्य म्हणजे कोणती ओळ कोणाची आहे आणि हे "कोण" कशासाठी जबाबदार आहे हे समजून घेणे शिकणे आहे. त्यामुळे जर VBR लॉगमधील एरर कोड तुम्हाला MSDN पेजवर घेऊन गेला, तर ते ठीक आणि बरोबर आहे.

आम्ही आधी मान्य केल्याप्रमाणे: Veeam एक तथाकथित SQL-आधारित अनुप्रयोग आहे. याचा अर्थ असा की सर्व सेटिंग्ज, सर्व माहिती आणि सर्वसाधारणपणे सर्वकाही जे फक्त सामान्य कार्यासाठी आवश्यक आहे - सर्वकाही त्याच्या डेटाबेसमध्ये संग्रहित केले आहे. त्यामुळे साधे सत्य: जे लॉगमध्ये नाही ते बहुधा डेटाबेसमध्ये असते. परंतु ही चांदीची बुलेट देखील नाही: काही गोष्टी Veeam घटकांच्या स्थानिक लॉगमध्ये किंवा त्याच्या डेटाबेसमध्ये नाहीत. म्हणून, तुम्हाला यजमान लॉग, स्थानिक मशीनचे लॉग आणि बॅकअप आणि पुनर्संचयित प्रक्रियेत समाविष्ट असलेल्या प्रत्येक गोष्टीचे लॉग कसे अभ्यासायचे हे शिकण्याची आवश्यकता आहे. आणि असेही घडते की आवश्यक माहिती कुठेही उपलब्ध नसते. तो मार्ग आहे. 

अशा API ची काही उदाहरणे

ही यादी अपवादात्मकपणे पूर्ण होण्याचे उद्दिष्ट नाही, त्यामुळे त्यात अंतिम सत्य शोधण्याची गरज नाही. त्याचा उद्देश फक्त आमच्या उत्पादनांमध्ये वापरल्या जाणार्‍या सर्वात सामान्य तृतीय-पक्ष API आणि तंत्रज्ञान दर्शविणे आहे.

चला सुरुवात करूया व्हीएमवेअर. 

यादीत पहिले असेल vSphere API. प्रमाणीकरण, पदानुक्रम वाचणे, स्नॅपशॉट तयार करणे आणि हटवणे, मशीनबद्दल माहितीची विनंती करणे आणि बरेच काही (खूप काही) यासाठी वापरले जाते. सोल्यूशनची कार्यक्षमता खूप विस्तृत आहे, म्हणून मी आवृत्तीसाठी VMware vSphere API संदर्भाची शिफारस करू शकतो. 5.5 и 6.0. अधिक वर्तमान आवृत्त्यांसाठी, सर्वकाही फक्त Google केले आहे.

VIX API. हायपरवाइजरची काळी जादू, ज्यासाठी वेगळे आहे त्रुटी यादी. नेटवर्कवर कनेक्ट न करता होस्टवरील फाइल्ससह कार्य करण्यासाठी VMware API. शेवटचा उपाय पर्याय जेव्हा तुम्हाला एखाद्या मशीनमध्ये फाइल ठेवण्याची आवश्यकता असते ज्यामध्ये कोणतेही चांगले संप्रेषण चॅनेल नाही. जर फाइल मोठी असेल आणि होस्ट लोड असेल तर वेदना आणि त्रास होतो. परंतु येथे नियम कार्य करतो की 56,6 Kb/s देखील 0 Kb/s पेक्षा चांगले आहे. हायपर-व्ही मध्ये, या गोष्टीला पॉवरशेल डायरेक्ट म्हणतात. पण ते फक्त आधी होते

vSpehere वेब सेवा API vSphere 6.0 पासून प्रारंभ करून (अंदाजे, हे API प्रथम आवृत्ती 5.5 वर सादर केले गेले होते) याचा वापर अतिथी मशीनसह कार्य करण्यासाठी केला जातो आणि जवळजवळ सर्वत्र VIX बदलला आहे. खरं तर, vSphere व्यवस्थापित करण्यासाठी हे दुसरे API आहे. ज्यांना स्वारस्य आहे त्यांच्यासाठी मी अभ्यास करण्याची शिफारस करतो छान मॅन्युअल 

VDDK (व्हर्च्युअल डिस्क डेव्हलपमेंट किट). यामध्ये अर्धवट चर्चा झालेल्या वाचनालयाची लेख. आभासी डिस्क वाचण्यासाठी वापरले जाते. एकेकाळी तो व्हीआयएक्सचा भाग होता, परंतु कालांतराने ते वेगळ्या उत्पादनात हलविण्यात आले. परंतु वारस म्हणून, ते VIX सारखेच त्रुटी कोड वापरते. परंतु काही कारणास्तव, SDK मध्येच या त्रुटींचे कोणतेही वर्णन नाही. त्यामुळे, इतर कोडसह व्हीडीडीके त्रुटी केवळ बायनरी ते दशांश कोडचे भाषांतर आहेत हे प्रायोगिकरित्या आढळून आले. यात दोन भाग आहेत - पहिला अर्धा भाग संदर्भाविषयी अदस्तांकित माहिती आहे आणि दुसरा भाग पारंपारिक VIX / VDDK त्रुटी आहे. उदाहरणार्थ, जर आपण पाहतो:

VDDK error: 21036749815809.Unknown error

मग आम्ही धैर्याने हे हेक्समध्ये रूपांतरित करतो आणि 132200000001 मिळवतो. आम्ही फक्त 132200 ची माहिती नसलेली सुरुवात टाकून देतो, आणि उरलेला आमचा त्रुटी कोड असेल (VDDK 1: अज्ञात त्रुटी). सर्वाधिक वारंवार होणाऱ्या VDDK त्रुटींबद्दल, नुकतेच एक वेगळे होते लेख.

आता बघूया विन्डोज.

येथे, आमच्यासाठी सर्वात आवश्यक आणि महत्त्वपूर्ण असलेली प्रत्येक गोष्ट मानकांमध्ये आढळू शकते कार्यक्रम दर्शक. परंतु एक कॅच आहे: दीर्घ परंपरेनुसार, विंडोज त्रुटीचा संपूर्ण मजकूर लॉग करत नाही, परंतु फक्त त्याची संख्या. उदाहरणार्थ, त्रुटी 5 आहे “प्रवेश नाकारला”, आणि 1722 “RPC सर्व्हर अनुपलब्ध आहे” आणि 10060 “कनेक्शन कालबाह्य” आहे. नक्कीच, जर तुम्हाला सर्वात प्रसिद्ध आठवत असेल तर ते छान आहे, परंतु आतापर्यंत न पाहिलेल्यांचे काय? 

आणि त्यामुळे जीवन अजिबात मधासारखे वाटत नाही, त्रुटी देखील हेक्साडेसिमल स्वरूपात 0x8007 उपसर्गासह संग्रहित केल्या जातात. उदाहरणार्थ, 0x8007000e प्रत्यक्षात 14, मेमरीबाहेर आहे. हे का आणि कोणासाठी केले गेले हे एक गूढ अंधारात आहे. तथापि, त्रुटींची संपूर्ण यादी विनामूल्य आणि एसएमएसशिवाय डाउनलोड केली जाऊ शकते डेव्हसेंटर.

तसे, काहीवेळा इतर उपसर्ग आहेत, फक्त 0x8007 नाही. अशा दु:खद परिस्थितीत, HRESULT ("रिझल्ट हँडल") समजून घेण्यासाठी, तुम्हाला आणखी खोलवर जावे लागेल दस्तऐवजीकरण विकसकांसाठी. सामान्य जीवनात, मी तुम्हाला असे करण्याचा सल्ला देत नाही, परंतु जर तुम्ही अचानक भिंतीवर दाबले किंवा फक्त उत्सुक असाल तर आता तुम्हाला काय करावे हे माहित आहे.

पण मायक्रोसॉफ्टच्या कॉम्रेड्सना आमची थोडी दया आली आणि त्यांनी जगाला एक उपयुक्तता दाखवली ERR. हा कन्सोल आनंदाचा एक छोटासा तुकडा आहे जो Google न वापरता एरर कोड मानवामध्ये अनुवादित करू शकतो. हे असे कार्य करते.

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"

एक कायदेशीर प्रश्न उद्भवतो: आम्ही लॉगवर त्वरित डिक्रिप्शन का लिहित नाही, परंतु हे रहस्यमय कोड का सोडत नाही? उत्तर तृतीय-पक्ष अनुप्रयोगांमध्ये आहे. जेव्हा तुम्ही स्वतःला काही WinAPI कॉल खेचता, तेव्हा त्याच्या प्रतिसादाचा उलगडा करणे कठीण नसते, कारण यासाठी एक विशेष WinAPI कॉल देखील आहे. पण आधीच नमूद केल्याप्रमाणे, फक्त प्रतिसादांमध्ये जे काही आम्हाला येते ते आमच्या नोंदींमध्ये येते. आणि येथे, ते डिक्रिप्ट करण्यासाठी, एखाद्याला सतत जाणीवेच्या या प्रवाहाचे निरीक्षण करावे लागेल, त्यातून विंडोज त्रुटी असलेले तुकडे काढावे लागतील, ते डिक्रिप्ट करावे लागेल आणि त्यांना परत पेस्ट करावे लागेल. चला प्रामाणिक राहा, सर्वात रोमांचक क्रियाकलाप नाही.

विंडोज फाइल व्यवस्थापन API फाइल्ससह कार्य करताना प्रत्येक संभाव्य मार्गाने वापरले जाते. फाइल्स तयार करणे, हटवणे, लिहिण्यासाठी उघडणे, गुणधर्मांसह कार्य करणे आणि असेच बरेच काही.

वर उल्लेख केला आहे पॉवरशेल डायरेक्ट हायपर-व्ही जगामध्ये VIX API चे अॅनालॉग म्हणून. दुर्दैवाने, इतके लवचिक नाही: कार्यक्षमतेवर बरेच निर्बंध, ते होस्टच्या प्रत्येक आवृत्तीसह कार्य करत नाही आणि सर्व अतिथींसह नाही.

जनता सरकारच्या (रिमोट प्रोसिजर कॉल) मला वाटत नाही की असा एकही व्यक्ती आहे ज्याने Windows सह काम केले आहे ज्याने RPC-संबंधित त्रुटी पाहिल्या नाहीत. लोकप्रिय गैरसमज असूनही, हा एकच प्रोटोकॉल नाही, परंतु कोणताही क्लायंट-सर्व्हर प्रोटोकॉल आहे जो अनेक पॅरामीटर्सचे समाधान करतो. तथापि, आमच्या नोंदींमध्ये RPC त्रुटी असल्यास, 90% वेळा ती Microsoft RPC ची त्रुटी असेल, जी DCOM (वितरित घटक ऑब्जेक्ट मॉडेल) चा भाग आहे. या विषयावर तुम्हाला नेटवर मोठ्या प्रमाणात दस्तऐवज सापडतील, परंतु त्यातील सिंहाचा वाटा खूपच जुना आहे. परंतु जर या विषयाचा अभ्यास करण्याची तीव्र इच्छा असेल तर मी लेखांची शिफारस करू शकतो RPC म्हणजे काय?, कसे RPC कामे आणि लांब यादी RPC त्रुटी.

आमच्या लॉगमधील RPC त्रुटींची मुख्य कारणे म्हणजे VBR घटक (सर्व्हर > प्रॉक्सी, उदाहरणार्थ) दरम्यान संवाद साधण्याचे अयशस्वी प्रयत्न आणि बहुतेकदा संप्रेषण समस्यांमुळे.

सर्व शीर्षांमध्ये शीर्षस्थानी त्रुटी आहे RPC सर्व्हर अनुपलब्ध आहे (1722). सोप्या भाषेत, क्लायंट सर्व्हरशी कनेक्शन स्थापित करू शकत नाही. कसे आणि का - कोणतेही एकच उत्तर नाही, परंतु सामान्यतः प्रमाणीकरण किंवा पोर्ट 135 वर नेटवर्क प्रवेशासह समस्या असते. नंतरचे डायनॅमिक पोर्ट असाइनमेंट असलेल्या पायाभूत सुविधांसाठी वैशिष्ट्यपूर्ण आहे. या विषयावर, सम आहे वेगळे HF. आणि मायक्रोसॉफ्टकडे आहे प्रचंड मार्गदर्शक अपयशाचे कारण शोधण्यासाठी.

दुसरी सर्वात लोकप्रिय त्रुटी: एंडपॉइंट मॅपर (1753) वरून आणखी कोणतेही एंडपॉइंट उपलब्ध नाहीत. RPC क्लायंट किंवा सर्व्हर स्वतःला एक पोर्ट नियुक्त करण्यात अयशस्वी झाले. सामान्यतः जेव्हा सर्व्हर (आमच्या बाबतीत, अतिथी मशीन) संपलेल्या अरुंद श्रेणीतील पोर्ट डायनॅमिकपणे वाटप करण्यासाठी कॉन्फिगर केले जाते तेव्हा उद्भवते. आणि जर तुम्ही क्लायंटच्या बाजूने लॉग इन केले (आमच्या बाबतीत, VBR सर्व्हर), याचा अर्थ आमचा VeeamVssAgent एकतर सुरू झाला नाही किंवा RPC इंटरफेस म्हणून नोंदणीकृत नाही. या विषयावर देखील आहे वेगळे HF.

बरं, शीर्ष 3 RPC त्रुटी पूर्ण करण्यासाठी, RPC फंक्शन कॉल अयशस्वी (1726) लक्षात ठेवूया. कनेक्शन स्थापित केले असल्यास दिसते, परंतु RPC विनंत्यांवर प्रक्रिया केली जात नाही. उदाहरणार्थ, आम्ही व्हीएसएसच्या स्थितीबद्दल माहितीची विनंती करतो (अचानक आत्ता तिथे सावलीची खाण बनवली जात आहे, आणि आम्ही चढण्याचा प्रयत्न करीत आहोत), आणि आम्हाला प्रतिसाद म्हणून, गप्प बसतो आणि दुर्लक्ष करतो.

विंडोज टेप बॅकअप API टेप लायब्ररी किंवा ड्राइव्हसह कार्य करणे आवश्यक आहे. मी सुरुवातीला म्हटल्याप्रमाणे: आम्हाला आमचे स्वतःचे ड्रायव्हर्स लिहिण्यात आणि नंतर प्रत्येक उपकरणाच्या आधाराने त्रास देण्यात आनंद नाही. म्हणून, विमकडे स्वतःचे कोणतेही चालक नाहीत. सर्व एक मानक API द्वारे, ज्याचे समर्थन स्वतः हार्डवेअर विक्रेत्यांद्वारे लागू केले जाते. खूप जास्त तार्किक, बरोबर?

एसएमबी / सीआयएफएस सवयीमुळे, प्रत्येकजण त्यांना शेजारी लिहितो, जरी प्रत्येकाला हे आठवत नाही की CIFS (कॉमन इंटरनेट फाइल सिस्टम) SMB (सर्व्हर मेसेज ब्लॉक) ची फक्त खाजगी आवृत्ती आहे. त्यामुळे या संकल्पनांचे सामान्यीकरण करण्यात काहीच गैर नाही. सांबा आधीच LinuxUnix अंमलबजावणी आहे, आणि त्याचे स्वतःचे वैशिष्ठ्य आहे, परंतु मी विचार करतो. येथे काय महत्त्वाचे आहे: जेव्हा Veeam UNC पथ (serverdirectory) वर काहीतरी लिहिण्यास सांगतो, तेव्हा सर्व्हर बॉलवर लिहिण्यासाठी mup आणि mrxsmb सह फाइल सिस्टम ड्रायव्हर्सच्या पदानुक्रमाचा वापर करतो. त्यानुसार या चालकांकडून त्रुटीही निर्माण होतील.

शिवाय करू शकत नाही Winsock API. नेटवर्कवर काही करणे आवश्यक असल्यास, VBR विंडोज सॉकेट API द्वारे कार्य करते, जे विन्सॉक म्हणून प्रसिद्ध आहे. म्हणून जर आपल्याला लॉगमध्ये IP:पोर्टचा एक समूह दिसला, तर हे आहे. अधिकृत कागदपत्रांमध्ये शक्यतेची चांगली यादी आहे चुका.

वर उल्लेख केला आहे WMI (विंडोज मॅनेजमेंट इंस्ट्रुमेंटेशन) हे विंडोजच्या जगातील प्रत्येक गोष्टीचे आणि प्रत्येकाचे व्यवस्थापन करण्यासाठी एक प्रकारचे सर्वशक्तिमान API आहे. उदाहरणार्थ, हायपर-व्ही सह काम करताना, होस्टला जवळजवळ सर्व विनंत्या त्याद्वारे जातात. एका शब्दात, गोष्ट पूर्णपणे न भरता येणारी आणि त्याच्या क्षमतांमध्ये खूप शक्तिशाली आहे. कुठे आणि काय तुटले आहे हे शोधण्यात मदत करण्याच्या प्रयत्नात, अंगभूत WBEMtest.exe टूल खूप मदत करते.

आणि यादीत शेवटचे, परंतु कोणत्याही अर्थाने किमान महत्त्व नाही - व्हीएसएस (व्हॉल्यूम शॅडो स्टोरेज). हा विषय जितका अक्षम्य आणि अनाकलनीय आहे तितकाच कागदोपत्री त्यावर लिहिला गेला आहे. शॅडो कॉपी हा एक विशेष प्रकारचा स्नॅपशॉट म्हणून समजला जातो, जो थोडक्यात आहे. त्याला धन्यवाद, तुम्ही VMware मध्ये ऍप्लिकेशन-सुसंगत बॅकअप बनवू शकता आणि हायपर-V मध्ये जवळजवळ सर्व काही. व्हीएसएस वर थोडासा दाब देऊन एक वेगळा लेख बनवायचा माझा विचार आहे, पण आत्ता तुम्ही वाचण्याचा प्रयत्न करू शकता हे वर्णन. फक्त काळजी घ्या, कारण. फ्लॅशमध्ये VSS समजून घेण्याचा प्रयत्न केल्याने मेंदूला इजा होऊ शकते.

यावर, कदाचित, थांबणे शक्य आहे. मी पूर्ण झालेल्या मूलभूत गोष्टींचे स्पष्टीकरण देण्याचे कार्य विचारात घेतो, म्हणून पुढील अध्यायात आपण नोंदी पाहणार आहोत. परंतु आपल्याकडे अद्याप प्रश्न असल्यास, टिप्पण्यांमध्ये त्यांना मोकळ्या मनाने आवाज द्या.

स्त्रोत: www.habr.com