स्केलिंग ज़ैबिक्स

जो एक औद्योगिक पैमाने पर ज़ैबिक्स का उपयोग या उपयोग करने का इरादा रखते हैं, वे हमेशा इस सवाल के बारे में चिंतित रहे हैं: आखिरकार घुट और घुट से पहले ज़ाबिक्स को कितना वास्तविक डेटा "पच" सकता है? मेरे हाल के काम का हिस्सा इस मुद्दे से निपटा है। तथ्य यह है कि मेरे पास 32,000 से अधिक नोड्स के साथ एक विशाल नेटवर्क है, और जो संभवतः भविष्य में ज़ैबिक्स द्वारा पूरी तरह से निगरानी कर सकता है। मंच लंबे समय से चर्चा कर रहा है कि बड़े पैमाने पर काम करने के लिए ज़ैबिक्स को कैसे अनुकूलित किया जाए, लेकिन, दुर्भाग्य से, मुझे अभी भी एक पूर्ण समाधान नहीं मिल पाया है।

इस लेख में मैं यह दिखाना चाहता हूं कि मैंने अपने सिस्टम को कैसे सेट किया, वास्तव में बहुत सारे डेटा को संसाधित करने में सक्षम है। ताकि आप समझ सकें कि यह किस बारे में है, यहाँ सिर्फ सिस्टम के आँकड़ों के साथ एक तस्वीर है:



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



जैसा कि ग्राफ़ में दिखाया गया है, ज़ैबिक्स औसतन प्रति सेकंड 9,260 अनुरोधों को संसाधित करता है। इसके अलावा, नेटवर्क पर 15,000 एनवीपीएस तक की छोटी-छोटी फटने की घटनाएं थीं , जिन्हें सर्वर ने बिना किसी समस्या के सामना किया। ईमानदारी से, यह बहुत अच्छा है!

आर्किटेक्चर

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

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

लोहा

सही लोहा खोजना आसान प्रक्रिया नहीं है। मुख्य बात जो मैंने यहां की थी, वह सैन को डेटा स्टोर करने के लिए उपयोग करना था, क्योंकि ज़ैबिक्स डेटाबेस को बहुत अधिक आई / ओ डिस्क सिस्टम की आवश्यकता होती है। सीधे शब्दों में कहें, डेटाबेस सर्वर पर जितनी तेजी से डिस्क, उतना ही डेटा ज़ैबिक्स प्रक्रिया कर सकता है।

बेशक, सीपीयू और मेमोरी भी MySQL के लिए बहुत महत्वपूर्ण हैं। रैम की एक बड़ी मात्रा Zabbix को मेमोरी में अक्सर पढ़ने वाले डेटा को स्टोर करने की अनुमति देती है, जो स्वाभाविक रूप से सिस्टम की गति में योगदान करती है। प्रारंभ में, मैंने एक डेटाबेस सर्वर 64GB मेमोरी के लिए योजना बनाई थी, लेकिन अब तक 32GB पर सब कुछ ठीक है।

सर्वर जिस पर zabbix_server स्वयं स्थापित है, में पर्याप्त रूप से तेज़ CPU होना चाहिए, क्योंकि यह आवश्यक है कि यह शांत रूप से सैकड़ों हजारों ट्रिगर की प्रक्रिया करता है। और 12 जीबी पर्याप्त मेमोरी होगी - चूंकि ज़ैबिक्स सर्वर पर ही कई प्रक्रियाएं नहीं हैं (लगभग सभी मॉनिटर एक प्रॉक्सी के माध्यम से हैं)।

DBMS और zabbix_server के विपरीत, Zabbix proxies को गंभीर हार्डवेयर की आवश्यकता नहीं है, इसलिए मैंने वर्चुअल मशीनों का उपयोग किया। मूल रूप से, सक्रिय डेटा तत्व एकत्र किए जाते हैं, इसलिए प्रॉक्सी डेटा संग्रह बिंदुओं के रूप में काम करते हैं, जबकि वे स्वयं व्यावहारिक रूप से कुछ भी पूछताछ नहीं करते हैं।

यहाँ एक सारांश तालिका है जो मैंने अपने सिस्टम पर प्रयोग की है:

Zabbix सर्वर	ज़ाबिक्स डीबी	ज़बिक्स प्रॉक्सिज़	सैन
HP ProLiant BL460c Gen8 12x इंटेल Xeon E5-2630 16GB मेमोरी 128GB डिस्क सेंटोस 6.2 x64 झाबिक्स 2.0.6	HP ProLiant BL460c Gen8 12x इंटेल Xeon E5-2630 32 जीबी मेमोरी 2TB सैन-समर्थित स्टोरेज (4Gbps FC) सेंटोस 6.2 x64 MySQL 5.6.12	VMware वर्चुअल मशीन 4x वीसीपीयू 8 जीबी मेमोरी 50GB डिस्क सेंटोस 6.2 x64 झाबिक्स 2.0.6 MySQL 5.5.18	हिताची यूनिफाइड स्टोरेज वी.एम. 2x 2TB LUN Tiered भंडारण (2TB SSD के साथ)

दोष सहिष्णुता Zabbix सर्वर

आइए हम उन वास्तु मुद्दों पर लौटते हैं जो मैंने ऊपर दिए थे। बड़े नेटवर्क में, स्पष्ट कारणों के लिए, काम नहीं करना निगरानी एक वास्तविक आपदा है। हालाँकि, ज़ैबिक्स आर्किटेक्चर आपको ज़ैबिक्स सर्वर प्रक्रिया के एक से अधिक उदाहरणों को चलाने की अनुमति नहीं देता है।

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

1. आईपी ​​पता साझा किया
   
   1. फेलोवर के मामले में, आईपी पता सर्वर पर जाता है, जो सक्रिय हो जाता है
   2. चूंकि साझा आईपी पता हमेशा सक्रिय ज़ैबिक्स सर्वर द्वारा उपयोग किया जाता है, इसलिए इससे तीन फायदे मिलते हैं:
      
      • यह पता लगाना हमेशा आसान होता है कि कौन सा सर्वर सक्रिय है
      • Zabbix सर्वर से सभी कनेक्शन हमेशा एक ही IP से होते हैं (Zabbix_server.conf में SourceIP = पैरामीटर सेट करने के बाद)
      • सभी Zabbix परदे के पीछे और Zabbix एजेंट बस सर्वर के रूप में एक सामान्य IP का उपयोग करते हैं
      
      
2. Zabbix_server प्रक्रिया
   
   • एक feylover के मामले में zabbix_server को पुराने सर्वर पर रोक दिया जाएगा और नए पर शुरू किया जाएगा
   
   
3. क्रॉन जॉब्स के लिए साइमलिंक
   
   1. सिमलिंक उस निर्देशिका को इंगित करता है जहां कार्य झूठ हैं, जिसे केवल सक्रिय ज़ैबिक्स सर्वर पर किया जाना चाहिए। Crontab के पास इस सिमलिंक के माध्यम से सभी कार्यों तक पहुंच होनी चाहिए
   2. फेलोवर के मामले में, सिम्लिंक को पुराने सर्वर पर हटा दिया जाता है और नए पर बनाया जाता है
4. crond
   
   • फेलोवर के मामले में, क्रोन पुराने सर्वर पर बंद हो जाता है और नए सक्रिय सर्वर पर शुरू होता है
   
   

कॉन्फ़िगरेशन फ़ाइल का एक उदाहरण, साथ ही एक zabbix सर्वर के लिए LSB init स्क्रिप्ट यहां डाउनलोड की जा सकती है । "<>" में संलग्न मापदंडों को संपादित करना याद रखें। इसके अलावा, init स्क्रिप्ट को इस तथ्य को ध्यान में रखते हुए लिखा गया है कि सभी ज़ैबिक्स फाइलें एक ही फ़ोल्डर (/ usr / स्थानीय / zabbix) में हैं। इसलिए यदि आवश्यक हो तो स्क्रिप्ट में पथ समायोजित करें।

DBMS गलती सहिष्णुता

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

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

