HighLoad++, Mikhail Makurov, Maxim Chernetsov (Intersvyaz): Zabbix, 100kNVPS एउटा सर्भरमा

अर्को HighLoad++ सम्मेलन अप्रिल 6 र 7, 2020 मा सेन्ट पीटर्सबर्गमा हुनेछ विवरण र टिकटहरू लिङ्क। HighLoad++ मस्को 2018. हल "मस्को"। नोभेम्बर 9, 15:00। थेसिस र प्रस्तुति.

* निगरानी - अनलाइन र विश्लेषण।
* ZABBIX प्लेटफर्मको आधारभूत सीमाहरू।
* स्केलिंग विश्लेषण भण्डारणको लागि समाधान।
* ZABBIX सर्भरको अनुकूलन।
* UI अनुकूलन।
* 40k NVPS भन्दा बढीको भारमा प्रणाली सञ्चालन गर्ने अनुभव लिनुहोस्।
* संक्षिप्त निष्कर्ष।

मिखाइल माकुरोव (यसपछि - एमएम): - नमस्ते सबै!

म्याक्सिम चेरनेत्सोभ (यसपछि - MCH): - शुभ दिउँसो!

MM: - मलाई म्याक्सिम परिचय गरौं। म्याक्स एक प्रतिभाशाली ईन्जिनियर हो, मलाई थाहा छ सबै भन्दा राम्रो नेटवर्कर। म्याक्सिम नेटवर्क र सेवाहरू, तिनीहरूको विकास र सञ्चालनमा संलग्न छ।

MCH: - र म तपाईंलाई मिखाइलको बारेमा बताउन चाहन्छु। मिखाइल एक C विकासकर्ता हो। उनले हाम्रो कम्पनीको लागि धेरै उच्च-लोड ट्राफिक प्रशोधन समाधानहरू लेखे। हामी युरालहरूमा बस्छौं र काम गर्छौं, कडा मानिसहरूको शहर चेल्याबिन्स्कमा, इन्टरस्भ्याज कम्पनीमा। हाम्रो कम्पनी १६ सहरमा १० लाख मानिसहरूका लागि इन्टरनेट र केबल टेलिभिजन सेवाहरू प्रदान गर्ने कम्पनी हो।

MM: - र यो भन्न लायक छ कि Intersvyaz केवल एक प्रदायक भन्दा धेरै हो, यो एक आईटी कम्पनी हो। हाम्रा अधिकांश समाधानहरू हाम्रो आईटी विभागद्वारा बनाइएका छन्।

A: सर्भरबाट कल सेन्टर र मोबाइल अनुप्रयोगमा ट्राफिक प्रशोधन गर्दै। IT विभागमा अहिले धेरै, धेरै विविध दक्षता भएका करिब 80 व्यक्तिहरू छन्।

Zabbix र यसको वास्तुकला बारे

MCH: - र अब म व्यक्तिगत रेकर्ड सेट गर्ने प्रयास गर्नेछु र Zabbix के हो भनेर एक मिनेटमा भन्नेछु (यसपछि "Zabbix" भनिन्छ)।

Zabbix आफैंलाई उद्यम-स्तर बाहिर-बक्स निगरानी प्रणालीको रूपमा राख्छ। यसमा धेरै सुविधाहरू छन् जसले जीवनलाई सजिलो बनाउँदछ: उन्नत एस्केलेसन नियमहरू, एकीकरणको लागि API, समूह र होस्ट र मेट्रिक्सको स्वत: पत्ता लगाउने। Zabbix सँग तथाकथित स्केलिंग उपकरणहरू छन् - प्रोक्सीहरू। Zabbix एक खुला स्रोत प्रणाली हो।

संक्षेपमा वास्तुकलाको बारेमा। हामी भन्न सक्छौं कि यसले तीन घटकहरू समावेश गर्दछ:

• सर्भर। सी मा लेखिएको। बरु जटिल प्रशोधन र थ्रेडहरू बीच जानकारीको स्थानान्तरणको साथ। सबै प्रशोधनहरू यसमा हुन्छन्: प्राप्त गर्ने देखि डाटाबेसमा बचत गर्न।
• सबै डाटा डाटाबेसमा भण्डार गरिएको छ। Zabbix MySQL, PostreSQL र Oracle लाई समर्थन गर्दछ।
• वेब इन्टरफेस PHP मा लेखिएको छ। धेरैजसो प्रणालीहरूमा यो Apache सर्भरको साथ आउँछ, तर nginx + php सँग संयोजनमा अझ प्रभावकारी रूपमा काम गर्दछ।

आज हामी Zabbix सँग सम्बन्धित हाम्रो कम्पनीको जीवनबाट एउटा कथा सुनाउन चाहन्छौं।

Intersvyaz कम्पनी को जीवन देखि एक कथा। हामीसँग के छ र हामीलाई के चाहिन्छ?

५–६ महिना अगाडिको कुरा हो । काम गरेपछि एक दिन...

MCH: - मिशा, नमस्ते! म तपाईंलाई समात्न सफल भएकोमा खुसी छु - त्यहाँ कुराकानी छ। अनुगमनमा हामीलाई फेरि समस्या भयो । ठूलो दुर्घटनाको समयमा, सबै कुरा ढिलो थियो र नेटवर्कको अवस्थाको बारेमा कुनै जानकारी थिएन। दुर्भाग्यवश, यो पहिलो पटक भएको छैन। मलाई तिम्रो सहयोग चाहियो। कुनै पनि परिस्थितिमा हाम्रो अनुगमन कार्य गरौं!

MM: - तर पहिले सिङ्क्रोनाइज गरौं। मैले त्यहाँ केही वर्षदेखि हेरेको छैन। जहाँसम्म मलाई याद छ, हामीले नागियोसलाई त्याग्यौं र लगभग 8 वर्ष पहिले Zabbix मा स्विच गर्यौं। र अब हामीसँग 6 शक्तिशाली सर्भरहरू र लगभग एक दर्जन प्रोक्सीहरू छन् जस्तो देखिन्छ। के म केहि भ्रममा छु?

MCH: - लगभग। 15 सर्भरहरू, जसमध्ये केही भर्चुअल मेसिनहरू हुन्। सबैभन्दा महत्त्वपूर्ण कुरा यो हो कि यसले हामीलाई बचाउन सक्दैन जब हामीलाई यसको सबैभन्दा धेरै आवश्यकता छ। दुर्घटना जस्तै - सर्भरहरू ढिलो हुन्छन् र तपाईंले केहि देख्न सक्नुहुन्न। हामीले कन्फिगरेसनलाई अनुकूलन गर्ने प्रयास गर्यौं, तर यसले इष्टतम कार्यसम्पादन वृद्धि प्रदान गर्दैन।

