Logs

Logs वो संदेश हैं जो किसी एप्लिकेशन या डिवाइस से आते हैं — ये एक या कई लाइनों में किसी इवेंट या एप्लिकेशन की सेहत के बारे में बताते हैं। आम तौर पर logs एक फ़ाइल में लिखे जाते हैं, लेकिन कभी-कभी इन्हें किसी कलेक्टर को भेजा जाता है जो इन्हें एनालाइज़ और एग्रीगेट करता है। आज कई लॉग एग्रीगेटर, फ़्रेमवर्क और प्रोडक्ट्स मौजूद हैं जो प्रतिदिन मेगाबाइट से लेकर प्रति घंटे टेराबाइट तक — किसी भी वॉल्यूम में लॉग डेटा बनाने, इनजेस्ट करने और मैनेज करने में मदद करते हैं।

Logs एक समय में एक ही एप्लिकेशन से आते हैं और आम तौर पर उसी एक एप्लिकेशन के दायरे तक सीमित होते हैं — हालाँकि डेवलपर्स इन्हें जितना चाहें उतना डिटेल्ड बना सकते हैं। हम logs को traces से अलग मानते हैं, क्योंकि traces एक से ज़्यादा एप्लिकेशन या सर्विस के इवेंट्स से बनते हैं और इनमें सर्विसेज़ के बीच कनेक्शन का कॉन्टेक्स्ट होता है — जैसे रिस्पॉन्स लेटेंसी, सर्विस फ़ॉल्ट्स, रिक्वेस्ट पैरामीटर्स आदि।

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

लॉगिंग के मुख्य उपयोग:

• किसी इवेंट का वर्णन — उसकी स्थिति, अवधि और अन्य ज़रूरी आँकड़ों सहित
• उस इवेंट से जुड़ी एरर्स या वॉर्निंग्स (जैसे stack traces, timeouts)
• एप्लिकेशन लॉन्च, स्टार्ट-अप और शटडाउन मैसेज

नोट

Logs immutable (अपरिवर्तनीय) होने चाहिए, और कई लॉग मैनेजमेंट सिस्टम में लॉग डेटा को बदलने की कोशिश पकड़ने के लिए सिक्योरिटी और डिटेक्शन मैकेनिज़्म होते हैं।

आपकी लॉगिंग ज़रूरतें चाहे जो हों, ये हमारे सुझाए गए सर्वोत्तम तरीके हैं।

स्ट्रक्चर्ड लॉगिंग सफलता की कुंजी है

कई सिस्टम सेमी-स्ट्रक्चर्ड फ़ॉर्मेट में logs बनाते हैं। उदाहरण के लिए, एक Apache वेब सर्वर इस तरह logs लिख सकता है, जहाँ हर लाइन एक वेब रिक्वेस्ट से जुड़ी है:

192.168.2.20 - - [28/Jul/2006:10:27:10 -0300] "GET /cgi-bin/try/ HTTP/1.0" 200 3395 127.0.0.1 - - [28/Jul/2006:10:22:04 -0300] "GET / HTTP/1.0" 200 2216

जबकि एक Java stack trace एक सिंगल इवेंट हो सकता है जो कई लाइनों में फैला है और कम स्ट्रक्चर्ड है:

Exception in thread "main" java.lang.NullPointerException at com.example.myproject.Book.getTitle(Book.java:16) at com.example.myproject.Author.getBookTitles(Author.java:25) at com.example.myproject.Bootstrap.main(Bootstrap.java:14)

और एक Python error log इवेंट कुछ ऐसा दिख सकता है:

	Traceback (most recent call last):
	  File "e.py", line 7, in <module>
	    raise TypeError("Again !?!")
	TypeError: Again !?!

इन तीन उदाहरणों में से, सिर्फ़ पहला इंसानों और लॉग एग्रीगेशन सिस्टम दोनों द्वारा आसानी से पार्स हो सकता है। स्ट्रक्चर्ड logs इस्तेमाल करने से लॉग डेटा को जल्दी और असरदार तरीके से प्रोसेस करना आसान हो जाता है — इंसानों और मशीनों दोनों को वो डेटा तुरंत मिल जाता है जो वे ढूंढ रहे हैं।

सबसे आम लॉग फ़ॉर्मेट JSON है, जहाँ इवेंट का हर हिस्सा एक key/value pair के रूप में दिखता है। JSON में, ऊपर का Python उदाहरण कुछ ऐसे लिखा जा सकता है:

	{
		"level", "ERROR"
		"file": "e.py",
		"line": 7,
		"error": "TypeError(\"Again !?!\")"
	}

