BanyanDB 0.11.2 sửa lỗi có thể làm sai bảng xếp hạng sự cố

Đội trực vận hành thường mở bảng xếp hạng lỗi để biết dịch vụ nào cần kiểm tra trước. Nếu bảng hiện ra bình thường nhưng đã đếm một phần dữ liệu hai lần và bỏ qua phần còn lại, thứ tự điều tra có thể sai ngay từ bước đầu. Trong thông báo ngày 8/11/2026, Apache SkyWalking cho biết BanyanDB 0.11.2 sửa một lỗi có thể làm sai kết quả theo cách đó. Lỗi nằm ở lúc cơ sở dữ liệu gộp kết quả lớn từ các máy tham gia xử lý.

Một bảng giám sát được dựng từ đâu?

Hãy hình dung một sàn bán hàng nhận được báo cáo rằng khách bấm thanh toán nhưng trang không phản hồi. Thay vì mở nhật ký của từng máy chủ, kỹ sư có thể hỏi hệ thống giám sát: trong mười phút qua, dịch vụ nào gặp nhiều lỗi nhất? Dữ liệu để trả lời được thu từ nhiều nơi, chẳng hạn từ máy nhận yêu cầu, dịch vụ xử lý đơn và phần mềm gọi cổng thanh toán. BanyanDB là cơ sở dữ liệu trong hệ sinh thái SkyWalking, dùng để lưu và truy vấn các dữ liệu phục vụ việc quan sát hệ thống như số đo, sự kiện theo dòng và dấu vết của yêu cầu.

Ở hệ thống phân tán, một máy thường không có toàn bộ dữ liệu. Mỗi máy có thể xử lý phần dữ liệu của mình và gửi kết quả trung gian. Một bộ phận khác gộp các phần này để trả lời truy vấn. Chẳng hạn, nếu một nhóm lỗi xuất hiện trên hai máy, lượt gộp cần cộng các lượt ghi nhận đúng nhóm. Khi đó bảng cuối cùng mới có thể sắp thứ tự theo tổng số. Việc bảng chỉ hiển thị mười dòng không có nghĩa toàn bộ phép tính trước đó chỉ xử lý mười dòng.

Vì sao có thể đếm lặp mà không báo lỗi?

Theo ghi chú phát hành của Apache, một đường xử lý truy vấn số đo bị sai nếu phần kết quả của một máy vượt 65.536 dòng. Bộ đếm dùng để chỉ vị trí dòng quay lại đầu khi qua giới hạn biểu diễn. Chương trình vẫn tiếp tục xử lý: nó đọc lại một số dòng ở đầu, trong khi những dòng đáng lẽ phải xử lý tiếp ở cuối không được đọc. Do quá trình vẫn trả về một kết quả, người xem không có cảnh báo ngay trên bảng.

Có thể hình dung một nhân viên kiểm kho đi theo danh sách đánh số. Khi hết chỗ để ghi số thứ tự, người đó trở lại trang đầu mà vẫn tưởng đang ở cuối danh sách. Nếu mặt hàng ở trang đầu vốn đã nhiều, lượng hàng của nó có thể bị thổi lên. Một mặt hàng xuất hiện ở các trang cuối có thể bị bỏ qua. Tương tự, sai số của BanyanDB không nhất thiết làm mọi nhóm tăng hoặc giảm như nhau. Một bảng vẫn có thể hiện số liệu hợp lý khi nhìn qua, nhưng thứ tự giữa các nhóm đã đổi.

Apache nêu truy vấn có thao tác Top, tức yêu cầu lấy các nhóm đứng đầu theo một chỉ số, là trường hợp có thể chạm điều kiện này. Giới hạn 65.536 ở đây nói về số dòng trung gian của một máy trong một đường xử lý cụ thể. Nó không phải số lượng dòng tối đa mà BanyanDB lưu được, cũng không phải ngưỡng mà mọi bảng SkyWalking đều bắt đầu sai. Hai đội dùng cùng phiên bản nhưng đặt truy vấn, thời gian lấy mẫu và cách chia dữ liệu khác nhau có thể không gặp cùng biểu hiện.

Bản vá đổi cách gộp dữ liệu như thế nào?

BanyanDB chia phần kết quả quá lớn thành các khối vừa với phạm vi bộ đếm, rồi tiêu thụ lần lượt. Việc chia khối giữ nguyên mục đích của truy vấn nhưng tránh cho bộ đếm quay về đầu trong một lượt xử lý. Ghi chú cũng nói giới hạn kích thước khối được áp dụng để lỗi không tái xuất hiện ở phía kết quả trả ra. Một thay đổi riêng liên quan đến truy vấn dấu vết: chương trình từ chối khởi động nếu người vận hành cấu hình khối vượt ngưỡng mà bộ chỉ mục của đường xử lý đó hỗ trợ. Trong trường hợp này, lỗi cấu hình hiện ra lúc khởi động thay vì ẩn trong kết quả về sau.

Bản phát hành còn thay đổi cách tiếp nhận một số truy vấn yêu cầu cửa sổ kết quả lớn. Đây là vấn đề khác: trước đó truy vấn có thể bị từ chối dựa vào một ước lượng, còn lỗi gộp khiến truy vấn có kết quả nhưng kết quả có thể sai. Các cơ chế giới hạn tuyệt đối, cạn tài nguyên và tính chi phí khi thực thi vẫn được duy trì theo ghi chú. Vì vậy, việc một truy vấn trước đây bị từ chối nay chạy được không phải lời bảo đảm nó sẽ nhanh hoặc nhẹ.

Đội vận hành nên xác minh lại điều gì?

Ưu tiên kiểm tra những truy vấn đang dùng để xếp thứ tự sự cố: nhóm đường dẫn có nhiều lỗi, nhóm dịch vụ có độ trễ cao, hay các báo cáo gộp dữ liệu qua nhiều cụm. Nếu có môi trường thử, hãy giữ cùng khoảng thời gian, bộ lọc và phạm vi dữ liệu rồi so kết quả trước và sau nâng cấp. Khi không thể dùng cùng dữ liệu, có thể đối chiếu một lát nhỏ với nguồn thô hoặc một phép tính độc lập. Mục tiêu là xác minh cách hệ thống xếp hạng, thay vì nhìn bảng mở thành công rồi coi như việc nâng cấp đã xong.

Kết quả mới khác kết quả cũ chưa đủ để quy toàn bộ chênh lệch cho lỗi này: dữ liệu đến trễ, chính sách lưu giữ hoặc thay đổi bộ lọc cũng có thể tác động. Điểm đáng giữ lại từ bản vá là một câu hỏi thực dụng cho bất kỳ bảng giám sát nào: với số liệu đang dùng để quyết định ưu tiên, đội vận hành có cách nào kiểm tra lại phép tính từ dữ liệu gốc? Nếu có, bảng xếp hạng vẫn là công cụ tìm hướng điều tra nhanh, và những sai lệch âm thầm cũng dễ phát hiện hơn.

Nguồn: Apache SkyWalking — ghi chú phát hành BanyanDB 0.11.2.

Ảnh minh họa: dãy máy chủ tại NERSC, ảnh Derrick Coetzee, 2011. Trang nguồn; CC0 1.0. Ảnh dùng nguyên bản.