HighLoad++, Andrey Gushchin (Zabbix): उच्च कार्यक्षमता आणि मूळ विभाजन

बॅकएंड म्हणून टाइमस्केलडीबी डेटाबेससह Zabbix कसे कार्य करते ते आम्ही पाहू. सुरवातीपासून सुरुवात कशी करायची आणि PostgreSQL मधून स्थलांतर कसे करायचे ते आम्ही तुम्हाला दाखवू. आम्ही दोन कॉन्फिगरेशनच्या तुलनात्मक कामगिरी चाचण्या देखील देऊ.

HighLoad++ सायबेरिया 2019. टॉम्स्क हॉल. जून 24, 16:00. प्रबंध आणि सादरीकरण. पुढील HighLoad++ परिषद 6 आणि 7 एप्रिल 2020 रोजी सेंट पीटर्सबर्ग येथे आयोजित केली जाईल. तपशील आणि तिकिटे दुवा.

आंद्रे गुश्चिन (यापुढे - एजी): - मी एक ZABBIX तांत्रिक समर्थन अभियंता आहे (यापुढे "Zabbix" म्हणून संदर्भित), एक प्रशिक्षक. मी 6 वर्षांहून अधिक काळ तांत्रिक समर्थनामध्ये काम करत आहे आणि मला कार्यप्रदर्शनाचा प्रत्यक्ष अनुभव आहे. आज मी नियमित PostgreSQL 10 च्या तुलनेत TimescaleDB प्रदान करू शकणार्‍या कामगिरीबद्दल बोलणार आहे. तसेच, ते सर्वसाधारणपणे कसे कार्य करते याबद्दल काही प्रास्ताविक भाग.

शीर्ष उत्पादकता आव्हाने: डेटा संकलन ते डेटा साफ करणे

सुरुवातीला, प्रत्येक मॉनिटरिंग सिस्टमला काही विशिष्ट कार्यप्रदर्शन आव्हाने असतात. पहिले उत्पादकता आव्हान म्हणजे डेटा पटकन गोळा करणे आणि त्यावर प्रक्रिया करणे.

चांगल्या मॉनिटरिंग सिस्टमने त्वरीत, वेळेवर सर्व डेटा प्राप्त केला पाहिजे, ट्रिगर अभिव्यक्तीनुसार त्यावर प्रक्रिया केली पाहिजे, म्हणजे, काही निकषांनुसार त्यावर प्रक्रिया केली पाहिजे (हे वेगवेगळ्या सिस्टममध्ये भिन्न आहे) आणि हा डेटा वापरण्यासाठी डेटाबेसमध्ये जतन केला पाहिजे. भविष्य

दुसरे कार्यप्रदर्शन आव्हान म्हणजे इतिहास संचयन. डेटाबेसमध्‍ये अनेकदा संचयित करा आणि ठराविक कालावधीत संकलित केलेल्या या मेट्रिक्सवर जलद आणि सोयीस्कर प्रवेश मिळवा. सर्वात महत्त्वाची गोष्ट अशी आहे की हा डेटा प्राप्त करणे, अहवाल, आलेख, ट्रिगर, काही थ्रेशोल्ड मूल्यांमध्ये, अलर्ट इत्यादींमध्ये वापरणे सोयीस्कर आहे.

तिसरे परफॉर्मन्स चॅलेंज म्हणजे हिस्ट्री क्लिअरिंग, म्हणजे, जेव्हा तुम्ही अशा टप्प्यावर पोहोचता की तुम्हाला 5 वर्षांपेक्षा जास्त (महिने किंवा दोन महिने सुद्धा) गोळा केलेले कोणतेही तपशीलवार मेट्रिक्स साठवण्याची गरज नसते. काही नेटवर्क नोड्स हटवले गेले किंवा काही होस्ट, मेट्रिक्सची यापुढे आवश्यकता नाही कारण ते आधीच जुने झाले आहेत आणि यापुढे संकलित केले जाणार नाहीत. हे सर्व साफ करणे आवश्यक आहे जेणेकरून आपला डेटाबेस खूप मोठा होणार नाही. सर्वसाधारणपणे, इतिहास साफ करणे ही बर्‍याचदा स्टोरेजसाठी एक गंभीर चाचणी असते - याचा बर्‍याचदा कार्यक्षमतेवर जोरदार प्रभाव पडतो.

कॅशिंग समस्यांचे निराकरण कसे करावे?

मी आता विशेषतः Zabbix बद्दल बोलेन. Zabbix मध्ये, पहिला आणि दुसरा कॉल कॅशिंग वापरून सोडवला जातो.

डेटा संकलन आणि प्रक्रिया - आम्ही हा सर्व डेटा संग्रहित करण्यासाठी RAM वापरतो. या डेटावर आता अधिक तपशीलवार चर्चा केली जाईल.

डेटाबेसच्या बाजूला मुख्य निवडीसाठी - आलेख आणि इतर गोष्टींसाठी काही कॅशिंग आहे.

Zabbix सर्व्हरच्या बाजूलाच कॅशिंग: आमच्याकडे ConfigurationCache, ValueCache, HistoryCache, TrendsCache आहे. हे काय आहे?

ConfigurationCache हे मुख्य कॅशे आहे ज्यामध्ये आम्ही मेट्रिक्स, होस्ट, डेटा आयटम, ट्रिगर्स साठवतो; प्रीप्रोसेसिंग, डेटा संकलित करण्यासाठी, कोणत्या यजमानांकडून गोळा करायचा, कोणत्या वारंवारतेसह आवश्यक आहे. डेटाबेसमध्ये जाऊन अनावश्यक प्रश्न निर्माण होऊ नयेत म्हणून हे सर्व कॉन्फिगरेशन कॅशेमध्ये साठवले जाते. सर्व्हर सुरू झाल्यानंतर, आम्ही ही कॅशे अद्यतनित करतो (ते तयार करतो) आणि वेळोवेळी अद्यतनित करतो (कॉन्फिगरेशन सेटिंग्जवर अवलंबून).

