วิธีล้างบันทึกการตรวจสอบของ Zimbra เพื่อเพิ่มพื้นที่ว่างในดิสก์อย่างปลอดภัย

เริ่มต้นด้วยการตัดสินใจว่าคุณต้องการกำจัดอะไรออกไปจริงๆ

เซิร์ฟเวอร์ Zimbra ที่มีพื้นที่ดิสก์เหลือน้อยอาจทำให้การล้างบันทึกข้อมูลดูเป็นเรื่องเร่งด่วน แต่/opt/zimbra/log/audit.logบันทึกเหล่านี้ไม่ใช่แค่ข้อมูลการวินิจฉัยที่ใช้แล้วทิ้งเท่านั้น Zimbra บันทึกไว้ว่าเป็นบันทึกการตรวจสอบเหตุการณ์การอนุญาตและการดำเนินการด้านการบริหารจัดการ นั่นหมายความว่าวิธีการล้างข้อมูลที่ดีที่สุดขึ้นอยู่กับว่าคุณต้องการพื้นที่ว่างทันที หลักฐานทางประวัติศาสตร์ หรือวิธีแก้ไขปัญหาการเก็บรักษาข้อมูลในระยะยาว

วิธีที่ปลอดภัยที่สุดคือปล่อยaudit.logไฟล์ที่ใช้งานอยู่ไว้เฉยๆ และจัดการกับสำเนาเก่าที่หมุนเวียนไว้ก่อน หากคุณอยู่ภายใต้นโยบายการเก็บรักษาภายใน การระงับทางกฎหมาย หรือข้อกำหนดด้านการปฏิบัติตามกฎระเบียบ ให้เก็บไฟล์เหล่านั้นไว้ในระบบไฟล์อื่นก่อนที่จะลบอะไรก็ตาม หากไฟล์ที่ใช้งานอยู่มีขนาดใหญ่ผิดปกติ คุณสามารถล้างไฟล์นั้นได้ แต่ควรดำเนินการในกรณีฉุกเฉินเท่านั้น เพราะจะลบประวัติการตรวจสอบปัจจุบันและอาจทำให้เกิดปัญหาการทำงานพร้อมกันได้เล็กน้อยหากเซิร์ฟเวอร์ยังคงเขียนข้อมูลอยู่ขณะที่คุณคัดลอกไฟล์

เอกสารเกี่ยวกับการบันทึกข้อมูลของ Zimbra เองได้จัดaudit.logวาง/opt/zimbra/logและอธิบายว่า Log4j เป็นส่วนประกอบที่รับผิดชอบในการหมุนเวียนไฟล์ต่างๆ เช่นaudit.logและmailbox.logบันทึกข้อมูลอื่นๆ ของ Zimbra อาจใช้การกำหนดค่าของระบบปฏิบัติการแทนlogrotateดังนั้นอย่าคิดว่าทุกไฟล์ในไดเร็กทอรีจะใช้กลไกเดียวกัน โปรดดูข้อมูลอ้างอิงไฟล์บันทึกข้อมูลอย่างเป็นทางการของ Zimbraและ หมายเหตุ เกี่ยวกับการหมุนเวียนบันทึกข้อมูลของ Zimbra

เปรียบเทียบตัวเลือกการทำความสะอาดก่อนตัดสินใจดำเนินการ

ขั้นตอนที่ 1: วัดขนาดของปัญหา ก่อนที่จะลบอะไรออกไป

ขั้นแรก ตรวจสอบให้แน่ใจว่าบันทึกการตรวจสอบเป็นสาเหตุของปัญหาจริง ๆ โดยเรียกใช้คำสั่งเหล่านี้root:

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*

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

โปรดบันทึกเวอร์ชันที่ติดตั้งไว้ก่อนทำการเปลี่ยนแปลงพฤติกรรม:

su - zimbra -c 'zmcontrol -v'

เรื่องนี้สำคัญเพราะเอกสารประกอบของ Zimbra ครอบคลุมผลิตภัณฑ์หลายรุ่น และไวยากรณ์ Log4j การกำหนดค่าที่สร้างขึ้น และงานการตัดแต่งอาจแตกต่างกัน อย่าคัดลอกค่าการเก็บรักษาจากตัวอย่างวิกิเก่าแล้วคิดว่าเป็นค่าเริ่มต้นปัจจุบันของคุณ

ตรวจสอบการใช้งานระบบไฟล์ ขนาดไฟล์บันทึกทั้งหมดของ Zimbra และรุ่นของไฟล์บันทึกการตรวจสอบแต่ละรุ่น ก่อนตัดสินใจว่าจะลบอะไรออก

