प्रोमेथियस मेट्रिक्स का लंबे समय तक भंडारण (एलेक्सी पलाज़ेन्को, पर्कोना)

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

बस इस बारे में, रूटकॉनफ 2018 में एलेक्सी पलाज़ेन्को द्वारा रिपोर्ट का डिकोडिंग। रिपोर्ट में: प्रोमेथियस, लोकल स्टोरेज टीएसडीबी, रिमोट स्टोरेज प्रोमेथियस, प्रोमसेल, टीएसडीबी, क्लिकहाउस, प्रोमिथहाउस, थोड़ा इन्फ्लूएंबीडी।

कौन परवाह करता है, कृपया, बिल्ली के नीचे।

दोस्तो! सभी को नमस्कार! मेरा नाम एलेक्सी पलाज़ेन्को है। मैं पेरकोना में काम करता हूं। मैं आपको प्रोमेथियस में मीट्रिक के दीर्घकालिक भंडारण के बारे में बताना चाहूंगा।

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

यह समझना महत्वपूर्ण है कि ये सास नहीं हैं। हमारे पास उत्पादन नहीं है। हमारे उत्पादन हमारे ग्राहकों के साथ स्थित है। इस पर प्रयोग करना बहुत अच्छा नहीं है। हमारे पास सबसे करीबी चीज है जिसे उत्पादन कहा जा सकता है - यह https://pmmdemo.percona.com/ है । रिपोर्ट के समय, GDPR के कारण pmmdemo.percona.com को बंद करना पड़ा।

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

प्रोमेथियस की कुछ चीजें बहुत शांत हैं।

• प्रोमेथियस क्वेरी भाषा वास्तव में एक अच्छी बात है जिसका कहीं भी कोई एनालॉग नहीं है।

  
  

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

  
  

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

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

प्रोमेथियस में मैट्रिक्स कैसे संग्रहीत होते हैं? स्थानीय भंडारण है। रिमोट स्टोरेज है। ये वास्तव में दो अलग-अलग दुनिया हैं। वे कमजोर पड़ते हैं। इसलिए, रिपोर्ट को भी 2 भागों में विभाजित किया गया है।

यदि आप मुख्य हॉल में पिछली रिपोर्ट में थे, जहां प्रोमेथियस में एक अच्छा परिचय था, तो आप जानते हैं कि स्थानीय भंडारण TSDB नामक एक अलग पुस्तकालय है। TSDB का OpenTSDB से कोई लेना-देना नहीं है। TSDB एक अलग Go पैकेज है जिसे आप अपने Go प्रोग्राम से उपयोग कर सकते हैं। TSDB लाइब्रेरी स्तर पर, कोई क्लाइंट या सर्वर नहीं है।

यह लाइब्रेरी समय श्रृंखला डेटा के साथ काम करने के लिए अनुकूलित है। उदाहरण के लिए, TSDB में डेल्टा एन्कोडिंग है, जो आपको संख्याओं को स्वयं संग्रहीत करने की अनुमति नहीं देता है, लेकिन इन संख्याओं के बीच परिवर्तन। यह आपको 16 बाइट्स के बजाय 1 बाइट स्टोर करने की अनुमति देता है। समय के लिए 1 बाइट और मूल्य के लिए 1 बाइट। यही है, आप इस अच्छे संपीड़न के कारण औसतन 1 या 2 बाइट्स को स्टोर करते हैं।

TSDB पुल मॉडल के लिए अनुकूलित है। डेटा केवल वहां जोड़ा जाता है। प्रोमेथियस ऐतिहासिक डेटा नहीं लिख सकता है। इसके लिए कोई एपीआई नहीं है। अधिकतम डेल्टा लगभग 5 मिनट है। यदि डेटा पुराना है, तो इसे स्वीकार नहीं किया जाएगा।

TSDB में कोई अंतर्निहित डाउनसमलिंग tsdb # 313 नहीं है। एक खुला मुद्दा है जिसमें इस तथ्य के बारे में चर्चा थी कि सामान्य तौर पर ऐसी परियोजनाएं हैं जो प्रोमेथियस को कुछ करती हैं और वहां डाउनसमलिंग होती है। अब तक, समाधान यह है कि TSDB डाउनसमलिंग को नहीं जोड़ेगा।

