अधिकांश लॉग फाइलें बाइनरी प्रारूप के बजाय सादे पाठ का उपयोग क्यों करती हैं?

81

लॉगिंग कुछ ऐसा है जो आवश्यक है लेकिन (अपेक्षाकृत) शायद ही कभी इस्तेमाल किया जाता है। जैसे कि इसे स्टोरेज के लिहाज से ज्यादा कॉम्पैक्ट बनाया जा सकता है।

उदाहरण के लिए आमतौर पर लॉग किए गए डेटा जैसे कि आईपी, तिथि, समय और अन्य डेटा जिन्हें एक पूर्णांक के रूप में दर्शाया जा सकता है उन्हें पाठ के रूप में संग्रहीत किया जा रहा है।

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

कुछ लोग कह सकते हैं कि यह इतना मामूली मुद्दा है कि यह वास्तव में मायने नहीं रखता है, लेकिन इस तरह के तंत्र के निर्माण के लिए आवश्यक प्रयास को ध्यान में रखते हुए इसका कोई मतलब नहीं है। कोई भी व्यक्ति अपने खाली समय में इसे दो दिनों के लिए बना सकता है, लोग ऐसा क्यों नहीं करते?

logging storage

— php_nub_qq
स्रोत

20

मैं आपके दावे को चुनौती दूंगा कि लोग ऐसा न करें। कई करते हैं। कुछ नहीं, यकीन है, लेकिन बहुत कुछ करते हैं।

— 15

55

"अगर आपकी मशीन बहुत करीब से चलती है तो यह सीमा है कि इस तरह के मुद्दे वास्तव में मायने रखेंगे, आपको सबसे अधिक गंभीर समस्याएं होने की संभावना है ..."

— gnat

44

> यदि लॉगिंग को बाइनरी डेटा के रूप में संग्रहीत किया गया था, तो बहुत सारे स्थान को संरक्षित किया जा सकता है खैर, पुराने लॉग आमतौर पर संकुचित होते हैं।

— leonbloy

89

एक मशीन पर एक पाठ लॉग पढ़ना जो आधा टूट गया है, उसे विश्लेषण करने के लिए एक बाइनरी की आवश्यकता पर एक बड़ा लाभ हो सकता है।

— 18

23

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

— null

163

systemdबाइनरी प्रारूप में अपनी लॉग फ़ाइलों को प्रसिद्ध रूप से संग्रहीत करता है। मैंने इसके साथ मुख्य मुद्दे सुने हैं:

यदि लॉग दूषित हो जाता है, तो इसे पुनर्प्राप्त करना कठिन है क्योंकि इसके लिए विशेषज्ञ टूलिंग की आवश्यकता होती है
वे मानव पठनीय नहीं हैं, इसलिए आप इस तरह के रूप में मानक उपकरण का उपयोग नहीं कर सकते हैं vi, grep, tailआदि उनके विश्लेषण के लिए

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

मेरा तर्क है कि व्यवहार में डिस्क स्थान लाभ अपेक्षाकृत छोटा (और कम) है। यदि आप बड़ी मात्रा में लॉगिंग स्टोर करना चाहते हैं तो रोल किए गए लॉग को ज़िप करना वास्तव में काफी कुशल है।

संतुलन पर, टूलिंग और परिचितता के फायदे संभवतः अधिकांश मामलों में पाठ लॉगिंग के पक्ष में होंगे।

— एलेक्स
स्रोत

3

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

— 5gon12eder 15

97

"प्रसिद्ध", "कुख्यात" की तरह

— whatsisname

4

pf (फ़ायरवॉल) द्विआधारी में भी लॉग करता है, विशेष रूप से tcpdump प्रारूप में

— नील मैकगिगन

3

