Monitoring Reliably at Scale

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

Bối cảnh

• Airbnb có hơn 1.000 service chạy trên hạ tầng chung (Kubernetes, service mesh Istio). Team Observability (nhỏ) dựng metrics platform trên chính những nền tảng đó, nên có phụ thuộc vòng: hệ để phát hiện sự cố hạ tầng lại chết theo hạ tầng; khi cần nhất thì dashboard tắt, alert im.
• Mục tiêu tự đặt: observability phải tin cậy hơn hệ nó quan sát. Giới hạn trách nhiệm rõ: chỉ bảo đảm cho khách nội bộ, không thiết kế dự phòng cho các miền lỗi bên ngoài.

Thay đổi chính

• Compute: cluster Kubernetes riêng nhưng vẫn do team Cloud vận hành. Hai cực bị loại: chạy chung cluster production (phụ thuộc vòng) và tự vận hành Kubernetes (quá nặng cho team nhỏ). Phối hợp với Cloud để mỗi lần chỉ một thay đổi lớn, thử trên cluster ít quan trọng trước.
• Mạng: tách khỏi service mesh. Theo Airbnb, traffic observability lớn hơn traffic nghiệp vụ nhiều bậc độ lớn và cần ưu tiên cao hơn; đi chung data plane thì metric của data plane phụ thuộc chính nó, và đỉnh telemetry có thể ăn capacity của traffic nghiệp vụ. Dựng tầng ingress L7 riêng trên Envoy, định tuyến theo header tenant (mỗi service một tenant, ánh xạ tới backend cụ thể); có thêm mirror metric sang đích thử nghiệm, kiểm soát truy cập chi tiết.
• Lý do tự giữ mạng mà không tự giữ compute: Kubernetes đã là nền tảng chín muồi được vận hành sẵn, thêm vài cluster là phần tăng nhỏ; còn ưu tiên và cô lập telemetry thì mesh không làm được và nằm trong chuyên môn của team.
• Meta-monitoring: một bộ Prometheus riêng giám sát chính stack observability, chạy trên node tách biệt và AZ khác, cả Prometheus lẫn Alertmanager đều theo cặp HA, không cặp nào cùng hạ tầng chung.
• Dead man's switch để tránh hồi quy vô hạn: một rule luôn bắn khi Prometheus còn scrape đúng; Alertmanager gửi liên tục tới AWS SNS; một alarm CloudWatch đo tốc độ tin đến, tắt tin thì page on-call.

Bài học cho SWE

• Vẽ đồ thị phụ thuộc của chính hệ giám sát; mọi thành phần chung với hệ được giám sát là một lỗ hổng đúng lúc sự cố (Observability và monitoring).
• Cô lập không nhất thiết là tự làm hết: chọn tách ở tầng mà nền tảng chung không đáp ứng được (mạng), dùng lại nền tảng ở tầng nó đáp ứng được (compute) (Độ tin cậy và multi-region).
• Ở tầng cuối cùng, kiểm tra bằng tín hiệu phải luôn có: im lặng mới là cảnh báo.

Liên quan

• Cùng công ty: Airbnb 2022 · Airbnb 2026
• Observability và monitoring · Độ tin cậy và multi-region · Upstash 2026