हमें TSDB से डेटा कैसे मिलेगा? TSDB डिस्क पर एक डेटाबेस है। यदि आप एक गो कार्यक्रम लिख रहे हैं तो आप इसके साथ काम कर सकते हैं। लेकिन यदि आप Go में कोई प्रोग्राम नहीं लिखते हैं, तो एक JSON API है जो आपको क्वेरी क्वेरी बनाने की अनुमति देता है। यदि आपने कभी प्रोमेथियस का उपयोग किया है और कम से कम एक बार एक चार्ट बनाया है, तो आप मानक क्वेरी एपीआई को जानते हैं, जिसमें एक क्वेरी पैरामीटर है जिसमें आप किसी भी प्रोमसेल क्वेरी और वैकल्पिक रूप से समय का निष्पादन कर सकते हैं। यदि कोई समय नहीं है, तो वर्तमान समय लिया जाता है।

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

दूसरी क्वेरी query_range है, जो समान कार्य करती है, लेकिन आपको डेटा को एक सीमा में और कुछ चरण के साथ लौटाती है। यह अनिवार्य रूप से शुरुआत से अंत तक प्रत्येक चरण के लिए कई बार एक प्रश्न बनाता है। यह ग्राफिक्स बनाने के लिए उपयोग किया जाने वाला एपीआई है। पहला API तुरंत मान प्राप्त करने के लिए उपयोग करता है।

मेटाडेटा प्राप्त करने के लिए हमारे पास एक एपीआई है। यदि हम मैट्रिक्स के सभी नाम प्राप्त करना चाहते हैं, तो हम इस तरह से एक क्वेरी बनाते हैं, जहाँ मिलान मैट्रिक्स का एक सरणी है। कई तर्क हो सकते हैं, लेकिन इस मामले में हम उसी मैच को पास करते हैं, जो सब कुछ हमारे पास लौटता है।

दूसरा मेटा एपीआई, जो हमें सभी लेबल का मान लौटाता है। यदि हम सभी नौकरियों की सूची देखना चाहते हैं, तो label_name के बजाय हम नौकरी लिखते हैं और यह सूची प्राप्त करते हैं। ये एपीआई हमें JSON लौटाते हैं।

एक और एपीआई है जो प्रोमेथियस के सभी मेट्रिक्स को एक ऐसे प्रारूप में लौटाता है जो निर्यातकों का मूल है। प्रारूप को expfmt कहा जाता है। प्रोमेथियस में ही, एक फेडरेशन एपीआई है जो आपको ऐसा अनुरोध करने की अनुमति देता है। यह किस लिए है? सबसे आसान विकल्प, यदि आपके पास कुछ कोड है जो पहले से ही एक्सपर्ट के साथ काम करता है, तो आपको कुछ कस्टम JSON API के साथ काम करने के लिए इसे वापस लेने की आवश्यकता नहीं है। इस प्रारूप को स्ट्रीम करना बहुत आसान है, क्योंकि यदि आपके पास ऑब्जेक्ट के शीर्ष स्तर पर कहीं JSON है, तो अक्सर आपको इस ऑब्जेक्ट को समग्र रूप से पार्स करने की आवश्यकता होती है। यहां इसे लाइन से लाइन किया जा सकता है।

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

इसका उपयोग कैसे किया जा सकता है?

सबसे पहले, सबसे महत्वपूर्ण बात यह है कि आपको ऐसा करने की आवश्यकता नहीं है। TSDB विभिन्न ऑपरेटिंग मोड के लिए अनुकूलित है। यदि आपके पास एक प्रोमेथियस है जो बहुत सारे डेटा को स्क्रैप करता है, तो यह बहुत सारे I / O करता है। यदि आप फेडरेशन एपीआई का उपयोग करते हैं, तो इनपुट आउटपुट की मात्रा लगभग 2 गुना बढ़ जाएगी। बारीकियां हैं। आप कितनी बार फेडरेट पर परिमार्जन करते हैं और कितनी बार आप लक्ष्यों को परिमार्जन करते हैं। यदि समय नहीं बदला गया है, तो यह वास्तव में भार को दोगुना कर देता है। इसलिए, यदि आप अपने प्रोमेथियस को स्केल करना चाहते हैं और फेडरेशन को सक्षम करना चाहते हैं, तो आप इसे मार देंगे। लोड दोगुना हो जाएगा।

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

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

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

