🚵🏻 👨🏾‍🎤 🔚 postgres_exporter और कई डेटाबेस के साथ PostgreSQL उदाहरण की निगरानी 🔋 🖕🏿 💾

UPD: नोट ने 0.8.0 के रिलीज के साथ इसकी प्रासंगिकता खो दी है। सभी नवाचार लेख में पाए जा सकते हैं: PostgreSQL की निगरानी के लिए postgres_exporter की नई सुविधाएँ

शुभ दोपहर, हेब्र पाठकों!

प्रोमेथियस और निर्यातकों (एजेंटों) का इसका पारिस्थितिकी तंत्र किसी भी प्रशासक और डेवलपर के लिए एक अच्छा उपकरण है। वितरण में आसानी, सादगी (सापेक्ष) सेटिंग्स, स्वचालित पहचान सेवा का उपयोग करने की क्षमता।
लेकिन यह प्रोमेथियस के बारे में इतना नहीं है, लेकिन उल्लेखनीय एजेंटों में से एक के बारे में है, जिसका नाम है पोस्टग्रैस_एक्सपोर्ट। यह आपको PostgreSQL के साथ मैट्रिक्स एकत्र करने की अनुमति देता है। लेकिन अगर सब कुछ इतना आसान था ...

दुर्भाग्य से, postgres_exporter प्रलेखन काफी तपस्वी है और केवल सामान्य मामलों को प्रभावित करता है। लेकिन क्या होगा यदि आपको कई डेटाबेस के साथ DBMS क्लस्टर का उदाहरण मिला है और / या आप एक बार क्लस्टर के कई उदाहरणों के लिए मीट्रिक एकत्र करना चाहते हैं।

लक्ष्य

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

मैं विशिष्ट समस्याओं को हल करने के लिए postgres_exporter का उपयोग करने के कुछ विशेष मामलों को छूना चाहता हूं, अर्थात् जिनके साथ एक एजेंट द्वारा मैट्रिक्स एकत्रित करना है:

एक उदाहरण में कई डेटाबेस;
कई प्रतियां;
विभिन्न उदाहरणों पर कई डेटाबेस।

postgres_exporter

विशेष रूप से, पेशेवरों और विपक्ष।

पेशेवरों से:

पहला और महत्वपूर्ण लाभ एजेंट की डिलीवरी और कॉन्फ़िगरेशन में आसानी है। एजेंट - एक निष्पादन योग्य फ़ाइल है (वैकल्पिक रूप से, उपयोगकर्ता मेट्रिक्स के सेट के साथ एक यमल फ़ाइल)। यह आवश्यक वितरण और वास्तुकला के लिए संकलित एक स्व-निहित अनुप्रयोग है, और सर्वर पर अतिरिक्त पैकेजों की स्थापना की आवश्यकता नहीं है। एजेंट को क्लस्टर उदाहरण के रूप में एक ही नोड पर और एक अलग नोड पर दोनों स्थापित किया जा सकता है;
एजेंट डीबीएमएस को एक नियमित एसक्यूएल क्लाइंट के रूप में जोड़ता है। यह inet के माध्यम से या एक यूनिक्स सॉकेट के माध्यम से कनेक्ट करना संभव है;
एक एजेंट द्वारा मैट्रिक्स प्राप्त करने की क्षमता, उदाहरणों के कई उदाहरणों और / या एक उदाहरण के कई डेटाबेस से;
प्रोमेथियस या किसी अन्य कलेक्टर द्वारा अनुरोध के अनुसार मेट्रिक्स को अक्सर एकत्र किया जाता है;
एक साधारण HTTP अनुरोध के साथ मैट्रिक्स प्राप्त करने की क्षमता;
स्वचालित रसीद, एक एजेंट द्वारा, एकल पोस्टग्रेएसक्यूएल उदाहरणों पर डेटाबेस की एक सूची के साथ, पोस्टग्रेज_एक्सपोर्ट 0.5.0+ संस्करण के साथ, -ऑटो-खोज-डेटाबेस विकल्प दिखाई दिया है।

Minuses की:

प्राधिकरण की कमी;
केवल HTTP के माध्यम से डेटा ट्रांसफर। सभी मीट्रिक स्पष्ट पाठ में प्रेषित की जाएंगी। और यह बुरा है, एक हमलावर के बाद से, जब अवरोधन, डेटाबेस और भूमिकाओं की एक विश्वसनीय सूची प्राप्त कर सकता है;
मैट्रिक्स को कैश नहीं करता है। इस प्रकार, उदाहरण के लिए, जब एजेंट नेटवर्क के लिए अनुपलब्ध है, तो अनुपलब्ध अवधि के लिए डेटा प्रोमेथियस द्वारा प्राप्त नहीं किया जाएगा;
--ऑटो-डिस्कवर-डेटाबेस विकल्प का उपयोग करते समय, सूची से कुछ डेटाबेस को बाहर करना संभव नहीं है। यह बल्कि अस्थायी है, क्योंकि अगली रिलीज़ में ऐसी संभावना पहले से ही दिखाई देनी चाहिए (विकल्प --exclude-database)।

एक उदाहरण में कई डेटाबेस

ठीक है, चलो अभ्यास करने के लिए आगे बढ़ते हैं। मान लीजिए कि हमारे पास कई डेटाबेस के साथ PostgreSQL का एक उदाहरण है और हमें उदाहरण मैट्रिक्स और सभी डेटाबेस के संग्रह को व्यवस्थित करने की आवश्यकता है।
मैंने डेटाबेस मेट्रिक्स के संग्रह और क्लस्टर उदाहरण को अलग क्यों किया, सब कुछ बहुत सरल है, एक ही क्लस्टर पर कई डेटाबेस के साथ काम करने वाले पोस्टग्रैज_एक्सपोर्ट का परिदृश्य विभिन्न डेटाबेस में समान प्रश्नों के वर्ग सेट के निष्पादन का तात्पर्य करता है। और परिणामस्वरूप, जब pg_stat_replication, pg_stat_activity, pg_stat_statement विचारों आदि से मैट्रिक्स प्राप्त करने की कोशिश की जा रही है। क्लस्टर के लिए सामान्य होने के नाते, हम हमेशा प्राप्त करते हैं, postgres_exporter की समझ में, मैट्रिक्स का एक ही सेट जो डुप्लिकेट कुंजियों और मूल्यों को जन्म देगा, जिससे त्रुटि होगी।
आइए देखें कि यह व्यवहार में कैसा दिखता है।

हमारे पास डेटाबेस के एक सेट के साथ एक परीक्षण उदाहरण है:

List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+------------+------------+----------------------- dbtest1 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | dbtest2 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | dbtest3 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | postgres | postgres | UTF8 | en_US.utf8 | en_US.utf8 |

हम postgres_exporter शुरू करते हैं, विकल्प के साथ --ऑटो-खोज-डेटाबेस (यदि कनेक्शन स्ट्रिंग में डेटाबेस का नाम निर्दिष्ट नहीं है, तो कनेक्शन उपयोगकर्ता नाम के साथ डेटाबेस में किया जाएगा):

 $ DATA_SOURCE_NAME="postgresql://postgres@127.0.0.1:5432/?sslmode=disable" ./postgres_exporter --auto-discover-databases --log.format=logger:stdout

DATA_SOURCE_NAME - PostgreSQL उदाहरण से कनेक्ट करने के लिए पर्यावरण चर वाला पैरामीटर

एजेंट के आउटपुट में, हम एक सुखद चित्र का अवलोकन करते हैं, यह लॉन्च किया गया है और क्लस्टर में सभी डेटाबेस से कनेक्ट करने में सक्षम है (हालांकि यह किन डेटाबेसों को नहीं लिखता है, लेकिन उम्मीद है कि यह तय हो जाएगा):

 INFO[0000] Established new database connection to "127.0.0.1:5432". source="postgres_exporter.go:788" INFO[0000] Established new database connection to "127.0.0.1:5432". source="postgres_exporter.go:788" INFO[0000] Semantic Version Changed on "127.0.0.1:5432": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Semantic Version Changed on "127.0.0.1:5432": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Established new database connection to "127.0.0.1:5432". source="postgres_exporter.go:788" INFO[0000] Semantic Version Changed on "127.0.0.1:5432": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Established new database connection to "127.0.0.1:5432". source="postgres_exporter.go:788" INFO[0000] Semantic Version Changed on "127.0.0.1:5432": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Established new database connection to "127.0.0.1:5432". source="postgres_exporter.go:788" INFO[0000] Semantic Version Changed on "127.0.0.1:5432": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Starting Server: :9187 source="postgres_exporter.go:1490"

