RUM กับ Context ของผู้ใช้จริง

ไอเดียหลักในหนึ่งประโยค

RUM เก็บสิ่งที่ผู้ใช้จริงทำใน browser หรือแอปเป็น structured event และเมื่อ RUM propagate trace context เข้าไปใน backend call ที่ action นั้น trigger ก็ขยาย correlation ออกไปอีกหนึ่ง hop เลยจาก backend trace ไปถึงตัวคนที่เป็นต้นเหตุ

RUM เก็บอะไรบ้างจริง ๆ

Real User Monitoring (RUM) รันเป็น SDK อยู่ใน browser หรือแอปมือถือเอง ไม่ได้รันบน server ของเรา ตอนผู้ใช้จริง interact กับหน้าหรือแอป SDK จะปล่อย structured event type สั้น ๆ ไม่กี่แบบ

session — การเข้ามาเยี่ยมหนึ่งครั้ง ตั้งแต่ต้นจนจบ
view — หน้า (หรือ screen บนมือถือ) ที่ผู้ใช้ไปถึง
action — คลิก, แตะ, submit form
error — JS exception หรือโหลด resource ไม่สำเร็จ ที่ถูกจับฝั่ง client

นี่คือมุมมองที่ต่างจาก synthetic monitoring (browser ที่รัน script แกล้งเป็นผู้ใช้ตามตารางเวลา พูดถึงใน module อื่นของคอร์สนี้) RUM คือ browser จริงของผู้ใช้จริง เกิดขึ้นตามเวลาจริง สะท้อนสภาพ network จริง อุปกรณ์จริง และเส้นทางจริงที่ผู้ใช้เดินผ่าน product — ไม่ใช่เส้นทางในอุดมคติของ script ตัวเดียว

จากคลิกหนึ่งครั้งไปถึง backend trace

ลำพัง RUM action หรือ view คือข้อมูลฝั่ง frontend เท่านั้น — บอกได้ว่าผู้ใช้คลิก “Pay now” แต่ไม่บอกว่าเกิดอะไรขึ้นบน server หลังจากนั้น payoff ของการ correlate คือ พอตั้งค่า RUM SDK ให้ trace URL ฝั่ง backend ชุดหนึ่งไว้ จะแปะ trace context header แบบเดียวกับที่ backend tracer มองหา ลงไปใน XHR/fetch call ที่ส่งออกไป ทำให้ span ของ backend service ที่ถูกสร้างขึ้น ลิงก์กลับไปหา RUM view/action ตัวนั้นได้พอดี

window.DD_RUM.init({
  applicationId: '<RUM_APP_ID>',
  clientToken: '<RUM_CLIENT_TOKEN>',
  service: 'checkout-web',
  allowedTracingUrls: [
    (url) => url.startsWith('https://api.example.com')
  ]
});

allowedTracingUrls คือ allowlist ที่บอก RUM SDK ว่า backend call ไหนปลอดภัยและควรได้รับ trace header ที่ inject เข้าไป — เฉพาะ call ไปหา backend ของเราเอง ไม่ใช่ third-party service

request เดียว traced ยาวไปถึงตัวคน

backend trace อย่างเดียวตอบได้แค่ “span ไหน จาก service ไหนบ้าง ที่จัดการ request นี้” — นั่นคือเรื่องทั้งหมดที่ module APM เล่าไว้ RUM ขยายไอเดีย trace_id เดียวกันนี้ออกไปอีกหนึ่ง hop เลยขอบ infrastructure ของเราออกไป identifier ตัวเดียวกันที่ผูก span เข้าด้วยกันข้าม service ก็ผูกกลับไปหา RUM view/session ได้ด้วย ตอบคำถามว่า “ผู้ใช้จริงคนไหน อยู่หน้าไหน คลิกอะไร ถึงทำให้ trace นี้เกิดขึ้นมาตั้งแต่แรก” บทนี้ตั้งใจให้เบา ๆ — RUM เป็นหัวข้อใหญ่พอจะเป็นคอร์สแยกได้เลย — แต่ไอเดีย correlation ก็คือไอเดียเดียวกับที่ module นี้สร้างมาตลอด นั่นคือ identifier ที่ใช้ร่วมกัน แทนการเดาเอาเอง

flowchart LR
  U[Real user in browser] --> Act["RUM action: click 'Pay now'"]
  Act --> View[RUM view/session]
  Act --> Req["Traced fetch/XHR call\n(trace context injected)"]
  Req --> Span[Backend service span]
  Span --> Trace[APM distributed trace]
  View -.linked to.-> Trace

From a click to a distributed trace