ClusterControl 1.7.0 ने एक साहसिक नई सुविधा पेश की - एजेंट-आधारित निगरानी के लिए प्रोमेथियस के साथ एकीकरण। हमने इसे SCUMM (सेवरलिन्स क्लस्टरकंट्रोल यूनिफाइड मैनेजमेंट एंड मॉनिटरिंग) कहा है। पिछले संस्करणों में, निगरानी कार्य पूरी तरह से एजेंट रहित तरीके से किए गए थे। यदि आपको आश्चर्य है कि ClusterControl अपने निगरानी कार्यों को कैसे करता है, तो इस दस्तावेज़ीकरण पृष्ठ को देखें।
ProxySQL, एक उच्च प्रदर्शन रिवर्स-प्रॉक्सी जो MySQL प्रोटोकॉल को समझता है, आमतौर पर बैकएंड MySQL सेवा के प्रवेश द्वार के रूप में कार्य करने के लिए MySQL प्रतिकृति और गैलेरा क्लस्टर के शीर्ष पर बैठता है। इसे क्वेरी राउटर, क्वेरी फ़ायरवॉल, क्वेरी कैशिंग, ट्रैफ़िक डिस्पैचर और कई अन्य के रूप में कॉन्फ़िगर किया जा सकता है। ProxySQL अपने STATS स्कीमा के माध्यम से प्रमुख मेट्रिक्स को भी एकत्रित और उजागर करता है जो प्रदर्शन का विश्लेषण करने और यह समझने के लिए बहुत उपयोगी है कि वास्तव में पर्दे के पीछे क्या होता है। ProxySQL के बारे में अधिक जानने के लिए हमारे विस्तृत ट्यूटोरियल पर जाएँ।
इस ब्लॉग पोस्ट में, हम इस नए दृष्टिकोण के साथ ProxySQL उदाहरणों की गहराई से निगरानी करने जा रहे हैं। इस उदाहरण में, हमारे पास हमारे दो-नोड MySQL प्रतिकृति (1 मास्टर, 1 दास) के शीर्ष पर एक ProxySQL उदाहरण है, जिसे ClusterControl के माध्यम से तैनात किया गया है। हमारा उच्च-स्तरीय आर्किटेक्चर कुछ इस तरह दिखता है:
हमारे पास प्रॉक्सीएसक्यूएल इंस्टेंस में परिभाषित निम्नलिखित क्वेरी नियम भी हैं (केवल संदर्भ के लिए, एकत्रित निगरानी मेट्रिक्स को और नीचे समझने के लिए):
प्रोमेथियस को सक्षम करना
ClusterControl की एजेंट-आधारित निगरानी प्रति क्लस्टर सक्षम है। ClusterControl आपके लिए एक नया Prometheus सर्वर परिनियोजित कर सकता है, या किसी मौजूदा Prometheus सर्वर (अन्य क्लस्टर के लिए ClusterControl द्वारा परिनियोजित) का उपयोग कर सकता है। प्रोमेथियस को सक्षम करना बहुत सीधा है। बस ClusterControl पर जाएं -> क्लस्टर चुनें -> डैशबोर्ड -> एजेंट आधारित निगरानी सक्षम करें:
फिर, नए प्रोमेथियस सर्वर का आईपी पता या होस्टनाम निर्दिष्ट करें, या ड्रॉपडाउन से मौजूदा प्रोमेथियस होस्ट चुनें:
ClusterControl आवश्यक पैकेज (Prometheus सर्वर पर Prometheus, डेटाबेस पर निर्यातक और ProxySQL नोड्स) को स्थापित और कॉन्फ़िगर करेगा, Prometheus को डेटा स्रोत के रूप में कनेक्ट करेगा और UI में मॉनिटरिंग डेटा को विज़ुअलाइज़ करना शुरू करेगा।
एक बार परिनियोजन कार्य समाप्त हो जाने के बाद, आपको अगले भाग में दिखाए गए अनुसार डैशबोर्ड टैब तक पहुंचने में सक्षम होना चाहिए।
ProxySQL डैशबोर्ड
आप डैशबोर्ड टैब के अंतर्गत संबंधित क्लस्टर में जाकर ProxySQL डैशबोर्ड तक पहुंच सकते हैं। डैशबोर्ड ड्रॉपडाउन पर क्लिक करने से हमारे क्लस्टर (MySQL प्रतिकृति) से संबंधित डैशबोर्ड सूचीबद्ध हो जाएंगे। आप "लोड बैलेंसर्स" अनुभाग के अंतर्गत ProxySQL अवलोकन डैशबोर्ड पा सकते हैं:
ProxySQL के लिए कई पैनल हैं, उनमें से कुछ स्व-व्याख्यात्मक हैं। फिर भी, आइए एक-एक करके उनसे मिलें।
होस्टग्रुप आकार
होस्टग्रुप का आकार सभी होस्टग्रुप पर होस्ट की कुल संख्या है:
इस मामले में, हमारे पास दो मेजबान समूह हैं - 10 (लेखक) और 20 (पाठक)। होस्टग्रुप 10 में एक होस्ट (मास्टर) होता है जबकि होस्टग्रुप 20 में दो होस्ट (मास्टर और स्लेव) होते हैं, जो कुल तीन होस्ट तक होते हैं।
जब तक आप ProxySQL से होस्टग्रुप कॉन्फ़िगरेशन (नए होस्ट का परिचय, मौजूदा होस्ट को हटाते हुए) को नहीं बदलते, आपको उम्मीद करनी चाहिए कि इस ग्राफ़ में कुछ भी नहीं बदलेगा।
क्लाइंट कनेक्शन
सभी होस्टग्रुप के लिए ProxySQL द्वारा संसाधित किए जा रहे क्लाइंट कनेक्शन की संख्या:
उपरोक्त ग्राफ़ केवल हमें बताता है कि पिछले 45 मिनट के लिए पोर्ट 6033 पर हमारे प्रॉक्सीएसक्यूएल इंस्टेंस से लगातार 8 MySQL क्लाइंट जुड़े हुए हैं (आप इसे "रेंज चयन" विकल्प के तहत बदल सकते हैं)। यदि आप अपने एप्लिकेशन को ProxySQL से कनेक्ट करना बंद कर देते हैं (या इसे बायपास कर देते हैं), तो मान अंततः 0 पर गिर जाना चाहिए।
ग्राहक प्रश्न
ग्राफ़ सभी होस्टग्रुप के लिए ProxySQL द्वारा संसाधित किए जा रहे प्रश्नों की संख्या की कल्पना करता है:
MySQL प्रलेखन के अनुसार, प्रश्न केवल सर्वर द्वारा निष्पादित कथनों की संख्या है। इसमें केवल क्लाइंट द्वारा सर्वर को भेजे गए स्टेटमेंट शामिल हैं और क्वेरी वेरिएबल के विपरीत संग्रहीत प्रोग्राम के भीतर निष्पादित स्टेटमेंट नहीं हैं। यह चर COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE, या COM_STMT_RESET कमांड की गणना नहीं करता है। दोबारा, यदि आप अपने एप्लिकेशन को ProxySQL से कनेक्ट करना बंद कर देते हैं (या इसे बायपास कर देते हैं), तो मान 0 पर गिर जाना चाहिए।
सक्रिय बैकएंड कनेक्शन
प्रॉक्सीएसक्यूएल प्रति होस्ट बैकएंड MySQL सर्वर से जितने कनेक्शन रखता है:
यह केवल हमें बताता है कि बैकएंड सर्वर पर क्वेरी भेजने के लिए प्रॉक्सीएसक्यूएल द्वारा वर्तमान में कितने कनेक्शन का उपयोग किया जा रहा है। जब तक अधिकतम मान विशेष सर्वर के लिए कनेक्शन सीमा के करीब न हो (max_connections के माध्यम से सेट करें) जब सर्वर को ProxySQL होस्टग्रुप में जोड़ा जाता है), तो हम अच्छी स्थिति में होते हैं।
विफल बैकएंड कनेक्शन
ProxySQL द्वारा सफलतापूर्वक स्थापित नहीं किए गए कनेक्शनों की संख्या:
उपरोक्त उदाहरण केवल यह दर्शाता है कि पिछले 45 मिनट में कोई बैकएंड कनेक्शन विफलता नहीं हुई है।
प्रश्नों को रूट किया गया
यह ग्राफ़ बैकएंड सर्वर को इनकमिंग स्टेटमेंट के वितरण पर अंतर्दृष्टि प्रदान करता है:
जैसा कि आप देख सकते हैं, अधिकांश रीड रीडर होस्टग्रुप (HG20) में जा रहे हैं। यहाँ से हम ProxySQL द्वारा निष्पादित संतुलन पैटर्न को समझ सकते हैं जो इस रीड-इंटेंसिव वर्कलोड में हमारे क्वेरी नियमों से मेल खाता है।
कनेक्शन मुक्त
ग्राफ़ दिखाता है कि वर्तमान में कितने कनेक्शन मुफ़्त हैं:
बैकएंड सर्वर को क्वेरी भेजने की समय लागत को कम करने के लिए कनेक्शन खुले रखे जाते हैं।
विलंबता
माइक्रोसेकंड में वर्तमान पिंग समय, जैसा कि ProxySQL मॉनिटरिंग थ्रेड से रिपोर्ट किया गया है:
यह केवल हमें बताता है कि प्रॉक्सीएसक्यूएल से बैकएंड MySQL सर्वर से कनेक्शन कितना स्थिर है। लंबे समय तक लगातार उच्च मान उनके बीच नेटवर्क समस्या को इंगित करता है।
क्वेरी कैश मेमोरी
यह ग्राफ़ प्रॉक्सीएसक्यूएल द्वारा कैश की जा रही क्वेरीज़ की मेमोरी खपत की कल्पना करता है:
ऊपर दिए गए ग्राफ़ से, हम बता सकते हैं कि ProxySQL क्वेरी कैश द्वारा कुल 8MB मेमोरी की खपत करता है। इसके 8 एमबी की सीमा तक पहुंचने के बाद (mysql-query_cache_size_MB के माध्यम से कॉन्फ़िगर करने योग्य) वेरिएबल), मेमोरी को ProxySQL के पर्ज थ्रेड द्वारा शुद्ध किया जाएगा। यदि आपके पास कोई क्वेरी कैश नियम परिभाषित नहीं है, तो यह ग्राफ़ पॉप्युलेट नहीं होगा।
वैसे, ProxySQL में किसी क्वेरी को कैशिंग करना ClusterControl के साथ केवल दो क्लिक में किया जा सकता है। प्रॉक्सीएसक्यूएल के शीर्ष प्रश्न पृष्ठ पर जाएं, एक प्रश्न पर रोलओवर करें, क्वेरी कैश पर क्लिक करें और "नियम जोड़ें" पर क्लिक करें:
क्वेरी कैश दक्षता
यह ग्राफ़ कैश्ड क्वेरी की दक्षता की कल्पना करता है:
नीली रेखा हमें क्वेरी कैश के विरुद्ध निष्पादित GET अनुरोधों का सफल अनुपात बताती है जहां परिणाम सेट मौजूद था और समाप्त नहीं हुआ था। गुलाबी रेखा क्वेरी कैश में लिखे या पढ़े गए डेटा का अनुपात दिखाती है। इस मामले में, क्वेरी कैश से पढ़ा गया हमारा डेटा एक कुशल कैश कॉन्फ़िगरेशन को इंगित करने वाले लिखित डेटा से अधिक है।
यदि आपके पास कोई क्वेरी कैश नियम परिभाषित नहीं है, तो यह ग्राफ़ पॉप्युलेट नहीं होगा।
नेटवर्क ट्रैफ़िक
यह ग्राफ़ प्रति होस्ट, बैकएंड MySQL सर्वर से/से नेटवर्क ट्रैफ़िक (डेटा प्राप्त + डेटा भेजा गया) की कल्पना करता है:
उपरोक्त स्क्रीनशॉट हमें बताता है कि पाठक होस्टग्रुप (HG20) से/को महत्वपूर्ण मात्रा में ट्रैफ़िक अग्रेषित/प्राप्त किया जा रहा है। इस पठन-गहन कार्यभार में, मुख्य रूप से SELECT स्टेटमेंट के परिणाम सेट आकार के कारण रीड ऑपरेशंस आमतौर पर बहुत अधिक ट्रैफ़िक की खपत करते हैं।
राइट होस्टग्रुप (HG10) से/को ट्रैफ़िक का केवल एक छोटा अनुपात अग्रेषित/प्राप्त किया जाता है, जिसकी अपेक्षा की जाती है क्योंकि राइट ऑपरेशन आमतौर पर कम नेटवर्क ट्रैफ़िक का उपभोग करते हैं और ग्राहकों को काफी छोटे परिणाम सेट वापस किए जाते हैं।
दर्पण क्षमता
ग्राफ़ केवल मिरर_कॉन्करेंसी बनाम मिरर_क्यू_लेंथ जैसे ट्रैफ़िक मिररिंग से संबंधित स्थिति दिखाता है:
ग्राफ़ केवल तभी भरा जाता है जब आपने ट्रैफ़िक मिररिंग कॉन्फ़िगर किया हो (mirror_hostgroup क्वेरी नियम के अंदर)। यदि दर्पण कतार ऊपर उठ रही है, तो मिररिंग समवर्ती सीमा को कम करने से मिररिंग दक्षता में वृद्धि होगी, जिसे mysql-mirror_max_concurrency के माध्यम से नियंत्रित किया जा सकता है। चर। सरल शब्दों में, शून्य कतार प्रविष्टियाँ ही सबसे कुशल मिररिंग है।
स्मृति उपयोग
ग्राफ़ ProxySQL के अंदर मुख्य घटकों द्वारा मेमोरी उपयोग को दिखाता है - कनेक्शन पूल, क्वेरी कैश और लगातार स्टोरेज (SQLite):
उपरोक्त स्क्रीनशॉट हमें बताता है कि ProxySQL मेमोरी फ़ुटप्रिंट छोटा है जो कुल मिलाकर 12 एमबी से कम है। हमारे 8-थ्रेड (क्लाइंट) वर्कलोड को समायोजित करने के लिए कनेक्शन पूल केवल 1.3 एमबी टॉप की खपत करता है। होस्ट पर अधिक निःशुल्क RAM उपलब्ध होने के साथ, हमें अपने MySQL बैकएंड सर्वर को ऑफ़लोड करने के लिए ProxySQL से क्लाइंट कनेक्शन की संख्या को तीन गुना बढ़ाकर चार गुना करने या ProxySQL के अंदर बहुत अधिक हॉट क्वेरी को कैश करने में सक्षम होना चाहिए।
बोनस फ़ीचर - नोड प्रदर्शन
ClusterControl 1.7.0 में अब ProxySQL इंस्टेंस के लिए होस्ट प्रदर्शन मेट्रिक्स शामिल हैं। पिछले संस्करण में, ClusterControl केवल ProxySQL संबंधित मेट्रिक्स की निगरानी करता था जैसा कि ProxySQL आँकड़े स्कीमा द्वारा उजागर किया गया था। इस नई सुविधा को नोड के टैब के अंतर्गत एक्सेस किया जा सकता है -> प्रॉक्सीएसक्यूएल इंस्टेंस -> नोड प्रदर्शन:
हिस्टोग्राम प्रमुख होस्ट मेट्रिक्स के लिए अंतर्दृष्टि प्रदान करते हैं, जैसा कि नोड्स -> अवलोकन अनुभाग के तहत डेटाबेस नोड्स के लिए नमूना किया जा रहा है। यदि आपका ProxySQL इंस्टेंस एप्लिकेशन के साथ उसी सर्वर में सह-स्थित है, तो आप एप्लिकेशन सर्वर पर भी नजर रखने के लिए सचमुच ClusterControl का उपयोग कर रहे हैं। वह कितना अच्छा है?!
अंतिम विचार
Prometheus के साथ ClusterControl एकीकरण आपके डेटाबेस स्टैक की निगरानी और विश्लेषण करने का एक वैकल्पिक तरीका प्रदान करता है, जब तक कि रिवर्स-प्रॉक्सी टियर नहीं हो जाता। अब आपके पास प्रोमेथियस को मॉनिटरिंग जॉब को ऑफलोड करने का विकल्प है, या अपने डेटाबेस इन्फ्रास्ट्रक्चर के लिए डिफ़ॉल्ट ClusterControl एजेंटलेस मॉनिटरिंग दृष्टिकोण का उपयोग करना जारी रखें।
