नमस्ते सबै! उनको मा अन्तिम लेख मैले माइक्रोसर्भिस आर्किटेक्चरको लागि मोड्युलर निगरानी प्रणाली व्यवस्थित गर्ने बारे लेखे। केहि पनि स्थिर छैन, हाम्रो परियोजना निरन्तर बढ्दै छ, र भण्डारण मेट्रिक्स को संख्या पनि छ। हामीले उच्च लोड अवस्थाहरूमा Graphite+Whisper बाट Graphite+ClickHouse मा संक्रमण कसरी व्यवस्थित गर्यौं, यसबाट अपेक्षाहरू र कटौती अन्तर्गत माइग्रेसनको नतिजाहरू पढ्नुहोस्।

हामीले ग्रेफाइट+व्हिस्परबाट ग्रेफाइट+क्लिकहाउसमा मेट्रिक्स भण्डारण गर्ने ट्रान्जिसनलाई कसरी व्यवस्थित गर्यौं भनी बताउन अघि, म यस्तो निर्णय लिनुको कारणहरू र हामी लामो समयदेखि व्हिस्परका बेफाइदाहरूको बारेमा जानकारी दिन चाहन्छु।

ग्रेफाइट+व्हिस्पर समस्याहरू

1. डिस्क उपप्रणालीमा उच्च भार

संक्रमणको समयमा, लगभग 1.5 मिलियन मेट्रिक्स प्रति मिनेट हामीमा आइपुगेको थियो। यस्तो प्रवाहको साथ, सर्भरहरूमा डिस्क उपयोग ~ 30% थियो। सामान्यतया, यो एकदम स्वीकार्य थियो - सबै कुरा स्थिर रूपमा काम गर्यो, चाँडै लेखियो, चाँडै पढियो... जबसम्म विकास टोलीहरू मध्ये एकले नयाँ सुविधा रोल आउट गर्दैन र हामीलाई प्रति मिनेट 10 मिलियन मेट्रिक्स पठाउन थाले। त्यो हो जब डिस्क सबसिस्टम कडा भयो, र हामीले 100% उपयोग देख्यौं। समस्या चाँडै हल भयो, तर अवशेष बाँकी थियो।

2. प्रतिकृति र स्थिरता को अभाव

सम्भवतः, ग्रेफाइट + व्हिस्पर प्रयोग गर्ने/प्रयोग गर्ने सबैजस्तै, हामीले त्रुटि सहिष्णुता सिर्जना गर्न धेरै ग्रेफाइट सर्भरहरूमा मेट्रिक्सको एउटै स्ट्रिम एकै पटक खन्यायौं। र यससँग कुनै विशेष समस्याहरू थिएनन् - सर्भरहरू मध्ये एक कुनै कारणको लागि क्र्यास भएको क्षण सम्म। कहिलेकाहीँ हामीले झरेको सर्भरलाई छिटो छिटो उठाउन व्यवस्थित गर्यौं, र कार्बन-सी-रिलेले यसको क्यासबाट मेट्रिक्स लोड गर्न व्यवस्थित गर्यौं, तर कहिलेकाहीँ होइन। र त्यसपछि मेट्रिक्समा एउटा प्वाल थियो, जुन हामीले rsync ले भर्यौं। प्रक्रिया निकै लामो थियो। एक मात्र बचत अनुग्रह थियो कि यो धेरै विरलै भयो। हामीले आवधिक रूपमा मेट्रिक्सको अनियमित सेट पनि लियौं र क्लस्टरको छिमेकी नोडहरूमा समान प्रकारका अरूसँग तुलना गर्यौं। लगभग 5% केसहरूमा, धेरै मानहरू फरक थिए, जुन हामी धेरै खुसी थिएनौं।

3. ठूलो पदचिह्न

