PostgreSQL लॉग से सर्वश्रेष्ठ कैसे प्राप्त करें

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

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

इस लेख में, मैं PostgreSQL लॉग से सर्वोत्तम प्राप्त करने के लिए कुछ मूलभूत प्रथाओं को शामिल करूंगा। यह ब्लॉग एक कठिन और तेज़ नियम पुस्तिका नहीं है; टिप्पणी अनुभाग में अपने विचार साझा करने के लिए पाठकों का स्वागत है। हालांकि इसका सर्वोत्तम मूल्य प्राप्त करने के लिए, मैं पाठक से यह सोचने के लिए कहता हूं कि वे अपने PostgreSQL डेटाबेस सर्वर लॉग का उपयोग कैसे करना चाहते हैं:

• कानूनी अनुपालन कारण जहां विशिष्ट जानकारी प्राप्त करने की आवश्यकता है
• सुरक्षा ऑडिटिंग जहां विशिष्ट घटना विवरण उपस्थित होने की आवश्यकता है
• प्रदर्शन समस्या निवारण जहां क्वेरी और उनके पैरामीटर रिकॉर्ड किए जाने हैं
• दिन-प्रति-दिन परिचालन सहायता जहां मीट्रिक की एक निर्धारित संख्या की निगरानी की जानी है

इसके साथ ही, चलिए शुरू करते हैं।

postgresql.conf में मैन्युअल बदलाव न करें

Postgresql.conf फ़ाइल में कोई भी परिवर्तन कठपुतली, Ansible, या शेफ जैसी कॉन्फ़िगरेशन प्रबंधन प्रणाली का उपयोग करके किया जाना चाहिए। यह सुनिश्चित करता है कि परिवर्तनों का पता लगाया जा सकता है और यदि आवश्यक हो तो उन्हें पिछले संस्करण में सुरक्षित रूप से वापस लाया जा सकता है। यह तब सच होता है जब आप लॉगिंग पैरामीटर में परिवर्तन कर रहे होते हैं।

DBA अक्सर postgresql.conf फ़ाइल की कई प्रतियाँ बनाते हैं, प्रत्येक थोड़े अलग मापदंडों के साथ, प्रत्येक एक अलग उद्देश्य के लिए। विभिन्न कॉन्फ़िगरेशन फ़ाइलों को मैन्युअल रूप से प्रबंधित करना एक बोझिल कार्य है यदि त्रुटियों की संभावना नहीं है। दूसरी ओर, एक कॉन्फ़िगरेशन प्रबंधन प्रणाली का नाम बदलने और इसे पारित पैरामीटर के आधार पर postgresql.conf फ़ाइल के विभिन्न संस्करणों का उपयोग करने के लिए बनाया जा सकता है। यह पैरामीटर वर्तमान संस्करण के उद्देश्य को निर्धारित करेगा। जब आवश्यकता पूरी हो जाती है, तो उसी इनपुट पैरामीटर को बदलकर पुरानी कॉन्फ़िग फ़ाइल को वापस रखा जा सकता है।

उदाहरण के लिए, यदि आप अपने PostgreSQL उदाहरण पर चल रहे सभी कथनों को लॉग करना चाहते हैं, तो पैरामीटर मान "log_statement=all" के साथ एक कॉन्फ़िगरेशन फ़ाइल का उपयोग किया जा सकता है। जब सभी कथनों को रिकॉर्ड करने की कोई आवश्यकता नहीं है - शायद एक समस्या निवारण अभ्यास के बाद - पिछली कॉन्फ़िगरेशन फ़ाइल को बहाल किया जा सकता है।

PostgreSQL के लिए अलग लॉग फ़ाइलों का उपयोग करें

मैं सामान्य संचालन के दौरान PostgreSQL के मूल लॉगिंग कलेक्टर को सक्षम करने की सलाह देता हूं। PostgreSQL नेटिव लॉगिंग को सक्षम करने के लिए, निम्न पैरामीटर को चालू पर सेट करें:

logging_collector = on

इसके दो कारण हैं:

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

