उपयोग, लाल, PgBouncer, इसकी सेटिंग्स और निगरानी

हमने अपनी सेवा में PgBouncer के लिए निगरानी अपडेट करना शुरू कर दिया और सब कुछ थोड़ा कंघी करने का फैसला किया। सब कुछ फिट करने के लिए, हमने टॉम विल्की से ब्रेंडन ग्रेग और RED (अनुरोध, त्रुटियां, अवधि) द्वारा सबसे प्रसिद्ध प्रदर्शन निगरानी के तरीके: USE (उपयोग, संतृप्ति, त्रुटियां) पर खींच लिया।

Cutscene के तहत ग्राफ़िक्स के साथ एक कहानी है कि कैसे pgbouncer काम करता है, इसकी कॉन्फ़िगरेशन क्या है और इसे मॉनिटर करने के लिए सही मैट्रिक्स चुनने के लिए USE / RED का उपयोग कैसे किया जाता है।

सबसे पहले खुद तरीकों के बारे में

यद्यपि ये विधियां काफी प्रसिद्ध हैं ( उनके बारे में यह पहले से ही हैबर पर था, हालांकि महान विवरण में नहीं ), ऐसा नहीं है कि वे व्यवहार में व्यापक हैं।

उपयोग

प्रत्येक संसाधन के लिए, निपटान, संतृप्ति और त्रुटियों पर नज़र रखें।
ब्रेंडन ग्रीग

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

यू - निपटान : या तो समय का एक प्रतिशत (अवलोकन अंतराल से) जब संसाधन उपयोगी कार्य में व्यस्त था। उदाहरण के लिए, CPU या डिस्क उपयोग 90% लोड करने का अर्थ है कि 90% समय किसी उपयोगी चीज द्वारा लिया गया था) या, स्मृति जैसे संसाधनों के लिए, यह उपयोग की गई स्मृति का प्रतिशत है।

किसी भी मामले में, 100% रीसाइक्लिंग का मतलब है कि संसाधन का उपयोग अब से अधिक नहीं किया जा सकता है। और या तो काम जारी होने / कतार में जाने के इंतजार में अटक जाएगा, या त्रुटियां होंगी। ये दो परिदृश्य इसी शेष बचे USE मैट्रिक्स द्वारा कवर किए गए हैं:

एस - संतृप्ति , यह संतृप्ति भी है: "आस्थगित" / कतारबद्ध काम की मात्रा का एक उपाय।

ई - त्रुटियां : हम बस विफलताओं की संख्या की गणना करते हैं। त्रुटियां / विफलताएं प्रदर्शन को प्रभावित करती हैं, लेकिन फ़्लिप किए गए संचालन या बैकअप सहिष्णुता के साथ दोष सहिष्णुता तंत्र, आदि प्राप्त करने के कारण तुरंत ध्यान देने योग्य नहीं हो सकती हैं।

लाल

टॉम विल्की (अब ग्राफाना लैब्स में काम कर रहे) को USE कार्यप्रणाली, या इसके बजाय, कुछ मामलों में इसकी खराब प्रयोज्यता और अभ्यास के साथ असंगतता से निराशा हुई। कैसे, उदाहरण के लिए, स्मृति की संतृप्ति को मापने के लिए? या व्यवहार में सिस्टम बस त्रुटियों को कैसे मापें?

लिनक्स, यह पता चला है, वास्तव में बग मायने रखता है।
टी। विल्की

संक्षेप में, माइक्रोसर्विसेस के प्रदर्शन और व्यवहार की निगरानी के लिए, उन्होंने एक और, उपयुक्त विधि का प्रस्ताव किया: फिर से, तीन संकेतक:

आर - दर : प्रति सेकंड अनुरोधों की संख्या।
ई - त्रुटियां : कितने अनुरोधों में त्रुटि हुई।
D - अवधि : अनुरोध को संसाधित करने में लगने वाला समय। यह विलंबता है, "विलंबता" (© स्वेता स्मिरनोवा :), प्रतिक्रिया समय, आदि।