ขั้นตอนที่ 2: ตรวจสอบว่าเซิร์ฟเวอร์นี้หมุนเวียนและตัดแต่งไฟล์บันทึกอย่างไร

เอกสารของ Zimbra ระบุกลไกที่เกี่ยวข้องสองอย่าง ได้แก่ Log4j สำหรับไฟล์ที่มีข้อมูลaudit.logและบันทึกของระบบปฏิบัติการlogrotateสำหรับบันทึกอื่นๆ ของ Zimbra อีกหลายรายการ นอกจากนี้ยังระบุว่า crontab ของ Zimbra เองอาจมีงานบำรุงรักษาบันทึกอยู่ด้วย ตรวจสอบการกำหนดค่าแบบเรียลไทม์แทนการคาดเดา:

su - zimbra
crontab -l
exit

grep -n "audit.log" /opt/zimbra/conf/log4j.properties
grep -n "audit.log" /opt/zimbra/conf/log4j.properties.in

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

สำหรับเซิร์ฟเวอร์ที่มีปริมาณการตรวจสอบสูงผิดปกติ ให้ตรวจสอบว่ามีการเปิดใช้งานการบันทึกเพิ่มเติมโดยตั้งใจzimbra_additional_loggingหรือไม่ เอกสารบันทึกการเผยแพร่ Zimbra 10.0.6 ระบุถึงคุณลักษณะการกำหนดค่าภายในเครื่อง ซึ่งสามารถเพิ่มเหตุการณ์การตรวจสอบสิทธิ์ที่ล้มเหลวหรือเหตุการณ์ที่มีประโยชน์อื่นๆ ลงในไฟล์audit.logบันทึกได้ อย่าปิดใช้งานการบันทึกความปลอดภัยที่มีประโยชน์เพียงเพื่อประหยัดพื้นที่ หากปริมาณข้อมูลนั้นถูกต้องตามกฎหมาย วิธีที่ดีกว่ามักจะเป็นการเก็บรักษา การบีบอัด หรือการจัดเก็บไฟล์บันทึกแบบรวมศูนย์ ดูเอกสารบันทึกการเผยแพร่ Zimbra 10.0.6 อย่าง เป็น ทางการ

ตรวจสอบการตั้งค่า crontab และ Log4j ของเซิร์ฟเวอร์อย่างละเอียดก่อนเปลี่ยนแปลงพฤติกรรมการเก็บรักษาหรือการหมุนเวียนไฟล์บันทึก

ขั้นตอนที่ 3: เลือกที่จะเก็บถาวรหรือลบไฟล์บันทึกที่หมุนเวียนก่อน

สำหรับผู้ดูแลระบบส่วนใหญ่ ไฟล์บันทึกการตรวจสอบที่หมุนเวียนเก่าๆ คือเป้าหมายแรกที่ดีที่สุด ควรใช้findในโหมดรายงานอย่างเดียว ก่อนที่จะลบอะไรก็ตาม ตัวอย่างต่อไปนี้แสดงรายการไฟล์บันทึกการตรวจสอบที่หมุนเวียนซึ่งมีอายุมากกว่า 30 วัน 30 วันเป็นเพียงเกณฑ์ตัวอย่าง ไม่ใช่ระยะเวลาการเก็บรักษาที่ Zimbra กำหนดไว้:

find /opt/zimbra/log -maxdepth 1 -type f -name 'audit.log.*' -mtime +30 -print

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

mkdir -p /mnt/backup/zimbra-audit-logs
cp --preserve=mode,ownership,timestamps   /opt/zimbra/log/audit.log.OLD_GENERATION   /mnt/backup/zimbra-audit-logs/

ทำซ้ำขั้นตอนนี้สำหรับชื่อไฟล์ที่ตรวจสอบแล้วทุกประการ ตรวจสอบการสำรองข้อมูลก่อนลบแหล่งที่มา หลีกเลี่ยงรูปแบบกว้างๆ เช่นrm -f /opt/zimbra/log/audit.log*; รูปแบบนั้นจะตรงกับไฟล์ที่ใช้งานอยู่ด้วย

หากคุณต้องการเก็บไฟล์บันทึกเก่าไว้ในเครื่องแต่ต้องการลดขนาดไฟล์ ให้บีบอัดเฉพาะไฟล์ที่หมุนเวียนแล้วเท่านั้น:

gzip /opt/zimbra/log/audit.log.OLD_GENERATION

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

คำแนะนำเกี่ยวกับการบันทึก ข้อมูลในอดีตของ Zimbra ยังเตือนด้วยว่าบันทึกการตรวจสอบอาจมีข้อมูลที่ละเอียดอ่อน จึงควรปฏิบัติต่อบันทึกที่เก็บถาวรด้วยการควบคุมการเข้าถึงเช่นเดียวกับบันทึกที่ใช้งานอยู่ ดูคำแนะนำเกี่ยวกับการบันทึกข้อมูลอย่างเป็นทางการของ Zimbra

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

