अत्यधिक-उपलब्ध, वेब-सुलभ और स्केलेबल और ग्रेफाइट की मापनीय तैनाती

Question

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

मेरी अड़चन:

• प्रविष्टि बिंदु को HTTP बोलना चाहिए: यह एक साधारण HTTP-टू-यूडीपी-स्टैटसिड प्रॉक्सी (जैसे। httpstatsd onithub) द्वारा हल किया गया है।
• एकल सर्वर की विफलता का विरोध करना चाहिए (मर्फी के नियम से लड़ने के लिए :)
• क्षैतिज रूप से स्केलेबल होना चाहिए: वेबस्केल, बेबी! :)
• वास्तुकला को यथासंभव सरल (और सस्ता) रखा जाना चाहिए
• मेरे सर्वर वर्चुअल मशीन हैं
• डेटा फ़ाइलों को एक फाइलर उपकरण (NFS के साथ) पर संग्रहीत किया जाएगा
• मेरे पास निपटान में tcp / udp हार्डवेयर लोड बैलेंसर्स हैं

संक्षेप में, डेटा पथ: [ग्राहक] - (http) -> [http2statsd] - (udp) -> [आँकड़े] - (tcp) -> [ग्रेफाइट] - (nfs) -> [फ़िलर]

अब तक के मेरे निष्कर्ष:

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

इसलिए मैं सोच रहा था कि क्या किसी के पास ठोस आँकड़े / ग्रेफाइट परिनियोजन के लिए साझा करने के लिए अनुभव और सर्वोत्तम अभ्यास हैं?

Comments

स्टैट्सड के बारे में एटी के ब्लॉगपोस्ट पर टिप्पणियों को पढ़ते हुए, वे लिखते हैं कि वे हर 10 सेकंड में स्टैट्सड को 10,000-30,000 मेट्रिक्स खिलाते हैं। मैं एक http2statsd क्लाइंट को एक आँकड़ों सर्वर से जोड़ने का सुझाव दूंगा और अगर आँकड़ों के लिए भेजी गई मैट्रिक्स की संख्या एक अड़चन बन जाती है।

— pkhamre

क्या आपने इसे अंत में लागू किया? यदि हां, तो क्या आप विवरण साझा कर सकते हैं?

— gf_

Answer 1

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

ग्रेफाइट भी मुश्किल है, लेकिन उम्मीद है कि आपको अनंत पैमाने की आवश्यकता नहीं होगी और सेवा या कुछ अन्य स्थिर पैरामीटर द्वारा ठीक ठीक कर सकते हैं।

सबसे कठिन हिस्सा वेबएप स्केल कर रहा है, और यह इस बात पर बहुत निर्भर करता है कि आपके सबसे भारी ग्राफ़ क्वेरी क्या हैं। हालाँकि आप हमेशा सबसे मुश्किल ग्राफ के लिए डेटा को प्री-एग्रीगेट कर सकते हैं और अधिकांश लोड से छुटकारा पा सकते हैं।

मैं इस सभी दर्द से बचने के लिए काफी समय से HostedGraphite का उपयोग कर रहा हूं, इन लोगों ने कार्बन के लिए अपने स्वयं के Riak बैकएंड को लागू किया है और वहां सभी स्केलिंग करते हैं।