सभी को नमस्कार!

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

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

लेकिन चलिए शुरू करते हैं।

2017 में वापस, मैंने घटकों की बातचीत का एक आरेख दिखाया जो उस समय प्रासंगिक था, और मैं इसे फिर से प्रदर्शित करना चाहूंगा ताकि आपको फिर से टैब स्विच न करना पड़े।

उस क्षण से, निम्नलिखित हुआ।

• ग्रेफाइट क्लस्टर में सर्वरों की संख्या 3 से बढ़कर 6 हो गई है।
  ( 56 CPU 2.60GHz, 384GB RAM, 10 SSD SAS 745GB, Raid 6, 10GBit/s Net )।

  
  

• हमने ब्रूइक को बायोयिनो के साथ बदल दिया - हमारे अपने स्टैटस का कार्यान्वयन रस्ट के साथ, और यहां तक ​​कि इसके बारे में एक पूरा लेख भी लिखा । हालांकि, लेख के विमोचन के बाद, हमने एक नेता का चयन करने के लिए इसमें टैग (ग्रेफाइट) और बेड़ा के लिए समर्थन लाया।

  
  

• हमने एक StatsD एजेंट के रूप में बायोयिनो का उपयोग करने की संभावना पर काम किया और ऐसे एजेंटों को अखंड उदाहरणों के बगल में रखा, साथ ही जहां इसे k8 में जरूरत थी।

  
  

• हमने अंततः पुराने मुनिन निगरानी प्रणाली से छुटकारा पा लिया (औपचारिक रूप से अभी भी हमारे पास है, लेकिन इसका डेटा अब उपयोग नहीं किया जाता है)।

  
  

• Kubernetes समूहों से डेटा संग्रह Prometheus / Federations के माध्यम से आयोजित किया गया था, क्योंकि Hubster को Kubernetes के नए संस्करणों में समर्थित नहीं किया गया था।

  
  

निगरानी

पिछले दो वर्षों में, स्वीकृत और संसाधित मेट्रिक्स की संख्या में लगभग 9 गुना वृद्धि हुई है।

कब्जे वाले सर्वर स्पेस का प्रतिशत भी बहुत कम है, और हम इसे कम करने के लिए कई कदम उठा रहे हैं। यह चार्ट पर स्पष्ट रूप से दिखाई देता है।

वास्तव में हम क्या कर रहे हैं?

• हमने डेटा कॉलम में जटिल संपीड़न विधियों को लागू करना शुरू किया।
  

   ALTER TABLE graphite.data MODIFY COLUMN Time UInt32 CODEC(Delta, ZSTD) 

• हम तीस-सेकंड के अंतराल से पाँच-मिनट तक पांच सप्ताह से अधिक पुराने डेटा को संक्षिप्त करना जारी रखते हैं। ऐसा करने के लिए, हमारे पास एक क्रोन कार्य है, जो महीने में एक बार शुरू होता है (लगभग) निम्नलिखित प्रक्रिया:

 10 10 10 * * clickhouse-client -q "select distinct partition from system.parts where active=1 and database='graphite' and table='data' and max_date between today()-55 AND today()-35;" | while read PART; do clickhouse-client -u systemXXX --password XXXXXXX -q "OPTIMIZE TABLE graphite.data PARTITION ('"$PART"') FINAL";done 

• हमने डेटा टेबल साझा किए। अब हमारे पास मेट्रिक की ओर से हैश शेरिंग कुंजी के साथ प्रत्येक में दो प्रतिकृतियां के साथ तीन शार्क हैं। यह दृष्टिकोण हमें रोलअप प्रक्रियाओं को करने का अवसर देता है, क्योंकि एक विशिष्ट मीट्रिक के सभी मान एक ही शार्क के भीतर होते हैं, और सभी शार्क पर डिस्क स्थान का समान रूप से उपयोग किया जाता है।