@Hatshepsut लुढ़का लॉग: लॉग आउटपुट एक फ़ाइल को लिखता है, myapp.logआधी रात तक कहता है , और फिर उस फ़ाइल को ले जाता है myapp.log.1, और एक नई myapp.logफ़ाइल पर लिखना शुरू करता है। और बूढ़े myapp.log.1चले जाते हैं myapp.log.2, और इसी तरह, वे सभी साथ चलते हैं। इस प्रकार, myapp.logहमेशा वर्तमान एक है। या वे एक निश्चित आकार तक पहुँचने पर स्विच कर सकते हैं। हो सकता है कि उन्होंने फ़ाइल नाम में तारीख / समय लगा दिया हो। कई लॉगिंग चौखटे इस तरह की बात का समर्थन करते हैं।

— सुसानडब्ल्यू

13

@ हत्शेपसट शब्द rotatingका उपयोग उस चीज़ से भी किया जाता है जो मैं जानता हूँ।

— जॉर्ज डी

89

अधिकांश लॉग फाइलें बाइनरी प्रारूप के बजाय सादे पाठ का उपयोग क्यों करती हैं?

यूनिक्स दर्शन विकिपीडिया लेख में शब्द "पाठ" के लिए खोजें , उदाहरण के लिए आप इस तरह के बयान पाएंगे:

McIlroy, बेल बेल्स CSRC (कम्प्यूटिंग साइंसेज रिसर्च सेंटर) के प्रमुख, और यूनिक्स पाइप के आविष्कारक, [9] ने यूनिक्स दर्शन को इस प्रकार संक्षेप में प्रस्तुत किया: [१०]

यह यूनिक्स दर्शन है: ऐसे प्रोग्राम लिखें जो एक काम करते हैं और इसे अच्छी तरह से करते हैं। एक साथ काम करने के लिए कार्यक्रम लिखें। पाठ धाराओं को संभालने के लिए प्रोग्राम लिखें, क्योंकि यह एक सार्वभौमिक इंटरफ़ेस है।

या उदाहरण के लिए, यूनिक्स दर्शन की मूल बातें से ,

रचना का नियम: डिजाइन कार्यक्रमों को अन्य कार्यक्रमों के साथ जोड़ा जाना है।

यदि आपके कोई भी प्रोग्राम एक-दूसरे से बात नहीं कर सकते हैं, तो अधूरा मोनोलिथ प्रोग्रामिंग करने से बचना मुश्किल है।

यूनिक्स परंपरा दृढ़ता से लेखन कार्यक्रमों को प्रोत्साहित करती है जो सरल, पाठ्य, धारा-उन्मुख, उपकरण-स्वतंत्र प्रारूप को पढ़ते और लिखते हैं। क्लासिक यूनिक्स के तहत, जितना संभव हो उतने कार्यक्रम सरल फिल्टर के रूप में लिखे गए हैं, जो इनपुट पर एक सरल पाठ स्ट्रीम लेते हैं और इसे आउटपुट पर एक और सरल पाठ स्ट्रीम में संसाधित करते हैं।

लोकप्रिय पौराणिक कथाओं के बावजूद, यह प्रथा इष्ट नहीं है क्योंकि यूनिक्स प्रोग्रामर ग्राफिकल यूजर इंटरफेस से नफरत करते हैं। ऐसा इसलिए है क्योंकि यदि आप ऐसे प्रोग्राम नहीं लिखते हैं जो सरल पाठ धाराओं को स्वीकार करते हैं और उनका उत्सर्जन करते हैं, तो कार्यक्रमों को एक साथ हुक करना अधिक कठिन है।

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

कोई भी व्यक्ति अपने खाली समय में इसे दो दिनों के लिए बना सकता है, लोग ऐसा क्यों नहीं करते?

बाइनरी में लॉग फ़ाइल को संग्रहीत करना केवल शुरुआत (और तुच्छ) है। फिर आपको इसके लिए टूल लिखना होगा:

संपूर्ण लॉग फ़ाइल प्रदर्शित करें ( edit)
इसकी शुरुआत को पढ़े बिना, लॉग के अंत को प्रदर्शित करें ( tail -f)
फ़ाइल में सामान खोजें ( grep)
केवल चयनित / दिलचस्प सामग्री को प्रदर्शित करने के लिए फ़िल्टर (एक मनमाने ढंग से जटिल फिल्टर अभिव्यक्ति का उपयोग करके)
लॉग को किसी और को ईमेल करें जिसके पास आपका लॉग-फाइल-डिकोडर-सॉफ्टवेयर नहीं है
लॉग फ़ाइल के टुकड़े को कॉपी-पेस्ट करें
लॉग फ़ाइल पढ़ें जबकि प्रोग्राम (जो लॉग फ़ाइल बनाता है) अभी भी विकसित और डीबग किया जा रहा है
सॉफ़्टवेयर के पुराने संस्करणों से लॉग फ़ाइलें पढ़ें (जो ग्राहक साइटों पर तैनात हैं और चल रहे हैं)।

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

— ChrisW
स्रोत

24

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

— सुसानडब्ल्यू

2

निष्पक्ष होना, पढ़ने के लिए बुनियादी क्वेरी टूल के साथ संयुक्त SQLite DB में अपने लॉग को संग्रहीत करना उन सभी सुविधाओं को प्रदान करेगा जो आप बॉक्स से बाहर उल्लेख करते हैं। ;)

— jpmc26

3

@ jpmc26 हाँ आप लॉग फ़ाइल को तब तक पढ़ सकते हैं, जब तक आप इसे किसी पाठ प्रारूप में बदल सकते हैं ...

— क्रिस डब्ल्यूटी

1

जैसा कि अन्य टिप्पणियों में कहा गया है: पाठ फ़ाइलों को आसानी से और कुशल संकुचित किया जा सकता है। लेकिन संपीड़न को 'डेटा' में होने की आवश्यकता नहीं है। संपीड़न फ़ाइल सिस्टम में किया जा सकता है। इसलिए आप सभी उपकरणों के लिए सादे पाठ का उपयोग कर सकते हैं और इसमें कोई व्यर्थ डिस्क स्थान नहीं है।

— बर्न विल्के

2

@ JefréN। यदि मैं tail -fएक बहु-गीगाबाइट लॉग फ़ाइल पर चलता हूं , तो यह फ़ाइल के अंत में पहुंच जाता है ('रीड' के बिना 'का उपयोग करके') और फिर फ़ाइल के अंत में रीड-एंड-डिस्प्ले दिखाता है। इसे पूरी फाइल को डीकोड / डीकोड करने की आवश्यकता नहीं है।

— क्रिस डब्ल्यूटी

49

यहां बहुत सारे बहस योग्य अनुमान हैं।

लॉगिंग मेरे पास मौजूद हर काम का एक अभिन्न अंग रहा है। यदि आप अपने अनुप्रयोगों के स्वास्थ्य पर किसी भी प्रकार की दृश्यता चाहते हैं तो यह आवश्यक है। मुझे संदेह है कि यह "फ्रिंज" का उपयोग है; अधिकांश संगठन जिन्हें मैं लॉग के साथ शामिल करता हूं, वे बहुत महत्वपूर्ण हैं।

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

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

— रॉबर्ट हार्वे
स्रोत

19

"आप एक डेटाबेस में लॉग को भी स्टोर कर सकते हैं, जहां आप उनसे पूछताछ कर सकते हैं और सांख्यिकीय रूप से उनका विश्लेषण कर सकते हैं।" पिछली नौकरी में, हमारे पास एक कस्टम टूल था जो हमारे (पाठ-आधारित) लॉग्स को इस उद्देश्य के लिए डेटाबेस में आयात करता है।

— मेसन व्हीलर

5

