डेटाबेस मॉनिटरिंग - SCUMM डैशबोर्ड के साथ प्रोमेथियस का समस्या निवारण

हमें SCUMM (सेवरलनाइन्स क्लस्टरकंट्रोल यूनिफाइड मैनेजमेंट एंड मॉनिटरिंग) जारी किए हुए अब लगभग दो महीने हो चुके हैं। SCUMM डेटाबेस इंस्टेंस और लोड बैलेंसर्स पर चल रहे निर्यातकों से समय श्रृंखला डेटा एकत्र करने के लिए अंतर्निहित विधि के रूप में प्रोमेथियस का उपयोग करता है। यह ब्लॉग आपको दिखाएगा कि जब प्रोमेथियस निर्यातक नहीं चल रहे हों, या ग्राफ़ डेटा प्रदर्शित नहीं कर रहे हों, या "कोई डेटा पॉइंट" नहीं दिखा रहे हों, तो समस्याओं को कैसे ठीक किया जाए।

प्रोमेथियस क्या है?

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

SCUMM डैशबोर्ड के लिए प्रोमेथियस कार्रवाई में है

प्रोमेथियस निर्यातकों से मेट्रिक्स डेटा एकत्र करता है, प्रत्येक निर्यातक डेटाबेस या लोड बैलेंसर होस्ट पर चलता है। नीचे दिया गया चित्र आपको दिखाता है कि ये निर्यातक प्रोमेथियस प्रक्रिया को होस्ट करने वाले सर्वर से कैसे जुड़े हैं। यह दर्शाता है कि ClusterControl नोड में Prometheus चल रहा है जहाँ यह process_exporter और node_exporter भी चलाता है।

आरेख दिखाता है कि Prometheus ClusterControl होस्ट और निर्यातकों पर चल रहा है process_exporter और नोड_एक्सपोर्टर अपने स्वयं के नोड से मीट्रिक एकत्र करने के लिए भी चल रहे हैं। वैकल्पिक रूप से, आप अपने क्लस्टरकंट्रोल होस्ट को लक्ष्य के रूप में भी बना सकते हैं जिसमें आप HAProxy या ProxySQL सेटअप कर सकते हैं।

उपरोक्त क्लस्टर नोड्स (नोड 1, नोड 2 और नोड 3) के लिए, इसमें mysqld_exporter या postgres_exporter चल सकता है जो एजेंट हैं जो उस नोड में आंतरिक रूप से डेटा को स्क्रैप करते हैं और इसे प्रोमेथियस सर्वर को पास करते हैं और इसे अपने डेटा स्टोरेज में स्टोर करते हैं। आप होस्ट के भीतर /var/lib/prometheus/data के माध्यम से इसके भौतिक डेटा का पता लगा सकते हैं जहां Prometheus सेटअप है।

जब आप Prometheus को सेटअप करते हैं, उदाहरण के लिए, ClusterControl होस्ट में, इसमें निम्न पोर्ट खुले होने चाहिए। नीचे देखें:

[[email protected] share]# netstat -tnvlp46|egrep 'ex[p]|prometheu[s]'
tcp6       0      0 :::9100                 :::*                    LISTEN      16189/node_exporter 
tcp6       0      0 :::9011                 :::*                    LISTEN      19318/process_expor 
tcp6       0      0 :::42004                :::*                    LISTEN      16080/proxysql_expo 
tcp6       0      0 :::9090                 :::*                    LISTEN      31856/prometheus

आउटपुट के आधार पर, मेरे पास ProxySQL के साथ-साथ होस्ट testccnode पर भी चल रहा है जिसमें ClusterControl होस्ट किया गया है।

प्रोमेथियस का उपयोग करने वाले SCUMM डैशबोर्ड के साथ सामान्य समस्याएं

जब डैशबोर्ड सक्षम होते हैं, तो क्लस्टरकंट्रोल बायनेरिज़ और एक्सपोर्टर्स जैसे कि node_exporter, process_exporter, mysqld_exporter, postgres_exporter, और daemon को स्थापित और तैनात करेगा। ये डेटाबेस नोड्स के पैकेज के सामान्य सेट हैं। जब ये सेटअप और इंस्टाल हो जाते हैं, तो निम्न डेमॉन कमांड सक्रिय हो जाते हैं और नीचे देखे गए तरीके से चलते हैं:

[[email protected] bin]# ps axufww|egrep 'exporte[r]'
prometh+  3604  0.0  0.0  10828   364 ?        S    Nov28   0:00 daemon --name=process_exporter --output=/var/log/prometheus/process_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/process_exporter.pid --user=prometheus -- process_exporter
prometh+  3605  0.2  0.3 256300 14924 ?        Sl   Nov28   4:06  \_ process_exporter
prometh+  3838  0.0  0.0  10828   564 ?        S    Nov28   0:00 daemon --name=node_exporter --output=/var/log/prometheus/node_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/node_exporter.pid --user=prometheus -- node_exporter
prometh+  3839  0.0  0.4  44636 15568 ?        Sl   Nov28   1:08  \_ node_exporter
prometh+  4038  0.0  0.0  10828   568 ?        S    Nov28   0:00 daemon --name=mysqld_exporter --output=/var/log/prometheus/mysqld_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/mysqld_exporter.pid --user=prometheus -- mysqld_exporter --collect.perf_schema.eventswaits --collect.perf_schema.file_events --collect.perf_schema.file_instances --collect.perf_schema.indexiowaits --collect.perf_schema.tableiowaits --collect.perf_schema.tablelocks --collect.info_schema.tablestats --collect.info_schema.processlist --collect.binlog_size --collect.global_status --collect.global_variables --collect.info_schema.innodb_metrics --collect.slave_status
prometh+  4039  0.1  0.2  17368 11544 ?        Sl   Nov28   1:47  \_ mysqld_exporter --collect.perf_schema.eventswaits --collect.perf_schema.file_events --collect.perf_schema.file_instances --collect.perf_schema.indexiowaits --collect.perf_schema.tableiowaits --collect.perf_schema.tablelocks --collect.info_schema.tablestats --collect.info_schema.processlist --collect.binlog_size --collect.global_status --collect.global_variables --collect.info_schema.innodb_metrics --collect.slave_status

PostgreSQL नोड के लिए,

[[email protected] vagrant]# ps axufww|egrep 'ex[p]'
postgres  1901  0.0  0.4 1169024 8904 ?        Ss   18:00   0:04  \_ postgres: postgres_exporter postgres ::1(51118) idle
prometh+  1516  0.0  0.0  10828   360 ?        S    18:00   0:00 daemon --name=process_exporter --output=/var/log/prometheus/process_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/process_exporter.pid --user=prometheus -- process_exporter
prometh+  1517  0.2  0.7 117032 14636 ?        Sl   18:00   0:35  \_ process_exporter
prometh+  1700  0.0  0.0  10828   572 ?        S    18:00   0:00 daemon --name=node_exporter --output=/var/log/prometheus/node_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/node_exporter.pid --user=prometheus -- node_exporter
prometh+  1701  0.0  0.7  44380 14932 ?        Sl   18:00   0:10  \_ node_exporter
prometh+  1897  0.0  0.0  10828   568 ?        S    18:00   0:00 daemon --name=postgres_exporter --output=/var/log/prometheus/postgres_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --env=DATA_SOURCE_NAME=postgresql://postgres_exporter:[email protected]:5432/postgres?sslmode=disable --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/postgres_exporter.pid --user=prometheus -- postgres_exporter
prometh+  1898  0.0  0.5  16548 11204 ?        Sl   18:00   0:06  \_ postgres_exporter

इसमें MySQL नोड के समान ही निर्यातक हैं, लेकिन यह केवल postgres_exporter पर भिन्न है क्योंकि यह एक PostgreSQL डेटाबेस नोड है।

हालांकि, जब कोई नोड पावर रुकावट, सिस्टम क्रैश या सिस्टम रीबूट से ग्रस्त होता है, तो ये निर्यातक चलना बंद कर देंगे। प्रोमेथियस रिपोर्ट करेगा कि एक निर्यातक नीचे है। ClusterControl नमूने प्रोमेथियस ही, और निर्यातक की स्थिति के लिए पूछता है। तो यह इस जानकारी पर काम करता है, और अगर यह नीचे है तो निर्यातक को फिर से शुरू कर देगा।

