ClusterControl के साथ एजेंट रहित डेटाबेस मॉनिटरिंग

डेटाबेस सेटअप की बढ़ती जटिलता के साथ, कई SysAdmins और DBA डेटाबेस मॉनिटरिंग चुनौतियों के बोझ को कम करने में मदद करने के लिए एक एजेंट रहित दृष्टिकोण की ओर रुख कर रहे हैं। ClusterControl की एजेंट रहित निगरानी आपको प्रत्येक मॉनिटर किए गए सिस्टम पर एजेंट सॉफ़्टवेयर स्थापित किए बिना डेटाबेस की निगरानी करने की अनुमति देती है। ClusterControl SSH प्रोटोकॉल का उपयोग करने वाले दूरस्थ डेटा संग्राहक का उपयोग करके निगरानी को लागू करता है।

एजेंट रहित निगरानी की बारीकियों में सीधे गोता लगाने से पहले, आइए पहले यहां हमारे संदर्भ में निगरानी के दायरे और अर्थ को स्पष्ट करें। निगरानी डेटा ट्रेंडिंग के बाद आती है - मेट्रिक्स संग्रह और भंडारण प्रक्रिया - जो निगरानी प्रणाली को रिपोर्टिंग के लिए ट्रेंडिंग डेटा को ट्यूनिंग, अलर्ट करने और प्रदर्शित करने के औचित्य का उत्पादन करने के लिए एकत्रित डेटा को संसाधित करने की अनुमति देती है।

संस्करण 1.7.0 (दिसंबर 2018 में जारी) से शुरू होकर, ClusterControl दो निगरानी विधियों का समर्थन करता है:

• एजेंट रहित निगरानी (डिफ़ॉल्ट)
• प्रोमेथियस के साथ एजेंट-आधारित निगरानी

यह पोस्ट ClusterControl की एजेंट रहित निगरानी के साथ आपके डेटाबेस सर्वर और क्लस्टर की निगरानी करने के तरीके के बारे में बताएगी। यदि आप ClusterControl की एजेंट-आधारित निगरानी के बारे में अधिक जानकारी की तलाश में हैं, तो आप इस दस्तावेज़ को देख सकते हैं।

आम तौर पर, ClusterControl निम्नलिखित तीन विधियों का उपयोग करके एजेंट रहित निगरानी, ​​चेतावनी और ट्रेंडिंग कर्तव्यों का पालन करता है:

• SSH - SSH लाइब्रेरी का उपयोग करके होस्ट मेट्रिक्स संग्रह (प्रक्रिया, लोड बैलेंसर आँकड़े, संसाधन उपयोग, खपत, आदि)
• डेटाबेस क्लाइंट - संबंधित डेटाबेस क्लाइंट लाइब्रेरी का उपयोग करके डेटाबेस मेट्रिक्स संग्रह (स्थिति, क्वेरी, चर, उपयोग, आदि)
• सलाहकार - ClusterControl DSL का उपयोग करके लिखे गए मिनी प्रोग्राम और मॉनिटरिंग, ट्यूनिंग और अलर्टिंग उद्देश्यों के लिए ClusterControl के भीतर ही चल रहे हैं

SSH का अर्थ सिक्योर शेल है, जो एक सुरक्षित नेटवर्क प्रोटोकॉल है जिसका उपयोग अधिकांश लिनक्स-आधारित सर्वर दूरस्थ प्रशासन के लिए करते हैं। ClusterControl Controller, या CMON, C++ के शीर्ष पर निर्मित स्वचालन, प्रबंधन, निगरानी और शेड्यूलिंग कार्यों को करने वाली बैकएंड सेवा है।

ClusterControl DSL (डोमेन विशिष्ट भाषा) आपको सलाहकार, ऑटो ट्यूनर या "मिनी प्रोग्राम" बनाकर अपने ClusterControl प्लेटफॉर्म की कार्यक्षमता बढ़ाने की अनुमति देता है। DSL सिंटैक्स जावास्क्रिप्ट पर आधारित है, जिसमें ClusterControl आंतरिक डेटा संरचनाओं और कार्यों तक पहुँच प्रदान करने के लिए एक्सटेंशन हैं। DSL आपको SQL कथनों को निष्पादित करने, आपके सभी क्लस्टर होस्टों में शेल कमांड/प्रोग्राम चलाने और सलाहकारों/अलर्ट या किसी अन्य कार्रवाई के लिए संसाधित किए जाने वाले परिणामों को पुनः प्राप्त करने की अनुमति देता है।