मैं पतली हूँ कि ओपी का मतलब _ "एसएसडी जहां राइट्स सीमित हैं" यह तथ्य है कि एसएसडी में एक सीमित लेखन / मिटा चक्र है और एक सेक्टर पर बहुत अधिक लिखना डिवाइस के सेवा जीवन को कम कर देता है। उसका मतलब यह नहीं था कि लेखन खो जाता है।

— ट्यूलेंस कोरडोवा

4

@ TulainsCórdova: हाँ, मुझे पता था कि उसका क्या मतलब था।

— रॉबर्ट हार्वे

2

@DocSalvager: मैंने अन्यथा जोर नहीं दिया।

— रॉबर्ट हार्वे

2

@ TulainsCórdova - एसएसडी लिखने की सीमाएं इन दिनों आम तौर पर बहुत अधिक हैं। यहां तक कि कम-लागत वाले उपभोक्ता ग्रेड SSDs के पास लिखने के चक्र पर निर्माता वारंटियां हैं जो डिवाइस के आकार के सैकड़ों गुना अधिक समय तक चलती हैं, और MTBFs जो आपको डिवाइस की क्षमता के हजारों गुना लिखने के लिए कवर करेंगे। और एक वाणिज्यिक सेटिंग में आपको उच्च अंत वाले उपकरणों का उपयोग करना चाहिए, जिनमें बहुत बड़ा लेखन चक्र सीमा है और उन्हें कम से कम 5 साल के चक्र पर प्रतिस्थापित किया जाना चाहिए, जब तक कि आप प्रति दिन 10% भंडारण क्षमता नहीं लिख रहे हों, मुझे नहीं लगता है चिंता की कोई बात नहीं है।

— जूल्स

36

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

यदि आप एक गैर-पाठ प्रारूप का उपयोग करते हैं, तो आपको तुरंत बाधा का सामना करना पड़ता है: आप द्विआधारी लॉग कैसे पढ़ते हैं? लॉग-रीडिंग टूल के साथ, जो आपके प्रोडक्शन सर्वर पर नहीं है! या यह है, लेकिन ओह प्रिय, हमने एक नया क्षेत्र जोड़ा है और यह पुराना पाठक है। क्या हमने यह परीक्षण नहीं किया? हां, लेकिन किसी ने इसे यहां तैनात नहीं किया। इस बीच, आपकी स्क्रीन आपको पिंग करने वाले उपयोगकर्ताओं के साथ प्रकाश करना शुरू कर रही है।

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

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

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

तो, बाइनरी का उपयोग करने से क्या संभावित लाभ उत्पन्न हो सकते हैं? अंतरिक्ष दक्षता की एक छोटी राशि - तेजी से महत्वहीन। कम (या छोटा) लिखते हैं? खैर, हो सकता है - वास्तव में, लिखने की संख्या डिस्क-कमिट की संख्या से संबंधित होगी, इसलिए यदि लॉग-लाइन डिस्क को ब्लॉक करने की तुलना में काफी छोटी है, तो एसएसडी वैसे भी नए ब्लॉक को असाइन करेगा। तो, बाइनरी एक उपयुक्त विकल्प है अगर:

आप बड़ी मात्रा में संरचित डेटा लिख रहे हैं
लॉग को विशेष रूप से जल्दी से बनाया जाना है
आपको "समर्थन शर्तों" के तहत उनका विश्लेषण करने की आवश्यकता नहीं है

लेकिन यह अनुप्रयोग लॉगिंग की तरह कम लग रहा है; ये आउटपुट फाइल या एक्टिविटी रिकॉर्ड हैं। उन्हें एक फ़ाइल में रखना शायद उन्हें डेटाबेस में लिखने से केवल एक कदम दूर है।

संपादित करें

