Dashboard: vài chỉ số đáng nhìn mỗi ngày

By Better Wise

Mở dashboard lên là biết app có ổn không

Bài trước bạn đã có hai metric nền: latency (nhìn p95, p99 chứ không chỉ trung bình) và error rate. Có metric rồi thì câu hỏi tiếp theo là đặt chúng ở đâu, để lúc 3 giờ sáng bạn mở dashboard lên và biết ngay app có ổn không, thay vì cuộn qua 40 panel rồi vẫn không hiểu gì.

Sau bài này bạn có thể:

• Giải thích vì sao dashboard on-call chỉ nên có 4 đến 6 panel
• Bố trí panel theo thứ tự từ tổng quan xuống chi tiết
• Chọn bộ panel nền tảng cho một app nhỏ: traffic, error rate, latency, saturation
• Nhận ra panel nào không nên đặt trên dashboard on-call
• Mở một dashboard lạ và biết bắt đầu nhìn từ đâu

Dashboard trả lời câu hỏi, không phải khoe metric

Chuyện thật: 2 giờ sáng, alert bắn. Mở dashboard, 40 panel, đủ thứ màu. Mất 10 phút mới nhận ra là error rate tăng ở đúng một endpoint. Nếu dashboard chỉ có 5 panel xếp đúng thứ tự, chuyện đó mất 30 giây.

Nguyên tắc duy nhất cần nhớ: mỗi panel phải trả lời được một câu hỏi cụ thể mà bạn sẽ thật sự hỏi khi app có vấn đề. Panel không trả lời câu hỏi nào thì xóa, dù nó đẹp.

Ba câu hỏi on-call hay hỏi nhất, theo đúng thứ tự:

1. App có đang ổn không?
2. Nếu không ổn thì hỏng ở đâu?
3. Do đâu mà hỏng?

Dashboard tốt đi đúng ba câu này, từ trái sang phải, từ trên xuống dưới.

Bài tập nhanh

1. Panel "số user đăng ký mới theo tuần" có nên nằm trên dashboard on-call không?
2. Panel "số dòng log ERROR mỗi phút" thì sao?

Xem gợi ý đáp án

1. Không. Đây là metric kinh doanh, để ở dashboard product. On-call cần biết app có hỏng không, không cần biết tuần này bán được bao nhiêu.
2. Có, nhưng chỉ khi bạn đã có structured log đủ tốt để đếm. Nó trả lời câu hỏi "có gì đó bất thường vừa xảy ra không", nên đặt cạnh error rate.

Xếp panel từ tổng quan xuống chi tiết

Mắt người quét theo hình chữ F: ngang trước, rồi xuống. Vì vậy panel trả lời câu hỏi số 1 phải nằm ở góc trên bên trái. Panel chi tiết nhất nằm cuối, để bạn drill-down khi cần.

flowchart TD
    A["🩺<br/>Có ổn không?<br/>traffic + error rate"] --> B["🎯<br/>Hỏng ở đâu?<br/>lỗi theo endpoint"]
    B --> C["🐢<br/>Chậm cỡ nào?<br/>p95 theo endpoint"]
    C --> D["🧱<br/>Do đâu?<br/>CPU, DB pool, queue"]

Một mẹo nhỏ nhưng cứu được nhiều lần: trên mỗi panel latency, vẽ thêm một đường tham chiếu mức bình thường (trung bình 7 ngày). Không có đường đó thì p95 = 800ms là cao hay thấp, bạn không biết.

Bài tập nhanh

Bạn có 5 panel: (a) p95 latency toàn app, (b) error rate toàn app, (c) lỗi theo endpoint, (d) traffic, (e) CPU. Hãy xếp thứ tự hiển thị.

Xem gợi ý đáp án

(d) traffic và (b) error rate lên trên cùng, cạnh nhau: đây là câu trả lời cho "có ổn không". Hàng giữa là (a) p95 latency và (c) lỗi theo endpoint: hỏng hoặc chậm ở đâu. Cuối cùng là (e) CPU: do đâu. Nếu bắt buộc chỉ giữ 4 panel thì bỏ (a), vì (c) đã cho bạn biết endpoint nào có vấn đề.

Bộ 4 đến 6 panel cho một app nhỏ

Đây là bố cục mình dùng cho gần như mọi app nhỏ, chỉ đổi phần chi tiết cho hợp domain:

Với app nhỏ, dashboard on-call nên có _____ panel, không phải càng nhiều càng tốt. Panel đầu tiên ở góc trên trái phải trả lời câu hỏi _____, còn panel chi tiết nhất nằm ở _____. Đường _____ (baseline) giúp bạn biết mức bình thường để so sánh. Khi error rate tăng, panel breakdown theo _____ hoặc status code cho biết hỏng ở đâu.