Zabbix मध्ये कॅशिंग. माहिती मिळवणे

येथे आकृती खूप मोठी आहे:

योजनेतील मुख्य हे कलेक्टर आहेत:

या स्वतः असेंब्ली प्रक्रिया आहेत, विविध प्रकारच्या असेंब्लीसाठी जबाबदार असलेले विविध “पोलर्स”. ते icmp, ipmi आणि विविध प्रोटोकॉलद्वारे डेटा संकलित करतात आणि ते सर्व प्रीप्रोसेसिंगमध्ये हस्तांतरित करतात.

प्रीप्रोसेसिंग हिस्ट्री कॅशे

तसेच, जर आमच्याकडे डेटा घटकांची गणना केली असेल (ज्यांना Zabbix शी परिचित आहेत त्यांना माहिती आहे), म्हणजेच गणना केलेले, एकत्रीकरण डेटा घटक, आम्ही ते थेट ValueCache वरून घेतो. ते कसे भरले ते मी नंतर सांगेन. हे सर्व संग्राहक त्यांच्या नोकर्‍या प्राप्त करण्यासाठी कॉन्फिगरेशन कॅशे वापरतात आणि नंतर त्यांना प्रीप्रोसेसिंगकडे पाठवतात.

प्रीप्रोसेसिंग प्रीप्रोसेसिंग पायऱ्या मिळविण्यासाठी कॉन्फिगरेशन कॅशे देखील वापरते आणि या डेटावर विविध प्रकारे प्रक्रिया करते. आवृत्ती ४.२ पासून सुरू करून, आम्ही ते प्रॉक्सीमध्ये हलवले आहे. हे खूप सोयीचे आहे, कारण प्रीप्रोसेसिंग स्वतःच एक कठीण ऑपरेशन आहे. आणि जर तुमच्याकडे खूप मोठे झब्बीक्स असेल, मोठ्या संख्येने डेटा घटक आणि उच्च संकलन वारंवारता, तर हे काम मोठ्या प्रमाणात सुलभ करते.

त्यानुसार, प्रीप्रोसेसिंगचा वापर करून आम्ही या डेटावर काही प्रकारे प्रक्रिया केल्यानंतर, त्यावर पुढील प्रक्रिया करण्यासाठी आम्ही तो HistoryCache मध्ये सेव्ह करतो. हे डेटा संकलनाचा निष्कर्ष काढते. आम्ही मुख्य प्रक्रियेकडे जाऊ.

इतिहास समक्रमणाचे कार्य

Zabbix मधील मुख्य प्रक्रिया (ती एक मोनोलिथिक आर्किटेक्चर असल्याने) हिस्ट्री सिंकर आहे. ही मुख्य प्रक्रिया आहे जी विशेषत: प्रत्येक डेटा घटकाच्या अणू प्रक्रियेशी संबंधित आहे, म्हणजेच प्रत्येक मूल्य:

• मूल्य येते (ते HistoryCache वरून घेते);
• कॉन्फिगरेशन सिंकमध्ये तपासते: गणनासाठी कोणतेही ट्रिगर आहेत की नाही - त्यांची गणना करते;
  जर असेल तर - कॉन्फिगरेशननुसार आवश्यक असल्यास इव्हेंट तयार करते, अॅलर्ट तयार करण्यासाठी एस्केलेशन तयार करते;
• त्यानंतरच्या प्रक्रियेसाठी रेकॉर्ड ट्रिगर, एकत्रीकरण; जर तुम्ही शेवटचा तास वगैरे एकत्रित केले तर, हे मूल्य व्हॅल्यूकॅचेद्वारे लक्षात ठेवले जाते जेणेकरून इतिहास सारणीवर जाऊ नये; अशा प्रकारे, ValueCache आवश्यक डेटाने भरलेले आहे जे ट्रिगर्स, गणना केलेले घटक इत्यादींची गणना करण्यासाठी आवश्यक आहे;
• नंतर इतिहास समक्रमण डेटाबेसवर सर्व डेटा लिहितो;
• डेटाबेस त्यांना डिस्कवर लिहितो - येथे प्रक्रिया प्रक्रिया समाप्त होते.

डेटाबेस. कॅशिंग

डेटाबेसच्या बाजूला, जेव्हा तुम्हाला इव्हेंट्सवरील आलेख किंवा काही अहवाल पहायचे असतील, तेव्हा विविध कॅशे असतात. पण या अहवालात मी त्यांच्याबद्दल बोलणार नाही.

MySQL साठी Innodb_buffer_pool आहे, आणि विविध कॅशेचा एक समूह आहे जो कॉन्फिगर देखील केला जाऊ शकतो.
परंतु हे मुख्य आहेत:

• सामायिक_बफर्स;
• प्रभावी_कॅशे_आकार;
• सामायिक_पूल.

सर्व डेटाबेससाठी, मी असे म्हटले आहे की काही कॅशे आहेत जे आपल्याला RAM मध्ये डेटा संग्रहित करण्यास अनुमती देतात जे सहसा क्वेरीसाठी आवश्यक असतात. यासाठी त्यांच्याकडे स्वतःचे तंत्रज्ञान आहे.

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