हम इन चीजों के इस संयोजन का उपयोग कैसे डाउनसमलिंग और लंबी अवधि के भंडारण के लिए कर सकते हैं।

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

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

यदि हमारे पास ग्रेफाना है और कई प्रोमेथियस हैं, तो हमें यह जानना होगा कि किस प्रोमेथियस को अनुरोध भेजना है। हम यह कैसे करेंगे?

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

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

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

हम रिमोट स्टोरेज से गुजरते हैं। क्या किसी ने प्रोमेथियस में रिमोट स्टोरेज के साथ काम किया है? कुछ हाथ। रिमोट स्टोरेज एक एपीआई है जो लंबे समय से आसपास है। अब संस्करण 2.2 में रिमोट स्टोरेज - प्रयोगात्मक के रूप में चिह्नित किया गया है। इसके अलावा, यह ज्ञात है कि रिमोट स्टोरेज एपीआई निश्चित रूप से बदल जाएगा।

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

मेटाडेटा के लिए अभी तक कोई एपीआई नहीं। आप एक ऐसी एपीआई नहीं बना सकते जो रिमोट स्टोरेज से ऑल टाइम सीरीज लौटाए। यदि आप प्रोमेथियस एपीआई के लिए अनुरोध करते हैं, तो यह रिमोट स्टोरेज पर नहीं जाएगा। यह आपको समय श्रृंखला लौटाएगा, जो इसके स्थानीय डेटाबेस में है। यदि आपका स्थानीय डेटाबेस अक्षम है, तो यह आपको 0. लौटा देगा जो कि थोड़ा अप्रत्याशित हो सकता है। अब यह API ProtoBuf का उपयोग करता है और भविष्य में इसे निश्चित रूप से gRPC में बदल दिया जाएगा। उन्होंने अभी तक ऐसा नहीं किया है, क्योंकि gRPC को HTTP2 की आवश्यकता है। और व्यवहार में उन्हें उससे समस्या थी।

राइट एपीआई इस तरह दिखता है। अनुरोध में लेबल का एक सेट है। लेबल्स का सेट विशिष्ट रूप से समय श्रृंखला की पहचान करता है। __name__ वास्तव में एक विशेष नाम वाला एक लेबल है। और नमूने समय और मूल्यों का एक सेट हैं - int64 और float64। रिकॉर्डिंग करते समय, आदेश महत्वहीन है। यह माना जाता है कि डेटाबेस जो इसे स्वयं लिखता है वह सब कुछ ठीक करेगा। प्रोमेथियस कुछ अनुकूलन कर सकता है और इसे फिर से छाँट नहीं सकता है। तदनुसार, एक लिखित अनुरोध केवल कुछ समय श्रृंखला है।

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

रिमोट रीड एपीआई इस तरह दिखता है। यह शुरू से अंत तक एक समय सीमा है और एक मैच सेट है।

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

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

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

पढ़ने का विन्यास क्या है?

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

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

पुराने ऐतिहासिक डेटा को रिमोट स्टोरेज से पढ़ा जाएगा। यह स्पष्ट करता है कि स्थानीय संग्रहण और दूरस्थ संग्रहण एक दूसरे के साथ कैसे संवाद करते हैं। कोई समर्पण नहीं है।

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

दिलचस्प है, प्रोमेथियस द्वारा संस्करण 1.8 के बाद से रिमोट रीड लागू किया गया है। यह वह तरीका है जो आपको पुराने प्रोमेथियस के डेटा को पढ़ने की अनुमति देता है जब आप संस्करण 2.x पर माइग्रेट करते हैं। आधिकारिक तरीका इसे रिमोट रीड के रूप में जोड़ने की सलाह देता है। आवश्यकतानुसार डाटा घटाया जाएगा।

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