निगरानी उपकरण

सभी पूर्वापेक्षित उपकरण इंस्टालर स्क्रिप्ट से मिलते हैं या डेटाबेस परिनियोजन चरण के दौरान क्लस्टरकंट्रोल द्वारा स्वचालित रूप से स्थापित किए जाते हैं या यदि आवश्यक फ़ाइल/बाइनरी/पैकेज किसी कार्य को निष्पादित करने से पहले लक्ष्य सर्वर पर मौजूद नहीं है। सामान्यतया, ClusterControl मॉनिटरिंग ड्यूटी के लिए केवल मॉनिटर किए गए होस्ट पर OpenSSH सर्वर पैकेज की आवश्यकता होती है। ClusterControl मॉनिटर किए गए होस्ट - CPU, मेमोरी, डिस्क, नेटवर्क, IO, प्रोसेस आदि के लिए होस्ट मेट्रिक्स एकत्र करने के लिए libssh क्लाइंट लाइब्रेरी का उपयोग करता है। OpenSSH क्लाइंट पैकेज को ClusterControl होस्ट पर केवल पासवर्ड रहित SSH और डिबगिंग उद्देश्यों को सेट करने के लिए आवश्यक है। ड्रॉपबियर और टाइनीएसएसएच जैसे अन्य एसएसएच कार्यान्वयन समर्थित नहीं हैं।

डेटाबेस आँकड़े और मेट्रिक्स एकत्र करते समय, ClusterControl Controller (CMON) डेटाबेस क्लाइंट लाइब्रेरी के माध्यम से सीधे डेटाबेस सर्वर से जुड़ता है - libmysqlclient (MySQL/MariaDB और ProxySQL), libpq (PostgreSQL), और libmongoxx (MongoDB) ) इसलिए डेटाबेस सर्वर के दृष्टिकोण से ClusterControl सर्वर के लिए उचित विशेषाधिकार सेट करना महत्वपूर्ण है। MySQL-आधारित क्लस्टर के लिए, ClusterControl को डेटाबेस उपयोगकर्ता "cmon" की आवश्यकता होती है, जबकि अन्य डेटाबेस के लिए, किसी भी उपयोगकर्ता नाम का उपयोग निगरानी के लिए किया जा सकता है, जब तक कि इसे सुपर-उपयोगकर्ता विशेषाधिकार दिए गए हों। अधिकांश समय, क्लस्टर इंपोर्ट या क्लस्टर परिनियोजन चरण के दौरान ClusterControl आवश्यक विशेषाधिकार (या निर्दिष्ट डेटाबेस उपयोगकर्ता का उपयोग) को स्वचालित रूप से सेट करेगा।

ClusterControl को लोड बैलेंसर के लिए निम्नलिखित टूल की आवश्यकता होती है:

• MariaDB MaxScale सर्वर पर Maxctrl
• HAProxy सर्वर पर netcat और/या socat ताकि HAProxy सॉकेट फ़ाइल से कनेक्ट किया जा सके और निगरानी डेटा प्राप्त किया जा सके
• ProxySQL को ProxySQL सर्वर पर एक mysql क्लाइंट की आवश्यकता है

निम्न आरेख, होस्ट और डेटाबेस दोनों की निगरानी प्रक्रियाओं को दिखाता है, जिन्हें ClusterControl द्वारा libssh और डेटाबेस क्लाइंट लाइब्रेरी का उपयोग करके निष्पादित किया गया है:

हालांकि मॉनिटरिंग थ्रेड को मॉनिटर किए गए होस्ट पर डेटाबेस क्लाइंट पैकेज स्थापित करने की आवश्यकता नहीं है, प्रबंधन उद्देश्यों के लिए उन्हें रखने की अत्यधिक अनुशंसा की जाती है। उदाहरण के लिए, MySQL क्लाइंट पैकेज mysql, mysqldump, mysqlbinlog, और mysqladmin प्रोग्राम के साथ आता है, जिसका उपयोग ClusterControl द्वारा बैकअप और पॉइंट-इन-टाइम रिकवरी करते समय किया जाएगा।

निगरानी के तरीके

होस्ट और लोड बैलेंसर आँकड़े संग्रह के लिए, ClusterControl सुपर-यूज़र विशेषाधिकार के साथ SSH के माध्यम से इस कार्य को निष्पादित करता है। इसलिए, सुपर-यूजर विशेषाधिकार के साथ पासवर्ड रहित एसएसएच क्लस्टरकंट्रोल को उचित एस्केलेशन के साथ दूर से आवश्यक कमांड चलाने की अनुमति देने के लिए महत्वपूर्ण है। इस पुल दृष्टिकोण के साथ, अन्य तंत्रों की तुलना में कुछ फायदे हैं:

• एजेंट रहित - एजेंट को स्थापित करने, कॉन्फ़िगर करने और बनाए रखने की कोई आवश्यकता नहीं है।
• प्रबंधन और मॉनिटरिंग कॉन्फ़िगरेशन को एकीकृत करना - SSH का उपयोग मॉनिटरिंग मेट्रिक्स को खींचने या लक्ष्य नोड्स पर प्रबंधन कार्यों को आगे बढ़ाने के लिए किया जा सकता है।
• परिनियोजन को सरल बनाएं - एकमात्र आवश्यकता उचित पासवर्ड रहित एसएसएच सेटअप है, और बस इतना ही। SSH भी बहुत सुरक्षित और एन्क्रिप्टेड है।
• केंद्रीकृत सेटअप - एक क्लस्टर कंट्रोल सर्वर कई सर्वर और क्लस्टर का प्रबंधन कर सकता है, बशर्ते उसके पास पर्याप्त संसाधन हों।

हालांकि, पुल तंत्र में निम्नलिखित कमियां भी हैं:

• निगरानी डेटा केवल ClusterControl के दृष्टिकोण से सटीक है। उदाहरण के लिए, यदि कोई नेटवर्क गड़बड़ है और ClusterControl मॉनिटर किए गए होस्ट से संचार खो देता है, तो नमूना अगले उपलब्ध चक्र तक छोड़ दिया जाएगा।
• नमूना दर में वृद्धि के कारण उच्च ग्रैन्युलैरिटी निगरानी के लिए नेटवर्क ओवरहेड होगा जहां क्लस्टर कंट्रोल को प्रत्येक लक्षित होस्ट के लिए अधिक कनेक्शन स्थापित करने की आवश्यकता होती है।
• ClusterControl लक्ष्य नोड से कनेक्शन फिर से स्थापित करने का प्रयास करता रहेगा क्योंकि उसके पास इसकी ओर से ऐसा करने के लिए कोई एजेंट नहीं है।
• अनावश्यक डेटा नमूनाकरण यदि आपके पास क्लस्टर की निगरानी करने वाले एक से अधिक ClusterControl सर्वर हैं, क्योंकि प्रत्येक ClusterControl सर्वर को अपने लिए निगरानी डेटा खींचना होता है।

MySQL क्वेरी मॉनिटरिंग के लिए, ClusterControl 1.9.0 (जुलाई 2021 में जारी) से शुरू होकर, ClusterControl दो प्रकारों का समर्थन करता है:

• एजेंट रहित क्वेरी मॉनिटरिंग (डिफ़ॉल्ट)
• CMON क्वेरी एजेंट का उपयोग करके एजेंट-आधारित क्वेरी मॉनिटरिंग, जिसे सक्षम करने के लिए अतिरिक्त चरणों की आवश्यकता होती है। केवल MySQL-आधारित और PostgreSQL-आधारित डेटाबेस के लिए।

एजेंट रहित क्वेरी मॉनिटरिंग दो अलग-अलग तरीकों से प्रश्नों की निगरानी करती है:

