Splunk at Zillow

Zillow · 2015 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài recap hai talk tại Seattle Splunk User Group. Phần một là extension của Splunk (lệnh f5query, getsnow truy vấn F5 và ServiceNow mà không ingest dữ liệu); ghi chú dưới đây tập trung phần hai về xếp hạng lỗi.

Bối cảnh

• Sau vài năm ship liên tục, lỗi chỉ tăng: một service tầng trình bày sinh hơn 4 triệu lỗi/ngày, khoảng 20.000 loại lỗi (2015), phần lớn không cần xử lý. Giám sát service này chỉ dựa vào số lượng lỗi, nên lỗi thật chìm trong nhiễu.
• Cách thử đầu: theo dõi phân bố lỗi theo "dấu câu" (dạng thông điệp) và báo khi lệch; thất bại vì mỗi lần deploy làm phân bố đổi, không dùng được ở môi trường test, không tính mùa vụ.

Thay đổi chính

• Định nghĩa một chỉ số trải nghiệm người dùng, Factor X, gộp lỗi Apache, URL hỏng, latency cao..., lấy mẫu mỗi giây và đo từ phía khách hàng.
• Mỗi lỗi service (dạng chuẩn hoá) ghi vào một DB trong bộ nhớ hàng tỷ dòng; mỗi phút, với từng loại lỗi, lấy trung bình Factor X trong cửa sổ −1 s/+29 s quanh các lần lỗi đó xuất hiện (window join). Loại lỗi nào luôn đi cùng Factor X tăng vọt thì mức nghiêm trọng cao.
• Xếp hạng bằng Wilson score để tính độ tin cậy theo số lần xuất hiện; một lần trùng hợp ngẫu nhiên với sự cố khác bị trung bình hoá đi.
• Kết quả tra trong Splunk vài giây: danh sách lỗi đang ảnh hưởng khách nhiều nhất.

Vì sao

• Mức nghiêm trọng của lỗi nên đo bằng tác động lên người dùng, không bằng số lượng (Observability và monitoring).
• Đo từ phía khách nên không bị ảnh hưởng khi một server bị rút khỏi pool để deploy.

Bài học cho SWE

• Khi lỗi quá nhiều để đọc, xếp hạng theo tương quan với một chỉ số trải nghiệm thay vì theo tần suất.
• Ngưỡng dựa trên phân bố lỗi sẽ gãy mỗi lần deploy; cần tín hiệu ổn định hơn mà deploy không làm đổi.

Liên quan

• Zillow 2018 · Zillow 2021
• Observability và monitoring