विभिन्न लॉग स्तरों का उपयोग कब करें

Question

घातकता के क्रम में, संदेशों को लॉग करने के विभिन्न तरीके हैं:

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

मैं कैसे तय करूं कि कब कौन सा उपयोग करना है?

उपयोग करने के लिए एक अच्छा विधर्मी क्या है?

Comments

काफी व्यापक सवाल। तो लॉगिंग की वास्तविक परिस्थितियों के आधार पर एक से अधिक उत्तर संभव है। noticeइस संग्रह में किसी को याद होगा कोई ...

— वुल्फ

@Wolf इस पदानुक्रम के अंतर्गत 'सूचना' कहाँ गिरेगी? सिर्फ रिकॉर्ड के लिए ...

— pgblu

noticeअच्छी तरह से गायब हो सकता है क्योंकि कुछ लोकप्रिय लॉगिंग सेवाएं जैसे log4j इसका उपयोग नहीं करते हैं।

— पैग्लू

Answer 1

मैं आम तौर पर निम्नलिखित सम्मेलन की सदस्यता लेता हूं:

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

Comments

क्यों आप जानकारी और चेतावनी नहीं कर सकते! वास्तव में "जानकारी" के बारे में एक चेतावनी नहीं है ...

— एम.पी.

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

— ग्रेविजोरक्स

@dzieciou यह आपकी विशेष जरूरतों पर निर्भर करता है। कभी-कभी यह घातक हो सकता है, कभी-कभी एक चेतावनी के रूप में। अगर मुझे एक महत्वपूर्ण सेवा से 4xx मिला है जो मैं निर्भर करता हूं और इसे जारी रख सकता हूं तो यह मेरे डिजाइन के लिए एक त्रुटि / घातक होगा। अगर मैं बाद में उपयोग के लिए कुछ डेटा कैश करने की कोशिश कर रहा था, लेकिन इसके बिना रह सकता है तो यह एक चेतावनी होगी। केवल एक बार जब मैं देख रहा हूं कि यह जानकारी किसी निगरानी एप की तरह है जो अपने यूआरएल की स्थिति की रिपोर्ट कर रहा है। इसलिए मैं जानकारी लेगा कि मुझे URL से 4xx मिला है और आगे बढ़ना है।

— ग्रेवॉरिक्सक्स

@GrayWizardx, मुझे लगता है कि दूसरा पहलू यह है कि क्या यह क्लाइंट है जिसे 4xx या सर्वर ने भेजा है। पहले मामले में, मैं ERROR (OMG, यह मेरी गलती है कि मैं सही अनुरोध तैयार नहीं कर सकता) का उपयोग करने के लिए अधिक इच्छुक हूं, जबकि बाद वाले मामले में मैं WARN लॉग इन करूंगा (यह क्लाइंट की गलती है जो वे अनुरोधों को सही ढंग से नहीं बना सकते हैं)

— dzieciou

मुझे संदेह है कि यह सच है - Debug - Information that is diagnostically helpful to people more than just developers (IT, sysadmins, etc.).। Logger.Debug केवल डेवलपर्स के लिए उत्पादन में बहुत खराब मुद्दों को ट्रैक करने के लिए है जैसेIf you want to print the value of a variable at any given point inside a for loop against a condition

— RBT

Answer 2

क्या आप चाहते हैं कि रात के मध्य में सिस्टम व्यवस्थापक को बिस्तर से बाहर निकलने का संदेश मिले?

• हां -> त्रुटि
• नहीं -> चेतावनी

Comments

ज्यादातर लोगों को छोड़कर अगर वे लोगों को रात में बिस्तर से बाहर निकालते हैं, तो परवाह नहीं है। हमने ग्राहकों को गंभीरता -1 डॉकसेट (100% आउटेज, अर्थात राष्ट्रीय) के लिए उठाया है क्योंकि एक साइट अपना काम नहीं कर सकती थी (उनका तर्क यह था कि यह उस साइट का 100% है)। हमने उन्हें उस स्कोर पर "शिक्षित" किया है।

— पाक्सिडाब्लो

FATALजब सिसादमिन उठता है, तो वह तय करता है कि उसने इसके लिए पर्याप्त भुगतान नहीं किया है, और वापस सो जाता है।

— मतीन उल्हाक

Answer 3

मुझे लॉग फ़ाइल देखने के परिप्रेक्ष्य से गंभीरता के बारे में सोचना अधिक उपयोगी लगता है।

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

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

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

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

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

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