सामान्य तौर पर, USE संसाधनों की निगरानी के लिए अधिक उपयुक्त है, और सेवाओं और उनके कार्यभार / पेलोड के लिए RED।

PgBouncer

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

इन तरीकों को बाउंसर पर कैसे लागू किया जाए, यह समझने के लिए, आपको इसके उपकरण के विवरण को समझने की आवश्यकता है। इसे ब्लैक-बॉक्स के रूप में मॉनिटर करने के लिए पर्याप्त नहीं है - "जीवित रहने की प्रक्रिया" या "पोर्ट ओपन है", क्योंकि समस्याओं के मामले में यह समझ में नहीं आएगा कि वास्तव में यह कैसे और कैसे टूट गया और क्या करना है।

PgBouncer ग्राहक के दृष्टिकोण से कैसा दिखता है

1. ग्राहक जोड़ता है
2. [क्लाइंट अनुरोध करता है - एक प्रतिक्रिया प्राप्त करता है] x उसे कितनी बार चाहिए

यहां मैंने PgBoucer के दृष्टिकोण से संबंधित क्लाइंट राज्यों का एक आरेख तैयार किया है:

लॉगिन प्रक्रिया में, प्राधिकरण स्थानीय रूप से (फ़ाइलें, प्रमाण पत्र और यहां तक ​​कि नए संस्करणों से पीएएम और एचबीए), और दूरस्थ रूप से - अर्थात् दोनों हो सकता है। डेटाबेस में ही जिससे कनेक्शन करने का प्रयास किया जा रहा है। इस प्रकार, लॉगिन राज्य का एक अतिरिक्त विकल्प है। इस समय डेटाबेस में auth_query है, यह इंगित करने के लिए इसे Executing करना कहते हैं:

लेकिन ये क्लाइंट कनेक्शन वास्तव में बैकएंड / अपस्ट्रीम कनेक्शन के साथ मेल खाते हैं जो PgBouncer पूल के भीतर खुलता है और एक सीमित संख्या रखता है। और वे क्लाइंट को केवल समय के लिए इस तरह का कनेक्शन देते हैं - सत्र की अवधि, लेनदेन या अनुरोध के आधार पर, पूलिंग के प्रकार ( pool_mode सेटिंग द्वारा निर्धारित) पर निर्भर करता है। सबसे अधिक बार, लेनदेन पूलिंग का उपयोग किया जाता है (हम मुख्य रूप से बाद में इस पर चर्चा करेंगे) - जब कनेक्शन एक लेनदेन के लिए क्लाइंट को जारी किया जाता है, और बाकी समय क्लाइंट वास्तव में सर्वर से जुड़ा नहीं होता है। इस प्रकार, क्लाइंट की "सक्रिय" स्थिति हमें थोड़ा बताती है, और हम इसे सब्सट्रेट में विभाजित करेंगे:

ऐसा प्रत्येक ग्राहक अपने स्वयं के कनेक्शन पूल में आता है, जिसे पोस्टग्रेज के वास्तविक कनेक्शन द्वारा उपयोग के लिए जारी किया जाएगा। यह PgBouncer का मुख्य कार्य है - Postgres से कनेक्शन की संख्या को सीमित करना।

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

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

यदि हम अब पीछे की ओर से देखते हैं - सर्वर कनेक्शनों की तरफ से, तो, तदनुसार, वे ऐसे राज्यों में हैं: जब कनेक्शन के तुरंत बाद प्राधिकरण होता है - क्लाइंट द्वारा उपयोग किया गया - SV_LOGIN , जारी किया गया और (संभवतः) - SV_ACTIVE , या स्वतंत्र रूप से - SV_IDLE ।

PgBouncer के लिए उपयोग करें

इस प्रकार हम एक विशिष्ट पूल के उपयोग (भोले संस्करण) पर आते हैं:

 Pool utiliz =    /   

PgBouncer में एक विशेष pgbouncer यूटिलिटी डेटाबेस है जिसमें एक SHOW POOLS जो प्रत्येक पूल के कनेक्शन की वर्तमान स्थिति प्रदर्शित करता है:

4 ग्राहक कनेक्शन खुले हैं और उनमें से सभी cl_active । 5 सर्वर कनेक्शनों में से - 4 sv_active और एक नए राज्य sv_used ।

SHOW POOLS (कुछ प्रोमेथियस एक्सपोर्टर द्वारा) को सावधानीपूर्वक मैट्रिक्स में ले कर हम इन राज्यों को प्लॉट कर सकते हैं:

लेकिन निपटान में जाने के लिए आपको कुछ सवालों के जवाब देने की जरूरत है:

• पूल का आकार क्या है?
• कैसे गणना करें कि कितने यौगिकों का उपयोग किया जाता है? चुटकुलों में या समय में, औसतन या शिखर पर?

पूल का आकार

यहां सब कुछ जटिल है, जैसा कि जीवन में। कुल मिलाकर, pbbouncer में पहले से ही पाँच सेटिंग्स-सीमाएँ हैं!

• प्रत्येक डेटाबेस के लिए pool_size सेट किया जा सकता है। प्रत्येक डीबी / उपयोगकर्ता जोड़ी के लिए एक अलग पूल बनाया गया है, अर्थात किसी भी अतिरिक्त उपयोगकर्ता से, आप एक और pool_size बैकएंड / पोस्टग्रेज वर्कर बना सकते हैं। क्योंकि यदि pool_size सेट नहीं है, तो यह default_pool_size में गिर जाता है, जो 20 तक चूक जाता है, फिर यह पता चलता है कि प्रत्येक उपयोगकर्ता जिसे डेटाबेस से कनेक्ट करने का अधिकार है (और pgbouncer के माध्यम से काम करता है) संभावित रूप से 20 पोस्ट प्रक्रियाएँ बना सकता है, जो अधिक नहीं लगती है। लेकिन अगर आपके पास डेटाबेस या डेटाबेस के कई अलग-अलग उपयोगकर्ता हैं, और पूल एक निश्चित उपयोगकर्ता के साथ पंजीकृत नहीं हैं, अर्थात। मक्खी पर बनाया जाएगा (और फिर autodb_idle_timeout द्वारा हटा दिया autodb_idle_timeout ), तो यह खतरनाक हो सकता है =)
  

  यह हर फायरमैन के लिए default_pool_size छोटा छोड़ने लायक हो सकता है।
  

