rsyslog กับ logrotate: โหลด rsyslog เทียบกับ copytruncate

ฉันทำงานกับ Ubuntu 14 พร้อมด้วย rsyslog และยูทิลิตี logrotate ที่เป็นค่าเริ่มต้น

ในการตั้งค่าเริ่มต้น rsyslog logrotate /etc/logrotate.d/rsyslogฉันเห็นดังต่อไปนี้:

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

จากสิ่งที่ฉันเข้าใจขอแนะนำให้ใช้ copytruncate ในสถานการณ์ logrotate ทั้งหมดเนื่องจากไม่ย้ายบันทึกปัจจุบัน แต่ตัดทอนบันทึกเพื่อให้กระบวนการใด ๆ ที่มีตัวจัดการไฟล์เปิดสามารถเขียนต่อไปได้

ดังนั้นการกำหนดค่าเริ่มต้นทำไมถึงใช้คุณสมบัติโหลด rsyslog แทน?

ในการตอบคำถามของคุณก่อนอื่นคุณต้องเข้าใจถึงความแตกต่างของการโหลดซ้ำและคัดลอก:

• โหลด : ไฟล์บันทึกเก่าถูกเปลี่ยนชื่อและกระบวนการเขียนลงในบันทึกนั้นจะได้รับแจ้ง (ผ่านสัญญาณ Unix) เพื่อสร้างไฟล์บันทึกอีกครั้ง นี่เป็นวิธีการค่าใช้จ่ายที่เร็วที่สุด / ต่ำกว่า: การดำเนินการเปลี่ยนชื่อ / ย้ายรวดเร็วและมีเวลาดำเนินการคงที่ ยิ่งไปกว่านั้นมันเป็นการดำเนินการที่เกือบจะเป็นปรมาณู: ซึ่งหมายความว่า (เกือบ) จะไม่มีการบันทึกรายการใดที่สูญหายระหว่างการย้าย / โหลดซ้ำ ในทางกลับกันคุณต้องมีกระบวนการที่สามารถโหลดและเปิดไฟล์บันทึกได้อีกครั้ง Rsyslog เป็นกระบวนการดังกล่าวดังนั้นการกำหนดค่า logrotate เริ่มต้นจึงใช้วิธีการโหลดซ้ำ การใช้โหมดนี้กับ rsyslog ขอแนะนำอย่างยิ่งโดย rsyslog ต้นน้ำ
• copytruncate : ไฟล์บันทึกเก่าจะถูกคัดลอกไปยังไฟล์เก็บถาวรจากนั้นจะถูกตัดทอนเป็น "ลบ" บรรทัดบันทึกเก่า แม้ว่าการดำเนินการตัดทอนจะเร็วมาก แต่การคัดลอกอาจใช้เวลานาน (ขึ้นอยู่กับว่าไฟล์ของคุณมีขนาดใหญ่แค่ไหน) ยิ่งกว่านั้นรายการบันทึกบางรายการอาจสูญหายระหว่างช่วงเวลาระหว่างการคัดลอก (โปรดจำไว้ว่าอาจช้า) และตัดทอน ด้วยเหตุผลเหล่านี้การคัดลอกจะไม่ถูกใช้โดยค่าเริ่มต้นสำหรับบริการที่สามารถโหลดซ้ำและสร้างไฟล์บันทึกได้ ในทางกลับกันหากเซิร์ฟเวอร์ไม่สามารถโหลด / สร้างไฟล์บันทึกซ้ำการคัดลอกคือทางออกที่ปลอดภัยที่สุดของคุณ กล่าวอีกนัยหนึ่งก็ไม่ต้องการการสนับสนุนระดับบริการใด ๆ rsyslog โครงการต้นน้ำแนะนำอย่างยิ่งต่อการใช้โหมดนี้

การพูดในฐานะผู้เขียน rsyslog การคัดลอกเป็นทางเลือกที่ดีมากและแย่มาก มันมีชีวิตชีวาโดยเนื้อแท้และใช้มันเกือบรับประกันได้ว่าคุณจะสูญเสียข้อมูลบันทึก ยิ่งไฟล์ถูกเขียนลงไปบ่อยเท่าใดคุณก็ยิ่งเสียมากเท่านั้น และนี่ไม่ได้เป็นเพียงส่วนหนึ่งของบรรทัดสุดท้าย แต่อาจมีได้หลายร้อยคนขึ้นอยู่กับเวลาที่แน่นอนและสถานะของระบบ ณ เวลาที่มีการหมุนเกิดขึ้น

