BÀI 3: CÁC KHÁI NIỆM "SỐNG CÒN" – TRANSACTION, SPAN, TRACE ID VÀ PARENT ID

Chào các bạn! Ở hai bài viết trước, chúng ta đã biết APM là gì và bộ máy Elastic APM vận hành ra sao. Khi bật giao diện Kibana APM lên, bạn sẽ thấy những biểu đồ dạng "thác nước" (Waterfall) hiển thị chi tiết đến từng mili-giây của Request.

Nhưng làm sao Elastic APM làm được điều kỳ diệu đó? Làm sao nó biết câu lệnh SQL này hay hàm xử lý kia thuộc về Request của User A mà không phải User B?

Hôm nay, chúng ta sẽ cùng nhau làm rõ 4 khái niệm "sống còn" trong APM: Transaction, Span, Trace ID và Parent ID. Nắm chắc 4 khái niệm này, bạn đã đi được 50% chặng đường làm chủ APM rồi đấy!

1. Transaction (Giao dịch) – Điểm khởi đầu của một hành trình

Hãy tưởng tượng Transaction giống như một chuyến xe buýt trọn gói từ điểm đầu đến điểm cuối.

Trong Elastic APM, Transaction là phần tử có cấp độ cao nhất (Highest-level work), đại diện cho một công việc trọn vẹn mà ứng dụng của bạn thực hiện để phản hồi lại một sự kiện. Thông thường, một Transaction sẽ là:

• Một Request HTTP gửi đến hệ thống (Ví dụ: POST /api/v1/checkout).
• Một Task chạy ngầm được kích hoạt (Ví dụ: Một Queue Job xử lý gửi mail, một Cronjob chạy lúc 12h đêm).

Tóm lại: Cứ mỗi khi có ai đó "gõ cửa" ứng dụng của bạn (qua HTTP hoặc CLI) và ứng dụng bắt đầu xử lý, Elastic APM Agent sẽ mở một Transaction để ghi lại.

2. Span (Khoảng thời gian) – Các mảnh ghép chi tiết

Nếu Transaction là một chuyến xe buýt lớn, thì Span chính là các chặng dừng chân hoặc các hành động cụ thể diễn ra trong chuyến xe đó.

Span đại diện cho một khối lệnh xử lý cụ thể nằm bên trong một Transaction. APM Agent tự động tạo ra các Spans cho các hoạt động như:

• Chạy một câu lệnh Database (SQL queries, MongoDB commands).
• Gọi một API bên ngoài qua HTTP Client (Ví dụ: Gọi sang cổng thanh toán VnPay, Momo).
• Đọc/Ghi file hoặc tương tác với Cache (Redis, Memcached).
• Hoặc một hàm Logic phức tạp do chính bạn tự định nghĩa để đo thời gian (Custom Span).

Một Transaction có thể chứa không giới hạn số lượng Span. Khi nhìn vào danh sách các Span, bạn sẽ biết chính xác dòng chảy của code đang chạy như thế nào.

3. Trace ID và Parent ID – Sợi dây liên kết vô hình

Làm sao Elastic APM liên kết được các Span và Transaction lại với nhau thành một cây sơ đồ phân cấp hoàn chỉnh? Câu trả lời nằm ở Cơ chế định danh bằng ID.

Trace ID (Mã định danh chuỗi hành trình) Khi một Request đầu tiên chạm vào hệ thống, APM Agent sẽ ngay lập tức sinh ra một chuỗi chuỗi ký tự ngẫu nhiên duy nhất gọi là Trace ID.

• Quy tắc: Trace ID này sẽ giữ nguyên không đổi trong suốt hành trình của Request đó, ngay cả khi nó đi qua nhiều hàm, nhiều database, thậm chí là nhảy qua nhiều service khác nhau (Microservices).
• Tất cả Transaction và Span sinh ra trong hành trình này đều mang chung một Trace ID này để nhận diện "chúng ta là người một nhà".

Span ID & Parent ID (Mã định danh cha - con) Để xếp thứ tự trước sau và phân cấp cho các hoạt động trong một Trace, APM sử dụng cặp bài trùng: Span ID (định danh chính nó) và Parent ID (định danh kẻ sinh ra nó).

Hãy xem một ví dụ thực tế về cấu trúc ID của một Request:

• Transaction: POST /checkout
• Trace ID: xyz-123
• Transaction ID / Span ID: aaa
• Parent ID: null (Vì nó là gốc)
• Span 1: Kiểm tra giỏ hàng trong DB (SELECT * FROM carts)
• Trace ID: xyz-123 (Giữ nguyên)
• Span ID: bbb
• Parent ID: aaa (Nó được sinh ra trong Transaction POST /checkout)
• Span 2: Gọi API sang bên Vận Chuyển (POST /shipping/calculate)
• Trace ID: xyz-123
• Span ID: ccc
• Parent ID: aaa

4. Bức tranh tổng thể trên giao diện Kibana

Khi tất cả dữ liệu có đầy đủ Trace ID và Parent ID được đẩy về Elasticsearch, Kibana sẽ dựa vào đó để vẽ lên một biểu đồ dạng Waterfall trực quan như thế này:

[Transaction] POST /checkout (Tổng thời gian: 150ms)
  ├── [Span 1] SELECT * FROM carts -------------> (Mất 20ms)
  └── [Span 2] POST /shipping/calculate ----------> (Mất 110ms)

Nhìn vào đây, một lập trình viên dù chưa biết code của bạn viết gì cũng có thể chỉ tay ngay vào màn hình và nói: "Web chậm là do thằng API bên Vận chuyển (Span 2) nó ngậm mất 110ms kìa, code DB mất có 20ms thôi!".

Đó chính là sức mạnh của việc thấu hiểu các khái niệm APM.

Lời kết & Bài học tiếp theo

Đến đây, chúng ta đã hoàn thành trọn vẹn phần lý thuyết nền tảng. Các bạn đã hiểu về bức tranh tổng quan (Bài 1), kiến trúc hệ thống (Bài 2) và ngôn ngữ chung của APM (Bài 3).

Đã đến lúc chúng ta "nhúng tay vào bùn"!

Ở Bài 4, chúng ta sẽ chính thức bước vào phần thực hành: Dựng Elastic APM Server & Kibana bằng Docker Compose ngay trên máy cá nhân của bạn. Hãy chuẩn bị sẵn Docker trong máy nhé!

Các bạn có chỗ nào chưa rõ về cách phân biệt Transaction và Span không? Để lại comment để mình giải thích sâu hơn nhé!