सर के बचाव में (और इसे कैसे कॉन्फ़िगर करें)

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

निगरानी के महत्व पर

सबसे पहले, बुनियादी सिस्टम मेट्रिक्स (सीपीयू, आई/ओ, मेमोरी) की निगरानी अत्यंत महत्वपूर्ण है। अन्य इंजीनियरों के साथ चर्चा में इसे इंगित करना थोड़ा अजीब है, लेकिन मैं कहूंगा कि 10 में से 1 इंजीनियर को लगता है कि उन्हें वास्तव में निगरानी की आवश्यकता नहीं है। तर्क आमतौर पर इन पंक्तियों के साथ जाता है:

यह सच्ची निगरानी ओवरहेड जोड़ती है, इसमें कोई संदेह नहीं है। लेकिन एप्लिकेशन क्या कर रहा है, इसकी तुलना में यह नगण्य है। दरअसल, sar वास्तव में कोई अतिरिक्त उपकरण नहीं जोड़ रहा है, यह केवल nernel से काउंटर पढ़ रहा है, डेल्टा की गणना कर रहा है और डिस्क पर लिख रहा है। इसके लिए कुछ डिस्क स्थान और I/O (CPU और डिस्क की संख्या के आधार पर) की आवश्यकता हो सकती है, लेकिन यह इसके बारे में है।

उदाहरण के लिए, 32 कोर और कई डिस्क वाली मशीन पर प्रति सेकंड आंकड़े एकत्र करने से प्रति दिन ~ 5GB कच्चा डेटा उत्पन्न होगा, लेकिन यह बहुत अच्छी तरह से संकुचित होता है, अक्सर ~ 5-10% तक। और यह मुश्किल से top में दिखाई देता है . प्रति सेकंड रिज़ॉल्यूशन थोड़ा चरम है, और 5 या 10 सेकंड का उपयोग करने से ओवरहेड कम हो जाएगा।

तो नहीं, पता चलता है कि ओवरहेड वास्तव में निगरानी को सक्षम नहीं करने का एक वैध कारण नहीं है।

लागत बनाम लाभ

इससे भी महत्वपूर्ण बात यह है कि, "निगरानी को सक्षम न करके मैं कितना ओवरहेड समाप्त कर सकता हूं?" गलत सवाल पूछना है। इसके बजाय आपको पूछना चाहिए "निगरानी से मुझे क्या लाभ मिलता है? क्या लाभ लागत से अधिक हैं?"

हम पहले से ही जानते हैं कि लागत (ओवरहेड) काफी कम या पूरी तरह से नगण्य है। क्या लाभ हैं? मेरे अनुभव में, निगरानी डेटा होना प्रभावी रूप से अमूल्य है।

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

दूसरे, यह आपको रुझानों का मूल्यांकन करने और संभावित मुद्दों की पहचान करने की अनुमति देता है इससे पहले कि वे वास्तव में आपको प्रभावित करें। आप कितने सीपीयू का उपयोग कर रहे हैं? क्या CPU उपयोग समय के साथ बढ़ रहा है? क्या स्मृति उपयोग में कुछ संदिग्ध पैटर्न हैं? आप उन सवालों के जवाब तभी दे सकते हैं जब आपके पास निगरानी हो।

क्यों `sar` मेरा पसंदीदा टूल है

आइए मान लें कि मुझे विश्वास है कि निगरानी महत्वपूर्ण है और आपको इसे निश्चित रूप से करना चाहिए। लेकिन क्यों है sar हमारा पसंदीदा टूल, जब ऑन-प्रिमाइसेस और क्लाउड आधारित दोनों तरह के फैंसी विकल्प मौजूद हैं?

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

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

यदि आपके पास प्रबंधित करने के लिए कई प्रणालियां हैं, तो आप शायद एक निगरानी समाधान पसंद करेंगे जो कई मशीनों से एक ही स्थान पर डेटा एकत्र करता है। लेकिन मेरे लिए sar अभी भी जीतता है।

तो, इसे कैसे कॉन्फ़िगर करें?

मैंने sar . को स्थापित करने और सक्षम करने का उल्लेख किया है (या बल्कि sysstat , जो sar . सहित पैकेज है ) बहुत सरल है। दुर्भाग्य से, डिफ़ॉल्ट कॉन्फ़िगरेशन कुछ हद तक खराब है। sysstat installing को इंस्टाल करने के बाद , आपको /etc/cron.d/sysstat . में कुछ ऐसा मिलेगा (या जहां भी आपका वितरण cron . स्टोर करता है कॉन्फ़िगरेशन):

*/10 * * * * root /usr/lib64/sa/sa1 1 1

यह प्रभावी रूप से sa1 . कहता है कमांड को हर 10 मिनट में निष्पादित किया जाएगा, और यह 1 सेकंड में एक नमूना एकत्र करेगा। यहां दो समस्याएं हैं। सबसे पहले, 10 मिनट काफी कम रिज़ॉल्यूशन है। दूसरे, नमूना 600 में से केवल 1 सेकंड को कवर करता है, इसलिए शेष 9:59 वास्तव में इसमें शामिल नहीं हैं। लंबी अवधि के रुझान के लिए यह कुछ हद तक ठीक है, जहां कम-रिज़ॉल्यूशन यादृच्छिक नमूनाकरण पर्याप्त है। अन्य उद्देश्यों के लिए आपको शायद इसके बजाय कुछ ऐसा करने की आवश्यकता है:

* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1

जो प्रति मिनट एक नमूना एकत्र करता है, और प्रत्येक नमूना एक मिनट को कवर करता है। -S XALL इसका मतलब है कि सभी आंकड़े एकत्र किए जाने चाहिए, जिसमें इंटरप्ट, अलग-अलग ब्लॉक डिवाइस और विभाजन आदि शामिल हैं। देखें man sadc अधिक जानकारी के लिए।

सारांश

तो, इस पोस्ट को कुछ सरल बिंदुओं में समेटने के लिए:

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

एक बात जो मैंने नहीं बताई वह है sar केवल सिस्टम मेट्रिक्स से संबंधित है - सीपीयू, डिस्क, मेमोरी, प्रोसेस, पोस्टग्रेएसक्यूएल आँकड़ों के साथ नहीं। आपको निश्चित रूप से स्टैक के उस हिस्से की भी निगरानी करनी चाहिए।