मुझे लगता है कि एक चौकस पाठक यह नोटिस करेगा कि क्लस्टर में चार आधार हैं (पोस्टग्रेज, डीबीटीईएस 1, डीबीटी 2 और डीबीटी 3, टेम्पलेट 0 और टेम्पलेट 1 को नजरअंदाज किया जाता है), और पांच कनेक्शन हैं। हमारे मामले में, postgres_exporter डेटाबेस से दो कनेक्शन बनाता है। और इस सुविधा के साथ आपको बहुत सावधान रहने की आवश्यकता है। क्यों? हम इस बारे में थोड़ा और पता लगाएंगे।

ठीक है, चलो जारी रखें और मैट्रिक्स प्राप्त करने का प्रयास करें:

 $ curl http://localhost:9178/metrics

नतीजतन, आउटपुट में हमें डुप्लिकेट के बारे में चेतावनी मिलती है "एक ही नाम और लेबल मानों के साथ पहले एकत्र किया गया था" (लेकिन पोस्टग्रेज_एक्सपोर्ट लॉग में हम चेतावनी नहीं देखेंगे):

 ... * collected metric pg_stat_activity_max_tx_duration label:<name:"datname" value:"dbtest1" > label:<name:"server" value:"127.0.0.1:5432" > label:<name:"state" value:"fastpath function call" > gauge:<value:0 > was collected before with the same name and label values * collected metric pg_stat_bgwriter_checkpoints_timed label:<name:"server" value:"127.0.0.1:5432" > counter:<value:1 > was collected before with the same name and label values ...

त्रुटियों से छुटकारा पाने का एकमात्र तरीका डिफ़ॉल्ट रूप से मैट्रिक्स के संग्रह को अक्षम करना है। ऐसा करने के दो तरीके हैं: पहले वातावरण चर सेट करें PG_EXPORTER_DISABLE_DEFAULT_METRICS और PG_EXPORTER_DISABLE_SETTINGS_METRICS विकल्पों को सही या उपयोग करने के लिए --disable-default-metrics और --disable-settings-met मीट्रिक

अतिरिक्त विकल्पों के साथ postgres_exporter को पुनरारंभ करें:

 $ DATA_SOURCE_NAME="postgresql://postgres@127.0.0.1:5432/?sslmode=disable" ./postgres_exporter --auto-discover-databases --log.format=logger:stdout --disable-default-metrics --disable-settings-metrics

मेट्रिक्स प्राप्त करने की कोशिश:

 $ curl http://localhost:9178/metrics

और इसलिए, सब कुछ योजना के अनुसार हुआ, लेकिन आउटपुट में PostgreSQL से जुड़ा एक भी मीट्रिक नहीं है:

 # HELP go_gc_duration_seconds A summary of the GC invocation durations. # TYPE go_gc_duration_seconds summary go_gc_duration_seconds{quantile="0"} 0 go_gc_duration_seconds{quantile="0.25"} 0 go_gc_duration_seconds{quantile="0.5"} 0 go_gc_duration_seconds{quantile="0.75"} 0 go_gc_duration_seconds{quantile="1"} 0 go_gc_duration_seconds_sum 0 go_gc_duration_seconds_count 0 ... # HELP process_virtual_memory_bytes Virtual memory size in bytes. # TYPE process_virtual_memory_bytes gauge process_virtual_memory_bytes 1.3832192e+07

इसके अलावा, पेलोड प्राप्त करने के लिए, हमें एक फाइल बनाने की ज़रूरत है जो यह बताती है कि हम कौन से मेट्रिक्स प्राप्त करना चाहते हैं (मत भूलो, हम केवल डेटाबेस-विशिष्ट मैट्रिक्स एकत्र कर सकते हैं)।