เมื่อใดจึงควรตัดทอนไฟล์ audit.log ที่ใช้งานอยู่

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

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

su - zimbra -c 'zmmailboxdctl stop'

cp --preserve=all /opt/zimbra/log/audit.log   /mnt/backup/audit.log.$(date +%Y%m%d-%H%M%S)

truncate -s 0 /opt/zimbra/log/audit.log

su - zimbra -c 'zmmailboxdctl start'

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

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

ขั้นตอนที่ 4: ตรวจสอบการกู้คืนดิสก์และการบันทึกข้อมูลอย่างต่อเนื่อง

หลังจากทำความสะอาดเสร็จแล้ว ให้ตรวจสอบผลลัพธ์อีกครั้งแทนที่จะพึ่งพาเพียงแค่ว่าไม่มีข้อผิดพลาด:

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*
tail -n 20 /opt/zimbra/log/audit.log
su - zimbra -c 'zmcontrol status'

ผลลัพธ์ที่ดีมีสามสัญญาณ ได้แก่ พื้นที่ว่างในระบบไฟล์ที่ต้องการเพิ่มขึ้นaudit.logยังคงอยู่และรับเหตุการณ์ใหม่ ๆ และบริการ Zimbra ที่เกี่ยวข้องยังคงทำงานอยู่ หากdfยังคงรายงานว่าระบบไฟล์เต็มในขณะที่duพื้นที่ว่างลดลงอย่างมาก ให้ตรวจสอบไฟล์ที่ถูกลบแล้วแต่ยังคงเปิดอยู่โดยกระบวนการที่กำลังทำงานอยู่ก่อนที่จะลบข้อมูลเพิ่มเติม

ตรวจสอบพื้นที่ที่กู้คืนได้ กิจกรรมการตรวจสอบล่าสุด และสถานะการทำงานของบริการหลังจากทำการล้างข้อมูลเสร็จสิ้น

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

หากการเจริญเติบโตเป็นปกติ แต่ระยะเวลาการคงอยู่ของเชื้อนานเกินไป

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

หากเสียงรบกวนจากการตรวจสอบสิทธิ์เป็นตัวขับเคลื่อนระดับเสียง

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

หากคุณจำเป็นต้องเก็บรักษาประวัติการตรวจสอบบัญชีเป็นเวลาหลายเดือน

ย้ายหรือจัดส่งไฟล์บันทึกไปยังพื้นที่จัดเก็บที่ออกแบบมาเพื่อการเก็บรักษา การบันทึกแบบรวมศูนย์ พื้นที่จัดเก็บแบบอ็อบเจ็กต์ หรือระบบไฟล์บันทึกเฉพาะ จะแยกประวัติการปฏิบัติตามข้อกำหนดออกจากความจุที่แพลตฟอร์มอีเมลต้องการ เอกสารเกี่ยวกับไฟล์บันทึกของ Zimbra ได้กล่าวถึงตัวเลือกการบันทึกแบบรวมศูนย์ไว้อย่างชัดเจน รวมถึงaudit.log.

สิ่งที่ไม่ควรทำ

• ห้ามลบaudit.log*โดยใช้สัญลักษณ์ตัวแทน (wildcard) ที่ยังไม่ได้ตรวจสอบ
• อย่าคิดว่า/etc/logrotate.d/zimbraระบบควบคุมจะจัดการบันทึกการตรวจสอบที่ใช้งานอยู่ทุกครั้งที่มีการเผยแพร่เวอร์ชันใหม่ Zimbra ระบุว่า Log4j เป็นกลไกการหมุนเวียนสำหรับเรื่องaudit.logนี้
• อย่าบีบอัดหรือจัดเก็บข้อมูลลงในระบบไฟล์ที่ใกล้เต็มเดียวกัน เว้นแต่คุณจะตรวจสอบแล้วว่ามีพื้นที่ว่างชั่วคราวเพียงพอ
• อย่าลดระยะเวลาการเก็บรักษาข้อมูลโดยไม่ตรวจสอบข้อกำหนดขององค์กร กฎหมาย หรือความปลอดภัยก่อน
• อย่าแก้ไขไฟล์ Log4j ที่สร้างขึ้นอย่างถาวรโดยไม่เข้าใจว่า Zimbra จะสร้างไฟล์เหล่านั้นขึ้นใหม่จากเทมเพลตหรือไม่

ตรวจสอบขั้นสุดท้าย

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