इवेंट लॉग मीट्रिक के लिए डेटा आर्किटेक्चर?

Question

मेरी सेवा में बड़ी संख्या में उपयोगकर्ता इवेंट हैं, और हम " डी के बाद से इवेंट टाइप टी की गणना" जैसी चीजें करना चाहते हैं ।

हम दो बुनियादी निर्णय लेने की कोशिश कर रहे हैं:

1. क्या स्टोर करना है? हर ईवेंट बनाम केवल एग्रीगेट को स्टोर करना

   • (ईवेंट लॉग स्टाइल) हर ईवेंट को लॉग करें और बाद में उन्हें गिनें;
   • (टाइम-सीरीज़ स्टाइल) हर दिन के लिए एक एकल "इवेंट ई के लिए तारीख डी " की कुल एकत्रित करता है

2. डाटा को कहाँ स्टोर करना है

   • एक रिलेशनल डेटाबेस में (विशेष रूप से MySQL)
   • एक गैर-संबंधपरक (NoSQL) डेटाबेस में
   • फ्लैट लॉग फ़ाइलों में (नेटवर्क के माध्यम से केंद्र पर एकत्र syslog-ng)

मानक अभ्यास क्या है / मैं विभिन्न प्रकार की प्रणालियों की तुलना के बारे में अधिक कहां पढ़ सकता हूं?

---

अतिरिक्त जानकारिया:

• कुल ईवेंट स्ट्रीम बड़ी है, संभावित रूप से प्रति दिन सैकड़ों हजारों प्रविष्टियां हैं
• लेकिन हमारी वर्तमान आवश्यकता केवल कुछ प्रकार की घटनाओं को गिनना है
• हमें आवश्यक रूप से कच्चे डेटा या एकत्रीकरण परिणामों के लिए वास्तविक समय तक पहुंच की आवश्यकता नहीं है

---

IMHO, "सभी घटनाओं को फाइलों में लॉग इन करें, बाद में उन्हें फ़िल्टर करने और स्ट्रीम को एग्रीगेट करने के लिए क्रॉल करें" एक सुंदर मानक UNIX वे है, लेकिन मेरे रेल-वाई हमवित्रों को लगता है कि कुछ भी वास्तविक नहीं है जब तक कि यह MySQL में न हो।

Comments

इस परियोजना पर कोई भाग्य?

— हाईवेलॉन

@hiwaylon हमने एक हाइब्रिड सिस्टम का उपयोग करके समाप्त कर लिया है: 1) MySQL जहां संभव हो (कम मात्रा) (एकत्रीकरण को आसान बनाता है SELECT...GROUP BY, आसानी से SELECTs के परिणामों को स्टोर कर सकता है ), 2) सरल बड़े पैमाने पर एकत्रीकरण और विज़ुअलाइज़ेशन के लिए ग्रेफाइट का उपयोग कर , और 3) संदर्भ के लिए पूर्ण घटनाओं को लॉग करना, और वास्तविक समय में डेटा प्रवाह के विवरण देखने के लिए। प्रत्येक वास्तव में अलग-अलग तरीकों से मूल्यवान रहा है।

— elliot42

यह एक महान समाधान की तरह लग रहा है, हम जो भी कर रहे हैं उसके साथ काफी समान है।

— हाईवेलॉन

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

— elliot42

अपडेट २०१६: काफ्का इन दिनों इस तरह की चीजें कर सकते हैं, कम से कम कच्चे भंडारण के लिए। फिर आप या तो उन्हें एक बड़े MapReduce या Spark job, या एक बड़े वेयरहाउस जैसे Vertica आदि में चिपका सकते हैं, यदि आप उन पर क्वेरी / एग्रीगेट करना चाहते हैं।

— elliot42

Answer 1

यह हमेशा निर्भर करता है, मैं आपको एक नया दृष्टिकोण प्रदान करने के लिए अपनी सलाह दूंगा

क्या स्टोर करना है? हर ईवेंट बनाम केवल एग्रीगेट को स्टोर करना

(ईवेंट लॉग स्टाइल) हर ईवेंट को लॉग करें और बाद में उन्हें गिनें;

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

(टाइम-सीरीज़ स्टाइल) हर दिन के लिए एक एकल "इवेंट ई के लिए तारीख डी" की संख्या को एकत्रित करता है

यदि आप इसे कल लागू करना चाहते हैं और इसका उपयोग करना चाहते हैं, तो यह काम कर सकता है, लेकिन तब यदि आपके पास कोई नई आवश्यकता है, या आप किसी अन्य कारण से किसी अन्य घटना से संबंधित हैं, तो आपको इस नए ईवेंट को जोड़ने की आवश्यकता है और फिर कुछ प्रतीक्षा करें लंबे समय के लिए अच्छा एकत्रीकरण स्तर है

