Bốn tín hiệu vàng ai cũng nhắc, nhưng hiếm khi đo cạnh nhau trên cùng một sự cố. Tôi quét tải 1→64 client trên một dịch vụ 8 worker và đo cả bốn ở mỗi mức: saturation chạm trần ở đúng lúc độ trễ, lỗi và thông lượng còn đẹp — và định luật Little dự đoán độ trễ sau điểm bão hoà khớp trong 1,3%. Thứ tự bốn tín hiệu phản ứng mới là điều đáng nhớ.
Tôi dựng cùng một sự cố hai lần rồi tính SLI ba cách. Theo request: vi phạm nặng. Theo cửa sổ: y hệt nhau dù số người dính khác 3,6 lần. Theo độ trễ trung bình: 100% đạt, mù hoàn toàn. Câu hỏi trung tâm của SLO không phải 'đặt bao nhiêu' mà là 'tính SLI thế nào'.
Mỗi bảng điều khiển đang mở là một chuỗi truy vấn lặp lại mà không con số chi phí nào hiện lên màn hình người đang nhìn. Tôi đo trên Prometheus 21.563 chuỗi: gộp bằng sum by chỉ cắt phần trả về chứ không cắt phần đọc (nhanh hơn vỏn vẹn 1,88 lần), cái nó thật sự cứu là trình duyệt; bước là đòn bẩy lớn nhất; và chi phí nhân thẳng với số người đang mở — mười người là hơn một nhân trọn vẹn.
Prometheus nén một mẫu còn 2,16 byte, và giãn chu kỳ thu thập tiết kiệm gần tuyến tính. Nhưng giảm mẫu bằng trung bình là phép biến đổi KHÔNG đảo ngược được: một đợt chậm 939 ms bị san còn 150 ms, biểu đồ vẫn có đường, chỉ là đỉnh biến mất và không ai biết. Cách giữ đỉnh mà vẫn tiết kiệm.
Một yêu cầu đi qua bốn dịch vụ. Nhìn từ ngoài, hai sự cố khác hẳn nhau chỉ là một con số. Metric ở dịch vụ đầu bó tay, còn trace chỉ thẳng vào svc-c: tự làm 101,45 ms trong khi ba chặng kia đều quanh 10 ms. Bài học: đọc trace theo cột 'tự làm', đừng theo cột 'tổng'.
opentelemetry-sdk thật, xuất OTLP, đo cả tốc độ lẫn số byte. Con số tốc độ đúng như dự đoán. Nhưng số span THỰC SỰ tới nơi thì không: hàng đợi mặc định 2.048 làm mất gần hai phần ba trace khi dịch vụ chạy nhanh, chỉ ghi đúng một dòng log. Không lỗi, không chỉ số.