स्ट्रक्चर्ड logs से आपका डेटा एक लॉग सिस्टम से दूसरे में पोर्टेबल बनता है, डेवलपमेंट सरल होता है, और ऑपरेशनल डायग्नोसिस तेज़ (और कम एरर वाला) होता है। इसके अलावा, JSON लॉग मैसेज के schema को डेटा के साथ ही एम्बेड करता है, जिससे एडवांस्ड लॉग एनालिसिस सिस्टम आपके मैसेज को ऑटोमैटिकली इंडेक्स कर सकते हैं।

Log level का सही इस्तेमाल करें

दो तरह के logs होते हैं: जिनका एक level होता है, और जो सिर्फ़ इवेंट्स की सीरीज़ होते हैं। जिनमें level होता है, उनके लिए ये एक कामयाब लॉगिंग नीति का अहम हिस्सा हैं। Log levels एक फ़्रेमवर्क से दूसरे में थोड़े अलग होते हैं, लेकिन आम तौर पर इस स्ट्रक्चर को फ़ॉलो करते हैं:

Level	विवरण
DEBUG	बारीक जानकारी वाले इवेंट जो एप्लिकेशन डिबग करने में सबसे काम आते हैं। ये आम तौर पर डेवलपर्स के लिए होते हैं और बहुत डिटेल्ड होते हैं।
INFO	जानकारी देने वाले मैसेज जो एप्लिकेशन की प्रोग्रेस मोटे तौर पर दिखाते हैं।
WARN	ऐसी स्थितियाँ जो एप्लिकेशन के लिए खतरा हो सकती हैं। ये alarm ट्रिगर कर सकती हैं।
ERROR	एरर इवेंट जिनके बावजूद एप्लिकेशन चलता रह सकता है। इन पर ध्यान देने की ज़रूरत होती है।
FATAL	बेहद गंभीर एरर जो एप्लिकेशन को बंद कर सकती हैं।

जानकारी

जिन logs का कोई स्पष्ट level नहीं है, उन्हें INFO माना जा सकता है — हालाँकि यह एप्लिकेशन पर निर्भर करता है।

प्रोग्रामिंग लैंग्वेज और फ़्रेमवर्क के हिसाब से CRITICAL और NONE भी कॉमन log levels हैं। ALL और NONE भी इस्तेमाल होते हैं, लेकिन हर स्टैक में नहीं मिलते।

Log levels आपके मॉनिटरिंग और ऑब्ज़र्वेबिलिटी सॉल्यूशन को आपके एनवायरनमेंट की सेहत बताने में अहम हैं, और लॉग डेटा को एक लॉजिकल वैल्यू से यह आसानी से ज़ाहिर करना चाहिए।

सुझाव

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

जानकारी

एक स्टैंडर्ड log level नीति अपनाने से ऑटोमेशन आसान होता है, और डेवलपर्स को प्रॉब्लम के रूट कॉज़ तक जल्दी पहुँचने में मदद मिलती है।

चेतावनी

Log levels के लिए स्टैंडर्ड अप्रोच के बिना, अपने logs को फ़िल्टर करना एक बड़ी चुनौती बन जाती है।

सोर्स के पास logs फ़िल्टर करें

जहाँ भी मुमकिन हो, सोर्स के जितना पास हो सके logs की मात्रा कम करें। इस तरीके को अपनाने के कई कारण हैं:

• Logs इनजेस्ट करने में हमेशा समय, पैसा और रिसोर्सेज़ लगते हैं।
• सेंसिटिव डेटा (जैसे PII) को डाउनस्ट्रीम सिस्टम से फ़िल्टर करने से डेटा लीक का रिस्क कम होता है।
• डाउनस्ट्रीम सिस्टम को सोर्स जैसी ऑपरेशनल चिंताएँ नहीं हो सकतीं। जैसे, एक एप्लिकेशन से INFO logs उस मॉनिटरिंग सिस्टम के लिए बेकार हो सकते हैं जो सिर्फ़ CRITICAL या FATAL मैसेज देख रहा है।
• लॉग सिस्टम और नेटवर्क पर बेवजह का लोड नहीं डालना चाहिए।

जानकारी

अपनी लागत कम रखने, डेटा एक्सपोज़र का रिस्क घटाने, और हर कंपोनेंट को मायने रखने वाली चीज़ों पर फ़ोकस रखने के लिए — अपने logs सोर्स के पास ही फ़िल्टर करें।

