Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
Kafka phát ra hàng trăm chỉ số qua JMX. Tôi dựng một sự cố thật — consumer treo, dữ liệu ngừng chảy tới hạ nguồn — rồi xem chỉ số nào báo: broker báo hoàn toàn khoẻ suốt cả phút. Bài này chỉ ra bốn chỉ số broker thật sự đáng cảnh báo, và ba chỉ số phía client mới là thứ nói cho bạn biết đường ống có đang chạy hay không.
Sơ đồ kiến trúc Kubernetes thì ở đâu cũng có. Tôi làm khác: tắt từng thành phần một trên cụm đang chạy rồi đo cái gì hỏng. Kết quả đáng nhớ nhất — mất control plane, mọi thứ vẫn chạy y như thường, cho tới đúng lần tiếp theo có một pod chết mà không ai thay nó. Và apiserver nặng gần gấp năm lần etcd.
Bản sao lưu hàng đêm chỉ đưa bạn về nửa đêm hôm qua. Khôi phục theo thời điểm đưa bạn về một giây trước khi ai đó gõ nhầm — nhưng chỉ khi bạn đã chuẩn bị trước tai nạn. Tôi chạy đủ quy trình từ đầu đến cuối, và cho thấy đặt mốc sai thì nó im lặng đưa bạn về nhầm chỗ.
Sau năm mươi ba phần đo từng cơ chế, phần này đo cách tìm ra chỗ nào đáng đo. Kết quả đầu tiên đã đủ giật mình: cách xếp hạng phổ biến nhất — theo thời gian mỗi lần — dẫn thẳng tới việc tối ưu nhầm truy vấn, bỏ qua đúng câu đang chiếm nhiều tài nguyên nhất.
Kafka hay bị gọi là hàng đợi tin nhắn, và cái tên đó đẻ ra phần lớn hiểu nhầm. Tôi đo đặc tính thật sự định nghĩa nó: đọc không xoá tin, ba nhóm cùng đọc đủ. Và 493.421 tin mỗi giây không đến từ 'mỗi tin nhanh' — bỏ gộp lô thì mỗi tin nhanh gấp 34 lần mà thông lượng sụp đổ.
Một broker Kafka thật ra khởi động 2 giây, chiếm 290 MB — nhẹ hơn hẳn tiếng tăm của nó. Nhưng thứ khiến tôi dừng lại là một cái bẫy đo lường: công cụ dòng lệnh tốn 0,86 giây trong khi gửi tin thật chỉ mất 0,89 mili giây. Chênh nhau một nghìn lần, và rất nhiều người đo trúng cái sai.