MM: - यो स्पष्ट छ। के तपाईंले केहि हेर्नुभयो, के तपाईंले पहिले नै निदानबाट केहि खोल्नुभयो?

MCH: - तपाईंले व्यवहार गर्नुपर्ने पहिलो कुरा डाटाबेस हो। MySQL लगातार लोड हुन्छ, नयाँ मेट्रिक्स भण्डारण गर्दै, र जब Zabbix ले घटनाहरूको गुच्छा उत्पन्न गर्न थाल्छ, डाटाबेस शाब्दिक रूपमा केही घण्टाको लागि ओभरड्राइभमा जान्छ। मैले तपाईंलाई कन्फिगरेसन अप्टिमाइज गर्ने बारे पहिले नै भनेको छु, तर शाब्दिक रूपमा यस वर्ष तिनीहरूले हार्डवेयर अपडेट गरे: सर्भरहरूसँग SSD RAIDs मा सय गीगाबाइट मेमोरी र डिस्क एरेहरू छन् - यसलाई लामो अवधिमा रैखिक रूपमा बढाउनुको कुनै मतलब छैन। हामी के गर्छौ?

MM: - यो स्पष्ट छ। सामान्यतया, MySQL एक LTP डाटाबेस हो। स्पष्ट रूपमा, यो अब हाम्रो आकारको मेट्रिक्सको संग्रह भण्डारण गर्न उपयुक्त छैन। यसलाई बाहिर निकालौं।

MCH: - गरौं!

ह्याकाथनको परिणाम स्वरूप Zabbix र Clickhouse को एकीकरण

केहि समय पछि हामीले रोचक डेटा प्राप्त गर्यो:

हाम्रो डाटाबेसको धेरैजसो ठाउँ मेट्रिक्स अभिलेखले ओगटेको थियो र कन्फिगरेसन, टेम्प्लेट र सेटिङहरूको लागि १% भन्दा कम प्रयोग गरिएको थियो। त्यसबेलासम्म, हामीले क्लिकहाउसमा आधारित बिग डाटा समाधान एक वर्षभन्दा बढी समयदेखि सञ्चालन गर्दै आएका थियौं। आन्दोलनको दिशा हाम्रो लागि स्पष्ट थियो। हाम्रो वसन्त ह्याकाथनमा, मैले सर्भर र फ्रन्टएन्डको लागि क्लिकहाउससँग Zabbix को एकीकरण लेखें। त्यो समयमा, Zabbix पहिले नै ElasticSearch को लागि समर्थन थियो, र हामीले तिनीहरूलाई तुलना गर्ने निर्णय गर्यौं।

Clickhouse र Elasticsearch को तुलना

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

उही परीक्षण सर्तहरू अन्तर्गत, क्लिकहाउसले तीन गुणा बढी डाटा लेख्यो। एकै समयमा, डेटा पढ्दा दुबै प्रणालीहरूले धेरै कुशलतापूर्वक (सानो मात्रामा स्रोतहरू) खपत गरे। तर इलास्टिकलाई रेकर्ड गर्दा ठूलो मात्रामा प्रोसेसर चाहिन्छ:

कुल मिलाएर, प्रोसेसर खपत र गतिको सन्दर्भमा क्लिकहाउस इलास्टिक्स भन्दा उल्लेखनीय रूपमा उच्च थियो। एकै समयमा, डाटा कम्प्रेसनको कारण, क्लिकहाउसले हार्ड ड्राइभमा 11 गुणा कम प्रयोग गर्दछ र लगभग 30 गुणा कम डिस्क सञ्चालनहरू प्रदर्शन गर्दछ:

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

स्रोतहरू अनुकूलन गर्न, तपाईंले आफ्नो अवस्थित मुख्य डाटाबेसको छेउमा क्लिकहाउस स्थापना गर्न सक्नुहुन्छ र यसरी धेरै CPU समय र डिस्क सञ्चालनहरू बचत गर्न सक्नुहुन्छ। हामीले मेट्रिक्सको अभिलेखलाई अवस्थित क्लिकहाउस क्लस्टरहरूमा सारेका छौं:

हामीले मुख्य MySQL डाटाबेसलाई यति धेरै राहत दियौं कि हामीले यसलाई Zabbix सर्भरसँग एक मेसिनमा जोड्न सक्छौं र MySQL को लागि समर्पित सर्भर त्याग्न सक्छौं।

Zabbix मा मतदान कसरी काम गर्छ?

२ महिना अघि

MM: - ठीक छ, के हामी आधार संग समस्याहरु को बारे मा बिर्सन सक्छौं?

MCH: - त्यो पक्का छ! हामीले समाधान गर्नुपर्ने अर्को समस्या भनेको ढिलो डाटा सङ्कलन हो। अब हाम्रा सबै 15 प्रोक्सी सर्भरहरू SNMP र मतदान प्रक्रियाहरूसँग ओभरलोड भएका छन्। र नयाँ र नयाँ सर्भरहरू स्थापना गर्न बाहेक कुनै उपाय छैन।

MM: - महान। तर पहिले, हामीलाई भन्नुहोस् कि Zabbix मा मतदान कसरी काम गर्दछ?

MCH: - छोटकरीमा, त्यहाँ 20 प्रकारका मेट्रिक्स र तिनीहरूलाई प्राप्त गर्न एक दर्जन तरिकाहरू छन्। Zabbix ले या त "अनुरोध-प्रतिक्रिया" मोडमा डाटा सङ्कलन गर्न सक्छ, वा "ट्रापर इन्टरफेस" मार्फत नयाँ डाटाको लागि पर्खन सक्छ।

यो ध्यान दिन लायक छ कि मूल Zabbix मा यो विधि (Trapper) सबैभन्दा छिटो छ।

लोड वितरणको लागि प्रोक्सी सर्भरहरू छन्:

प्रोक्सीहरूले Zabbix सर्भरको रूपमा उही सङ्कलन कार्यहरू प्रदर्शन गर्न सक्छन्, यसबाट कार्यहरू प्राप्त गर्न र Trapper इन्टरफेस मार्फत सङ्कलन मेट्रिक्स पठाउन। यो लोड वितरण गर्न आधिकारिक रूपमा सिफारिस गरिएको तरिका हो। प्रोक्सीहरू NAT वा ढिलो च्यानल मार्फत सञ्चालन हुने रिमोट इन्फ्रास्ट्रक्चर अनुगमनका लागि पनि उपयोगी छन्:

MM: - वास्तुकला संग सबै कुरा स्पष्ट छ। हामीले स्रोतहरू हेर्नु पर्छ ...

एक दुई दिन पछि

nmap fping कसरी जित्यो भन्ने कथा

MM: "मलाई लाग्छ कि मैले केहि खने।"

MCH: - मलाई भन्नुहोस्!

MM: - मैले पत्ता लगाए कि उपलब्धता जाँच गर्दा, Zabbix ले एक पटकमा अधिकतम 128 होस्टहरू जाँच गर्दछ। मैले यो संख्यालाई 500 मा बढाउने प्रयास गरें र तिनीहरूको पिंग (पिंग) मा अन्तर-प्याकेट अन्तराल हटाउने - यसले कार्यसम्पादनलाई दोब्बर बनायो। तर म ठूलो संख्या चाहन्छु।

MCH: - मेरो अभ्यासमा, मैले कहिलेकाहीँ हजारौं होस्टहरूको उपलब्धता जाँच गर्नुपर्छ, र मैले यसको लागि nmap भन्दा छिटो केहि देखेको छैन। म पक्का छु कि यो सबैभन्दा छिटो बाटो हो। यसलाई प्रयास गरौं! हामीले प्रति पुनरावृत्ति होस्टहरूको संख्या उल्लेखनीय रूपमा वृद्धि गर्न आवश्यक छ।

MM: - पाँच सय भन्दा बढी जाँच? ६००?

MCH: - कम्तिमा दुई हजार।

MM: - ठिक छ। मैले भन्न चाहेको सबैभन्दा महत्त्वपूर्ण कुरा यो हो कि मैले फेला पारे कि Zabbix मा धेरै जसो मतदान सिंक्रोनस गरिएको छ। हामीले निश्चित रूपमा यसलाई एसिन्क्रोनस मोडमा परिवर्तन गर्न आवश्यक छ। त्यसपछि हामी नाटकीय रूपमा पोलरहरू द्वारा सङ्कलन मेट्रिक्सको संख्या बढाउन सक्छौं, विशेष गरी यदि हामीले प्रति पुनरावृत्ति मेट्रिक्सको संख्या बढाउँछौं।

MCH: - महान! अनि कहिले?

MM: - सामान्य रूपमा, हिजो।

MCH: - हामीले fping र nmap को दुबै संस्करणहरू तुलना गर्यौं:

ठूलो संख्यामा होस्टहरूमा, nmap पाँच गुणा बढी प्रभावकारी हुने अपेक्षा गरिएको थियो। nmap ले मात्र उपलब्धता र प्रतिक्रिया समय जाँच गर्ने भएकोले, हामीले घाटाको गणनालाई ट्रिगरहरूमा सार्यौं र उपलब्धता जाँच अन्तरालहरूलाई उल्लेखनीय रूपमा कम गर्‍यौं। हामीले nmap को लागि होस्टहरूको इष्टतम संख्या प्रति पुनरावृत्ति लगभग 4 हजार भेट्टायौं। Nmap ले हामीलाई उपलब्धता जाँचको CPU लागत तीन पटक घटाउन र अन्तराललाई १२० सेकेन्डबाट १० मा घटाउन अनुमति दियो।

मतदान अनुकूलन

MM: “त्यसपछि हामीले पोलर गर्न थाल्यौं। हामी मुख्य रूपमा SNMP पत्ता लगाउने र एजेन्टहरूमा रुचि राखेका थियौं। Zabbix मा, मतदान सिंक्रोनस गरीन्छ र प्रणालीको दक्षता बढाउन विशेष उपायहरू लिइएको छ। सिंक्रोनस मोडमा, होस्ट अनुपलब्धताले महत्त्वपूर्ण मतदान गिरावट निम्त्याउँछ। त्यहाँ राज्यहरूको सम्पूर्ण प्रणाली छ, त्यहाँ विशेष प्रक्रियाहरू छन् - तथाकथित पहुँचयोग्य पोलरहरू, जसले पहुँचयोग्य होस्टहरूसँग मात्र काम गर्दछ:

यो एक टिप्पणी हो जसले राज्य म्याट्रिक्स प्रदर्शन गर्दछ, संक्रमण प्रणालीको सबै जटिलता जुन प्रणाली प्रभावकारी रहनको लागि आवश्यक छ। थप रूपमा, सिंक्रोनस मतदान आफैंमा एकदम ढिलो छ:

त्यसकारण दर्जनौं प्रोक्सीहरूमा हजारौं पोलर स्ट्रिमहरूले हाम्रो लागि आवश्यक डेटा सङ्कलन गर्न सकेनन्। एसिंक्रोनस कार्यान्वयनले थ्रेडहरूको संख्याको समस्या मात्र समाधान गर्‍यो, तर अनुपलब्ध होस्टहरूको राज्य प्रणालीलाई पनि महत्त्वपूर्ण रूपमा सरल बनायो, किनकि कुनै पनि संख्याको लागि एक मतदान पुनरावृत्तिमा जाँच गरिएको, अधिकतम प्रतीक्षा समय 1 टाइमआउट थियो:

थप रूपमा, हामीले SNMP अनुरोधहरूको लागि मतदान प्रणाली परिमार्जन र सुधार गरेका छौं। तथ्य यो हो कि धेरै व्यक्तिहरूले एकै समयमा धेरै SNMP अनुरोधहरूको जवाफ दिन सक्दैनन्। त्यसकारण, हामीले हाइब्रिड मोड बनायौं, जब एउटै होस्टको SNMP पोलिंग एसिन्क्रोनस रूपमा गरिन्छ:

यो होस्टहरूको सम्पूर्ण प्याकको लागि गरिन्छ। यो मोड अन्ततः पूर्ण रूपमा एसिन्क्रोनस भन्दा ढिलो छैन, किनकि डेढ सय SNMP मानहरू मतदान गर्न अझै पनि 1 टाइमआउट भन्दा धेरै छिटो छ।

हाम्रा प्रयोगहरूले देखाएको छ कि एक पुनरावृत्तिमा अनुरोधहरूको अधिकतम संख्या SNMP मतदानको साथ लगभग 8 हजार हो। कुलमा, एसिन्क्रोनस मोडमा संक्रमणले हामीलाई 200 पटक, धेरै सय पटक मतदान कार्यसम्पादनलाई गति दिन अनुमति दियो।

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

करिब तीन महिनाअघिको कुरा हो