Comments

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

— 17

डीबग के बारे में <-> ट्रेस: ​​ध्यान दें कि कम से कम जावा-भूमि में, प्राथमिकता का क्रम "डिबग> ट्रेस" है। यह कन्वेंशन सभी लॉगिंग फ्रेमवर्क है जो मुझे पता है (SLF4J, Logback, log4j, Apache Commons Logging, Log4Net, NLog)। इसलिए डिबग <ट्रेस मुझे असामान्य लगता है।

— 18

@ जय सिनकोटा महान जवाब। मुझे लगता है कि डीबग / ट्रेस वरीयता का विषय है, लेकिन निश्चित रूप से इस तरह के विवरण ऐप / कंपनी विशिष्ट होते हैं ताकि विभिन्न विचारों को देखने के लिए अच्छा हो।

— ग्रेवॉरिक्सक्स

मैंने अभी कई भाषाओं में 7 लॉगिंग फ्रेमवर्क का सर्वेक्षण किया है। तीन में से एक "ट्रेस" गंभीरता स्तर शामिल है, उन सभी में यह डिबग से कम गंभीर होने के रूप में है। यानी, ट्रेस <डीबग; मेरे पास कोई वास्तविक दुनिया के मामले नहीं हैं जहां विपरीत सच है। @RBT हमेशा डिबगर में तोड़ना संभव नहीं है। उदाहरण के लिए, webservers को समय की एक सीमित मात्रा में अनुरोधों की सेवा करनी चाहिए, या मल्टीथ्रेडेड और / या सर्वर वातावरण में मौजूद होना चाहिए जो कि उपकरण के लिए मुश्किल हो सकता है, या बग काफी दुर्लभ हो सकता है कि डिबगर एक विकल्प नहीं है। या आप नहीं जानते कि आप क्या देख रहे हैं।

— थानाटोस

@RBT मैं 4 वर्षों से जावा सिस्टम के साथ काम कर रहा हूं। मैं आपको बता सकता हूं कि आप जो पूछ रहे हैं वह पूरी तरह से अव्यावहारिक है। आईडीई डिबगिंग आपको केवल इतना दूर ले जा सकती है। एक निश्चित बिंदु पर, आपको बस यह समझने के लिए कि क्या चल रहा है और बग को ठीक करने के लिए किसी अन्य सिस्टम (अक्सर एक उत्पादन सर्वर) से डिबग लॉग की आवश्यकता होती है । आप सोच सकते हैं कि यह आपके स्थानीय आईडीई में प्रतिलिपि प्रस्तुत करने योग्य होना चाहिए, लेकिन यदि आप वास्तविक सिस्टम के साथ काम करते हैं, तो आप पाएंगे कि अक्सर कई कीड़े उत्पादन सर्वर के लिए अद्वितीय होते हैं।

— ADTC

Answer 4

यहाँ "लकड़हारा" क्या है की एक सूची है।

---

Apache log4j: §1 , §2

1. FATAL:

   [ v1.2 : ..] बहुत गंभीर त्रुटि घटनाएं जो संभवतः एप्लिकेशन को गर्भपात की ओर ले जाएंगी।

   [ v2.0 : ..] गंभीर त्रुटि जो एप्लिकेशन को जारी रखने से रोकेगी।

2. ERROR:

   [ v1.2 : ..] त्रुटि घटनाएं जो अभी भी एप्लिकेशन को चालू रखने की अनुमति दे सकती हैं।

   [ v2.0 : ..] आवेदन में त्रुटि, संभवतः पुनर्प्राप्त करने योग्य।

3. WARN:

   [ v1.2 : ..] संभावित हानिकारक स्थितियों।

   [ v2.0 : ..] घटना जो संभव हो सकती है [ sic ] एक त्रुटि की ओर ले जाती है।

4. INFO:

   [ v1.2 : ..] सूचनात्मक संदेश जो मोटे स्तर पर अनुप्रयोग की प्रगति को उजागर करते हैं।

   [ v2.0 : ..] सूचना के प्रयोजनों के लिए घटना।

5. DEBUG:

   [ v1.2 : ..] एक सूचना को डिबग करने के लिए सबसे उपयोगी उपयोगी सूचनाएँ हैं।

   [ v2.0 : ..] सामान्य डिबगिंग घटना।