• SSH के माध्यम से डेटाबेस नोड पर स्कीमा को क्वेरी करके PERFORMANCE_SCHEMA से क्वेरी पुनर्प्राप्त की जाती हैं।
• यदि PERFORMANCE_SCHEMA अक्षम या अनुपलब्ध है, तो ClusterControl SSH के माध्यम से स्लो क्वेरी लॉग की सामग्री को पार्स करेगा।

यदि प्रदर्शन स्कीमा सक्षम है, तो ClusterControl धीमी क्वेरी को देखने के लिए इसका उपयोग करेगा। अन्यथा, ClusterControl निम्न प्रवाह के आधार पर MySQL स्लो क्वेरी लॉग (slow_query_log=ON डायनामिक वैरिएबल के माध्यम से) की सामग्री को पार्स करेगा:

1. धीमा लॉग प्रारंभ करें (MySQL रनटाइम के दौरान)।
2. इसे थोड़े समय के लिए चलाएं (एक सेकंड या कुछ सेकंड)।
3. लॉग रोकें.
4. पार्स लॉग।
5. लॉग को छोटा करें (नई लॉग फ़ाइल)।
6. 1 पर जाएं।

संग्रहीत प्रश्नों को हैश किया जाता है, गणना की जाती है, और डाइजेस्ट किया जाता है (सामान्यीकृत, औसत, गिनती, सॉर्ट) और फिर ClusterControl CMON डेटाबेस में संग्रहीत किया जाता है। ध्यान दें कि इस नमूना विधि के लिए, कुछ प्रश्नों को कैप्चर नहीं किया जाएगा, विशेष रूप से "स्टॉप लॉग, पार्स लॉग, ट्रंकेट लॉग" भागों के दौरान थोड़ा सा मौका है। यदि यह विकल्प नहीं है तो आप प्रदर्शन स्कीमा को सक्षम कर सकते हैं।

धीमी क्वेरी लॉग का उपयोग करके केवल लंबी क्वेरी समय से अधिक की क्वेरी को यहां सूचीबद्ध किया जाएगा। मान लीजिए कि डेटा सही ढंग से नहीं भरा गया है, और आप मानते हैं कि इसमें कुछ होना चाहिए, यह हो सकता है:

• ClusterControl ने डेटा को सारांशित करने और पॉप्युलेट करने के लिए पर्याप्त क्वेरी एकत्र नहीं की। लंबी क्वेरी समय को कम करने का प्रयास करें।
• आपने MySQL सर्वर के my.cnf में स्लो क्वेरी लॉग कॉन्फ़िगरेशन विकल्पों को कॉन्फ़िगर किया है, और स्थानीय क्वेरी को ओवरराइड करना बंद है। यदि आप वास्तव में my.cnf के अंदर परिभाषित मान का उपयोग करना चाहते हैं, तो आपको संभवतः long_query_time मान को कम करना होगा ताकि ClusterControl अधिक सटीक परिणाम की गणना कर सके।
• आपके पास एक और ClusterControl नोड है जो स्लो क्वेरी लॉग को भी खींच रहा है (यदि आपके पास स्टैंडबाय ClusterControl सर्वर है)। यह कार्य केवल एक ClusterControl सर्वर को करने दें।

आप MySQL, MariaDB और Percona सर्वर के लिए ClusterControl Query Monitor का भी उपयोग कर सकते हैं।

PostgreSQL क्वेरी मॉनिटरिंग के लिए, ClusterControl को सभी SQL स्टेटमेंट के निष्पादन आंकड़ों को ट्रैक करने के लिए pg_stat_statements मॉड्यूल की आवश्यकता होती है। यह UI में प्रश्नों को प्रदर्शित करते समय pg_stat_statements विचारों और कार्यों को पॉप्युलेट करता है (क्वेरी मॉनिटर टैब के अंतर्गत)।

अंतराल और समय समाप्त

