Thay Thế Vai Trò Của Thanos: Self-Deployed Collector & Retention
Vì sao đặt câu hỏi "tích hợp Thanos với GMP" là sai câu hỏi
Với một tổ chức đã quen self-hosted Prometheus ở quy mô nhiều cluster, Thanos (hoặc Cortex) thường là thành phần bắt buộc để giải quyết ba vấn đề: (1) global query xuyên cluster, (2) long-term retention vượt quá giới hạn local disk của Prometheus, (3) high availability giữa các Prometheus replica. Khi tiếp cận GMP, phản xạ tự nhiên là hỏi "làm sao tích hợp Thanos vào đây" — nhưng đây là câu hỏi sai, vì cả ba vấn đề Thanos giải quyết đã được kiến trúc Monarch giải quyết sẵn ở tầng nền tảng, theo cách khác hẳn.
Global query đã được giải quyết bởi chính root mixer fan-out ra mọi zone thuộc metrics scope — đây chính là nội dung file 01. Long-term retention được Monarch xử lý bằng chính sách downsample tự động (chi tiết ở phần dưới), không cần một tầng object storage riêng như Thanos dùng GCS/S3. High availability giữa nhiều collector replica được giải quyết bằng cơ chế leader election riêng của binary export (--export.ha.backend=kube), không cần Thanos Query dedupe hai luồng Prometheus HA pair.
Vì vậy, thay vì "tích hợp Thanos", câu hỏi đúng là: những gì Thanos từng làm cho bạn, phần nào GMP đã tự làm, và phần nào bạn cần tái tạo bằng self-deployed collector?
Phát hiện quan trọng nhất: GMP không hỗ trợ federation
Đây là điểm dễ vi phạm nhất khi migrate một kiến trúc Thanos hiện có sang GMP. Tài liệu chính thức nêu rõ ràng, không mập mờ: "Managed Service for Prometheus does not support exporting metrics from a federation server or from a server used as a remote-write receiver" (Get started with self-deployed collection). Nghĩa là nếu kiến trúc cũ của bạn có một Prometheus "federation server" gom dữ liệu từ nhiều Prometheus con qua endpoint /federate rồi export dữ liệu đã gom đó vào GMP, đây là anti-pattern bị từ chối tường minh, không phải một cấu hình chưa tối ưu.
Nguyên nhân sâu xa nằm ở chính khác biệt data model: endpoint /federate chỉ trả về snapshot giá trị tại thời điểm scrape, không mang theo # TYPE metadata gốc của Prometheus (Counter, Gauge, Histogram). Khi GMP nhận dữ liệu không có TYPE metadata, nó không thể phân loại đúng metric kind, dẫn đến hàng loạt triệu chứng đã ghi nhận trong tài liệu troubleshooting: "Missing counter data, broken histograms, metric names bị gắn hậu tố unknown/unknown:counter". Đây không phải bug ngẫu nhiên — nó là hệ quả tất yếu của việc federation phá vỡ chuỗi truyền metadata mà GMP cần để ánh xạ đúng vào mô hình dữ liệu Monarch.
Cách sửa chính thức không phải là "tìm cách làm federation hoạt động" mà là loại bỏ hoàn toàn tầng federation, thay bằng: mỗi cluster chạy collector/self-deployed Prometheus của riêng nó, export thẳng vào Monarch; câu hỏi "tổng hợp xuyên cluster" được trả lời bằng PromQL query trực tiếp trên GMP (tận dụng global query scope), không cần một tầng gom trung gian nào nữa.
Self-deployed collector: công cụ tái tạo local aggregation mà managed collection không có
File 01 đã giới thiệu self-deployed collection như chế độ thay thế managed collection khi cần quyền kiểm soát sâu hơn. Ở đây ta cần làm rõ chính xác trường hợp nào bắt buộc phải dùng self-deployed thay vì managed — vì đây là công cụ duy nhất chính thức được công nhận để thay thế vai trò "cuộn dữ liệu trước khi xuất ra ngoài" mà Thanos/federation từng đảm nhiệm.
Với managed collection, bạn chỉ có metricRelabeling ở tầng scrape (giữ/bỏ theo tên metric hoặc label, đã nói ở file 02) — không có khả năng chạy một recording rule cục bộ để tính toán lại dữ liệu (ví dụ tổng hợp bỏ label instance) trước khi nó rời cluster. Với self-deployed collector, bạn có toàn quyền recording rule local:
groups:
- name: local_rollup
rules:
- record: job:high_cardinality_metric_1:sum
expr: sum without (instance) (high_cardinality_metric_1)Sau đó dùng flag --export.match để chỉ xuất ra bản đã rollup, chặn hoàn toàn metric gốc cardinality cao rời khỏi cluster:
--export.match='{__name__!="high_cardinality_metric_1",__name__!="high_cardinality_metric_2"}'Tài liệu lưu ý cơ chế logic của nhiều flag --export.match: điều kiện bên trong cùng một flag được AND với nhau, còn các flag riêng biệt được OR với nhau — một chi tiết dễ hiểu nhầm dẫn đến filter sai nếu không đọc kỹ. Đây chính xác là kỹ thuật thay thế cho việc "Thanos sidecar tổng hợp dữ liệu trước khi upload lên object storage" — chỉ khác là điểm tổng hợp diễn ra tại chính self-deployed Prometheus trong cluster, trước khi export, thay vì tại một tầng Thanos riêng biệt.
Chi phí phải trả khi chọn self-deployed
Đổi lại quyền kiểm soát này, tài liệu chính thức nêu rõ hai đánh đổi: (1) chi phí resource — khuyến nghị tăng CPU/memory limit gấp 5 lần so với Prometheus tiêu chuẩn để bù cho tầng xử lý export thêm; (2) mức hỗ trợ — "Google Cloud technical support provides limited assistance for self-deployed collection", nghĩa là bạn chịu trách nhiệm vận hành gần như toàn bộ, GMP chỉ còn là nơi lưu trữ đầu ra cuối cùng.
HA mode: cách self-deployed thay thế Thanos Query dedupe
Với Prometheus HA pair truyền thống, Thanos Query đảm nhiệm việc dedupe hai luồng dữ liệu trùng lặp từ hai replica. Trên GMP, cách tiếp cận khác hẳn và đơn giản hơn: binary export hỗ trợ cờ --export.ha.backend=kube, dùng cơ chế leader election qua Kubernetes để đảm bảo chỉ một trong nhiều replica thực sự export dữ liệu ra Monarch tại một thời điểm — loại bỏ nhu cầu dedupe ở tầng query hoàn toàn, vì dữ liệu trùng lặp không bao giờ được ghi vào Monarch ngay từ đầu. Đây là khác biệt triết lý quan trọng: Thanos giải quyết trùng lặp sau khi dữ liệu đã tồn tại (dedupe tại thời điểm query); GMP self-deployed giải quyết trùng lặp trước khi dữ liệu được ghi (leader election tại thời điểm export).
Ví dụ di trú cụ thể: từ kiến trúc Thanos federation sang GMP
Để cụ thể hóa khác biệt kiến trúc, hãy xét một tổ chức đang vận hành mô hình phổ biến trước GMP: mỗi cluster có một Prometheus riêng, một Thanos sidecar đẩy block dữ liệu lên GCS, một Thanos Query đứng trước tất cả để trả lời câu hỏi xuyên cluster, và một Prometheus "global" chạy federation kéo vài metric tổng hợp từ các cluster con về để alerting tập trung.
Trước (Thanos):
Cluster A: Prometheus → Thanos Sidecar → GCS
Cluster B: Prometheus → Thanos Sidecar → GCS
↓
Thanos Query (đọc GCS + Prometheus trực tiếp)
↓
Global Prometheus (federate 1 vài metric quan trọng)
↓
Alertmanager tập trungSau (GMP), theo đúng khuyến nghị chính thức là loại bỏ hoàn toàn tầng federation:
Cluster A: Collector (managed) → Monarch
Cluster B: Collector (managed) → Monarch
↓
PromQL query trực tiếp trên Monarch, filter theo cluster/project khi cần
(không cần Thanos Query, không cần Prometheus "global" federate)Ba thay đổi kiến trúc cụ thể cần thực hiện khi di trú:
- Xóa bỏ Prometheus "global" chạy federation — không tái tạo nó dưới bất kỳ hình thức export nào vào GMP, vì đây chính là pattern bị từ chối tường minh đã nói ở trên. Mọi câu hỏi trước đây trả lời bằng Prometheus global giờ trả lời bằng PromQL query trực tiếp trên GMP, tận dụng root mixer fan-out.
- Xóa bỏ Thanos sidecar và GCS bucket cho dữ liệu mới (có thể giữ lại bucket cũ tạm thời chỉ để tra cứu dữ liệu lịch sử vượt quá 24 tháng retention của Monarch, nếu compliance yêu cầu — đây là trường hợp hiếm cần giữ song song hai hệ thống có chủ đích, không phải kiến trúc ổn định lâu dài).
- Thay Thanos Query bằng chính GMP Prometheus-compatible endpoint trong cấu hình Grafana — về cơ bản chỉ đổi URL data source, vì cả hai đều expose Prometheus HTTP API chuẩn (
/api/v1/query,/api/v1/query_range).
Rủi ro lớn nhất trong quá trình di trú không nằm ở bước 3 (đổi endpoint) mà ở bước 1 — đội ngũ quen thuộc với tư duy "cần một tầng tổng hợp trung tâm" thường vô tình tái tạo lại federation dưới một tên khác (ví dụ dựng một Prometheus "aggregator" tự query GMP rồi remote-write kết quả trở lại GMP). Đây vẫn là anti-pattern tương đương, vì GMP không hỗ trợ remote-write receiver, và bản thân hành động này cũng không cần thiết — bất kỳ phép tính tổng hợp nào cũng nên là recording rule (Rules/ClusterRules/GlobalRules, xem file 03) chạy trực tiếp trên Monarch, không phải một Prometheus trung gian đọc-rồi-ghi-lại.
Retention: cơ chế downsample thực tế, không cấu hình được
Với Thanos, retention và downsampling là thứ bạn tự cấu hình (compactor, resolution levels, storage class lifecycle). Với GMP, retention là chính sách cố định của Monarch, không thể tùy chỉnh, nhưng cần biết chính xác để lập kế hoạch cho các query cần dữ liệu lịch sử dài hạn:
| Giai đoạn | Độ phân giải | Thời lượng |
|---|---|---|
| Mới nhất | Nguyên bản (theo scrape interval gốc) | 1 tuần |
| Trung hạn | Downsample xuống 1 phút | 5 tuần tiếp theo |
| Dài hạn | Downsample xuống 10 phút | Đến tổng cộng 24 tháng |
Hệ quả thực tiễn quan trọng nhất từ bảng này: một query so sánh dữ liệu cách đây 3 tháng với hôm nay sẽ tự động so sánh dữ liệu ở độ phân giải 10 phút, không phải độ phân giải scrape gốc — điều này ảnh hưởng trực tiếp đến độ chính xác của các phép tính như rate() trên khoảng lookback dài, vì rate() trên dữ liệu đã downsample có thể che khuất các đợt spike ngắn đã bị "làm mịn" trong quá trình downsample. Đây cũng là lý do vì sao alerting rule dùng cửa sổ ngắn (5-15 phút) luôn phản ánh dữ liệu chính xác nhất, còn dashboard "so sánh theo quý" cần được hiểu là biểu đồ xu hướng đã làm mịn, không phải dữ liệu thô.
Về giới hạn liên quan, tài liệu quotas ghi nhận cửa sổ điều kiện đánh giá PromQL cho alerting tối đa 2 năm — khớp với tổng thời gian retention 24 tháng nói trên, xác nhận đây không phải hai con số độc lập mà cùng phản ánh một giới hạn retention vật lý duy nhất của Monarch.
Khi nào thực sự cần cân nhắc không dùng GMP (thay vì cố "tích hợp Thanos")
Kế thừa từ phân tích trade-off tổng quát đã có ở Chương 39, ở góc độ retention/federation cụ thể, có hai trường hợp nên cân nhắc giữ nguyên kiến trúc Thanos tự vận hành thay vì ép buộc migrate:
- Cần độ phân giải nguyên bản (raw resolution) lâu hơn 1 tuần cho mục đích compliance/audit chi tiết — Thanos compactor có thể giữ raw resolution vô thời hạn trên object storage nếu cấu hình như vậy, còn Monarch downsample cứng sau 1 tuần không có ngoại lệ.
- Kiến trúc đa đám mây thực sự nơi phần lớn workload nằm ngoài GCP — chi phí data transfer khi self-deployed collector export từ ngoài Google Cloud vào Monarch là chi phí thật, có thể không kinh tế bằng giữ nguyên object storage trung lập cloud của Thanos.
Ngoài hai trường hợp trên, trong phần lớn tổ chức chạy chủ yếu trên GKE, self-deployed collector với local aggregation là lựa chọn thay thế đầy đủ và ít vận hành hơn so với duy trì song song một cụm Thanos riêng.