Skip to content
Tech

ทำไมฉันถึงไม่สามารถติดตามความล้มเหลวใน production ที่ผ่าน message queue?

83

โอกาส

Distributed tracing สมมติว่ามีกราฟ span ที่เชื่อมต่อกัน แต่สถาปัตยกรรม microservice จริงๆ ส่งต่อ traffic จำนวนมากผ่าน message queues, event streams และ async callbacks ที่ทำให้การส่งต่อ span หยุดชะงัก เมื่อความล้มเหลวเกิดขึ้นปลายทางของขอบเขต queue เครื่องมือ observability ที่มีอยู่จะเห็นเพียงชิ้นส่วนที่ขาดการเชื่อมต่อและไม่สามารถสร้างความสัมพันธ์เชิงเหตุและผลได้ งานวิจัย RCA ล่าสุดในระบบ microservice production ระบุจุดบอด async เหล่านี้อย่างชัดเจนว่าเป็นรูปแบบความล้มเหลวหลักของเครื่องมือในปัจจุบัน และการสำรวจ CNCF ปี 2025 พบว่า 78 เปอร์เซ็นต์ขององค์กรที่รัน microservices ระบุช่องว่างด้าน observability ว่าเป็นความท้าทายด้านการดำเนินงานอันดับหนึ่ง ทีมงานในสถาปัตยกรรมที่ใช้ queue มากต้องจับคู่ timestamps ของ log ด้วยตนเองเพื่อหาต้นตอของการหยุดทำงาน ไม่มีเครื่องมือระดับ production ใดที่ปิดช่องว่างนี้ในการขนส่งที่หลากหลาย

ทำไมถึงสำคัญ

การปิดช่องว่างการติดตาม async boundary ทำให้เครื่องมือ observability ใช้ได้จริงกับสถาปัตยกรรม event-driven ที่ระบบ production ส่วนใหญ่ใช้อยู่ในปัจจุบัน

วิธีที่ผมให้คะแนนโอกาส

คะแนนโอกาสเป็นมุมมองส่วนตัวของผม ไม่ใช่การวัดผล โดยดูว่ามันเจ็บปวดแค่ไหน บ่อยแค่ไหนที่มันกัดกิน และมีทางแก้อยู่น้อยเพียงใดในปัจจุบัน คะแนนสูงกว่าหมายความว่าผมคิดว่าคุ้มค่าแก่การสร้างมากกว่า

ความรุนแรง8/10

ความเจ็บปวดที่มันก่อขึ้นเมื่อปรากฏตัว

ความถี่8/10

ความถี่ที่คนจริงๆ เจอมัน

ช่องว่าง8/10

ความขาดแคลนของเครื่องมือที่ดีสำหรับมันในปัจจุบัน

ปัญหาอื่นที่น่าแก้ไข