त्यानुसार, स्पर्धात्मक वातावरण आहे, म्हणजे, Zabbix सर्व्हर डेटा गोळा करतो आणि तो रेकॉर्ड करतो. रीस्टार्ट केल्यावर, ValueCache वगैरे भरण्यासाठी ते इतिहासातून देखील वाचते. येथे तुमच्याकडे वेब इंटरफेसवर तयार केलेल्या Zabbix API वापरणाऱ्या स्क्रिप्ट आणि अहवाल असू शकतात. Zabbix API डेटाबेसमध्ये प्रवेश करते आणि आलेख, अहवाल किंवा काही प्रकारच्या घटनांची यादी, अलीकडील समस्या मिळविण्यासाठी आवश्यक डेटा प्राप्त करते.

तसेच एक अतिशय लोकप्रिय व्हिज्युअलायझेशन सोल्यूशन Grafana आहे, जे आमचे वापरकर्ते वापरतात. Zabbix API द्वारे आणि डेटाबेसद्वारे दोन्ही थेट लॉग इन करण्यास सक्षम. हे डेटा मिळविण्यासाठी एक विशिष्ट स्पर्धा देखील तयार करते: परिणाम आणि चाचणीच्या जलद वितरणाचे पालन करण्यासाठी डेटाबेसचे एक उत्कृष्ट, चांगले ट्यूनिंग आवश्यक आहे.

इतिहास साफ करत आहे. Zabbix कडे हाऊसकीपर आहे

Zabbix मध्ये वापरलेला तिसरा कॉल हाऊसकीपर वापरून इतिहास साफ करत आहे. हाऊसकीपर सर्व सेटिंग्ज फॉलो करतो, म्हणजेच आमचे डेटा घटक किती काळ (दिवसांमध्ये), ट्रेंड किती काळ साठवायचे आणि बदलांची गतिशीलता दर्शवतात.

मी TrendCache बद्दल बोललो नाही, ज्याची आम्ही फ्लायवर गणना करतो: डेटा येतो, आम्ही तो एका तासासाठी एकत्रित करतो (बहुतेक हे शेवटच्या तासासाठीचे आकडे असतात), रक्कम सरासरी/किमान असते आणि आम्ही ते तासातून एकदा रेकॉर्ड करतो. बदलांच्या गतिशीलतेची सारणी ("ट्रेंड") . "घरगुती" नियमित निवडींचा वापर करून डेटाबेसमधून डेटा सुरू करतो आणि हटवतो, जे नेहमीच प्रभावी नसते.

ते कुचकामी आहे हे कसे समजून घ्यावे? अंतर्गत प्रक्रियांच्या कामगिरीच्या आलेखांवर तुम्ही खालील चित्र पाहू शकता:

तुमचा इतिहास समक्रमण सतत व्यस्त असतो (लाल आलेख). आणि वर जाणारा “लाल” आलेख. हा एक "हाउसकीपर" आहे जो डेटाबेसने निर्दिष्ट केलेल्या सर्व पंक्ती हटवण्यासाठी सुरू होतो आणि प्रतीक्षा करतो.

चला काही आयटम आयडी घेऊ: तुम्हाला शेवटचे 5 हजार हटविणे आवश्यक आहे; अर्थात, निर्देशांकानुसार. परंतु सामान्यतः डेटासेट खूप मोठा असतो - डेटाबेस अजूनही डिस्कमधून वाचतो आणि कॅशेमध्ये ठेवतो आणि डेटाबेससाठी हे खूप महाग ऑपरेशन आहे. त्याच्या आकारानुसार, यामुळे काही कार्यप्रदर्शन समस्या उद्भवू शकतात.

तुम्ही हाऊसकीपरला सोप्या पद्धतीने अक्षम करू शकता - आमच्याकडे एक परिचित वेब इंटरफेस आहे. प्रशासनाच्या सामान्य सेटिंग्ज ("घरगुती" साठी सेटिंग्ज) आम्ही अंतर्गत इतिहास आणि ट्रेंडसाठी अंतर्गत घरकाम अक्षम करतो. त्यानुसार, हाऊसकीपर यापुढे यावर नियंत्रण ठेवणार नाही:

आपण पुढे काय करू शकता? तुम्ही ते बंद केले, तुमचे आलेख समतल झाले आहेत... या प्रकरणात आणखी कोणत्या समस्या उद्भवू शकतात? काय मदत करू शकते?

विभाजन (विभाग करणे)

सामान्यत: मी सूचीबद्ध केलेल्या प्रत्येक रिलेशनल डेटाबेसवर हे वेगळ्या प्रकारे कॉन्फिगर केले जाते. MySQL चे स्वतःचे तंत्रज्ञान आहे. परंतु पोस्टग्रेएसक्यूएल 10 आणि मायएसक्यूएलच्या बाबतीत ते एकंदरीत समान आहेत. अर्थात, हे सर्व कसे अंमलात आणले जाते आणि ते सर्व कार्यक्षमतेवर कसे परिणाम करते यामध्‍ये बरेच अंतर्गत फरक आहेत. परंतु सर्वसाधारणपणे, नवीन विभाजनाच्या निर्मितीमुळे देखील काही समस्या उद्भवतात.

तुमच्या सेटअपवर अवलंबून (तुम्ही एका दिवसात किती डेटा तयार करता), ते सहसा किमान सेट करतात - हे 1 दिवस / बॅच आहे आणि "ट्रेंड" साठी, बदलांची गतिशीलता - 1 महिना / नवीन बॅच. तुमच्याकडे खूप मोठा सेटअप असल्यास हे बदलू शकते.