हालांकि, ध्यान दें कि जिन निर्यातकों को ClusterControl के माध्यम से स्थापित नहीं किया गया है, उन्हें दुर्घटना के बाद फिर से शुरू नहीं किया जाएगा। इसका कारण यह है कि सिस्टमड या डेमॉन द्वारा उनकी निगरानी नहीं की जाती है जो एक सुरक्षा स्क्रिप्ट के रूप में कार्य करता है जो क्रैश या असामान्य शटडाउन पर एक प्रक्रिया को पुनरारंभ करेगा। इसलिए, नीचे दिया गया स्क्रीनशॉट दिखाएगा कि जब निर्यातक नहीं चल रहे हैं तो यह कैसा दिखता है। नीचे देखें:

और PostgreSQL डैशबोर्ड में, ग्राफ़ में "नो डेटा पॉइंट्स" लेबल के साथ एक ही लोडिंग आइकन होगा। नीचे देखें:

इसलिए, निम्नलिखित अनुभागों में अनुसरण की जाने वाली विभिन्न तकनीकों के माध्यम से इनका निवारण किया जा सकता है।

प्रोमेथियस के साथ समस्याओं का निवारण

प्रोमेथियस एजेंट, जिन्हें निर्यातकों के रूप में जाना जाता है, निम्नलिखित बंदरगाहों का उपयोग कर रहे हैं:9100 (नोड_एक्सपोर्टर), 9011 (प्रोसेस_एक्सपोर्टर), 9187 (पोस्टग्रेस_एक्सपोर्टर), 9104 (mysqld_exporter), 42004 (प्रॉक्सीस्क्ल_एक्सपोर्टर), और बहुत ही 9090 जो एक प्रोमेथियस के स्वामित्व में है। प्रक्रिया। ये इन एजेंटों के लिए पोर्ट हैं जिनका उपयोग ClusterControl द्वारा किया जाता है।

SCUMM डैशबोर्ड समस्याओं का निवारण प्रारंभ करने के लिए, आप डेटाबेस नोड से खुले पोर्ट की जाँच करके प्रारंभ कर सकते हैं। आप नीचे दी गई सूचियों का अनुसरण कर सकते हैं:

जांचें कि पोर्ट खुले हैं या नहीं

उदा.
```
## Use netstat and check the ports
[[email protected] vagrant]# netstat -tnvlp46|egrep 'ex[p]'
tcp6       0      0 :::9100                 :::*                    LISTEN      5036/node_exporter  
tcp6       0      0 :::9011                 :::*                    LISTEN      4852/process_export 
tcp6       0      0 :::9187                 :::*                    LISTEN      5230/postgres_expor 
```
इस बात की संभावना हो सकती है कि फ़ायरवॉल (जैसे कि iptables या फ़ायरवॉल) के कारण पोर्ट नहीं खुलते हैं या पोर्ट को खोलने से रोकते हैं या प्रक्रिया डेमॉन स्वयं नहीं चल रही है।

होस्ट मॉनिटर से कर्ल का उपयोग करें और सत्यापित करें कि पोर्ट पहुंच योग्य और खुला है या नहीं।

उदा.

