Bài 16: Observability — Metrics, Logs & Tracing

Bài 15 vừa tách một use case thành bốn service và tạo ra một vấn đề mới: khi request đi qua bốn tiến trình, không tiến trình nào nhìn thấy toàn bộ đường đi của nó. Hop nào ăn hết thời gian? Nó hỏng ở đâu? Không trả lời được hai câu đó thì mọi cơ chế chống chịu ở Bài 17 đều là đoán mò.

Lab của bài này tự viết cả ba trụ cột trong app.js — histogram, correlation ID, span — không dùng thư viện nào. Ba phép đo đáng chú ý. Thứ nhất, với sự cố làm 1% request chậm 300 ms, p99 đo được là 0,90 ms — nó hoàn toàn không thấy sự cố; phải tới p99,9 mới hiện ra 474 ms. Thứ hai, thêm đúng một nhãn user_id vào metric làm số chuỗi thời gian nhảy từ 2 lên 49.317 và bộ nhớ từ 330 byte lên 8,4 MB — chỉ trong 8 giây chạy tải, trên một instance. Thứ ba, quên truyền correlation ID qua một chặng làm waterfall rơi từ 4 span xuống 1 span, và toàn bộ thời gian bị quy sai cho service gọi.

16.1 Monitoring trả lời câu hỏi cũ, observability trả lời câu hỏi mới

Hai chữ này hay được dùng thay nhau, nhưng chúng mô tả hai năng lực khác hẳn. Monitoring là chuẩn bị sẵn câu trả lời cho những câu hỏi bạn đã biết trước sẽ hỏi: CPU bao nhiêu, tỉ lệ lỗi bao nhiêu, có vượt ngưỡng không. Nó cho ra dashboard và alert. Observability là khả năng trả lời câu hỏi bạn chưa từng lường trước — thứ luôn xuất hiện trong mọi sự cố thật, vì nếu bạn đã lường trước được thì bạn đã vá rồi.

Ba trụ cột dưới đây khác nhau ở ba chiều cùng lúc: độ chi tiết, chi phí, và loại câu hỏi trả lời được. Hiểu sai chiều nào cũng dẫn tới hoá đơn lớn mà vẫn không debug được.

16.2 Metrics đúng: RED, USE, và hai cái bẫy

Hai bộ chỉ số phủ gần hết nhu cầu. RED cho mỗi service: Rate (lưu lượng), Errors (tỉ lệ lỗi), Duration (phân bố thời gian). USE cho mỗi tài nguyên: Utilization, Saturation (độ dài hàng đợi — Bài 1 đã cho thấy đây mới là chỉ số cảnh báo sớm), Errors. Một dịch vụ có đủ RED cho từng route và USE cho từng tài nguyên thì đã trả lời được đa số câu hỏi thường gặp.

Nhưng chữ D trong RED phải là phân bố, không phải một con số. Lab tái tạo một sự cố có hình dạng điển hình nhất — đại đa số request nhanh, một tỉ lệ nhỏ chậm 300 ms — rồi hỏi: percentile nào nhìn thấy được sự cố đó?

Cột p99 có một vách đứng giữa 1% và 2%: từ 0,90 ms nhảy lên 300 ms. Lý do rất đơn giản khi nói ra — p99 là ngưỡng mà 99% request nằm dưới, nên khi đúng 1% request chậm, ngưỡng đó rơi ngay tại biên và có thể rơi về phía nhanh. p99 mù với sự cố ảnh hưởng đúng 1% người dùng. Ở mức 1%, phải tới p99,9 mới thấy — histogram trong app đo được p99,9 = 474 ms.

Còn cột mean thì tệ theo kiểu khác: nó tăng đều đặn (1,61 → 3,06 → 6,28 → 15,60) nên trông có vẻ hữu ích, nhưng không request nào thật sự mất 3,06 ms cả. Với 1% chậm, mean cao gấp 23 lần median. Nó không mô tả trải nghiệm của ai hết: không mô tả người dùng bình thường (0,13 ms), cũng không mô tả người dùng gặp sự cố (300 ms).

Cái bẫy thứ hai của metrics không nằm ở giá trị mà nằm ở nhãn. Mỗi tổ hợp nhãn là một chuỗi thời gian riêng, và mỗi chuỗi tốn bộ nhớ riêng. Lab chạy cùng một tải với hai cấu hình nhãn khác nhau, 50.000 người dùng phân biệt, trong 8 giây:

16.3 Correlation ID: một header, và chỗ nó hay bị đánh rơi

Log có cấu trúc nghĩa là mỗi dòng là một object có schema thay vì một chuỗi tự do — nhờ đó truy vấn được theo trường, thay vì phải viết biểu thức chính quy lúc 3 giờ sáng. Nhưng trường quan trọng nhất trong đó không phải thông báo lỗi mà là correlation ID: mã định danh sinh ra ở chặng đầu tiên (thường là gateway, Bài 4) và đi theo request qua mọi service.

// Generated at the first hop, reused if already present. These 3 lines are the whole "generate" part.
function corrIdOf(req) {
  return req.headers['x-correlation-id'] || `c-${INSTANCE}-${Date.now().toString(36)}-${seq++}`;
}

// Returned to the client: when they report a bug, they attach this ID and you find it instantly.
res.setHeader('X-Correlation-Id', corrId);

// And here is the part that gets forgotten — PROPAGATE it when calling another service:
function callPeer(peer, path, corrId) {
  const headers = corrId ? { 'X-Correlation-Id': corrId } : {};
  return new Promise((resolve) => {
    http.get({ host, port, path, headers }, ...);
  });
}

Phần "sinh" thì ai cũng làm đúng. Phần "truyền tiếp" là chỗ hỏng, và nó hỏng im lặng: không có lỗi nào, mọi request vẫn chạy, chỉ là trace bị cắt làm hai mảnh không nối được. Lab đo hậu quả bằng cách chạy cùng một chuỗi ba hop với propagate=1 và propagate=0:

$ ./tools/observe-test.sh trace

  --- propagate=1        (CO truyen correlation ID)
  so chang: 4
    app1/traced-chain        292.52 ms   52.0%
    app2/slow-async          256.98 ms   45.7%     (!) thu pham hien ra ngay
    app3/slow-async            7.46 ms    1.3%
    app1/slow-async            5.71 ms    1.0%

  --- propagate=0        (QUEN truyen)
  so chang: 1
    app1/traced-chain        289.32 ms  100.0%     (!) quy HET cho app1

Đọc kỹ dòng cuối: khi không truyền ID, hệ thống báo app1 chiếm 100% thời gian. Đó không phải "thiếu thông tin" — đó là thông tin sai, và nó sai theo hướng nguy hiểm nhất, chỉ thẳng vào service vô tội. Một đội đọc waterfall đó sẽ đi tối ưu app1 trong khi thủ phạm thật (app2, ăn 45,7% thời gian) ngồi yên.

16.4 Tracing: span nằm rải rác, phải có người thu gom

Một trace là toàn bộ hành trình của một request; mỗi span là một chặng trong đó, có thời điểm bắt đầu, thời lượng, và span cha. Ghép lại thành waterfall — thứ trả lời câu hỏi "hop nào ăn hết thời gian" bằng cách chỉ ra, không phải bằng cách suy đoán.

Có một chi tiết kiến trúc mà lab bắt buộc phải đối mặt và nó rất đáng nói: span của mỗi service nằm trong bộ nhớ của chính service đó. Không tiến trình nào tự nhiên nhìn thấy toàn bộ. Vì vậy mọi hệ tracing thật đều cần một bộ thu gom — trong lab này là endpoint /trace-all, đi hỏi từng instance rồi ghép span lại. Đây chính là vai trò của collector trong các hệ thật, và nó giải thích vì sao tracing luôn kéo theo thêm một thành phần hạ tầng phải vận hành.

Bảng này nối thẳng với mục 16.2: nếu sự cố của bạn chỉ ảnh hưởng 1% request, thì head-based sampling ở tỉ lệ 1% sẽ giữ lại đúng 1% của 1% — tức một phần vạn. Bạn sẽ có metrics báo p99,9 xấu nhưng không có trace nào của một request chậm để xem. Đó là lý do các hệ trưởng thành thường dùng tail sampling cho đúng nhóm trace đáng giữ: chậm và lỗi.

16.5 SLI, SLO và error budget: biến độ tin cậy thành con số ra quyết định được

