การติดตาม: คืออะไร หลักการ และการรวบรวมข้อมูล

การติดตามในการตรวจสอบคืออะไร

การติดตาม เป็นวิธีการสังเกตแบบกระจายที่แต่ละคำขอที่เข้ามาจะถูกติดตามผ่านบริการและส่วนประกอบทั้งหมดของระบบ แตกต่างจากเมทริกซ์ที่แสดงค่ารวม (เวลาเฉลี่ยในการตอบสนอง จำนวนข้อผิดพลาด) การติดตามจะคงบริบทที่สมบูรณ์ของคำขอเฉพาะหนึ่งคำขอ

แต่ละขั้นตอนการประมวลผล — การเรียกฐานข้อมูล คำขอ HTTP ไปยังไมโครเซอร์วิสอื่น การดำเนินงานพื้นหลัง — จะถูกบันทึกเป็นหน่วยแยกต่างหากพร้อมประทับเวลา สถานะ และแอตทริบิวต์ ตามข้อมูลจาก Google Dapper (เอกสารต้นฉบับปี 2010) การติดตามช่วยระบุตำแหน่งความล่าช้าในระบบกระจายได้อย่างแม่นยำถึงระดับการเรียกเดียว

การติดตามมีความสำคัญเป็นพิเศษสำหรับแอปพลิเคชันมือถือที่แบ็กเอนด์ประกอบด้วยไมโครเซอร์วิสนับสิบ การกระทำของผู้ใช้ — เช่น การเข้าสู่ระบบบัญชี — อาจผ่าน API Gateway บริการตรวจสอบสิทธิ์ ฐานข้อมูล และบริการ Push หากไม่มีการติดตาม การระบุว่าส่วนประกอบใดทำให้การตอบสนองช้าลงนั้นแทบเป็นไปไม่ได้

Spans และ traces: โครงสร้างข้อมูลพื้นฐาน

หน่วยพื้นฐานของการติดตามคือ span แต่ละ span แทนการดำเนินการทางตรรกะหนึ่งรายการ: คำขอ HTTP, คำสั่ง SQL, การเรียก gRPC, การทำให้ JSON เป็นอนุกรม span ประกอบด้วยตัวระบุที่ไม่ซ้ำกัน ตัวระบุหลัก ชื่อการดำเนินการ เวลาเริ่มต้น ระยะเวลา สถานะ และชุดแอตทริบิวต์

ลำดับชั้นของ spans ใน trace

spans ทั้งหมดที่เกี่ยวข้องกับคำขอรูทเดียวกันจะถูกจัดกลุ่มเป็น trace span รูทแทนจุดเริ่มต้น — คำขอ HTTP จากไคลเอ็นต์มือถือไปยัง API span ย่อยสร้างเป็นแผนภูมิ โดยแต่ละ span อ้างอิงถึงหลักผ่านฟิลด์ parent_span_id

ระยะเวลาของ trace เท่ากับผลรวมของระยะเวลาของส่วนเวลาที่ไม่ซ้ำกันของ spans ทั้งหมด หาก span ย่อยสองรายการทำงานแบบขนาน เวลาของพวกมันจะไม่ถูกบวก — นี่เป็นสิ่งสำคัญสำหรับการวิเคราะห์ความล่าช้าที่เกิดจากการเรียกไมโครเซอร์วิสแบบขนานอย่างถูกต้อง

แอตทริบิวต์และเหตุการณ์ของ span

แต่ละ span สามารถมี แอตทริบิวต์ — คู่คีย์-ค่าพร้อมข้อมูลเมตา: URL คำขอ, ID ผู้ใช้, เวอร์ชัน API, ชื่อโฮสต์ แอตทริบิวต์ใช้สำหรับการกรองและจัดกลุ่ม traces นอกเหนือจากแอตทริบิวต์แล้ว spans ยังรองรับ เหตุการณ์ — ประทับเวลาพร้อมคำอธิบายข้อความ เช่น "cache miss" หรือ "ลองเชื่อมต่อใหม่"

distributed tracing ทำงานอย่างไร

Distributed tracing แก้ปัญหาการเชื่อมโยง spans ที่สร้างขึ้นในกระบวนการต่างกันและบนเครื่องต่างกัน กลไกนี้ใช้การส่งต่อบริบท: เมื่อบริการ A เรียกบริการ B ส่วนหัวที่มี ID trace ปัจจุบันและ ID span หลักจะถูกเพิ่มไปยังคำขอขาออก

โปรโตคอลการส่งต่อบริบทมาตรฐานคือ W3C Trace Context (ส่วนหัว traceparent และ tracestate) และ Zipkin B3 (ส่วนหัว X-B3-TraceId, X-B3-SpanId) W3C Trace Context ถูกนำมาใช้เป็นมาตรฐานโดย W3C Consortium ในปี 2021 และรองรับโดยผู้ให้บริการเทเลเมทรีหลักทุกราย

