सेवा लॉग - उपयोगकर्ताओं के लिए

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

यह आश्चर्य लाने के लिए शुरू से ही एक सरल कार्य प्रतीत होगा।


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

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

सुविधाओं को स्पष्ट करने और पढ़ने के लॉग का तरीका चुनने के बाद "तह बिस्तर" को लागू करने की प्रक्रिया भी मनोरंजक थी।

मैंने मौजूदा उपकरणों का उपयोग करने के लिए UNIX की विचारधारा के अनुसार जाने का फैसला किया। मैंने पारंपरिक रूप से "फोल्डिंग-आउट" को पर्ल में लिखा था, यह कार्य पत्रिकाओं को ट्रैक करना था। पसंद की प्रत्येक पत्रिका के लिए -f स्विच के साथ पूंछ उपयोगिता पर गिर गई और जो पढ़ा गया था उसके बाद के विश्लेषण। लेकिन हम जो लॉग पढ़ते हैं, उसके रोटेशन के साथ क्या करना है? और फिर, बुढ़ापे में, मैंने अपनी आँखें कुंजी -F पर खोल दीं। सादगी के लिए, मैंने प्रत्येक पत्रिका के लिए एक प्रक्रिया करने का फैसला किया ... और प्रक्रियाओं के निर्धारण में "मर गया"। जब कोई बाहरी सिग्नल आता है, तो सभी को सिग्नल भेजना आवश्यक होता है, कि किसी के पास अपने हैंडलर होने चाहिए, सिस्टम क्रैश, रीबूट का काम करना आवश्यक है। और फिर मुझे याद आया कि पूंछ एक साथ कई फाइलों की निगरानी कर सकती है। कौन सी फ़ाइल किस लाइन से संबंधित है, यह निर्धारित करने के लिए एल्गोरिदम को आरेखित करना नाकाफी है। 'टेल' लिखता है कि यह किस फाइल से वर्तमान में लाइनों को आउटपुट कर रहा है, लेकिन आपको एक ट्रैकिंग सिस्टम बनाना होगा जो वह लिखे जो याद है। दोपहर के बाद, यह पता चला कि फ्रीबीएसडी में पूंछ के सिस्टम कार्यान्वयन में एक त्रुटि थी, जब टर्मिनल के साथ काम नहीं कर रहा था, तो यह उससे आउटपुट लाइनों के बाद फ़ाइल का नाम लिखता है, और इससे पहले नहीं। अंत में, मैंने सिर्फ अपने नाम बदलने की ट्रैकिंग के साथ पर्ल में फ़ाइलों के निरंतर पढ़ने का अपना कार्यान्वयन किया। साइकिल और मानक समाधान के मुद्दे पर। कभी-कभी सभी मामलों में एक साइकिल अधिक लाभदायक होती है।

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

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

सारांश। जब आप एक कार्यक्रम लिखते हैं, तो सोचें कि आप इस कार्यक्रम के लॉग को किसके लिए लिखते हैं। जब आप एक उपकरण चुनते हैं, तो इसके बारे में सोचें - लेकिन यह निश्चित रूप से एक वैचारिक विकल्प नहीं है?

PS मैं सिस्टम को विकसित करने में उनकी मदद के लिए जिक पर अपने पाठकों के प्रति अपनी गहरी कृतज्ञता व्यक्त करता हूं। आपके बिना, कार्य के साथ सामना नहीं करने का हर मौका था।

अद्यतन: github.com/schors/peruserlog