Distributed Tracing: การวิเคราะห์โฟลว์คำขอสำหรับแอปพลิเคชันยุคใหม่

ในสถาปัตยกรรมแอปพลิเคชันที่ซับซ้อนและเป็นแบบกระจายในปัจจุบัน การทำความเข้าใจโฟลว์ของคำขอ (request) ที่วิ่งผ่านบริการต่างๆ เป็นสิ่งสำคัญอย่างยิ่งเพื่อรับประกันประสิทธิภาพ ความน่าเชื่อถือ และการดีบักที่มีประสิทธิภาพ Distributed tracing ให้ข้อมูลเชิงลึกที่จำเป็นโดยการติดตามคำขอขณะที่มันเดินทางผ่านบริการต่างๆ ช่วยให้นักพัฒนาและทีมปฏิบัติการสามารถระบุจุดคอขวดของประสิทธิภาพ ระบุการพึ่งพากัน และแก้ไขปัญหาได้อย่างรวดเร็ว คู่มือนี้จะเจาะลึกแนวคิดของ distributed tracing ประโยชน์ของมัน กลยุทธ์การนำไปใช้ และกรณีการใช้งานจริง

Distributed Tracing คืออะไร?

Distributed tracing คือเทคนิคที่ใช้ในการตรวจสอบและโปรไฟล์คำขอเมื่อมันแพร่กระจายไปทั่วระบบแบบกระจาย (distributed system) มันให้มุมมองแบบองค์รวมของวงจรชีวิตของคำขอ โดยแสดงเส้นทางที่คำขอใช้ตั้งแต่จุดเริ่มต้นแรกจนถึงการตอบสนองสุดท้าย ซึ่งช่วยให้คุณสามารถระบุได้ว่าบริการใดบ้างที่เกี่ยวข้องในการประมวลผลคำขอหนึ่งๆ ความหน่วง (latency) ที่แต่ละบริการสร้างขึ้น และข้อผิดพลาดใดๆ ที่เกิดขึ้นระหว่างทาง

เครื่องมือตรวจสอบแบบดั้งเดิมมักจะไม่เพียงพอในสภาพแวดล้อมแบบกระจาย เพราะมันมุ่งเน้นไปที่บริการแต่ละตัวแบบแยกส่วน Distributed tracing ช่วยลดช่องว่างนี้โดยการให้มุมมองที่เป็นหนึ่งเดียวของทั้งระบบ ช่วยให้คุณสามารถเชื่อมโยงเหตุการณ์ต่างๆ ข้ามบริการและเข้าใจความสัมพันธ์ระหว่างกันได้

แนวคิดหลัก

• Span: Span หมายถึงหน่วยการทำงานเดียวภายใน trace โดยทั่วไปจะสอดคล้องกับการดำเนินการหรือการเรียกฟังก์ชันเฉพาะภายในบริการ Span จะมีข้อมูลเมตาดาต้า เช่น เวลาเริ่มต้นและสิ้นสุด ชื่อการดำเนินการ ชื่อบริการ และแท็ก (tags)
• Trace: Trace หมายถึงเส้นทางทั้งหมดของคำขอขณะที่มันเดินทางผ่านระบบแบบกระจาย มันประกอบด้วยโครงสร้างแบบต้นไม้ของ span โดยมี root span เป็นตัวแทนของจุดเริ่มต้นแรกของคำขอ
• Trace ID: ตัวระบุที่ไม่ซ้ำกันที่กำหนดให้กับ trace เพื่อให้สามารถเชื่อมโยง span ทั้งหมดที่อยู่ในคำขอเดียวกันได้
• Span ID: ตัวระบุที่ไม่ซ้ำกันที่กำหนดให้กับ span ภายใน trace
• Parent ID: Span ID ของ span แม่ ซึ่งสร้างความสัมพันธ์เชิงสาเหตุระหว่าง span ใน trace
• Context Propagation: กลไกที่ใช้ในการส่งผ่าน Trace ID, Span ID และข้อมูลเมตาดาต้าการติดตามอื่นๆ ระหว่างบริการต่างๆ ขณะที่คำขอแพร่กระจายไปในระบบ โดยทั่วไปจะเกี่ยวข้องกับการแทรก tracing context เข้าไปใน HTTP headers หรือโปรโตคอลการส่งข้อความอื่นๆ