सेटअपच्या आकाराबद्दल लगेच सांगूया: प्रति सेकंद 5 हजार नवीन मूल्यांपर्यंत (तथाकथित एनव्हीपीएस) - हे एक लहान "सेटअप" मानले जाईल. सरासरी - प्रति सेकंद 5 ते 25 हजार मूल्यांपर्यंत. वर जे काही आहे ते आधीच मोठे आणि खूप मोठे इंस्टॉलेशन्स आहेत ज्यांना डेटाबेसचे अत्यंत काळजीपूर्वक कॉन्फिगरेशन आवश्यक आहे.

खूप मोठ्या स्थापनेवर, 1 दिवस इष्टतम असू शकत नाही. मी वैयक्तिकरित्या MySQL वर 40 गीगाबाइट्स प्रति दिन विभाजने पाहिली आहेत (आणि आणखी असू शकतात). हा डेटा खूप मोठा आहे, ज्यामुळे काही समस्या उद्भवू शकतात. ते कमी करणे आवश्यक आहे.

तुम्हाला विभाजनाची गरज का आहे?

विभाजन काय प्रदान करते, माझ्या मते प्रत्येकाला माहित आहे, ते टेबल विभाजन आहे. बहुतेकदा या डिस्क आणि स्पॅन विनंत्यांवर वेगळ्या फायली असतात. सामान्य विभाजनाचा भाग असल्यास ते एक विभाजन अधिक चांगल्या प्रकारे निवडते.

Zabbix साठी, विशेषतः, ते श्रेणीनुसार, श्रेणीनुसार वापरले जाते, म्हणजेच, आम्ही टाइमस्टॅम्प वापरतो (नियमित संख्या, युगाच्या सुरुवातीपासूनची वेळ). तुम्ही दिवसाची सुरुवात/दिवसाची समाप्ती निर्दिष्ट करता आणि हे विभाजन आहे. त्यानुसार, जर तुम्ही दोन दिवस जुना डेटा विचारत असाल तर, डेटाबेसमधून सर्वकाही जलद पुनर्प्राप्त केले जाईल, कारण तुम्हाला फक्त एक फाइल कॅशेमध्ये लोड करायची आहे आणि ती परत करायची आहे (मोठ्या टेबलऐवजी).

अनेक डेटाबेस इन्सर्ट (एका चाइल्ड टेबलमध्ये इन्सर्टेशन) गती वाढवतात. मी सध्या अमूर्तपणे बोलत आहे, परंतु हे देखील शक्य आहे. विभाजन अनेकदा मदत करते.

NoSQL साठी लवचिक शोध

अलीकडे, 3.4 मध्ये, आम्ही एक NoSQL उपाय लागू केला. Elasticsearch मध्ये लिहिण्याची क्षमता जोडली. तुम्ही विशिष्ट प्रकार लिहू शकता: तुम्ही निवडा - एकतर संख्या किंवा काही चिन्हे लिहा; आमच्याकडे स्ट्रिंग मजकूर आहे, तुम्ही Elasticsearch वर लॉग लिहू शकता... त्यानुसार, वेब इंटरफेस देखील Elasticsearch मध्ये प्रवेश करेल. हे काही प्रकरणांमध्ये चांगले कार्य करते, परंतु याक्षणी ते वापरले जाऊ शकते.

TimescaleDB. हायपरटेबल

4.4.2 साठी आम्ही TimescaleDB सारख्या एका गोष्टीकडे लक्ष दिले. हे काय आहे? हे PostgreSQL साठी एक विस्तार आहे, म्हणजेच त्याचा मूळ PostgreSQL इंटरफेस आहे. शिवाय, हा विस्तार तुम्हाला टाइमसिरीज डेटासह अधिक कार्यक्षमतेने कार्य करण्यास आणि स्वयंचलित विभाजन करण्यास अनुमती देतो. ते कसे दिसते:

हे हायपरटेबल आहे - टाइमस्केलमध्ये अशी संकल्पना आहे. हे तुम्ही तयार केलेले हायपरटेबल आहे आणि त्यात भाग आहेत. भाग म्हणजे विभाजने, ही मूल सारणी आहेत, जर माझी चूक नसेल. ते खरोखर प्रभावी आहे.

TimescaleDB आणि PostgreSQL

TimescaleDB निर्मात्यांनी खात्री दिल्याप्रमाणे, ते क्वेरीवर प्रक्रिया करण्यासाठी अधिक योग्य अल्गोरिदम वापरतात, विशिष्ट इन्सर्टमध्ये, जे त्यांना डेटासेट इन्सर्टच्या वाढत्या आकारासह अंदाजे स्थिर कार्यप्रदर्शन करण्यास अनुमती देते. म्हणजेच, पोस्टग्रेसच्या 200 दशलक्ष पंक्तींनंतर, नेहमीच्या पंक्ती खूप कमी होऊ लागतात आणि अक्षरशः शून्यावर कार्यप्रदर्शन गमावतात, तर टाइमस्केल आपल्याला डेटाच्या कोणत्याही प्रमाणात शक्य तितक्या कार्यक्षमतेने इन्सर्ट घालण्याची परवानगी देतो.

TimescaleDB कसे स्थापित करावे? हे सोपं आहे!

हे दस्तऐवजीकरणात आहे, त्याचे वर्णन केले आहे - तुम्ही ते कोणत्याही पॅकेजमधून स्थापित करू शकता... हे अधिकृत पोस्टग्रेस पॅकेजेसवर अवलंबून आहे. स्वहस्ते संकलित केले जाऊ शकते. असे झाले की मला डेटाबेससाठी संकलित करावे लागले.