वितरित तालिका स्कीमा निम्नानुसार है।

 CREATE TABLE graphite.data_all ( `Path` String, `Value` Float64, `Time` UInt32, `Date` Date, `Timestamp` UInt32 ) ENGINE = Distributed ( 'graphite_cluster', 'graphite', 'data', jumpConsistentHash(cityHash64(Path), 3) ) 

हमने उपयोगकर्ता को "डिफ़ॉल्ट" आसानी से अधिकार भी सौंपा है और लेखन प्रक्रियाओं के निष्पादन को टेबल पर एक अलग उपयोगकर्ता systemXXX फेंक दिया है।

ClickHouse में ग्रेफाइट क्लस्टर का विन्यास इस प्रकार है।

  <remote_servers> <graphite_cluster> <shard> <internal_replication>true</internal_replication> <replica> <host>graphite-clickhouse01</host> <port>9000</port> <user>systemXXX</user> <password>XXXXXX</password> </replica> <replica> <host>graphite-clickhouse04</host> <port>9000</port> <user>systemXXX</user> <password>XXXXXX</password> </replica> </shard> <shard> <internal_replication>true</internal_replication> <replica> <host>graphite-clickhouse02</host> <port>9000</port> <user>systemXXX</user> <password>XXXXXX</password> </replica> <replica> <host>graphite-clickhouse05</host> <port>9000</port> <user>systemXXX</user> <password>XXXXXX</password> </replica> </shard> <shard> <internal_replication>true</internal_replication> <replica> <host>graphite-clickhouse03</host> <port>9000</port> <user>systemXXX</user> <password>XXXXXX</password> </replica> <replica> <host>graphite-clickhouse06</host> <port>9000</port> <user>systemXXX</user> <password>XXXXXX</password> </replica> </shard> </graphite_cluster> </remote_servers> 

राइट लोड के अलावा, ग्रेफाइट से डेटा पढ़ने के अनुरोधों की संख्या में वृद्धि हुई है। इस डेटा का उपयोग इसके लिए किया जाता है:

• ट्रिगर प्रसंस्करण और चेतावनी पीढ़ी;
• कार्यालय में लैपटॉप और पीसी स्क्रीन और कंपनी के कर्मचारियों की बढ़ती संख्या के मॉनीटर पर रेखांकन प्रदर्शित करना।

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

 CREATE TABLE graphite.data_reverse ( `Path` String, `Value` Float64, `Time` UInt32 CODEC(Delta(4), ZSTD(1)), `Date` Date, `Timestamp` UInt32 ) ENGINE = ReplicatedGraphiteMergeTree ( '/clickhouse/tables/{cluster}/data_reverse', '{replica}', 'graphite_rollup' ) PARTITION BY Date ORDER BY (Path, Time) SETTINGS index_granularity = 4096 

इसे डेटा को निर्देशित करने के लिए, हमने कार्बन-क्लिकहाउस एप्लिकेशन कॉन्फ़िगरेशन फ़ाइल में एक नया खंड जोड़ा।

 [upload.graphite_reverse] type = "points-reverse" table = "graphite.data_reverse" threads = 2 url = "http://systemXXX:XXXXXXX@localhost:8123/" timeout = "60s" cache-ttl = "6h0m0s" zero-timestamp = true 

दो दिनों से पुराने विभाजन को हटाने के लिए, हमने एक क्रोन कार्य लिखा। यह कुछ इस तरह दिखता है।

 1 12 * * * clickhouse-client -q "select distinct partition from system.parts where active=1 and database='graphite' and table='data_reverse' and max_date<today()-2;" | while read PART; do clickhouse-client -u systemXXX --password XXXXXXX -q "ALTER TABLE graphite.data_reverse DROP PARTITION ('"$PART"')";done 

तालिका से डेटा पढ़ने के लिए, ग्रेफाइट-क्लिकहाउस कॉन्फ़िगरेशन फ़ाइल में, एक खंड जोड़ा गया था:

 [[data-table]] table = "graphite.data_reverse" max-age = "48h" reverse = true 