हामी ग्रेफाइटमा पूर्वाधार मात्र होइन, व्यापार मेट्रिक्स (र अब Kubernetes बाट पनि मेट्रिक्स) लेख्ने हुनाले, हामी प्रायः यस्तो अवस्था पाउँछौं जसमा मेट्रिकले केही मानहरू मात्र समावेश गर्दछ, र .wsp फाइल सबै रिटेन्सनलाई ध्यानमा राखेर सिर्जना गरिन्छ। अवधि, र पूर्व-विनियोजन गरिएको ठाउँ लिन्छ, जुन हाम्रो लागि ~2MB थियो। समस्या यस तथ्यले अझ बढेको छ कि धेरै समान फाईलहरू समयको साथ देखा पर्दछ, र तिनीहरूमा रिपोर्टहरू निर्माण गर्दा, खाली बिन्दुहरू पढ्न धेरै समय र स्रोतहरू लाग्छ।

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

माथिका सबै भएको (विगतलाई ध्यानमा राख्दै लेख), साथै प्राप्त मेट्रिक्सको संख्यामा निरन्तर वृद्धि, 30 सेकेन्डको भण्डारण अन्तरालमा सबै मेट्रिक्स स्थानान्तरण गर्ने इच्छा। (आवश्यक भएमा १० सेकेन्ड सम्म), हामीले ग्रेफाइट+क्लिकहाउसलाई व्हिस्परको आशाजनक विकल्पको रूपमा प्रयास गर्ने निर्णय गर्यौं।

ग्रेफाइट+क्लिकहाउस। अपेक्षाहरू

Yandex बाट केटाहरूको धेरै भेटघाटहरू भ्रमण गर्दै, पढेर Habré मा लेख को एक जोडी, कागजातको माध्यमबाट गएर र Graphite अन्तर्गत ClickHouse बाइन्डिङको लागि समझदार कम्पोनेन्टहरू फेला पारेपछि, हामीले कारबाही गर्ने निर्णय गर्यौं!

म निम्न प्राप्त गर्न चाहन्छु:

डिस्क सबसिस्टम उपयोग 30% बाट 5% मा घटाउनुहोस्;
1TB बाट 100GB सम्म ओगटेको ठाउँको मात्रा घटाउनुहोस्;
सर्भरमा प्रति मिनेट 100 मिलियन मेट्रिक्स प्राप्त गर्न सक्षम हुनुहोस्;
डाटा प्रतिकृति र बाकस बाहिर गल्ती सहिष्णुता;
यस परियोजनामा एक वर्षसम्म नबस्नुहोस् र उचित समयसीमा भित्र संक्रमण गर्नुहोस्;
डाउनटाइम बिना स्विच।

एकदम महत्वाकांक्षी, हैन?

ग्रेफाइट+क्लिकहाउस। अवयवहरू

ग्रेफाइट प्रोटोकल मार्फत डाटा प्राप्त गर्न र पछि क्लिकहाउसमा रेकर्ड गर्न, मैले चयन गरें कार्बन क्लिकहाउस (गोलाङ)।

ClickHouse को पछिल्लो रिलीज, स्थिर संस्करण 1.1.54253, समय श्रृंखला भण्डारण गर्न डाटाबेसको रूपमा छनोट गरिएको थियो। यसको साथ काम गर्दा समस्याहरू थिए: त्रुटिहरूको पहाड लगहरूमा खन्यायो, र तिनीहरूसँग के गर्ने भन्ने पूर्ण रूपमा स्पष्ट थिएन। सँग छलफलमा छ रोमन लोमोनोसोव (कार्बन-क्लिकहाउस, ग्रेफाइट-क्लिकहाउस र धेरै, धेरैका लेखक) पुरानो एक छानिएको थियो रिलीज 1.1.54236। त्रुटिहरू गायब भयो - सबै कुरा एक धमाका संग काम गर्न थाले।

क्लिकहाउसबाट डाटा पढ्न चयन गरियो ग्रेफाइट-क्लिक हाउस (गोलाङ)। ग्रेफाइट - को लागि API को रूपमा कार्बनपी (गोलाङ)। ClickHouse तालिकाहरू बीच प्रतिकृति व्यवस्थित गर्न प्रयोग गरिएको थियो चिडियाखाना। राउटिंग मेट्रिक्सको लागि, हामीले हाम्रो प्रियलाई छोड्यौं कार्बन-सी-रिले (सी) (अघिल्लो लेख हेर्नुहोस्).

ग्रेफाइट+क्लिकहाउस। तालिका संरचना

"ग्रेफाइट" हामीले अनुगमन तालिकाहरूको लागि सिर्जना गरेको डाटाबेस हो।

