VictoriaMetrics र निजी क्लाउड निगरानी। पावेल कोलोबाएव

VictoriaMetrics एक समय श्रृंखला को रूप मा डाटा भण्डारण र प्रशोधन को लागी एक छिटो र स्केलेबल DBMS हो (एक रेकर्ड मा समय र यस समय संग सम्बन्धित मान को एक सेट समावेश गर्दछ, उदाहरण को लागी, सेन्सर को स्थिति को आवधिक मतदान द्वारा प्राप्त वा मेट्रिक्स को संग्रह)।

मेरो नाम Kolobaev पावेल हो। DevOps, SRE, LeroyMerlin, सबै कुरा कोड जस्तै छ - यो सबै हाम्रो बारेमा हो: मेरो बारेमा र अन्य LeroyMerlin कर्मचारीहरूको बारेमा।

https://bit.ly/3jf1fIK

त्यहाँ OpenStack मा आधारित क्लाउड छ। प्राविधिक राडारमा एउटा सानो लिङ्क छ।

यो Kubernetes हार्डवेयर, साथै OpenStack र लगिङका लागि सबै सम्बन्धित सेवाहरूमा निर्मित छ।

हामीले विकासको योजना बनाएका छौं । जब हामीले यो सबै विकास गरिरहेका थियौं, हामीसँग प्रोमिथियस अपरेटर थियो जसले K8s क्लस्टर भित्र डाटा भण्डारण गर्‍यो। उसले स्क्रब गर्नु पर्ने कुरा स्वतः फेला पार्छ र आफ्नो खुट्टामुनि राख्छ, लगभग बोल्दै।

हामीले सबै डाटा Kubernetes क्लस्टर बाहिर सार्न आवश्यक हुनेछ, किनकि यदि केहि भयो भने, हामीले के र कहाँ बुझ्न आवश्यक छ।

पहिलो समाधान भनेको हामीसँग तेस्रो-पक्ष प्रोमिथियस हुँदा, जब हामी फेडरेशन मेकानिजम मार्फत कुबेरनेट क्लस्टरमा जान्छौं, फेडरेशन प्रयोग गर्छौं।

तर यहाँ केही साना समस्याहरू छन्। हाम्रो मामलामा, समस्याहरू सुरु भयो जब हामीसँग 250 मेट्रिकहरू थिए, र जब त्यहाँ 000 मेट्रिकहरू थिए, हामीले महसुस गर्यौं कि हामीले त्यसरी काम गर्न सक्दैनौं। हामीले scrape_timeout लाई २५ सेकेन्डमा बढायौं।

हामीले यो किन गर्नुपर्‍यो? प्रोमेथियसले बारको सुरुबाट टाइमआउट गणना गर्न थाल्छ। यसले कुनै फरक पर्दैन कि डाटा अझै प्रवाह भइरहेको छ। यदि यो निर्दिष्ट अवधिमा डाटा मर्ज गरिएको छैन र सत्र http मार्फत बन्द गरिएको छैन भने, त्यसपछि सत्र असफल भएको मानिन्छ र डाटा प्रोमेथियसमा आउँदैन।

केहि डाटा हराइरहेको बेला हामीले प्राप्त गर्ने ग्राफहरूसँग सबैलाई परिचित छ। तालिका च्यातिएको छ र हामी यससँग खुसी छैनौं।

अर्को विकल्प एउटै संघीय संयन्त्र मार्फत दुई फरक प्रोमेथियसमा आधारित छ।

उदाहरण को लागी, केवल तिनीहरूलाई लिनुहोस् र नाम द्वारा तिनीहरूलाई काट्नुहोस्। यो पनि प्रयोग गर्न सकिन्छ, तर हामीले अगाडि बढ्ने निर्णय गर्यौं।