नतीजतन, हमारे पास सभी छह सर्वरों के लिए दोहराए गए 100% डेटा के साथ एक तालिका है जो दो दिनों से कम समय की विंडो के साथ अनुरोधों से पूरे रीडिंग लोड की प्रक्रिया करती है (और हमारे पास इनमें से 95% हैं)। और हमारे पास प्रत्येक शार्क पर डेटा के 1/3 के साथ एक शार्प टेबल भी है, जो सभी ऐतिहासिक डेटा को पढ़ने की सुविधा प्रदान करता है। और यहां तक ​​कि अगर इस तरह के अनुरोध बहुत छोटे हैं, तो उनमें से लोड बहुत अधिक है।

सीपीयू के साथ क्या हो रहा है? ग्रेफाइट क्लस्टर में दर्ज और पढ़े गए डेटा की मात्रा में वृद्धि के परिणामस्वरूप, सर्वरों पर कुल सीपीयू भार भी बढ़ गया। यह कुछ इस तरह दिखता है।

मैं निम्नलिखित बारीकियों पर ध्यान आकर्षित करना चाहता हूं: सीपीयू का आधा हिस्सा कार्बन-सी-रिले (2018-09-05 से v3.2, जो मैट्रिक्स परिवहन के लिए जिम्मेदार है) में मैट्रिक्स की प्राथमिक और पार्सिंग प्रसंस्करण पर जाता है, जो छह में से तीन सर्वरों पर स्थित है। जैसा कि आप ग्राफ से देख सकते हैं, यह ये तीन सर्वर हैं जो TOP में हैं।

चेतावनी

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

आधारभूत संरचना टीमों के लिए पैस का उपयोग नहीं करने के लिए, हमने एक अलग रिपॉजिटरी का आयोजन किया है जिसे एलर्टिंग कहा जाता है। इसने फॉर्म की संरचना बनाई: टीम / प्रोजेक्ट / अलर्ट। श्याम। प्रत्येक अलर्ट के लिए। ओएमएल, हम टीमसिटी में एक अलग असेंबली बनाते हैं, जो परीक्षण चलाता है और मोइरा में अलर्ट की सामग्री को आगे बढ़ाता है।

इस प्रकार, हमारे सभी कर्मचारी एकल दृष्टिकोण का उपयोग करके अपने ट्रिगर्स, सूचनाओं और वृद्धि का प्रबंधन कर सकते हैं।

चूंकि पहले ही हमने GUI के माध्यम से ट्रिगर किया था, इसलिए हमने उन्हें yaml प्रारूप में अपलोड करने की क्षमता को लागू किया। प्राप्त याम्ल-दस्तावेज़ की सामग्री को सतर्क रूप से डाला जा सकता है। व्यावहारिक रूप से कोई अतिरिक्त परिवर्तन नहीं होने पर, और फिर विज़ार्ड में परिवर्तन को धकेलें। बिल्ड के दौरान, अलर्ट-ऑटोकॉनफ समझ जाएगा कि ऐसा ट्रिगर पहले से मौजूद है और इसे रेडिस में हमारी रजिस्ट्री में पंजीकृत करेगा।

और इतना समय पहले नहीं, हमें 24x7 इंजीनियरों की ड्यूटी शिफ्ट मिली थी। सेवा के लिए उन्हें ट्रिगर्स में स्थानांतरित करने के लिए, यह आपके अलर्ट में पर्याप्त है। केवल "यदि आप इसे देखते हैं तो क्या करना है" के विवरण को सही ढंग से भरने के लिए, टैग [24x7] डालें और विज़ार्ड में बदलावों को आगे बढ़ाएं। अलर्ट रोल करने के बाद। ओएमएल, इसमें वर्णित सभी ट्रिगर्स स्वचालित रूप से 24-घंटे की शिफ्ट मॉनिटरिंग 24x7 के तहत आ जाएंगे। U - सरलीकृत करें! ब्यूटी!