"graphite.metrics" - ReplicatedReplacingMergeTree इन्जिनको साथ तालिका (प्रतिकृति मर्जट्री प्रतिस्थापन गर्दै)। यो तालिकाले मेट्रिक्स र मार्गहरूको नाम भण्डार गर्दछ।

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

"graphite.data" - ReplicatedGraphiteMergeTree इन्जिनको साथ तालिका (प्रतिकृति GraphiteMergeTree)। यो तालिका मेट्रिक मानहरू भण्डारण गर्दछ।

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

"graphite.date_metrics" ReplicatedReplacingMergeTree इन्जिनसँग सशर्त भरिएको तालिका हो। यो तालिकाले दिनको समयमा सामना गरिएका सबै मेट्रिक्सका नामहरू रेकर्ड गर्दछ। यसको निर्माण को कारण खण्ड मा वर्णन गरिएको छ "समस्याहरू" यस लेखको अन्त्यमा।

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

"graphite.data_stat" - सर्त अनुसार भरिएको तालिका, ReplicatedAggregatingMergeTree इन्जिनको साथ (प्रतिकृति AggregatingMergeTree)। यो तालिकाले आगमन मेट्रिक्सको संख्या रेकर्ड गर्दछ, 4 नेस्टिङ स्तरहरूमा विभाजित।

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

ग्रेफाइट+क्लिकहाउस। कम्पोनेन्ट अन्तरक्रिया रेखाचित्र

ग्रेफाइट+क्लिकहाउस। डाटा माइग्रेसन

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

ClickHouse तालिकाहरूको प्रतिकृतिमा भाग लिने सर्भरहरू मध्ये एकको कार्बन-क्लिकहाउसमा मेट्रिक्सको अतिरिक्त स्ट्रिम पठाउनको लागि कार्बन-सी-रिलेमा एउटा नियम थपिएको छ।
हामीले पाइथनमा एउटा सानो स्क्रिप्ट लेख्यौं, जसले व्हिस्पर-डम्प लाइब्रेरी प्रयोग गरेर, हाम्रो भण्डारणबाट सबै .wsp फाइलहरू पढ्थ्यौं र यो डाटालाई 24 थ्रेडहरूमा माथि वर्णन गरिएको कार्बन-क्लिकहाउसमा पठायो। कार्बन-क्लिकहाउसमा स्वीकृत मेट्रिक मानहरूको संख्या 125 मिलियन/मिनेट पुग्यो, र क्लिकहाउसले पसिना पनि तोडेन।
हामीले अवस्थित ड्यासबोर्डहरूमा प्रयोग गरिएका कार्यहरू डिबग गर्न Grafana मा छुट्टै डाटा स्रोत सिर्जना गर्यौं। हामीले प्रयोग गरेका प्रकार्यहरूको सूची पहिचान गर्यौं, तर ती कार्बोनापीमा लागू भएनन्। हामीले यी प्रकार्यहरू थप्यौं र कार्बोनापीका लेखकहरूलाई PR पठायौं (उनीहरूलाई विशेष धन्यवाद)।
ब्यालेन्सर सेटिङहरूमा पढ्ने लोड बदल्नको लागि, हामीले ग्रेफाइट-एपीआई (ग्रेफाइट + व्हिस्परको लागि एपीआई इन्टरफेस) बाट कार्बोनापीमा अन्त्य बिन्दुहरू परिवर्तन गर्यौं।

ग्रेफाइट+क्लिकहाउस। परिणामहरू

डिस्क सबसिस्टम उपयोग 30% बाट 1% मा घटाइयो;
1 TB बाट 300 GB सम्म ओगटेको ठाउँको मात्रा घटाइयो;
हामीसँग सर्भरमा प्रति मिनेट १२५ मिलियन मेट्रिक्स प्राप्त गर्ने क्षमता छ (माइग्रेसनको समयमा शिखरहरू);
तीस-सेकेन्ड भण्डारण अन्तरालमा सबै मेट्रिक्स स्थानान्तरण गरियो;
प्राप्त डाटा प्रतिकृति र गल्ती सहिष्णुता;
डाउनटाइम बिना स्विच गरियो;
सबै कुरा पूरा गर्न लगभग 7 हप्ता लाग्यो।