दूसरा - और जैसा कि हम बाद में देखेंगे - लॉग को लॉग मैनेजमेंट यूटिलिटी के साथ एकत्र, पार्स, अनुक्रमित और विश्लेषण किया जाना चाहिए। PostgreSQL के syslog में इसकी घटनाओं को रिकॉर्ड करने का अर्थ होगा सभी "शोर संदेशों" को फ़िल्टर करने के लिए लॉग प्रबंधन भाग में फ़िल्टरिंग और पैटर्न-मिलान की एक अतिरिक्त परत बनाना। अधिकांश टूल द्वारा समर्पित लॉग फ़ाइलों को आसानी से पार्स किया जा सकता है और ईवेंट के लिए अनुक्रमित किया जा सकता है।

लॉग गंतव्य को stderr पर सेट करें

आइए "log_destination" पैरामीटर पर विचार करें। इसके चार मान हो सकते हैं:

log_destination = stderr | syslog | csv | eventlog

जब तक विंडोज में कॉमा से अलग किए गए फॉर्मेट या इवेंट लॉग में लॉग इवेंट को सेव करने का कोई अच्छा कारण न हो, मैं इस पैरामीटर को stderr पर सेट करने की सलाह देता हूं। ऐसा इसलिए है क्योंकि CSV फ़ाइल गंतव्य के साथ, एक कस्टम "log_line_prefix" पैरामीटर मान का कोई प्रभाव नहीं पड़ेगा, और फिर भी, मूल्यवान जानकारी को शामिल करने के लिए उपसर्ग बनाया जा सकता है।

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

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

सार्थक लॉग फ़ाइल नामों का उपयोग करें

जब PostgreSQL लॉग फ़ाइलें स्थानीय रूप से सहेजी जाती हैं, तो नामकरण शैली का अनुसरण करना आवश्यक नहीं लग सकता है। गैर-सीएसवी प्रारूपित लॉग के लिए डिफ़ॉल्ट फ़ाइल नाम शैली "postgresql-%Y-%m-%d_%H%M%S.log" है, जो अधिकांश मामलों के लिए पर्याप्त है।

नामकरण तब महत्वपूर्ण हो जाता है जब आप एक समर्पित लॉग सर्वर, एक माउंटेड NFS वॉल्यूम, या एक S3 बकेट जैसे कई सर्वरों से लॉग फ़ाइलों को केंद्रीय स्थान पर सहेज रहे होते हैं। मैं ऐसे मामले में दो मापदंडों का उपयोग करने की सलाह देता हूं:

log_directory
log_filename

एक ही स्थान पर एकाधिक इंस्टेंस से लॉग फ़ाइलों को संग्रहीत करने के लिए, पहले प्रत्येक इंस्टेंस के लिए एक अलग निर्देशिका पदानुक्रम बनाएँ। यह कुछ इस तरह हो सकता है:

/<Application_Name>/<Environment_Name>/<Instance_Name>

प्रत्येक PostgreSQL उदाहरण के "log_directory" को उसके निर्दिष्ट फ़ोल्डर में इंगित किया जा सकता है।

प्रत्येक उदाहरण तब समान "log_filename" पैरामीटर मान का उपयोग कर सकता है। डिफ़ॉल्ट मान

postgresql_2020-08-25_2359.log

अधिक सार्थक नाम का उपयोग करने के लिए, "log_filename" को कुछ इस तरह सेट करें:

log_filename = "postgresql_%A-%d-%B_%H%M"

तब लॉग फ़ाइलों का नाम इस प्रकार रखा जाएगा:

postgresql_Saturday-23-August_2230

सार्थक लॉग लाइन उपसर्ग का उपयोग करें

PostgreSQL लॉग लाइन उपसर्गों में वास्तविक संदेश के अलावा सबसे मूल्यवान जानकारी हो सकती है। पोस्टग्रेज़ दस्तावेज़ लॉग इवेंट प्रीफ़िक्स कॉन्फ़िगरेशन के लिए कई एस्केप वर्ण दिखाता है। इन एस्केप अनुक्रमों को रन टाइम पर विभिन्न स्थिति मानों के साथ प्रतिस्थापित किया जाता है। कुछ एप्लिकेशन जैसे pgBadger एक विशिष्ट लॉग लाइन उपसर्ग की अपेक्षा करते हैं।

मेरा सुझाव है कि उपसर्ग में निम्नलिखित जानकारी शामिल करें:

• इवेंट का समय (मिलीसेकंड के बिना):%t
• दूरस्थ ग्राहक का नाम या आईपी पता:%h
• उपयोगकर्ता नाम:%u
• डेटाबेस एक्सेस किया गया:%d
• आवेदन का नाम:%a
• प्रक्रिया आईडी:%p
• गैर-सत्र प्रक्रिया आउटपुट को समाप्त करना:%q
• 1 से शुरू होने वाले प्रत्येक सत्र या प्रक्रिया के लिए लॉग लाइन नंबर:%l

यह समझने के लिए कि उपसर्ग में प्रत्येक फ़ील्ड किस बारे में है, हम फ़ील्ड से पहले एक छोटा शाब्दिक स्ट्रिंग जोड़ सकते हैं। इसलिए, प्रक्रिया आईडी मान को शाब्दिक "पीआईडी ​​=" से पहले किया जा सकता है, डेटाबेस नाम को "डीबी =" आदि के साथ उपसर्ग किया जा सकता है। यहां एक उदाहरण दिया गया है:

log_line_prefix = 'time=%t, pid=%p %q db=%d, usr=%u, client=%h , app=%a, line=%l '

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

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

साथ ही, “log_hostname” पैरामीटर को 1 पर सेट करें:

log_hostname = 1

इसके बिना, केवल क्लाइंट आईपी पता दिखाया जाएगा। उत्पादन प्रणालियों में, यह आमतौर पर प्रॉक्सी, लोड बैलेंसर या कनेक्शन पूलर का पता होगा। जब तक आप इन प्रणालियों के आईपी पते को दिल से नहीं जानते, तब तक उनके होस्टनामों को लॉग करना सार्थक हो सकता है। हालाँकि, DNS लुकअप लॉगिंग डेमॉन को फ़ाइल में लिखने के लिए अतिरिक्त समय भी जोड़ देगा।

एक अन्य पैरामीटर जिसे "log_line_prefix" के साथ सेट किया जाना चाहिए, वह है "log_timezone"। इसे सर्वर के स्थानीय समयक्षेत्र में सेट करने से यह सुनिश्चित होगा कि लॉग किए गए ईवेंट पहले स्थानीय समय में बदलने के बजाय उनके टाइमस्टैम्प से अनुसरण करना आसान है। नीचे दिए गए कोड स्निपेट में, हम log_timzeone को ऑस्ट्रेलियाई पूर्वी मानक समय क्षेत्र पर सेट कर रहे हैं:

log_timezone = 'Australia/Sydney'

केवल कनेक्शन लॉग करें

दो पैरामीटर नियंत्रित करते हैं कि PostgreSQL क्लाइंट कनेक्शन और डिस्कनेक्शन को कैसे रिकॉर्ड करता है। दोनों पैरामीटर डिफ़ॉल्ट रूप से बंद हैं। आपके संगठन की सुरक्षा आवश्यकताओं के आधार पर, आप इनमें से एक को 1 और दूसरे को 0 पर सेट करना चाह सकते हैं (जब तक कि आप pgBadger जैसे टूल का उपयोग नहीं कर रहे हैं - उस पर बाद में और अधिक)।

log_connections = 1
log_disconnections = 0

log_connections को 1 पर सेट करने से सभी अधिकृत कनेक्शन और साथ ही प्रयास किए गए . रिकॉर्ड हो जाएंगे सम्बन्ध। यह सुरक्षा ऑडिटिंग के लिए स्पष्ट रूप से अच्छा है:एक क्रूर बल के हमले को लॉग से आसानी से पहचाना जा सकता है। हालाँकि, इस सेटिंग के सक्षम होने के साथ, हजारों या सैकड़ों अल्पकालिक वैध कनेक्शन वाले व्यस्त PostgreSQL वातावरण में लॉग फ़ाइल जलमग्न हो सकती है।

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

केवल DDL और DML संचालन लॉग करें

पोस्टग्रेज लॉग में क्या दर्ज किया जाना चाहिए, इसके बारे में बहुत बहस है - यानी, "log_statement" पैरामीटर का मान क्या होना चाहिए। इसके तीन मान हो सकते हैं:

log_statement = 'off' | 'ddl' | 'mod' | 'all'