6. TRACE:

   [ v1.2 : ..] की तुलना में महीन दाने वाली सूचनात्मक घटनाएँ DEBUG।

   [ v2.0 : ..] ठीक-ठीक डिबग संदेश, आमतौर पर एप्लिकेशन के माध्यम से प्रवाह को कैप्चर करता है।

---

Apache Httpd (हमेशा की तरह) ओवरकिल के लिए जाना पसंद करता है: d

1. उभरना :

   आपात स्थिति - प्रणाली अनुपयोगी है।

2. सतर्क :

   तुरंत कार्रवाई की जानी चाहिए [लेकिन प्रणाली अभी भी प्रयोग करने योग्य है]।

3. समालोचना :

   गंभीर स्थितियां [लेकिन कार्रवाई तुरंत नहीं की जानी चाहिए]।

   • " सॉकेट: एक सॉकेट पाने में विफल, बच्चा बाहर निकल रहा है "

4. त्रुटि :

   त्रुटि की स्थिति [लेकिन महत्वपूर्ण नहीं]।

   • " स्क्रिप्ट हेडर का समयपूर्व अंत "

5. चेतावनी :

   चेतावनी की स्थिति। [त्रुटि के करीब, लेकिन त्रुटि नहीं]

6. सूचना :

   सामान्य लेकिन महत्वपूर्ण [ उल्लेखनीय ] स्थिति।

   • " httpd: पकड़ा गया SIGBUS, कोर को डंप करने का प्रयास ... "

7. जानकारी :

   सूचनात्मक [और अनभिग्य]।

   • [" सर्वर एक्स घंटे के लिए चल रहा है। "]

8. डिबग :

   डिबग-स्तरीय संदेश [, अर्थात संदेश डी-बगिंग के लिए लॉग इन किए गए हैं ]]।

   • " कॉन्फ़िगरेशन फ़ाइल खोल रहा है ... "

9. ट्रेस 1 → ट्रेस 6 :

   ट्रेस संदेश [, संदेश ट्रेसिंग के लिए लॉग किए गए संदेश ]।

   • " प्रॉक्सी: एफ़टीपी: नियंत्रण कनेक्शन पूरा "
   • " प्रॉक्सी: कनेक्ट: रिमोट प्रॉक्सी से कनेक्ट अनुरोध भेजना "
   • " ओपनसेल: हैंडशेक: स्टार्ट "
   • " बफेड एसएसएल ब्रिगेड से पढ़ें, मोड 0, 17 बाइट्स "
   • " मैप लुकअप विफल:map=rewritemap key=keyname "
   • " कैश लुकअप विफल, नया मानचित्र लुकिंग मजबूर "

10. ट्रेस 7 → ट्रेस 8 :

    संदेश ट्रेस करें, बड़ी मात्रा में डेटा डंप करना

    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

---

अपाचे कॉमन्स-लॉगिंग: log

1. घातक :

   गंभीर त्रुटियां जो समयपूर्व समाप्ति का कारण बनती हैं। एक सांत्वना कंसोल पर तुरंत दिखाई देने की अपेक्षा करें।

2. त्रुटि :

   अन्य रनटाइम त्रुटियाँ या अप्रत्याशित स्थितियाँ। एक सांत्वना कंसोल पर तुरंत दिखाई देने की अपेक्षा करें।

3. चेतावनी :

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

4. जानकारी :

   दिलचस्प रनटाइम इवेंट (स्टार्टअप / शटडाउन)। उम्मीद करें कि ये तुरंत एक कंसोल पर दिखाई देंगे, इसलिए रूढ़िवादी रहें और न्यूनतम रखें।

5. डिबग :

   प्रणाली के माध्यम से प्रवाह पर विस्तृत जानकारी। इनकी अपेक्षा केवल लॉग में लिखे जाने की अपेक्षा करें।

6. ट्रेस :

   अधिक विस्तृत जानकारी। इनकी अपेक्षा केवल लॉग में लिखे जाने की अपेक्षा करें।

अपाचे कॉमन-लॉगिंग "बेस्ट प्रैक्टिस" एंटरप्राइज़ उपयोग के लिए डिबग और जानकारी के बीच अंतर करता है कि यह किस तरह की सीमाओं को पार करता है।

सीमाओं में शामिल हैं:

• बाहरी सीमाएँ - अपेक्षित अपवाद।

• बाहरी सीमाएँ - अप्रत्याशित अपवाद।

• आंतरिक सीमाएँ।