हामीले अब यी शार्डहरूलाई कुनै न कुनै रूपमा प्रशोधन गर्नुपर्नेछ। तपाईं promxy लिन सक्नुहुन्छ, जुन शार्ड क्षेत्रमा जान्छ र डेटा गुणा गर्दछ। यसले एकल प्रविष्टि बिन्दुको रूपमा दुई शार्डहरूसँग काम गर्दछ। यो promxy मार्फत लागू गर्न सकिन्छ, तर यो अझै धेरै गाह्रो छ।

पहिलो विकल्प भनेको महासंघको संयन्त्र एकदमै ढिलो भएकाले त्यसलाई परित्याग गर्न चाहन्छौँ ।

Prometheus विकासकर्ताहरूले स्पष्ट रूपमा भनिरहेका छन्, "साथीहरू, फरक TimescaleDB प्रयोग गर्नुहोस् किनभने हामी मेट्रिक्सको दीर्घकालीन भण्डारणलाई समर्थन गर्दैनौं।" यो उनीहरुको काम होइन ।

हामी कागजको टुक्रामा लेख्छौं जुन हामीले अझै पनि बाहिर अनलोड गर्न आवश्यक छ, ताकि सबै कुरा एकै ठाउँमा भण्डारण नगर्नुहोस्।

दोस्रो कमजोरी मेमोरी खपत हो। हो, म बुझ्छु कि धेरैले भन्नेछन् कि २०२० मा दुई गिगाबाइट मेमोरी एक पैसा खर्च हुन्छ, तर अझै।

अब हामीसँग dev र prod वातावरण छ। dev मा यो 9 मेट्रिक्स को लागी लगभग 350 गीगाबाइट छ। उत्पादनमा यो 000 गीगाबाइट र 14 मेट्रिक्स भन्दा थोरै छ। एकै समयमा, हाम्रो अवधारण समय मात्र 780 मिनेट हो। यो खराब छ। र अब म व्याख्या गर्नेछु किन।

हामी गणना गर्छौं, त्यो हो, डेढ मिलियन मेट्रिक्सको साथ, र हामी पहिले नै तिनीहरूको नजिक छौं, डिजाइन चरणमा हामीले 35-37 गीगाबाइट मेमोरी पाउँछौं। तर पहिले नै 4 मिलियन मेट्रिक्सलाई लगभग 90 गीगाबाइट मेमोरी चाहिन्छ। अर्थात्, यो प्रोमेथियस विकासकर्ताहरू द्वारा प्रदान गरिएको सूत्र प्रयोग गरेर गणना गरिएको थियो। हामीले सहसंबंध हेर्यौं र हामीले अनुगमनको लागि मात्र सर्भरको लागि दुई लाख तिर्न चाहँदैनौं भनेर महसुस गर्यौं।

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

डिस्क स्पेसको साथ, यहाँ सबै कुरा यति खराब छैन, तर म यसलाई सुधार गर्न चाहन्छु। हामीले १५ दिनमा कुल १२० गिगाबाइटहरू प्राप्त गर्यौं, जसमध्ये १०० कम्प्रेस गरिएका डाटा हुन्, २० अनकम्प्रेस गरिएका डाटा हुन्, तर हामी सधैं कम चाहन्छौँ।

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

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

यो अर्को कारण हो कि प्रोमिथियस हाम्रो लागि उपयुक्त छैन, अर्थात् हामी मेमोरी खपत सीमित गर्न सक्दैनौं।

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

यस योजनाले भन्छ कि हामीसँग शार्डहरूको नक्कल हुनेछ, र, तदनुसार, उपभोग गरिएका स्रोतहरूको लागतको नक्कल। यो लगभग तेर्सो मापन गर्न सकिन्छ, तर यद्यपि संसाधन खपत नरक हुनेछ।

हामीले तिनीहरूलाई आफ्नै लागि लेखेको फारममा बेफाइदाहरू:

• बाह्य रूपमा मेट्रिक्स अपलोड गर्न आवश्यक छ।
• उच्च स्रोत खपत।
• मेमोरी खपत सीमित गर्ने कुनै तरिका छैन।
• HA को जटिल र संसाधन-गहन कार्यान्वयन।

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

