logrotate के साथ rsyslog: rsyslog बनाम copytruncate पुनः लोड करें

Question

मैं डिफ़ॉल्ट rsyslog और logrotate उपयोगिता के साथ Ubuntu 14 पर काम कर रहा हूं।

डिफ़ॉल्ट rsyslog logrotate /etc/logrotate.d/rsyslogconfig में मैं निम्नलिखित देखता हूं:

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

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

तो बजाय rsyslog पुनः लोड सुविधा का उपयोग करके डिफ़ॉल्ट कॉन्फ़िगरेशन कैसे आए?

Answer 1

अपने प्रश्न का उत्तर देने के लिए, आपको पहले अलग-अलग ट्रेड-ऑफ को पुनः लोड करने और कॉपीरूट करने की आवश्यकता को समझना होगा:

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

Comments

मैं अपनी लॉग फ़ाइलों को 500M प्रत्येक तक सीमित कर रहा हूं, इसलिए उनकी नकल करना परेशानी नहीं होगी (कई सेकंड में अधिकतम)। धन्यवाद!

— मटन

Answer 2

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

जब फ़ाइल को स्थानांतरित किया जाता है और एक नया इनकोड (फ़ाइल) बनाया जाता है, तो rsyslog पिछली फ़ाइल और पूर्ण प्रसंस्करण का ट्रैक रखता है। इसलिए आपको इस मामले में कोई नुकसान नहीं है। गारंटी (यदि आप फ़ाइल सिस्टम को अनमाउंट करते हैं तो छोड़कर ...)।

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

मैं वर्तमान में रिफ्लेक्टिंग इम्फाइल (ईटीए 8.34 या 8.35) पर काम करता हूं। अपवर्तित संस्करण शायद एपीआई रेस के कारण आकस्मिक पुन: भेजने से रोकने में सक्षम होगा, लेकिन डेटा हानि से भी रक्षा नहीं कर सकता है - क्योंकि यह वैचारिक रूप से असंभव है।

Answer 3

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

Answer 4

चूंकि संस्करण 8.16 rsyslog में imfile विकल्प है reopenOnTruncateजो copytruncte समस्या को संभालता है।

Answer 5

विशेष रूप से rsyslog के लिए, यह संभवतः चीजों को छोड़ने के लिए अधिक समझ में आता है जैसे वे हैं।

मूल कारण यह है कि rsyslog की आंतरिक कतारें हैं, यह उन मामलों में उपयोग कर सकता है जहां इसका आउटपुट हैंडल अनुपलब्ध है।

पुनः लोड करने से a) rsyslog को अपनी लॉग फ़ाइल को फिर से बनाने का कारण बनेगा, और b) किसी भी कतारबद्ध घटनाओं को सृजन पर फ़ाइल में फ़्लश करने का कारण होगा।

हो सकता है कि यह copytruncate को कोई नुकसान नहीं पहुंचाए (हालाँकि मुझे आंशिक रूप से लिखित पंक्तियों के बारे में चिंतित किया जाएगा), लेकिन मैं यह सोचना चाहूंगा कि एक अखंडता की दृष्टि से कॉपी / डिलीट / रीलोड 'सुरक्षित' है।

जैसा कि @ faker द्वारा उल्लेख किया गया है , क्योंकि rsyslog उस स्थिति को संभाल सकता है जहां इसकी फाइल अनुपलब्ध हो जाती है, लेकिन कोपिट्रंकट का उपयोग करने के लिए कोई बाध्यकारी कारण नहीं है।

और जैसा कि @ SelivanovPavel द्वारा उल्लेख किया गया है , rsyslog को कॉपी ट्रंकट से ठीक से निपटने के लिए वास्तव में विशिष्ट कॉन्फ़िगरेशन की आवश्यकता होती है।

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