आपको अपने PostgreSQL परिनियोजन के किन मीट्रिक की निगरानी करनी चाहिए? ब्लॉग पोस्ट की इस श्रृंखला का उद्देश्य आवश्यक निगरानी क्रियाओं का एक न्यूनतम, प्रारंभिक सेट प्रदान करना है जिसे आपको अपने पोस्टग्रेज सर्वर के स्वास्थ्य और स्थिरता को सुनिश्चित करने के लिए लागू करना चाहिए।
पहले भाग में क्लस्टर-स्तरीय पैरामीटर शामिल हैं।
भाग 1:क्लस्टर स्तर
पोस्टग्रेज शब्दजाल में, एक क्लस्टर डेटाबेस का एक सेट है जिसे सिंगलपोस्टग्रेस सर्वर इंस्टेंस द्वारा प्रबंधित किया जाता है। प्रतिकृति और WAL अभिलेखीय कार्य जैसी सुविधाएं क्लस्टर स्तर पर काम करती हैं।
1. लेन-देन आईडी श्रेणी
एक सामान्य क्लाइंट के दृष्टिकोण से, पोस्टग्रेएसक्यूएल क्लस्टर की डेटा फाइलें अंतिम प्रतिबद्ध लेनदेन द्वारा संशोधित डेटा के स्नैपशॉट को समाहित करती हुई दिखाई देंगी। हालांकि, पोस्टग्रेस के एमवीसीसी आर्किटेक्चर के कारण, भौतिक फाइलों में न केवल सबसे हालिया लेनदेन के लिए डेटा होता है, बल्कि नवीनतम लेनदेन के साथ समाप्त होने वाले लेनदेन के लिए भी डेटा होता है। (नियमित वैक्यूमिंग पुराने लेनदेन के डेटा से छुटकारा दिलाता है।)
प्रत्येक लेन-देन में एक अद्वितीय 32-बिट पूर्णांक पहचानकर्ता होता है, जिसे लेनदेन आईडी . कहा जाता है . विभिन्न कारणों से, पहली और अंतिम लेन-देन आईडी का अंतर 2 से कम होना चाहिए, जो लगभग 2 बिलियन है। सीमा को इस सीमा से काफी नीचे रखना एक जरूरी है - इस वास्तविक जीवन की कहानी को पढ़ें अन्यथा क्या होता है।
कार्रवाई:लेन-देन आईडी श्रेणी की निरंतर निगरानी करें, यदि मान एक निर्धारित सीमा से अधिक हो तो अलर्ट करें।
कैसे करें:
-- returns the first and last transactions IDs for the cluster
SELECT oldest_xid::text::int as first,
regexp_replace(next_xid, '^[0-9]+:', '')::int-1 as last
FROM pg_control_checkpoint();
-- returns the transaction ID range for each database
SELECT datname, age(datfrozenxid)
FROM pg_database;2. बैकएंड की संख्या
प्रत्येक बैकएंड या तो सर्वर से जुड़े क्लाइंट या सिस्टमबैकएंड प्रक्रिया (जैसे ऑटो वैक्यूम वर्कर, बैकग्राउंड राइटर आदि) का प्रतिनिधित्व करता है। प्रत्येक बैकएंडिस एक ओएस प्रक्रिया भी है जो मेमोरी, ओपन फाइल डिस्क्रिप्टर आदि जैसे ओएस संसाधनों का उपभोग करती है। बहुत अधिक बैकएंड, आमतौर पर बहुत अधिक क्लाइंट या बहुत अधिक लंबे समय तक चलने वाली क्वेरीज़ ओएस संसाधनों पर दबाव डाल सकती हैं और प्रत्येक क्लाइंट के लिए क्वेरी प्रतिक्रिया समय धीमा कर सकती हैं।
कार्रवाई:प्रत्येक दिन/सप्ताह में अधिकतम बैकएंड गणना की निगरानी करें, बढ़ते रुझानों की जांच करें।
कैसे करें:
-- returns the count of currently running backends
SELECT count(*)
FROM pg_stat_activity;3. निष्क्रिय प्रतिकृति स्लॉट
जब प्रतिकृति क्लाइंट स्लॉट से कनेक्ट होता है तो प्रतिकृति स्लॉट को 'निष्क्रिय' के रूप में चिह्नित किया जाता है। निष्क्रिय प्रतिकृति स्लॉट WAL फ़ाइलों को बनाए रखने का कारण बनते हैं, क्योंकि उन्हें क्लाइंट को फिर से कनेक्ट होने पर भेजा जाना होगा और स्लॉट सक्रिय हो जाएंगे। वास्तव में, यह जांचने के लिए पहली चीज है कि क्या आपकी WAL फाइल की संख्या कम नहीं होती है, यह देखना है कि क्या आपके पास निष्क्रिय प्रतिकृति स्लॉट हैं।
अक्सर निष्क्रिय प्रतिकृति स्लॉट एक बैकअप क्लाइंट का परिणाम होता है जिसे हटा दिया गया था, एक दास जिसे हटा दिया गया था, पदोन्नति, विफलता और इसी तरह।
कार्रवाई:निष्क्रिय प्रतिकृति स्लॉट की लगातार जांच करें, यदि कोई हो तो अलर्ट करें।
कैसे करें:
-- returns the count of inactive replication slots
SELECT count(*)
FROM pg_replication_slots
WHERE NOT active;4. बैकएंड लॉक पर प्रतीक्षा कर रहा है
SQL कथन स्पष्ट रूप से या परोक्ष रूप से अन्य SQL कथनों को प्रतीक्षा करने का कारण बन सकते हैं। उदाहरण के लिए, "चयन .. अद्यतन के लिए" चलाना स्पष्ट रूप से इन चयनित पंक्तियों के लिए लॉक घोषित करता है, और "अद्यतन" चलाने से पंक्ति-अनन्य ताले निहित होते हैं। अन्य SQL कथन जब लॉक का सामना करने के लिए तब तक इंतजार करना होगा जब तक कि पहला स्टेटमेंट लॉक को छोड़ नहीं देता, इसके निष्पादन को जारी रखने से पहले।
यह साप्ताहिक रिपोर्ट रन, टाइम आउट लेनदेन/वेब पेज और इसी तरह के दौरान धीमी एप्लिकेशन प्रदर्शन के रूप में प्रकट हो सकता है।
हालांकि लॉकिंग की कुछ मात्रा को टाला नहीं जा सकता है, बैकएंड की बढ़ती प्रवृत्ति लॉक के लिए प्रतीक्षा कर रही है, आमतौर पर प्रश्नों या एप्लिकेशन लॉजिक को पुनर्गठित करने की आवश्यकता होती है।
कार्रवाई:प्रत्येक दिन/सप्ताह में लॉक पर प्रतीक्षा कर रहे बैकएंड की अधिकतम संख्या की निगरानी करें, बढ़ते रुझानों की जांच करें।
कैसे करें:
-- returns the count of backends waiting on locks
SELECT count(*)
FROM pg_stat_activity
WHERE wait_event = 'Lock';5. बैकएंड लेन-देन में निष्क्रिय रहता है
PostgreSQL की दुनिया में लंबे समय तक चलने वाले लेन-देन बहुत अच्छे नहीं हैं। वे WAL फ़ाइलों को बनाने, ऑटोवैक्यूम और मैनुअल वैक्यूम को रोकने और संसाधनों का उपयोग करने का कारण बन सकते हैं। वास्तविक लेन-देन के बारे में बहुत कुछ नहीं किया जा सकता है जिसे पूरा होने में लंबा समय लगता है, लेकिन दुर्व्यवहार करने वाले ऐप्स/स्क्रिप्ट और कभी-कभी psql क्लाइंट जैसे मामले हैं जो लेनदेन शुरू करते हैं लेकिन उन्हें बंद नहीं करते हैं। ऐसे क्लाइंट की सेवा करने वाले बैकएंड "लेन-देन में निष्क्रिय" के रूप में दिखाई देते हैं।
लेन-देन में निष्क्रिय बैकएंड का पता लगाया जाना चाहिए और सिस्टम स्थिरता को प्रभावित करने से पहले बंद कर दिया जाना चाहिए।
कार्रवाई:लेन-देन में निष्क्रिय बैकएंड की संख्या की लगातार निगरानी करें, यदि कोई पाया जाता है तो समीक्षा करें।
कैसे करें:
-- returns the count of backends waiting on locks
SELECT count(*)
FROM pg_stat_activity
WHERE state = 'idle in transaction';6. सक्रिय कनेक्शन के लिए प्रतिकृति अंतराल
जब सक्रिय स्ट्रीमिंग प्रतिकृति क्लाइंट (हॉट स्टैंडबाय की तरह) या सक्रिय तार्किक प्रतिकृति क्लाइंट होते हैं, तो Postgres एक सिस्टम बैकएंड चलाता है जिसे WAL प्रेषक कहा जाता है। प्रत्येक सक्रिय (जुड़े) क्लाइंट के लिए। WAL प्रेषक WAL रिकॉर्ड डेटा भेजने के लिए ज़िम्मेदार होता है जिसकी क्लाइंट को आवश्यकता होती है।
प्रतिकृति क्लाइंट आमतौर पर प्राथमिक के साथ जितना हो सके उतना बनाए रखने की कोशिश करते हैं। हालांकि, कभी-कभी, प्राथमिक स्तर पर WAL उत्पादन दर उस दर से अधिक हो सकती है जिस पर ग्राहक उनका उपभोग करने में सक्षम होता है। इसका परिणाम प्रतिकृति अंतराल . में होता है प्रत्येक प्रतिकृति कनेक्शन के लिए।
पोस्टग्रेएसक्यूएल लैग लिखने के लिए क्वेरी करने के लिए एक तंत्र प्रदान करता है (भेजे गए बाइट्स की संख्या लेकिन क्लाइंट की डिस्क पर नहीं लिखा गया है), फ्लश लैग (लिखे गए बाइट्स की संख्या लेकिन क्लाइंट की डिस्क पर फ्लश नहीं किया गया) और रीप्ले लैग (बाइट्स की संख्या फ्लश की गई लेकिन क्लाइंट में फिर से नहीं चलाई गई) डेटाबेस फ़ाइलें) प्रत्येक सक्रिय WAL प्रेषक के लिए।
कार्रवाई:सक्रिय कनेक्शन के लिए लगातार प्रतिकृति अंतराल की निगरानी करें, यदि मान सेट थ्रेशोल्ड से अधिक हो तो अलर्ट करें।
कैसे करें:
-- returns the write, flush and replay lags per WAL sender, as described above
SELECT write_lsn - sent_lsn AS write_lag,
flush_lsn - write_lsn AS flush_lag,
replay_lsn - flush_lsn AS replay_lag
FROM pg_stat_replication;7. प्रतिकृति स्लॉट के लिए प्रतिकृति अंतराल
न केवल पुनरावृत्ति ग्राहक पिछड़ सकते हैं, वे क्रैश, टोपोलॉजी परिवर्तन या मानवीय त्रुटि के कारण पूरी तरह से गायब भी हो सकते हैं। यह डिज़ाइन द्वारा भी हो सकता है, जहां ग्राहक हमेशा ऑनलाइन नहीं होते हैं।
यदि क्लाइंट को प्रतिकृति स्लॉट द्वारा समर्थित किया जाता है, तो क्लाइंट के लिए आवश्यक सभी WAL फ़ाइलें पोस्टग्रेएसक्यूएल द्वारा बनाए रखी जाती हैं। TheWAL फ़ाइलें अनिश्चित काल के लिए रखी जाएंगी - कोई सीमा निर्धारित करने का कोई तरीका नहीं है। जब क्लाइंट फिर से कनेक्ट होता है, तो सभी बनाए रखा डेटा क्लाइंट को पहले स्ट्रीम किया जाना चाहिए, जिसमें प्राथमिक पर बहुत अधिक डिस्क और नेटवर्क ट्रैफ़िक शामिल हो सकता है। इन कारणों से, आपको स्लॉट-स्तर पर भी अंतराल की निगरानी करनी चाहिए।
(नोट:WAL प्रेषक प्रक्रिया केवल क्लाइंट के कनेक्ट होने पर चलती है, और क्लाइंट के डिस्कनेक्ट होने पर यह बाहर निकल जाती है। क्लाइंट के डिस्कनेक्ट होने पर क्लाइंट कितनी दूर है, यह मापने की WAL प्रेषक विधि काम नहीं करती है।)
कार्रवाई:तार्किक प्रतिकृति स्लॉट के लिए लगातार प्रतिकृति अंतराल की निगरानी करें, यदि मान एक निर्धारित सीमा से अधिक हो तो अलर्ट करें।
कैसे करें:
-- returns the replication slot lag in bytes
-- (works only for logical replication slots)
SELECT pg_current_wal_lsn() - confirmed_flush_lsn
FROM pg_replication_slots;8. वाल फ़ाइल गणना
WAL फ़ाइलों को प्रबंधित करना एक कठिन कार्य हो सकता है, खासकर यदि आपके पास WALसंग्रह या स्ट्रीमिंग प्रतिकृति क्लाइंट हैं। WAL फ़ाइल की संख्या बिना किसी स्पष्ट कारण के बढ़ना शुरू हो सकती है, WAL संग्रह प्रक्रिया WAL पीढ़ी दर को बनाए रखने में विफल हो सकती है, और कुल WAL फ़ाइल आकार टेराबाइट्स में मिल सकता है।
कम से कम, आपको अपने डेटाबेस निर्देशिका में मौजूद WAL फ़ाइलों की संख्या की निगरानी करने और यह सुनिश्चित करने की आवश्यकता है कि संख्या आपके परिनियोजन के लिए उचित लगे।
कार्रवाई:लगातार WAL फ़ाइल गणना की निगरानी करें, यदि मान एक निर्धारित सीमा से अधिक हो तो अलर्ट करें।
कैसे करें:
-- returns the number of WAL files present in the pg_wal directory (v10+)
SELECT count(*)
FROM pg_ls_waldir();
-- same, for v9.x
SELECT count(*)
FROM pg_ls_dir('pg_xlog')
WHERE pg_ls_dir ~ '^[0-9A-F]{24}$';
-- can also count the files physically present in $DBDIR/pg_wal
-- /bin/ls -l $DBDIR/pg_wal | grep -c '^-'9. संग्रह के लिए तैयार WAL फ़ाइल की संख्या
जब WAL संग्रह सक्षम किया जाता है, तो PostgreSQL हर बार एक नईWAL फ़ाइल उत्पन्न होने पर एक उपयोगकर्ता स्क्रिप्ट को आमंत्रित करता है। स्क्रिप्ट को एकल WAL फ़ाइल को "संग्रहित" करना चाहिए, जिसके लिए इसे बुलाया गया था (यह आमतौर पर इसे किसी अन्य सर्वर या S3 बाल्टी में कॉपी करता है)। यदि स्क्रिप्ट अपना काम करने में बहुत अधिक समय लेती है, या यदि यह विफल हो जाती है, तो WALfiles का सेट ढेर हो जाओ।
कार्रवाई:WAL रेडी-टू-आर्काइव फ़ाइल गणना की निरंतर निगरानी करें, यदि मान एक निर्धारित सीमा से अधिक है तो अलर्ट करें।
कैसे करें:
-- returns the number of WAL files ready to be archived (v12+)
SELECT count(*)
FROM pg_ls_archive_statusdir()
WHERE name ~ '^[0-9A-F]{24}.ready$';
-- same, for v10+
SELECT count(*)
FROM pg_ls_dir('pg_wal/archive_status')
WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';
-- same, for v9.x
SELECT count(*)
FROM pg_ls_dir('pg_xlog/archive_status')
WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';
-- can also count the *.ready files physically present in $DBDIR/pg_wal/archive_status
-- /bin/ls -l $DBDIR/pg_wal/archive_status | grep -c .readyइन मेट्रिक को कलेक्ट करना
उपरोक्त अनुभाग चल रहे Postgres सर्वर से आवश्यक मीट्रिक निकालने के लिए SQL कथन प्रदान करते हैं। यदि आप स्वयं स्क्रिप्ट नहीं लिखना चाहते हैं, तो ओपन सोर्स टूल pgmetrics देखें। यह ऊपर दिए गए मेट्रिक और बहुत कुछ एकत्र कर सकता है, और उन्हें टेक्स्ट और JSON प्रारूपों में रिपोर्ट कर सकता है।
आप सीधे हमारी व्यावसायिक पेशकश, pgDash को pgmetrics रिपोर्ट भेज सकते हैं, जो ग्राफ़ प्रदर्शित करने और अलर्ट करने के लिए इन रिपोर्टों को संग्रहीत और संसाधित करती है।
अगला ऊपर
इस श्रृंखला के आगे के भाग डेटाबेस-स्तर, तालिका-स्तर, अनुक्रमणिका-स्तर और सिस्टम-स्तरीय मीट्रिक को कवर करेंगे। बने रहें!