हामीले आफैलाई आवश्यक पर्ने अतिरिक्त आवश्यकताहरू पहिचान गरेका छौं। यो:

• यो promql समर्थन हो, किनभने धेरै चीजहरू पहिले नै प्रोमेथियसका लागि लेखिएका छन्: प्रश्नहरू, सतर्कताहरू।
• र त्यसपछि हामीसँग Grafana छ, जुन पहिले नै ब्याकइन्डको रूपमा प्रोमेथियसको लागि ठीक त्यस्तै तरिकामा लेखिएको छ। म ड्यासबोर्डहरू पुन: लेख्न चाहन्न।
• हामी सामान्य HA वास्तुकला निर्माण गर्न चाहन्छौं।
• हामी कुनै पनि स्रोतको खपत कम गर्न चाहन्छौं।
• त्यहाँ अर्को सानो nuance छ। हामी विभिन्न प्रकारका क्लाउड मेट्रिक्स सङ्कलन प्रणालीहरू प्रयोग गर्न सक्दैनौं। हामीलाई थाहा छैन के यी मेट्रिक्समा पर्नेछ। र त्यहाँ जे पनि उड्न सक्छ, हामीले आफैलाई स्थानीय प्लेसमेन्टमा सीमित गर्नुपर्छ।

विकल्प थोरै थियो । हामीले अनुभव गरेका सबै कुरा संकलन गर्यौं। हामीले एकीकरण खण्डमा प्रोमिथियस पृष्ठ हेर्यौं, लेखहरूको गुच्छा पढ्यौं, र त्यहाँ के थियो देख्यौं। र हाम्रो लागि, हामीले प्रोमेथियसको प्रतिस्थापनको रूपमा VictoriaMetrics रोज्यौं।

किन? किनभने:

• promql थाहा छ।
• त्यहाँ एक मोड्युलर वास्तुकला छ।
• Grafana मा परिवर्तन आवश्यक छैन।
• र सबैभन्दा महत्त्वपूर्ण कुरा, हामी सम्भवतः सेवाको रूपमा हाम्रो कम्पनी भित्र मेट्रिक्स भण्डारण प्रदान गर्नेछौं, त्यसैले हामी विभिन्न प्रकारका प्रतिबन्धहरू तर्फ अग्रिम हेरिरहेका छौं ताकि प्रयोगकर्ताहरूले क्लस्टरका सबै स्रोतहरू केही सीमित रूपमा प्रयोग गर्न सकून्, किनभने त्यहाँ मौका छ। कि यसले बहुमुखी हुनेछ।

पहिलो तुलना गरौं। हामी क्लस्टर भित्र उही प्रोमिथियस लिन्छौं, बाहिरी प्रोमेथियस यसमा जान्छ। RemoteWrite VictoriaMetrics मार्फत थप्नुहोस्।

म तुरुन्तै रिजर्भेसन गर्नेछु कि यहाँ हामीले VictoriaMetrics बाट CPU खपतमा थोरै वृद्धि पायौं। VictoriaMetrics विकिले तपाईंलाई कुन प्यारामिटरहरू उत्तम छन् भनी बताउँछ। हामीले तिनीहरूलाई जाँच गर्यौं। तिनीहरूले CPU खपत धेरै राम्रो कम गरेका छन्।

हाम्रो मामला मा, प्रोमेथियस को मेमोरी खपत, जो Kubernetes क्लस्टर मा स्थित छ, उल्लेखनीय वृद्धि भएको छैन।

हामी एउटै डाटाका दुई डेटा स्रोतहरू तुलना गर्छौं। Prometheus मा हामी समान हराएको डाटा देख्छौं। VictoriaMetrics मा सबै ठीक छ।

