Bạn Không Thể Sửa Thứ Bạn Không Thấy: Logs, Metrics, Traces và SLO ở Quy mô Lớn

Khi hệ thống còn là một monolith trên một máy, debug gần như ấm cúng. Một log file. Một process để gắn debugger vào. Một chỗ sự thật cư ngụ. Reproduce con bug, đọc stack trace, sửa. Distributed systems lặng lẽ lấy đi sự tiện nghi đó. Một request checkout giờ toả ra cả tá service trên cả tá máy, và khi nó chậm hay hỏng, chẳng có một log file nào và chẳng có ai để ssh vào. Bạn không thể sửa thứ bạn không thấy — và ở quy mô lớn, việc nhìn thấy là một kỷ luật riêng.

Kỷ luật đó đáng được tách khỏi người anh em già hơn của nó. Monitoring là ngồi canh những dashboard bạn dựng sẵn, cho những thất bại bạn đã đoán trước — “CPU cao,” “disk đầy.” Observability là khả năng đặt những câu hỏi hoàn toàn mới cho một hệ thống đang chạy — kể cả những câu bạn chưa từng nghĩ tới — mà không phải ship code mới để trả lời. Monitoring báo cho bạn rằng có gì sai; observability cho bạn tìm ra vì sao. Ở quy mô lớn bạn cần cả hai, và cả hai được dựng từ ba loại dữ liệu.

Ba trụ cột: metrics, logs, traces

Mỗi trụ cột trả lời một câu hỏi khác nhau. Sai lầm kinh điển là cố bắt một cái làm cả ba việc — chết đuối trong logs để tính thứ một metric nên tính, hay dựng dashboard để đuổi theo thứ một trace chỉ ra trong vài giây.

• Metrics là những con số theo thời gian: số request, số lỗi, p99 latency, độ sâu hàng đợi. Chúng rẻ để lưu vì đã được tổng hợp, nên hoàn hảo cho dashboard và alert “có gì sai ngay bây giờ không?” Thứ chúng không nói được là request nào hay user nào. Metrics là chuông báo khói, không phải cuộc điều tra.
• Logs là những sự kiện rời rạc, chi tiết: “order 8123 fail validation: thiếu địa chỉ giao hàng.” Chúng trả lời “chính xác đã xảy ra gì trong ca cụ thể này?” Cái giá là khối lượng — ở quy mô lớn, logs thường là dòng đắt nhất trên hóa đơn — và một log dạng chuỗi không cấu trúc thì gần như vô dụng để truy vấn. Hãy cấu trúc hóa chúng.
• Traces theo dõi một request khi nó đi xuyên qua các service, chia thành những span có đo thời gian. Đây là trụ cột mà distributed systems buộc phải sinh ra: nó trả lời “thời gian đi đâu mất?” và “chặng nào lỗi?” khi câu trả lời bị trải ra trên mười cái máy.

// Không cấu trúc — ok trên một máy, vô dụng xuyên năm mươi máy
console.log(`Order ${id} fail cho ${userId}: ${err.message}`)

// Có cấu trúc — truy vấn được, và buộc vào cả request qua trace_id
log.error({
  event: "order_failed",
  trace_id: ctx.traceId,   // cùng một id chảy qua mọi service
  order_id: id,
  user_id: userId,
  error: err.message,
})

Sợi chỉ buộc chúng lại: một trace ID

Đây là thói quen có đòn bẩy cao nhất trong cả bài này. Cấp cho mỗi request một ID ngay ở biên, và lan nó qua mọi service nó chạm tới — đóng dấu nó lên mọi dòng log và mọi span. Đây là context propagation, và nó là khác biệt giữa mười log file rời rạc vô dụng và một câu chuyện mạch lạc: “cho tôi xem mọi thứ đã xảy ra với request abc-123.”

Chuẩn mở để sinh và lan dữ liệu này là OpenTelemetry (OTel) — một cách trung lập với nhà cung cấp để phát metrics, logs và traces, để bạn không bị cưới chết vào một backend. Hãy áp dụng sớm; gắn trace propagation vào một đàn service đã trưởng thành là công việc thực sự khổ sở.

Đọc một request phân tán: trace waterfall

Một trace vẽ mọi span của một request trên một timeline. Đột nhiên span chậm hiện ra ngay tắp lự — “checkout chậm” trở thành “payment-service chậm” trong vài giây, thay vì cả buổi chiều đào bới Slack xuyên team. Đây là phần thưởng biện minh cho chi phí instrument mọi thứ.

Metrics scale được: RED, USE và cái bẫy cardinality

Bạn không cần một nghìn dashboard; bạn cần vài tín hiệu có kỷ luật. Hai công thức quen thuộc che phần lớn:

• RED, cho service hướng request: Rate (request/giây), Errors (lỗi/giây), Duration (phân phối latency). Ba con số mỗi service bắt được phần lớn nỗi đau của người dùng.
• USE, cho tài nguyên như CPU, disk và connection pool: Utilization (mức dùng), Saturation (mức bão hòa), Errors.

Rồi tới cái bẫy lặng lẽ làm phá sản các team: cardinality. Một label của metric với giá trị vô hạn — user_id, request_id — nhân lên thành hàng triệu time series riêng biệt, và hóa đơn metrics của bạn nổ tung. Giữ label của metric cardinality thấp (status code, endpoint, region). Chi tiết cardinality cao — user nào, request nào — thuộc về traces và logs, không phải trên một metric.

