เอเจนต์ AI SRE แบบอัตโนมัติสองตัวที่ทำงานบน SigNoz’s Managed Cloud Platform (MCP) สามารถระบุสาเหตุที่แท้จริง (root-cause) โพสต์สรุปไปยัง Slack และเสร็จสิ้นการตรวจสอบทั้งหมดได้ภายในเวลาไม่ถึง 4 วินาที โดยมีค่าใช้จ่ายเพียง 0.0013 ดอลลาร์ต่อเหตุการณ์ ผลลัพธ์ที่ได้คือการเปลี่ยนจากการสอบถามผ่านแชทบอทแบบตั้งรับ (reactive) ไปสู่แรงงานด้าน observability แบบขับเคลื่อนด้วยตัวเอง (self-driving observability workforce) ที่ช่วยลดค่าใช้จ่ายในการตรวจสอบ พร้อมทั้งเปิดเผยเมทริกซ์ที่สูญเปล่า

ทำไมเรื่องนี้ถึงสำคัญ

การสาธิต AI-observability แบบดั้งเดิมยังคงต้องใช้มนุษย์ในการพิมพ์คำถามเกี่ยวกับ trace หรือ log แต่แนวทางใหม่นี้ตัดขั้นตอนนั้นออกไป: เมื่อมีการแจ้งเตือน (alert) เกิดขึ้น ระบบจะรัน SRE playbook ที่ผ่านการพิสูจน์แล้วโดยอัตโนมัติและส่งคำตอบให้ทันที

แฮกกาธอนที่ให้กำเนิดเอเจนต์เหล่านี้

เอเจนต์เหล่านี้เกิดขึ้นจากงาน WeMakeDevs × Agents of SigNoz hackathon ภายใต้ชื่อโปรเจกต์ MIB (Men in Backend) แทนที่จะเป็นแชทบอทเพื่อการสนทนา ทีมงานได้สร้าง “แรงงานด้าน observability แบบอัตโนมัติ” ที่ประกอบด้วยเอเจนต์สองตัว:

  • Agent J – The Incident Responder – คอยฟังการแจ้งเตือน จากนั้นจะทำตาม playbook 5 ขั้นตอน: ยืนยันการแจ้งเตือน, ระบุ trace ที่เป็นปัญหา, เจาะลึก log ที่เกี่ยวข้อง, คำนวณส่วนต่าง (delta), และโพสต์การ์ดสรุปสาเหตุที่แท้จริงไปยัง Slack โดยลำดับขั้นนี้ใช้เวลาเฉลี่ย 3.7 วินาที
  • Agent K – The Auditor – ทำการตรวจสอบการใช้งานเมทริกซ์ตามกำหนดเวลา, ระบุเมทริกซ์ที่ทำให้เกิดค่าใช้จ่ายแต่ไม่มีการใช้งาน, และร่างการเปลี่ยนแปลง dashboard เพื่อให้มนุษย์อนุมัติ

ในระหว่างการแข่งขัน Agent K รายงานว่า 38% ของเมทริกซ์ยอดนิยมไม่เคยถูกอ่านเลย ซึ่งเผยให้เห็นความสูญเปล่าที่ซ่อนอยู่ใน observability stack

ระบบทำงานอย่างไร

Deterministic playbooks ไม่ใช่การวนลูปแบบปลายเปิด

เอเจนต์เหล่านี้ทำตาม playbook ที่กำหนดไว้แน่นอน (deterministic) แทนที่จะใช้การใช้เหตุผลแบบ "agentic" ที่เป็นอิสระ การรันแต่ละครั้งจะดำเนินการตาม workflow ของ SRE ที่ทราบกันดี คือ—ยืนยัน, trace, log, delta—ซึ่งให้ผลลัพธ์ที่สม่ำเสมอและหลีกเลี่ยงความไม่แน่นอนของข้อความจาก LLM ที่ไม่มีขอบเขต