डिस्क स्पेस परीक्षण परिणाम। हामीले प्रोमेथियसमा कुल 120 गिगाबाइटहरू प्राप्त गर्यौं। VictoriaMetrics मा हामीले पहिले नै प्रति दिन 4 गीगाबाइटहरू प्राप्त गर्छौं। प्रोमिथियसमा हामीले देख्ने बानीभन्दा अलि फरक संयन्त्र छ। त्यो हो, डाटा पहिले नै एक दिनमा राम्रोसँग कम्प्रेस गरिएको छ, आधा घण्टामा। तिनीहरूले पहिले नै एक दिनमा राम्रोसँग कटनी गरिसकेका छन्, आधा घण्टामा, तथ्याङ्कको बावजुद डेटा अझै पछि हराउनेछ। नतिजाको रूपमा, हामीले डिस्क स्थानमा बचत गर्यौं।

हामी मेमोरी स्रोत खपतमा पनि बचत गर्छौं। परीक्षणको समयमा, हामीले प्रोमेथियसलाई भर्चुअल मेसिनमा तैनाथ गरेका थियौं - 8 कोर, 24 गीगाबाइट। प्रोमेथियसले लगभग सबै खान्छ। ऊ ओओएम किलरमा पर्यो। एकै समयमा, केवल 900 सक्रिय मेट्रिक्स यसमा राखिएको थियो। यो प्रति सेकेन्ड लगभग 000-25 मेट्रिक्स हो।

हामीले VictoriaMetrics लाई 8 गीगाबाइट RAM भएको डुअल-कोर भर्चुअल मेसिनमा चलायौं। हामीले VictoriaMetrics लाई 8GB मेसिनमा केही चीजहरू मार्फत राम्रोसँग काम गर्न व्यवस्थित गर्यौं। अन्तमा, हामीले यसलाई 7 गिगाबाइटमा राख्यौं। एकै समयमा, सामग्रीको वितरणको गति, अर्थात् मेट्रिक्स, प्रोमेथियसको भन्दा पनि उच्च थियो।

प्रोमेथियसको तुलनामा CPU धेरै राम्रो भएको छ। यहाँ प्रोमेथियसले २.५ कोर खपत गर्छ, र भिक्टोरियामेट्रिक्सले ०.२५ कोर मात्र खपत गर्छ। सुरुमा - 2,5 कोर। यो मर्ज हुँदा, यो एक कोरमा पुग्छ, तर यो अत्यन्तै दुर्लभ छ।

हाम्रो केसमा, छनौट स्पष्ट कारणहरूको लागि VictoriaMetrics मा पर्यो; हामी पैसा बचत गर्न चाहन्थ्यौं र हामीले गर्यौं।

तुरुन्तै दुईवटा बिन्दुहरू पार गरौं - मेट्रिक्सको अपलोडिङ र स्रोतहरूको उच्च खपत। र हामीले केवल दुईवटा बिन्दुहरू निर्णय गर्नुपर्दछ जुन हामीले अझै पनि आफ्नै लागि छोडेका छौं।

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

त्यहाँ एक अद्भुत प्यारामिटर छ जसले तपाईंलाई समय, डेटाको मात्रा र कार्यान्वयन समय द्वारा सीमित गर्न अनुमति दिन्छ।

त्यहाँ एक उत्कृष्ट विकल्प पनि छ जसले हामीलाई मेमोरी खपत सीमित गर्न अनुमति दिन्छ, यसैले हामी धेरै सन्तुलन पाउन सक्छौं जसले हामीलाई सामान्य सञ्चालन गति र पर्याप्त स्रोत खपत प्राप्त गर्न अनुमति दिनेछ।

माइनस एक थप बिन्दु, अर्थात् बिन्दु क्रस आउट गर्नुहोस् - तपाईले मेमोरी खपत सीमित गर्न सक्नुहुन्न।

पहिलो पुनरावृत्तिमा, हामीले VictoriaMetrics एकल नोड परीक्षण गर्यौं। अर्को हामी VictoriaMetrics क्लस्टर संस्करणमा जान्छौं।

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

