วิธีเลือก Logging API สำหรับโปรเจกต์เล็กด้วยการทดสอบ 3 รูปแบบ

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

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

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

ผู้เขียนแนะนำให้ส่งเหตุการณ์พื้นฐาน 4 รูปแบบ ได้แก่ import_started, import_completed, import_empty และ import_failed พร้อมแนบตัวระบุการนำเข้า, ชื่อแหล่งที่มา, เวลาที่ทำงาน, จำนวนผลลัพธ์ และตัวระบุความสัมพันธ์ โดยควรหลีกเลี่ยงการนำเนื้อหาข้อความของลูกค้ามาใส่ในบันทึกประจำ

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

"หากผู้ให้บริการไม่สามารถช่วยกู้คืนการทำงาน 3 ครั้งล่าสุดจากบันทึกที่ค้นหาได้ แสดงว่านั่นไม่ใช่ตัวเลือกที่เหมาะสม"

ผู้เขียนบทความบน Dev.to

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