मुझे लगता है कि "प्रोग्राम लॉग" (लॉगिंग फ्रेमवर्क के अनुसार) बनाम "रिकॉर्ड" (एक्सेस लॉग्स, लॉगिन रिकॉर्ड आदि) के बीच यहां एक सामान्य भ्रम है। मुझे संदेह है कि प्रश्न उत्तरार्द्ध से सबसे अधिक निकटता से संबंधित है, और उस मामले में यह मुद्दा बहुत कम परिभाषित है। यह एक संदेश-रिकॉर्ड या गतिविधि लॉग के लिए पूरी तरह से स्वीकार्य है एक कॉम्पैक्ट प्रारूप में, विशेष रूप से जब यह समस्या निवारण के बजाय अच्छी तरह से परिभाषित और विश्लेषण के लिए उपयोग होने की संभावना है। ऐसा करने वाले टूल में शामिल हैं tcpdumpऔर यूनिक्स सिस्टम मॉनिटर sar। दूसरी ओर प्रोग्राम लॉग बहुत अधिक तदर्थ हो जाते हैं।

— SusanW
स्रोत

1

यहां तक कि यूनिक्स /var/log/utmp/ wtmp बाइनरी हैं । वे रिकॉर्ड करते हैं जो वर्तमान में किस tty पर लॉग इन किया गया है (इसलिए वे सिर्फ बढ़ते नहीं हैं), लेकिन वे लॉगिंग का एक रूप हैं। (और यह सस्ते में उन्हें पार्स करने में सक्षम होने के लिए उपयोगी है, क्योंकि विभिन्न सामान्य आदेश जैसे whoकि बस ऐसा ही करते हैं।)

— पीटर कॉर्ड्स

1

@PeterCordes बहुत सच है। फिर से, अच्छी तरह से परिभाषित डेटा। संरचित रिकॉर्ड। और निश्चित रूप से, सभी पैमानों पर गति और आकार उन दिनों में महत्वपूर्ण विचार थे।

— सुसानडब्ल्यू

9

कुछ हद तक बाइनरी लॉग का एक उदाहरण व्यापक प्रसार है: विंडोज इवेंट लॉग। समर्थक पक्ष पर, यह लॉग संदेशों को लगभग बिना किसी लागत के संभवतः काफी चिंताजनक (और इस प्रकार उम्मीद के मुताबिक मददगार) होने की अनुमति देता है, संभवतः ऐसा कुछ

चेतावनी: पिछले 90 सेकंड में 517 वस्तुओं के द्वारा फोबर्स की कतार बढ़ी है। यदि यह प्रति दिन एक बार होता है, तो चिंता की कोई बात नहीं है। यदि यह अधिक बार या तीव्र उत्तराधिकार में होता है, तो आप फोबार एप्लिकेशन को उपलब्ध रैम की मात्रा की जांच करना चाह सकते हैं। अगर यह 12345 ईवेंट के साथ होता है, तो आप डेटा के नुकसान को रोकने के लिए एक अप्रचलित डेटाबेस का उपयोग करते हैं और आप 1-555-12345 पर बेहतर कॉल समर्थन करते हैं।

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

डनो, "517" और "90" के साथ कुछ।

और अब किसी भी तरह से मददगार नहीं है।

— हेगेन वॉन एटिजन
स्रोत

9

यह उल्लेख नहीं करने के लिए कि विंडोज इवेंट लॉग में कुछ ढूंढना एक बुरा सपना हो सकता है। यह निश्चित रूप से मुझे एक साधारण पाठ फ़ाइल के लिए लंबा बनाता है।

— माइकल हैम्पटन

4

रुको। क्या आप दो (या अधिक) लॉग प्रविष्टियों को एक साथ देखना चाहते थे ? खैर बहुत बुरा हुआ।

— एरिक टावर्स

2

मेरा जवाब था "विंडोज इवेंट लॉग, पर्याप्त कहा।"

— क्रेग

इवेंट व्यूअर के लिए संसाधनों के गुम होने का मेरा अनुभव ऐसे उपकरणों के साथ रहा है जिनके पास स्थापित करने के लिए संसाधन नहीं हैं , लेकिन उस मामले में, AFAIR, अभी भी रिपोर्टिंग प्रोग्राम से वास्तविक जानकारी की एक पंक्ति है, तल पर, विंडोज के समाप्त होने के बाद ' संसाधन गायब हो सकता है या दूषित हो सकता है "स्पील।