ประโยชน์ของ Distributed Tracing

การนำ distributed tracing มาใช้ให้ประโยชน์หลักหลายประการสำหรับองค์กรที่ดำเนินงานระบบแบบกระจายที่ซับซ้อน:

• การตรวจสอบประสิทธิภาพที่ดีขึ้น: ระบุจุดคอขวดของประสิทธิภาพและปัญหาความหน่วงข้ามบริการ ช่วยให้สามารถวิเคราะห์สาเหตุของปัญหาและทำการปรับปรุงให้เหมาะสมได้รวดเร็วยิ่งขึ้น
• การดีบักที่ดียิ่งขึ้น: ได้รับความเข้าใจที่ครอบคลุมเกี่ยวกับโฟลว์ของคำขอ ทำให้ง่ายต่อการวินิจฉัยและแก้ไขข้อผิดพลาดที่ครอบคลุมหลายบริการ
• ลดเวลาเฉลี่ยในการแก้ไขปัญหา (MTTR): ระบุแหล่งที่มาของปัญหาได้อย่างรวดเร็ว ลดเวลาที่ระบบไม่ทำงาน (downtime) และปรับปรุงความน่าเชื่อถือโดยรวมของระบบ
• ความเข้าใจที่ดีขึ้นเกี่ยวกับการพึ่งพากัน: แสดงภาพความสัมพันธ์ระหว่างบริการต่างๆ เผยให้เห็นการพึ่งพาที่ซ่อนอยู่และจุดที่อาจเกิดความล้มเหลว
• การจัดสรรทรัพยากรที่เหมาะสมที่สุด: ระบุบริการที่ใช้งานน้อยเกินไปหรือมากเกินไป ช่วยให้สามารถจัดสรรทรัพยากรและวางแผนความจุได้อย่างมีประสิทธิภาพมากขึ้น
• ปรับปรุง Observability: ได้รับความเข้าใจที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับพฤติกรรมของระบบ ช่วยให้คุณสามารถระบุและแก้ไขปัญหาที่อาจเกิดขึ้นได้ในเชิงรุกก่อนที่จะส่งผลกระทบต่อผู้ใช้

การนำ Distributed Tracing ไปใช้งาน

การนำ distributed tracing ไปใช้งานเกี่ยวข้องกับหลายขั้นตอน รวมถึงการเลือก tracing backend, การติดตั้งเครื่องมือวัดผล (instrumenting) ในโค้ดของคุณ และการกำหนดค่า context propagation

1. การเลือก Tracing Backend

มี tracing backend แบบโอเพ่นซอร์สและเชิงพาณิชย์ให้เลือกใช้หลายตัว ซึ่งแต่ละตัวมีจุดแข็งและจุดอ่อนแตกต่างกันไป ตัวเลือกยอดนิยมบางส่วน ได้แก่:

• Jaeger: ระบบ tracing แบบโอเพ่นซอร์สที่พัฒนาโดย Uber เหมาะสำหรับสถาปัตยกรรมไมโครเซอร์วิสและมี UI บนเว็บที่ใช้งานง่ายสำหรับการแสดงภาพ trace
• Zipkin: ระบบ tracing แบบโอเพ่นซอร์สที่พัฒนาโดย Twitter เป็นที่รู้จักในด้านความสามารถในการขยายขนาด (scalability) และการรองรับ backend สำหรับจัดเก็บข้อมูลที่หลากหลาย
• OpenTelemetry: เฟรมเวิร์ก observability แบบโอเพ่นซอร์สที่ให้ API ที่เป็นกลางต่อผู้ขาย (vendor-neutral) สำหรับการติดตั้งเครื่องมือวัดผลในโค้ดของคุณและรวบรวมข้อมูล telemetry รองรับ tracing backend หลายตัว รวมถึง Jaeger, Zipkin และอื่นๆ OpenTelemetry กำลังจะกลายเป็นมาตรฐานของอุตสาหกรรม
• โซลูชันเชิงพาณิชย์: Datadog, New Relic, Dynatrace และแพลตฟอร์มการตรวจสอบเชิงพาณิชย์อื่นๆ ก็มีความสามารถด้าน distributed tracing เช่นกัน โซลูชันเหล่านี้มักจะมีคุณสมบัติเพิ่มเติม เช่น การรวบรวม로그 (log aggregation), การตรวจสอบเมตริก และการแจ้งเตือน

