Infrastructure monitoring with Prometheus

Bài tóm tắt Zerodha 2020 3. Quy mô lớn Độ khó: Trung bình

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

Bối cảnh

  • Năm 2020 Zerodha xử lý khoảng 15% khối lượng giao dịch bán lẻ hằng ngày trên các sàn ở Ấn Độ; tự host gần như mọi phụ thuộc (CRM, database lớn, Kafka, mail server).
  • Hạ tầng lai: rack vật lý ở hai data center (nơi đường leased line của sàn kết thúc) và AWS, nối với VPC bằng đường P2P; workload từ bare metal tới cụm Kubernetes, cần giám sát độc lập.

Thay đổi chính

  • Prometheus (đã so với Sensu, Nagios, ELK) vì mô hình label và PromQL. Service discovery: ec2_sd_config cho AWS, static_config cho bare metal (IP tĩnh).
  • Trong Kubernetes: kube-state-metrics xuất metadata khoảng 30 loại tài nguyên, nên cần thứ chịu được hàng trăm triệu data point đang hoạt động trên mọi cụm. Storage cục bộ của Prometheus không phân cụm, không nhân bản, nên cần long-term storage chung qua remote write.
  • Xét Thanos nhưng theo Zerodha quá nhiều thành phần, vận hành nặng không cần thiết; chọn VictoriaMetrics (một binary, lúc đó còn mới) vì tin tác giả chính qua các dự án Go khác và benchmark ghi tốt, ít RAM/đĩa. Prometheus ghi đĩa cục bộ và song song đẩy remote; WAL giữ dữ liệu khi remote không sẵn sàng. Khoảng 56 tỉ data point sau dọn theo retention, ingest hàng chục nghìn series mỗi giây (2020); Grafana dùng VictoriaMetrics như datasource Prometheus, truy vấn gộp xuyên cụm.
  • Cấu hình xuyên cụm: Prometheus Operator; Kustomize với base dùng chung và overlay theo cụm (số replica, endpoint remote, Alertmanager ngoài cụm). Mỗi Prometheus gắn externalLabels (zero_cluster: eks-cluster-dev) để metric hai cụm không trùng nhau khi gom về một kho.
  • Alertmanager tập trung cho mọi Prometheus, khử trùng alert; đẩy sang Google Chat bằng công cụ tự viết. Rule và cấu hình alert nằm trong repo GitLab; CI lint, kiểm rồi đẩy lên S3, một sync server trên cụm Alertmanager tự reload khi có cấu hình mới.
  • Exporter tự viết: store-exporter lấy dữ liệu từ PostgreSQL/MySQL thành metric để vẽ và alert theo bất thường nghiệp vụ; exporter HTTP nhúng cho metric RED; exporter đọc API AWS (băng thông và sức khoẻ đường P2P, chính sách snapshot EBS).

Vì sao

  • Theo Zerodha: giữ ít phụ thuộc ở ứng dụng quan trọng, và chọn thành phần vận hành đơn giản (một binary) hơn kiến trúc nhiều mảnh.

Bài học cho SWE

  • Khi gom metric nhiều cụm về một kho, nhãn nguồn (cluster) phải gắn ở nơi phát, không thì dữ liệu hai nơi lẫn vào nhau mà không báo lỗi.
  • Alert as code đi qua CI như mọi cấu hình khác: lint, kiểm, phát hành, tự reload.
  • Metric nghiệp vụ lấy thẳng từ database cho phép alert theo bất thường kinh doanh, không chỉ theo tài nguyên máy.

Liên quan