वास्तुकला परिवर्तन गर्नुहोस् - लोड बढाउनुहोस्!

MM: - ठीक छ, म्याक्स, यो उत्पादक बन्ने समय हो? मलाई एक शक्तिशाली सर्भर र राम्रो इन्जिनियर चाहिन्छ।

MCH: - ठीक छ, यो योजना गरौं। 5 हजार मेट्रिक्स प्रति सेकेन्डको मृत बिन्दुबाट सार्नको लागि यो उच्च समय हो।

अपग्रेड पछि बिहान

MCH: - मिशा, हामीले आफैलाई अपडेट गर्यौं, तर बिहानसम्म हामी पछाडि फर्कियौं... अनुमान गर्नुहोस् हामीले कस्तो गति हासिल गर्न सफल भयौं?

MM: - अधिकतम २० हजार।

MCH: - हो, 25! दुर्भाग्यवश, हामीले सुरु गरेको ठाउँमा हामी ठीक छौं।

MM: - किन? के तपाईंले कुनै निदान चलाउनुभयो?

MCH: - हो, पक्का! यहाँ, उदाहरण को लागी, एक रोचक शीर्ष छ:

MM: - हेरौं। मैले देखेको छु कि हामीले धेरै संख्यामा मतदान थ्रेडहरू प्रयास गरेका छौं:

तर एकै समयमा तिनीहरूले प्रणालीलाई आधा पनि पुन: प्रयोग गर्न सकेनन्:

र समग्र प्रदर्शन एकदम सानो छ, लगभग 4 हजार मेट्रिक्स प्रति सेकेन्ड:

अरु केहि छ?

MCH: - हो, पोलर मध्ये एक को स्ट्रेस:

MM: - यहाँ तपाईंले स्पष्ट रूपमा देख्न सक्नुहुन्छ कि मतदान प्रक्रिया "सेमाफोरहरू" को लागि पर्खिरहेको छ। यी तालाहरू हुन्:

MCH: - अस्पष्ट।

MM: - हेर्नुहोस्, यो एक परिस्थितिसँग मिल्दोजुल्दो छ जहाँ थ्रेडहरूको गुच्छाले एक पटकमा मात्र काम गर्न सक्ने स्रोतहरूसँग काम गर्ने प्रयास गरिरहेको छ। त्यसोभए तिनीहरूले गर्न सक्ने सबै समयको साथ यो स्रोत साझा गर्नु हो:

र यस्तो स्रोत संग काम को कुल प्रदर्शन एक कोर को गति द्वारा सीमित छ:

यो समस्या समाधान गर्न दुई तरिकाहरू छन्।

मेसिनको हार्डवेयर अपग्रेड गर्नुहोस्, छिटो कोरहरूमा स्विच गर्नुहोस्:

वा वास्तुकला परिवर्तन गर्नुहोस् र एकै समयमा लोड परिवर्तन गर्नुहोस्:

MCH: - वैसे, परीक्षण मेसिनमा हामी लडाईको तुलनामा कम कोरहरू प्रयोग गर्नेछौं, तर तिनीहरू प्रति कोर फ्रिक्वेन्सीमा 1,5 गुणा छिटो छन्!

MM: - खाली? तपाईंले सर्भर कोड हेर्न आवश्यक छ।

Zabbix सर्भरमा डाटा मार्ग

MCH: - यो पत्ता लगाउन, हामीले Zabbix सर्भर भित्र डाटा कसरी स्थानान्तरण गरिन्छ भनेर विश्लेषण गर्न थाल्यौं:

राम्रो तस्वीर, सही? यसलाई कम वा कम स्पष्ट बनाउनको लागि यसलाई चरणबद्ध रूपमा जानुहोस्। डाटा सङ्कलन गर्न जिम्मेवार थ्रेड र सेवाहरू छन्:

तिनीहरूले सङ्कलन मेट्रिकहरू सकेट मार्फत प्रिप्रोसेसर प्रबन्धकमा पठाउँछन्, जहाँ तिनीहरू लाममा सुरक्षित हुन्छन्:

"प्रिप्रोसेसर प्रबन्धक" ले आफ्ना कामदारहरूलाई डाटा पठाउँछ, जसले प्रिप्रोसेसिङ निर्देशनहरू कार्यान्वयन गर्छ र तिनीहरूलाई उही सकेट मार्फत फिर्ता गर्छ:

यस पछि, प्रिप्रोसेसर प्रबन्धकले तिनीहरूलाई इतिहास क्यासमा भण्डार गर्दछ:

त्यहाँबाट तिनीहरू इतिहास सिंकहरू द्वारा लिइन्छ, जसले धेरै प्रकार्यहरू प्रदर्शन गर्दछ: उदाहरणका लागि, ट्रिगरहरू गणना गर्ने, मूल्य क्यास भर्ने र सबैभन्दा महत्त्वपूर्ण कुरा, इतिहास भण्डारणमा मेट्रिकहरू बचत गर्ने। सामान्यतया, प्रक्रिया जटिल र धेरै भ्रामक छ।

MM: - हामीले देखेको पहिलो कुरा यो थियो कि अधिकांश थ्रेडहरू तथाकथित "कन्फिगरेसन क्यास" (मेमोरी क्षेत्र जहाँ सबै सर्भर कन्फिगरेसनहरू भण्डारण गरिएका छन्) का लागि प्रतिस्पर्धा गर्छन्। डाटा सङ्कलन गर्न जिम्मेवार थ्रेडहरू विशेष गरी धेरै ब्लकिङ गर्छन्:

...किनभने कन्फिगरेसनले तिनीहरूको प्यारामिटरहरूसँग मेट्रिकहरू मात्र भण्डारण गर्दैन, तर पङ्क्तिहरू पनि जहाँबाट पोलरहरूले अब के गर्ने बारे जानकारी लिन्छन्। जब त्यहाँ धेरै पोलरहरू छन् र एकले कन्फिगरेसनलाई रोक्छ, अरूले अनुरोधहरूको लागि पर्खिरहेका छन्:

मतदाताहरूले विवाद गर्नु हुँदैन

त्यसकारण, हामीले पहिलो कुरा भनेको लामलाई 4 भागहरूमा विभाजन गर्नु थियो र पोलरहरूलाई यी लामहरू, यी भागहरूलाई एकै समयमा, सुरक्षित अवस्थामा रोक्न अनुमति दिनुभयो:

यसले कन्फिगरेसन क्यासको लागि प्रतिस्पर्धा हटायो, र पोलरहरूको गति उल्लेखनीय रूपमा बढ्यो। तर त्यसपछि हामीले यस तथ्यको सामना गर्‍यौं कि प्रिप्रोसेसर प्रबन्धकले कार्यहरूको लाम जम्मा गर्न थाले:

प्रिप्रोसेसर प्रबन्धकले प्राथमिकता दिन सक्षम हुनुपर्छ

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

यो समस्या समाधान गर्न, हामीले दोस्रो सकेट थप्यौं जुन विशेष गरी कामदारहरूलाई समर्पित थियो:

यसरी, प्रिप्रोसेसर प्रबन्धकसँग यसको कामलाई प्राथमिकता दिने अवसर थियो र, यदि बफर बढ्छ भने, कार्यकर्ताहरूलाई यो बफर लिने अवसर दिँदै, हटाउने कामलाई ढिलो गर्नु हो:

त्यसपछि हामीले पत्ता लगायौं कि मन्दीको एक कारण कामदारहरू आफैं थिए, किनकि तिनीहरूले उनीहरूको कामको लागि पूर्ण रूपमा महत्त्वपूर्ण नभएको स्रोतको लागि प्रतिस्पर्धा गरिरहेका थिए। हामीले यो समस्यालाई बग-फिक्सको रूपमा दस्तावेज गर्यौं, र यो Zabbix को नयाँ संस्करणहरूमा पहिले नै समाधान गरिएको छ:

हामी सकेटहरूको संख्या बढाउँछौं - हामी परिणाम पाउँछौं

यसबाहेक, प्रिप्रोसेसर प्रबन्धक आफैं एक बाधा बनेको छ, किनकि यो एक थ्रेड हो। यो कोर स्पीडमा रह्यो, प्रति सेकेन्ड लगभग 70 हजार मेट्रिक्सको अधिकतम गति दिँदै:

त्यसकारण, हामीले चार, सकेटहरूको चार सेटहरू, कामदारहरू बनायौं:

र यसले हामीलाई लगभग 130 हजार मेट्रिक्समा गति बढाउन अनुमति दियो:

वृद्धिको गैर-रेखीयता इतिहास क्यासको लागि प्रतिस्पर्धा देखा परेको तथ्य द्वारा व्याख्या गरिएको छ। 4 प्रिप्रोसेसर प्रबन्धकहरू र इतिहास सिंकहरू यसको लागि प्रतिस्पर्धा गरे। यस बिन्दुमा, हामीले परीक्षण मेसिनमा लगभग 130 हजार मेट्रिक्स प्रति सेकेन्ड प्राप्त गरिरहेका थियौं, यसलाई प्रोसेसरको लगभग 95% द्वारा प्रयोग गर्दै:

करिब २.५ महिना अगाडि

snmp-समुदायबाट अस्वीकारले NVPs डेढ गुणा बढ्यो

MM: - म्याक्स, मलाई नयाँ परीक्षण कार चाहिन्छ! हामी अब वर्तमानमा फिट छैनौं।

MCH: - तपाईसँग अहिले के छ?

MM: - अब - 130k NVPs र एक शेल्फ-तयार प्रोसेसर।

MCH: - वाह! राम्रो! पर्खनुहोस्, मसँग दुईवटा प्रश्न छन्। मेरो हिसाब अनुसार, हाम्रो आवश्यकता प्रति सेकेन्ड 15-20 हजार मेट्रिक्स छ। हामीलाई किन थप चाहिन्छ?

MM: "म काम पूरा गर्न चाहन्छु।" म हेर्न चाहन्छु कि हामी यो प्रणालीबाट कति निचोर्न सक्छौं।

MCH: - तर…

MM: "तर यो व्यापार को लागी बेकार छ।"

MCH: - यो स्पष्ट छ। र दोस्रो प्रश्न: के हामी विकासकर्ताको मद्दत बिना हामीसँग अहिले हामीसँग भएको कुरालाई समर्थन गर्न सक्छौं?

MM: - मलाई लाग्दैन। कन्फिगरेसन क्यास कसरी काम गर्दछ परिवर्तन गर्न एक समस्या हो। यसले धेरै थ्रेडहरूमा परिवर्तनहरूलाई असर गर्छ र कायम राख्न धेरै गाह्रो छ। सम्भवतः, यसलाई कायम राख्न धेरै गाह्रो हुनेछ।

MCH: "त्यसो भए हामीलाई केहि प्रकारको विकल्प चाहिन्छ।"

MM: - त्यहाँ यस्तो विकल्प छ। नयाँ लकिङ प्रणाली त्याग्दा हामी द्रुत कोरहरूमा स्विच गर्न सक्छौं। हामी अझै 60-80 हजार मेट्रिक्स को प्रदर्शन प्राप्त गर्नेछौं। एकै समयमा, हामी सबै बाँकी कोड छोड्न सक्छौं। क्लिकहाउस र एसिन्क्रोनस मतदानले काम गर्नेछ। र यसलाई कायम राख्न सजिलो हुनेछ।

MCH: - अचम्मको! म यहाँ रोक्न सुझाव दिन्छु।

सर्भर साइड अप्टिमाइज गरेपछि, हामी अन्ततः उत्पादनमा नयाँ कोड सुरु गर्न सक्षम भयौं। हामीले द्रुत कोरको साथ मेसिनमा स्विच गर्ने र कोड परिवर्तनहरूको संख्या कम गर्ने पक्षमा केही परिवर्तनहरू त्याग्यौं। हामीले कन्फिगरेसनलाई सरलीकृत गरेका छौं र सम्भव भएसम्म डेटा वस्तुहरूमा म्याक्रोहरू हटाएका छौं, किनकि तिनीहरूले अतिरिक्त लकिङ परिचय गराउँछन्।

उदाहरणका लागि, snmp-community macro लाई त्याग्दा, जुन प्रायः कागजात र उदाहरणहरूमा पाइन्छ, हाम्रो मामलामा NVPs लाई लगभग 1,5 गुणाले थप गति दिन सम्भव भयो।

उत्पादनमा दुई दिन पछि

घटना इतिहास पप-अप हटाउँदै

MCH: - मिशा, हामी दुई दिनदेखि प्रणाली प्रयोग गर्दैछौं, र सबै काम गर्दछ। तर जब सबै काम गर्दछ! हामीले नेटवर्कको एकदम ठूलो खण्डको स्थानान्तरणको साथ काम गर्ने योजना बनाएका थियौं, र हामीले फेरि हाम्रो हातले जाँच गर्यौं कि के बढ्यो र के छैन।