— अंडरस्कोर_ड

5

पाठ और बाइनरी के बीच चयन करने से पहले आप जो दो मुख्य प्रश्न पूछना चाहेंगे, वे हैं:

मेरे दर्शक कौन हैं?
मुझे क्या सामग्री संप्रेषित करने की आवश्यकता है?

एक आम राय यह है कि लॉग संदेश के श्रोता एक इंसान हैं। यह स्पष्ट रूप से एक सही धारणा नहीं है, क्योंकि वहाँ लॉग आउट क्रॉलिंग स्क्रिप्ट बहुत सारे हैं, लेकिन यह एक आम है। इस मामले में, यह एक माध्यम में जानकारी को व्यक्त करने के लिए समझ में आता है, जिसके साथ मनुष्य सहज हैं। पाठ में इस माध्यम के होने की एक लंबी परंपरा है।

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

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

— Cort Ammon
स्रोत

5

TL; DR: आकार वास्तव में मायने नहीं रखता है, लेकिन उपयोग की सुविधा है

सबसे पहले, अल्पकालिक लॉग स्टोरेज के लिए पाठ और बाइनरी प्रारूपों के संबंधित लाभों की तुलना करना एक महत्वपूर्ण सवाल है, आकार वास्तव में कोई फर्क नहीं पड़ता। इसके दो कारण हैं:

लॉग अत्यधिक अनावश्यक जानकारी है जो बहुत अच्छी तरह से संपीड़ित करेगा: मेरे अनुभव में संकुचित लॉग फ़ाइलों को देखना दुर्लभ नहीं है, जिनका आकार मूल फ़ाइल के आकार का 5% या उससे कम है। नतीजतन, पाठ या बाइनरी प्रारूप का उपयोग करने से लॉग के लंबे समय तक भंडारण पर कोई औसत दर्जे का प्रभाव नहीं होना चाहिए।
यदि हम जो भी प्रारूप चुनते हैं, तो लॉग जल्दी से एक सर्वर डिस्क को भर देगा यदि हम एक "लॉग फाइल सिंक" को लागू नहीं करते हैं जो लॉग फाइल को दीर्घकालिक भंडारण प्लेटफॉर्म पर संपीड़ित और भेजता है। एक द्विआधारी प्रारूप का उपयोग करने से यह थोड़ा धीमा हो सकता है लेकिन यहां तक कि एक कारक 10 से बदलाव भी इतना महत्वपूर्ण नहीं होगा।

पाठ बनाम द्विआधारी लॉग प्रारूप

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

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

(कुछ समय पहले, मैंने इस बारे में एक ब्लॉग पोस्ट लिखा था ।)

— माइकल ले बारबियर ग्रुएनवाल्ड
स्रोत

4

लॉग फाइलें पाठ प्रारूप में होती हैं क्योंकि उन्हें किसी भी प्रकार के पाठ संपादक का उपयोग करके या कंसोल कमांड के माध्यम से सामग्री प्रदर्शित करके आसानी से पढ़ा जा सकता है।

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

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

— थॉमस मैथ्यूज
स्रोत

3

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

अधिक संसाधनों वाले सिस्टम में, अनुकूलन के लिए क्या-क्या आवश्यक नहीं है, इसका अनुकूलन करने के लिए योजनाओं का आविष्कार क्यों करें?

— JRobert
स्रोत

1

इसी तरह, जब एक 9,600 बॉड सीरियल पोर्ट पर पीसी से एम्बेडेड डिवाइस से वास्तविक समय में लॉग इन करने की कोशिश की जाती है, तो अक्सर डेटा को संपीड़ित करने या द्विआधारी प्रारूप का उपयोग करने की सलाह दी जाती है, ताकि ओवरफ्लो को रोका जा सके।