เมื่อเลือก tracing backend ให้พิจารณาปัจจัยต่างๆ เช่น ความสามารถในการขยายขนาด, ประสิทธิภาพ, ความง่ายในการใช้งาน, การผสานรวมกับโครงสร้างพื้นฐานที่มีอยู่ และค่าใช้จ่าย

2. การติดตั้งเครื่องมือวัดผลในโค้ดของคุณ (Instrumenting Your Code)

การติดตั้งเครื่องมือวัดผลในโค้ดของคุณเกี่ยวข้องกับการเพิ่มโค้ดเพื่อสร้าง span และส่งต่อ tracing context ซึ่งสามารถทำได้ด้วยตนเองโดยใช้ไลบรารี tracing หรือทำโดยอัตโนมัติโดยใช้ instrumentation agent การทำ Auto-instrumentation กำลังได้รับความนิยมมากขึ้นเรื่อยๆ เนื่องจากต้องการการเปลี่ยนแปลงโค้ดน้อยกว่าและบำรุงรักษาง่ายกว่า

Manual Instrumentation: วิธีนี้เกี่ยวข้องกับการใช้ไลบรารี tracing เพื่อสร้าง span ที่จุดเริ่มต้นและจุดสิ้นสุดของแต่ละการดำเนินการที่คุณต้องการติดตาม คุณยังต้องส่งต่อ tracing context ระหว่างบริการต่างๆ ด้วยตนเอง นี่คือตัวอย่างพื้นฐานโดยใช้ OpenTelemetry ใน Python:

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.sdk.trace.export import ConsoleSpanExporter

# กำหนดค่า tracer provider
tracer_provider = TracerProvider()
processor = BatchSpanProcessor(ConsoleSpanExporter())
tracer_provider.add_span_processor(processor)
trace.set_tracer_provider(tracer_provider)

# รับ tracer
tracer = trace.get_tracer(__name__)

# สร้าง span
with tracer.start_as_current_span("my_operation") as span:
 span.set_attribute("key", "value")
 # ดำเนินการ
 print("Performing my operation")

Automatic Instrumentation: ไลบรารี tracing หลายตัวมี agent ที่สามารถติดตั้งเครื่องมือวัดผลในโค้ดของคุณโดยอัตโนมัติโดยไม่ต้องเปลี่ยนแปลงโค้ดด้วยตนเอง Agent เหล่านี้มักใช้การจัดการ bytecode หรือเทคนิคอื่นๆ เพื่อแทรกโค้ด tracing เข้าไปในแอปพลิเคชันของคุณในขณะที่ทำงาน (runtime) นี่เป็นวิธีที่ประหยัดและรบกวนน้อยกว่ามากในการนำ tracing ไปใช้งาน

3. การกำหนดค่า Context Propagation

Context propagation คือกลไกที่ใช้ในการส่งผ่านข้อมูลเมตาดาต้าการติดตามระหว่างบริการต่างๆ วิธีที่พบบ่อยที่สุดคือการแทรก tracing context เข้าไปใน HTTP headers หรือโปรโตคอลการส่งข้อความอื่นๆ headers เฉพาะที่ใช้สำหรับ context propagation ขึ้นอยู่กับ tracing backend ที่คุณใช้ OpenTelemetry กำหนด headers มาตรฐาน (เช่น `traceparent`, `tracestate`) เพื่อส่งเสริมการทำงานร่วมกันระหว่างระบบ tracing ต่างๆ

ตัวอย่างเช่น เมื่อใช้ Jaeger คุณอาจแทรก header `uber-trace-id` เข้าไปในคำขอ HTTP บริการที่รับคำขอก็จะดึง Trace ID และ Span ID ออกจาก header และสร้าง child span การใช้ service mesh เช่น Istio หรือ Linkerd ก็สามารถจัดการ context propagation โดยอัตโนมัติได้เช่นกัน

4. การจัดเก็บและวิเคราะห์ข้อมูล