क्लिकहाउस क्यों?

• हमारे शोध समाधान के लिए, हमने ClickHouse को चुना, क्योंकि हम लंबे समय से इसे देख रहे हैं। हमारे पास ऐसे लोग हैं जो लगातार डेटाबेस प्रदर्शन में लगे हुए हैं, लगातार नए डेटाबेस की जाँच कर रहे हैं। हमारी कंपनी ओपनसोर्स डेटाबेस में लगी हुई है।

  
  

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

  
  

• अंतर्निहित प्रतिकृति, पैनापन।

  
  

• ग्रेफाइटमार्टट्री ग्रेफाइट डेटा संग्रहीत करने के लिए एक विशेष इंजन है। पहले तो वह हम में बहुत दिलचस्पी रखते थे।

  
  

इंजन ग्रेफाइट डेटा के रोलअप (थिनिंग और एग्रीगेशन / एवरेज) के लिए अभिप्रेत है।

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

मैं रिपोर्ट के लिए महीने की शुरुआत में तैयारी कर रहा था। कोई व्यक्ति टेलीग्राम चैट में आता है और पूछता है - "ग्रेफाइटमेजरट्री डेटा डाउनसम्प्ल"? मैं पहले से ही नहीं लिखता हूं। दस्तावेज कहते हैं, नहीं। लेकिन चैट का दूसरा व्यक्ति जवाब देता है "हां, आपको कॉल करने की आवश्यकता है।" भागो, जाँच करो - हाँ सच। प्रलेखन अनिवार्य रूप से एक बग है। फिर मैंने स्रोत कोड पढ़ा, जाँच की, यह पता चला है कि अनुकूलन है, अंतिम रूप से अनुकूलित करें। ऑप्टिमाइज़ फ़ाइनल मूल रूप से विशेष रूप से GraphiteMergeTree के लिए बनाया गया था। वास्तव में downsampling वह करता है। लेकिन उसे अपने हाथों से बुलाना होगा।

GraphiteMergeTree में एक अलग डेटा मॉडल है। उसके पास कोई लेबल नहीं है। मैट्रिक्स के नाम पर यह सब प्रभावी ढंग से लिखना बहुत अच्छी तरह से काम नहीं करता है।

नाम मीट्रिक एक तालिका में संग्रहीत किए जाते हैं। मैट्रिक्स के नाम की एक अलग लंबाई है। यह इस तथ्य की ओर जाता है कि अगर हम मीट्रिक के नाम से एक सूचकांक खोज करते हैं, क्योंकि लंबाई अलग है, तो यह सूचकांक उतना प्रभावी नहीं होगा जैसे कि इस सूचकांक का एक निश्चित लंबाई मान था। क्योंकि आपको एक फाइल सर्च करने की जरूरत है। द्विआधारी खोज करने के लिए वास्तव में कहाँ उतरना है, यह निर्दिष्ट करना असंभव है।

