👾 🈳 🧕🏽 मुनिन के लिए स्टेरॉयड 👩🏽‍🏭 🥥 😫

मुनिन सर्वरों की निगरानी के लिए एक बहुत अच्छी चीज है, खासकर एक या दो। हालाँकि, यदि सर्वर की संख्या बढ़ती है, तो यह बदतर और बदतर काम करता है। बिल्ली के नीचे, मैंने 1000 से अधिक आभासी मशीनों (सिस्टम में 275K rrd फाइलें) की निगरानी के लिए इसे कैसे ओवरक्लॉक किया इसकी कहानी।

क्यों मुनिन

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

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

Rrd के आधार पर, यह पेशेवरों और विपक्ष दोनों को जोड़ता है।

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

समस्याओं

- अपनी पूंछ पर कदम रखना शुरू कर दिया (5 मिनट में पूरा करने का समय नहीं है);
- बहुत भारी डिस्क लोड करता है;
- कॉन्फ़िगर को संपादित करना असुविधाजनक है (आप लगातार एक नया सर्वर जोड़ने या पुराने को हटाने के लिए भूल जाते हैं);
- समग्र रेखांकन लिखना मुश्किल है;
- नागियोस के साथ कोई एकीकरण नहीं था।

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

और उनका निर्णय

overclock

ग्राफ़ की पीढ़ी को CGI / FastCGI के रूप में करना सुनिश्चित करें, यह गति देता है लेकिन बहुत अधिक नहीं।

मुनिन को केवल महंगे तरीके से ओवरक्लॉक करना संभव है, सभी आरडी को मेमोरी (tmpfs) में डाल दिया। और कुछ नहीं, न तो RAID और न ही एसएसडी मदद करता है, अफसोस। 275K rrd पर 14GB का कब्जा है, जो इतना अधिक नहीं है, 32 जीबी रैम वाला सर्वर असामान्य नहीं है (कुछ और जीबी मुनिन की प्रक्रियाओं को ही प्रभावित करेगा)। लेकिन डिस्क सबसे साधारण हो सकती है।

स्वाभाविक रूप से, हर घंटे में एक बार आपको डिस्क को फ्लश करने और मौजूदा आरआरडी को बस पैक करने की आवश्यकता होती है। एक पैक संग्रह एक SATA ड्राइव के लिए पूरी तरह से लिखा गया है।

मुनिन अपने आप को साफ नहीं करता है, इसलिए आपको बिना इस्तेमाल किए हुए गड्ढे को साफ करने की जरूरत है
/ usr / bin / find / mnt / ramdrive / -type f -mtime +5 -delete

स्मृति उपयोग की अनिवार्यता के बारे में एक छोटा सा विषयांतर

ऐसी सभी प्रणालियों के साथ समस्या यह है कि डेटा "ट्रांसवर्सली" (प्रत्येक मीट्रिक से एक माप) आता है, लेकिन इसे "अनुदैर्ध्य" (एक मीट्रिक के लिए सभी माप) संसाधित किया जाता है और इस स्ट्रीम को फेरबदल करना बहुत मुश्किल है। आप तुरंत "longitudinally" के रूप में rrd लिख सकते हैं और रिकॉर्ड की प्रतीक्षा कर सकते हैं, आप डेटाबेस में "बाद में" लिख सकते हैं (बस एक बार एक बड़ी मेज पर रिकॉर्ड जोड़ सकते हैं) और फिर उन्हें धीरे से पढ़ें।
किसी भी मामले में, मेमोरी में एक बड़ा कैश / इंडेक्स अपरिहार्य है।

चूंकि हमारे पास बहुत अधिक मेमोरी है, तो हम प्रक्रियाओं को प्रतिबंधित किए बिना अपडेट चलाते हैं, यह धीमी प्लगइन्स के साथ मदद करता है। केवल मैंने मुनिन-अपडेट को मारने के लिए एक टाइमर लगाया, जो 3 मिनट से अधिक समय तक काम करता है।

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

मुनिन-अपडेट सामान्य रूप से कॉन्फिग को पढ़ेगा और लिखेगा, साथ ही स्टेबल मॉड्यूल का उपयोग करके कॉन्फिगर ऑब्जेक्ट को सेव करेगा। यदि कोई है, तो मुनिन-ग्राफ स्टिच फ़ाइल को पढ़ेगा।
यह रेखांकन के आरेख को तेज करता है, लेकिन मेमोरी को खा जाता है, 64 मेगाबाइट का विन्यास 375MB की वर्चुअल मेमोरी प्रति प्रक्रिया में बदल जाता है।

अजीब तरह से पर्याप्त है, यह मुनिन-अपडेट के लिए एक बड़ी समस्या नहीं है, क्योंकि यह पहली बार मेमोरी में कॉन्फ़िगरेशन का विस्तार करता है, और फिर टोस्क करता है। नतीजतन, 250 एमबी में आरएसएस के साथ शीर्ष 1000 प्रक्रियाओं में और केवल 21 जीबी रैम का उपयोग किया गया (उनमें से 14 खराब हैं)!
मुनिन-ग्राफ के साथ एक बड़ी समस्या है, क्योंकि प्रत्येक प्रक्रिया ईमानदारी से अपनी 400MB मेमोरी खाती है, लेकिन अभी तक पर्याप्त मेमोरी है।

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

और इसे और अधिक सुविधाजनक बनाते हैं

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

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

यह पता चला है कि सर्वर के लिए अनुरोधों का योग खींचने के लिए इस तरह का एक मुनिन प्लगइन है

#!/usr/bin/perl -w use strict; use warnings; if($ARGV[0] && $ARGV[0] eq 'config') { print <<<'EOS'; host_name Aggregated graph_title Total requests graph_args --base 1000 -l 0 graph_vlabel requests graph_category Nginx graph_info Total count of requests total.label total requests total.info total requests EOS exit(0); } my @rrd_files = `/bin/ls /mnt/ramdrive/munin/oMobile/*-nginx_log_access-total-d.rrd`; my $sum = 0; foreach my $filename (@rrd_files) { next unless(-f $filename); my $lastline = `/usr/bin/rrdtool fetch $filename AVERAGE -s -15M -e now | fgrep -v 'nan' | tail -n 1`; if($lastline =~ m/^\d+: ([-+.0-9e]+)\s*$/) { $sum+=$1; } } print "total.value $sum\n"; exit(0);

ऐसा कभी मत करो! यह सिर्फ प्रदर्शन के लिए है, यह अनावश्यक निष्पादन का एक बादल बनाता है, उत्पादन में आरआरडी का उपयोग करना अनिवार्य है।

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

Host_name पर ध्यान दें, जिससे आप मुनिन में वर्चुअल होस्ट और डोमेन बना सकते हैं और उनमें दिलचस्प ग्राफिक्स बना सकते हैं।

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

कुल मिलाकर

- rrd पर आधारित किसी भी सिस्टम को मेमोरी (tmpfs) में rrd files लगाकर ओवरक्लॉक किया जा सकता है;
- छोटी परियोजनाओं के लिए सुविधाजनक मुनिन को सर्वर की एक ध्यान देने योग्य संख्या तक बढ़ाया जा सकता है (मेरे लिए> 1500 मुनिन-नोड);
- एक छोटी स्क्रिप्ट और आप काफी जटिल ग्राफिक्स आकर्षित कर सकते हैं;
- एक छोटी स्क्रिप्ट और आप रुझानों का विश्लेषण कर सकते हैं और उन पर अलर्ट रिपोर्ट कर सकते हैं।