VictoriaMetrics क्लस्टर संस्करण को मुख्य घटक vmstsorage हो। तिनीहरूको N संख्या हुन सक्छ। हाम्रो मामला मा ती मध्ये 2 अहिलेसम्म छन्।

र त्यहाँ vminsert छ। यो एक प्रोक्सी सर्भर हो जसले हामीलाई अनुमति दिन्छ: हामीले यसको बारेमा भनेका सबै भण्डारणहरू बीचको शार्डिङ मिलाउन, र यसले प्रतिकृतिलाई पनि अनुमति दिन्छ, अर्थात् तपाईंसँग शार्डिङ र प्रतिकृति दुवै हुनेछ।

Vminsert ले Prometheus बाट OpenTSDB, Graphite, InfluxDB र remoteWrite प्रोटोकल समर्थन गर्दछ।

त्यहाँ vmselect पनि छ। यसको मुख्य कार्य भनेको vmstorage मा जानु, तिनीहरूबाट डाटा प्राप्त गर्नु, यो डाटा डुप्लिकेट गर्नु र ग्राहकलाई दिनु हो।

vmagent भनिने एउटा अचम्मको कुरा छ। हामी उनलाई साँच्चै मनपर्छौं। यसले तपाइँलाई प्रोमेथियस जस्तै कन्फिगर गर्न र अझै पनि प्रोमिथियस जस्तै सबै कुरा गर्न अनुमति दिन्छ। त्यो हो, यसले विभिन्न निकाय र सेवाहरूबाट मेट्रिक्स सङ्कलन गर्छ र तिनीहरूलाई vminsert मा पठाउँछ। त्यसपछि सबै कुरा तपाईं मा निर्भर गर्दछ।

अर्को उत्कृष्ट सेवा vmalert हो, जसले तपाईंलाई VictoriaMetrics लाई ब्याकइन्डको रूपमा प्रयोग गर्न, vminsert बाट प्रशोधित डाटा प्राप्त गर्न र vmselect मा पठाउन अनुमति दिन्छ। यसले अलर्टहरू आफैं प्रशोधन गर्दछ, साथै नियमहरू। अलर्टको अवस्थामा, हामी अलर्ट म्यानेजर मार्फत अलर्ट प्राप्त गर्छौं।