सर्वर पर चल रहे प्रत्येक SQL कथन को कैप्चर करने के लिए इसे "सभी" पर सेट करना आकर्षक हो सकता है, लेकिन वास्तविकता में यह हमेशा एक अच्छा विचार नहीं हो सकता है।

व्यस्त उत्पादन प्रणालियाँ ज्यादातर SELECT स्टेटमेंट चलाती हैं, कभी-कभी प्रति घंटे हजारों। हो सकता है कि इंस्टेंस पूरी तरह से ठीक चल रहा हो, बिना किसी प्रदर्शन समस्या के। ऐसे मामलों में इस पैरामीटर को "सभी" पर सेट करने से लॉगिंग डेमॉन पर अनावश्यक रूप से बोझ पड़ेगा क्योंकि उसे उन सभी कथनों को फ़ाइल में लिखना होगा।

हालाँकि, आप जो कैप्चर करना चाहते हैं, वह कोई डेटा भ्रष्टाचार है, या डेटाबेस संरचना में परिवर्तन है जो किसी प्रकार की समस्या का कारण बनता है। अवांछित या अनधिकृत डेटाबेस परिवर्तन डेटा के चयन की तुलना में अधिक एप्लिकेशन समस्याओं का कारण बनते हैं; इसलिए मैं इस पैरामीटर को "मॉड" पर सेट करने की सलाह देता हूं। इस सेटिंग के साथ, PostgreSQL लॉग फ़ाइल में सभी DDL और DML परिवर्तनों को रिकॉर्ड करेगा।

यदि आपका PostgreSQL उदाहरण मध्यम रूप से व्यस्त है (प्रति घंटे दर्जनों प्रश्न), तो इस पैरामीटर को "सभी" पर सेट करने के लिए स्वतंत्र महसूस करें। जब आप धीमी गति से चलने वाली SELECT क्वेरी का समस्या निवारण कर रहे हों या अनधिकृत डेटा एक्सेस की तलाश कर रहे हों, तो आप इसे अस्थायी रूप से "सभी" पर भी सेट कर सकते हैं। कुछ एप्लिकेशन जैसे pgBadger भी आपसे इसे "सभी" पर सेट करने की अपेक्षा करते हैं।

“चेतावनी” संदेश लॉग करें और ऊपर करें

अगर "log_statement" पैरामीटर तय करता है कि किस प्रकार के बयान दर्ज किए जाएंगे, तो निम्नलिखित दो पैरामीटर तय करते हैं कि संदेश कितना विस्तृत होगा:

log_min_messages
log_min_error_statement

प्रत्येक PostgreSQL ईवेंट में एक संबद्ध संदेश स्तर होता है। संदेश का स्तर वर्बोज़ DEBUG से लेकर संक्षिप्त PANIC तक कुछ भी हो सकता है। स्तर जितना कम होगा, संदेश उतना ही अधिक क्रियात्मक होगा। "Log_min_messages" पैरामीटर के लिए डिफ़ॉल्ट मान "चेतावनी" है। जब तक आप सूचनात्मक संदेशों को भी लॉग नहीं करना चाहते, मैं इसे इस स्तर तक रखने की सलाह देता हूं।

"log_min_error_statement" पैरामीटर नियंत्रित करता है कि कौन से SQL स्टेटमेंट थ्रोइंग एरर लॉग किए जाएंगे। "Log_min_message" की तरह, "log_min_error_statement" में निर्दिष्ट मान के बराबर या उससे अधिक त्रुटि गंभीरता स्तर वाले किसी भी SQL कथन को रिकॉर्ड किया जाएगा। डिफ़ॉल्ट मान "ERROR" है, और मैं डिफ़ॉल्ट रखने की सलाह देता हूं।

लॉग अवधि पैरामीटर को डिफ़ॉल्ट पर रखें

फिर हमारे पास निम्नलिखित दो पैरामीटर हैं:

log_duration
log_min_duration_statement

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

अंत में, हमारे पास "log_min_duration_statement" पैरामीटर है। जब यह पैरामीटर सेट किया जाता है (बिना किसी इकाई के, इसे मिलीसेकंड के रूप में लिया जाता है), तो पैरामीटर मान के बराबर या उससे अधिक समय लेने वाले किसी भी स्टेटमेंट की अवधि लॉग की जाएगी। इस पैरामीटर मान को 0 पर सेट करने से सभी पूर्ण किए गए कथनों की अवधि रिकॉर्ड हो जाएगी। इसे -1 पर सेट करने से स्टेटमेंट अवधि लॉगिंग अक्षम हो जाएगी। यह डिफ़ॉल्ट मान है, और मैं इसे ऐसा ही रखने की सलाह देता हूं।

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

