DevOps 02/09/2026 9 phút

Biểu đồ máy chủ ghi 0,673 ms trong khi người dùng chờ 151 ms tải trang — không ai nói dối, họ chỉ đang trả lời ba câu hỏi khác nhau

Máy chủ tự báo 0,673 ms, người dùng thật chờ 151,255 ms — nó mù 99,6% thời gian. Tôi đo khoảng cách đó khi thêm độ trễ mạng, và phát hiện kích thước phản hồi chỉ lộ ra khi có độ trễ (chênh 2,2% trên mạng nhanh thành 128% khi thêm 50 ms), còn keep-alive tiết kiệm đúng một vòng khứ hồi. Ba con số trong bảng là ba đại lượng khác nhau, không phải ba mức chính xác của một đại lượng.

DevOps 02/09/2026 9 phút

Dịch vụ của tôi chết 5 phút lúc 2 giờ sáng và giám sát thụ động bỏ sót 54% số lần — vì lúc đó 305/500 phút không có một request nào

Giám sát thụ động chỉ thấy lỗi khi có ai đó gặp lỗi. Tôi đo khoảng cách của nó so với kiểm tra tổng hợp: ban ngày hai cách ngang nhau, nhưng ban đêm — giờ không ai dùng — thụ động bỏ lọt hơn nửa số sự cố ngắn. Toàn bộ giá trị của synthetic check nằm ở đúng cái khoảng trống lưu lượng đó.

DevOps 02/09/2026 9 phút

Tôi đoán hàm này ăn 70% CPU — chính tay tôi viết nó — hai phép đo nói 90,7% và 98,3%; và py-spy đo được điều đó gần như miễn phí

Lấy mẫu hồ sơ ngoài tiến trình ở 99 Hz gần như không tốn gì (−0,8%), nên bật được suốt ngày ở production; còn cProfile làm chương trình chậm gấp 2,06 lần và tự tạo sự cố hiệu năng. Nhưng bài học lớn nhất là con số tôi đoán sai về mã của chính mình — thời gian chạy không tỷ lệ với số dòng.

DevOps 02/09/2026 9 phút

Bật cả log, chỉ số và trace lấy đi 12,9% thông lượng — nhưng một lớp sinh 10,8 GB/ngày còn lớp kia chỉ 7,2 MB, chênh 1.540 lần

Tôi cộng cả ba lớp quan sát trên cùng một dịch vụ và đo tổng: −12,9% thông lượng, +19,3% CPU, +45,8% bộ nhớ. Nhưng phát hiện quan trọng hơn con số tổng là mô hình chi phí — chỉ số giữ trạng thái gộp nên KHÔNG tỷ lệ với lưu lượng (1.312 byte dù 20 nghìn hay 20 triệu yêu cầu), còn log và trace ghi từng sự kiện nên phình tuyến tính. Cùng lượng việc, trace tốn gấp 1.540 lần chỉ số.

DevOps 02/09/2026 8 phút

Bốn cách viết truy vấn Prometheus sai mà không hề báo lỗi — một trong đó thổi con số lên gấp 3,44 lần, một cái giấu mất 75% chiều cao đỉnh

Bốn lỗi bảng điều khiển tôi gặp thường xuyên nhất, đo bằng chính Prometheus: cửa sổ rate quá ngắn cho biểu đồ trống, rate(sum()) thay vì sum(rate()) cho con số cao 3,44 lần, vẽ counter thô, và step lớn hơn cửa sổ rate giấu 75% đỉnh. Điểm chung đáng sợ: không cái nào sinh ra lỗi — biểu đồ vẫn vẽ, truy vấn vẫn trả 200.

DevOps 02/09/2026 9 phút

Giữ chỉ số một năm không làm dashboard hằng ngày chậm đi một mili-giây — đòn bẩy chi phí thật không phải thời gian giữ, mà là chu kỳ thu thập

Dung lượng tăng tuyến tính theo thời gian giữ, nhưng chi phí truy vấn thì DƯỚI tuyến tính — giữ lâu chỉ làm hoá đơn dài ra, không làm bảng điều khiển chậm. Và đòn bẩy tiết kiệm lớn nhất (15 lần) là chu kỳ thu thập, không phải rút thời gian giữ. Quyết định 'giữ bao lâu' hoá ra hoàn toàn là quyết định về giá trị, không phải kỹ thuật.