इसलिए, उन्होंने अपनी योजना बनाई। स्लाइड दिखाती है कि हम डेटाबेस में समय श्रृंखला कैसे संग्रहीत करते हैं। ClickHouse की जरूरत की तारीख एक फिंगरप्रिंट है। यदि आपने प्रोमेथियस या टीएसडीबी के स्रोतों को देखा, तो आप जानते हैं कि फिंगरप्रिंट अनिवार्य रूप से पूर्ण नाम समय श्रृंखला का संक्षिप्त त्वरित चेकसम है। फ़िंगरप्रिंट सभी लेबल, कुंजियों और मूल्यों का एक संयोजन है। एक नाम एक नियमित लेबल है। हम संगतता के लिए समान एल्गोरिथ्म का उपयोग करते हैं। किसी चीज़ पर बहस करना सुविधाजनक हो सकता है। फिंगरप्रिंट समान है और इसे TSDB में और हमारे स्टोरेज में चेक किया जा सकता है कि वे समान हैं। लेबल एक विशेष JSON में संग्रहीत किए जाते हैं, जो ClickHouse को इसके मानक कार्यों के साथ काम करने की अनुमति देता है। यह कॉम्पैक्ट JSON है जिसमें कोई स्थान नहीं है, थोड़ा सरलीकृत नामकरण के साथ। ऑपरेशन के दौरान इस तालिका का उपयोग नहीं किया जाता है। यह हमेशा हमारे वास्तविक समाधान की स्मृति में संग्रहीत होता है, जिसे प्रोमहाउस कहा जाता है। इसका उपयोग केवल तभी किया जाता है जब हम सर्वर को यह जानने के लिए शुरू करते हैं कि समय श्रृंखला क्या है। उसे घटाया जाता है। जैसे ही नई समय श्रृंखला आती है, हम उन्हें वहां रिकॉर्ड करते हैं। सभी कई प्रोमोहाउस उदाहरण एक ही तालिका पढ़ सकते हैं। ReplacingMergeTree हमें बताता है कि ये समय श्रृंखला - कई अलग-अलग उदाहरण हैं - एक ही समय श्रृंखला लिखें। वे चुनाव लड़ेंगे - और यहाँ कोई समस्या नहीं होगी।

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

24 बाइट्स एक सरलीकृत संस्करण है। वास्तव में, यह अच्छी तरह से संपीड़ित करता है। वास्तव में कम जगह का उपयोग करता है। हमारे नवीनतम परीक्षणों में, संपीड़न अनुपात लगभग 1 से 42 है।

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

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

हम डाउनसैंपलिंग कैसे करते हैं? हम एक अस्थायी तालिका बनाते हैं। सही कार्यों का उपयोग करके सम्मिलित डेटा को इसमें से कॉपी करें।

हम नाम बदलें जो वैश्विक लॉक के तहत परमाणु है। हम मौजूदा तालिका का नाम बदलकर पुराने के लिए कर रहे हैं। मौजूदा के लिए नया। हम पुरानी तालिका छोड़ देते हैं। हमारे पास 148 दिनों का डेटा पहले से डाउनसम्पलिंग है। यहाँ क्या समस्या है? सुंदर लग रहा है में डालें। वास्तव में, हमें सही कार्य, सही एकत्रीकरण करने की आवश्यकता है। व्यवहार में, यह एक बड़े अनुरोध के साथ नहीं किया जा सकता है। यहां तक ​​कि कुछ बड़े अनुरोध भी नहीं किए जा सकते हैं। यह कोड से किया जाना है। कोड बड़ी संख्या में छोटे अनुरोध भेजता है। हमने बड़े अनुरोधों के साथ ऐसा करने की पूरी कोशिश की, लेकिन यह बहुत प्रभावी नहीं है। एक दिन से अब तक डेटा डाउन करने में एक दिन से भी कम समय लगता है। डेटा की मात्रा के आधार पर, इसमें लंबा समय लग सकता है।

ClickHouse में अपडेट / डिलीट होगा। हटाएं पहले से ही पहला संस्करण मिला है। यदि अद्यतन / हटाए गए कार्य हैं, तो हमारी डाउनसम्पलिंग डेटा योजना को सरल बनाया जा सकता है।

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

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

OpenTSDB और ग्रेफाइट हैं, जो केवल लेखन है। प्रोमेथियस से मानक एडाप्टर वास्तव में काम नहीं करता है।

एक CrateDB है। एक TimescaleDB है जो समय श्रृंखला डेटाबेस के लिए PostgreSQL कांटा करता है। वे कहते हैं कि यह अच्छी तरह से काम करता है, लेकिन हमने खुद इसकी कोशिश नहीं की है।

कॉर्टेक्स है, जिसे फ्रेंकस्टीन परियोजना के रूप में भी जाना जाता था। यह उसका बहुत अच्छा वर्णन करता है। यह वे लोग हैं जो प्रोमेथियस फेडरेशन के आधार पर निर्णय लेने की कोशिश कर रहे हैं। वे S3 में डेटा स्टोर करते हैं।

थानोस हैं।

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