หลังจากรวบรวมข้อมูล trace แล้ว จะต้องนำไปจัดเก็บและวิเคราะห์ Tracing backend มักจะมีส่วนประกอบการจัดเก็บสำหรับเก็บข้อมูล trace และมี query interface สำหรับการดึงและวิเคราะห์ trace ตัวอย่างเช่น Jaeger สามารถเก็บข้อมูลใน Cassandra, Elasticsearch หรือในหน่วยความจำ Zipkin รองรับ Elasticsearch, MySQL และตัวเลือกการจัดเก็บอื่นๆ OpenTelemetry มี exporters ที่สามารถส่งข้อมูลไปยัง backend ต่างๆ ได้

เครื่องมือวิเคราะห์มักมีคุณสมบัติต่างๆ เช่น:

• การแสดงภาพ Trace: แสดง trace เป็นแผนภาพน้ำตก (waterfall chart) ซึ่งแสดงระยะเวลาของแต่ละ span และความสัมพันธ์ระหว่างกัน
• กราฟการพึ่งพากันของบริการ: แสดงภาพการพึ่งพากันระหว่างบริการต่างๆ โดยอิงจากข้อมูล trace
• การวิเคราะห์สาเหตุของปัญหา (Root Cause Analysis): ระบุสาเหตุที่แท้จริงของจุดคอขวดด้านประสิทธิภาพหรือข้อผิดพลาดโดยการวิเคราะห์ข้อมูล trace
• การแจ้งเตือน: กำหนดค่าการแจ้งเตือนโดยอิงจากข้อมูล trace เช่น เกณฑ์ความหน่วงหรืออัตราข้อผิดพลาด

กรณีการใช้งานจริง

Distributed tracing สามารถนำไปประยุกต์ใช้กับกรณีการใช้งานที่หลากหลายในสถาปัตยกรรมแอปพลิเคชันสมัยใหม่:

• สถาปัตยกรรมไมโครเซอร์วิส: ในสภาพแวดล้อมไมโครเซอร์วิส คำขอมักจะเดินทางผ่านบริการหลายตัว Distributed tracing ช่วยให้คุณเข้าใจโฟลว์ของคำขอระหว่างบริการและระบุจุดคอขวดด้านประสิทธิภาพ ตัวอย่างเช่น แอปพลิเคชันอีคอมเมิร์ซอาจใช้ distributed tracing เพื่อติดตามคำขอขณะที่มันไหลผ่านบริการสั่งซื้อ บริการชำระเงิน และบริการจัดส่ง
• แอปพลิเคชัน Cloud-Native: แอปพลิเคชัน Cloud-native มักจะถูกปรับใช้บนคอนเทนเนอร์และเครื่องเสมือนหลายเครื่อง Distributed tracing ช่วยให้คุณตรวจสอบประสิทธิภาพของแอปพลิเคชันเหล่านี้และระบุปัญหาที่เกี่ยวข้องกับเครือข่ายหรือการจัดสรรทรัพยากร
• ฟังก์ชัน Serverless: ฟังก์ชัน Serverless มีอายุการใช้งานสั้นและมักจะไม่มีสถานะ (stateless) Distributed tracing สามารถช่วยคุณติดตามการทำงานของฟังก์ชันเหล่านี้และระบุปัญหาด้านประสิทธิภาพหรือข้อผิดพลาด ลองนึกภาพแอปพลิเคชันประมวลผลภาพแบบ serverless; tracing จะเผยให้เห็นจุดคอขวดในขั้นตอนการประมวลผลต่างๆ
• แอปพลิเคชันมือถือ: Distributed tracing สามารถใช้เพื่อตรวจสอบประสิทธิภาพของแอปพลิเคชันมือถือและระบุปัญหาที่เกี่ยวข้องกับการเชื่อมต่อเครือข่ายหรือบริการ backend ข้อมูลจากอุปกรณ์มือถือสามารถเชื่อมโยงกับ trace ของ backend ทำให้ได้ภาพที่สมบูรณ์
• แอปพลิเคชันดั้งเดิม (Legacy): แม้แต่ในแอปพลิเคชันแบบ monolithic, distributed tracing ก็มีคุณค่าในการทำความเข้าใจเส้นทางโค้ดที่ซับซ้อนและระบุจุดคอขวดด้านประสิทธิภาพ สามารถเปิดใช้งาน tracing เฉพาะสำหรับธุรกรรมที่สำคัญได้

