My Awesome Project

Appearance

Chương 59: Managed Prometheus ở Quy Mô Lớn — Tối Ưu Hóa & Xử Lý Sự Cố ​

Giới thiệu ​

Chương 39 đã giới thiệu Managed Service for Prometheus (GMP) ở mức kiến trúc tổng quan: collector DaemonSet, PodMonitoring CRD, Rule Evaluator, và lợi thế global query scope so với self-hosted Prometheus. Chương đó đủ để bạn triển khai GMP đúng cách.

Chương 59 này giả định bạn đã có GMP chạy trong production, và bây giờ đối mặt với câu hỏi khó hơn: tại sao bill tháng này tăng gấp ba dù không thêm service mới? Tại sao dashboard load 15 giây rồi báo timeout? Tại sao alert không fire dù metric rõ ràng đã vượt ngưỡng?

Đây là những câu hỏi không thể trả lời bằng cách đọc lại PodMonitoring reference. Chúng đòi hỏi hiểu Monarch — hệ thống lưu trữ nội bộ của Google mà GMP xây dựng trên đó — vận hành ra sao ở tầng dưới: dữ liệu được shard thế nào, một query fan-out qua bao nhiêu tầng, "active time series" thực sự nghĩa là gì đối với billing, và tại sao high cardinality không chỉ là vấn đề cost mà còn là failure mode có thể làm sập toàn bộ pipeline ingest của một service.

Theo tài liệu chính thức, mục tiêu thiết kế của GMP là "get global monitoring at scale" bằng cách để mọi truy vấn PromQL chạy trực tiếp trên Monarch thay vì trên local Prometheus server (Query using the Prometheus API or UI). Điều này là lợi thế lớn nhất của GMP, nhưng cũng là nguồn gốc của gần như mọi failure mode được thảo luận trong chương này — vì bạn không còn kiểm soát local storage, bạn đang chia sẻ một hệ thống multi-tenant khổng lồ.

Điều kiện tiên quyết ​

Cấu trúc chương ​

1. Kiến trúc Monarch & GMP ở Quy Mô Toàn Cầu ​

Đào sâu vào Monarch — root mixer, zone mixer, leaf — và cách kiến trúc ba tầng này quyết định latency, consistency, và giới hạn của mọi query GMP. Giải thích sự khác biệt giữa managed collection và self-deployed collection, và tại sao lựa chọn này ảnh hưởng đến toàn bộ phần còn lại của chương.

2. PodMonitoring CRD: Cấu Hình Nâng Cao & Kiểm Soát Scrape ​

Cơ chế bên trong của ScrapeEndpoint, metricRelabeling pipeline, và field limits (sampleLimit, labelLimit, labelNameLengthLimit, labelValueLengthLimit) như một cơ chế phòng thủ ở tầng scrape. Phân tích tại sao protected target labels tồn tại và hệ quả khi vi phạm chúng.

3. Rule Evaluator: Recording Rules & Alert Evaluation Ở Quy Mô ​

Cách Rule Evaluator — một Deployment single-replica — evaluate Rules, ClusterRules, GlobalRules khác nhau ra sao về scope và reliability. Giải thích cơ chế fan-in của kết quả rule trở lại Monarch, và tại sao label cluster/namespace không nên bị aggregate away.

4. High Cardinality & Label Explosion: Cơ Chế Vỡ Ở Tầng Nào ​

Giải phẫu chính xác cardinality explosion xảy ra ở đâu trong pipeline — từ metric descriptor đến time series đến Monarch leaf shard. Bao gồm cơ chế "Monarch Quarantiner" và hiện tượng monitored resource có quá nhiều time series.

5. Chi Phí Ingestion & Mô Hình Billing Active Time Series ​

Mô hình billing theo sample, công thức tính chi phí từ scrape interval và cardinality, và cách dùng trang Metrics Management để quy trách nhiệm chi phí (cost attribution) theo namespace, workload, metric type.

6. Tối Ưu Hóa PromQL: Query Nào Đắt, Vì Sao ​

Cơ chế thực thi PromQL trên Monarch — tại sao subquery, long-range rate(), và ratio query dễ gây timeout hoặc bị quarantine bởi giới hạn concurrent query per project. Kỹ thuật tách numerator/denominator, dùng offset, và pre-aggregate bằng recording rule.

7. Thay Thế Vai Trò Của Thanos: Self-Deployed Collector & Retention ​

Vì sao GMP không hỗ trợ federation server hay remote-write receiver — và tại sao đây là quyết định thiết kế đúng đắn, không phải thiếu sót. Cách self-deployed collector với local aggregation thay thế hoàn toàn nhu cầu chạy Thanos, và cơ chế retention/downsampling thực tế của Monarch.

8. Troubleshooting Runbook: Query Timeout, Cardinality, Ingestion Failure ​

Runbook có cấu trúc: bắt đầu từ metric up, phân nhánh query-side vs ingestion-side, danh mục lỗi thực tế kèm nguyên nhân gốc và lệnh chẩn đoán cụ thể.

Tư duy quan trọng xuyên suốt chương ​

GMP che giấu vận hành hạ tầng (không còn phải patch Prometheus, quản lý PVC, cấu hình Thanos sidecar), nhưng không che giấu vật lý của cardinality. Một time series vẫn là một time series dù bạn tự vận hành Prometheus hay dùng GMP — điều thay đổi là ai trả giá cho nó và ai nhìn thấy triệu chứng đầu tiên. Với self-hosted Prometheus, triệu chứng là OOM của Prometheus Pod. Với GMP, triệu chứng là hóa đơn tăng đột biến hoặc lỗi RESOURCE_EXHAUSTED xuất hiện âm thầm vài tuần sau khi ai đó thêm một label user_id vào một metric.

Mục tiêu của chương này là giúp bạn nhìn xuyên qua lớp "managed" để thấy cơ chế thật — vì chỉ khi hiểu Monarch shard dữ liệu thế nào, bạn mới biết vì sao một aggregation query chậm, vì sao label nào an toàn để giữ và label nào phải drop ngay tại collector.

Tham khảo chính thức ​