เมื่อไฟล์ถูกย้ายและสร้าง inode (ไฟล์) ใหม่ rsyslog จะติดตามไฟล์ก่อนหน้าและประมวลผลเสร็จสมบูรณ์ ดังนั้นคุณจะไม่สูญเสียใด ๆ ในกรณีนี้ รับประกัน (ยกเว้นถ้าคุณยกเลิกการต่อเชื่อมระบบไฟล์ ... )

เมื่อวันที่ "reopenOnTruncate": ฉันเองได้เห็น reopenOnTruncate เป็นการส่วนตัวที่มีชีวิตชีวาในเรื่องอื่น ๆ เช่นกันโดยเฉพาะกับ NFS และอื่น ๆ เมื่อไม่นานมานี้ฉันได้ลบฟังก์ชั่นนั้นโดยสิ้นเชิง แต่หลังจากนั้นได้ชักชวนให้รวมฟังก์ชั่นที่คล้ายกันกลับมามันจะยังคง "ทดลอง" ที่สุดตลอดกาล "copytruncate" ไม่ใช่โหมดที่เหมาะสมในการทำงานกับไฟล์บันทึก

ขณะนี้ฉันทำงานเกี่ยวกับ refactoring imfile (ETA 8.34 หรือ 8.35) เวอร์ชันที่ได้รับการปรับสภาพใหม่อาจจะสามารถป้องกันการส่งซ้ำโดยไม่ได้ตั้งใจเนื่องจากการแข่งขัน API แต่ก็ไม่สามารถป้องกันการสูญหายของข้อมูลได้ - เพราะนี่เป็นแนวคิดที่เป็นไปไม่ได้

ขึ้นอยู่กับว่ากระบวนการเขียนบันทึกเป็นอย่างไร
copytruncateทำงานเฉพาะถ้าข้อความเข้าสู่ระบบจะถูกผนวกเข้ากับแฟ้ม (เช่นwhatever >> logfile.
และไม่เมื่อมีการเปลี่ยนเส้นทางออก (เช่นwhatever > logfile)

ตั้งแต่เวอร์ชัน 8.16 rsyslog มีตัวเลือก imfile reopenOnTruncateที่จัดการปัญหาการคัดลอก

สำหรับ rsyslog โดยเฉพาะมันอาจจะเหมาะสมกว่าที่จะละทิ้งสิ่งต่าง ๆ ตามที่เป็นอยู่

เหตุผลพื้นฐานคือ rsyslog มีคิวภายในซึ่งสามารถใช้ในกรณีที่การจัดการเอาต์พุตไม่พร้อมใช้งาน

การโหลดซ้ำจะทำให้ a) ทำให้ rsyslog สร้างไฟล์บันทึกของตัวเองใหม่และ b) ทำให้เหตุการณ์ที่อยู่ในคิวจะถูกลบทิ้งไปยังไฟล์ที่สร้าง

มันอาจจะ copytruncate ไม่เป็นอันตราย (แม้ว่าฉันจะกังวลเกี่ยวกับบรรทัดที่เขียนบางส่วนที่ถูกตัดทอน) แต่ฉันมักจะคิดว่าการคัดลอก / ลบ / โหลดใหม่นั้นเป็น 'ปลอดภัย' จากมุมมองที่สมบูรณ์

ตามที่กล่าวถึงโดย @ fakerเนื่องจาก rsyslog สามารถจัดการกับสถานการณ์ที่ไฟล์ไม่พร้อมใช้งานจึงไม่มีเหตุผลที่น่าสนใจในการใช้ copytruncate

และตามที่กล่าวถึงโดย @ SelivanovPavel rsyslog ต้องการการกำหนดค่าเฉพาะเพื่อจัดการกับสำเนาที่ถูกตัดทอนอย่างถูกต้อง

ดังนั้นหากเพียงเพราะใช้reloadวิธีการที่ต้องการเบี่ยงเบนน้อยกว่าค่าเริ่มต้นฉันจะเก็บไว้