เมื่อได้รับคำขอ บริการ B จะแยก trace_id ออกจากส่วนหัวและสร้าง span ย่อยด้วย trace_id นั้น ดังนั้นเมื่อคำขอเสร็จสมบูรณ์ spans ทั้งหมดจากบริการต่าง ๆ จะถูกรวมเป็น trace เดียวที่ด้านตัวรวบรวม สิ่งนี้ต้องการให้ทุกบริการใช้ไลบรารีการติดตามเดียวกัน

การส่งต่อบริบทในไมโครเซอร์วิส

ในการพัฒนาแอปมือถือ การส่งต่อบริบทครอบคลุมไม่เพียงแบ็กเอนด์ แต่ยังรวมถึงการโต้ตอบระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ แอปพลิเคชันมือถือสามารถส่ง trace_id ในส่วนหัวของทุกคำขอ API ช่วยให้เชื่อมโยงการกระทำของไคลเอ็นต์กับการประมวลผลฝั่งเซิร์ฟเวอร์ OpenTelemetry SDK สำหรับ iOS และ Android รองรับการสร้างและการส่งต่อบริบท trace อัตโนมัติผ่านไคลเอ็นต์ HTTP

import io.opentelemetry.api.trace.Span
import io.opentelemetry.api.trace.Tracer
import io.opentelemetry.context.Context

class TracingInterceptor : Interceptor {
    private val tracer: Tracer = OpenTelemetry.getTracer("mobile-app")

    override fun intercept(chain: Interceptor.Chain): Response {
        val span = tracer.spanBuilder("HTTP POST /api/login")
            .setParent(Context.current())
            .startSpan()

        return chain.proceed(chain.request())
            .also { span.end() }
    }
}

ตัวสกัดกั้น Kotlin ที่นำเสนอสร้าง span สำหรับทุกคำขอ HTTP ไปยังเซิร์ฟเวอร์ บริบทหลักถูกส่งต่อจากโค้ดที่เรียกผ่าน Context.current() ซึ่งช่วยให้เชื่อมโยงการติดตามฝั่งไคลเอ็นต์กับการติดตามฝั่งเซิร์ฟเวอร์

การนำการติดตามไปใช้ด้วย OpenTelemetry

OpenTelemetry เป็นมาตรฐานโดยพฤตินัยสำหรับการรวบรวมข้อมูล trace ให้ API ที่เป็นหนึ่งเดียวสำหรับการสร้าง spans การตรวจวัดเครื่องมืออัตโนมัติของไลบรารียอดนิยม และกลไกที่ยืดหยุ่นสำหรับการส่งออกข้อมูลไปยังแบ็กเอนด์ต่าง ๆ: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic

การตรวจวัดเครื่องมืออัตโนมัติ

OpenTelemetry รองรับการสร้าง spans อัตโนมัติสำหรับเฟรมเวิร์กยอดนิยม: Spring Boot, Ktor, Flask, Express, gRPC นักพัฒนาเพียงเพิ่มการพึ่งพาไปยังโปรเจกต์ และไลบรารีจะสกัดกั้นคำขอขาเข้าและขาออกโดยอัตโนมัติ Auto-instrumentation สำหรับ Java ใช้ javaagent ที่ปรับเปลี่ยนไบต์โค้ดทันทีโดยไม่เปลี่ยนซอร์สโค้ด

สำหรับแพลตฟอร์มมือถือ OpenTelemetry ให้ Swift SDK และ Kotlin SDK พวกมันสร้าง spans โดยอัตโนมัติสำหรับคำขอเครือข่าย (URLSession, OkHttp) การดำเนินการฐานข้อมูล (CoreData, Room) และงานพื้นหลัง นักพัฒนาสามารถเพิ่ม spans ที่กำหนดเองสำหรับตรรกะทางธุรกิจ

การส่งออกข้อมูล

spans ที่รวบรวมจะถูกส่งไปยังตัวรวบรวมผ่านโปรโตคอล OTLP (OpenTelemetry Protocol) ตัวรวบรวมสามารถบัฟเฟอร์ กรอง และส่งต่อข้อมูลไปยังระบบจัดเก็บข้อมูลหนึ่งระบบหรือมากกว่า ตามเอกสารของ OpenTelemetry ความหน่วงโดยทั่วไปตั้งแต่การสร้าง span จนถึงการแสดงในแดชบอร์ดคือ 2–5 วินาทีเมื่อใช้การส่งออก gRPC

import OpenTelemetryApi
import OpenTelemetrySdk
import URLSessionInstrumentation