Ba khái niệm này thường bị coi là thủ tục quản lý, nhưng chúng giải một vấn đề rất kỹ thuật: quyết định bao giờ thì dừng ship tính năng để đi vá độ tin cậy. Không có chúng, cuộc tranh luận đó diễn ra bằng cảm tính và thường thắng bởi người nói to hơn.

• SLI — chỉ số đo từ góc nhìn người dùng, dạng "tỉ lệ sự kiện tốt trên tổng sự kiện". Ví dụ: tỉ lệ request thành công và dưới 250 ms.
• SLO — mục tiêu có số cho SLI đó, ví dụ 99,9%.
• Error budget — phần được phép hỏng: 100% − SLO. Với SLO 99,9% thì ngân sách là 0,1%, tức khoảng 43 phút mỗi tháng.

Lab tính SLI trực tiếp từ histogram — đúng cách các hệ thật làm, và chỉ làm được vì có histogram chứ không phải trung bình:

Hàng giữa là hàng đáng nhớ nhất, và nó khép lại vòng lặp của cả bài: đúng cái sự cố mà p99 không nhìn thấy (1% chậm, p99 = 0,90 ms) lại đốt hết 8,7 lần ngân sách lỗi tháng đó. Nếu bạn chỉ alert theo p99, bạn sẽ ngủ ngon suốt trong khi ngân sách của cả quý bốc hơi.

Tự làm lại các phép đo

cd blog/sysdesign/sysdesign-lab

# --- Which percentile actually SEES the incident? ---
./tools/observe-test.sh percentile
#   0.5% slow -> p99   0.49ms      1% slow -> p99   0.90ms   (p99.9 = 474ms)
#     2% slow -> p99 300.01ms      5% slow -> p99 303.05ms
#   p99's cliff edge sits between 1% and 2%.

# --- What happens if we add one user_id label? ---
./tools/observe-test.sh cardinality
#   route,status        ->      2 time series ·     330 bytes
#   route,status,user   -> 49,317 time series · 8,855,160 bytes

# --- Correlation ID: propagated versus dropped ---
./tools/observe-test.sh trace
#   propagate=1 -> 4 spans, app2 eats 45.7% of the time
#   propagate=0 -> 1 span, 100% blamed on app1 (WRONG, not just missing)

# --- SLI and error budget computed from a real histogram ---
./tools/observe-test.sh slo
#   1% slow -> SLI 99.034% against a 99.9% target -> 865.5% of the month's budget burned

Tóm lại

Ba trụ cột không thay thế được nhau: metrics cho biết có chuyện, trace cho biết ở đâu, log cho biết vì sao. Chi phí của chúng tăng dần theo đúng thứ tự đó, và mỗi cái có một cái bẫy riêng.

Bẫy của metrics là tưởng rằng chọn p99 là đủ. Phép đo cho thấy điều ngược lại: với sự cố ảnh hưởng đúng 1% người dùng, p99 = 0,90 ms — hoàn toàn mù — trong khi p99,9 = 474 ms và ngân sách lỗi tháng đó đã bị đốt 8,7 lần. Percentile phải chọn theo tỉ lệ người dùng bạn cần bảo vệ, không phải theo thói quen. Còn trung bình thì tệ theo kiểu khác: cao gấp 23 lần median mà không mô tả trải nghiệm của bất kỳ ai.

Bẫy thứ hai của metrics nằm ở nhãn, và nó đắt bằng tiền thật: thêm đúng một nhãn user_id làm số chuỗi thời gian nhảy từ 2 lên 49.317 — hơn 24 nghìn lần — chỉ trong 8 giây trên một instance. Nhãn phải có tập giá trị hữu hạn và biết trước.

Về tracing, bài học đắt nhất không phải kỹ thuật mà là hậu quả của một thiếu sót nhỏ: quên truyền correlation ID không làm bạn thiếu dữ liệu, nó làm bạn có dữ liệu sai — 100% thời gian bị quy cho service vô tội, trong khi thủ phạm thật ăn 45,7%. Và chỗ hay quên nhất là ranh giới queue, tức đúng chỗ khó debug nhất.

Bài 17 dùng chính bộ đo này để nhìn một hiện tượng mà nếu không đo thì không bao giờ tin được: hệ thống tự đánh sập mình bằng lưu lượng retry của chính nó, và ba tầng retry ba lần tạo ra hai mươi bảy lần tải lên service yếu nhất.