परीक्षण के लिए, हम pg_statio_user_tables संबंध से मैट्रिक्स एकत्र करेंगे। ऐसा करने के लिए, निम्न सामग्री के साथ एक क्वेरी .yaml फ़ाइल बनाएँ:

 pg_statio_user_tables: query: "SELECT current_database() as datname, schemaname, relname, heap_blks_read, heap_blks_hit FROM pg_statio_user_tables" metrics: - datname: usage: "LABEL" description: "Name of database" - schemaname: usage: "LABEL" description: "Name of the schema that this table is in" - relname: usage: "LABEL" description: "Name of this table" - heap_blks_read: usage: "COUNTER" description: "Number of disk blocks read from this table" - heap_blks_hit: usage: "COUNTER" description: "Number of buffer hits in this table"

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

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

और इसलिए, हम अपने एजेंट को विकल्प के साथ लॉन्च करते हैं --extend.query-path (यहां मेट्रिम के विवरण के साथ याम फाइल के लिए रास्ता इंगित किया गया है):

 DATA_SOURCE_NAME="postgresql://postgres@127.0.0.1:5432?sslmode=disable" ./postgres_exporter --log.format=logger:stdout --auto-discover-databases --disable-default-metrics --disable-settings-metrics --extend.query-path=./queries.yaml

हम मीट्रिक प्राप्त करने की कोशिश कर रहे हैं (स्पष्टता के लिए, हम केवल pg_statio_user_tables_heap_blks_hit लेते हैं):

 curl -s http://localhost:9187/metrics | grep pg_statio_user_tables_heap_blks_hit

परिणामस्वरूप, हमें मेट्रिक्स की विशिष्ट व्याख्या प्राप्त होती है:

 # HELP pg_statio_user_tables_heap_blks_hit Number of buffer hits in this table # TYPE pg_statio_user_tables_heap_blks_hit counter pg_statio_user_tables_heap_blks_hit{datname="dbtest1",relname="t1",schemaname="public",server="127.0.0.1:5432"} 0 pg_statio_user_tables_heap_blks_hit{datname="dbtest1",relname="t2",schemaname="public",server="127.0.0.1:5432"} 0 pg_statio_user_tables_heap_blks_hit{datname="dbtest2",relname="t1",schemaname="public",server="127.0.0.1:5432"} 0 pg_statio_user_tables_heap_blks_hit{datname="dbtest2",relname="t2",schemaname="public",server="127.0.0.1:5432"} 0 pg_statio_user_tables_heap_blks_hit{datname="dbtest3",relname="t1",schemaname="public",server="127.0.0.1:5432"} 0 pg_statio_user_tables_heap_blks_hit{datname="dbtest3",relname="t2",schemaname="public",server="127.0.0.1:5432"} 0

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

'अतिरिक्त' कनेक्शन की पहेली का जवाब

याद रखें, शुरुआत में, हमने "अतिरिक्त" कनेक्शन पर ध्यान आकर्षित किया था। इसलिए, यह विकल्प के साथ postgres_exporter की एक विशेषता है -ऑटो-खोज-डेटाबेस।
लेकिन यह बहुत परेशानी क्यों पैदा कर सकता है? वास्तव में, सब कुछ सरल है और पहले से ही ऊपर वर्णित है, अर्थात्, समस्या यह है कि postgres_exporter पोस्टग्रेज डेटाबेस से दो बार मैट्रिक्स एकत्र करेगा और मैट्रिक्स की नकल करना शुरू कर देगा। हमारे मामले में, केवल --exclude-डेटाबेस विकल्प की उपस्थिति मदद कर सकती है (इसलिए हम अगली रिलीज़ की प्रतीक्षा कर रहे हैं)।
और हां, यदि आपके पास पोस्टग्रेज डेटाबेस में उपयोगकर्ता तालिकाएं हैं, तो ऊपर दिया गया उदाहरण काम नहीं करेगा।

कई उदाहरण हैं

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

 $ DATA_SOURCE_NAME="postgresql://postgres@127.0.0.1:5432/postgres?sslmode=disable,postgresql://postgres@127.0.0.1:5434/postgres?sslmode=disable" ./postgres_exporter --log.format=logger:stdout