पुल मॉडल का उपयोग करने से बहुत अधिक डेटा नहीं लिखा जाता है। वार्षिक डेटा भरने के लिए आपको पूरे एक साल का इंतजार करना होगा। हम किसी तरह उन्हें वहां लिखने की कोशिश कर रहे हैं।

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

दूसरी समस्या। यदि हम तनाव परीक्षण के लिए डेटा उत्पन्न करते हैं, तो वे अक्सर अच्छी तरह से हिलाते हैं। उदाहरण के लिए, यदि हम मौजूदा डेटा लेते हैं और 100 इंस्टेंस उत्पन्न करते हैं, और ये समान डेटा हैं, तो वहां संपीड़न गुणांक इतना सुंदर होगा कि वास्तव में वे ऐसा नहीं करते हैं।

हमने एक नकली निर्यातक लिखा जो एक नियमित निर्यातक की तरह दिखता है जिसे प्रोमेथियस एक साथ पकड़ सकता है:

• जब स्क्रैप आता है, तो वह कुछ अपस्ट्रीम एक्सपोर्टर के पास जाता है। इससे डेटा लेता है।
• कई उदाहरण उत्पन्न करता है। मान लें कि 1 एक स्क्रेपी है, और हम आउटपुट पर 100 प्राप्त करते हैं।
• डेटा को थोड़ा बदल देता है: काउंटर और गेज के लिए प्लस माइनस 10%।
• यह सरल मानों को 0 या 1 में परिवर्तित नहीं करता है। क्योंकि अगर कोई यूपी मीट्रिक है जो इसका जवाब देता है तो यह दिखाता है कि सेवा चल रही है: हाँ - 1 या नहीं - 0. और यह बहुत स्पष्ट नहीं है कि 098 यूपी का मतलब क्या है।
• हम पूर्णांकों को वास्तविक में नहीं बदलते हैं और इसके विपरीत।
• यह सिर्फ सामान्य एक्सपफेट प्रारूप में डेटा देता है।

एक प्रीलोड टूल जो डेटा लोड करता है। डेटा पढ़ना:

• फ़ाइलों से अपने स्वरूप में पढ़ सकते हैं
• शायद रिमोट से पढ़ा हो
• कुछ निर्यातक से पढ़ सकते हैं

विभिन्न स्वरूपों में लिखता है। / देव / अशक्त सहित, अगर हम वास्तव में परीक्षण करना चाहते हैं कि पढ़ना जल्दी कैसे काम करता है।

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

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

मक्खी पर किसी प्रकार का फ़िल्टर करना, मक्खी पर किसी प्रकार का संशोधन करना।

TSDB के लिए मूल समर्थन। डिस्क पर डेटाबेस के साथ काम करने के लिए, और एपीआई के माध्यम से नहीं।

प्रवास के लिए सटीकता पर ध्यान दें। मैंने एक बार pmmdemo.percona.com डाला: कनेक्टेड, सभी मीट्रिक प्राप्त किए। यदि आप इसे देशी तरीके से करते हैं, तो प्रोमेथियस TSDB खोलता है, डिस्क से सभी समय श्रृंखला उठाता है, अनुक्रमित करता है, फिर क्रंक फ़ाइलों में क्रॉल करता है, यह महसूस करता है कि वे वास्तव में मौजूद हैं। इस बिंदु पर, सब कुछ बस लेट सकता है।

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

लोड परीक्षण के परिणाम, कोई रेखांकन नहीं होगा। लोड परीक्षण में बहुत समय लगता है और, दुर्भाग्य से, एक कॉन्फ़िगरेशन त्रुटि के कारण, सब कुछ गलत हो गया। इसलिए, परिणाम नहीं निकले।

जब हम लोड परीक्षण करते हैं तो हम पेरकोना ब्लॉग पर लिखेंगे।

