ข้ามไปเนื้อหาหลัก

นักพัฒนาสร้าง AI Agent วิเคราะห์ปัญหาแอปบน SigNoz ถามตอบได้เหมือนเพื่อนร่วมทีม

เจาะเบื้องหลังการสร้าง Why Did It Break เอเจนต์ตรวจจับปัญหาแอปพลิเคชันที่ดึงข้อมูลสดจาก SigNoz พร้อมลิงก์ตรงสู่ทราซหลักฐานจริง

เรียบเรียงโดย AI
Inewgen
26 Jul 20263 นาทีอ่าน (0 ครั้ง)อัปเดตล่าสุด 20 Sep 2026
แชร์
นักพัฒนาสร้าง AI Agent วิเคราะห์ปัญหาแอปบน SigNoz ถามตอบได้เหมือนเพื่อนร่วมทีม

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

ขนาดตัวอักษร
  • พัฒนาขึ้นสำหรับงานแฮกกาธอน Agents of SigNoz ในเดือนกรกฎาคม 2026
  • ตอบคำถามเกี่ยวกับปัญหาระบบได้ทันทีด้วยภาษามนุษย์ พร้อมระบุระดับความมั่นใจ
  • เชื่อมโยงหลักฐานทุกชิ้นตรงไปยังทราซ (Trace) ของ SigNoz เพื่อความโปร่งใสสูงสุด
  • แก้ปัญหาเอเจนต์วนลูปด้วยการจำกัดโควตาคำขอและการตรวจสอบสุขภาพล่วงหน้า

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

นี่จึงเป็นที่มาของโครงการ Why Did It Break ซึ่งเป็นเอเจนต์สืบสวนปัญหาที่ทำงานอยู่บน SigNoz ผู้ใช้งานสามารถพิมพ์ถามคำถามได้เหมือนกับการคุยกับเพื่อนร่วมทีม เช่น "ทำไมระบบเช็คเอาต์ถึงช้า?" จากนั้นเอเจนต์จะทำการรันคิวรีสด วิเคราะห์ร่องรอยเหมือนวิศวกรมืออาชีพ และส่งคำตอบกลับมาพร้อมสาเหตุที่แท้จริง หลักฐาน วิธีแก้ที่แนะนำ และระดับความมั่นใจ ทุกข้อกล่าวหาจะมีลิงก์เชื่อมไปยังทราซที่ใช้พิสูจน์ใน SigNoz ทันที

architecture diagram trace logs

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

กฎเหล็กข้อเดียวที่ผู้พัฒนาตั้งไว้ก่อนเริ่มเขียนโค้ดคือ ห้ามใช้ข้อมูลปลอม (No faked data) ไม่ว่าจะเป็นเดโมเดตาจำลองหรือคำตอบสำเร็จรูป หากเอเจนต์ไม่สามารถสนับสนุนข้ออ้างอิงจากเทเลเมทรีสดได้ มันจะต้องตอบว่า "ไม่รู้" และลดระดับความมั่นใจลง กฎข้อนี้ทำให้ฟีเจอร์ทุกตัวต้องรอดพ้นจากการใช้งานจริงกับข้อมูลจริงให้ได้

การสร้าง AI Agent สำหรับงาน Observability ถือเป็นก้าวสำคัญที่เปลี่ยนจากการเปิด Dashboard หาข้อผิดพลาดแบบเดิม มาเป็นการสนทนากับระบบโดยตรง อย่างไรก็ตาม ความท้าทายหลักคือการป้องกันไม่ให้ AI มโนคำตอบขึ้นมาเอง การบังคับให้ทุกลิงก์ชี้ตรงไปยัง Trace ID ของระบบจริงจึงเป็นแนวทางสำคัญที่ช่วยสร้างความน่าเชื่อถือในสภาพแวดล้อมโปรดักชันจริง

ระบบเดโมที่ใช้คือ HotROD ซึ่งเป็นแอปพลิเคชันกระจายรถรับส่งหลายบริการที่รันอยู่ภายใต้โหลด HTTP จริงอย่างต่อเนื่อง ปัญหาระบบช้าและข้อผิดพลาดที่เกิดขึ้นจึงเป็นเรื่องจริง เช่น คำสั่ง MySQL SELECT ที่ใช้เวลาเกินกว่าหนึ่งวินาทีภายใต้ภาวะแย่งชิงทรัพยากร และปัญหา Redis timeout เป็นต้น

ไม่อยากพลาดข่าวใหม่?

สมัครรับสรุปข่าวสารใหม่ทางอีเมล ไม่บ่อยจนรำคาญ

โฆษณา

18.5%อัตราความผิดพลาดที่เอเจนต์ตรวจวัดได้
10%เกณฑ์การแจ้งเตือนเริ่มต้น

ในส่วนของการแจ้งเตือนเชิงรุก (Proactive alerts) เมื่อทราฟฟิกจริงดันอัตราความผิดพลาดเกินเกณฑ์ ระบบประเมินของ SigNoz จะส่งเว็บฮุกมายังแอป เอเจนต์จะทำการตรวจสอบด้วยตัวเองทันทีก่อนที่ใครจะเปิดแดชบอร์ด โดยมันวัดอัตราความผิดพลาดได้ 18.5% เทียบกับเกณฑ์ 10% ของการแจ้งเตือน พร้อมทั้งตรวจสอบข้อกล่าวหานั้นเทียบกับ raw spans ดั้งเดิม

เมื่อใกล้ถึงวันกำหนดส่งงาน ผู้พัฒนาประสบปัญหาโควตา API แบบเสียเงินหมดเกลียว จึงต้องกรองแคตตาล็อกของ OpenRouter เพื่อหาโมเดลฟรีที่รองรับการเรียกใช้เครื่องมือ (Tool-calling) อย่างแท้จริง และสลับไปใช้โมเดลฟรีขนาด 550B ซึ่งทำการสืบสวนได้ถูกต้องแต่ชอบอ้างอิง Trace ID เป็นข้อความธรรมดา จึงต้องทำระบบแบ็คฟิลด์เพื่อดึง Trace ID เหล่านั้นมาแสดงผลเป็นการ์ดหลักฐานที่คลิกได้

ที่มา: Dev.to

ความคิดเห็น

แสดงความคิดเห็น
0/2000

พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้