Lướt tin thấy Bộ Công an đề xuất xây dựng 01 Ví điện tử quốc gia duy nhất gắn với VNeID, mình thấy ý tưởng của các bác chúng ta rất hay hướng tới nền tảng thanh toán thống nhất.

Tự nhiên phản xạ nghề nghiệp thì mình hình dung ngay về một cảnh rất quen thuộc… 11 giờ đêm, người dùng báo bị trừ tiền, bên kia báo chưa nhận, hệ thống vẫn xanh trên dashboard CPU.

Lúc đó, nếu chỉ nhìn vào hạ tầng để mò thì như muối bỏ biển xác định là mất ngủ luôn. Nhưng nếu làm Observability đúng cách thì là ngon luôn.

Nay chia sẻ lại một đêm on-call hệ thống từ trải nghiệm cá nhân để các bác chưa có được hào quang rực rỡ hiểu sức mạnh của việc tracing đúng (với mình).

Đêm đó ta và đồng chí support

Support quăng vào ticket một mã order_id. Cái này phải nghiêm túc này Rất sai lầm nếu đi grep cái order_id đó trong đống log. Chúng ta chỉ cần tìm ra Correlation ID.

Trong kiến trúc Microservices, một giao dịch nhảy qua đủ bước: API Gateway -> Ledger -> Partner Adapter -> Queue.

Nếu log chỉ rời rạc từng dòng thì chịu chết, chịu hẳn luôn. Nhưng nếu Log được quy hoạch hợp lý (Structured Logging), câu chuyện sẽ hiện ra ngay trước mắt:

Log kiểu như sau, các bác xem rõ nhé – mà sample thôi chứ log thật là phòng pháp chế vào cuộc đấy :))

# Kéo toàn bộ flow bằng correlation_id="2f3a9c9e"
ts=23:07:15 service=ledger       trace_id=2f3a9c9e step=reserve_fund status=OK balance_after=50000
ts=23:07:16 service=partner-gw   trace_id=2f3a9c9e step=call_upstream attempt=1 error="connection reset"
ts=23:07:16 service=partner-gw   trace_id=2f3a9c9e step=call_upstream attempt=2 error="timeout_3000ms"
ts=23:07:17 service=payment-orch trace_id=2f3a9c9e step=fallback action=mark_pending reason="partner_unreachable"

Chỉ vài dòng log nhưng nó trả lời được câu hỏi sống còn: Tiền đã hold ở Ledger, nhưng chết ở cổng Partner do timeout, hệ thống đã tự động chuyển trạng thái PENDING.

Lưu ý cực kỳ quan trọng: Đừng bao giờ để rớt correlationid khi bắn message vào Kafka/RabbitMQ.

Nếu chỉ gửi mỗi cái cục data (payload), tới lúc qua consumer xử lý là đứt gãy toàn bộ dấu vết. Code hay là phải kẹp thêm cái ID vào header:

// Bad practice: Mất context
producer.Publish(topic, payload) 

// Best practice: Propagate context
headers := map[string]string{"X-Correlation-ID": ctx.Value("correlation_id")}
producer.Publish(topic, payload, headers)

Timeline quan trọng hơn chi tiết lỗi

Đêm đó, thứ giúp mình trả lời với support không phải là nội dung error (vì timeout thì ai chả biết), mà là State Timeline.

Mình thường dựng một Audit Trail đơn giản để visualize trạng thái giao dịch (kiểu kiểu thế này):

[23:07:15] CREATED   (User init)
[23:07:15] RESERVED  (Ledger lock fund)
[23:07:16] RETRYING  (Partner GW - Attempt 1)
[23:07:16] RETRYING  (Partner GW - Attempt 2)
[23:07:17] PENDING   (System hold for Reconcile)

Nhìn vào đây thì tự tin báo khách: “Giao dịch không mất, đang nằm trong hàng đợi đối soát. Anh yên tâm ngủ tiếp.”

Khi CPU xanh, hãy alert bằng Business Metrics

CPU xanh mà khách vẫn chửi, vì alert hạ tầng không đo được “nỗi đau nghiệp vụ”.

Đêm đó, alert bắn đã được setup monitor cho Pending Age (Tuổi thọ của giao dịch đang chờ).

Thay vì đo CPU, mình đo cái này (ví dụ với PromQL):

# Cảnh báo nếu lượng giao dịch bị kẹt > 5 phút tăng đột biến
sum(increase(payment_transactions_total{status="pending", age_bucket=">5m"}[5m])) > 10

Pending count tăng có thể chỉ là bận. Pending age tăng mới là kẹt thật. Chỉ cần nhìn pending age nhô lên là mình biết sự cố đang lan rộng tới đâu, và sau khi xử lý xong thì chỉ cần pending age dừng leo rồi đi xuống là biết mình đã kéo hệ thống về trạng thái có thể kiểm soát.

Một lưu ý nhỏ nhưng rất thực dụng là: txn id hay user id đừng nhét vào label metrics, dễ nổ cardinality. Txn id để log và trace. Metrics để đo xu hướng và chất lượng hành trình.

Hóng hớt

Xử lý transaction cho một hệ thống như vậy SRE quèn đã cần kỹ lưỡng từng dòng log, từng metric như vậy. Thì không biết quy mô khủng như các ngân hàng đầu tư toàn cầu, nơi một giây delay là cả núi tiền, họ build hệ thống Observability kinh đến mức nào?

Đọc đến đây thì chắc mọi người cũng hiểu phần kiến thức này ai cũng nên biết, cũng PR trá hình cho những anh em hay theo dõi mình không bị tụt lại phía sau nhưng thật sự Observability with Datadog các sếp DevOps VietNam hợp tác cùng Datadog mang đến cho cộng đồng cực kỳ đáng để học hỏi.

Thấy từ cả phần kiến thức nền tảng cho các anh em chưa biết nhiều về Observability đến usecase quả ngân hàng đầu tư quốc tế to nhất nên mình cũng rất hóng.