1. आईपी ​​पता साझा किया
   
   1. फेलोवर के मामले में, आईपी पता सर्वर पर जाता है, जो सक्रिय हो जाता है
   2. चूंकि साझा आईपी पता हमेशा सक्रिय ज़ैबिक्स सर्वर द्वारा उपयोग किया जाता है, इसलिए इससे दो फायदे मिलते हैं:
      
      • यह पता लगाना हमेशा आसान होता है कि कौन सा सर्वर सक्रिय है।
      • एक विफलता के मामले में, नए सक्रिय MySQL सर्वर के पते को इंगित करने के लिए Zabbix सर्वर पर कोई कार्रवाई आवश्यक नहीं है
      
      
2. सामान्य दास आईपी पता
   
   1. इस IP पते का उपयोग तब किया जा सकता है जब डेटाबेस में रीड रिक्वेस्ट आती है। इस प्रकार, यदि उपलब्ध हो तो क्वेरी को MySQL दास सर्वर द्वारा संसाधित किया जा सकता है
   2. किसी भी सर्वर का एक अतिरिक्त पता हो सकता है, यह निम्नलिखित पर निर्भर करता है:
      
      • यदि दास सर्वर उपलब्ध है, और घड़ी 60 सेकंड से अधिक नहीं चलती है, तो इसका एक पता होगा
      • अन्यथा, MySQL मास्टर सर्वर का पता होगा
3. mysqld
   
   • फेलोवर के मामले में, नया MySQL सर्वर सक्रिय हो जाएगा। यदि इसके बाद पुराना सर्वर वापस आ जाता है, तो यह पहले से बने नए मास्टर के लिए एक गुलाम बना रहेगा।

कॉन्फ़िगरेशन फ़ाइल का एक उदाहरण यहां लिया जा सकता है । "<>" में संलग्न पेसमेकर मापदंडों को संपादित करना याद रखें। आपको पेसमेकर के साथ उपयोग के लिए एक और MySQL संसाधन एजेंट डाउनलोड करने की आवश्यकता हो सकती है। इस लिंक को दस्तावेज़ में Percona github भंडार में पेसमेकर के साथ MySQL क्लस्टर स्थापित करने के लिए पाया जा सकता है । इसके अलावा, बस एक "आग दुर्घटना" के मामले में, एक प्रति यहाँ है ।

Zabbix प्रॉक्सी

यदि किसी कारणवश आपने ज़ैबिक्स प्रॉक्सिज़ के बारे में नहीं सुना है, तो कृपया तुरंत प्रलेखन में देखें । परदे के पीछे Zabbix कई मशीनों में निगरानी लोड वितरित करने की अनुमति देता है। उसके बाद, पहले से ही हर Zabbix प्रॉक्सी Zabbix सर्वर पर सभी एकत्रित डेटा भेजता है।

जब Zabbix परदे के पीछे के साथ काम करना, यह याद रखना महत्वपूर्ण है:

1. Zabbix परदे के पीछे डेटा की बहुत गंभीर मात्रा को संभालने में सक्षम हैं अगर ठीक से कॉन्फ़िगर किया गया हो। इसलिए, उदाहरण के लिए, परीक्षणों के दौरान, प्रॉक्सी (इसे प्रॉक्सी कहते हैं) ने 1500-1750 NVPS को बिना किसी समस्या के संसाधित किया। और यह एक वर्चुअल मशीन है जिसमें दो वर्चुअल CPU, 4GB RAM और SQLite3 डेटाबेस हैं। उसी समय, प्रॉक्सी सर्वर के साथ उसी साइट पर थी, इसलिए नेटवर्क पर देरी को ध्यान में नहीं रखा जा सकता था। इसके अलावा, लगभग जो कुछ भी एकत्र किया गया था वह सक्रिय Zabbix एजेंट डेटा तत्व था
2. इससे पहले, मैंने उल्लेख किया कि निगरानी करते समय नेटवर्क विलंबता कितनी महत्वपूर्ण है। इसलिए, यह सच है जब बड़े सिस्टम की बात आती है। वास्तव में, एक डेटा है कि एक छद्म सीधे अंतराल के बिना भेज सकते हैं की मात्रा नेटवर्क पर निर्भर करता है।
   
   नीचे दिया गया ग्राफ़ स्पष्ट रूप से दिखाता है कि नेटवर्क लेटेंसी को ध्यान में नहीं रखने पर समस्याएं कैसे बढ़ती हैं। एक प्रॉक्सी जिसमें समय नहीं है:

शायद, यह काफी स्पष्ट है कि ट्रांसमिशन के लिए डेटा से कतार में वृद्धि नहीं होनी चाहिए। ग्राफ एक और ज़ैबिक्स प्रॉक्सी (प्रॉक्सी बी) को संदर्भित करता है, जो प्रॉक्सी ए से हार्डवेयर में अलग नहीं है, लेकिन केवल 500NVPS के बिना समस्याओं को प्रसारित कर सकता है और 1500NVPS को नहीं, प्रॉक्सी ए की तरह। अंतर यह है कि बी सिंगापुर और अपने आप में स्थित है। उत्तरी अमेरिका में सर्वर, और साइटों के बीच देरी लगभग 230ms है। इस देरी का एक गंभीर प्रभाव है, जिस तरह से डेटा भेजा जाता है। हमारे मामले में, प्रॉक्सी बी हर 2-3 सेकंड में केवल 1000 एकत्रित ज़ैबिक्स तत्वों को सर्वर पर भेज सकता है। मेरी टिप्पणियों के अनुसार, यह वही होता है:

• प्रॉक्सी सर्वर से कनेक्शन स्थापित करता है
• अधिकतम प्रॉक्सी एक बार में 1000 एकत्रित डेटा आइटम मान भेजता है।
• प्रॉक्सी कनेक्शन बंद कर देता है

इस प्रक्रिया को आवश्यकतानुसार कई बार दोहराया जाता है। एक बड़ी देरी के मामले में, इस पद्धति में कई गंभीर समस्याएं हैं:

• प्रारंभिक कनेक्शन बहुत धीमा है। मेरे मामले में, यह 0.25 सेकंड में होता है। ओह!
• चूंकि 1000 डेटा तत्वों को भेजने के बाद कनेक्शन बंद हो गया है, टीसीपी कनेक्शन चैनल के सभी उपलब्ध बैंडविड्थ का उपयोग करने के प्रबंधन के लिए कभी भी लंबे समय तक नहीं रहता है।

डेटाबेस प्रदर्शन

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

• प्रारंभ में, मैंने सिस्टम पर MySQL 5.5.18 का उपयोग किया। सबसे पहले, कोई भी दृश्य प्रदर्शन समस्याएं नहीं देखी गईं, हालांकि, 700-750 एनवीपीएस के बाद MySQL ने प्रोसेसर को 100% पर लोड करना शुरू कर दिया और सिस्टम का शाब्दिक रूप से "फ्रिज़" था। कॉन्फ़िगरेशन फ़ाइल में मापदंडों को घुमाकर, बड़े पृष्ठों को सक्रिय करने या विभाजन के कारण स्थिति को ठीक करने के मेरे आगे के प्रयासों से कुछ भी नहीं हुआ। मेरी पत्नी ने बेहतर समाधान का सुझाव दिया: पहले MySQL 5.6 में अपग्रेड करें और फिर उसका पता लगाएं। मेरे आश्चर्य के लिए, एक सरल अद्यतन ने सभी प्रदर्शन समस्याओं को हल किया, जिसे मैं 5.5.18 में नहीं हरा सकता था। बस के मामले में, यहाँ my.cnf की एक प्रति है।

ग्राफ़ डेटाबेस में प्रति सेकंड अनुरोधों की संख्या दिखाता है:


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

एक और प्रदर्शन मुद्दा Zabbix हाउसकीपर हो सकता है। बड़े नेटवर्क में, मैं इसे बंद करने की अत्यधिक सलाह देता हूं। ऐसा करने के लिए, DisableHousekeeping = 1 को कॉन्फ़िगर फ़ाइल में सेट करें। यह स्पष्ट है कि हाउसकीपिंग के बिना पुराने डेटा (डेटा तत्वों, घटनाओं, कार्यों) को डेटाबेस से हटाया नहीं जाएगा। फिर हटाने को विभाजन के माध्यम से आयोजित किया जा सकता है।