สามเลเยอร์ของ observability

  1. Application layer – แอปพลิเคชันที่ถูกตรวจสอบจะส่ง stream ของ trace, log และ metrics ไปยัง SigNoz
  2. Agent layer – เอเจนต์แต่ละตัวจะส่ง semantic spans ที่สร้างโดย GenAI ของตัวเองกลับไปยัง SigNoz ทำให้ตัวเอเจนต์เองสามารถถูกตรวจสอบได้ (observable)
  3. MCP telemetry layer – เซิร์ฟเวอร์ MCP จะบันทึก telemetry ของการเรียกใช้เครื่องมือ (tool-call) ทำให้เกิดวงจรการตอบกลับ (feedback loop) ที่ SigNoz คอยเฝ้าดูเอเจนต์ที่กำลังเฝ้าดู SigNoz อีกทีหนึ่ง

เอนจินการคาดการณ์เพื่อข้อมูลเชิงลึกก่อนการแจ้งเตือน

กระบวนการเบื้องหลังจะให้คะแนนแนวโน้ม (trends) ทุกๆ 25 วินาที เมื่อความหน่วง (latency) หรืออัตราข้อผิดพลาด (error rates) พุ่งสูงขึ้น เอนจินจะคาดการณ์เหตุการณ์ก่อนที่ค่าจะถึงเกณฑ์การแจ้งเตือน ช่วยให้เอเจนต์สามารถเริ่มทำงานล่วงหน้าได้

ผลลัพธ์ที่จับต้องได้

เมทริกซ์ ผลลัพธ์
ค่าใช้จ่ายในการตรวจสอบต่อครั้ง $0.0013
เวลาที่ใช้ในการวิเคราะห์สาเหตุที่แท้จริงทั้งหมด < 4 วินาที
เมทริกซ์ยอดนิยมที่ไม่ได้ใช้งานถูกระบุพบ 38 %

บทเรียนที่ได้รับจากหน้างาน

  • Manual instrumentation สำหรับ GenAI spans – การเพิ่ม instrumentation อย่างชัดเจนเพื่อจับผลลัพธ์เชิงความหมาย (semantic output) ของ AI ช่วยให้ข้อมูลมีความแม่นยำและสามารถค้นหาได้
  • ปิดโหมด “thinking” – LLM ที่พยายามจะสนทนาบ่อยครั้งมักจะทำให้ JSON ถูกตัดตอน (truncate) การปิดโหมดเหล่านี้จะบังคับให้ได้ผลลัพธ์ที่กระชับและเครื่องสามารถอ่านได้ (machine-readable)
  • Patch ด้วย RFC 6902 – การใช้ JSON-Patch (RFC 6902) กับแพลตฟอร์ม Foundry ช่วยให้ทีมสามารถแก้ไขการตรวจสอบสถานะคอนเทนเนอร์ (container health-checks) และพารามิเตอร์ความหน่วงได้โดยไม่ต้อง deploy บริการใหม่ทั้งหมด

ใครจะได้ประโยชน์ และใครที่อาจจะระแวง

องค์กรที่จ่ายค่าบริการแพลตฟอร์ม observability อยู่แล้วสามารถเห็นการประหยัดได้ทันที ทั้งการลดเวลาของนักวิเคราะห์และการกำจัดการเก็บข้อมูลเมทริกซ์ที่ไม่ได้ใช้งาน

สิ่งที่ควรจับตามองต่อไป

โค้ด open-source สำหรับ MIB อยู่บน GitHub และมีวิดีโอสาธิตที่แสดงขั้นตอนการทำงานเมื่อเกิดเหตุการณ์หนึ่งๆ อย่างครบถ้วน

บทสรุป

การฝังเอเจนต์ AI เฉพาะทางสองตัวลงใน MCP ของ SigNoz โดยตรง แสดงให้เห็นว่าการวิเคราะห์สาเหตุที่แท้จริงแบบอัตโนมัติสามารถทำได้อย่างรวดเร็วเป็นพิเศษและราคาถูกมาก แนวทางนี้เปลี่ยน observability จากเครื่องมือรายงานผลแบบตั้งรับ ให้กลายเป็นผู้มีส่วนร่วมเชิงรุกที่ดำเนินการทันทีที่เกิดเหตุการณ์ ช่วยประหยัดทั้งเวลา เงิน และลดความหงุดหงิดของมนุษย์ที่ต้องมานั่งไล่ดู log หลังจากเกิดปัญหาไปแล้ว