ClusterControl Controller (cmon) एक बहु-थ्रेडेड प्रक्रिया है। डिफ़ॉल्ट रूप से, ClusterControl कंट्रोलर सैंपलिंग थ्रेड प्रत्येक मॉनिटर किए गए होस्ट से एक बार कनेक्ट होता है और तब तक लगातार कनेक्शन बनाए रखता है जब तक कि होस्ट आँकड़ों का नमूना लेते समय होस्ट ड्रॉप या डिस्कनेक्ट नहीं हो जाता। यह मेजबान को सौंपे गए कार्यों के आधार पर अधिक कनेक्शन स्थापित कर सकता है क्योंकि अधिकांश प्रबंधन कार्य अपने स्वयं के धागे में चलते हैं। उदाहरण के लिए, क्लस्टर पुनर्प्राप्ति पुनर्प्राप्ति थ्रेड पर चलती है, सलाहकार निष्पादन क्रोन-थ्रेड पर चलता है, और प्रक्रिया निगरानी प्रक्रिया संग्राहक थ्रेड पर चलती है।

ClusterControl मॉनिटरिंग थ्रेड निम्नलिखित अंतराल में निम्नलिखित नमूना संचालन करता है:

• MySQL क्वेरी/स्टेटस मेट्रिक्स:हर सेकेंड
• संग्रह की प्रक्रिया (/proc):हर 10 सेकंड में
• सर्वर का पता लगाना:हर 10 सेकंड में
• होस्ट मेट्रिक्स (/ proc, /sys):हर 30 सेकंड में (host_stats_collection_interval के माध्यम से कॉन्फ़िगर करने योग्य)
• डेटाबेस मेट्रिक्स (केवल PostgreSQL और MongoDB):हर 30 सेकंड में (db_stats_collection_interval के माध्यम से कॉन्फ़िगर करने योग्य)
• डेटाबेस स्कीमा मेट्रिक्स:हर 3 घंटे में (db_schema_stats_collection_interval के माध्यम से कॉन्फ़िगर करने योग्य)
• लोड बैलेंसर मेट्रिक्स:हर 15 सेकंड में (lb_stats_collection_interval के माध्यम से कॉन्फ़िगर करने योग्य)

अनिवार्य स्क्रिप्ट (सलाहकार) निम्नलिखित प्रतिबंधों के साथ सीएमओएन के साथ आने वाले एसएसएच और डेटाबेस क्लाइंट लाइब्रेरी का उपयोग कर सकते हैं:

• SSH निष्पादन के लिए 5 सेकंड की हार्ड लिमिट।
• डेटाबेस कनेक्शन के लिए 10 सेकंड की डिफ़ॉल्ट सीमा, CMON कॉन्फ़िगरेशन फ़ाइल में net_read_timeout, net_write_timeout, Connect_timeout के माध्यम से कॉन्फ़िगर करने योग्य।
• सीएमओएन द्वारा इसे निरस्त करने से पहले कुल स्क्रिप्ट निष्पादन समय सीमा के 60 सेकंड।

सलाहकारों को प्रबंधित करें → डेवलपर स्टूडियो के अंतर्गत सीधे ClusterControl के UI से बनाया, संकलित, परीक्षण और शेड्यूल किया जा सकता है . निम्न स्क्रीनशॉट PERFORMANCE_SCHEMA से शीर्ष 10 क्वेरी निकालने के लिए एक सलाहकार का उदाहरण दिखाता है:

सलाहकारों का निष्पादन इस पर निर्भर करता है कि क्या यह सक्रिय है और समय-निर्धारण समय क्रॉन प्रारूप में:

निष्पादन के परिणाम प्रदर्शन → सलाहकार<के अंतर्गत प्रदर्शित होते हैं /em> , जैसा कि निम्न स्क्रीनशॉट में दिखाया गया है:

डिफॉल्ट रूप से सलाहकार क्या प्रदान करते हैं, इस बारे में अधिक जानकारी के लिए, हमारे डेवलपर को देखें स्टूडियो उत्पाद पृष्ठ।

