Python अपवाद लॉगिंग: ट्रेसबैक और पर्याप्त अनुरोध संदर्भ बनाए रखें
एक नामित लॉगर का उपयोग करें, एप्लिकेशन एक बार कॉन्फ़िगर करें, और हर त्रुटि को दोहराए बिना सुरक्षित संदर्भ संलग्न करें।
इस पृष्ठ पर
संक्षिप्त उत्तर
एक अपवाद हैंडलर के अंदर, logger.exception वर्तमान अपवाद सूचना के साथ एक ERROR घटना रिकॉर्ड करता है। एप्लिकेशन प्रवेश बिंदु में हैंडलर कॉन्फ़िगर करें और व्यक्तिगत मॉड्यूल में getLogger(__name__) का उपयोग करें। एक सुरक्षित ऑपरेशन या अनुरोध पहचानकर्ता शामिल करें ताकि ट्रेसबैक को विफल कार्रवाई से संबंधित किया जा सके। लॉगिंग विफलता को रिकॉर्ड करती है; प्रोग्राम को अलग से तय करना होगा कि क्या पुनर्प्राप्ति करनी है, त्रुटि लौटानी है या पुनः उठाना है।
रिकॉर्ड करने की आवश्यकता वाली घटना चुनें
एक अपवाद ऑब्जेक्ट और एक संचालन घटना अलग-अलग प्रश्नों के उत्तर देते हैं। अपवाद बताता है कि क्या विफल हुआ; घटना पहचान सकती है कि कौन सा कार्य चल रहा था। लॉगिंग जोड़ने से पहले, तय करें कि रिकॉर्ड को कौन पढ़ेगा और जांच करने के लिए उन्हें क्या चाहिए। एक संक्षिप्त संदेश जो संचालन का नाम बताता है और एक गैर-गुप्त सहसंबंध पहचानकर्ता होता है, आमतौर पर पूरे अनुरोध शरीर को दोहराने या हर स्थानीय चर को डंप करने से अधिक उपयोगी होता है।
एप्लिकेशन सीमा पर लॉगिंग कॉन्फ़िगर करें
एक स्टैंडअलोन स्क्रिप्ट के लिए, एप्लिकेशन कार्य शुरू करने से पहले लॉगिंग कॉन्फ़िगर करें। नीचे दिया गया उदाहरण एक बार basicConfig का उपयोग करता है और एक नामित लॉगर प्राप्त करता है। एक बड़ा एप्लिकेशन एक अलग कॉन्फ़िगरेशन तंत्र का उपयोग कर सकता है, लेकिन स्वामित्व अभी भी स्पष्ट होना चाहिए। एक पुन: उपयोग योग्य लाइब्रेरी को नामित लॉगर प्रकट करने चाहिए और अपने कॉलर को हैंडलर, गंतव्य और स्तर चुनने देना चाहिए, न कि अनशर्त रूप से एप्लिकेशन कॉन्फ़िगरेशन को बदलना चाहिए।
हैंडलर के अंदर अपवाद सूचना का उपयोग करें
logger.exception एक अपवाद हैंडलर के लिए है, जहाँ वर्तमान अपवाद सूचना उपलब्ध होती है। केवल अपवाद पाठ के साथ logger.error को कॉल करने से ट्रेसबैक छूट जाता है जब तक कि अपवाद सूचना स्पष्ट रूप से अनुरोध न की गई हो। इसके विपरीत, ट्रेसबैक लिखने का अर्थ यह नहीं है कि हर पुनर्प्राप्ति योग्य स्थिति को एक घातक एप्लिकेशन विफलता के रूप में Treat किया जाए। घटना स्तर और पुनर्प्राप्ति नीति संचालन के अनुसार चुनें, केवल अपवाद वर्ग नाम के अनुसार नहीं।
एक पूर्ण छोटा उदाहरण पढ़ें
यह निर्मित स्टैंडअलोन स्क्रिप्ट जानबूझकर एक गैर-संख्यात्मक स्ट्रिंग को int को पास करती है। अपेक्षित लॉग में request_id=demo1 के साथ एक ERROR संदेश और ValueError पर समाप्त होने वाली अपवाद सूचना होती है। सटीक ट्रेसबैक पथ और पंक्ति संख्या इस बात पर निर्भर करती हैं कि स्क्रिप्ट कहाँ सहेजी गई है, इसलिए कोई निश्चित पूर्ण ट्रेसबैक वादा नहीं किया गया है। उदाहरण एक लॉगिंग कॉल प्रदर्शित करता है; इसका पकड़ा गया अपवाद स्वचालित रूप से कॉलर को प्रसारित नहीं होता है।
import logging
logging.basicConfig(level=logging.INFO, format="%(levelname)s %(name)s %(message)s")
logger = logging.getLogger(__name__)
request_id = "demo1"
try:
int("bad")
except ValueError:
logger.exception("Could not parse quantity; request_id=%s", request_id)
अंतिम त्रुटि रिकॉर्ड का स्वामी तय करें
यदि कोई निचली परत कोई अपवाद लॉग करती है और फिर उसे फिर से उठाती है, और कोई ऊपरी परत भी उसे लॉग करती है, तो एक ही विफलता दो बार दिख सकती है। तय करें कि कौन सी परत पर्याप्त संदर्भ रखती है ताकि संचालन रिकॉर्ड बना सके। निचली परत एक उचित अपवाद उठाकर जानकारी जोड़ सकती है, जबकि सीमांत परत अंतिम विफलता को लॉग करती है। यह एक डिज़ाइन विकल्प है, हर अपवाद को हर जगह ठीक एक बार लॉग करना जरूरी नहीं है।
हैंडलर के माध्यम से दोहराया गया आउटपुट पहचानें
डुप्लिकेट लगने वाले रिकॉर्ड तब भी बन सकते हैं जब किसी बच्चे के लॉगर पर हैंडलर जोड़ा गया हो और साथ ही प्रसारण की अनुमति भी हो ताकि वह पूर्वज लॉगर भी अपना हैंडलर चला सके। ऐप इवेंट्स हटाने से पहले लॉगर पदानुक्रम और हैंडलर कॉन्फ़िगरेशन की जाँच करें। लॉगर और हैंडलर दोनों के स्तर भी तय कर सकते हैं कि आउटपुट दिखेगा या नहीं। प्रसारण को दबाना बिना गंतव्यों को समझे केंद्रीय सिंक से रिकॉर्ड छिपा सकता है, साथ ही डुप्लिकेट कंसोल पंक्ति भी हटा सकता है।
संवेदनशील संदर्भ को रिकॉर्ड से दूर रखें
एक अपारदर्शी अनुरोध पहचानकर्ता या सावधानीपूर्वक चुना गया संचालन नाम का उपयोग करें। पासवर्ड, अधिकृति हेडर, एपीआई कुंजी या पूरा बिना फ़िल्टर किया अनुरोध पेलोड शामिल न करें। स्वयं अपवाद संदेश में उपयोगकर्ता इनपुट या कनेक्शन विवरण हो सकते हैं, इसलिए एक सुरक्षित लॉगिंग कॉल यह साबित नहीं करती कि हर परिणामी ट्रेसबैक सुरक्षित रूप से रखा जा सकता है। वास्तविक ऐप और लॉग गंतव्य के अनुसार पहुँच, धारणा और रद्दीकरण नीतियाँ लागू करें।
निदान को प्रोग्राम व्यवहार से अलग रखें
लॉगिंग कॉल न तो संचालन को फिर से करने का प्रयास करती है और न ही क्लाइंट को लौटाया जाने वाला प्रतिक्रिया चुनती है। घटना रिकॉर्ड करने के बाद, जानबूझकर तय करें कि क्या कोई वैध विकल्प के साथ जारी रहना है, दस्तावेज़ीकृत विफलता लौटानी है, या फिर से अपवाद उठाना है। इस चुनाव को त्रुटि सीमांत के पास दस्तावेज़ करें। यदि प्रोग्राम जारी रहता है, तो बाद के कोड को इस बात पर निर्भर न बनाएँ कि विफल होने वाले कथन द्वारा कभी सफलतापूर्वक बनाई गई कोई मान नहीं थी।
क्या जाँचें
- हैंडलर को हर मॉड्यूल में नहीं, एप्लिकेशन में कॉन्फ़िगर करें।
- अपवाद को संभालते समय अपवाद सूचना का उपयोग करें।
- एक सुरक्षित सहसंबंध पहचानकर्ता शामिल करें।
- आउटपुट दोहराए जाने पर हैंडलर और प्रसार की जांच करें।
- लॉगिंग से अलग पुनर्प्राप्ति या प्रसार को परिभाषित करें।
उपयोग की सीमाएँ
यह स्क्रिप्ट मानक-लाइब्रेरी लॉगिंग और एक पकड़े गए ValueError को दर्शाती है। यह एक पूर्ण उत्पादन लॉगिंग कॉन्फ़िगरेशन नहीं है और यह एक तैनात लॉग सिंक, स्वचालित रेडैक्शन, पुनः प्रयास या एक निष्पादित एप्लिकेशन परीक्षण को प्रदर्शित नहीं करती है।