जो भी हो, एक बार जब आपके पास प्रत्येक बार-बार चलने वाली क्वेरी के लिए आधार रेखा हो, तो आप "log_min_duration_statement" पैरामीटर को उच्चतम आधारभूत मानों पर सेट कर सकते हैं। अब, उच्चतम बेसलाइन मान से अधिक लंबी चलने वाली कोई भी क्वेरी फ़ाइन-ट्यूनिंग के लिए एक उम्मीदवार होगी।

त्रुटि संदेश वर्बोसिटी को डिफ़ॉल्ट पर रखें

“log_error_verbosity” पैरामीटर के तीन संभावित मान हो सकते हैं:

log_error_verbosity = terse | standard | verbose

यह पैरामीटर लॉग फ़ाइल में दर्ज प्रत्येक घटना के लिए PostgreSQL द्वारा रिकॉर्ड की जाने वाली जानकारी की मात्रा को नियंत्रित करता है। जब तक किसी डेटाबेस एप्लिकेशन को डिबग नहीं किया जाता है, तब तक यह पैरामीटर "डिफ़ॉल्ट" रखने के लिए सबसे अच्छा है। वर्बोज़ मोड तब उपयोगी होगा जब आपको फ़ाइल या फ़ंक्शन नाम और उस लाइन नंबर को कैप्चर करने की आवश्यकता होगी जो त्रुटि उत्पन्न करता है। इसे "टर्स" पर सेट करने से क्वेरी लॉगिंग बंद हो जाएगी, जो उपयोगी भी नहीं हो सकती है।

एक लॉग रोटेशन नीति खोजें जो आपके . के लिए काम करे केस का उपयोग करें

मैं लॉग फ़ाइल के आकार या आयु के आधार पर लॉग रोटेशन नीति बनाने की अनुशंसा करता हूं, लेकिन दोनों नहीं। दो PostgreSQL कॉन्फ़िगरेशन पैरामीटर निर्धारित करते हैं कि पुराने लॉग कैसे संग्रहीत किए जाते हैं और नए लॉग कैसे बनाए जाते हैं:

log_rotation_age = <number of minutes>
log_rotation_size = <number of kilobytes>

“log_rotration_age” के लिए डिफ़ॉल्ट मान 24 घंटे है, और “log_rotation_size” के लिए डिफ़ॉल्ट मान 10 मेगाबाइट है।

ज्यादातर मामलों में, आकार रोटेशन नीति होने की गारंटी नहीं है कि संग्रहीत लॉग फ़ाइल में अंतिम लॉग संदेश पूरी तरह से केवल उस फ़ाइल में निहित है।

यदि "log_rotation_age" को 24 घंटे के डिफ़ॉल्ट मान पर रखा जाता है, तो प्रत्येक फ़ाइल को आसानी से पहचाना जा सकता है और व्यक्तिगत रूप से जांच की जा सकती है, क्योंकि प्रत्येक फ़ाइल में एक दिन के ईवेंट होंगे। हालाँकि, यह भी गारंटी नहीं देता है कि प्रत्येक फ़ाइल पिछले 24 घंटों के लॉग की एक स्व-निहित इकाई होगी। कभी-कभी धीमी-प्रदर्शन वाली क्वेरी को समाप्त होने में 24 घंटे से अधिक समय लग सकता है; घटनाएं हो सकती हैं जब पुरानी फ़ाइल बंद हो जाती है, और नई उत्पन्न होती है। रात के बैच की नौकरी के दौरान ऐसा हो सकता है, जिसके परिणामस्वरूप क्वेरी के कुछ हिस्से एक फ़ाइल में और शेष दूसरी फ़ाइल में रिकॉर्ड हो जाते हैं।

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

pgBadger जैसे टूल का उपयोग करें

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