डेटा को सीधे सीएमओएन डेटाबेस में संग्रहीत किया जाता है ताकि लघु-अंतराल निगरानी डेटा जैसे MySQL क्वेरी और स्थिति के लिए डेटा संग्रहीत किया जा सके। साप्ताहिक/मासिक/वार्षिक डेटा बिंदुओं जैसे लंबे-अंतराल निगरानी डेटा को हर 60 सेकंड में एकत्र किया जाता है और 10 मिनट के लिए मेमोरी में संग्रहीत किया जाता है। आर्किटेक्चर डिज़ाइन के कारण ये व्यवहार कॉन्फ़िगर करने योग्य नहीं हैं।

पैरामीटर

ClusterControl में आपकी निगरानी और चेतावनी नीति के अनुरूप कई पैरामीटर हैं। उनमें से अधिकांश ClusterControl UI → एक क्लस्टर चुनें → सेटिंग्स . के माध्यम से कॉन्फ़िगर करने योग्य हैं . "सेटिंग" टैब अलर्ट, थ्रेसहोल्ड, नोटिफिकेशन, ग्राफ़ लेआउट, डेटाबेस काउंटर, क्वेरी मॉनिटरिंग आदि को कॉन्फ़िगर करने के लिए कई विकल्प प्रदान करता है। उदाहरण के लिए, चेतावनी और महत्वपूर्ण थ्रेशोल्ड निम्नानुसार कॉन्फ़िगर करने योग्य हैं:

“रनटाइम कॉन्फिगरेशन” पेज सक्रिय क्लस्टर कंट्रोल कंट्रोलर की एक सारांशित सूची दिखाता है (CMON) रनटाइम कॉन्फ़िगरेशन पैरामीटर:

कुल मिलाकर 170 से अधिक ClusterControl नियंत्रक कॉन्फ़िगरेशन विकल्प हैं, और इनमें से कुछ उन्नत सेटिंग्स को नीति ठीक ट्यूनिंग की निगरानी और चेतावनी कॉन्फ़िगर किया जा सकता है। इनमें से कुछ में शामिल हैं:

• मॉनिटर_cpu_temperature
• स्वैप_चेतावनी
• swap_critical
• redobuffer_warning
• redobuffer_critical
• indexmemory_warning
• indexmemory_critical
• datamemory_warning
• datamemory_critical
• tablespace_warning
• tablespace_critical
• redolog_warning
• redolog_critical
• max_replication_lag
• long_query_time
• log_queries_not_using_indexes
• query_monitor_use_local_settings
• enable_query_monitor
• enable_query_monitor_auto_purge_ps

आप /etc/cmon.d/cmon_X.cnf पर स्थित UI या CMON कॉन्फ़िगरेशन फ़ाइल का उपयोग करके "रनटाइम कॉन्फ़िगरेशन" पृष्ठ में सूचीबद्ध मापदंडों को बदल सकते हैं, जहां X क्लस्टर आईडी है। आप निम्न कमांड का उपयोग करके सीएमओएन के लिए सभी समर्थित कॉन्फ़िगरेशन विकल्पों को सूचीबद्ध कर सकते हैं:

$ cmon --help-config

अंतिम विचार

एजेंटलेस मॉनिटरिंग तेजी से जटिल डेटाबेस इन्फ्रास्ट्रक्चर के प्रबंधन के लिए सबसे प्रभावी तरीकों में से एक बन गया है। यह डेटाबेस निगरानी से जुड़ी कई चुनौतियों के बोझ को कम करता है और इसे प्रबंधित करना आसान है।

आज बहुत सारे एजेंट रहित निगरानी उपकरण उपलब्ध हैं। हालाँकि, उनमें से बहुत से आपके डेटाबेस क्लस्टर के हर दूसरे पहलू को प्रबंधित करने में आपकी मदद करने के लिए सुविधाओं से भरा एक संपूर्ण प्लेटफ़ॉर्म भी प्रदान नहीं करते हैं। यह देखने के लिए कि ClusterControl और क्या कर सकता है, अपना 30-दिन का निःशुल्क परीक्षण डाउनलोड करना सुनिश्चित करें।

क्या आप डेटाबेस मॉनिटरिंग के लिए एजेंट-आधारित विकल्प की तलाश कर रहे हैं? ClusterControl के एजेंट-आधारित डेटाबेस मॉनिटरिंग इंफ्रास्ट्रक्चर — SCUMM देखें।