मैं बिना रेखांकन के परिणाम कह सकता हूं। रिकॉर्डिंग रैखिक थी। पढ़ना कूद गया और बहुत तेज नहीं था। वर्तमान डेटा को पढ़ना हमारे लिए बहुत महत्वपूर्ण नहीं है। रीड संकेत के माध्यम से उन्हें त्वरित किया जा सकता है। आप रीडिंग को बेहतर बनाने के लिए read_recent को सक्षम कर सकते हैं। और पुराने डेटा के लिए, यह ठीक काम करता है।

लोग दीर्घकालिक भंडारण चाहते हैं। ऐसी मांग है। हमने PromCouse के बारे में एक बात की है PromCon पर। वहाँ यह एक बहुत ही गर्म विषय था। थानोस सक्रिय रूप से विकसित हो रहा है।

यह पहले से ही अब संभव है। इसके लिए एक उपाय है। एक एपीआई है। कुछ एकीकरण हैं। लेकिन यह सब एक फ़ाइल के साथ अंतिम रूप देने की आवश्यकता है। कोई उत्पादन तैयार समाधान नहीं।

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

हमारे ब्लॉग में प्रदर्शन और कुछ समाचारों के बारे में जानकारी होगी।

सवाल:

प्रश्न: क्या आपने इन्फ्लक्सबीडी के बारे में अफवाहों की जाँच की है?

उत्तर: वह बहुत अच्छा नहीं था। वह बहुत बेहतर हो गया। इस तथ्य के बारे में ये सभी कहानियाँ कि इन्फ्लुएंक्सडीबी धीमी है, अलग हो रही है - वे पुराने संस्करण के बारे में हैं। वर्तमान संस्करण स्थिर है। मैं नहीं कहूंगा? यह तेजी से काम करता है। लेकिन यह stably काम करता है। मेरी राय में InfluxDB के पेशेवरों:

• सबसे पहले, पास में कुछ करने की आवश्यकता नहीं है, क्योंकि इन्फ्लक्सबीडी बॉक्स से बाहर काम करता है।
• दूसरे, ClickHouse में, अन्य डेटाबेस-आधारित समाधानों के रूप में, लेकिन TSDB नहीं, आप एक क्वेरी भाषा का उपयोग कर सकते हैं जो आपके लिए अधिक परिचित है। InfluxDB क्वेरी भाषा SQL के समान है। आप उस पर एनालिटिक्स कर सकते हैं, जो प्रोमसेल पर करना मुश्किल है। यदि आप TimeScaleDB का उपयोग करते हैं - वास्तविक SQL है।

प्रश्न: क्या ग्रेफाइटमेजरट्री इंजन केवल रिकॉर्डिंग कार्य के लिए है? यदि हम रेखांकन दिखाना चाहते हैं, तो क्या ग्रेफाना को दीर्घकालिक भंडारण दिखाने के लिए ग्रेफाइट पर स्थापित करने की आवश्यकता है?

उत्तर: हां। प्रोमेथियस में जो एकीकरण है, वह केवल रिकॉर्डिंग के लिए काम करता है। वह केवल डेटा लिखते हैं। इसलिए ग्राफाना से आप ग्रेफाइट में जाएं।

प्रश्न: और वह लिखते समय लेबल खो देता है?

उत्तर: एक कॉन्फ़िगरेशन है जो कहता है कि उनके साथ क्या करना है, उन्हें कैसे सम्मिलित करना है, उन्हें कहां सम्मिलित करना है।

दर्शकों से जानकारी: एविटो ने कहा कि वे प्रोमेथियस से ग्रेफाइट तक रिकॉर्डिंग के लिए अपना समाधान लिख रहे हैं।

प्रश्न: एक निष्कर्ष था कि दीर्घकालिक भंडारण सर्वर पर सब कुछ रिकॉर्ड करने के साथ ठीक है।

(5- 15-). raid 6 sata ?

: PMM — . downsampling c 14 1 . , . . . .

: IOPS ?

: .

:

: . , . , , .

: InfluxDB, InfluxDB?

: read_recent. , remote storage. InfluxDB . . read_recent , .

: , Prometheus. InfluxDB. Grafana Prometheus. Prometheus PromQL , InfluxDB?

: .

: Prometheus InfluxDB Grafana?

: . Prometheus 2.2 , .

PS : valyala gecube
, .