व्यापार मैट्रिक्स संग्रह

बिजनेस मेट्रिक्स को इकट्ठा करने और प्रसंस्करण के बारे में पिछले लेख के बाद से, हमारा बायोइनो और भी बेहतर हो गया है।

1. कॉन्सल के माध्यम से एक नेता को चुनने के बजाय, अंतर्निहित रग का उपयोग किया जाता है ।
2. ग्रेफाइट प्रारूप में टैग को सही ढंग से संसाधित किया जाता है ।
3. अब आप बायोइनो (StatsD-server) को एक एजेंट के रूप में उपयोग कर सकते हैं।
4. अद्वितीय मानों की गणना के लिए, "सेट" प्रारूप समर्थित है।
5. मैट्रिक्स का अंतिम एकत्रीकरण कई थ्रेड्स में किया जा सकता है।
6. डेटा को कई समानांतर कनेक्शनों में ग्रेफाइट चंक्स में भेजा जा सकता है।
7. तय सभी कीड़े मिले।

अब यह इस तरह काम करता है।

हमने सभी बड़े बड़े मीट्रिक जनरेटर के बगल में स्टैट्सड एजेंटों को सक्रिय रूप से पेश करना शुरू किया: मोनोलिथ के उदाहरणों के साथ कंटेनरों में, सेवाओं के बगल में k8s फली में, बुनियादी ढांचे के घटकों के साथ मेजबानों पर आदि।
Statsd एजेंट अनुप्रयोग के बगल में स्थित है। यह यूडीपी पर इस एप्लिकेशन से सभी समान मैट्रिक्स को स्वीकार करता है, लेकिन अब नेटवर्क सबसिस्टम (लिनक्स कर्नेल में अनुकूलन के कारण) का उपयोग नहीं करता है। सभी घटनाओं को पूर्व-एकत्र किया जाता है, और हर सेकंड (अंतराल को कॉन्फ़िगर किया जा सकता है) एकत्र किए गए डेटा को Cap'n प्रोटो प्रारूप में StatsD सर्वर (बायोयिनो0 [1-3]) के मुख्य क्लस्टर में भेजा जाता है।

मेट्रिक्स की आगे की प्रक्रिया और एकत्रीकरण, स्टैट्सड क्लस्टर में एक नेता की पसंद, और ग्रेफाइट के लिए नेता द्वारा मीट्रिक भेजने व्यावहारिक रूप से अपरिवर्तित हैं। इसके बारे में आप हमारे पिछले लेख में विस्तार से पढ़ सकते हैं।

संख्या के लिए, वे इस प्रकार हैं।

प्राप्त StatsD घटनाओं का ग्राफ

मेट्रिक्स का ग्राफ स्टैट्सडी से ग्रेफाइट में भेजा जाता है

कुल मिलाकर

फिलहाल निगरानी घटकों के बीच बातचीत की सामान्य योजना इस प्रकार है।

मैट्रिक्स की कुल संख्या: 2 189 484 898 474।
मैट्रिक्स के भंडारण की कुल गहराई: 3 वर्ष।
अद्वितीय मीट्रिक नामों की संख्या: 6 585 413 171।
ट्रिगर की संख्या: 1053, वे 1 से 15k मीट्रिक तक सेवा करते हैं।

निकट भविष्य की योजनाएं:

• टैग की गई मीट्रिक संग्रहण योजना में उत्पाद सेवाओं को स्थानांतरित करना शुरू करना;
• ग्रेफाइट क्लस्टर में तीन और सर्वर जोड़ें;
• लगातार ऊतक के साथ मोइरा दोस्त बनाएं;
• मॉनिटरिंग टीम पर एक और डेवलपर खोजें ।

मुझे यहां टिप्पणियों और प्रश्नों के लिए खुशी होगी - लिखना। और मैं 7 नवंबर को हाईलोड ++ पर भी प्रदर्शन करूंगा, अगर आप वहां हैं, तो हम बात कर सकते हैं।