ग्रेफाइट का कार्बन एग्रीगेटर एक ही काम कर सकता है जब आंकड़े का उपयोग क्यों करें?

Question

मैं कई सर्वरों से मीट्रिक दिखाने के लिए ग्रेफाइट ग्राफिंग टूल की खोज कर रहा हूं, और ऐसा लगता है कि 'अनुशंसित' तरीका सभी मेट्रिक्स डेटा को पहले StatsD पर भेजना है। आंकड़े डेटा एकत्र करते हैं और इसे ग्रेफाइट (या बल्कि कार्बन) भेजता है।

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

स्टैट्सडी इस तरह की एकत्रीकरण भी प्रदान नहीं करता है जिसके बारे में मैं बात कर रहा हूं।

मेरा प्रश्न है - क्या मुझे अपने उपयोग के मामले में आंकड़ों का उपयोग करना चाहिए? मैं यहाँ कुछ भी याद कर रहा हूँ?

Answer 1

1. StatsD यूडीपी, जो carbon-aggregator.py प्रतिक्रिया करने के लिए धीमी गति से किया जा रहा है और अपने आवेदन में विलंबता शुरू करने का जोखिम को हटा से अधिक चल रही है। दूसरे शब्दों में, ढीला युग्मन।

2. स्टैट्सड इनबाउंड मेट्रिक्स का नमूनाकरण का समर्थन करता है, जो उपयोगी नहीं है जब आप नहीं चाहते हैं कि आपका एग्रीगेटर वर्णनात्मक आंकड़ों की गणना करने के लिए सभी डेटा बिंदुओं का 100% ले। उच्च-मात्रा कोड अनुभागों के लिए, 0.5% -1% नमूना दरों का उपयोग करना आम है ताकि StatsD को अधिभारित न किया जा सके।

3. स्टैट्सडी broad client-side समर्थन है।

Answer 2

क्योंकि ग्रेफाइट, एक न्यूनतम संकल्प है ताकि आप परिभाषित अंतराल के दौरान एक ही मीट्रिक के लिए दो अलग-अलग मान नहीं बचा सकता है। StatsD इस समस्या को पूर्व-समेकित करके हल करता है, और "अब पंजीकृत 1 उपयोगकर्ता" और "अब पंजीकृत 1 उपयोगकर्ता" कहने के बजाय यह कहता है "2 उपयोगकर्ता पंजीकृत"।

अन्य कारण है प्रदर्शन है क्योंकि:

1. आप यूडीपी, जो एक आग है के माध्यम से StatsD को डेटा भेजने और प्रोटोकॉल, राज्यविहीन, बहुत तेजी से
2. StatsD Etsy के कार्यान्वयन NodeJS जो भी बढ़ जाती है में है भूल जाते हैं बहुत प्रदर्शन

Answer 3

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

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

मैं कार्बन एग्रीगेटर और स्टैट्सडी (और Bucky, पायथन में एक स्टेटस डी कार्यान्वयन) के स्रोत कोड को देख रहा हूं, और वे सभी इतने सरल हैं कि मैं किसी भी विकल्प के लिए संसाधन उपयोग या प्रदर्शन के बारे में चिंता नहीं करता।

Answer 4

कार्बन एग्रीगेटर तरह लग रहा है और statsd सुविधाओं के संबंध तोड़ना सेट का समर्थन:

• statsd दर गणना और योग का समर्थन करता है, लेकिन समर्थन नहीं करता औसत
• कार्बन एग्रीगेटर औसत का समर्थन करता है को महत्व देता है, लेकिन दर गणना का समर्थन नहीं करता।

Answer 5

tldr: आप शायद statsd (या carbon-c-relay) अगर तुम कभी सर्वर विशेष योग या औसत देखना चाहते हैं चाहते हैं।

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