สถานการณ์ตัวอย่าง: แอปพลิเคชันอีคอมเมิร์ซ

พิจารณาแอปพลิเคชันอีคอมเมิร์ซที่สร้างขึ้นโดยใช้สถาปัตยกรรมไมโครเซอร์วิส แอปพลิเคชันประกอบด้วยบริการหลายอย่าง ได้แก่:

• Frontend Service: จัดการคำขอของผู้ใช้และแสดงผลส่วนติดต่อผู้ใช้
• Product Service: จัดการแคตตาล็อกสินค้าและดึงข้อมูลสินค้า
• Order Service: สร้างและจัดการคำสั่งซื้อของลูกค้า
• Payment Service: ประมวลผลการชำระเงินและจัดการธุรกรรม
• Shipping Service: จัดการการจัดส่งสินค้าตามคำสั่งซื้อ

เมื่อผู้ใช้วางคำสั่งซื้อ Frontend Service จะเรียก Order Service ซึ่งจะเรียก Product Service, Payment Service และ Shipping Service ต่อไป หากไม่มี distributed tracing การทำความเข้าใจโฟลว์ของคำขอและระบุจุดคอขวดด้านประสิทธิภาพในระบบที่ซับซ้อนนี้อาจเป็นเรื่องยาก

ด้วย distributed tracing คุณสามารถติดตามคำขอขณะที่มันเดินทางผ่านแต่ละบริการและเห็นภาพความหน่วงที่แต่ละบริการสร้างขึ้น ซึ่งช่วยให้คุณระบุได้ว่าบริการใดเป็นสาเหตุของคอขวดและดำเนินการแก้ไข ตัวอย่างเช่น คุณอาจพบว่า Payment Service ช้าเนื่องจากการสืบค้นฐานข้อมูล (database query) ที่ใช้เวลานานเกินไป จากนั้นคุณสามารถปรับปรุง query นั้นหรือเพิ่มการแคชเพื่อปรับปรุงประสิทธิภาพได้

แนวทางปฏิบัติที่ดีที่สุดสำหรับ Distributed Tracing

เพื่อให้ได้ประโยชน์สูงสุดจาก distributed tracing ให้ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดเหล่านี้:

• เริ่มต้นด้วยบริการที่สำคัญที่สุด: มุ่งเน้นไปที่การติดตั้งเครื่องมือวัดผลกับบริการที่สำคัญที่สุดต่อธุรกิจของคุณหรือที่ทราบกันว่ามีปัญหา
• ใช้แบบแผนการตั้งชื่อที่สอดคล้องกัน: ใช้แบบแผนการตั้งชื่อที่สอดคล้องกันสำหรับ span และ tag เพื่อให้ง่ายต่อการวิเคราะห์ข้อมูล trace
• เพิ่ม Tag ที่มีความหมาย: เพิ่ม tag ให้กับ span เพื่อให้บริบทเพิ่มเติมเกี่ยวกับการดำเนินการที่กำลังทำอยู่ ตัวอย่างเช่น คุณอาจเพิ่ม tag สำหรับ HTTP method, URL หรือ ID ผู้ใช้
• สุ่มตัวอย่าง Trace (Sample Traces): ในสภาพแวดล้อมที่มีปริมาณข้อมูลสูง คุณอาจต้องสุ่มตัวอย่าง trace เพื่อลดปริมาณข้อมูลที่ถูกรวบรวม ตรวจสอบให้แน่ใจว่าคุณกำลังสุ่มตัวอย่าง trace ในลักษณะที่ไม่ทำให้ผลลัพธ์ของคุณเอนเอียง มีกลยุทธ์ต่างๆ เช่น head-based หรือ tail-based sampling; tail-based sampling ให้ข้อมูลที่แม่นยำกว่าสำหรับการวิเคราะห์ข้อผิดพลาด
• ตรวจสอบโครงสร้างพื้นฐาน Tracing ของคุณ: ตรวจสอบประสิทธิภาพของ tracing backend ของคุณและให้แน่ใจว่ามันไม่ได้กลายเป็นคอขวดเสียเอง
• ทำให้การติดตั้งเครื่องมือวัดผลเป็นอัตโนมัติ: ใช้ automatic instrumentation agent ทุกครั้งที่เป็นไปได้เพื่อลดความพยายามที่ต้องใช้ในการติดตั้งเครื่องมือวัดผลในโค้ดของคุณ
• ผสานรวมกับเครื่องมือ Observability อื่นๆ: ผสานรวม distributed tracing กับเครื่องมือ observability อื่นๆ เช่น การรวบรวม log และการตรวจสอบเมตริก เพื่อให้ได้มุมมองที่สมบูรณ์ยิ่งขึ้นของระบบของคุณ
• ให้ความรู้แก่ทีมของคุณ: ตรวจสอบให้แน่ใจว่าทีมของคุณเข้าใจถึงประโยชน์ของ distributed tracing และวิธีใช้เครื่องมืออย่างมีประสิทธิภาพ