— मगग

3

लॉग फ़ाइलों का उद्देश्य मुद्दों की डीबगिंग में सहायता करना है। आमतौर पर, हार्ड ड्राइव स्पेस इंजीनियरिंग के समय की तुलना में बहुत सस्ता है। लॉग फाइलें पाठ का उपयोग करती हैं क्योंकि पाठ (जैसे tail -f) के साथ काम करने के लिए कई उपकरण हैं । यहां तक कि HTTP सादा-पाठ का उपयोग करता है (यह भी देखें कि हम http पर पाठ के बजाय बाइनरी क्यों नहीं भेजते हैं )।

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

— केसी कुबाल
स्रोत

2

चूंकि यह किसी और द्वारा लाया गया था, इसलिए मैं इंगित करना चाहता था कि HTTP / 2 (बाहर देखो!) द्विआधारी, द्वि-दिशात्मक, बहुसंकेतन संचार की अनुमति देता है। कोई भी डेवलपर्स जो खुद को अभिजात वर्ग के लिए पसंद करते हैं, उन्हें इसे वास्तविक रूप से सीखना चाहिए और फिर खुद से पूछना चाहिए कि ऐसा क्यों नहीं हुआ।

— शॉन विल्सन

3

दूषित भाग के चारों ओर एक दूषित पाठ फ़ाइल अभी भी पढ़ने योग्य है। एक दूषित बाइनरी फ़ाइल शायद आरामदायक हो, लेकिन यह भी नहीं हो सकती है। यहां तक कि अगर यह आरामदायक है, तो इसके लिए बहुत अधिक काम करना होगा। दूसरा कारण यह है कि एक बाइनरी लॉगिंग प्रारूप यह संभावना कम करता है कि एक "अस्थायी फ़िक्स" बनाने के लिए भीड़ के दौरान (उर्फ "सभी फ़िक्सेस का सबसे स्थायी") लॉगिंग समाधान का उपयोग उस चीज़ के बजाय किया जाएगा जिसे जल्दी बनाया जा सकता है।

— दिमित्री रुबानोविच
स्रोत

2

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

— कला स्वरी
स्रोत

2

हालांकि किसी और को नीचा दिखाया गया है, मैं इस तरह के जवाब को इंगित करना चाहता हूं, फिर भी मूल्य प्रदान करता है, यह दर्शाता है कि पाठ-आधारित लॉग को अभ्यास के सबसे खराब स्तरों पर भी उपयोगी बनाया जा सकता है, जिसमें आपके औसत प्रोग्रामर को वास्तव में परवाह नहीं है, लेकिन ऐसा करना चाहिए। +1

— शॉन विल्सन

समर्थन टिप्पणी के लिए धन्यवाद। मैं यह जानकारी देने की कोशिश करता हूं कि मुझे लगता है कि कम से कम कुछ लोगों के लिए उपयोगी होगा। यह वह है जो मैं चाहता हूं और उम्मीद करता हूं कि जब मैं एसओ जाऊंगा।

— बजे कला स्वरी

2

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

— Chris_F
स्रोत

2

मेरे मेनफ्रेम दिनों में, हमने एक कस्टम-डिज़ाइन बाइनरी लॉग प्रारूप का उपयोग किया। मुख्य कारण अंतरिक्ष को बचाने के लिए नहीं था, यह इसलिए था क्योंकि हम चाहते थे कि नए लोगों के साथ पुरानी प्रविष्टियों को अधिलेखित करके परिमित स्थान पर कब्जा किया जाए; आखिरी चीज जो हम चाहते थे, वह डिस्क के पूर्ण होने के कारण होने वाली समस्याओं का निदान करने में असमर्थ थी (1980 में डिस्क स्पेस में $ 1000 / एमबी की लागत आती थी, इसलिए लोग जरूरत से ज्यादा नहीं खरीदते थे)।

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

— माइकल के
स्रोत