การอภิปรายล่าสุดเกี่ยวกับกลยุทธ์ logging ในระบบที่มีปริมาณงานสูงได้จุดประกายการถกเถียงที่น่าสนใจในหมู่นักพัฒนา การสนทนามีจุดศูนย์กลางอยู่ที่ว่าแอปพลิเคชันควร log ความคืบหน้าทุก X วินาที (time-based) หรือทุก X รายการที่ประมวลผล (count-based) แต่การตอบสนองของชุมชนเผยให้เห็นประเด็นที่ลึกซึ้งกว่าเกี่ยวกับจุดประสงค์พื้นฐานของ logging เอง
ปัญหาหลักของแนวทาง Logging แบบดั้งเดิม
ข้อเสนอเดิมแนะนำว่า time-based logging ให้อัตราการส่งออกที่สม่ำเสมอกว่าเมื่อเปรียบเทียบกับ count-based logging ในระบบที่อาจประมวลผลเหตุการณ์หลายล้านครั้งต่อวินาทีในการใช้งานจริง แต่มีเพียงไม่กี่ครั้งในระหว่างการทดสอบในเครื่อง count-based logging สร้างปริมาณ log ที่แตกต่างกันอย่างมาก time-based logging มีเป้าหมายที่จะแก้ไขปัญหานี้โดยการรักษาการส่งออกที่คงที่โดยไม่คำนึงถึงความเร็วในการประมวลผล
อย่างไรก็ตาม นักพัฒนาที่มีประสบการณ์ในชุมชนได้ระบุปัญหาพื้นฐานที่สำคัญกว่าอย่างรวดเร็ว การถกเถียงไม่ได้เกี่ยวกับกลยุทธ์เวลาจริงๆ แต่เป็นเรื่องของการสับสน logs กับ metrics ความแตกต่างนี้สำคัญเพราะแต่ละอย่างมีจุดประสงค์ที่แตกต่างกันและควรได้รับการจัดการที่แตกต่างกัน
การเปรียบเทียบระหว่างการบันทึก Log แบบนับจำนวนกับแบบตามเวลา
| วิธีการ | ข้อดี | ข้อเสีย |
|---|---|---|
| แบบนับจำนวน | • การใช้หน่วยความจำที่จำกัด<br>• การใช้ทรัพยากรที่คาดการณ์ได้<br>• การใช้งานที่เรียบง่าย | • อัตราการบันทึก log ที่ไม่สม่ำเสมอ<br>• การปรับขนาดที่ไม่ดีในสภาพแวดล้อมต่างๆ<br>• ปริมาณข้อมูลที่ออกมาไม่แน่นอน |
| แบบตามเวลา | • อัตราการออกข้อมูล log ที่สม่ำเสมอ<br>• พฤติกรรมที่ไม่ขึ้นกับสภาพแวดล้อม<br>• ปริมาณ log ที่คาดการณ์ได้ | • การใช้หน่วยความจำที่อาจไม่จำกัด<br>• การใช้งานที่ซับซ้อนมากขึ้น<br>• ความต้องการในการเก็บข้อมูลที่แปรผัน |
Logs กับ Metrics: ทำความเข้าใจความแตกต่าง
ชุมชนเน้นย้ำอย่างแรงว่า logs ควรจับภาพเหตุการณ์เฉพาะและข้อมูลสถานะ ในขณะที่ metrics ควรติดตามการวัดและสถิติ Logs มีไว้เพื่อบันทึกเหตุการณ์ที่น่าสนใจ เช่น ข้อผิดพลาด การเปลี่ยนแปลงสถานะ หรือเหตุการณ์ที่น่าสังเกต ในทางตรงกันข้าม Metrics วัดสิ่งต่างๆ เช่น อัตราการประมวลผล ประสิทธิภาพของระบบ และสถิติการดำเนินงาน
รายการ log ควรจับภาพเหตุการณ์ในเวลา ตัวอย่างเช่น: บุคคลที่เข้าสู่ระบบ ความล้มเหลว บันทึกของเหตุการณ์ที่น่าสังเกตที่เกิดขึ้น เป็นต้น ในทางตรงกันข้าม metric เป็นค่าเดียว การจับภาพขนาดของสิ่งใดสิ่งหนึ่ง ณ จุดเวลาหนึ่ง ที่วัดในหน่วยหรือด้วยมิติ
การแยกนี้สำคัญเพราะการผสมทั้งสองอย่างสร้างปัญหา เมื่อ metrics ถูกฝังใน logs พวกมันจะกลายเป็นสิ่งที่ขึ้นอยู่กับระดับ log วิเคราะห์ได้ยากขึ้น และบังคับข้อจำกัดด้านเวลาที่รวมการดำเนินการ I/O ที่ไม่จำเป็น
ความแตกต่างหลัก: Logs เทียบกับ Metrics
- Logs: บันทึกเหตุการณ์เฉพาะ การเปลี่ยนแปลงสถานะ ข้อผิดพลาด และเหตุการณ์สำคัญที่เกิดขึ้น ณ เวลาที่เกิดขึ้น
- Metrics: วัดประสิทธิภาพของระบบ อัตราการประมวลผล และสถิติการดำเนินงานตลอดช่วงเวลา
- การจัดเก็บ: Logs โดยทั่วไปจะถูกเก็บในรูปแบบ text/JSON ส่วน metrics จะถูกเก็บในฐานข้อมูล time-series
- การวิเคราะห์: Logs ถูกค้นหาและกรองข้อมูล ส่วน metrics ถูกรวบรวมและแสดงผลด้วยภาพ
- ช่วงเวลา: Logs ถูกเขียนเมื่อเหตุการณ์เกิดขึ้น ส่วน metrics ถูกเก็บรวบรวมเป็นระยะ
โซลูชัน Observability สมัยใหม่
การอภิปรายเผยให้เห็นว่าแพลตฟอร์ม observability สมัยใหม่ได้พัฒนาไปเพื่อจัดการกับความท้าทายเหล่านี้อย่างไร เครื่องมือเช่น Datadog , Honeycomb และระบบที่สร้างขึ้นบนมาตรฐาน OpenTelemetry ช่วยให้นักพัฒนาสามารถส่งข้อมูลที่มีโครงสร้างซึ่งสามารถแบ่งส่วนและวิเคราะห์ได้หลายวิธี แพลตฟอร์มเหล่านี้สามารถจัดการเหตุการณ์แต่ละรายการและให้ผู้ใช้สร้างมุมมอง metrics แบบกำหนดเองโดยไม่ต้องรวมข้อมูลล่วงหน้า
แนวทางนี้มีข้อได้เปรียบอย่างมากสำหรับการ debug และการวิเคราะห์ระบบ นักพัฒนาสามารถติดตาม session ของผู้ใช้แต่ละรายข้ามหลายบริการ กรองข้อมูลตามคุณลักษณะเฉพาะ และเจาะลึกจาก metrics ระดับสูงไปยัง trace แต่ละรายการเมื่อเกิดปัญหา
ข้อพิจารณาการนำไปใช้ในทางปฏิบัติ
สำหรับระบบที่ต้องการ progress logging จริงๆ สมาชิกชุมชนหลายคนแนะนำแนวทางแบบผสม วิธีเหล่านี้รวมเกณฑ์เวลาและจำนวน โดย log เมื่อเงื่อนไขใดเงื่อนไขหนึ่งเป็นจริง สิ่งนี้ให้การใช้หน่วยความจำที่มีขอบเขตในขณะที่รักษาอัตราการส่งออกที่สมเหตุสมผล
นักพัฒนาบางคนยังชี้ให้เห็นข้อจำกัดของทรัพยากรกับ pure time-based logging การเก็บข้อมูลจำนวนผันแปรเป็นระยะเวลาคงที่สามารถใช้หน่วยความจำได้ไม่จำกัด ในขณะที่แนวทาง count-based ใช้ทรัพยากรที่คาดเดาได้
เส้นทางไปข้างหน้า
ฉันทามติของชุมชนแนะนำว่าสถานการณ์การติดตาม progress ส่วนใหญ่ได้รับการบริการที่ดีกว่าโดยระบบ metrics ที่เหมาะสมมากกว่า logs Logs ควรมุ่งเน้นไปที่การจับภาพเหตุการณ์และข้อผิดพลาดที่มีความหมาย ในขณะที่ metrics ควรจัดการกับการวัดประสิทธิภาพและปริมาณงาน
สำหรับทีมที่เพิ่งเริ่มต้นกับระบบปริมาณงานสูง นี่หมายถึงการลงทุนในโครงสร้างพื้นฐาน observability ที่เหมาะสมตั้งแต่เนิ่นๆ เครื่องมือสมัยใหม่ทำให้ง่ายขึ้นในการแยกข้อกังวลอย่างเหมาะสมและให้ความสามารถในการ debug ที่ดีกว่าแนวทาง logging แบบดั้งเดิม
การถกเถียงเน้นให้เห็นว่าการตัดสินใจสถาปัตยกรรมระบบที่ดูเรียบง่ายบนพื้นผิวมักเผยให้เห็นหลักการออกแบบที่ลึกซึ้งกว่า ในกรณีนี้ คำถามเกี่ยวกับเวลาที่จะ log นำไปสู่การอภิปรายที่สำคัญเกี่ยวกับจุดประสงค์พื้นฐานของเครื่องมือ observability ที่แตกต่างกัน
อ้างอิง: Log by Time, not by Count