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ớ.
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.
Thêm hai nhãn 'vô hại' biến 1.000 chuỗi thành 20.000. Và 50.000 giá trị nhãn ăn 1,3 GB RAM của Prometheus.
Ngưỡng tức thời báo giả 50 lần cho 3 sự cố thật. Nhưng lỗi không nằm ở quy tắc — nó nằm ở mẫu quá nhỏ.
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'.
Bản thân cụm Kubernetes cũng là một nguồn phát chỉ số, và nó phát ngay cả khi bạn chưa triển khai gì. Tôi đo: 187 chuỗi/pod tuyến tính hoàn hảo, kể cả pod pause chẳng làm gì. Và một bất ngờ — xoá sạch một namespace để lại 4.580 chuỗi control plane không bao giờ co lại (nhưng nó bão hoà).