त्यहाँ wmauth कम्पोनेन्ट छ। हामीले यसलाई क्लस्टरहरूको बहु-टेनेन्सी संस्करणको लागि प्राधिकरण प्रणालीको रूपमा प्रयोग गर्न सक्छौं वा नगर्न सक्छौं (हामीले यसबारे अझै निर्णय गरेका छैनौं। यसले Prometheus को लागि remoteWrite लाई समर्थन गर्दछ र url को आधारमा अधिकृत गर्न सक्छ, वा यसको दोस्रो भाग, जहाँ तपाइँ लेख्न सक्नुहुन्छ वा गर्न सक्नुहुन्न।

त्यहाँ vmbackup, vmrestore पनि छ। यो, सार मा, सबै डाटा को पुनर्स्थापना र ब्याकअप हो। S3, GCS, फाइल गर्न सक्नुहुन्छ।

हाम्रो क्लस्टरको पहिलो पुनरावृत्ति क्वारेन्टाइनको समयमा गरिएको थियो। त्यस समयमा, त्यहाँ कुनै प्रतिकृति थिएन, त्यसैले हाम्रो पुनरावृत्तिमा दुई फरक र स्वतन्त्र क्लस्टरहरू थिए जसमा हामीले रिमोट राइट मार्फत डेटा प्राप्त गर्यौं।

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

यहाँ पहिले नै प्रतिकृति थपिएको छ। हामीले यी सबैलाई एक अपेक्षाकृत ठूलो क्लस्टरमा जोड्यौं। हाम्रो सबै डेटा छायादार र प्रतिकृति दुवै छ।

सम्पूर्ण क्लस्टरमा N प्रविष्टि बिन्दुहरू छन्, जसको अर्थ प्रोमेथियसले HAPROXY मार्फत डेटा थप्न सक्छ। यहाँ हामीसँग यो प्रविष्टि बिन्दु छ। र यो प्रविष्टि बिन्दु मार्फत तपाईं Grafana बाट लग इन गर्न सक्नुहुन्छ।

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

हामीसँग अलर्ट छ। हामी यसलाई प्रयोग गर्छौं। हामी Prometheus बाट चेतावनी प्रबन्धक प्रयोग गर्दछौं। हामी अलर्ट डेलिभरी च्यानलको रूपमा Opsgenie र Telegram प्रयोग गर्छौं। Telegram मा तिनीहरू dev बाट भित्र पाउँछन्, सायद उत्पादनबाट केहि, तर प्रायः केहि सांख्यिकीय, ईन्जिनियरहरु लाई आवश्यक छ। र Opsgenie महत्वपूर्ण छ। यी कलहरू हुन्, घटना व्यवस्थापन।

अनन्त प्रश्न: "कसले अनुगमन निगरानी गर्दछ?" हाम्रो केसमा, मोनिटरिङ मोनिटरहरू आफैलाई निगरानी गर्दछ, किनभने हामी प्रत्येक नोडमा vmagent प्रयोग गर्छौं। र हाम्रा नोडहरू एउटै प्रदायकका विभिन्न डाटा केन्द्रहरूमा वितरित भएकाले, प्रत्येक डाटा केन्द्रको आफ्नै च्यानल छ, तिनीहरू स्वतन्त्र छन्, र यदि एक विभाजित मस्तिष्क आइपुग्छ भने, हामी अझै पनि अलर्टहरू प्राप्त गर्नेछौं। हो, तिनीहरूमध्ये धेरै हुनेछन्, तर कुनै पनि भन्दा बढी अलर्टहरू प्राप्त गर्नु राम्रो हो।

हामी HA कार्यान्वयनको साथ हाम्रो सूची समाप्त गर्छौं।

र थप म VictoriaMetrics समुदाय संग संचार को अनुभव नोट गर्न चाहन्छु। यो धेरै सकारात्मक भयो। केटाहरू उत्तरदायी छन्। तिनीहरूले प्रस्ताव गरिएको हरेक मामलामा खोजी गर्ने प्रयास गर्छन्।

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

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

केहि बिन्दुमा हामी VictoriaMetrics को VictoriaMetrics अपरेटर हुन चाहन्थ्यौं। हामीले उहाँलाई पर्ख्यौं। हामी अब सक्रिय रूपमा भिक्टोरियामेट्रिक्स अपरेटरका लागि सबै पूर्व-गणना नियमहरू, आदि लिनको लागि एक रूपरेखा निर्माण गर्दैछौं।

क्लस्टर कार्यान्वयनमा सुधार गर्ने प्रस्तावहरू छन्। मैले तिनीहरूलाई माथि उल्लेख गरें।

र म वास्तवमै डाउनसम्पल गर्न चाहन्छु। हाम्रो केसमा, प्रवृतिहरू हेर्नको लागि डाउनसम्पलिंग विशेष रूपमा आवश्यक छ। सामान्य रूपमा भन्नुपर्दा, दिनको समयमा मेरो लागि एक मेट्रिक पर्याप्त छ। यी प्रवृत्तिहरू एक वर्ष, तीन, पाँच, दस वर्षको लागि आवश्यक छ। र एक मेट्रिक मान पर्याप्त छ।

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

हामी घरमा VictoriaMetrics प्रयोग गर्नेछौं किनभने हामीलाई यो वास्तवमै मन पर्यो। यो जे थियो र बन्यो।

https://t.me/VictoriaMetrics_ru1

VictoriaMetrics च्याट, मेरा सम्पर्कहरू, LeroyMerlin प्राविधिक रडारका लागि केही QR कोडहरू।

स्रोत: www.habr.com