Xây dựng Hệ thống Tổng hợp Kiểm tra Sức khỏe Đa vùng (Multi-Region Health-Check Aggregator)
Một người dùng ở São Paulo truy cập vào một edge node bị lỗi. Họ không gửi báo cáo lỗi. Họ đóng tab và đi xem thứ khác.
Một trình giám sát uptime thông thường sẽ bỏ lỡ điều này. Hầu hết các trình giám sát đều thực hiện kiểm tra (probe) từ một vị trí duy nhất. Từ vị trí đó, mọi thứ trông vẫn có vẻ ổn.
Trang trạng thái của chúng tôi từng hiển thị uptime 100% trong khi người dùng thực tế lại gặp tình trạng timeout. Một trình kiểm tra sức khỏe toàn cầu duy nhất đã đánh lừa chúng tôi.
Đây là cách chúng tôi xây dựng một hệ thống nói lên sự thật.
Vấn đề: Thành kiến lấy mẫu (Sampling Bias) Nếu trình giám sát của bạn nằm trong một trung tâm dữ liệu, nó chỉ thấy được một thực tế duy nhất. Bạn có thể báo cáo trạng thái vẫn ổn ngay cả khi các edge tại Singapore và São Paulo đang bị mất kết nối.
Lưu lượng video khiến vấn đề này trở nên tồi tệ hơn. Các lỗi khu vực phổ biến bao gồm:
- Các tuyến BGP lỗi ảnh hưởng đến một châu lục.
- Việc xóa cache (cache evictions) buộc phải fallback về origin chậm chạp.
- Lỗi đĩa gây ra tình trạng timeout khi bắt tay TLS (TLS handshake).
- Các vấn đề DNS tại các bộ phân giải (resolvers) cục bộ cụ thể.
Một phản hồi "200 OK" duy nhất gần như không cho bạn biết được điều gì.
Ba quy tắc về Sức khỏe của chúng tôi: Chúng tôi đã vượt xa các mã trạng thái (status codes). Chúng tôi định nghĩa sức khỏe dựa trên ba chỉ số:
- Khả năng tiếp cận (Reachability): Các bước bắt tay TCP và TLS phải hoàn tất trong vòng 800ms.
- Độ trễ (Latency): Chúng tôi theo dõi p95 Time-to-First-Byte (TTFB). Các giá trị trung bình thường che lấp "phần đuôi" chậm chạp (slow tail) gây khó chịu cho người dùng.
- Tính chính xác (Correctness): Thân phản hồi (response body) phải chứa một dấu hiệu (marker) dự kiến. Một phản hồi 200 OK nhưng lại trả về trang lỗi thì vẫn bị coi là thất bại.
Giải pháp: Kiểm tra Đa vùng (Multi-Region Probing) Chúng tôi đã ngừng sử dụng một trình giám sát lớn duy nhất. Thay vào đó, chúng tôi triển khai các tệp thực thi Go (Go binaries) nhỏ gọn lên các máy chủ VPS khu vực giá rẻ.
Mỗi trình kiểm tra (prober):
- Kiểm tra các edge từ một điểm quan sát cục bộ.
- Sử dụng
httptraceđể lấy dữ liệu TTFB thực tế. - Gửi kết quả về một bộ tổng hợp trung tâm.
Chúng tôi sử dụng SQLite để lưu trữ. Nó đơn giản và xử lý khối lượng công việc của chúng tôi mà không tốn nhiều tài nguyên (zero overhead). Chúng tôi lưu trữ các mẫu thô (raw samples) thay vì dữ liệu đã được tổng hợp trước. Điều này cho phép chúng tôi tính toán lại điểm số lịch sử hoặc gỡ lỗi các lỗi cụ thể sau này.
Bí mật: Quorum Mạng lưới luôn có nhiễu. Một gói tin bị mất không có nghĩa là một sự cố ngừng hoạt động (outage).
Chúng tôi sử dụng hệ thống quorum để ngăn chặn các cảnh báo giả. Chúng tôi chỉ tuyên bố một edge bị "down" khi nhiều khu vực cùng đồng thuận. Nếu một khu vực thấy lỗi nhưng các khu vực khác thì không, chúng tôi sẽ không gửi thông báo (page) cho đội ngũ. Lựa chọn thiết kế này đã loại bỏ 90% các cảnh báo giả của chúng tôi.
Các bài học chính:
- Kiểm tra những gì người dùng thực sự truy cập, chứ không phải một đường dẫn giả lập (synthetic path).
- Theo dõi độ trễ phần đuôi (p95), thay vì giá trị trung bình.
- Sử dụng các trình kiểm tra (probers) giá rẻ, có thể thay thế dễ dàng ở nhiều khu vực.
- Sử dụng quorum để tránh tình trạng quá tải cảnh báo (pager fatigue).
- Giữ cho ngăn xếp lưu trữ (storage stack) của bạn đơn giản.
Bạn không cần một nền tảng quan sát cồng kềnh. Bạn cần các probe cục bộ, dữ liệu thô, và một quy tắc không cho phép sự hoảng loạn trước các tín hiệu nhiễu.