Microsoft’s Foundry team ได้เพิ่มการทำ tracing ที่ใช้พื้นฐานจาก OpenTelemetry เข้ากับ agent framework ของตน ซึ่งช่วยให้นักพัฒนาสามารถมองเห็นการทำงานแบบ end-to-end ผ่าน agent ต่างๆ ที่ขับเคลื่อนด้วย LLM ที่มีความหลากหลาย (heterogeneous)

ทำไมระบบ multi-agent ถึงต้องการมากกว่าแค่ไฟล์ log

การซ้อมรับมือเหตุการณ์ (incident-response drill) ที่ขับเคลื่อนด้วย AI โดยทั่วไปจะใช้ commander agent เพื่อควบคุมดูแล specialist agents หลายตัว เช่น ตัวหนึ่งทำหน้าที่วิเคราะห์ logs, อีกตัวตรวจจับความผิดปกติของ metric, ตัวที่สามจับคู่ symptoms เข้ากับ runbooks และ router จะเลือก language model ที่ดีที่สุดสำหรับแต่ละ sub-task โดย specialist แต่ละตัวอาจเรียกใช้ model ที่แตกต่างกัน เช่น variant ของ “gpt-5-mini” และเรียกใช้เครื่องมือ (tools) ของตนเอง เมื่อเกิดข้อผิดพลาด วิศวกรจะต้องจ้องมอง logs ที่แยกส่วนกัน ซึ่งแสดงให้เห็นว่าแต่ละส่วนประกอบทำอะไรไปบ้าง แต่ไม่เห็นภาพรวมว่าชิ้นส่วนต่างๆ ทำงานร่วมกันอย่างไร

หากไม่มี trace ที่เป็นหนึ่งเดียว สาเหตุที่แท้จริง (root cause) มักจะซ่อนอยู่ระหว่างการส่งต่อข้อมูล (hand-off) ระหว่าง agent ตัวอย่างเช่น commander อาจส่งคำขอที่ log-reader จัดการได้อย่างถูกต้อง แต่ metric specialist กลับตีความข้อมูลผิดพลาดและแนะนำ runbook ที่ไม่ถูกต้อง การไล่ตรวจสอบ (debugging) สายโซ่นี้ด้วยมือต้องใช้เวลาและเสี่ยงต่อความผิดพลาด

OpenTelemetry เชื่อมโยง workflow เข้าด้วยกันได้อย่างไร

OpenTelemetry กำหนดแนวคิดหลักสองประการคือ traces และ spans โดย trace คือตัวระบุที่เป็นเอกลักษณ์ (unique identifier) ที่ติดตามคำขอตั้งแต่เริ่มต้นจนถึงการตอบกลับสุดท้าย ส่วน span จะบันทึกการทำงานเพียงหนึ่งรายการ เช่น การเรียกใช้ language model หรือการเรียกใช้ tool ภายใน trace นั้นๆ

เมื่อ agent ได้รับคำขอ มันจะดึง Trace ID ที่ส่งมาพร้อมกับ metadata ของคำขอ และสร้าง child span ที่สืบทอด ID เดียวกันนั้น โดย child span จะบันทึกเวลาเริ่มต้น, ระยะเวลา (duration), attributes (เช่น ชื่อ model, tool ที่ใช้) และข้อผิดพลาดใดๆ กระบวนการนี้จะเกิดขึ้นซ้ำกับทุกๆ downstream agent จนเกิดเป็นโครงสร้างแบบต้นไม้ (tree) ที่สะท้อนถึงลำดับขั้นตอนทางตรรกะ (logical flow) ของงานทั้งหมด

OpenTelemetry ยังรองรับ Baggage ซึ่งเป็นตัวพาข้อมูล (carrier) น้ำหนักเบาสำหรับคู่ key-value ที่กำหนดเอง การแนบ “drill-id” หรือบริบททางธุรกิจอื่นๆ เข้ากับ baggage ที่จุดเริ่มต้นของ trace จะทำให้ทุกๆ downstream span ได้รับ identifier นั้นโดยอัตโน จากนั้น span processor จะเปลี่ยน baggage ให้กลายเป็น attributes ปกติ ซึ่งช่วยให้การ query span ทั้งหมดที่เกี่ยวข้องกับการซ้อมรับมือเหตุการณ์ (incident drill) นั้นๆ ทำได้ง่ายขึ้น