MM: - हुन सक्दैन! हामीले सबै कुरा १० पटक जाँच्यौं। सर्भरले पूर्ण नेटवर्क अनुपलब्धतालाई तुरुन्तै ह्यान्डल गर्दछ।

MCH: - हो, म सबै बुझ्छु: सर्भर, डाटाबेस, शीर्ष, अस्टाट, लगहरू - सबै छिटो छ... तर हामी वेब इन्टरफेस हेर्छौं, र त्यहाँ सर्भरमा "शेल्फमा" प्रोसेसर छ र यो:

MM: - यो स्पष्ट छ। वेब हेरौं। हामीले धेरै संख्यामा सक्रिय घटनाहरू भएको अवस्थामा, धेरैजसो लाइभ विजेटहरूले धेरै ढिलो काम गर्न थालेका छन् भनी फेला पारेका छन्:

यसको कारण घटना इतिहास पप-अपहरूको पुस्ता थियो जुन सूचीमा प्रत्येक वस्तुको लागि उत्पन्न हुन्छ। त्यसकारण, हामीले यी विन्डोजहरूको उत्पादनलाई त्याग्यौं (कोडमा 5 लाइनहरू टिप्पणी गरे), र यसले हाम्रो समस्याहरू समाधान गर्‍यो।

विजेटहरूको लागि लोडिङ समय, पूर्ण रूपमा अनुपलब्ध हुँदा पनि, हाम्रो लागि स्वीकार्य 10-15 सेकेन्डमा धेरै मिनेटबाट घटाइएको छ, र इतिहास अझै पनि समयमा क्लिक गरेर हेर्न सकिन्छ:

काम पछि। २ महिना अगाडि

MCH: - मिशा, तपाईं जाँदै हुनुहुन्छ? हामीले कुरा गर्नुपर्छ।

MM: - मेरो मनसाय थिएन। Zabbix संग फेरि केहि?

MCH: - होइन, आराम गर्नुहोस्! म मात्र भन्न चाहन्छु: सबै काम गर्दछ, धन्यवाद! मसँग बियर छ।

Zabbix कुशल छ

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

• तपाईं Elasticsearch सँग एकीकरण वा पाठ फाइलहरूमा इतिहास अपलोड गर्ने (संस्करण XNUMX बाट उपलब्ध) को रूपमा निर्मित उपकरणहरू प्रयोग गर्न सक्नुहुन्छ;
• तपाईंले हाम्रो अनुभव र Clickhouse को साथ एकीकरणको फाइदा लिन सक्नुहुन्छ।

नाटकीय रूपमा मेट्रिक्स सङ्कलनको गति बढाउन, तिनीहरूलाई एसिन्क्रोनस विधिहरू प्रयोग गरेर सङ्कलन गर्नुहोस् र ट्र्यापर इन्टरफेस मार्फत Zabbix सर्भरमा पठाउनुहोस्; वा तपाईले Zabbix पोलरहरूलाई एसिन्क्रोनस बनाउन प्याच प्रयोग गर्न सक्नुहुन्छ।

Zabbix C मा लेखिएको छ र धेरै कुशल छ। धेरै आर्किटेक्चरल बाधाहरू समाधान गर्नाले तपाईंलाई यसको कार्यसम्पादन बढाउन र हाम्रो अनुभवमा, एकल-प्रोसेसर मेशिनमा 100 हजार भन्दा बढी मेट्रिक्स प्राप्त गर्न अनुमति दिन्छ।

एउटै Zabbix प्याच

MM: - म केही बिन्दुहरू थप्न चाहन्छु। सम्पूर्ण हालको रिपोर्ट, सबै परीक्षणहरू, नम्बरहरू हामीले प्रयोग गर्ने कन्फिगरेसनका लागि दिइन्छ। हामी अहिले यसबाट प्रति सेकेन्ड लगभग २० हजार मेट्रिक्स लिइरहेका छौं। यदि तपाइँ यो तपाइँको लागि काम गर्दछ कि भनेर बुझ्न कोशिस गर्दै हुनुहुन्छ भने, तपाइँ तुलना गर्न सक्नुहुन्छ। आज के छलफल गरिएको थियो एक प्याच को रूप मा GitHub मा पोस्ट गरिएको छ: github.com/miklert/zabbix

प्याच समावेश छ:

• क्लिकहाउसको साथ पूर्ण एकीकरण (दुवै Zabbix सर्भर र फ्रन्टएन्ड);
• प्रिप्रोसेसर प्रबन्धक संग समस्या समाधान;
• एसिन्क्रोनस मतदान।

प्याच सबै संस्करण 4 सँग मिल्दो छ, lts सहित। सम्भवतः, न्यूनतम परिवर्तन संग यो संस्करण 3.4 मा काम गर्नेछ।

तपाईंको ध्यान लागि धन्यवाद।

तपाईंका प्रश्नहरू

श्रोताहरूबाट प्रश्न (यसपछि - A): - शुभ दिउँसो! कृपया मलाई भन्नुहोस्, के तपाईंसँग Zabbix टोली वा तिनीहरूसँग गहन अन्तरक्रिया गर्ने योजना छ, ताकि यो प्याच होइन, तर Zabbix को सामान्य व्यवहार हो?

MM: - हो, हामी निश्चित रूपमा केहि परिवर्तनहरू गर्नेछौं। केहि हुनेछ, केहि प्याचमा रहनेछ।

A: - उत्कृष्ट रिपोर्ट को लागी धेरै धेरै धन्यवाद! कृपया मलाई भन्नुहोस्, प्याच लागू गरेपछि, Zabbix बाट समर्थन रहनेछ र कसरी उच्च संस्करणहरूमा अद्यावधिक जारी राख्ने? के तपाइँको प्याच 4.2, 5.0 मा Zabbix अद्यावधिक गर्न सम्भव हुनेछ?

MM: – म समर्थनको बारेमा केही भन्न सक्दिन। यदि म Zabbix प्राविधिक समर्थन हुँ भने, म सायद होइन भन्न सक्छु, किनभने यो अरू कसैको कोड हो। 4.2 कोडबेसको लागि, हाम्रो स्थिति यो हो: "हामी समयसँगै सर्नेछौं, र हामी आफैलाई अर्को संस्करणमा अपडेट गर्नेछौं।" त्यसकारण, केहि समयको लागि हामी अपडेट गरिएको संस्करणहरूको लागि प्याच पोस्ट गर्नेछौं। मैले पहिले नै रिपोर्टमा भनें: संस्करणहरूको साथ परिवर्तनहरूको संख्या अझै धेरै सानो छ। मलाई लाग्छ 3.4 देखि 4 सम्मको संक्रमणले हामीलाई लगभग 15 मिनेट लियो। त्यहाँ केहि परिवर्तन भयो, तर धेरै महत्त्वपूर्ण छैन।