Bài tập nhanh

Latency p95 của app bạn bình thường 300ms. Hôm nay nó là 320ms, nhưng error rate vọt từ 0.5% lên 6%, và panel lỗi theo endpoint cho thấy /checkout chiếm 90% số lỗi. Bạn nhìn panel nào tiếp theo và vì sao?

Xem gợi ý đáp án

Nhìn panel saturation (CPU, DB connection pool, queue depth), vì đây là bước "do đâu". Nếu DB pool đầy thì /checkout timeout là hệ quả. Cũng nên nhìn panel traffic: nếu request/giây tăng vọt cùng lúc thì nhiều khả năng đây là quá tải chứ không phải bug mới deploy. Latency p95 gần như không đổi là dấu hiệu tốt: phần lớn người dùng vẫn ổn, vấn đề khu trú ở một luồng.

Giữ dashboard gọn: mấy lỗi mình từng mắc

• Nhồi quá nhiều panel. Trên 8 panel là bắt đầu phải cuộn, mà phải cuộn thì lúc 3 giờ sáng bạn sẽ bỏ qua panel quan trọng.
• Thiếu đường baseline. Không có mức bình thường thì mọi con số đều vô nghĩa.
• Trộn đơn vị trên cùng một panel. ms và % trên một trục tung khiến cả hai đều khó đọc. Tách ra.
• Refresh quá nhanh. 5 giây một lần làm bạn không kịp đọc. 30 đến 60 giây là đủ cho on-call.
• Không ghi timezone. Sự cố lúc 14:00 UTC và 14:00 giờ Việt Nam là hai câu chuyện khác nhau.
• Đặt tên panel bằng tên metric thô. http_request_duration_seconds_p95 khó đọc hơn "p95 latency toàn app". Tên panel nên là câu hỏi, không phải tên biến.

Một quy tắc dễ nhớ: nếu bạn không giải thích được panel đó trong một câu, nó chưa cần ở đây.

Mang gì sang bài checkpoint

• Dashboard on-call trả lời ba câu: có ổn không, hỏng ở đâu, do đâu
• 4 đến 6 panel là đủ, xếp từ tổng quan xuống chi tiết, quan trọng nhất ở góc trên trái
• Bộ nền: traffic, error rate, latency (p95/p99), saturation
• Luôn có đường baseline để biết "bình thường" là bao nhiêu
• Metric kinh doanh để ở dashboard khác

Bài tiếp theo là checkpoint của module: bạn sẽ tự dựng một dashboard nhỏ từ dữ liệu cho sẵn, rồi kiểm tra xem mình có đọc ra sự cố trong vài giây hay không.

Front: Mục đích của một dashboard on-call là gì? Back: Trả lời câu hỏi app có đang ổn không trong vài giây, không phải khoe mọi metric.

Front: Vì sao panel quan trọng nhất nên đặt ở góc trên bên trái? Back: Mắt người quét theo hình chữ F, nên vị trí đó được nhìn đầu tiên.

Front: Dashboard on-call của một app nhỏ nên có bao nhiêu panel? Back: 4 đến 6 panel.

Front: Ba câu hỏi mà dashboard on-call phải trả lời theo thứ tự là gì? Back: Có ổn không, hỏng ở đâu, do đâu.

Front: Bốn panel nền tảng của một dashboard nhỏ? Back: Traffic, error rate, latency (p95/p99), saturation.

Front: Panel traffic trả lời câu hỏi gì? Back: Có bao nhiêu request mỗi giây và lưu lượng có tụt hoặc tăng bất thường không.

Front: Khi error rate tăng, nên xem panel nào tiếp theo? Back: Panel lỗi breakdown theo endpoint hoặc status code, để biết hỏng ở đâu.

Front: Vì sao nên xem p95, p99 thay vì chỉ giá trị trung bình? Back: Trung bình che mất nhóm người dùng đang bị chậm nặng.

Front: Đường baseline trên panel dùng để làm gì? Back: Cho biết mức bình thường là bao nhiêu, để nhận ra con số hôm nay có bất thường không.

Front: Panel saturation theo dõi những gì? Back: Tài nguyên sắp cạn: CPU, memory, DB connection pool, queue depth.

Front: Metric nào không thuộc dashboard on-call? Back: Metric kinh doanh như số đăng ký mới theo tuần, để ở dashboard product.

Front: Vì sao không nên để dashboard refresh mỗi 5 giây? Back: Không kịp đọc và tạo cảm giác nhiễu, 30 đến 60 giây là đủ.

Front: Lỗi hay gặp khi đặt tên panel là gì? Back: Dùng tên metric thô khó đọc thay vì tên gợi câu hỏi, ví dụ p95 latency toàn app.