จากการตรวจสอบฐานโค้ด (codebase) สามแห่งพบว่า เพียงแค่การติดตั้ง OpenTelemetry (OTel) นั้นไม่เพียงพอที่จะทำให้วงจรการตอบกลับ (feedback loop) สำหรับ AI-assisted coding agents สมบูรณ์ หากไม่มีวงจรที่ใช้งานได้จริง ข้อมูล telemetry ก็ไม่สามารถช่วยให้ agent ตัดสินใจได้ว่าควรเปลี่ยนอะไร และนักพัฒนาจะเสียเวลาไปกับการเพิ่มเครื่องมือที่ไม่เคยสื่อสารกับโมเดลเลย
ทำไมแนวคิดแบบ “observability-first” ถึงยังไม่เพียงพอ
หลายทีมมองว่า observability เป็นเพียงแค่สิ่งที่ต้องทำตามรายการ (checkbox): แค่ใส่ tracing library เข้าไป เปิดใช้งาน dashboard แล้วก็ถือว่าเสร็จสิ้น แต่ในความเป็นจริง มันคือบันไดสามขั้น:
- มีกลไก observability อยู่จริง
- ระบบสามารถสร้าง telemetry ออกมาได้จริง
- AI agent สามารถนำ telemetry นั้นไปใช้ในการตัดสินใจได้
โปรเจกต์ส่วนใหญ่มักจะติดขัดอยู่ที่ขั้นที่ 1 middleware ที่ถูกทำ instrumentation ไว้อย่างสมบูรณ์แบบจะไม่มีประโยชน์เลยหากแอปพลิเคชันไม่เคยเรียกใช้งานมัน ทำให้ไม่มีข้อมูลใดๆ ถูกสร้างขึ้น AI agent ที่สแกนซอร์สโค้ดจะเห็นโค้ดการทำ tracing และทึกทักเอาเองว่าระบบนั้นสามารถสังเกตการณ์ได้ (observable) แต่กลับพบเพียงภาพการทำงาน (runtime) ที่ว่างเปล่า ช่องว่างระหว่าง “การมีเครื่องมือ” กับ “การมีวงจร (loop)” คือจุดที่ความพยายามทั้งหมดสูญเปล่า
เงื่อนไข 6 ประการสำหรับข้อมูลที่นำไปใช้งานได้
เพื่อเปลี่ยน raw traces ให้กลายเป็นข้อมูลนำเข้า (input) ที่ใช้งานได้จริงสำหรับ AI coding agent ข้อมูล telemetry จะต้องตอบโจทย์เงื่อนไขเชิงปฏิบัติ 6 ประการ ดังนี้:
- Standardization. ใช้ชื่อและประเภทของ attribute ที่สอดคล้องกัน เพื่อให้ agent สามารถ parse ข้อมูลได้โดยไม่ต้องทำ mapping เฉพาะกิจ
- Propagation. ส่งต่อ trace identifier ชุดเดียวผ่านทุกบริการและข้ามขอบเขตของภาษา เพื่อให้ agent สามารถสร้างภาพการทำงานแบบ end-to-end ขึ้นมาใหม่ได้
- Discoverability. เปิดเผยข้อมูลผ่าน code-level hooks หรือคำสั่ง CLI ง่ายๆ เพื่อให้โมเดลสามารถค้นหาข้อมูลได้โดยไม่ต้องขุดค้นด้วยตัวเอง
- Controllability. อนุญาตให้ agent จำกัดการ query ตามช่วงเวลาหรือจำนวนผลลัพธ์ เพื่อป้องกันไม่ให้มันถูกถาโถมด้วย spans ที่ไม่เกี่ยวข้อง
- Accessibility. ทำให้ข้อมูลสามารถอ่านได้ใน session เดียวกันกับที่ agent ทำงาน โดยควรจะอ่านได้จากไฟล์ในเครื่อง (local file) หรือ stdout stream
- Comparability. มีวิธีดึง snapshot แบบ “ก่อน” และ “หลัง” ภายใต้เงื่อนไขที่เหมือนกัน เพื่อให้ agent สามารถวัดผลกระทบจากการเปลี่ยนแปลงได้
เมื่อขาดเสาหลักข้อใดข้อหนึ่งไป วงจรการตอบกลับจะขาดตอน และ AI agent จะกลับไปใช้วิธีการคาดเดาแทน
Local pipelines ดีกว่า cloud สำหรับการพัฒนา
สภาพแวดล้อมในระดับ production จะพึ่งพา cloud-based telemetry collectors, บริการ aggregation และ dashboard ซึ่ง pipeline เหล่านี้จำเป็นสำหรับการตรวจสอบในสเกลใหญ่ แต่พวกมันสร้าง latency ที่วัดเป็นนาที AI agent ที่ต้องรอข้อมูลเป็นนาทีไม่สามารถมีส่วนร่วมในวงจรการพัฒนาที่ต้องการการตัดสินใจภายในไม่กี่วินาทีได้
ทางเลือกที่ใช้งานได้จริงคือ local telemetry pipeline:
- เขียน telemetry ลงในไฟล์ในเครื่องหรือ stdout. OTel รองรับ exporter ที่สามารถ dump ข้อมูล JSON หรือ plain-text spans ลงใน workspace ของนักพัฒนาได้โดยตรง
- เปิดเผยข้อมูลผ่านเครื่องมือที่เรียบง่าย. HTTP server ขนาดเล็ก, อินเทอร์เฟซการ query ผ่าน command-line หรือ SQL wrapper น้ำหนักเบา สามารถส่งต่อ traces ให้กับ agent ได้ตามต้องการ
- ให้ agent อ่าน raw output. รูปแบบ JSON หรือ Markdown นั้นง่ายต่อการที่ language models จะ parse และเปรียบเทียบภายใน session การแก้ไขเดียวกัน
การเริ่มต้นด้วยการทำ auto-instrumentation แบบครอบคลุมทั้งหมดมีแต่จะเพิ่ม noise ให้เลือกเส้นทางการทำงาน (execution path) ที่สำคัญเพียงเส้นทางเดียว เช่น routine การจัดการ request หรือขั้นตอนการ build แล้วทำ instrumentation แบบ end-to-end ให้ครบวงจร: Generate → Propagate → Store → Query → Compare เมื่อวงจรนั้นทำงานได้แล้ว จึงค่อยขยายขอบเขตออกไปทีละน้อย
สิ่งที่ทีมควรทำต่อไป
- ระบุ flow ที่มีค่าที่สุด. เลือกโค้ดส่วนที่การเปลี่ยนแปลงจะส่งผลกระทบต่อประสิทธิภาพหรือความถูกต้องที่วัดผลได้
- ทำ instrumentation flow นั้นด้วย OTel. ใช้ API เฉพาะของภาษานั้นๆ เพื่อสร้าง spans, แนบ standardized attributes และส่งต่อ trace context
- Export แบบ local. ตั้งค่า exporter ให้เขียน JSON lines ลงในไฟล์ในไดเรกทอรีของโปรเจกต์ หรือพิมพ์ออกทาง console
- จัดเตรียม query interface. สคริปต์เล็กๆ ที่กรองไฟล์ตาม trace ID และช่วงเวลา (time window) ก็เพียงพอที่จะให้ agent ดึงข้อมูลส่วนที่ต้องการออกมาได้
- ป้อนข้อมูลให้ AI agent. ส่ง prompt ให้โมเดลด้วย trace แบบ “ก่อน” (before), สั่งให้ทำการเปลี่ยนแปลง, จากนั้นรันโค้ดที่อัปเดตแล้วและเก็บ trace แบบ “หลัง” (after) เพื่อนำมาเปรียบเทียบ
- ทำซ้ำ (Iterate). ทุกๆ วงจรที่สำเร็จจะช่วยยืนยันเงื่อนไขทั้ง 6 ประการ และขยายขอบเขตของส่วนที่สามารถสังเกตการณ์ได้ (observable surface area)
บทสรุป
OpenTelemetry มอบภาษาที่เป็นมาตรฐานเดียวกันสำหรับการทำ tracing ให้กับโค้ดของคุณ แต่ภาษานี้จะมีประโยชน์ก็ต่อเมื่อข้อมูลเป็นไปตามเงื่อนไขที่ชัดเจน 6 ประการ และสามารถเข้าถึงได้ในเครื่อง (locally) ภายในวงจรการตอบกลับที่รวดเร็ว (tight feedback loop) เริ่มจากจุดเล็กๆ โดยการทำ instrumentation กับเพียงหนึ่ง flow จากนั้นส่งออกข้อมูลไปยังไฟล์ และปล่อยให้ AI agent อ่านและเปรียบเทียบ trace เหล่านั้นได้โดยตรง นั่นคือเส้นทางที่ใช้งานได้จริง จากจุดที่ “ฉันมี observability” ไปสู่ “ผู้ช่วย AI ของฉันสามารถปรับปรุงโค้ดของฉันได้จริงๆ”