सुझाव

आपकी आर्किटेक्चर के हिसाब से, आप अपने एप्लिकेशन और एनवायरनमेंट में बदलाव एक ही ऑपरेशन में डिप्लॉय करने के लिए Infrastructure as Code (IaC) इस्तेमाल कर सकते हैं। इससे आप एप्लिकेशन के साथ अपने लॉग फ़िल्टर पैटर्न भी डिप्लॉय कर सकते हैं।

डबल-इनजेशन एंटी-पैटर्न से बचें

एक कॉमन पैटर्न जो एडमिन्स फ़ॉलो करते हैं — सारा लॉगिंग डेटा एक ही सिस्टम में कॉपी करना ताकि एक जगह से सब कुछ क्वेरी किया जा सके। इसके कुछ मैन्युअल वर्कफ़्लो फ़ायदे हैं, लेकिन यह पैटर्न एक्स्ट्रा कॉस्ट, कॉम्प्लेक्सिटी, फ़ेलियर पॉइंट्स और ऑपरेशनल ओवरहेड लाता है।

जानकारी

जहाँ मुमकिन हो, अपने एनवायरनमेंट से लॉग डेटा के पूरे प्रसार से बचने के लिए log levels और log filtering का कॉम्बिनेशन इस्तेमाल करें।

जानकारी

कुछ ऑर्गनाइज़ेशन्स या वर्कलोड्स को रेगुलेटरी ज़रूरतें पूरी करने, सिक्योर लोकेशन में logs रखने, या अन्य उद्देश्यों के लिए log shipping की ज़रूरत होती है। यह लॉग डेटा री-इनजेस्ट करने का एक वैध उपयोग है। ध्यान दें कि इन लॉग आर्काइव्स में जाने वाले अनावश्यक डेटा को कम करने के लिए log levels और log filtering का सही इस्तेमाल अभी भी ज़रूरी है।

अपने logs से मेट्रिक डेटा निकालें

आपके logs में metrics मौजूद हैं! ISV सॉल्यूशन्स या ऐसे एप्लिकेशन जो आपने खुद नहीं लिखे, वे भी अपने logs में काम का डेटा देते हैं जिससे आप वर्कलोड की सेहत के बारे में अच्छी इनसाइट पा सकते हैं। कुछ आम उदाहरण:

• डेटाबेस से स्लो क्वेरी टाइम
• वेब सर्वर का अपटाइम
• ट्रांज़ैक्शन प्रोसेसिंग टाइम
• समय के साथ ERROR या WARNING इवेंट्स की गिनती
• अपग्रेड के लिए अवेलेबल पैकेज की रॉ काउंट

सुझाव

यह डेटा एक स्टैटिक लॉग फ़ाइल में बंद होने पर कम काम का है। सबसे अच्छा तरीका है कि ज़रूरी मेट्रिक डेटा पहचानें और इसे अपने मेट्रिक सिस्टम में पब्लिश करें जहाँ इसे दूसरे सिग्नल्स के साथ correlate किया जा सके।

stdout पर लॉग करें

जहाँ मुमकिन हो, एप्लिकेशन को फ़ाइल या सॉकेट जैसी फ़िक्स्ड लोकेशन के बजाय stdout पर लॉग करना चाहिए। इससे लॉग एजेंट आपके ऑब्ज़र्वेबिलिटी सॉल्यूशन के रूल्स के हिसाब से लॉग इवेंट्स को कलेक्ट और रूट कर सकता है। हर एप्लिकेशन के लिए यह मुमकिन नहीं, लेकिन कंटेनराइज़्ड वर्कलोड्स के लिए यह सबसे अच्छा तरीका है।

नोट

एप्लिकेशन को अपनी लॉगिंग में सिंपल रहना चाहिए और लॉगिंग सॉल्यूशन्स से लूज़ली कपल्ड रहना चाहिए। stdout से फ़ाइल में डेटा भेजने के लिए एक log collector की ज़रूरत होती है। मुख्य बात यह है कि आपके एप्लिकेशन और बिज़नेस लॉजिक को लॉगिंग इंफ्रास्ट्रक्चर पर डिपेंड नहीं होना चाहिए — यानी concerns को अलग रखें।

जानकारी

अपने एप्लिकेशन को लॉग मैनेजमेंट से अलग रखने से आप बिना कोड बदले अपना सॉल्यूशन बदल या बेहतर बना सकते हैं, जिससे आपके एनवायरनमेंट में किसी भी बदलाव का blast radius कम रहता है।