let instrumentation = URLSessionInstrumentation()
instrumentation.enable()

let tracer = OpenTelemetry.instance.tracerFactory
    .get("mobile-monitoring")

let span = tracer.spanBuilder("fetch-user-profile")
    .setAttribute(key: "user.id", value: userId)
    .startSpan()
span.end()

โค้ด Swift เปิดใช้งานการตรวจวัดเครื่องมืออัตโนมัติของเลเยอร์เครือข่ายและสร้าง span ที่กำหนดเองสำหรับการดำเนินการดึงข้อมูลโปรไฟล์ผู้ใช้ แอตทริบิวต์ user.id ช่วยให้กรอง traces ตามผู้ใช้เฉพาะในภายหลัง

กลยุทธ์การสุ่มตัวอย่าง trace

ในระบบที่มีโหลดสูง การติดตามทุกคำขอเป็นไปไม่ได้ — สร้างภาระที่ยอมรับไม่ได้ต่อพื้นที่จัดเก็บและเครือข่าย การสุ่มตัวอย่าง แก้ปัญหานี้โดยบันทึกเพียงส่วนหนึ่งของ traces การเลือกกลยุทธ์ส่งผลโดยตรงต่อความสมบูรณ์ของข้อมูลและต้นทุนโครงสร้างพื้นฐาน

การสุ่มตัวอย่างแบบ head-based

การตัดสินใจบันทึก trace จะทำ ณ เวลาที่สร้าง — ใน span รูท วิธีที่ง่ายและธรรมดาที่สุด: เปอร์เซ็นต์คงที่ของคำขอ (เช่น 5%) ถูกบันทึก ส่วนที่เหลือจะถูกทิ้ง ข้อเสียคือไม่สามารถรับประกันได้ว่าข้อผิดพลาดที่หายากจะถูกจับ Probability sampler ใน OpenTelemetry รองรับการตั้งค่าความน่าจะเป็นตั้งแต่ 0.0 ถึง 1.0

การสุ่มตัวอย่างแบบ tail-based

การตัดสินใจจะถูกเลื่อนออกไปจนกว่า spans ทั้งหมดของ trace จะเสร็จสมบูรณ์ ตัววิเคราะห์ประเมินว่า trace มีข้อผิดพลาด การเกินเวลา หรือแอตทริบิวต์ที่น่าสนใจหรือไม่ จากนั้นจึงบันทึก วิธีนี้ต้องมีการบัฟเฟอร์ spans ทั้งหมดในตัวรวบรวม ซึ่งเพิ่มการใช้หน่วยความจำ ตามข้อมูลจาก Grafana Labs การสุ่มตัวอย่างแบบ tail-based มีประสิทธิภาพมากกว่า 40–60% ในแง่ของ "ต้นทุนต่อข้อมูลที่มีประโยชน์" ในระบบที่มีข้อผิดพลาดที่หายากแต่สำคัญ

ความแตกต่างระหว่างการติดตามและการบันทึก

การบันทึก บันทึกเหตุการณ์แต่ละรายการพร้อมระดับความสำคัญ (info, warn, error) แต่ไม่ได้เชื่อมโยงเข้าสู่บริบทของคำขอเดียว การติดตาม ในทางกลับกัน สร้างแผนภูมิที่มีโครงสร้างของการดำเนินการที่เป็นของคำขอแบบ end-to-end ในทางปฏิบัติ ทั้งสองวิธีนี้ไม่ได้แยกจากกันแต่เสริมซึ่งกันและกัน

บันทึกมีประสิทธิภาพสำหรับการวิเคราะห์รายละเอียดของข้อผิดพลาดเฉพาะ: นักพัฒนาเห็นข้อความที่แน่นอน สแต็กเทรซ และค่าตัวแปร การติดตามตอบคำถาม "ทำไมคำขอใช้เวลา 5 วินาที" — แสดงให้เห็นว่าไมโครเซอร์วิสหรือการเรียกใดใช้เวลามากที่สุด ตามข้อมูลจาก Honeycomb (2024) ทีมที่ใช้การติดตามร่วมกับการบันทึกค้นหาสาเหตุที่แท้จริงของเหตุการณ์ได้เร็วกว่า 2.3 เท่า

วิธีการที่ทันสมัย — ความสามารถในการสังเกต — รวมการติดตาม เมทริกซ์ และบันทึกเป็นระบบเดียว OpenTelemetry รองรับความสัมพันธ์ระหว่างสัญญาณทั้งสามนี้: แต่ละ span สามารถมีลิงก์ไปยังบันทึกที่เกี่ยวข้อง และเมทริกซ์สามารถถูกแท็กด้วย trace_id เพื่อเจาะลึกไปยัง traces เฉพาะ