Scaling Prometheus to billions of samples a second
Bài tóm tắt Hudson River Trading 2021 3. Quy mô lớn Độ khó: Trung bình
Hudson River Trading · 2021 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc
Bối cảnh
- HRT dùng Prometheus làm thành phần chính để giám sát hạ tầng toàn cầu, cả metric host lẫn metric service, cho môi trường giao dịch live và cụm nghiên cứu. Một instance scale lên rất xa nhưng vẫn có trần phần cứng.
- Hai cách scale cộng đồng khuyên: federation (mỗi DC/service một instance, một instance "global" gom một phần dữ liệu) và sharding (gom lại cũng qua federation). Một instance mỗi DC hợp với môi trường giao dịch phân tán, nhưng không hợp với một cụm nghiên cứu lớn; federation lại mất khả năng tổng hợp ad-hoc trên toàn bộ dữ liệu, vì chỉ query được phần đã kéo về instance global.
Thay đổi chính
- Sharding + remote read: hai loại instance. Shard chỉ lo scrape và ingest, nhiều shard hợp lại thành bộ dữ liệu đầy đủ. Query node không scrape gì, chỉ đọc remote từ các shard và chạy query, recording rule, alert.
- Recording rule cực lớn (ví dụ CPU của cả cụm nghiên cứu, mà ngay cả query tức thời cũng timeout): mỗi shard chạy rule trên phần dữ liệu của mình, gắn nhãn tạm
shard; query node tổng hợp lại và bỏ nhãn. - HA: mỗi server có bản đôi; Consul giữ pool cho query node và cho từng cặp shard, health check tự loại host chết. Thêm storage chịu hỏng ổ, snapshot từ xa.
- Đọc remote đồng thời: query ban đầu chậm hơn đọc local; HRT đề xuất và cùng cộng đồng làm tính năng đọc nhiều nguồn remote song song (upstream). Giờ nút cổ chai là shard trả chậm nhất.
Vì sao
- Ingest scale theo số server thay vì theo tài nguyên còn lại của một máy: câu hỏi chuyển từ "nâng phần cứng được không" sang "rack server mới ở đâu", thêm server không gây downtime.
- Khởi động lại nhanh hơn: replay WAL từng vượt một giờ, giờ chia theo số shard; query node không có WAL.
- Cái giá (theo bài): cấu hình phức tạp, nhiều điểm hỏng hơn, quản lý rule shard tinh vi; remote read thiếu passthrough
/targets,/labelsnên UI không gợi ý tự động. - 2021: khoảng 150 triệu series khác nhau, vẫn query ad-hoc được trên tất cả.
Bài học cho SWE
- Chọn cách scale theo kiểu truy vấn: nếu cần tổng hợp toàn cục ad-hoc, federation không đủ.
- Tách vai trò ingest và query; tính trước phần nặng ở từng shard rồi gộp.
- Khi chia nhỏ để scale, đi kèm HA cho từng mảnh, vì mất một shard là mất một phần dữ liệu.
Liên quan
- Hudson River Trading 2025 (HRT sau này dùng VictoriaMetrics) · Two Sigma 2019 · Zerodha 2020
- Observability và monitoring
#Prometheus#federation#sharding#remote read#query node#recording rule#shard label#WAL replay#Consul#HA pair#concurrent remote read#150 million series
Được nhắc tới trong
Chủ đề (1)
Công ty (1)
Bài tóm tắt (3)