เราเพิ่งย้ายหนึ่งในแอปพลิเคชันของเราไปยังแพลตฟอร์ม "Corretto 8 ที่ทำงานบน 64 บิต Amazon Linux 2/3.2.12" ตอนนี้เรากำลังพบปัญหาที่ไฟล์บันทึกกำลังเต็มดิสก์ของเราในช่วงเวลาหนึ่งสัปดาห์ เราไม่ได้มีปัญหามาก่อน
สิ่งที่น่ารำคาญคือเรากำลังสตรีมบันทึกเหล่านั้นไปยัง cloudwatch ดังนั้นเราจึงไม่ต้องการบันทึกเหล่านั้นในอินสแตนซ์เอง
สิ่งที่น่ารำคาญยิ่งกว่าคือเอกสารทั้งหมด บล็อกโพสต์ ฯลฯ ฉันพบว่าเรื่องนี้ไม่ได้เขียนขึ้นสำหรับแพลตฟอร์มนี้ เมื่อดูที่โครงสร้างไฟล์ ดูเหมือนว่าจะใช้แนวทางอื่นที่ฉันยังคิดไม่เสร็จ
ก่อนอื่น ไม่มีโฟลเดอร์ /var/log/httpd ... หรือโฟลเดอร์อื่นสำหรับบันทึกเฉพาะ ถึงตอนนี้ฉันรู้แล้วว่าสิ่งที่ส่งไปยัง web.stdout.log logstream (ซึ่งในแพลตฟอร์มเก่าเคยตั้งชื่อต่างกัน แต่ฉันจำไม่ได้ว่าแม่นยำแค่ไหน ในกรณีใด ๆ แอปพลิเคชันสปริงบูตจะบันทึก ถึง) ถูกเก็บไว้ในไฟล์ /var/log/messages
ฉันรู้เรื่องนี้เพราะในขณะที่วิเคราะห์สาเหตุที่พื้นที่ดิสก์ของเราหมด ไฟล์นี้จะมีขนาดใหญ่ที่สุดเพียงไฟล์เดียวในดิสก์ทั้งหมด ยกเว้นทันทีหลังจากที่อินสแตนซ์เริ่มต้นขึ้น อินสแตนซ์จะมีขนาดที่เหมาะสม หลังจากผ่านไป 3 วัน มันจะมีขนาดได้ถึง 2 GB และจะเติบโตขึ้นเรื่อยๆ จนกระทั่งไม่เหลืออะไรเลย เป็นที่มาของปัญหาของเราอย่างไม่ต้องสงสัย
คำถามคือฉันจะได้อะไร ทำ เกี่ยวกับมัน? การหมุนบันทึกอยู่ในการกำหนดค่าเริ่มต้น และฉันสามารถเห็นไฟล์บางไฟล์ใน /var/log/rotated (ซึ่งเป็นโฟลเดอร์อื่นจากที่เคยเป็นบันทึกการหมุน) แต่ไฟล์เหล่านั้นมีขนาดเล็ก (ไฟล์ที่ใหญ่ที่สุดคือ 1.3 MB ที่น่ารัก ขนาด...) และขนาดของ /var/log/messages ไม่เคยลดลง แต่จะขยายใหญ่ขึ้นเท่านั้น
ฉันได้อ่านบทความมากมายเกี่ยวกับวิธีแก้ปัญหาที่คล้ายกันโดยการกำหนดค่า logrotate โดยใช้ ebextensions โดย AWS เองและบล็อกเกอร์ แต่จากทั้งหมดนั้นฉันสามารถเห็นได้อย่างรวดเร็วว่าพวกเขาสร้างขึ้นจากโครงสร้างที่แตกต่างกันมาก ดังนั้นพวกเขาจึงไม่ ดูเหมือนจะใช้ได้ นอกจากนี้ เราเคยมีประสบการณ์มาแล้วในระหว่างการย้ายข้อมูลว่าบางสิ่งที่ทำกับ ebextension ตอนนี้ไม่ได้ทำด้วย ebextension อีกต่อไป แต่เอกสารค่อนข้างขาด
มีใครรู้จักแพลตฟอร์มนี้มากพอที่จะบอกเบาะแสเกี่ยวกับวิธีที่ฉันจะกำหนดค่านี้ได้บ้าง ฉันไม่จำเป็นต้อง หมุน ท่อนซุง พูดตามตรง ฉันอยากให้มันหายไปทันทีที่มันมีอายุมากกว่าหนึ่งชั่วโมง เรามีพวกเขาใน cloudwatch หลังจากทั้งหมด ...
ข้อมูลเพิ่มเติม
ยิ่งฉันค้นหาสิ่งนี้มากเท่าไหร่ ฉันก็ยิ่งสับสนมากขึ้นเท่านั้น มีไฟล์ /var/log/web.stdout.log ซึ่งรับข้อความเหมือนกับ /var/log/messages เมื่อดูเนื้อหาของ logrotate.elasticbeanstalk.hourly นี่เป็นไฟล์ที่อยู่ระหว่างการหมุนบันทึก และดูเหมือนว่าจะทำงานได้ดี
เมื่อทำ lsof กระบวนการที่ใช้ไฟล์นั้นคือ rsyslogd ตามความคิดเห็นของ shearn89 ด้านล่าง เห็นได้ชัดว่านั่นคือ syslog ใหม่และทุกสิ่งที่บันทึกไปยัง stdout จะถูกบันทึกไว้ที่นั่น
เมื่อตระหนักว่าไฟล์นั้นไม่ได้อยู่ภายใต้การหมุนใดๆ ฉันจึงพยายามตั้งค่านั้น สำหรับตอนนี้ในอินสแตนซ์โดยตรง ฉันจะหาวิธีดำเนินการในการกำหนดค่าสภาพแวดล้อมจริงในภายหลัง
ฉันได้สร้างไฟล์ปรับแต่งใหม่ใน /etc/logrotate/elasticbeanstalk.hourly โดยมีเนื้อหาดังต่อไปนี้:
/var/log/ข้อความ {
su ราก
ขนาด 10M
หมุน 5
หายไป
บีบอัด
การแจ้งเตือน
copytruncate
วันที่
รูปแบบวันที่ %s
olddir /var/log/rotated
}
วิ่ง sudo /usr/sbin/logrotate /etc/logrotate.elasticbeanstalk.hourly/logrotate.elasticbeanstalk.messages.conf --debug
ฉันได้รับผลลัพธ์ต่อไปนี้:
รูปแบบการหมุน: /var/log/messages 10485760 ไบต์ (5 รอบ)
olddir คือ /var/log/rotated ไฟล์บันทึกว่างจะไม่หมุน บันทึกเก่าจะถูกลบออก
พิจารณาบันทึก /var/log/messages
บันทึกต้องหมุน
บันทึกการหมุน /var/log/messages, log->rotateCount คือ 5
แปลง ' %s' -> '%s'
dateext ต่อท้าย '1646905905'
รูปแบบลูกโลก '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0 -9]'
glob การค้นหาบันทึกการหมุนเก่าล้มเหลว
คัดลอก /var/log/messages ไปยัง /var/log/rotated/messages1646905905
ตัดทอน /var/log/messages
บันทึกการบีบอัดด้วย: /bin/gzip
ดูเหมือนจะมีแนวโน้ม แต่ความจริงก็คือไม่มีอะไรเปลี่ยนแปลง ไฟล์ยังคงมีขนาดเท่าเดิม และไม่มีไฟล์ใดถูกสร้างขึ้นในโฟลเดอร์การหมุน ดูเหมือนจะไม่มีผลอะไรเลย
ฉันได้เปลี่ยนการกำหนดค่าเพื่อให้มันย้ายและสร้างแทนการตัดทอน ฉันได้ลอง -f แล้ว ทั้งหมดมีผลลัพธ์เดียวกัน ไม่มีข้อผิดพลาดจาก logrotate แต่ก็ไม่มีผลเช่นกัน ไฟล์นั้นดูเหมือนจะไม่สามารถเจาะเลือดได้