statsd उदाहरण: मानते हैं कि आपकी ग्रेफाइट भंडारण-schemas.conf फ़ाइल 10 सेकंड (डिफ़ॉल्ट) की एक न्यूनतम प्रतिधारण है और आपके आवेदन services.login.server1 लगभग 100 डेटा बिंदुओं हर 10 सेकंड भेज रहा है .count बिना किसी आंकड़े के 1 के साथ, ग्रेफाइट केवल प्रत्येक 10-सेकंड बाल्टी में प्राप्त अंतिम गणना को संग्रहीत करेगा। 100 वें संदेश प्राप्त होने के बाद, अन्य 99 डेटा पॉइंट फेंक दिए गए थे। हालांकि, यदि आप अपने एप्लिकेशन और ग्रेफाइट के बीच आंकड़े डालते हैं, तो यह ग्रेफाइट को कुल भेजने से पहले सभी 100 डेटापॉइंट्स को एक साथ जोड़ देगा। इसलिए, आंकड़ों के बिना आपका ग्राफ केवल इंगित करता है यदि 10 सेकंड अंतराल के दौरान एक लॉगिन हुआ। आंकड़े के साथ, यह इंगित करता है कि उस अंतराल के दौरान कितने लॉग इन हुए थे। (for example)

कार्बन एग्रीगेटर उदाहरण: मान लें कि आपके 200 विभिन्न 200 अलग रिपोर्टिंग मीट्रिक्स सर्वर (services.login.server1.response.time, services.login.server2.response.time, आदि) है । अपने ऑपरेशंस डैशबोर्ड पर आप इस ग्रेफाइट क्वेरी का उपयोग कर सभी सर्वरों में औसत का ग्राफ दिखाते हैं: भारित औसत (services.login.server * .response.time, services.login.server * .response.count, 2)। दुर्भाग्य से, इस ग्राफ को प्रस्तुत करने में 10 सेकंड लगते हैं। इस समस्या को हल करने के लिए, आप अपने सभी सर्वरों में औसत की गणना करने के लिए कार्बन एग्रीगेटर नियम जोड़ सकते हैं और मान को एक नए मीट्रिक में संग्रहीत कर सकते हैं। अब आप केवल एक मीट्रिक खींचने के लिए अपने डैशबोर्ड को अपडेट कर सकते हैं (उदा। services.login.response.time)। नया मीट्रिक लगभग तुरंत प्रस्तुत करता है।

पक्ष नोट:

1. भंडारण-aggregation.conf में एकत्रीकरण नियमों भंडारण-schemas.conf में सभी भंडारण अंतराल को को छोड़कर प्रत्येक प्रतिधारण स्ट्रिंग के लिए पहले (छोटी) अवधारण अवधि लागू । उस पहली प्रतिधारण अवधि के लिए मीट्रिक के भीतर डेटा बिंदुओं को एकत्रित करने के लिए कार्बन-एग्रीगेटर का उपयोग करना संभव है। दुर्भाग्यवश, एग्रीगेशन-नियम.कॉम रेगेक्स पैटर्न के बजाय "ब्लॉब" पैटर्न का उपयोग करता है। इसलिए आपको प्रत्येक पथ गहराई और एकत्रीकरण प्रकार के लिए एक अलग समेकन-नियम.कॉफ़ फ़ाइल प्रविष्टि जोड़ने की आवश्यकता है।आंकड़े का लाभ यह है कि मेट्रिक भेजने वाला क्लाइंट मीट्रिक पथ में एन्कोडिंग करने के बजाय समेकन प्रकार निर्दिष्ट कर सकता है। जो आपको मीट्रिक पथ गहराई के बावजूद फ्लाई पर एक नया मीट्रिक जोड़ने की लचीलापन देता है। यदि आप कॉन्फ़िगर करना कार्बन एग्रीगेटर स्वचालित रूप से statsd की तरह एकत्रीकरण करने के लिए जब आप एक नया मीट्रिक जोड़ने के लिए चाहते थे, अपने एकत्रीकरण-rules.conf फ़ाइल कुछ इस तरह दिखेगा:

   <n1>.avg (10)= avg <n1>.avg$ 
   <n1>.count (10)= sum <n1>.count$ 
   <n1>.<n2>.avg (10)= avg <n1>.<n2>.avg$ 
   <n1>.<n2>.count (10)= sum <n1>.<n2>.count$ 
   <n1>.<n2>.<n3>.avg (10)= avg <n1>.<n2>.<n3>.avg$ 
   <n1>.<n2>.<n3>.count (10)= sum <n1>.<n2>.<n3>.count$ 
   ... 
   <n1>.<n2>.<n3> ... <n99>.count (10)= sum <n1>.<n2>.<n3> ... <n99>.count$ 
   

   नोट: अनुगामी "$" है ग्रेफाइट में की जरूरत नहीं 0.10+ (रिलीज पूर्व वर्तमान में) here is the relevant patch on github और यहाँ aggregation rules