• अक्सर प्रतीक्षारत प्रश्न।
• अधिकांश अस्थायी फ़ाइलें या सबसे बड़ी अस्थायी फ़ाइलें उत्पन्न करने वाली क्वेरी
• सबसे धीमी गति से चलने वाली क्वेरी
• क्वेरी की औसत अवधि
• अक्सर चलने वाली क्वेरी
• प्रश्नों में सबसे अधिक बार-बार होने वाली त्रुटियां
• क्वेरी चलाने वाले उपयोगकर्ता और एप्लिकेशन
• चौकियों के आंकड़े।
• ऑटोवैक्यूम और आंकड़ों का स्वतः विश्लेषण करें।
• आंकड़े लॉक करना
• त्रुटि की घटनाएं (आतंक, घातक, त्रुटि और चेतावनी)।
• कनेक्शन और सत्र प्रोफाइल (डेटाबेस, उपयोगकर्ता, एप्लिकेशन द्वारा)
• सत्र प्रोफ़ाइल
• क्वेरी प्रोफाइल (क्वेरी प्रकार, डेटाबेस/एप्लिकेशन द्वारा क्वेरी)
• I/O आँकड़े
• आदि.

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

यदि आप कमांड प्रॉम्प्ट में चीजों को करने और सिस्टम दृश्यों का उपयोग करने में अधिक सहज हैं, तो आप pg_stat_statements का उपयोग करना चाहेंगे। वास्तव में, यह किसी भी उत्पादन PostgreSQL स्थापना में सक्षम होना चाहिए।

pg_stat_statements एक PostgreSQL एक्सटेंशन है और अब डिफ़ॉल्ट इंस्टॉलेशन के साथ है। इसे सक्षम करने के लिए, "shared_preload_libraries" कॉन्फ़िगरेशन पैरामीटर में इसके मूल्यों में से एक के रूप में pg_stat_statements होना चाहिए। फिर इसे "क्रिएट एक्सटेंशन" कमांड का उपयोग करके किसी भी अन्य एक्सटेंशन की तरह स्थापित किया जा सकता है। एक्सटेंशन pg_stat_statement दृश्य बनाता है जो मूल्यवान क्वेरी-संबंधी जानकारी प्रदान करता है।

जानकारी हासिल करने के लिए लॉग प्रबंधन एप्लिकेशन का उपयोग करें

बाजार में कई लॉग प्रबंधन सुविधाएं हैं, और अधिकांश संगठन इन दिनों एक या अधिक का उपयोग करते हैं। जो भी उपकरण मौजूद है, मैं अनुशंसा करता हूं कि इसका उपयोग PostgreSQL लॉग को एकत्र करने और प्रबंधित करने के लिए करें।

इसके कुछ कारण हैं:

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

लॉग प्रबंधन समाधान आज आम तौर पर PostgreSQL लॉग को पार्स करने की अंतर्निहित क्षमता के साथ आते हैं। कुछ में ऐसे डैशबोर्ड भी होते हैं जो इन लॉग से निकाले गए सबसे सामान्य मीट्रिक दिखा सकते हैं।

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

अंत में, पोस्टग्रेएसक्यूएल लॉग को स्टोर करने के लिए लॉग मैनेजर का उपयोग करने का मतलब यह भी होगा कि घटनाओं को भावी पीढ़ी के लिए सहेजा जाता है, भले ही मूल फाइलें गलती से या दुर्भावनापूर्ण रूप से हटा दी गई हों।

हालांकि लॉग प्रबंधन एप्लिकेशन का उपयोग करने के स्पष्ट लाभ हैं, कई संगठनों के पास कहां . के बारे में प्रतिबंध हैं उनके लॉग रह सकते हैं। यह सास-आधारित समाधानों के साथ एक विशिष्ट मामला है जहां लॉग को अक्सर किसी संगठन की भौगोलिक सीमा के बाहर सहेजा जाता है - कुछ ऐसा जो नियामक आवश्यकताओं के अनुरूप नहीं हो सकता है।

ऐसे मामलों में, मैं स्थानीय डेटा केंद्र उपस्थिति वाले विक्रेता को चुनने की सलाह देता हूं - यदि संभव हो तो - या संगठन के नेटवर्क में होस्ट किए गए स्व-प्रबंधित लॉग प्रबंधक का उपयोग करना, जैसे कि ईएलके स्टैक।

अंतिम शब्द

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