Workers Tracing เพิ่ม spanContext, setStatus และ updateName เชื่อม Log กับ Trace ได้ชัดขึ้น

Cloudflare ประกาศเมื่อ 26 ตุลาคม 2026 ว่า custom spans ของ Workers รองรับเพิ่มอีกสามเมธอดจาก OpenTelemetry span API ได้แก่ spanContext(), setStatus() และ updateName() ช่วยเชื่อม request กับ trace ระบุผลของงาน และตั้งชื่อ span ให้ตรง route ที่ทราบหลังเริ่มคำขอได้ ข่าวนี้มีประโยชน์กับทีมที่ต้องไล่เหตุขัดข้องข้าม log และระบบ tracing โดยไม่ต้องเดาจากเวลาเพียงอย่างเดียว

Trace ID ใช้เชื่อมหลักฐานของคำขอเดียวกัน

spanContext() คืน traceId, spanId และ traceFlags โดย ID ตรงกับ Workers Observability และ trace ที่ส่งออก ทีมสามารถบันทึก ID เพื่อค้นเหตุการณ์ของคำขอเดียวกันต่อได้ แต่ ID ไม่ใช่สิทธิ์เข้าถึงข้อมูล ผู้ดูแลยังต้องควบคุมว่าใครค้น log หรือ trace ได้ และผลค้นมีข้อมูลใดเปิดเผยอยู่

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

สถานะ Span กับ HTTP Status มีหน้าที่ต่างกัน

setStatus() รองรับ unset, ok และ error พร้อมข้อความประกอบ error สถานะนี้อยู่ใน trace ที่ส่งออกไปปลายทาง OpenTelemetry แต่ประกาศระบุว่า Workers Observability dashboard ยังไม่แสดง ทีมจึงควรตรวจข้อมูลที่ปลายทางส่งออก ไม่ควรสรุปว่าเมธอดไม่ทำงานเพราะยังไม่เห็นในหน้าจอ Workers

ในแอปจริงต้องกำหนดความหมายของสถานะให้สอดคล้องกับงาน เช่น HTTP 200 อาจเป็นคำตอบที่แจ้งว่าธุรกรรมถูกปฏิเสธตามกฎธุรกิจ ซึ่งไม่จำเป็นต้องเป็นความผิดพลาดของโครงสร้างพื้นฐาน ในทางกลับกัน งานภายในอาจล้มและ fallback ได้จนผู้ใช้ยังได้รับ response สำเร็จ การตั้งทุก span ตาม HTTP status ของคำขอสุดท้ายเพียงค่าเดียวอาจซ่อนเหตุที่ต้องแก้

ตั้งชื่อ Route ให้รวมกลุ่มได้โดยไม่ใส่ข้อมูลผู้ใช้

updateName() เปลี่ยนชื่อ span หลังเริ่มได้ รวมถึง root span ที่อ่านผ่าน tracing.getActiveSpan() เมื่อ router จับคู่เส้นทางแล้ว ทีมจึงสามารถใช้ชื่อที่สื่อถึงงานได้มากกว่าชื่อเริ่มต้นทั่วไป ควรใช้รูปแบบ route เช่น /orders/:id แทน URL ที่มีเลขคำสั่งซื้อจริง เพื่อไม่ให้เกิดชื่อจำนวนมากและข้อมูลธุรกิจหลุดเข้า metadata

การเลือกชื่อควรตกลงร่วมกันก่อนเพิ่ม instrumentation ทั้งโครงการ หากแต่ละทีมใช้รูปแบบต่างกัน งานที่เหมือนกันอาจถูกแยกเป็นหลายชื่อจนกรองข้อมูลยาก ส่วนข้อความ error ควรสั้นและอธิบายชนิดปัญหา โดยเก็บรายละเอียดที่จำเป็นในพื้นที่ที่มีการควบคุมการเข้าถึงเหมาะสม

ทดสอบตั้งแต่การสร้างจนถึงการส่งออก

เลือก endpoint ทดลองที่มีทั้งกรณีสำเร็จและข้อผิดพลาดที่จำลองได้ ตรวจว่า span จบครบแม้ handler โยน exception และมี Trace ID ที่ใช้ค้นในปลายทางได้จริง หากโค้ดมีหลายทางออก ให้ตรวจทุกทางเพื่อไม่ให้ span ค้างหรือข้อมูลขาดส่วนที่สำคัญ

จากนั้นตรวจชื่อและสถานะที่ปลายทาง OpenTelemetry ใช้สร้างมุมมองหรือ alert ให้ตรงกับนิยามของทีม การเพิ่มเมธอดใน runtime ยังไม่ยืนยันว่า exporter, pipeline และ dashboard ภายในตีความข้อมูลตรงกันทั้งหมด ควรเก็บ trace ตัวอย่างที่ไม่มีข้อมูลลับไว้เป็นหลักฐานการทดสอบ

เพิ่มข้อมูลเท่าที่ช่วยแก้ปัญหาได้จริง

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

หลังนำไปใช้ ควรทบทวนตัวอย่าง incident ว่าค้นจากรหัสอ้างอิงไปถึงต้นเหตุได้หรือไม่ พร้อมติดตามค่าใช้จ่ายและปริมาณข้อมูลในระบบส่งออกตามการตั้งค่าจริง ประกาศนี้ไม่ได้ยืนยันว่าการเก็บ trace ทุกระดับไม่มีต้นทุนหรือใช้แทน log และ metric อื่นได้ทั้งหมด

แหล่งต้นทาง: Workers tracing — spanContext(), setStatus(), and updateName() APIs ประกาศวันที่ 26 ตุลาคม 2026