• महत्वपूर्ण आंतरिक सीमाएँ।

( इस बारे में अधिक जानकारी के लिए कॉमन्स-लॉगिंग गाइड देखें ।)

Answer 5

यदि आप समस्या से उबर सकते हैं तो यह एक चेतावनी है। यदि यह निरंतर निष्पादन को रोकता है तो यह एक त्रुटि है।

Comments

लेकिन फिर, त्रुटि और घातक त्रुटि के बीच अंतर क्या है?

— user192472

एक त्रुटि कुछ है जो आप करते हैं (जैसे एक गैर-मौजूद फ़ाइल पढ़ें), एक घातक त्रुटि कुछ ऐसा है जो आपको किया जाता है (उदाहरण के लिए स्मृति से बाहर)।

— इग्नासियो वाज़केज़-अब्राम्स

@ IgnacioVazquez-Abrams मुझे भेद करने का आपका तरीका पसंद है। लेकिन आपकी टिप्पणी किस पर आधारित है? आईओएस डेवलपर्स के बीच AFIAK यह एक अभिकर्ता लिखने के लिए सम्मेलन है जो fatalErrorएक फ़ाइल मौजूद नहीं होने पर संबंधित है। मूल रूप से यह आपके द्वारा कही गई बातों के विपरीत है।

— हनी

@ हनी: एक मोबाइल स्थिति में एक लापता फ़ाइल को एक घातक त्रुटि मानना ​​उचित है।

— इग्नासियो वाज़क्वेज़-अब्राम्स

Answer 6

मैं Syslog गंभीरता स्तरों को अपनाने की सिफारिश करूंगा DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY:। Http://en.wikipedia.org/wiki/Syslog#Severity_levels
देखें

उन्हें अधिकांश उपयोग के मामलों के लिए पर्याप्त सूक्ष्मता गंभीरता स्तर प्रदान करना चाहिए और मौजूदा लॉग-पार्सर्स द्वारा मान्यता प्राप्त है। हालांकि, आपको DEBUG, ERROR, EMERGENCYअपने ऐप की आवश्यकताओं के आधार पर केवल एक सबसेट लागू करने की स्वतंत्रता है ।

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

Comments

मुझे एक ट्रेस लॉग की आवश्यकता है क्योंकि मैं यह देखना चाहता हूं कि चीजें मेरे कोड में कैसे निष्पादित हो रही हैं। इसे ठीक करने के लिए syslog क्या करता है?

— कार्ल मॉरिसन

निशान आमतौर पर कुछ ऐसा नहीं है जिसे आप syslog पर प्रसारित करना चाहते हैं और मुझे लगता है कि आप अपने स्वयं के इंटरैक्टिव डिबगिंग सत्रों के लिए इस स्तर को जोड़ने के लिए स्वतंत्र हैं?

— kvz

ये सभी विस्तारित स्तर IMO लॉगिंग की जटिलता को बढ़ाते हैं। विशिष्ट एप्लिकेशन की जरूरतों को पूरा करने के लिए सबसे सरल सेट से चिपकना सबसे अच्छा है। मेरे लिए, आप के साथ शुरू करना चाहिए DEBUG, INFO, WARNINGऔर ERROR। डेवलपर्स को सभी स्तरों को देखना चाहिए। SysAdmins तक INFOऔर एंड यूज़र्स चेतावनी और त्रुटियों को देख सकते हैं लेकिन केवल तभी जब उन्हें इसके बारे में सचेत करने की कोई रूपरेखा हो ।

— ADTC