A: - त्यसोभए तपाइँ आफ्नो प्याचलाई समर्थन गर्ने योजना बनाउनुहुन्छ र तपाइँ यसलाई सुरक्षित रूपमा उत्पादनमा स्थापना गर्न सक्नुहुन्छ र भविष्यमा कुनै न कुनै रूपमा अद्यावधिकहरू प्राप्त गर्न सक्नुहुन्छ?

MM: - हामी दृढताका साथ सिफारिस गर्दछौं। यसले हाम्रो लागि धेरै समस्याहरू समाधान गर्दछ।

MCH: - एक पटक फेरि, म यस तथ्यमा ध्यानाकर्षण गर्न चाहन्छु कि परिवर्तनहरू जसले वास्तुकलासँग सरोकार राख्दैन र अवरुद्ध वा लामहरूको चिन्ता नगर्ने मोड्युलर हो, तिनीहरू अलग मोड्युलमा छन्। सानातिना परिवर्तनहरू भए पनि तपाईंले तिनीहरूलाई सजिलैसँग कायम राख्न सक्नुहुन्छ।

MM: - यदि तपाइँ विवरणहरूमा रुचि राख्नुहुन्छ भने, "क्लिकहाउस" तथाकथित इतिहास पुस्तकालय प्रयोग गर्दछ। यो खुला छ - यो Elastics समर्थन को एक प्रतिलिपि हो, त्यो हो, यो कन्फिगर योग्य छ। मतदानले पोलरलाई मात्र परिवर्तन गर्छ। यसले लामो समयसम्म काम गर्ने विश्वास छ ।

A: - धेरै धेरै धन्यवाद। मलाई भन्नुहोस्, त्यहाँ गरिएका परिवर्तनहरूको कुनै कागजात छ?

MM: - कागजात एक प्याच हो। स्पष्ट रूपमा, क्लिकहाउसको परिचयको साथ, नयाँ प्रकारका पोलरहरूको परिचयसँगै, नयाँ कन्फिगरेसन विकल्पहरू उत्पन्न हुन्छन्। अन्तिम स्लाइडको लिङ्कमा यसलाई कसरी प्रयोग गर्ने भन्ने छोटो विवरण छ।

fping लाई nmap ले प्रतिस्थापन गर्ने बारे

A: – अन्त्यमा यसलाई कसरी कार्यान्वयन गर्नुभयो ? के तपाइँ विशिष्ट उदाहरणहरू दिन सक्नुहुन्छ: के तपाइँसँग स्ट्र्यापर र बाह्य लिपि छ? यति ठूलो संख्यामा होस्टहरूको यति चाँडो जाँच गर्दा के हुन्छ? तपाईं यी होस्टहरू कसरी खान गर्नुहुन्छ? के हामीले तिनीहरूलाई कुनै न कुनै रूपमा nmap गर्न, तिनीहरूलाई कतैबाट ल्याउन, तिनीहरूलाई भित्र राख्न, केही चलाउन आवश्यक छ? ..

MM: - चिसो। एकदमै सहि प्रश्न ! कुरो यही हो । हामीले ICMP जाँचहरूको लागि पुस्तकालय (ICMP पिंग, Zabbix को भाग) परिमार्जन गर्‍यौं, जसले प्याकेटहरूको संख्या - एक (1), र कोडले nmap प्रयोग गर्ने प्रयास गर्छ। त्यो हो, यो Zabbix को आन्तरिक काम हो, जुन पिङ्गर को आन्तरिक काम भएको छ। तदनुसार, कुनै सिङ्क्रोनाइजेसन वा ट्र्यापरको प्रयोग आवश्यक छैन। यो जानाजानी प्रणालीलाई अक्षुण्ण छोड्न र दुई डाटाबेस प्रणालीहरूको सिंक्रोनाइजेसनको सामना गर्न नपर्ने गरी गरिएको थियो: के जाँच गर्ने, पोलर मार्फत अपलोड गर्ने, र हाम्रो अपलोड बिग्रिएको छ?... यो धेरै सरल छ।

A: - के यसले प्रोक्सीहरूको लागि पनि काम गर्छ?

MM: - हो, तर हामीले जाँच गरेनौं। मतदान कोड Zabbix र सर्भर दुवैमा समान छ। काम गर्नुपर्छ। मलाई एक पटक फेरि जोड दिनुहोस्: प्रणालीको प्रदर्शन यस्तो छ कि हामीलाई प्रोक्सीको आवश्यकता पर्दैन।

MCH: - प्रश्नको सही उत्तर हो: "तपाईलाई यस्तो प्रणालीको साथ प्रोक्सी किन चाहिन्छ?" केवल NAT को कारण वा केहि ढिलो च्यानल मार्फत निगरानी ...

A: - र तपाईले Zabbix लाई अलर्टरको रूपमा प्रयोग गर्नुहुन्छ, यदि मैले सहि बुझें भने। वा तपाईंको ग्राफिक्स (जहाँ अभिलेख तह छ) अर्को प्रणालीमा सारियो, जस्तै Grafana? वा तपाइँ यो कार्यक्षमता प्रयोग गर्दै हुनुहुन्छ?

MM: – म फेरि एकपटक जोड दिनेछु: हामीले पूर्ण एकीकरण हासिल गरेका छौं। हामी क्लिकहाउसमा इतिहास राख्दैछौं, तर एकै समयमा हामीले php फ्रन्टएन्ड परिवर्तन गरेका छौं। Php फ्रन्टएन्ड क्लिकहाउसमा जान्छ र त्यहाँबाट सबै ग्राफिक्स गर्दछ। एकै समयमा, इमानदार हुन, हामीसँग एउटै क्लिकहाउसबाट अन्य ग्राफिक प्रदर्शन प्रणालीहरूमा डाटा निर्माण गर्ने एउटा भाग छ, उही Zabbix डाटाबाट।

MCH: - "ग्राफन" मा पनि।

स्रोतको बाँडफाँडमा कसरी निर्णय भयो ?

A: - आफ्नो भित्री भान्सा को एक सानो साझा गर्नुहोस्। उत्पादनको गम्भीर प्रशोधनका लागि स्रोतहरू विनियोजन गर्न आवश्यक भएको निर्णय कसरी भयो? यी, सामान्यतया, निश्चित जोखिमहरू हुन्। र कृपया मलाई भन्नुहोस्, तथ्यको सन्दर्भमा कि तपाइँ नयाँ संस्करणहरूलाई समर्थन गर्न जाँदै हुनुहुन्छ: यो निर्णय व्यवस्थापन दृष्टिकोणबाट कसरी उचित हुन्छ?