Zabbix वर आम्ही फक्त Extention सक्रिय करतो. मला असे वाटते की ज्यांनी Postgres मध्ये Extention वापरले... तुम्ही फक्त Extention सक्रिय करा, तुम्ही वापरत असलेल्या Zabbix डेटाबेससाठी ते तयार करा.

आणि शेवटचा टप्पा...

TimescaleDB. इतिहास सारण्यांचे स्थलांतर

आपल्याला हायपरटेबल तयार करण्याची आवश्यकता आहे. यासाठी एक विशेष कार्य आहे - हायपरटेबल तयार करा. त्यामध्ये, प्रथम पॅरामीटर हे टेबल आहे जे या डेटाबेसमध्ये आवश्यक आहे (ज्यासाठी तुम्हाला हायपरटेबल तयार करणे आवश्यक आहे).

क्षेत्र ज्याद्वारे तयार करायचे आहे, आणि chunk_time_interval (हा भागांचा मध्यांतर आहे (जे विभाजने वापरणे आवश्यक आहे). 86 एक दिवस आहे.

माइग्रेट_डेटा पॅरामीटर: जर तुम्ही सत्यात समाविष्ट केले, तर हे सर्व वर्तमान डेटा पूर्व-निर्मित भागांमध्ये स्थलांतरित करेल.

मी स्वतः migrate_data वापरला आहे - तुमचा डेटाबेस किती मोठा आहे यावर अवलंबून याला बराच वेळ लागतो. माझ्याकडे टेराबाइटपेक्षा जास्त होते - ते तयार करण्यासाठी एका तासापेक्षा जास्त वेळ लागला. काही प्रकरणांमध्ये, चाचणी दरम्यान, मी मजकूर (history_text) आणि स्ट्रिंग (history_str) साठी ऐतिहासिक डेटा हटविला आहे जेणेकरून ते हस्तांतरित करू नये - ते माझ्यासाठी खरोखर मनोरंजक नव्हते.

आणि आम्ही आमच्या db_extention मध्ये शेवटचे अपडेट करतो: आम्ही timescaledb स्थापित करतो जेणेकरून डेटाबेस आणि विशेषतः आमच्या Zabbix ला समजेल की db_extention आहे. तो ते सक्रिय करतो आणि टाइमस्केलडीबीसाठी आवश्यक असलेली “वैशिष्ट्ये” वापरून डेटाबेसमध्ये योग्य वाक्यरचना आणि क्वेरी वापरतो.

सर्व्हर कॉन्फिगरेशन

मी दोन सर्व्हर वापरले. पहिला सर्व्हर एक बऱ्यापैकी लहान व्हर्च्युअल मशीन, 20 प्रोसेसर, 16 गीगाबाइट्स रॅम आहे. मी त्यावर पोस्टग्रेस 10.8 कॉन्फिगर केले:

ऑपरेटिंग सिस्टम डेबियन होती, फाइल सिस्टम xfs होती. मी हा विशिष्ट डेटाबेस वापरण्यासाठी किमान सेटिंग्ज केल्या आहेत, Zabbix स्वतः काय वापरेल. त्याच मशीनवर Zabbix सर्व्हर, PostgreSQL आणि लोड एजंट होते.

मी 50 सक्रिय एजंट वापरले आहेत जे विविध परिणाम द्रुतपणे व्युत्पन्न करण्यासाठी LoadableModule वापरतात. त्यांनीच स्ट्रिंग्स, संख्या इत्यादी निर्माण केल्या आहेत. मी डेटाबेसमध्ये भरपूर डेटा भरला. सुरुवातीला, कॉन्फिगरेशनमध्ये प्रत्येक होस्टसाठी 5 हजार डेटा घटक होते आणि अंदाजे प्रत्येक डेटा घटकामध्ये ट्रिगर होता - हे वास्तविक सेटअप होण्यासाठी. काहीवेळा आपल्याला वापरण्यासाठी एकापेक्षा जास्त ट्रिगर देखील आवश्यक असतात.

मी केवळ 50 एजंट्स (अधिक जोडणे) वापरूनच नव्हे तर डायनॅमिक डेटा घटकांचा वापर करून आणि अपडेट मध्यांतर 4 सेकंदांपर्यंत कमी करून अद्यतन अंतराल आणि लोड स्वतःच नियंत्रित केले.

कार्यक्षमता चाचणी. PostgreSQL: 36 हजार NVPs

या हार्डवेअरवर (प्रति सेकंद ३५ हजार मूल्ये) शुद्ध PostreSQL 10 वर माझ्याकडे पहिले प्रक्षेपण, पहिले सेटअप होते. सर्वसाधारणपणे, जसे आपण स्क्रीनवर पाहू शकता, डेटा घालण्यासाठी सेकंदाचा अपूर्णांक लागतो - सर्वकाही चांगले आणि वेगवान आहे, SSD ड्राइव्हस् (35 गीगाबाइट्स). फक्त एक गोष्ट अशी आहे की 200 जीबी खूप लवकर भरते.

भविष्यात असे बरेच आलेख असतील. हा एक मानक Zabbix सर्व्हर कामगिरी डॅशबोर्ड आहे.

पहिला आलेख प्रति सेकंद मूल्यांची संख्या आहे (निळा, वर डावीकडे), या प्रकरणात 35 हजार मूल्ये. हे (वरचे केंद्र) बिल्ड प्रक्रियेचे लोडिंग आहे, आणि हे (वर उजवीकडे) अंतर्गत प्रक्रियांचे लोडिंग आहे: हिस्ट्री सिंकर्स आणि हाऊसकीपर, जे येथे (खाली मध्यभागी) बर्याच काळापासून चालू आहे.

हा आलेख (तळाशी मध्यभागी) ValueCache चा वापर दर्शवतो - ट्रिगर्ससाठी किती ValueCache हिट होतात (प्रति सेकंद अनेक हजार मूल्ये). दुसरा महत्त्वाचा आलेख हा चौथा (खाली डावीकडे) आहे, जो हिस्ट्री कॅशेचा वापर दर्शवतो, ज्याबद्दल मी बोललो, जो डेटाबेसमध्ये टाकण्यापूर्वी बफर आहे.

कार्यक्षमता चाचणी. PostgreSQL: 50 हजार NVPs

पुढे, मी त्याच हार्डवेअरवर लोड 50 हजार व्हॅल्यू प्रति सेकंदापर्यंत वाढवले. हाऊसकीपरने लोड केल्यावर, गणनेसह 10-2 सेकंदात 3 हजार मूल्ये रेकॉर्ड केली गेली. काय, खरं तर, खालील स्क्रीनशॉटमध्ये दर्शविले आहे:

"हाउसकीपर" आधीच कामात व्यत्यय आणू लागला आहे, परंतु सर्वसाधारणपणे, इतिहास-सिंकर ट्रॅपर्सवरील भार अजूनही 60% (तिसरा आलेख, वर उजवीकडे) आहे. हाऊसकीपर चालू असताना (खाली डावीकडे) हिस्ट्री कॅशे आधीच सक्रियपणे भरण्यास सुरुवात होते. ते सुमारे अर्धा गीगाबाइट होते, 20% भरले होते.

कार्यक्षमता चाचणी. PostgreSQL: 80 हजार NVPs

मग मी ते प्रति सेकंद 80 हजार मूल्यांपर्यंत वाढवले:

हे अंदाजे 400 हजार डेटा घटक, 280 हजार ट्रिगर होते. इन्सर्ट, जसे आपण पाहू शकता, इतिहास बुडविणार्‍यांच्या लोडच्या दृष्टीने (त्यापैकी 30 होते) आधीच बरेच जास्त होते. मग मी विविध पॅरामीटर्स वाढवले: हिस्ट्री सिंकर्स, कॅशे... या हार्डवेअरवर, हिस्ट्री सिंकर्सवरील भार जास्तीत जास्त वाढू लागला, जवळजवळ "शेल्फवर" - त्यानुसार, हिस्ट्री कॅशे खूप जास्त लोडमध्ये गेला:

या सर्व वेळी मी सर्व सिस्टम पॅरामीटर्सचे निरीक्षण केले (प्रोसेसर कसा वापरला जातो, रॅम) आणि डिस्कचा वापर जास्तीत जास्त असल्याचे आढळले - मी या हार्डवेअरवर, या आभासी मशीनवर या डिस्कची कमाल क्षमता प्राप्त केली. "पोस्टग्रेस" ने अशा तीव्रतेने सक्रियपणे डेटा डंप करण्यास सुरुवात केली आणि डिस्कला यापुढे लिहिण्यास, वाचण्यास वेळ मिळाला नाही ...

मी दुसरा सर्व्हर घेतला ज्यात आधीपासून 48 प्रोसेसर आणि 128 गीगाबाइट्स RAM आहेत:

मी ते "ट्यून" देखील केले - इतिहास समक्रमण स्थापित केले (60 तुकडे) आणि स्वीकार्य कामगिरी प्राप्त केली. खरं तर, आम्ही "शेल्फवर" नाही, परंतु कदाचित ही उत्पादकतेची मर्यादा आहे, जिथे याबद्दल काहीतरी करणे आधीच आवश्यक आहे.

कार्यक्षमता चाचणी. TimescaleDB: 80 हजार NVPs

माझे मुख्य कार्य TimescaleDB वापरणे होते. प्रत्येक आलेख डिप दाखवतो:

हे अपयश अचूकपणे डेटा माइग्रेशन आहेत. त्यानंतर, Zabbix सर्व्हरमध्ये, इतिहास सिंकर्सचे लोडिंग प्रोफाइल, जसे आपण पाहू शकता, बरेच बदलले. हे तुम्हाला जवळपास 3 पट वेगाने डेटा घालण्याची आणि कमी हिस्ट्री कॅशे वापरण्याची परवानगी देते - त्यानुसार, तुमच्याकडे वेळेवर डेटा वितरित केला जाईल. पुन्हा, प्रति सेकंद 80 हजार मूल्ये हा बर्‍यापैकी उच्च दर आहे (अर्थात, यांडेक्ससाठी नाही). एकंदरीत हे एका सर्व्हरसह बऱ्यापैकी मोठे सेटअप आहे.

PostgreSQL कामगिरी चाचणी: 120 हजार NVPs

पुढे, मी डेटा घटकांच्या संख्येचे मूल्य अर्धा दशलक्ष पर्यंत वाढविले आणि प्रति सेकंद 125 हजार गणना केलेले मूल्य प्राप्त केले:

आणि मला हे आलेख मिळाले:

तत्वतः, हा एक कार्यरत सेटअप आहे, तो बराच काळ कार्य करू शकतो. पण माझ्याकडे फक्त १.५ टेराबाइट डिस्क असल्याने, मी ती काही दिवसात वापरली. सर्वात महत्वाची गोष्ट अशी आहे की त्याच वेळी TimescaleDB वर नवीन विभाजने तयार केली गेली होती, आणि हे कार्यक्षमतेसाठी पूर्णपणे दुर्लक्षित होते, जे MySQL बद्दल सांगितले जाऊ शकत नाही.

सामान्यतः, रात्रीच्या वेळी विभाजने तयार केली जातात, कारण हे साधारणपणे समाविष्ट करणे आणि टेबलसह कार्य करणे अवरोधित करते आणि सेवेचे ऱ्हास होऊ शकते. या प्रकरणात असे नाही! TimescaleDB च्या क्षमतांची चाचणी घेणे हे मुख्य कार्य होते. परिणाम खालील आकृती होता: प्रति सेकंद 120 हजार मूल्ये.

समाजात अशी उदाहरणे देखील आहेत:

व्यक्तीने TimescaleDB देखील चालू केले आणि प्रोसेसरवर io.weight वापरण्याचा भार कमी झाला; आणि TimescaleDB च्या समावेशामुळे अंतर्गत प्रक्रिया घटकांचा वापर देखील कमी झाला आहे. शिवाय, या सामान्य पॅनकेक डिस्क्स आहेत, म्हणजे, सामान्य डिस्कवरील एक सामान्य आभासी मशीन (एसएसडी नाही)!

डिस्क कार्यप्रदर्शनाद्वारे मर्यादित असलेल्या काही लहान सेटअपसाठी, TimescaleDB, माझ्या मते, हा एक चांगला उपाय आहे. हे तुम्हाला डेटाबेससाठी जलद हार्डवेअरवर स्थलांतरित करण्यापूर्वी काम सुरू ठेवण्यास अनुमती देईल.

मी तुम्हा सर्वांना आमच्या कार्यक्रमांसाठी आमंत्रित करतो: मॉस्कोमधील परिषद, रीगा येथे शिखर परिषद. आमचे चॅनेल वापरा - टेलिग्राम, फोरम, IRC. आपल्याकडे काही प्रश्न असल्यास, आमच्या डेस्कवर या, आम्ही प्रत्येक गोष्टीबद्दल बोलू शकतो.

प्रेक्षकांचे प्रश्न

श्रोत्यांकडून प्रश्न (यापुढे - अ):- जर TimescaleDB कॉन्फिगर करणे इतके सोपे असेल आणि त्यामुळे अशा कामगिरीला चालना मिळते, तर कदाचित पोस्टग्रेससह Zabbix कॉन्फिगर करण्यासाठी हा सर्वोत्तम सराव म्हणून वापरला जावा? आणि या सोल्यूशनचे काही तोटे आणि तोटे आहेत का, किंवा शेवटी, जर मी स्वतःसाठी Zabbix बनवायचे ठरवले असेल, तर मी सहजपणे Postgres घेऊ शकतो, तिथे लगेच Timescale स्थापित करू शकतो, ते वापरू शकतो आणि कोणत्याही समस्यांबद्दल विचार करू शकत नाही?

AG: - होय, मी म्हणेन की ही एक चांगली शिफारस आहे: TimescaleDB विस्तारासह त्वरित Postgres वापरा. मी आधीच म्हटल्याप्रमाणे, हे “वैशिष्ट्य” प्रायोगिक असूनही बरीच चांगली पुनरावलोकने आहेत. पण प्रत्यक्षात चाचण्या दाखवतात की हा एक उत्तम उपाय आहे (TimescaleDB सह) आणि मला वाटते की ते विकसित होईल! आम्ही हा विस्तार कसा विकसित होतो याचे निरीक्षण करत आहोत आणि आवश्यकतेनुसार बदल करू.

विकासादरम्यानही, आम्ही त्यांच्या एका सुप्रसिद्ध "वैशिष्ट्यांवर" विसंबून राहिलो: भागांसह थोड्या वेगळ्या पद्धतीने कार्य करणे शक्य होते. पण नंतर त्यांनी पुढच्या रिलीझमध्ये ते कापले आणि आम्हाला या कोडवर अवलंबून राहणे थांबवावे लागले. मी हे उपाय अनेक सेटअपवर वापरण्याची शिफारस करतो. तुम्ही MySQL वापरत असल्यास... सरासरी सेटअपसाठी, कोणतेही समाधान चांगले कार्य करते.

उत्तरः - समुदायातील शेवटच्या आलेखांवर, "घरची सेवक" असलेला आलेख होता:

तो काम करत राहिला. TimescaleDB सह हाउसकीपर काय करतो?

AG: - आता मी निश्चितपणे सांगू शकत नाही - मी कोड पाहीन आणि तुम्हाला अधिक तपशीलवार सांगेन. हे टाइमस्केलडीबी क्वेरीचा वापर भाग हटवण्यासाठी नाही, तर त्यांना एकत्रित करण्यासाठी करते. मी अद्याप या तांत्रिक प्रश्नाचे उत्तर द्यायला तयार नाही. आम्ही आज किंवा उद्या स्टँडवर अधिक शोधू.

उत्तरः – मला असाच प्रश्न आहे – Timescale मधील डिलीट ऑपरेशनच्या कामगिरीबद्दल.
A (प्रेक्षकांकडून उत्तर): – जेव्हा तुम्ही टेबलमधून डेटा हटवता, जर तुम्ही तो डिलीट द्वारे केला असेल, तर तुम्हाला टेबलमधून जावे लागेल - भविष्यातील व्हॅक्यूमसाठी सर्वकाही हटवा, साफ करा, चिन्हांकित करा. टाइमस्केलमध्ये, तुमच्याकडे तुकडे असल्याने, तुम्ही ड्रॉप करू शकता. साधारणपणे सांगायचे तर, तुम्ही मोठ्या डेटामध्ये असलेल्या फाइलला फक्त सांगा: "हटवा!"

टाईमस्केल फक्त समजते की असा भाग यापुढे अस्तित्वात नाही. आणि ते क्वेरी प्लॅनरमध्ये समाकलित केल्यामुळे, ते निवडक किंवा इतर ऑपरेशन्समध्ये तुमच्या अटी पकडण्यासाठी हुक वापरते आणि लगेच समजते की हा भाग यापुढे अस्तित्वात नाही - "मी आता तिथे जाणार नाही!" (डेटा उपलब्ध नाही). इतकंच! म्हणजेच, टेबल स्कॅन बायनरी फाइल हटवण्याने बदलले आहे, त्यामुळे ते जलद आहे.

उत्तरः - आम्ही यापूर्वीच नॉन-एसक्यूएल विषयाला स्पर्श केला आहे. जोपर्यंत मला समजले आहे, Zabbix ला खरोखर डेटा सुधारण्याची आवश्यकता नाही आणि हे सर्व लॉग सारखे आहे. विशेष डेटाबेस वापरणे शक्य आहे जे त्यांचा डेटा बदलू शकत नाहीत, परंतु त्याच वेळी जतन, संचयित आणि जलद वितरण - क्लिकहाऊस, उदाहरणार्थ, काफ्कासारखे काहीतरी?.. काफ्का देखील एक लॉग आहे! ते कसे तरी समाकलित करणे शक्य आहे का?

AG: - अनलोडिंग करता येते. आवृत्ती ३.४ पासून आमच्याकडे एक विशिष्ट "वैशिष्ट्य" आहे: तुम्ही सर्व ऐतिहासिक फाइल्स, इव्हेंट्स, इतर सर्व काही फाइल्सवर लिहू शकता; आणि नंतर काही हँडलर वापरून इतर कोणत्याही डेटाबेसवर पाठवा. खरं तर, बरेच लोक पुन्हा काम करतात आणि थेट डेटाबेसवर लिहितात. जाताना, हिस्ट्री सिंकर्स हे सर्व फायलींमध्ये लिहितात, या फायली फिरवतात, आणि असेच, आणि तुम्ही हे क्लिकहाऊसमध्ये हस्तांतरित करू शकता. मी योजनांबद्दल सांगू शकत नाही, परंतु कदाचित NoSQL सोल्यूशन्ससाठी पुढील समर्थन (जसे की क्लिकहाऊस) सुरू राहील.

उत्तरः - सर्वसाधारणपणे, असे दिसून आले की आपण पोस्टग्रेसपासून पूर्णपणे मुक्त होऊ शकता?

AG: - नक्कीच, Zabbix मधील सर्वात कठीण भाग म्हणजे ऐतिहासिक तक्ते, जे सर्वात जास्त समस्या आणि घटना निर्माण करतात. या प्रकरणात, आपण बर्याच काळासाठी इव्हेंट संचयित न केल्यास आणि इतर काही वेगवान स्टोरेजमध्ये ट्रेंडसह इतिहास संचयित केल्यास, सर्वसाधारणपणे, मला वाटते, कोणतीही समस्या येणार नाही.

उत्तरः - उदाहरणार्थ, क्लिकहाऊसवर स्विच केल्यास सर्वकाही किती वेगाने कार्य करेल याचा अंदाज लावू शकता का?

AG: - मी त्याची चाचणी केली नाही. मला वाटते की क्लिकहाऊसचा स्वतःचा इंटरफेस आहे हे लक्षात घेऊन किमान समान संख्या अगदी सोप्या पद्धतीने मिळवता येतात, परंतु मी निश्चितपणे सांगू शकत नाही. चाचणी करणे चांगले आहे. हे सर्व कॉन्फिगरेशनवर अवलंबून असते: आपल्याकडे किती होस्ट आहेत आणि असेच. घालणे ही एक गोष्ट आहे, परंतु आपल्याला हा डेटा पुनर्प्राप्त करणे देखील आवश्यक आहे - ग्राफना किंवा दुसरे काहीतरी.

उत्तरः - तर आम्ही समान लढ्याबद्दल बोलत आहोत, आणि या वेगवान डेटाबेसच्या मोठ्या फायद्याबद्दल नाही?

AG: - मला वाटते जेव्हा आम्ही समाकलित करतो, तेव्हा अधिक अचूक चाचण्या होतील.

उत्तरः - चांगले जुने आरआरडी कुठे गेले? तुम्ही SQL डेटाबेसेसवर कशामुळे स्विच केले? सुरुवातीला, सर्व मेट्रिक्स RRD वर गोळा केले गेले.

AG: - Zabbix कडे RRD होते, कदाचित खूप प्राचीन आवृत्तीत. एसक्यूएल डेटाबेस नेहमीच असतात - एक उत्कृष्ट दृष्टीकोन. क्लासिक दृष्टीकोन म्हणजे MySQL, PostgreSQL (ते बर्याच काळापासून अस्तित्वात आहेत). आम्ही SQL आणि RRD डेटाबेससाठी सामान्य इंटरफेस जवळजवळ कधीच वापरला नाही.

काही जाहिराती 🙂

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

डेल R730xd ऍमस्टरडॅममधील इक्विनिक्स टियर IV डेटा सेंटरमध्ये 2 पट स्वस्त? फक्त इथेच 2 x इंटेल टेट्राडेका-कोर Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीव्ही $199 पासून नेदरलँड मध्ये! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 पासून! बद्दल वाचा इन्फ्रास्ट्रक्चर कॉर्पोरेशन कसे तयार करावे. डेल R730xd E5-2650 v4 सर्व्हरचा वापर करून 9000 युरो किमतीचा वर्ग?

स्त्रोत: www.habr.com