(cont'd) ऐप के परिपक्व होने पर, आप ज़रूरत पड़ने पर अधिक स्तरों तक विस्तार कर सकते हैं। दोनों DEBUGऔर TRACEडेवलपर्स की तरह ग्रैन्युलैरिटी को नियंत्रित करने के लिए। और ERRORविस्तार अन्य स्तरों पसंद करने के लिए CRITICAL, ALERT, EMERGENCYत्रुटियों की गंभीरता भेद और गंभीरता के आधार पर कार्रवाई निर्धारित करने के लिए।

— ADTC

Answer 7

चेतावनियों से आप उबर सकते हैं। त्रुटियाँ आप नहीं कर सकते। यह मेरा अनुमान है, अन्य लोगों के पास अन्य विचार हो सकते हैं।

उदाहरण के लिए, मान लें कि आप "Angela Müller"अपने आवेदन में नाम दर्ज / आयात करते हैं (नोट umlaut पर u)। आपका कोड / डेटाबेस केवल अंग्रेजी हो सकता है (हालांकि यह शायद इस दिन और उम्र में नहीं होना चाहिए ) और इसलिए चेतावनी दे सकता है कि सभी "असामान्य" अक्षर नियमित अंग्रेजी वर्णों में परिवर्तित हो गए थे।

कंट्रास्ट कि डेटाबेस के लिए उस जानकारी को लिखने की कोशिश कर रहा है और सीधे 60 सेकंड के लिए एक नेटवर्क डाउन संदेश वापस मिल रहा है। यह चेतावनी से अधिक त्रुटि है।

Comments

यदि डेटाबेस एक निश्चित वर्ण सेट में है जिसमें umlaut शामिल नहीं है, तो इस इनपुट को अस्वीकार कर दिया जाना चाहिए।

— कोच रूहुलसिन

कोच, दुनिया शायद ही कभी काले और सफेद है :-)

— paxdiablo

Answer 8

जैसा कि दूसरों ने कहा है, त्रुटियां समस्याएं हैं; चेतावनी संभावित समस्याएं हैं।

विकास में, मैं अक्सर चेतावनियों का उपयोग करता हूं, जहां मैं दावे की विफलता के बराबर हो सकता हूं, लेकिन आवेदन काम करना जारी रख सकता है; यह मुझे यह पता लगाने में सक्षम बनाता है कि क्या वास्तव में ऐसा मामला है, या यदि यह मेरी कल्पना है।

लेकिन हाँ, यह पुनर्प्राप्ति और वास्तविकता पहलुओं के लिए नीचे जाता है। यदि आप पुनर्प्राप्त कर सकते हैं, तो यह संभवतः एक चेतावनी है; अगर यह वास्तव में विफल होने का कारण बनता है, तो यह एक त्रुटि है।

Answer 9

मुझे लगता है कि SYSLOG स्तर NOTICE और ALERT / EMERGENCY आवेदन-स्तर की लॉगिंग के लिए बड़े पैमाने पर अति-उपयोगी हैं - जबकि CRITICAL / ALERT / EMERGENCY एक ऑपरेटर के लिए उपयोगी चेतावनी स्तर हो सकता है जो विभिन्न कार्यों और सूचनाओं को ट्रिगर कर सकता है, एक आवेदन व्यवस्थापक के लिए यह सब समान है घातक। और मैं सिर्फ नोटिस या कुछ सूचना दिए जाने के बीच पर्याप्त अंतर नहीं कर सकता। यदि जानकारी उल्लेखनीय नहीं है, तो यह वास्तव में जानकारी नहीं है :)

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

हालाँकि एक लॉगिंग स्तर है जिसे मैं अपनी त्रुटि लॉग में देखना पसंद करता हूं, जब एक sadadmin की टोपी पहनना उतना ही तकनीकी समर्थन, या यहां तक ​​कि डेवलपर: OPER, OPERATIONAL संदेशों के लिए। यह मैं टाइमस्टैम्प लॉगिंग के लिए उपयोग करता हूं, जिस प्रकार का ऑपरेशन किया जाता है, आपूर्ति की गई दलीलें, संभवतः एक (अद्वितीय) कार्य पहचानकर्ता, और कार्य पूर्णता। इसका उपयोग तब किया जाता है जब उदाहरण के लिए एक स्टैंडअलोन कार्य बंद कर दिया जाता है, कुछ ऐसा जो लंबे समय तक चलने वाले ऐप के भीतर से एक सच्चा आह्वान है। यह उस तरह की चीज है जिसे मैं हमेशा लॉग इन करना चाहता हूं, चाहे कुछ भी गलत हो या न हो, इसलिए मैं ओपर के स्तर को फेटल से अधिक मानता हूं, इसलिए आप इसे पूरी तरह से साइलेंट मोड पर जाकर बंद कर सकते हैं। और यह महज INFO लॉग डेटा से कहीं अधिक है - एक लॉग स्तर अक्सर बिना किसी ऐतिहासिक मूल्य के मामूली परिचालन संदेशों के साथ स्पैमिंग लॉग के लिए दुर्व्यवहार किया जाता है।

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

Answer 10

RFC 5424 से, सिसलॉग प्रोटोकॉल (IETF) - पृष्ठ 10:

प्रत्येक संदेश प्राथमिकता में एक दशमलव गंभीरता स्तर सूचक भी होता है। ये उनके संख्यात्मक मूल्यों के साथ निम्नलिखित तालिका में वर्णित हैं। गंभीर मान 0 से 7 समावेशी की सीमा में होना चाहिए।

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

          Table 2. Syslog Message Severities

Answer 11

अच्छा दिन,

इस प्रश्न के एक कोरोलरी के रूप में, लॉग स्तरों की अपनी व्याख्याओं को संप्रेषित करें और सुनिश्चित करें कि किसी परियोजना के सभी लोग स्तरों की अपनी व्याख्या में संरेखित हैं।

यह लॉग संदेशों की एक विशाल विविधता को देखने के लिए दर्दनाक है जहां गंभीरता और चयनित लॉग स्तर असंगत हैं।

यदि विभिन्न लॉगिंग स्तरों का संभव हो तो उदाहरण प्रदान करें। और संदेश में लॉग इन की जाने वाली सूचना के अनुरूप हो।

HTH

Answer 12

मैं दूसरों के साथ पूरी तरह से सहमत हूं, और सोचता हूं कि ग्रेविजेरक्स ने इसे सबसे अच्छा कहा।

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

अब, क्या आप यह पता लगा सकते हैं कि घातक क्या हो सकता है? तुम्हें पता है कि घातक क्या मतलब है, है ना? तो, आपकी सूची में कौन सी चीजें घातक हैं।

ठीक है, नहीं है कि घातक के साथ निपटा, अब कम से त्रुटियों ... कुल्ला और दोहराने के लुक करते हैं।

नीचे घातक, या शायद त्रुटि, मैं सुझाव दूंगा कि अधिक जानकारी हमेशा कम से कम बेहतर होती है, इसलिए "ऊपर की ओर" गलत। यकीन नहीं है कि यह जानकारी या चेतावनी है? तो यह एक चेतावनी हैं।

मुझे लगता है कि घातक और त्रुटि हम सभी के लिए स्पष्ट होनी चाहिए। दूसरे लोग फ़र्ज़ी हो सकते हैं, लेकिन उन्हें ठीक से हासिल करना यकीनन कम महत्वपूर्ण है।

यहाँ कुछ उदाहरण हैं:

घातक - स्मृति, डेटाबेस, आदि का आवंटन नहीं कर सकता - जारी नहीं रख सकता।

त्रुटि - संदेश का जवाब नहीं, लेन-देन निरस्त, फ़ाइल नहीं बचा सकता, आदि।

चेतावनी - संसाधनों के आवंटन पहुँच एक्स% (कहते हैं कि 80%) - कि एक संकेत है कि आप फिर से आयाम अपने करना चाह सकते हैं है।

जानकारी - उपयोगकर्ता लॉग इन / आउट, नया लेनदेन, फ़ाइल क्रिएट, नया डी / बी फ़ील्ड, या फ़ील्ड हटा दिया गया।

डीबग - आंतरिक डेटा संरचना का डंप, फ़ाइल नाम और लाइन नंबर के साथ कुछ भी ट्रेस स्तर।
ट्रेस - कार्रवाई सफल / असफल, डी / बी अपडेट की गई।

Answer 13

एक त्रुटि कुछ ऐसी है जो गलत है, सादा गलत है, इसके आसपास कोई रास्ता नहीं है, इसे ठीक करने की आवश्यकता है।

चेतावनी एक पैटर्न का संकेत है जो गलत हो सकता है, लेकिन तब भी नहीं हो सकता है।

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

हालांकि, "sql निष्पादन में बहुत अधिक समय लगता है" जैसी चीजें एक चेतावनी हो सकती हैं, जबकि "sql निष्पादन गतिरोध" एक त्रुटि है, इसलिए शायद कुछ मामलों में सब के बाद है।

Comments

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

— क्रस्ट

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

— लास वी। कार्लसन

एक उदाहरण जो मैं सोच सकता था वह यह है: कुछ संदेश सामान्य से अधिक लंबे समय तक संसाधित होने में अधिक समय लेते हैं। यह एक संकेत हो सकता है कि कुछ गलत है (शायद कुछ अन्य प्रणाली अतिभारित है या एक बाहरी संसाधन अस्थायी रूप से नीचे था)।

— लारदाद

Answer 14

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

Answer 15

मैंने सिस्टम बनाया है इससे पहले कि निम्नलिखित का उपयोग करें:

1. त्रुटि - का अर्थ है कि कुछ गंभीर रूप से गलत है और वह विशेष धागा / प्रक्रिया / अनुक्रम नहीं चल सकता है। कुछ उपयोगकर्ता / व्यवस्थापक हस्तक्षेप की आवश्यकता है
2. चेतावनी - कुछ सही नहीं है, लेकिन प्रक्रिया पहले की तरह चल सकती है (जैसे कि 100 के सेट में एक काम विफल हो गया है, लेकिन शेष को संसाधित किया जा सकता है)

सिस्टम में मैंने जो व्यवस्थापक बनाए हैं वे ERRORs पर प्रतिक्रिया करने के निर्देश के तहत थे। दूसरी तरफ हम चेतावनी के लिए देखते हैं और प्रत्येक मामले के लिए निर्धारित करते हैं कि क्या कोई प्रणाली में परिवर्तन, पुन: संयोजन आदि की आवश्यकता है।

Answer 16

Btw, मैं सब कुछ पर कब्जा करने और बाद में जानकारी को छानने का एक बड़ा प्रशंसक हूँ।

यदि आप चेतावनी के स्तर पर कब्जा कर रहे हैं और चेतावनी से संबंधित कुछ डिबग जानकारी चाहते हैं, तो क्या होगा, लेकिन चेतावनी को फिर से बनाने में असमर्थ थे?

सब पर कब्जा कर लो और बाद में फ़िल्टर करें!

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

सब कुछ कैप्चर करें और बाद में फ़िल्टर करें !!

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

Answer 17

मेरे दो लॉग के बारे में FATALऔर TRACEत्रुटि लॉग स्तर।

ERROR जब कुछ FAULT (अपवाद) होते हैं।

FATAL वास्तव में डबल गलती है: जब अपवाद होते हैं, जबकि अपवाद हैंडलिंग।

वेब सेवा के लिए इसे समझना आसान है।

1. निवेदन आ गया। इवेंट के रूप में लॉग किया गया हैINFO
2. सिस्टम कम डिस्क स्थान का पता लगाता है। इवेंट के रूप में लॉग किया गया हैWARN
3. कुछ फ़ंक्शन अनुरोध को संभालने के लिए कहा जाता है। जबकि प्रसंस्करण विभाजन शून्य से होता है। इवेंट के रूप में लॉग किया गया हैERROR
4. वेब सेवा के अपवाद हैंडलर को शून्य से विभाजन को संभालने के लिए कहा जाता है। वेब सेवा / ढांचा ईमेल भेजने वाला है, लेकिन ऐसा नहीं हो सकता क्योंकि मेलिंग सेवा अभी ऑफ़लाइन है। यह दूसरा अपवाद सामान्य रूप से नियंत्रित नहीं किया जा सकता है, क्योंकि वेब सेवा के अपवाद हैंडलर अपवाद को संसाधित नहीं कर सकते हैं।
5. विभिन्न अपवाद हैंडलर कहा जाता है। इवेंट के रूप में लॉग किया गया हैFATAL

TRACEजब हम फ़ंक्शन प्रविष्टि / निकास का पता लगा सकते हैं। यह लॉगिंग के बारे में नहीं है, क्योंकि यह संदेश कुछ डिबगर द्वारा उत्पन्न किया जा सकता है और आपके कोड ने बिल्कुल भी कॉल नहीं किया है log। इसलिए आपके एप्लिकेशन से नहीं आने वाले संदेशों को TRACEस्तर की तरह चिह्नित किया जाता है। उदाहरण के लिए आपका एप्लिकेशन आपके द्वारा चलाया जाता हैstrace

तो आम तौर पर आपके कार्यक्रम में आप करते हैं DEBUG, INFOऔर WARNलॉगिंग। और केवल तभी जब आप कुछ वेब सेवा / रूपरेखा लिख ​​रहे हों, जिसका आप उपयोग करेंगे FATAL। और जब आप एप्लिकेशन को डीबग कर रहे हैं, तो आपको TRACEइस प्रकार के सॉफ़्टवेयर से लॉगिंग मिलेगी ।

Answer 18

मैं केवल तीन स्तरों का उपयोग करने का सुझाव देता हूं

1. घातक - जो अनुप्रयोग को तोड़ देगा।
2. जानकारी - जानकारी
3. डीबग - कम महत्वपूर्ण जानकारी