Scaling Production Globally: Solving observability problems for developers (Part-2)

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

Phần 2 của series; phần 1 (service mesh Istio đa region): Achievers 2022. Lấy từ bản Wayback (Medium chặn crawler).

Bối cảnh

• Sau khi đưa Istio lên nhiều cluster ở nhiều region (phần 1), lượng metric tăng mạnh. Achievers dùng New Relic làm "single pane of glass" cho cả nền tảng phân tán.
• Trước đó chỉ team SRE trực cho độ tin cậy của nền tảng; giờ engineer sở hữu service của mình trên production, nhiều team mới chưa biết bắt đầu observability từ đâu.

Thay đổi chính

• Chọn ít metric để bắt đầu: từ metric Prometheus của Istio chỉ lấy vài cái (istio_requests_total, istio_request_duration_milliseconds, kích thước request/response), lọc theo workload và cluster nguồn/đích để thấy request đi xuyên cluster. Bắt đầu với hai trong bốn golden signals: availability (tỉ lệ thành công) và latency, so giữa các cluster.
• Chi phí metric: giữ Prometheus cục bộ trong cluster cho điều tra tại chỗ, chỉ gửi metric được chọn lên New Relic; không tắt hẳn metric chưa dùng, nhưng không cho ra khỏi cluster; giảm sample rate ở môi trường non-production.
• Mặc định cho mọi service: công cụ self-service của SRE (Abattoir) tự sinh dashboard cho từng service (lỗi, error log, pod hỏng, trang Istio riêng) và bộ alert mặc định theo golden signals; developer có thể tắt hay viết policy riêng. Ví dụ từ phần 1: dashboard mặc định dẫn tới lỗi 503 upstream_reset_before_response_started do Node.js không tắt êm khi nhận SIGTERM, thứ APM (chỉ thấy tầng ứng dụng) bỏ sót.
• SLO và error budget trong New Relic, bắt đầu bằng availability rồi latency. Product owner tham gia đặt SLO và cam kết chậm hay dừng làm tính năng khi SLO không đạt. Khẩu hiệu nội bộ: mọi người sở hữu độ tin cậy, không riêng SRE.
• Canary có phân tích: Argo Rollouts truy vấn New Relic để quyết định canary có gây lỗi không, tự rollback; developer chọn từ thư viện template phân tích dựng sẵn hoặc tự viết. Có thể dùng traffic shaping của Istio cho canary theo mạng.

Vì sao

• Khi chuyển từ "SRE trực tất cả" sang "team tự sở hữu", cách nhanh nhất để team mới có observability là mặc định hợp lý do nền tảng sinh sẵn, thay vì mỗi team tự dựng.

Bài học cho SWE

• Metric ở tầng mesh thấy được lỗi mạng mà APM không thấy; dùng cả hai (Observability và monitoring).
• Không gửi mọi metric lên hệ trung tâm tính tiền theo lượng; giữ cục bộ phần ít dùng.
• Dashboard và alert mặc định, có lối thoát cho team muốn tuỳ biến, là cách SRE nhân rộng thực hành khi không đủ người (Mô hình tổ chức SRE).
• SLO chỉ có tác dụng khi phía sản phẩm đồng ý đánh đổi tốc độ tính năng khi hết error budget.
• Đưa cùng nguồn metric vào phân tích canary để rollback tự động (Deploy và release an toàn).

Liên quan

• Cùng công ty: Achievers 2022
• Observability và monitoring · Mô hình tổ chức SRE · Deploy và release an toàn