อนาคตของ Distributed Tracing

Distributed tracing กำลังพัฒนาอย่างรวดเร็ว โดยมีเครื่องมือและเทคนิคใหม่ๆ เกิดขึ้นตลอดเวลา แนวโน้มสำคัญบางประการใน distributed tracing ได้แก่:

• OpenTelemetry: OpenTelemetry กำลังจะกลายเป็นมาตรฐานของอุตสาหกรรมสำหรับ distributed tracing โดยให้ API ที่เป็นกลางต่อผู้ขายสำหรับการติดตั้งเครื่องมือวัดผลในโค้ดของคุณและรวบรวมข้อมูล telemetry การนำไปใช้อย่างแพร่หลายทำให้การผสานรวมระหว่างระบบต่างๆ ง่ายขึ้น
• eBPF: Extended Berkeley Packet Filter (eBPF) เป็นเทคโนโลยีที่ช่วยให้คุณสามารถรันโปรแกรมแบบ sandboxed ในเคอร์เนลของ Linux ได้ สามารถใช้ eBPF เพื่อติดตั้งเครื่องมือวัดผลในแอปพลิเคชันโดยอัตโนมัติและรวบรวมข้อมูล tracing โดยไม่จำเป็นต้องเปลี่ยนแปลงโค้ดใดๆ
• การวิเคราะห์ที่ขับเคลื่อนด้วย AI: อัลกอริทึมแมชชีนเลิร์นนิงกำลังถูกนำมาใช้เพื่อวิเคราะห์ข้อมูล trace และระบุความผิดปกติโดยอัตโนมัติ ทำนายปัญหาด้านประสิทธิภาพ และแนะนำการปรับปรุงให้เหมาะสม
• การผสานรวม Service Mesh: Service mesh เช่น Istio และ Linkerd ให้การสนับสนุนในตัวสำหรับ distributed tracing ทำให้ง่ายต่อการติดตั้งเครื่องมือวัดผลและตรวจสอบแอปพลิเคชันไมโครเซอร์วิส

สรุป

Distributed tracing เป็นเครื่องมือที่จำเป็นสำหรับการทำความเข้าใจและจัดการระบบแบบกระจายที่ซับซ้อน ด้วยการให้มุมมองแบบองค์รวมของโฟลว์คำขอ มันช่วยให้คุณสามารถระบุจุดคอขวดด้านประสิทธิภาพ ดีบักข้อผิดพลาด และปรับปรุงการจัดสรรทรัพยากรให้เหมาะสมที่สุด ในขณะที่สถาปัตยกรรมแอปพลิเคชันมีความซับซ้อนมากขึ้น distributed tracing จะมีความสำคัญมากยิ่งขึ้นในการรับประกันประสิทธิภาพ ความน่าเชื่อถือ และ observability ของแอปพลิเคชันสมัยใหม่

ด้วยการทำความเข้าใจแนวคิดหลัก การปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุด และการเลือกเครื่องมือที่เหมาะสม องค์กรสามารถใช้ประโยชน์จาก distributed tracing เพื่อรับข้อมูลเชิงลึกที่มีค่าเกี่ยวกับระบบของตนและมอบประสบการณ์ผู้ใช้ที่ดีขึ้น OpenTelemetry กำลังเป็นผู้นำไปสู่มาตรฐาน ทำให้ distributed tracing เข้าถึงได้ง่ายกว่าที่เคยเป็นมา เปิดรับ distributed tracing เพื่อปลดล็อกศักยภาพสูงสุดของแอปพลิเคชันสมัยใหม่ของคุณ