हालांकि, MySQL 5.6.12 की सीमाओं में से एक यह है कि विभाजन का उपयोग विदेशी कुंजी के साथ तालिकाओं में नहीं किया जा सकता है, और वे ज़ैबिक्स डेटाबेस में लगभग हर जगह मौजूद हैं। लेकिन इतिहास तालिकाओं के अलावा, जिसकी हमें जरूरत है। विभाजन से हमें दो फायदे होते हैं:

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

Zabbiks में विभाजन के बारे में पहले से ही हैबे पर लिखा गया था।

इकट्ठा या सुनना

Zabbix में डेटा संग्रह की दो विधियाँ हैं: सक्रिय और निष्क्रिय: Zabbix की निष्क्रिय निगरानी के मामले में, सर्वर स्वयं Zabbix एजेंटों का सर्वेक्षण करता है, और सक्रिय होने की स्थिति में, यह Zabbix एजेंटों के लिए स्वयं सर्वर से कनेक्ट होने की प्रतीक्षा करता है। ज़ैबिक्स ट्रॉपर भी सक्रिय निगरानी के तहत आता है, क्योंकि दीक्षा भेजना मेजबान पक्ष पर रहता है।

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

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

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

ज़ैबिक्स की निगरानी स्वयं

ज़ैबिक्स की निगरानी के बिना, एक बड़ी प्रणाली का प्रभावी संचालन बस संभव नहीं है - यह समझना महत्वपूर्ण है कि जब सिस्टम नया डेटा प्राप्त करने से इनकार करता है तो "प्लग" कहां होगा। मौजूदा ज़ैबिक्स निगरानी डेटा तत्वों को यहां पाया जा सकता है । ज़ैबिक्स के संस्करणों में 2.x में, उन्हें कृपया "बॉक्स से बाहर" प्रदान किए गए ज़ैबिक्स सर्वर मॉनिटरिंग टेम्प्लेट में इकट्ठा किया गया था। इसका उपयोग करें!

एक उपयोगी मैट्रिक हिस्ट्री राइट कैशे (सर्वर कॉन्फिग फाइल में हिस्ट्रीशीटसाइज़) में खाली जगह है। यह पैरामीटर हमेशा 100% के करीब होना चाहिए। यदि कैश भरा हुआ है, तो इसका मतलब है कि Zabbix में डेटाबेस में आने वाले डेटा को जोड़ने का समय नहीं है।

दुर्भाग्य से, यह विकल्प Zabbix प्रॉक्सी द्वारा समर्थित नहीं है। इसके अलावा, Zabbix में, कोई डेटा तत्व नहीं है जो यह दर्शाता है कि Zabbix सर्वर पर कितने डेटा भेजे जाने की प्रतीक्षा है। हालाँकि, यह डेटा आइटम SQL क्वेरी के माध्यम से प्रॉक्सी डेटाबेस के लिए खुद को करना आसान है:

SELECT ((SELECT MAX(proxy_history.id) FROM proxy_history)-nextid) FROM ids WHERE field_name='history_lastid'

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

UserParameter=zabbix.proxy.items.sync.remaining,/usr/bin/sqlite3 /path/to/the/sqlite/database "SELECT ((SELECT MAX(proxy_history.id) FROM proxy_history)-nextid) FROM ids WHERE field_name='history_lastid'" 2>&1


अगला, बस एक ट्रिगर लगाएं जो सूचित करेगा कि प्रॉक्सी कॉपी नहीं कर रहा है:

{Hostname:zabbix.proxy.items.sync.remaining.min(10m)}>100000

कुल आँकड़े

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








और यहाँ डेटाबेस सर्वर से रेखांकन हैं। हर दिन ट्रैफ़िक की वृद्धि डंपिंग (mysqldump) के समय से मेल खाती है। इसके अलावा, क्वेरी ग्राफ़ (qps) में 16 जुलाई की विफलता उसी समस्या से संबंधित है जिसका मैंने ऊपर वर्णन किया था।

प्रबंध