หน้าตาของ tracing surface แบบใหม่เป็นอย่างไร

เมื่อมีการติดตั้ง instrumentation แล้ว Azure Monitor (หรือ backend ใดๆ ที่รองรับ OpenTelemetry) จะแสดงลำดับชั้นในรูปแบบภาพ (visual hierarchy) ดังนี้:

  • Agent name / ID – แสดงว่าส่วนประกอบใดเป็นผู้ดำเนินการ
  • Tool usage – บันทึกว่ามีการเรียกใช้ service หรือ function ภายนอกใด
  • Model version – บันทึก LLM ที่ใช้จริง ซึ่งมีประโยชน์ในการติดตามการถดถอยของประสิทธิภาพ (regressions) หลังจากการอัปเกรด model
  • Token consumption – บันทึกจำนวน token ที่ส่งไปยังและรับมาจาก model ช่วยให้ทีมสามารถจัดการต้นทุนได้
  • Latency / duration – ระบุจุดที่เกิดคอขวด (bottlenecks) ไม่ว่าจะเป็นในการประมวลผลของ model (inference) หรือในส่วนของ tool I/O

ในตัวอย่างการซ้อมรับมือเหตุการณ์ root span ของ commander จะสร้าง child spans สำหรับ specialist แต่ละตัว และ specialist แต่ละตัวก็จะสร้าง child spans ต่อไปสำหรับการเรียกใช้ model ของตน การคลิกที่ node ใดๆ จะแสดงชุด attributes ทั้งหมด ทำให้นักวิศวกรเห็นรายละเอียดของการทำงานแต่ละขั้นตอนได้ทันที

ความสำคัญต่อการดำเนินงานที่เน้น AI เป็นศูนย์กลาง

  • ความเร็วในการวิเคราะห์สาเหตุที่แท้จริง (root-cause analysis) – ทีมสามารถไล่ตามความล้มเหลวกลับไปยัง span ที่เกิดข้อผิดพลาดได้อย่างแม่นยำ ช่วยลดระยะเวลาเฉลี่ยในการแก้ไขปัญหา (mean time to resolution)
  • การมองเห็นต้นทุน (Cost visibility) – จำนวน token จะแสดงควบคู่ไปกับ latency ช่วยให้ฝ่ายการเงินตรวจพบการใช้งานที่สูงผิดปกติก่อนที่ค่าใช้จ่าย cloud จะพุ่งสูงขึ้น
  • การปรับแต่งประสิทธิภาพ (Performance tuning) – span ที่มี latency สูงในระหว่าง agent จะชี้ให้เห็นว่าการทำ caching, การเลือก model หรือการออกแบบ tool ใหม่จะช่วยเพิ่ม throughput ได้อย่างไร

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

โปรเจกต์ที่สร้างบน LangChain, OpenAI SDK หรือ orchestration layers อื่นๆ สามารถนำ semantic conventions แบบเดียวกันมาใช้สำหรับ GenAI ซึ่งเป็นการปูทางไปสู่การทำ trace ที่ไหลผ่านผู้ให้บริการ cloud และการติดตั้งแบบ on-premise ได้

องค์กรต่างๆ เพียงแค่เปิดใช้งาน OpenTelemetry SDK ใน agent ของตน และส่งข้อมูลไปยัง Azure Monitor หรือ open-source collector

บทสรุป

OpenTelemetry มอบ "กาว" ที่ขาดหายไปให้กับระบบ AI แบบ multi-agent ซึ่งเปลี่ยนเศษเสี้ยวของ logs ให้กลายเป็นเรื่องราวที่ต่อเนื่องและเข้าใจง่าย การส่งต่อ Trace ID เพียงหนึ่งเดียวผ่าน LLM ที่หลากหลาย, routers และการเรียกใช้ tool ช่วยให้นักพัฒนาสามารถระบุความล้มเหลว, ตรวจสอบต้นทุน และปรับแต่งประสิทธิภาพได้ โดยไม่ต้องสร้างโครงสร้างพื้นฐานสำหรับการทำ tracing ขึ้นมาใหม่