หมุนเวียนล็อกของวอตช์ด็อก VPN โดยไม่ทำให้ตัวเขียนพัง

การตรวจสอบสุขภาพ VPN ที่เพิ่มหนึ่งบรรทัดทุกนาทีสร้างหน้าที่ที่สองอย่างเงียบ ๆ: ตัดสินใจว่าบรรทัดเหล่านั้นออกจากดิสก์อย่างไร การซ่อมอุโมงค์ไม่ได้ช่วยอะไรกับหน้าที่นั้น และการเปลี่ยนชื่อไฟล์ไม่ได้เปลี่ยนเส้นทางของโปรเซสที่ยังถือตัวอธิบายเก่าอยู่ ตอบคำถามเรื่องปลายทางก่อน แล้วจึงทำให้การหมุนเวียนตรงกับวิธีที่ตัวเขียนเปิดมัน

เลือกปลายทางก่อนนโยบายการหมุนเวียน

ยูนิต systemd ที่ส่งเอาต์พุตไปยังเจอร์นัลอยู่แล้วเก็บการเก็บรักษาไว้ที่เดียว journald บังคับใช้ขีดจำกัดเช่น SystemMaxUse และ MaxRetentionSec ดังนั้นวอตช์ด็อกที่บันทึกที่นั่นจึงได้รับขีดจำกัดโดยไม่ต้องทำงานเพิ่ม การเพิ่มไฟล์ที่ไม่มีขีดจำกัดไฟล์ที่สองไว้ข้าง ๆ ทำให้การบำรุงรักษาเป็นสองเท่าโดยไม่มีประโยชน์

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

เขียนบล็อกให้ตรงกับตัวเขียน

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

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

คู่มือ logrotate กำหนดจำนวนเป็นจำนวนเวอร์ชันที่หมุนแล้วซึ่งเก็บไว้ ไม่ใช่การรับประกันประวัติเจ็ดวัน และคำสำคัญ daily จะถูกประเมินเมื่องานทำงาน ไม่ใช่ทำหน้าที่เป็นตัวจัดตารางของตัวเอง ในดิสทริบิวชันส่วนใหญ่ ตัวจับเวลา systemd หรือรายการ cron เป็นเจ้าของการเรียกนั้นอยู่แล้ว ดังนั้นตรวจสอบว่ามีอันไหนก่อนเพิ่มอันที่สอง การจับคู่ความเป็นเจ้าของสำคัญกว่าจำนวนการเก็บรักษา การคัดลอกโหมดสำหรับ root เท่านั้นไปยังไฟล์ที่บัญชีบริการเขียนจะหยุดการบันทึกในการหมุนเวียนครั้งถัดไป และความล้มเหลวจะปรากฏหลายชั่วโมงต่อมาเป็นตราเวลาที่เก่า ไม่ใช่เป็นข้อผิดพลาด ยืนยันผู้ใช้ของตัวเขียนก่อนคัดลอกบล็อกจากที่อื่น

ตัวเขียนที่ไม่เคยเปิดใหม่ต้องใช้วิธีอื่น

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

เส้นทางการเปิดใหม่สะอาดกว่าในที่ที่ซอฟต์แวร์รองรับ: ส่งสัญญาณที่บันทึกไว้หรือเรียกใช้คำสั่งที่บันทึกไว้ และปล่อยให้โปรเซสเปิดไฟล์ใหม่เอง ทางเลือกคือ copytruncate ซึ่งคัดลอกเนื้อหาไปยังชื่อที่หมุนแล้วและตัดไฟล์ต้นฉบับในที่เดิม ดังนั้นตัวอธิบายยังใช้ได้แต่การเขียนที่เกิดขึ้นระหว่างการคัดลอกและการตัดจะหายไป

สำหรับยูนิตที่เริ่มโดย systemd ให้ชี้ StandardOutput ไปที่เจอร์นัลหรือไฟล์ และปล่อยให้ยูนิตเป็นเจ้าของวงจรชีวิต ลูปเชลล์ที่เพิ่มผ่าน tee -a โดยไม่มีขีดจำกัดขนาดคือการจัดวางที่เติมพาร์ทิชันระหว่างเหตุขัดข้อง เพราะการตรวจสอบที่ล้มเหลวมักบันทึกมากกว่าที่สุขภาพดีมาก

ทดสอบการหมุนเวียนโดยไม่ต้องรอตัวจับเวลา

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

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

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

ทำการรันแบบบังคับซ้ำสองครั้งเพื่อดูว่าการเก็บรักษาทำงานอย่างไรเมื่อมีเวอร์ชันอยู่แล้ว การลบไฟล์ที่เก่าที่สุดเป็นผลลัพธ์ที่คาดไว้ และการไม่ลบมักหมายถึงจำนวนหรือไวลด์การ์ดในชื่อที่หมุนแล้วไม่ตรงกับสิ่งที่ logrotate สร้าง

เก็บการย้อนกลับและบันทึกเป็นลายลักษณ์อักษร

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

บันทึกโหมด เจ้าของ จำนวนการเก็บรักษา และงบดิสก์ที่คาดไว้ข้างการตรวจสอบเอง เมื่อการตรวจสอบเปลี่ยนจากสคริปต์ครั้งเดียวเป็นเดมอนในภายหลัง นโยบายการหมุนเวียนต้องเปลี่ยนตามไปด้วย และบันทึกนั้นคือสิ่งที่บอกคนถัดไปว่าสมมติฐานใดแตก

สุดท้าย แยกการตัดสินใจเรื่องล็อกออกจากการตัดสินใจเรื่องการกู้คืน การตรวจสอบที่ล้มเหลวควรปฏิบัติตามนโยบายการกู้คืนของการเชื่อมต่อเอง ไม่ใช่กฎที่ซ่อนอยู่ใน logrotate และไม่มีการจัดวางการบันทึกใดควรเป็นเหตุผลให้รีสตาร์ทอุโมงค์ที่ทำงานอยู่