डाटा को कहाँ स्टोर करना है

एक रिलेशनल डेटाबेस में (विशेष रूप से MySQL)

DB के लिए पहला विकल्प भारी हो सकता है यदि आप सभी घटनाओं को रिकॉर्ड करने के लिए जाते हैं, तो MySQL मुझे डर है कि मैं बहुत छोटा हो सकता हूं, और यदि आप RDBMS समाधानों के लिए जाना चाहते हैं तो आप बड़ा सोच सकते हैं, जैसे कि PostgreSQL या ओरेकल या DB2 जैसे मालिकाना। ।

लेकिन एकत्रीकरण के लिए एक अच्छा विकल्प होगा, उत्पन्न भार के आधार पर आप कोड में एकत्र कर सकते हैं और उन एकत्रीकरण को डीबी में सम्मिलित कर सकते हैं।

एक गैर-संबंधपरक (NoSQL) डेटाबेस में

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

फ्लैट लॉग फ़ाइलों में (syslog- एनजी के माध्यम से नेटवर्क पर केंद्रीय रूप से एकत्र)

मैं व्यक्तिगत रूप से आपको उस विकल्प के लिए जाने के लिए हतोत्साहित करूंगा, यदि फ़ाइल बहुत बढ़ जाती है, तो उसे पार्स करना अधिक कठिन होगा, लेकिन फिर भी मुझे मुख्य उद्देश्य नहीं पता है, सिस्टम पर चलना है, या बस लॉग की जांच करना है फ़ाइल ...

आशा करता हूँ की ये काम करेगा!

Comments

लॉग फ़ाइलों को आकार या लंबाई पर घुमाया जाना चाहिए। मुझे नहीं लगता कि अंतिम चिंता तब एक मुद्दा होगा।

— 13

Answer 2

मुझे लगता है कि DB में लॉग्स, काउंट और स्टोर परिणामों को पार्स करने का आपका विचार मान्य है। सुनिश्चित नहीं हैं कि आप वैसे भी DB में उन सभी कच्चे लॉग को चाहते हैं (मुझे लगता है कि आपने जो कहा है कि आपके हमवतन सुझाव दे रहे हैं)। आप पहले से ही फाइलों में लॉग को सही कर चुके हैं? आप बस उन संग्रह कर सकते हैं। मुझे लगता है कि बिट वास्तव में आपके उपयोग के मामले पर निर्भर करता है।

इस सवाल पर अपने "कमेंट आंसर" को आगे बढ़ाने के बारे में @ Thorbjørn Ravn Andersen से भी सहमत हैं।

Answer 3

आपके इच्छित उपयोग पर निर्भर करता है। यदि आपके पास एक मानक ग्राफ या रिपोर्ट है जो कुल मूल्यों को दिखा रहा है, तो आप बस घटनाओं को फ़िल्टर करना चाहेंगे क्योंकि वे अंदर आते हैं और उन्हें उपयुक्त बाल्टी में एकत्रित करते हैं। यदि आपको विशिष्ट घटनाओं में कमी करने की आवश्यकता है, या यदि आपको लगता है कि आप बाद में वापस जाना चाहते हैं और बाद में घटनाओं को फिर से वर्गीकृत करना चाहते हैं, तो आपको व्यक्तिगत घटनाओं को संग्रहीत करना चाहिए।

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

Comments

"डेटा एकत्र करें, लेकिन विवरण को एक (संपीड़ित) फ़ाइल में संग्रहीत करें"। विशेष रूप से महान सोचा, धन्यवाद!

— elliot42

क्या उल्लेखित ओपी को लॉग करने और फ़िल्टरिंग + एग्रीगेटिंग की मात्रा के साथ चिंता है जैसे वे आते हैं? ऐसा लगता है कि लॉग वॉल्यूम अधिक है और / या एकत्रीकरण गैर तुच्छ है, तो यह एक खतरनाक अड़चन हो सकती है।

— हाईवेलॉन

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

— TMN

Answer 4

किसी भी आर्किटेक्चर डेसीकॉन को व्यावसायिक जरूरतों से प्रेरित होना चाहिए। आपके मामले में, आपके पास यह अधिक स्पष्ट विचार होना चाहिए कि आप अपने लॉग सिस्टम से क्या जानकारी प्राप्त करना चाहते हैं और यह तय करने के लिए कि कैसे स्टोर करना है, कितनी बार आपको इस जानकारी की आवश्यकता होगी और आप परिणाम प्राप्त करने के लिए कितना समय इंतजार कर सकते हैं। । यह वही है जो लॉग कलेक्टरों, घटना के सहसंबंधकों और इसी तरह के अनुप्रयोगों के डिजाइन को चलाता है।

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

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