MM: - जाहिर छ, हामीले इतिहासको नाटकलाई राम्रोसँग बताएनौं। हामीले आफूलाई एउटा परिस्थितिमा भेट्टायौं जहाँ केहि गर्नुपर्दछ, र हामी अनिवार्य रूपमा दुई समानान्तर टोलीहरूसँग गयौं:

• एउटाले नयाँ विधिहरू प्रयोग गरेर अनुगमन प्रणाली सुरू गरिरहेको थियो: सेवाको रूपमा निगरानी, ​​खुला स्रोत समाधानहरूको एक मानक सेट जुन हामीले संयोजन गर्छौं र त्यसपछि नयाँ अनुगमन प्रणालीसँग काम गर्नको लागि व्यापार प्रक्रिया परिवर्तन गर्ने प्रयास गर्छौं।
• एकै समयमा, हामीसँग एक उत्साही प्रोग्रामर थियो जसले यो गरिरहेको थियो (आफ्नो बारेमा)। यस्तो भयो कि उसले जित्यो।

A: - र टोलीको आकार के हो?

MCH: - उनी तपाईको अगाडि छिन्।

A: - त्यसोभए, सधैं जस्तै, तपाईंलाई एक भावुक चाहिन्छ?

MM: - मलाई थाहा छैन एक भावुक के हो।

A: - यस अवस्थामा, स्पष्ट रूपमा, तपाईं। धेरै धेरै धन्यवाद, तपाईं अद्भुत हुनुहुन्छ।

MM: - धन्यवाद।

Zabbix का लागि प्याचहरूको बारेमा

A: - प्रोक्सीहरू प्रयोग गर्ने प्रणालीको लागि (उदाहरणका लागि, केही वितरण प्रणालीहरूमा), के यो अनुकूलन गर्न र प्याच गर्न सम्भव छ, पोलरहरू, प्रोक्सीहरू र आंशिक रूपमा Zabbix आफैंको प्रिप्रोसेसर; र तिनीहरूको अन्तरक्रिया? के बहुविध प्रोक्सीहरूको साथ प्रणालीको लागि अवस्थित विकासहरू अनुकूलन गर्न सम्भव छ?

MM: - मलाई थाहा छ कि Zabbix सर्भर प्रोक्सी प्रयोग गरेर भेला गरिएको छ (कोड संकलित र प्राप्त गरिएको छ)। हामीले उत्पादनमा यो परीक्षण गरेका छैनौं। म यस बारे निश्चित छैन, तर मलाई लाग्छ कि प्रिप्रोसेसर प्रबन्धक प्रोक्सीमा प्रयोग गरिएको छैन। प्रोक्सीको कार्य भनेको Zabbix बाट मेट्रिक्सको सेट लिनु, तिनीहरूलाई मर्ज गर्नु (यसले कन्फिगरेसन, स्थानीय डाटाबेस पनि रेकर्ड गर्दछ) र यसलाई Zabbix सर्भरमा फिर्ता दिनु हो। सर्भरले यसलाई प्राप्त गर्दा प्रिप्रोसेसिङ गर्नेछ।

प्रोक्सीहरूमा चासो बुझ्न सकिन्छ। हामी यसलाई जाँच गर्नेछौं। यो एउटा रोचक विषय हो।

A: - विचार यो थियो: यदि तपाइँ पोलरहरू प्याच गर्न सक्नुहुन्छ, तपाइँ तिनीहरूलाई प्रोक्सीमा प्याच गर्न सक्नुहुन्छ र सर्भरसँग अन्तर्क्रिया प्याच गर्न सक्नुहुन्छ, र सर्भरमा मात्र यी उद्देश्यहरूको लागि प्रिप्रोसेसर अनुकूलन गर्न सक्नुहुन्छ।

MM: - मलाई लाग्छ यो अझ सरल छ। तपाइँ कोड लिनुहोस्, प्याच लागू गर्नुहोस्, त्यसपछि तपाइँलाई चाहिने तरिका कन्फिगर गर्नुहोस् - प्रोक्सी सर्भरहरू सङ्कलन गर्नुहोस् (उदाहरणका लागि, ODBC सँग) र प्याच गरिएको कोड प्रणालीहरूमा वितरण गर्नुहोस्। जहाँ आवश्यक छ - प्रोक्सी सङ्कलन गर्नुहोस्, जहाँ आवश्यक छ - सर्भर।

A: - सम्भवतः, तपाईले सर्भरमा प्रोक्सी ट्रान्समिशन प्याच गर्नुपर्दैन?

MCH: - होइन, यो मानक हो।

MM: - वास्तवमा, विचारहरु मध्ये एक आवाज लागेन। हामीले सधैं विचारहरूको विस्फोट र परिवर्तनको मात्रा र समर्थनको सहजता बीच सन्तुलन कायम गरेका छौं।

केही विज्ञापनहरू 🙂

हामीसँग रहनु भएकोमा धन्यवाद। तपाईलाई हाम्रा लेखहरू मनपर्छ? थप रोचक सामग्री हेर्न चाहनुहुन्छ? हामीलाई अर्डर गरेर वा साथीहरूलाई सिफारिस गरेर समर्थन गर्नुहोस्, $4.99 बाट विकासकर्ताहरूको लागि क्लाउड VPS, प्रविष्टि-स्तर सर्भरहरूको एक अद्वितीय एनालग, जुन हामीले तपाईंको लागि आविष्कार गरेको हो: VPS (KVM) E5-2697 v3 (6 कोर) 10GB DDR4 480GB SSD 1Gbps $ 19 बाट वा कसरी सर्भर साझा गर्ने बारे सम्पूर्ण सत्य? (RAID1 र RAID10 सँग उपलब्ध, 24 कोर सम्म र 40GB DDR4 सम्म)।

डेल R730xd 2x एम्स्टर्डमको इक्विनिक्स टियर IV डाटा सेन्टरमा सस्तो छ? यहाँ मात्र 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 बाट नेदरल्याण्ड मा! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 बाट! बारे पढ्नुहोस् पूर्वाधार कर्पोरेशन कसरी निर्माण गर्ने। डेल R730xd E5-2650 v4 सर्भरहरूको प्रयोगको साथ एक पैसाको लागि 9000 यूरो मूल्यको वर्ग?

स्रोत: www.habr.com