इससे पहले कि आप SQL सर्वर मॉनिटरिंग टूल को देखना शुरू करें, अपने विशिष्ट परिवेश के बारे में सोचें:
- आप कितने उदाहरणों की निगरानी करना चाहते हैं?
- क्या ये एक स्थान पर हैं या बिखरे हुए हैं?
- क्या आपको ऑपरेटिंग सिस्टम और/या हाइपरवाइजर की निगरानी करने की आवश्यकता है?
- अपने उदाहरण के संचालन की सीमाओं की सटीक तस्वीर प्राप्त करने के लिए आपको कितने इतिहास की आवश्यकता है?
- क्या वे सभी ऑन-प्रिमाइसेस हैं या कुछ क्लाउड में हैं?
- क्या आपकी टीमें वितरित हैं?
- क्या आप पूंजीगत व्यय या परिचालन व्यय बजट के तहत सॉफ़्टवेयर खरीदते हैं?
- क्या आप बुनियादी ढांचे और लाइसेंस पर एकमुश्त निवेश कर सकते हैं या क्या आप समय के साथ अपनी लागतों को फैलाना पसंद करते हैं?
- क्या आपके पास निगरानी उपकरण को समर्पित करने के लिए आधारभूत संरचना और डेटाबेस उदाहरण उपलब्ध हैं?
- क्या आपके पास निगरानी के बुनियादी ढांचे के निर्माण के लिए समय है?
- क्या आपकी टीम में लगातार उच्च विशेषज्ञता है?
- क्या आप प्रारंभिक परीक्षण के लिए कनिष्ठ संसाधनों का उपयोग करते हैं या हर चीज के लिए अपने विशेषज्ञों पर निर्भर हैं?
- क्या आपके पास निगरानी के बुनियादी ढांचे को बनाए रखने के लिए आंतरिक रूप से समय या संसाधन हैं?
क्या मुझे अपना रोल करना चाहिए?
मैं यहां अपने पूर्वाग्रह की घोषणा कर सकता हूं। क्वेस्ट सॉफ्टवेयर पिछले 20 वर्षों से प्रदर्शन निगरानी उपकरण बना रहा है। हम और हमारे जैसे कई अन्य लोग इतने लंबे समय से इस सेगमेंट में बने हुए हैं और हमारे पास बढ़ते ग्राहक आधार क्यों हैं, इसका एक उत्कृष्ट कारण है। प्रदर्शन की निगरानी अच्छी तरह से करना आसान नहीं है!
कुछ का उल्लेख करने के लिए PerfMon, ट्रेस, DMV और XEvents का उपयोग करके SQL सर्वर से मेट्रिक्स इकट्ठा करने के कुछ शानदार तरीके हैं। किसी एक मुद्दे के लिए एक बार के आधार पर ऐसा करना अच्छा और अच्छा है—यदि आपके पास इस शोध में निवेश करने का समय है कि उस मुद्दे के लिए डेटा कहां और कैसे एकत्र किया जाए। एक बार जब मुद्दे बढ़ने लगते हैं और उदाहरणों की संख्या बढ़ जाती है, तो यह तेजी से अस्थिर हो जाता है।
आपके SQL सर्वर के प्रदर्शन स्वास्थ्य की पूरी तस्वीर प्राप्त करने के लिए कई सौ मीट्रिक उपलब्ध हैं जो ट्रैकिंग के लायक हैं। इसके अलावा, एक SQL कोड है जो चलता है और क्वेरी योजनाएँ उसी के प्रत्येक निष्पादन से जुड़ी होती हैं। कुछ मेट्रिक्स हर सेकंड, कुछ हर घंटे और कुछ कोड के निष्पादन के आधार पर एकत्र किए जाने चाहिए। कुछ संग्रह विधियां मॉनिटर किए गए उदाहरण को प्रभावित कर सकती हैं और इनसे बचा जाना चाहिए।
प्रत्येक मीट्रिक की अलग-अलग सीमाएँ होंगी जो उसकी स्थिति को परिभाषित करेंगी। विशेष उदाहरणों में ऐसे स्तर हो सकते हैं जो गैरमानक हों। फिर आपको यह सब स्टोर करना होगा। डेटा की मात्रा बहुत तेजी से जुड़ती है। आपको नियमित आधार पर विस्तृत डेटा को शुद्ध करने के लिए एक रणनीति बनानी होगी और फिर, यदि ट्रेंडिंग के लिए आवश्यक हो, तो रिपोर्टिंग के लिए इस डेटा को एकत्रित करें।
यह बहुत काम है ... और निश्चित रूप से, हर बार एक नया SQL सर्वर संस्करण सामने आता है, इससे निपटने के लिए आपके पास एक प्रतिगमन सिरदर्द होता है। जब तक आप वास्तव में एक निगरानी उपकरण बेचना नहीं चाहते हैं, मैं दृढ़ता से सलाह दूंगा कि आप अपना खुद का रोल न करें जब तक कि मुद्दों की मात्रा कम न हो और जिन समस्याओं को आपको हल करना है वे बहुत विशिष्ट हों।
निःशुल्क टूल के बारे में क्या?
नि:शुल्क उपकरण अक्सर विचार करने योग्य होते हैं, खासकर कम महत्वपूर्ण उदाहरणों वाली छोटी टीमों के लिए। इसे "अपना खुद का रोल" करने के बाद स्केलेबिलिटी की सीढ़ी के अगले चरण के रूप में सोचें। कई एंट्री-लेवल कमर्शियल SQL सर्वर मॉनिटरिंग टूल्स में समान विचार होने चाहिए। निम्नलिखित पर विचार करें:
- क्या आपके मॉनिटर किए गए इंस्टेंस में उपयोग के सभी मामलों के लिए आपको पर्याप्त कवरेज देने के लिए टूल में पर्याप्त मीट्रिक शामिल हैं? कई मुफ़्त टूल आपकी खुद की मेट्रिक्स जोड़ने के लिए किसी प्रकार का "कस्टमाइज़ेशन" देंगे। जब "कस्टमाइज़ेशन" का उपयोग कार्यक्षमता में अंतराल को भरने के लिए किया जा रहा है, तो आप जल्दी से अपनी टीम को आवश्यक व्याकुलता और रखरखाव सिरदर्द के साथ "अपना खुद का रोल" समाप्त करते हुए पाएंगे।
- क्या टूल अलर्ट करने का समर्थन करता है? क्या यह पूर्व-कॉन्फ़िगर है? अलर्ट कॉन्फ़िगर करना बहुत समय लेने वाला हो सकता है। किसी अन्य व्यक्ति के टूल को कॉन्फ़िगर करने में कई खोए हुए मानव-घंटे को रोकने के लिए आउट-ऑफ-बॉक्स अलर्टिंग आवश्यक है। इसे किनारे के मामलों के लिए अलर्ट के अनुकूलन की सुविधा भी देनी चाहिए जो डिफ़ॉल्ट के अनुरूप नहीं हैं।
- डेटा कैसे और कहाँ संग्रहीत किया जाता है? प्रदर्शन डेटा के भंडारण को प्रबंधित करने के लिए अधिकांश निःशुल्क टूल इसे आपके पास छोड़ देते हैं। क्लाउड विक्रेताओं से "मुक्त" निगरानी से सावधान रहें। वे भंडारण के लिए शुल्क लेते हैं, और यह तेजी से बड़ा और महंगा हो सकता है!
तो, हर तरह से, वहां मौजूद मुफ्त टूल का फायदा उठाएं। बस उनकी सीमाओं से अवगत रहें और अपनी टीम के भीतर क्लासिक विरोधी पैटर्न देखें, जैसे:
- समस्या को ठीक करने के लिए इसका उपयोग करने वाले टूल को ठीक करने या बनाए रखने में अधिक समय व्यतीत होता है
- बुनियादी ढांचे और भंडारण पर अधिक पैसा खर्च किया गया
- बहुत सारा डेटा लेकिन कोई जानकारी नहीं
- समस्याओं को हल करने के लिए निदान में पर्याप्त गहराई नहीं है
- आपकी आवश्यकताओं के अनुरूप पर्याप्त मापनीय नहीं है
यदि आप उपरोक्त में से कोई भी नोटिस करते हैं, तो यह एक अधिक मजबूत समाधान में अपग्रेड करने की आवश्यकता को इंगित करना चाहिए।
SQL सर्वर मॉनिटरिंग सिस्टम का विशिष्ट आर्किटेक्चर
पारंपरिक ऑन-प्रिमाइसेस समाधान या सेवा (सास) समाधान के रूप में होस्ट किए गए सॉफ़्टवेयर के लिए जाने पर विचार करते समय, मॉनिटरिंग एप्लिकेशन आर्किटेक्चर पर विचार करना सहायक होता है। यहां प्रमुख वास्तु घटकों का सारांश दिया गया है।
सास और ऑन-प्रिमाइसेस के बीच मुख्य विचलन इस बात से संबंधित है कि प्रदर्शन डेटा कहाँ संग्रहीत किया जाता है और कौन इस भंडार का प्रबंधन करता है। ऑन-प्रिमाइसेस समाधान के लिए, यह अंतिम उपयोगकर्ता की ज़िम्मेदारी है। ये भंडार तेजी से बढ़ सकते हैं, इसलिए इन्हें सावधानीपूर्वक प्रबंधित करने की आवश्यकता है। (अधिक नीचे) के लिए बुनियादी ढांचे की योजना और बजट बनाने की जरूरत है।
SQL सर्वर निगरानी के लिए SaaS समाधान में, इन प्रमुख अवसंरचना घटकों को आपके लिए होस्ट और प्रबंधित किया जाता है।
| पारंपरिक ऑन-प्रिमाइसेस समाधान | सास समाधान |
|
|
अधिक जानकारी के लिए, हमारे ब्लॉग, डेटाबेस मॉनिटरिंग सिस्टम आर्किटेक्चर देखें।