• max_db_connections - केवल एक डेटाबेस के लिए कनेक्शन की कुल संख्या को सीमित करने की आवश्यकता है, क्योंकि अन्यथा बुरी तरह से व्यवहार करने वाले ग्राहक कई बैकएंड / पोस्टग्रेज प्रोसेस बना सकते हैं। और यहाँ डिफ़ॉल्ट रूप से - असीमित (_ (default) _ / unlimited
  

  हो सकता है कि आपको डिफ़ॉल्ट max_db_connections बदलना चाहिए, उदाहरण के लिए, आप अपने Postgres (डिफ़ॉल्ट 100 द्वारा) के max_connections पर ध्यान केंद्रित कर सकते हैं। लेकिन अगर आपके पास कई PgBouncers हैं ...
  

• reserve_pool_size - वास्तव में, यदि pool_size उपयोग किया जाता है, तो PgBouncer आधार के लिए कई और कनेक्शन खोल सकता है। जैसा कि मैं इसे समझता हूं, यह भार में वृद्धि के साथ सामना करने के लिए किया जाता है। हम इस पर वापस आएंगे।
• max_user_connections - यह, इसके विपरीत, एक उपयोगकर्ता से सभी डेटाबेस के लिए कनेक्शन की सीमा है, अर्थात। प्रासंगिक यदि आपके पास कई डेटाबेस हैं और वे एक ही उपयोगकर्ता के अंतर्गत आते हैं।
• max_client_conn - PgBouncer कुल कितने ग्राहक कनेक्शन स्वीकार करेगा। डिफ़ॉल्ट, हमेशा की तरह, एक बहुत ही अजीब अर्थ है - 100. यही है, यह माना जाता है कि यदि 100 से अधिक क्लाइंट अचानक दुर्घटनाग्रस्त हो जाते हैं, तो उन्हें बस टीसीपी स्तर पर चुपचाप reset करने की आवश्यकता है और (अच्छी तरह से, लॉग्स में, मुझे स्वीकार करना होगा, यह "कोई और कनेक्शन की अनुमति नहीं है (max_client_conn)")।
  

  यह अधिक से अधिक बनाने के लायक हो सकता है।
  

SHOW POOLS अलावा SHOW POOLS सेवा छद्म-बेस pgbouncer SHOW DATABASES भी प्रदान करता है, जो वास्तव में किसी विशेष पूल पर लागू होने वाली सीमाओं को दर्शाता है:

सर्वर कनेक्शन

एक बार फिर - कैसे मापें कि कितने यौगिकों का उपयोग किया जाता है?
चुटकुलों में औसत / पीक में / समय में?

व्यवहार में, यह व्यापक उपकरण के साथ बाउंसर द्वारा पूल के उपयोग की निगरानी करने के लिए काफी समस्याग्रस्त है pgbouncer खुद को केवल एक क्षणिक तस्वीर प्रदान करता है, और जैसा कि अक्सर कोई सर्वेक्षण नहीं करता है, नमूना लेने के कारण गलत चित्र की संभावना अभी भी है। यहाँ एक वास्तविक उदाहरण है, जब निर्यातक द्वारा काम किए जाने पर निर्भर करता है - मिनट की शुरुआत में या अंत में - दोनों खुले और उपयोग किए गए यौगिकों की तस्वीर मौलिक रूप से बदलती है:

यहां कनेक्शनों के लोड / उपयोग में सभी परिवर्तन केवल एक कल्पना है, जो आंकड़े कलेक्टर के पुनरारंभ की एक कलाकृति है। यहाँ आप इस समय के दौरान Postgres में कनेक्शन ग्राफ़ देख सकते हैं और बाउंसर और PG के फ़ाइल डिस्क्रिप्टर - कोई विकल्प नहीं:

निपटान के मुद्दे पर वापस। हमने अपनी सेवा में एक संयुक्त दृष्टिकोण का उपयोग करने का निर्णय लिया - हम एक दूसरे के बाद एक बार SHOW POOLS नमूना लेते हैं, और एक मिनट में हम प्रत्येक वर्ग में कनेक्शन की औसत और अधिकतम संख्या दोनों प्रदान करते हैं:

और अगर हम पूल के आकार द्वारा इन सक्रिय राज्य कनेक्शनों की संख्या को विभाजित करते हैं, तो हमें इस पूल का औसत और शिखर उपयोग मिलता है और अगर यह 100% के करीब है तो अलर्ट कर सकता है।

इसके अलावा, PgBouncer में एक SHOW STATS कमांड है जो प्रत्येक अनुमानित डेटाबेस के लिए उपयोग के आंकड़े दिखाएगा:

हम कॉलम total_query_time में सबसे अधिक रुचि रखते हैं - पोस्टग्रेज में प्रश्नों को निष्पादित करने की प्रक्रिया में सभी कनेक्शनों द्वारा बिताया गया समय। और संस्करण 1.8 से मीट्रिक total_xact_time भी है - लेनदेन में बिताया गया समय। इन मैट्रिक्स के आधार पर, हम सर्वर कनेक्शन समय के उपयोग का निर्माण कर सकते हैं; यह संकेतक विषय नहीं है, कनेक्शन राज्यों से गणना के विपरीत, समस्याओं के नमूने के लिए, क्योंकि ये total_..._time काउंटर संचयी हैं और कुछ भी पास नहीं करते हैं:

तुलना

यह देखा जा सकता है कि नमूना उच्च ~ 100% उपयोग के सभी क्षणों और क्वेरी_टाइम शो को नहीं दिखाता है।

संतृप्ति और PgBouncer

आपको संतृप्ति की निगरानी करने की आवश्यकता क्यों है, क्योंकि उच्च उपयोग के कारण यह पहले से ही स्पष्ट है कि सब कुछ खराब है?

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

इस स्थिति की निगरानी कैसे की जा सकती है - अच्छी तरह से, फिर से, हम SHOW POOLS cl_waiting अनुसार cl_waiting राज्य में ग्राहकों की संख्या की गणना कर सकते हैं। एक सामान्य स्थिति में, शून्य होते हैं और शून्य से अधिक का अर्थ है इस पूल का अतिप्रवाह:

ऐसी समस्या बनी हुई है कि SHOW POOLS को केवल सैंपल किया जा सकता है, और समकालिक मुकुट या इस तरह की किसी चीज के साथ, हम बस ऐसे प्रतीक्षाशील ग्राहकों को छोड़ सकते हैं और नहीं देख सकते हैं।

आप इस ट्रिक का उपयोग कर सकते हैं, pgbouncer स्वयं पूल के 100% उपयोग का पता लगा सकता है और बैकअप पूल को खोल सकता है। इसके लिए दो सेटिंग्स जिम्मेदार हैं: reserve_pool_size - इसके आकार के लिए, जैसा कि मैंने कहा, और reserve_pool_timeout - कितने क्लाइंट को बैकअप पूल का उपयोग waiting से पहले कितने सेकंड waiting करना चाहिए। इस प्रकार, यदि हम सर्वर कनेक्शन के ग्राफ पर देखते हैं कि पोस्टग्रेज के लिए खुले कनेक्शन की संख्या पूल_साइज से अधिक है, तो पूल की संतृप्ति इस तरह थी:

जाहिर है, एक घंटे में एक बार मुकुट जैसा कुछ बहुत सारे अनुरोध करता है और पूरी तरह से पूल पर कब्जा कर लेता है। और भले ही हम उस क्षण को नहीं देखते हैं जब active कनेक्शन pool_size सीमा से अधिक हो pool_size , फिर भी pgbouncer को अतिरिक्त कनेक्शन खोलने के लिए मजबूर किया गया था।

इस ग्राफ पर भी, server_idle_timeout सेटिंग्स काम स्पष्ट रूप से दिखाई दे रही है - होल्डिंग को रोकने के लिए और कनेक्शन का उपयोग नहीं करने के बाद कितना। डिफ़ॉल्ट रूप से, यह 10 मिनट है, जिसे हम चार्ट पर देखते हैं - active चोटियों के बाद ठीक 5:00 बजे, 6:00 बजे, आदि। (क्रोन 0 * * * * ), कनेक्शन idle लटका + एक और 10 मिनट के used और करीब।

यदि आप प्रगति के मामले में सबसे आगे रहते हैं और पिछले 9 महीनों में PgBouncer को अपडेट किया है, तो आप SHOW STATS कॉलम total_wait_time में पा सकते हैं, जो संतृप्ति को सबसे अच्छा दिखाता है, क्योंकि संचयी रूप से ग्राहकों द्वारा waiting स्थिति में बिताया गया समय मानता है। उदाहरण के लिए, यहाँ - waiting 16:30 बजे दिखाई दी:

और wait_time , जो average query time तुलनीय और स्पष्ट रूप से प्रभावित होता है, 15:15 से लगभग 19 तक देखा जा सकता है:

फिर भी, क्लाइंट कनेक्शन की स्थिति की निगरानी करना अभी भी बहुत उपयोगी है, क्योंकि यह आपको न केवल इस तथ्य का पता लगाने की अनुमति देता है कि इस तरह के एक डेटाबेस के सभी कनेक्शन खर्च किए गए हैं और ग्राहकों को इंतजार करना पड़ता है, बल्कि इसलिए भी कि SHOW POOLS उपयोगकर्ताओं द्वारा अलग-अलग पूल में विभाजित किया गया है, और SHOW STATS नहीं करता है, यह आपको यह पता लगाने की अनुमति देता है कि कौन से क्लाइंट ने सभी कनेक्शनों का उपयोग किया है निर्दिष्ट आधार पर - संबंधित पूल के sv_active कॉलम के अनुसार। या मेट्रिक द्वारा

 sum_by(user, database, metric(name="pgbouncer.clients.count", state="active-link")): 

हम ओकेमीटर में और भी आगे बढ़ गए और उन ग्राहकों के आईपी पते द्वारा उपयोग किए जाने वाले कनेक्शनों को तोड़ दिया जिन्होंने उन्हें खोला और उनका उपयोग किया। यह आपको यह समझने की अनुमति देता है कि कौन से एप्लिकेशन इंस्टेंस अलग व्यवहार करते हैं:

यहां हम विशिष्ट कुबेरनेट्स के आईपी को देखते हैं जिन्हें हमें निपटने की आवश्यकता है।

त्रुटियाँ

यहां विशेष रूप से मुश्किल कुछ भी नहीं है: पेग्यून्सर लॉग्स लिखता है जिसमें यह त्रुटियों की रिपोर्ट करता है यदि क्लाइंट कनेक्शन की सीमा पूरी हो जाती है, तो सर्वर से कनेक्ट होने का समय समाप्त हो जाता है, आदि। हम अभी तक स्वयं पेग्यूनिसर लॉग तक नहीं पहुंचे हैं :(

लाल PgBouncer के लिए

जबकि USE प्रदर्शन पर अधिक केंद्रित है, अड़चन के अर्थ में, RED, मेरी राय में, सामान्य रूप से आने वाले और बाहर जाने वाले ट्रैफ़िक की विशेषताओं के बारे में अधिक है, और बाधाओं के बारे में नहीं। यही है, लाल सवाल का जवाब देता है - क्या सब कुछ ठीक काम करता है, और यदि नहीं, तो यूएसई यह समझने में मदद करेगा कि समस्या क्या है।

अनुरोध

ऐसा लगता है कि सब कुछ SQL डेटाबेस के लिए काफी सरल है और इस तरह के डेटाबेस में प्रॉक्सी / कनेक्शन खींचने के लिए - क्लाइंट SQL कथन निष्पादित करते हैं, जो अनुरोध हैं। SHOW STATS हम total_requests लेते हैं और इसके समय को व्युत्पन्न करते हैं

 rate(metric(name="pgbouncer.total_requests", database: "*")) 

लेकिन वास्तव में खींचने के विभिन्न तरीके हैं, और सबसे आम लेनदेन है। इस मोड के लिए काम की इकाई एक लेन-देन है, क्वेरी नहीं। तदनुसार, संस्करण 1.8 से शुरू होकर, Pgbouner पहले से ही दो अन्य आंकड़े प्रदान करता है - total_query_count , total_requests बजाय, और total_xact_count - पूर्ण किए गए लेनदेन की संख्या।

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

 rate(metric(name="total_requests", database="*")) / rate(metric(name="total_xact", database="*")) 

यहां हम लोड प्रोफाइल में स्पष्ट बदलाव देखते हैं, जो प्रदर्शन में बदलाव का कारण हो सकता है। और यदि आपने केवल लेन-देन या अनुरोधों की दर को देखा, तो आप इसे नहीं देख सकते।

लाल त्रुटियां

यह स्पष्ट है कि RED और USE त्रुटि की निगरानी पर प्रतिच्छेद करते हैं, लेकिन मुझे ऐसा लगता है कि USE में त्रुटियां मुख्य रूप से 100% उपयोग के कारण प्रसंस्करण त्रुटियों के अनुरोध के बारे में हैं, अर्थात्। जब सेवा अधिक काम करने से इनकार कर देती है। और RED के लिए त्रुटियां ग्राहक के दृष्टिकोण, क्लाइंट अनुरोधों के दृष्टिकोण से त्रुटियों को ठीक से मापना बेहतर होगा। यही नहीं, न केवल ऐसी स्थिति में जहां PgBouncer में पूल भरा हुआ है या किसी अन्य सीमा ने काम किया है, बल्कि यह भी कि जब "अपने स्टेटमेंट टाइमआउट के कारण स्टेटमेंट कैंसिल करना", जैसे कैंसल और रोलबैक का अनुरोध क्लाइंट द्वारा स्वयं काम किया गया हो, आदि। ई। उच्च-स्तरीय, व्यावसायिक तर्क प्रकार की त्रुटियों के करीब।

अवधियां

यहाँ फिर से संचयी काउंटरों के साथ SHOW STATS total_xact_time , total_query_time और total_wait_time हमारी मदद करेंगे, उन्हें क्रमशः अनुरोधों और लेनदेन की संख्या से विभाजित करके, हमें औसत अनुरोध समय, औसत लेन-देन का समय, प्रति लेनदेन औसत समय प्राप्त होता है। मैंने पहले से ही पहले और तीसरे के बारे में एक ग्राफ दिखाया:

और क्या आप शांत हो सकते हैं? डेटाबेस और पोस्टग्रेज के साथ काम करने में प्रसिद्ध एंटीपार्टन, विशेष रूप से, जब एप्लिकेशन एक लेनदेन खोलता है, एक अनुरोध करता है, तो उसके परिणामों को संसाधित करने के लिए (लंबे समय के लिए) शुरू होता है, या इससे भी बदतर - किसी अन्य सेवा / डेटाबेस में जाता है और वहां अनुरोध करता है। यह सब समय, लेन-देन "लटके" पोस्टग्रैज में खुलता है, फिर सेवा वापस आती है और कुछ और अनुरोध करता है, डेटाबेस में अपडेट करता है, और उसके बाद ही लेनदेन बंद कर देता है। पोस्टग्रेज के लिए यह विशेष रूप से अप्रिय है, क्योंकि पीजी कर्मी महंगे हैं। इसलिए हम इस बात की निगरानी कर सकते हैं कि जब इस तरह के आवेदन को पोस्टग्रेज idle in transaction में idle in transaction है - pg_stat_activity में state कॉलम के अनुसार, लेकिन नमूनाकरण के साथ अभी भी वही वर्णित समस्याएं हैं, क्योंकि pg_stat_activity केवल वर्तमान तस्वीर देता है। PgBouncer में, हम total_query_time में लेन-देन में total_xact_time समय से total_query_time अनुरोध में ग्राहकों द्वारा खर्च किए गए समय को घटा सकते हैं - यह इस तरह की सुस्ती का समय होगा। यदि परिणाम अभी भी total_xact_time विभाजित है, तो इसे सामान्यीकृत किया जाएगा: 1 का मान उस स्थिति से मेल खाता है जहां ग्राहक 100% समय idle in transaction हैं। और इस तरह के सामान्यीकरण के साथ, यह समझना आसान हो जाता है कि सब कुछ कितना बुरा है:

इसके अलावा, अवधि में वापस लौटना, मीट्रिक total_xact_time - total_query_time को लेनदेन की संख्या से विभाजित करके total_xact_time - total_query_time जा सकता है कि प्रति लेनदेन औसत निष्क्रिय आवेदन कितना है।

मेरी राय में, USE / RED विधियाँ संरचित करने के लिए सबसे उपयोगी हैं कि आप किस मैट्रिक्स को शूट करते हैं और क्यों। चूंकि हम पूर्णकालिक निगरानी में लगे हुए हैं और हमें विभिन्न बुनियादी ढांचे के घटकों की निगरानी करनी है, इसलिए ये तरीके हमें सही मैट्रिक्स लेने, हमारे ग्राहकों के लिए सही कार्यक्रम और ट्रिगर बनाने में मदद करते हैं।

अच्छी निगरानी अभी नहीं की जा सकती है, यह एक पुनरावृत्ति प्रक्रिया है। Okmeter.io में हमारे पास बस निरंतर निगरानी है (बहुत सारी चीजें हैं, लेकिन कल यह बेहतर और अधिक विस्तृत होगी :)