Từ “nó còn sống không?” sang “nó đủ tốt chưa?”: SLI, SLO và error budget

Cú nhảy trưởng thành thật sự là ngừng đo cái máy và bắt đầu đo trải nghiệm của người dùng — như một con số bạn có thể hành động theo.

• Một SLI (Service Level Indicator) là một tỉ lệ đo được của các sự kiện tốt: phần trăm request được phục vụ dưới 300 ms, hay phần trăm request không phải 5xx.
• Một SLO (Objective) là mục tiêu bạn cam kết: 99.9% trong 30 ngày cuốn.
• Error budget là điều kỳ diệu rơi ra từ đó: 100% − 99.9% = 0.1%, qua một tháng là khoảng 43 phút hỏng “được phép.” Reliability trở thành một ngân sách bạn được phép tiêu.

Điều này đặt lại cuộc chiến muôn thuở giữa product (“ship nhanh hơn”) và engineering (“phải đáng tin”) thành một con số chung thay vì một trận cãi vã. Budget khỏe? Ship mạnh dạn, chấp nhận rủi ro. Budget gần cạn? Dừng ship tính năng và ổn định. Và, quan trọng nhất, nó cho bạn biết thứ gì thực sự đáng đánh thức ai đó dậy.

Alert đánh thức bạn vì đúng lý do

Cách nhanh nhất để biến on-call thành địa ngục là alert vào nguyên nhân. “Disk 80%” lúc 3 giờ sáng, mỗi đêm, cho một disk tự động giãn — và chẳng mấy chốc không ai đọc alert nữa, kể cả cái đêm con thật sự nổ. Đó là alert fatigue, và đó là cách những sự cố thật lọt qua.

# Alert vào TRIỆU CHỨNG (người dùng đau), không vào nguyên nhân (một CPU nóng).
# Chỉ page khi ta đang đốt error budget tháng nhanh.
alert: HighErrorBudgetBurn
expr:  error_rate_5m > 14.4 * (1 - 0.999)   # SLO 99.9%, đốt nhanh
for:   5m
then: page on-call · đính kèm link runbook

Hai quy tắc sửa phần lớn. Alert vào triệu chứng, không vào nguyên nhân — page khi người dùng thật sự đau (tốc đốt error budget, error rate tăng, latency vượt SLO), không phải khi một metric nội bộ giật nhẹ. Và mọi page phải vừa khẩn vừa làm được — nếu chẳng có gì để làm ngay phút này, nó là một ticket hay một dashboard, không phải một page lúc 3 giờ sáng. Đính một runbook vào mỗi alert để kỹ sư bị đánh thức có một bước đầu tiên, chứ không chỉ là một cơn hoảng.

Hóa đơn là có thật: sampling và retention

Dữ liệu observability có thể lặng lẽ tốn hơn chính ứng dụng nó canh chừng — đặc biệt là traces và logs. Ba đòn bẩy giữ nó tỉnh táo. Sample traces: giữ 100% lỗi và request chậm, nhưng chỉ một phần nhỏ những request thành công nhàm chán (“tail sampling” quyết định sau khi thấy kết quả). Phân tầng retention: nóng và tìm kiếm được trong vài ngày, rẻ và lạnh trong vài tháng. Và giữ lằn ranh cardinality. Hãy quyết định mấy thứ này có chủ đích — hoặc nhà cung cấp sẽ quyết định giùm bạn, bằng một hóa đơn.

Nên với tới gì

Góc nhìn thành thật theo quy mô công ty

• Solo / startup giai đoạn đầu. Bạn không cần một observability platform. Một error tracker (alert crash và exception), structured logs tìm kiếm được, và hai ba alert uptime/latency che phần lớn sự cố. Nhưng hãy làm một việc rẻ ngay bây giờ: đặt một trace ID lên mọi dòng log. Nó gần như miễn phí hôm nay và bạn sẽ biết ơn lần đầu tiên bạn có service thứ hai.
• Scale-up đang lớn. Áp dụng OpenTelemetry trước khi bị cưới chết, và lan trace ID qua mọi service. Dựng RED metrics và một bộ dashboard nhỏ. Viết SLO đầu tiên cho một hai hành trình thực sự quan trọng (checkout, login). Bắt đầu một lịch on-call và xóa không thương tiếc mọi alert không làm được gì. Bắt đầu sample traces trước khi hóa đơn dạy bạn.
• Doanh nghiệp lớn. Ba trụ cột là một platform có chủ sở hữu. Chính sách error budget gác cổng release một cách chính thức. Mỗi team sở hữu SLO và on-call của mình. Sampling, retention và cardinality được quản trị tập trung, vì chi phí giờ đã là một dòng tiền thực. Đến đây phần khó không còn là thu dữ liệu — mà là văn hóa: thực sự hành động theo budget, giữ alert trung thực, và viết runbook trước sự cố, không phải trong lúc sự cố.

Resilience là xây hệ thống để sống sót qua thất bại; observability là giác quan cho bạn nhận ra nó đang hỏng, tìm ra nguyên nhân trong vài phút thay vì vài giờ, và học từ nó sau đó. Xây cho thất bại, rồi làm thất bại hiện ra. Cùng nhau, đó là phần lớn của việc “vận hành” một hệ thống lớn thực sự nghĩa là gì — và đó là khác biệt lặng lẽ giữa một bí ẩn lúc 3 giờ sáng và một cú sửa lúc 3 giờ sáng.