ग्रेफाइट+क्लिकहाउस। समस्याहरू

हाम्रो मामला मा, त्यहाँ केही त्रुटिहरू थिए। संक्रमणकालपछि हामीले भोगेको यही हो ।

क्लिकहाउसले सधैं फ्लाईमा कन्फिगहरू पुन: पढ्दैन; कहिलेकाहीँ यसलाई रिबुट गर्न आवश्यक छ। उदाहरणका लागि, ClickHouse कन्फिगरेसनमा zookeeper क्लस्टरको विवरणको मामलामा, clickhouse-सर्भर रिबुट नभएसम्म यो प्रयोग गरिएन।
ठूला क्लिकहाउस अनुरोधहरू पूरा भएनन्, त्यसैले ग्रेफाइट-क्लिकहाउसमा हाम्रो क्लिकहाउस जडान स्ट्रिङ यस्तो देखिन्छ:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
क्लिकहाउसले प्रायः स्थिर रिलीजहरूको नयाँ संस्करणहरू जारी गर्दछ; तिनीहरूमा आश्चर्यहरू हुन सक्छन्: सावधान रहनुहोस्।
kubernetes मा गतिशील रूपमा सिर्जना गरिएका कन्टेनरहरूले छोटो र अनियमित जीवनकालको साथ ठूलो संख्यामा मेट्रिकहरू पठाउँछन्। त्यहाँ त्यस्ता मेट्रिक्सका लागि धेरै बिन्दुहरू छैनन्, र ठाउँसँग कुनै समस्याहरू छैनन्। तर प्रश्नहरू निर्माण गर्दा, क्लिकहाउसले 'मेट्रिक्स' तालिकाबाट यी उही मेट्रिकहरूको ठूलो संख्या उठाउँछ। 90% केसहरूमा, विन्डो (24 घण्टा) भन्दा बाहिर तिनीहरूमा कुनै डाटा छैन। तर 'डेटा' तालिकामा यो डाटा खोज्न समय बिताइन्छ, र अन्ततः समय समाप्त हुन्छ। यो समस्या समाधान गर्नको लागि, हामीले दिनको समयमा सामना गर्ने मेट्रिक्समा जानकारीको साथ एक अलग दृष्टिकोण राख्न थाल्यौं। यसैले, जब गतिशील रूपमा सिर्जना गरिएका कन्टेनरहरूको लागि रिपोर्टहरू (ग्राफहरू) निर्माण गर्छौं, हामी ती मेट्रिकहरू मात्र सोध्छौं जुन दिइएको सञ्झ्याल भित्र सामना गरिएको थियो, र सम्पूर्ण समयको लागि होइन, जसले महत्त्वपूर्ण रूपमा तिनीहरूमा रिपोर्टहरूको निर्माणलाई गति दिन्छ। माथि वर्णन गरिएको समाधानको लागि, मैले सङ्कलन गरें ग्रेफाइट क्लिकहाउस (फोर्क), जसमा date_metrics तालिकासँग काम गर्ने कार्यान्वयन समावेश छ।

ग्रेफाइट+क्लिकहाउस। ट्यागहरू

संस्करण 1.1.0 संग ग्रेफाइट आधिकारिक भयो समर्थन ट्यागहरू। र हामी ग्रेफाइट+क्लिकहाउस स्ट्याकमा यस पहललाई समर्थन गर्न के र कसरी गर्ने भन्ने बारे सक्रिय रूपमा सोचिरहेका छौं।

ग्रेफाइट+क्लिकहाउस। विसंगति डिटेक्टर

माथि वर्णन गरिएको पूर्वाधारमा आधारित, हामीले विसंगति डिटेक्टरको प्रोटोटाइप लागू गरेका छौं, र यसले काम गर्छ! तर अर्को लेखमा उनको बारेमा थप।

सदस्यता लिनुहोस्, माथि तीर थिच्नुहोस् र खुसी हुनुहोस्!

स्रोत: www.habr.com

मेट्रिक्स भण्डारण: हामीले कसरी Graphite+Whisper बाट Graphite+ClickHouse मा स्विच गर्यौं