कुल मिलाकर, सिस्टम Zabbix सर्वर के लिए 2 सर्वर, MySQL के लिए 2 सर्वर, Zabbix प्रॉक्सी के लिए 16 वर्चुअल सर्वर और Zabbix एजेंटों के साथ हजारों मॉनिटर किए गए सर्वर का उपयोग करता है। इतने सारे मेजबानों के साथ, हाथ से बदलाव करने का कोई सवाल ही नहीं था। और समाधान Git रिपॉजिटरी था, जिसे सभी सर्वरों तक पहुंच है, और जहां मैं सभी कॉन्फ़िगरेशन फ़ाइलों, स्क्रिप्ट्स, और अन्य सभी को स्थित करता हूं जिन्हें वितरित करने की आवश्यकता है। इसके बाद, मैंने एक स्क्रिप्ट लिखी जिसे एजेंट में UserParameter के माध्यम से लिखा गया है। स्क्रिप्ट चलाने के बाद, सर्वर Git रिपॉजिटरी से कनेक्ट होता है, सभी आवश्यक फ़ाइलों और अपडेट को डाउनलोड करता है, और फिर Zabbix एजेंट / प्रॉक्सी / सर्वर को पुनरारंभ करता है यदि कॉन्फ़िगरेशन फ़ाइलों में परिवर्तन होता था। अपडेट करना zabbix_get को चलाने से अधिक कठिन नहीं है!

वेब इंटरफेस के माध्यम से मैन्युअल रूप से नए मेजबान बनाना भी इतने सारे सर्वरों के साथ हमारी पद्धति नहीं है। हमारी कंपनी में CMDB है, जिसमें वे सभी सर्वर और सेवाओं के बारे में जानकारी होती है जो वे प्रदान करते हैं। इसलिए, एक और जादू की स्क्रिप्ट हर घंटे CMDB से जानकारी एकत्र करती है और इसकी तुलना Zabbix में होती है। इस तुलना के निष्कर्ष पर, होस्ट मेजबानों को हटा / जोड़ / बदल देता है, एक समूह होस्ट बनाता है, और मेजबानों को टेम्पलेट जोड़ता है। इस मामले में मैन्युअल रूप से किए जाने वाले सभी नए प्रकार के ट्रिगर या डेटा तत्व का कार्यान्वयन है। दुर्भाग्य से, ये स्क्रिप्ट हमारे सिस्टम से दृढ़ता से जुड़ी हुई हैं, इसलिए मैं उन्हें साझा नहीं कर सकता।

खुले मुद्दे

मेरे द्वारा किए गए सभी प्रयासों के बावजूद, एक महत्वपूर्ण समस्या बनी हुई है जिसे मुझे अभी तक हल नहीं करना है। तथ्य यह है कि जब सिस्टम 8000-9000NVPS तक पहुंचता है, तो बैकअप MySQL डेटाबेस अब मुख्य एक के साथ नहीं रहता है, इसलिए वास्तव में कोई गलती सहनशीलता नहीं है।

मेरे पास इस समस्या को हल करने के उपाय हैं, लेकिन मुझे इसे लागू करने का समय नहीं मिला है:

• डेटाबेस के विभाजन के लिए DRBD के साथ लिनक्स-हा का उपयोग करें।
• LUN प्रतिकृति पर SAN एक और LUN की प्रतिकृति के साथ
• पर्कोना XtraDB क्लस्टर। 5.6 संस्करण में यह अभी भी उपलब्ध नहीं है, इसलिए आपको इसके साथ इंतजार करना होगा (जैसा कि मैंने लिखा था, MySQL 5.5 में प्रदर्शन समस्याएं थीं)

संदर्भ

• लेख से सभी डाउनलोड के साथ ज़िप फ़ाइल
• बड़ा पर्यावरण मंच धागा
• Zabbix सर्वर कॉन्फ़िगरेशन प्रलेखन
• Zabbix प्रॉक्सी ने निगरानी प्रलेखन वितरित किया
• Zabbix सक्रिय / निष्क्रिय आइटम प्रलेखन
• Zabbix आंतरिक आइटम प्रलेखन
• आंतरिक वस्तुओं पर Zabbix blogpost
• पेसमेकर / CMAN Quickstart गाइड
• MySQL पेसमेकर कॉन्फ़िगरेशन गाइड
• MySQL लार्ज पेज
• Zabbix डेटाबेस का विभाजन