2. weightedAverage समारोह पर मानक प्रलेखन है नया ग्रेफाइट 0.10 में है, लेकिन आम तौर पर averageSeries समारोह के रूप में लंबे समय से एक बहुत ही संख्या में दे देंगे के रूप में अपने भार समान रूप से संतुलित है। यदि आपके पास कुछ सर्वर हैं जो धीमे और सेवा दोनों कम अनुरोध हैं या आप परिशुद्धता के लिए केवल एक स्टिकर हैं, तो आप अभी भी ग्रेफाइट 0.9 के साथ भारित औसत की गणना कर सकते हैं। यदि statsd ग्राहक बॉक्स यह भी नेटवर्क लोड कम कर देता है पर चलाया जाता है

   divideSeries(sumSeries(multiplySeries(a.time,a.count), multiplySeries(b.time,b.count)),sumSeries(a.count, b.count)) 
   

3. : आप सिर्फ इस तरह एक अधिक जटिल क्वेरी बनाने के लिए की जरूरत है। हालांकि, सिद्धांत रूप में, आप क्लाइंट पक्ष पर भी कार्बन-एग्रीगेटर चला सकते हैं। हालांकि, यदि आप आंकड़े क्लाइंट पुस्तकालयों में से किसी एक का उपयोग करते हैं, तो आप अपने एप्लिकेशन मशीन के सीपीयू (जैसे लूपबैक udp पैकेट बनाने) पर लोड को कम करने के लिए नमूनाकरण का भी उपयोग कर सकते हैं। इसके अलावा, आंकड़े स्वचालित रूप से एक इनपुट इनपुट मीट्रिक (योग, माध्य, न्यूनतम, अधिकतम, इत्यादि) पर कई अलग-अलग एकत्रीकरण कर सकते हैं

4. यदि आप प्रतिक्रिया समय को एकत्र करने के लिए प्रत्येक ऐप सर्वर पर आंकड़े का उपयोग करते हैं, और फिर उन मानों को फिर से एकत्रित करते हैं कार्बन एग्रीगेटर का उपयोग कर ग्रेफाइट सर्वर पर, आप अनुरोध के बजाय ऐप सर्वर द्वारा भारित औसत प्रतिक्रिया समय के साथ समाप्त होते हैं। जाहिर है, यह केवल एक औसत या top_90 एकत्रीकरण नियम का उपयोग करके एकत्रित करने के लिए महत्वपूर्ण है, और न्यूनतम, अधिकतम या योग नहीं। यह भी, अगर आपका भार असंतुलित है तो यह केवल मायने रखता है। एक उदाहरण के रूप में: मान लें कि आपके पास 100 सर्वर का समूह है, और अचानक 1 सर्वर को 99% यातायात भेजा जाता है। परिणामस्वरूप, प्रतिक्रिया समय उस सर्वर पर चौगुनी है, लेकिन अन्य 99 सर्वरों पर स्थिर रहता है। यदि आप क्लाइंट साइड एकत्रीकरण का उपयोग करते हैं, तो आपका समग्र मीट्रिक केवल 3% तक बढ़ जाएगा। लेकिन यदि आप एक सर्वर-साइड कार्बन एग्रीगेटर में अपने सभी एकत्रीकरण करते हैं, तो आपका समग्र मीट्रिक लगभग 300% तक बढ़ जाएगा।

5. carbon-c-relay अनिवार्य रूप से सी में लिखित कार्बन-एग्रीगेटर के लिए एक ड्रॉप-इन प्रतिस्थापन है। इसने प्रदर्शन और रेगेक्स-आधारित मिलान नियमों में सुधार किया है। उपरोक्त यह है कि आप एक ही सरल regex- आधारित कॉन्फ़िगरेशन फ़ाइल में सभी आंकड़े-शैली डेटापॉइंट एकत्रीकरण और कार्बन-रिले शैली मीट्रिक एकत्रीकरण और बहु-स्तरित समेकन जैसी अन्य साफ-सुथरी सामग्री कर सकते हैं।

6. अगर आप cyanite बैक-एंड कार्बन कैश के बजाय का उपयोग करें, तो cyanite इंट्रा-मीट्रिक औसतन आप के लिए स्मृति में (version 0.5.1 के रूप में) या पढ़ने में समय (संस्करण में < 0.1.3 वास्तुकला करना होगा)।