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

answer

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

เมื่อผู้คนนึกถึงการบันทึกจากระยะไกลที่แขวนสิ่งของใน * nix land มักจะเป็นเพราะพวกเขาเข้าสู่การเมานต์ nfs ซึ่งอาจทำให้เกิดการแฮงค์ได้อย่างแน่นอน ซิสล็อก คุณสบายดี

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

นั่น (โดยทั่วไป) มีแนวโน้มที่จะทบต้นปัญหาเพราะสิ่งต่าง ๆ เริ่มล้มเหลวและต้องการส่งสัญญาณให้มาก แต่ต้องรอให้ syslog ยอมรับข้อความของพวกเขา

โปรดทราบว่ายังมีข้อบกพร่องที่อาจทำให้เกิดพฤติกรรมที่ไม่เหมาะสมในสถานการณ์ดังกล่าว - โดยเฉพาะอย่างยิ่ง rsyslog ทำให้เกิดปัญหานี้ใน RH ( https://bugzilla.redhat.com/show_bug.cgi?id=519203 ) ดังนั้นฉันขอแนะนำให้ตรวจสอบเวอร์ชันซอฟต์แวร์ของคุณกับข้อบกพร่องที่รู้จักอย่างแน่นอน

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

โชคดีที่ยังมีการแก้ไขหลายอย่าง (ไม่ใช่เฉพาะสำหรับ syslog-ng) แต่คุณจะต้องประนีประนอมเป็นเวอร์ชันสั้น

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

  2. อีกทางเลือกหนึ่งคือการเลือกสรรสิ่งที่คุณส่งผ่านเครือข่ายมากขึ้น เช่น ตัวกรอง และ/หรือจัดลำดับความสำคัญ บางรายการจะไหลมากกว่าตัวเลือกอื่นๆ ความช่วยเหลือมากน้อยเพียงใดนั้นขึ้นอยู่กับว่ามีตัวเลือกใดบ้างในการใช้งาน syslog ที่คุณเลือก - rsyslog มีตัวเลือกค่อนข้างมาก ส่วนอื่นๆ ที่ฉันไม่ค่อยคุ้นเคย

  3. ไม่จำเป็นต้องเข้าสู่ระบบเครือข่ายโดยตรงเสมอไป คุณสามารถพิจารณาไม่ทำเช่นนั้น และใช้แทน log tailing/parsing agent (เช่นhttps://www.elastic.co/products/logstash ) แทน - สิ่งนี้สามารถหลีกเลี่ยงการสัมผัสการตั้งค่า syslog ที่ใช้งานได้ ในขณะที่ยังมีรีโมต การบันทึก (คุณยังสามารถให้เอเจนต์ฟังบน localhost และส่งต่อข้อมูล syslog ในเครื่องได้ หากคุณไม่ได้เก็บข้อมูลไว้ในไฟล์)

  4. ในบันทึกที่คล้ายกัน เราขอแนะนำให้คุณตรวจสอบนโยบาย auditd ของคุณและดูว่ามีอะไรที่อาจก่อให้เกิดปัญหาหรือไม่ โดยเฉพาะอย่างยิ่ง ถ้า auditd กำลังบันทึกไปยัง syslog โฟลว์ก็อาจมีความสำคัญมาก แม้กระทั่ง (หรือโดยเฉพาะอย่างยิ่ง) เมื่อใช้การกำหนดค่า 'แนวปฏิบัติที่ดีที่สุด' (เช่น เกณฑ์มาตรฐาน CIS) ฉันได้เห็นสิ่งนี้ทำให้เกิดปัญหาในหลาย ๆ ด้าน และในบางกรณีเมื่อ audispd ไม่สามารถส่งข้อความไปยัง syslog ได้อีกต่อไป ข้อความนั้นอาจถูกบล็อก

  5. สุดท้าย สำหรับสิ่งต่างๆ เช่น rsyslog คุณยังมีตัวเลือกในการใช้ดิสก์และคิวหน่วยความจำเพื่อบรรเทาปัญหาประเภทนี้ ต้องใช้การตั้งค่าเล็กน้อย (สำหรับ rsyslog โปรดดูที่http://www.rsyslog.com/doc/v8-stable/concepts/queues.html ) แต่อนุญาตให้สร้างการตั้งค่าที่ทนต่อข้อผิดพลาดได้มากขึ้นหากคุณไม่ทำ ไม่สนใจที่จะโยนทรัพยากรไปที่ปัญหา

Rsyslog ให้คำแนะนำสำหรับการตั้งค่าประสิทธิภาพสูง ( http://www.rsyslog.com/doc/v8-stable/examples/high_performance.html ) และเซิร์ฟเวอร์ syslog ที่ล้มเหลว ( http://www.rsyslog.com/doc/v8 -stable/tutorials/failover_syslog_server.html ) ฉันขอแนะนำให้คุณตรวจสอบเซิร์ฟเวอร์บันทึกส่วนกลางเป็นอย่างน้อย เพื่อให้แน่ใจว่าสามารถจัดการกับปริมาณการบันทึก - และปรับแต่งเป็นอย่างอื่นได้ (ฉันมีประสบการณ์ที่ดีในการทำเช่นนี้กับ rsyslog ซึ่งการกำหนดค่าตัวรับ 'มาตรฐาน' ที่เป็นธรรม ไม่สามารถติดตามได้ แต่การปรับแต่งทำให้เราสามารถรองรับปริมาณการรับส่งข้อมูลได้มากขึ้นหลายขนาด)

นอกจากนี้ ให้พิจารณาตรวจสอบการกำหนดค่าการบันทึกของคุณให้กว้างขึ้น - ฉันรู้จากประสบการณ์ (เศร้า) ว่าอาจมีคนมีแนวโน้มที่จะเปิดใช้งานการบันทึก TRACE หรือ DEBUG และปล่อยทิ้งไว้ ซึ่งโดยทั่วไปจะไม่ทำ syslog (หรือระบบโดยทั่วไปมากกว่า) เช่นกัน โปรดปรานมากมาย

คล้ายกับประสบการณ์ของ bagster/growse และ gparent ด้านบน ฉันยังพบสถานการณ์ที่การเรียกใช้ vsyslog() หยุดทำงาน (เป็นเวลา 30 ถึง 20 นาที) เมื่อใช้ syslog-ng ในขณะที่เซิร์ฟเวอร์ระยะไกลไม่พร้อมใช้งาน

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

โปรดทราบด้วยว่าฉันกำลังเข้าสู่ระบบผ่าน UDP ซึ่งคุณคาดว่าจะอำนวยความสะดวกในการไม่ปิดกั้นการดับไฟ

ฉันมองโลกในแง่ดีว่าสามารถอธิบายลักษณะนี้ได้ดีพอที่จะระบุจุดบกพร่องกับ syslog-ng และจะอัปเดตที่นี่หาก/เมื่อฉันทำ

ฉันรู้ว่ามันเป็นข้อความเก่า แต่ฉันจะตอบถ้าคนอื่นกดหน้านี้

เราเคยเห็นกรณีที่การบันทึกจากระยะไกลทำให้เซิร์ฟเวอร์หยุดทำงาน Syslog-ng เมื่อสูญเสียการเข้าถึงเครือข่ายไปยัง loghost ให้เริ่มบัฟเฟอร์ และเมื่อบัฟเฟอร์เต็ม จะหยุดอ่านจาก/dev/logไฟล์ ที่ "เต็ม" ทำให้การตรวจสอบของเราล้มเหลว พยายามเขียนไปยัง/dev/log.