## Using curl and grep mysql list of available metric names used in PromQL.
[[email protected] prometheus]# curl -sv mariadb_g01:9104/metrics|grep 'mysql'|head -25
* About to connect() to mariadb_g01 port 9104 (#0)
*   Trying 192.168.10.10...
* Connected to mariadb_g01 (192.168.10.10) port 9104 (#0)
> GET /metrics HTTP/1.1
> User-Agent: curl/7.29.0
> Host: mariadb_g01:9104
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Length: 213633
< Content-Type: text/plain; version=0.0.4; charset=utf-8
< Date: Sat, 01 Dec 2018 04:23:21 GMT
< 
{ [data not shown]
# HELP mysql_binlog_file_number The last binlog file number.
# TYPE mysql_binlog_file_number gauge
mysql_binlog_file_number 114
# HELP mysql_binlog_files Number of registered binlog files.
# TYPE mysql_binlog_files gauge
mysql_binlog_files 26
# HELP mysql_binlog_size_bytes Combined size of all registered binlog files.
# TYPE mysql_binlog_size_bytes gauge
mysql_binlog_size_bytes 8.233181e+06
# HELP mysql_exporter_collector_duration_seconds Collector time duration.
# TYPE mysql_exporter_collector_duration_seconds gauge
mysql_exporter_collector_duration_seconds{collector="collect.binlog_size"} 0.008825006
mysql_exporter_collector_duration_seconds{collector="collect.global_status"} 0.006489491
mysql_exporter_collector_duration_seconds{collector="collect.global_variables"} 0.00324821
mysql_exporter_collector_duration_seconds{collector="collect.info_schema.innodb_metrics"} 0.008209824
mysql_exporter_collector_duration_seconds{collector="collect.info_schema.processlist"} 0.007524068
mysql_exporter_collector_duration_seconds{collector="collect.info_schema.tables"} 0.010236411
mysql_exporter_collector_duration_seconds{collector="collect.info_schema.tablestats"} 0.000610684
mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.eventswaits"} 0.009132491
mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.file_events"} 0.009235416
mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.file_instances"} 0.009451361
mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.indexiowaits"} 0.009568397
mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.tableiowaits"} 0.008418406
mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.tablelocks"} 0.008656682
mysql_exporter_collector_duration_seconds{collector="collect.slave_status"} 0.009924652
* Failed writing body (96 != 14480)
* Closing connection 0

आदर्श रूप से, मैंने व्यावहारिक रूप से इस दृष्टिकोण को मेरे लिए व्यवहार्य पाया क्योंकि मैं टर्मिनल से आसानी से grep और डिबग कर सकता हूं।

वेब UI का उपयोग क्यों न करें?
- प्रोमेथियस पोर्ट 9090 को उजागर करता है जिसका उपयोग हमारे SCUMM डैशबोर्ड में ClusterControl द्वारा किया जाता है। इसके अलावा, निर्यातक जिन बंदरगाहों को उजागर कर रहे हैं, उनका उपयोग प्रोमक्यूएल का उपयोग करके उपलब्ध मीट्रिक नामों के समस्या निवारण और निर्धारण के लिए भी किया जा सकता है। सर्वर में जहां प्रोमेथियस चल रहा है, आप http:// :9090/targets पर जा सकते हैं। . नीचे दिया गया स्क्रीनशॉट इसे क्रिया में दिखाता है:
  
  और "समापन बिंदु" पर क्लिक करके, आप मेट्रिक्स के साथ-साथ नीचे दिए गए स्क्रीनशॉट को भी सत्यापित कर सकते हैं:
  
  आईपी पते का उपयोग करने के बजाय, आप स्थानीय रूप से उस विशिष्ट नोड पर स्थानीयहोस्ट के माध्यम से भी देख सकते हैं जैसे कि http://localhost:9104/metrics या तो वेब UI इंटरफ़ेस में या cURL का उपयोग करके।
  
  अब, यदि हम "लक्ष्य . पर वापस जाते हैं "पृष्ठ, आप उन नोड्स की सूची देख सकते हैं जहां पोर्ट के साथ कोई समस्या हो सकती है। इसके कारण जो कारण हो सकते हैं वे नीचे सूचीबद्ध हैं:
  - सर्वर डाउन है
  - फ़ायरवॉल के चलने के कारण नेटवर्क पहुंच योग्य नहीं है या पोर्ट नहीं खुले हैं
  - डेमॉन नहीं चल रहा है जहां _exporter नहीं चल रहा है। उदाहरण के लिए, mysqld_exporter नहीं चल रहा है।

जब ये निर्यातक चल रहे हों, तो आप डेमन . का उपयोग करके प्रक्रिया को सक्रिय और चला सकते हैं आज्ञा। आप उपलब्ध चल रही प्रक्रियाओं का उल्लेख कर सकते हैं जिनका मैंने ऊपर उदाहरण में उपयोग किया था, या इस ब्लॉग के पिछले भाग में उल्लेख किया था।

मेरे डैशबोर्ड में "नो डेटा पॉइंट्स" ग्राफ़ के बारे में क्या?

SCUMM डैशबोर्ड एक सामान्य उपयोग केस परिदृश्य के साथ आते हैं जो आमतौर पर MySQL द्वारा उपयोग किया जाता है। हालाँकि, कुछ चर होते हैं जब ऐसे मीट्रिक को लागू करना किसी विशेष MySQL संस्करण या MySQL विक्रेता, जैसे कि MariaDB या Percona Server में उपलब्ध नहीं हो सकता है।

मुझे नीचे एक उदाहरण दिखाने दें:

यह ग्राफ wsrep_25.23 उदाहरण के wsrep_patch_version के साथ संस्करण 10.3.9-MariaDB-log MariaDB सर्वर पर चलने वाले डेटाबेस सर्वर पर लिया गया था। अब सवाल यह है कि कोई डेटा पॉइंट लोड क्यों नहीं हो रहा है? ठीक है, जैसा कि मैंने चेकपॉइंट की उम्र की स्थिति के लिए नोड से पूछताछ की, यह पता चलता है कि यह खाली है या कोई चर नहीं मिला है। नीचे देखें:

MariaDB [(none)]> show global status like 'Innodb_checkpoint_max_age';
Empty set (0.000 sec)

मुझे नहीं पता कि मारियाडीबी में यह चर क्यों नहीं है (यदि आपके पास उत्तर है तो कृपया हमें इस ब्लॉग के टिप्पणी अनुभाग में बताएं)। यह एक Percona XtraDB क्लस्टर सर्वर के विपरीत है जहां चर Innodb_checkpoint_max_age मौजूद है। नीचे देखें:

mysql> show global status like 'Innodb_checkpoint_max_age';
+---------------------------+-----------+
| Variable_name             | Value     |
+---------------------------+-----------+
| Innodb_checkpoint_max_age | 865244898 |
+---------------------------+-----------+
1 row in set (0.00 sec)

हालांकि इसका मतलब यह है कि, ऐसे ग्राफ़ हो सकते हैं जिनमें डेटा बिंदु एकत्रित नहीं होते हैं क्योंकि प्रोमेथियस क्वेरी निष्पादित होने पर उस विशेष मीट्रिक पर कोई डेटा काटा नहीं जा रहा है।

हालांकि, एक ग्राफ जिसमें डेटा बिंदु नहीं हैं, इसका मतलब यह नहीं है कि MySQL का आपका वर्तमान संस्करण या इसका संस्करण इसका समर्थन नहीं करता है। उदाहरण के लिए, कुछ ऐसे ग्राफ़ हैं जिनके लिए कुछ चरों की आवश्यकता होती है जिन्हें ठीक से सेटअप या सक्षम करने की आवश्यकता होती है।

निम्न अनुभाग दिखाएगा कि ये ग्राफ़ क्या हैं।

इंडेक्स कंडीशन पुशडाउन (ICP) ग्राफ़

इस ग्राफ का उल्लेख मेरे पिछले ब्लॉग में किया गया है। यह एक MySQL ग्लोबल वैरिएबल पर निर्भर करता है जिसका नाम innodb_monitor_enable है। यह चर गतिशील है इसलिए आप इसे अपने MySQL डेटाबेस के हार्ड रीस्टार्ट के बिना सेट कर सकते हैं। इसके लिए innodb_monitor_enable =module_icp की भी आवश्यकता होती है या आप इस वैश्विक चर को innodb_monitor_enable =all पर सेट कर सकते हैं। आमतौर पर, ऐसे मामलों और भ्रम से बचने के लिए कि ऐसा ग्राफ़ कोई डेटा बिंदु क्यों नहीं दिखाता है, आपको सावधानी के अलावा सभी का उपयोग करना पड़ सकता है। जब इस चर को चालू किया जाता है और सभी पर सेट किया जाता है, तो कुछ ओवरहेड हो सकता है।

MySQL प्रदर्शन स्कीमा ग्राफ़

तो ये ग्राफ़ "कोई डेटा बिंदु नहीं" क्यों दिखा रहे हैं? जब आप हमारे टेम्प्लेट का उपयोग करके ClusterControl का उपयोग करके एक क्लस्टर बनाते हैं, तो डिफ़ॉल्ट रूप से यह performance_schema चर को परिभाषित करेगा। उदाहरण के लिए, ये चर नीचे सेट किए गए हैं:

performance_schema = ON
performance-schema-max-mutex-classes = 0
performance-schema-max-mutex-instances = 0

हालांकि, अगर performance_schema =OFF है, तो यही कारण है कि संबंधित ग्राफ़ "कोई डेटा बिंदु नहीं" प्रदर्शित करेंगे।

लेकिन मेरे पास performance_schema सक्षम है, अन्य ग्राफ़ अभी भी एक समस्या क्यों हैं?

खैर, अभी भी ऐसे ग्राफ़ हैं जिनके लिए कई चर सेट करने की आवश्यकता है। यह हमारे पिछले ब्लॉग में पहले ही कवर किया जा चुका है। इस प्रकार, आपको innodb_monitor_enable =all और userstat=1 सेट करने की आवश्यकता है। परिणाम इस तरह दिखेगा:

हालांकि, मैंने देखा है कि मारियाडीबी 10.3 (विशेष रूप से 10.3.11) के संस्करण में, performance_schema=ON सेट करना MySQL प्रदर्शन स्कीमा डैशबोर्ड के लिए आवश्यक मीट्रिक को पॉप्युलेट करेगा। यह बहुत अच्छा लाभ है क्योंकि इसमें innodb_monitor_enable=ON सेट करने की आवश्यकता नहीं है जो डेटाबेस सर्वर पर अतिरिक्त ओवरहेड जोड़ देगा।

उन्नत समस्या निवारण

क्या कोई अग्रिम समस्या निवारण है जिसकी मैं अनुशंसा कर सकता हूं? हाँ वहाँ है! हालांकि, आपको कम से कम कुछ जावास्क्रिप्ट कौशल की आवश्यकता है। चूंकि प्रोमेथियस का उपयोग करने वाले एससीयूएमएम डैशबोर्ड हाईचार्ट्स पर निर्भर करते हैं, जिस तरह से प्रोमक्यूएल अनुरोधों के लिए उपयोग किए जा रहे मीट्रिक को ऐप.जेएस स्क्रिप्ट के माध्यम से निर्धारित किया जा सकता है जो नीचे दिखाया गया है:

इसलिए इस मामले में, मैं Google Chrome के DevTools का उपयोग कर रहा हूं और प्रदर्शन स्कीमा प्रतीक्षा (ईवेंट) देखने का प्रयास किया है। . यह कैसे मदद कर सकता है? ठीक है, यदि आप लक्ष्यों को देखते हैं, तो आप देखेंगे:

targets: [{
expr: 'topk(5, rate(mysql_perf_schema_events_waits_total{instance="$instance"}[$interval])>0) or topk(5, irate(mysql_perf_schema_events_waits_total{instance="$instance"}[5m])>0)',
legendFormat: "{{event_name}} "
}]

अब, आप अनुरोधित मेट्रिक्स का उपयोग कर सकते हैं जो कि mysql_perf_schema_events_waits_total है। आप इसे देख सकते हैं, उदाहरण के लिए, http:// :9090/graph के माध्यम से जाकर जांच सकते हैं कि क्या एकत्रित मीट्रिक हैं। नीचे देखें:

ClusterControl स्वत:पुनर्प्राप्ति बचाव के लिए!

अंत में, मुख्य प्रश्न यह है कि क्या असफल निर्यातकों को पुनः आरंभ करने का कोई आसान तरीका है? हां! हमने पहले उल्लेख किया था कि ClusterControl निर्यात की स्थिति को देखता है और यदि आवश्यक हो तो उन्हें पुनः आरंभ करता है। यदि आप देखते हैं कि SCUMM डैशबोर्ड सामान्य रूप से ग्राफ़ लोड नहीं करते हैं, तो सुनिश्चित करें कि आपके पास स्वतः पुनर्प्राप्ति सक्षम है। नीचे दी गई छवि देखें:

जब इसे सक्षम किया जाता है, तो यह सुनिश्चित करेगा कि <प्रक्रिया>_निर्यातक सही ढंग से शुरू किया जाएगा अगर यह पता लगाता है कि ये नहीं चल रहे हैं। ClusterControl आपके लिए इसे संभाल लेगा और आगे कोई कार्रवाई करने की आवश्यकता नहीं है।

निर्यातकों को फिर से स्थापित या फिर से कॉन्फ़िगर करना भी संभव है।

निष्कर्ष

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

आपने यह भी सीखा कि हमारे SCUMM डैशबोर्ड को कैसे डिबग करना है, खासकर जब कोई डेटा बिंदु एकत्र नहीं किया जाता है।

यदि आपके कोई प्रश्न हैं, तो कृपया अपनी टिप्पणियों में जोड़ें या हमारे सामुदायिक मंचों के माध्यम से हमें बताएं।