यहां हम स्थानीय नोड पर, हमारे मामले में चल रहे दो अलग-अलग क्लस्टर उदाहरणों से जुड़ते हैं। यह लॉग में कैसा दिखता है:

 INFO[0000] Established new database connection to "127.0.0.1:5432". source="postgres_exporter.go:788" INFO[0000] Semantic Version Changed on "127.0.0.1:5432": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Established new database connection to "127.0.0.1:5434". source="postgres_exporter.go:788" INFO[0000] Semantic Version Changed on "127.0.0.1:5434": 0.0.0 -> 11.5.0 source="postgres_exporter.go:1251" INFO[0000] Starting Server: :9187 source="postgres_exporter.go:1490"

अगला, हम मैट्रिक्स प्राप्त करने की कोशिश करते हैं (स्पष्टता के लिए, हम खुद को pg_stat_database_blk_read_time मीट्रिक तक सीमित करते हैं):

 curl -s http://localhost:9187/metrics | grep pg_stat_database_blk_read_time

परिणामस्वरूप, एक एजेंट से, हम दोनों उदाहरणों के लिए मैट्रिक्स प्राप्त करते हैं:

 # HELP pg_stat_database_blk_read_time Time spent reading data file blocks by backends in this database, in milliseconds # TYPE pg_stat_database_blk_read_time counter pg_stat_database_blk_read_time{datid="1",datname="template1",server="127.0.0.1:5432"} 0 pg_stat_database_blk_read_time{datid="1",datname="template1",server="127.0.0.1:5434"} 0 pg_stat_database_blk_read_time{datid="13116",datname="template0",server="127.0.0.1:5432"} 0 pg_stat_database_blk_read_time{datid="13116",datname="template0",server="127.0.0.1:5434"} 0 pg_stat_database_blk_read_time{datid="13117",datname="postgres",server="127.0.0.1:5432"} 0 pg_stat_database_blk_read_time{datid="13117",datname="postgres",server="127.0.0.1:5434"} 0 pg_stat_database_blk_read_time{datid="16384",datname="dbtest1",server="127.0.0.1:5432"} 0 pg_stat_database_blk_read_time{datid="16385",datname="dbtest2",server="127.0.0.1:5432"} 0 pg_stat_database_blk_read_time{datid="16386",datname="dbtest3",server="127.0.0.1:5432"} 0

इस मामले में, एक उदाहरण पर कई डेटाबेस के मामले में सब कुछ कुछ सरल था। उसी समय, हमारे पास अभी भी सभी उदाहरणों से वैश्विक मीट्रिक प्राप्त करने का अवसर है।

सारांश

और इसलिए, प्रयोजनों के लिए इंगित किया गया तीसरा मामला ऊपर वर्णित दो का संयोजन है, इसलिए मुझे इसे लाने का कोई कारण नहीं दिखता है।

नतीजतन, हमारे पास नीचे की पंक्ति में क्या है, postgres_exporter, मेरी राय में, PostgreSQL क्लस्टर और उन पर तैनात डेटाबेस के इंस्टेंस की निगरानी के लिए एक दिलचस्प और आशाजनक प्रशासक उपकरण है। लेकिन इसकी उम्र के कारण, यह उन कमियों के बिना नहीं है जिन्हें समझा और माफ किया जा सकता है।

सूत्रों का कहना है

प्रोमेथियस [ 1 ] एक खुला स्रोत अनुप्रयोग है जिसका उपयोग घटनाओं की निगरानी और सतर्क करने के लिए किया जाता है। यह लचीले प्रश्नों और वास्तविक समय अलर्ट के साथ HTTP अनुरोध मॉडल का उपयोग करके निर्मित एक समय श्रृंखला डेटाबेस के लिए वास्तविक समय के मैट्रिक्स लिखता है।
Postgres_exporter Prometheus के लिए PostgreSQL मैट्रिक्स का निर्यातक है।

संस्करण, लेखन के समय, वी 0.5.1। PostgreSQL 9.4+ के समर्थित संस्करण (स्रोत कोड में उल्लेखित 9.1+ प्रतिबंध)।