Monitored Resources & Billing Model
Monitored Resource Types — Cầu nối giữa Metric và Resource
Trong Cloud Monitoring, một time series không chỉ xác định bởi metric type và labels — nó còn được gắn với một monitored resource. Monitored resource là biểu diễn trừu tượng của thực thể mà metric đến từ đó.
Tại sao cần monitored resource?
Bài toán: cùng một metric type compute.googleapis.com/instance/cpu/utilization có thể đến từ hàng nghìn VMs khác nhau. Làm sao phân biệt?
Câu trả lời không phải là nhét thông tin VM vào metric labels — đó sẽ làm tăng cardinality và tạo coupling không cần thiết. Thay vào đó, Cloud Monitoring tách biệt "loại thực thể sinh ra metric" thành một type riêng: monitored resource type.
Mỗi monitored resource type có schema riêng với các resource labels cố định:
resource type: gce_instance
resource labels:
- project_id: "my-project"
- zone: "us-central1-a"
- instance_id: "1234567890"Một time series đầy đủ có dạng:
(metric_type) + (metric_labels) + (resource_type) + (resource_labels) → unique time seriesCác monitored resource types quan trọng
GCP Infrastructure:
| Resource Type | Đại diện cho | Labels quan trọng |
|---|---|---|
gce_instance | Compute Engine VM | project_id, zone, instance_id |
gke_container | GKE container (legacy) | cluster_name, namespace_id, pod_id, container_name |
k8s_container | Kubernetes container | cluster_name, namespace_name, pod_name, container_name |
k8s_pod | Kubernetes pod | cluster_name, namespace_name, pod_name |
k8s_node | Kubernetes node | cluster_name, node_name |
k8s_cluster | Kubernetes cluster | cluster_name, location |
cloud_run_revision | Cloud Run revision | service_name, revision_name, configuration_name, location |
cloudsql_database | Cloud SQL instance | project_id, region, database_id |
pubsub_topic | Cloud Pub/Sub topic | project_id, topic_id |
pubsub_subscription | Cloud Pub/Sub subscription | project_id, subscription_id |
bigquery_dataset | BigQuery dataset | project_id, dataset_id |
global | Project-level metrics | project_id |
Tại sao gke_container vs k8s_container quan trọng:
GKE từng dùng resource type gke_container nhưng đã chuyển sang k8s_container để align với Kubernetes API. Một số metrics cũ vẫn dùng gke_container. Khi bạn query metrics, phải xác định đúng resource type, vì query k8s_container không tự động include gke_container và ngược lại.
Monitored resource global: Resource type global dùng cho các metrics không gắn với một resource infrastructure cụ thể — ví dụ, custom metrics của application-level business logic. Labels chỉ gồm project_id.
Resource label filtering trong query
Một trong những lợi ích chính của monitored resource model là bạn có thể filter time series dựa trên resource labels mà không cần nhúng thông tin đó vào metric labels:
# Filter chỉ lấy metrics từ namespace "production"
fetch k8s_container
| filter resource.namespace_name = "production"
| metric "kubernetes.io/container/cpu/core_usage_time"Điều này giúp namespace-scoped query rất tự nhiên và không yêu cầu phải add namespace vào mọi custom metric.
Tự định nghĩa monitored resource type
Nếu bạn có service không phải GCP infrastructure (ví dụ, on-premises server), bạn có thể dùng resource type generic_node hoặc generic_task:
generic_node: {project_id, location, namespace, node_id}
generic_task: {project_id, location, namespace, job, task_id}Đây là resource types "generic" được thiết kế cho workloads không thuộc GCP managed resources.
Billing Model — Free vs Chargeable Metrics
Cloud Monitoring billing là một trong những nguồn bill "bất ngờ" phổ biến nhất vì nhiều engineer giả định mọi GCP metric đều miễn phí.
Nguyên tắc tính phí
Cloud Monitoring tính phí dựa trên volume metric ingestion — cụ thể là số bytes dữ liệu metric được ingested mỗi tháng, sau một free tier.
Theo tài liệu GCP chính thức, Cloud Monitoring charges for metric data ingested beyond the free allotment. The pricing is based on the volume of data (in bytes) ingested per month.
Metrics miễn phí
Các metrics không tính phí bao gồm:
1. GCP built-in system metrics:
- Tất cả metrics được tạo tự động bởi GCP services khi bạn sử dụng chúng
- Ví dụ:
compute.googleapis.com/*,container.googleapis.com/*,cloudsql.googleapis.com/*,pubsub.googleapis.com/* - Đây là hàng nghìn metric types tự động xuất hiện khi bạn tạo resources
2. Kubernetes system metrics:
- Metrics từ GKE System metric collection (kube-state-metrics, cAdvisor system component metrics)
- Được enable mặc định khi tạo GKE cluster
3. Một số Anthos metrics:
- Metrics từ Anthos Service Mesh (nếu dùng managed ASM)
4. Uptime check metrics:
monitoring.googleapis.com/uptime_check/*— không tính phí
5. Process health metrics:
agent.googleapis.com/agent/*— metrics về Monitoring Agent itself
Metrics có tính phí
1. Custom metrics (custom.googleapis.com/*): Đây là các metrics do bạn tự tạo qua Cloud Monitoring API hoặc client libraries. Mỗi data point bạn ghi đều tính vào volume ingested.
2. External metrics (external.googleapis.com/*): Metrics từ các nguồn ngoài GCP ingested vào Cloud Monitoring, ví dụ: metrics từ AWS CloudWatch qua integrations, hay third-party SaaS tools.
3. Prometheus metrics qua Managed Service for Prometheus: Metrics scraped bởi GMP collector và ingested vào Cloud Monitoring. Đây là nguồn phổ biến nhất gây bill không mong đợi vì:
- Mỗi Prometheus metric endpoint có thể expose hàng trăm metrics
- Mỗi metric với nhiều labels tạo nhiều time series
- High cardinality Prometheus metrics explode số lượng time series
4. Log-based metrics: Metrics được tạo từ Cloud Logging qua log-based metric configurations. Tính phí dựa trên số time series.
5. Agent metrics (một số loại): Một số metrics từ Ops Agent (agent.googleapis.com/) nằm ngoài free tier.
Mô hình tính phí chi tiết
Giá tính theo volume bytes ingested mỗi tháng, với free tier đầu tiên miễn phí (thường là 150MB-250MB tùy loại). Sau free tier, tính theo $/MiB.
Ước tính cost cho custom metrics:
Mỗi data point chiếm khoảng 40-200 bytes tùy thuộc vào:
- Số lượng labels (nhiều label → nhiều bytes)
- Kiểu giá trị (DISTRIBUTION lớn hơn INT64 nhiều)
- Metadata
Ví dụ thực tế:
- 100 custom metrics × 5 labels mỗi metric × ghi mỗi 60 giây × 30 ngày
- ≈ 100 × 1 time series × (30×24×60) = 100 × 43,200 points/tháng = 4.32 triệu points
- ≈ 4.32M × 100 bytes = 432 MB/tháng → vào billable range
Cho Prometheus metrics:
Nếu mỗi pod expose 500 Prometheus metrics và bạn có 100 pods:
- 500 × 100 = 50,000 time series
- Scrape mỗi 30 giây → 2 points/phút × 43,200 phút = 86,400 points/time series/tháng
- 50,000 × 86,400 × 60 bytes ≈ 259 GB/tháng → rất đắt tiền
Đây là lý do tại sao phải rất cẩn thận về metric cardinality với GMP.
Chiến lược kiểm soát cost
1. Dùng metric relabeling để drop metrics không cần: Trong GMP PodMonitoring config, dùng metricRelabeling để drop metrics không cần thiết trước khi push:
metricRelabeling:
- sourceLabels: [__name__]
regex: go_.*|process_.* # drop Go runtime và process metrics
action: drop2. Tăng scrape interval: Tăng từ 30s lên 60s giảm 50% volume ngay lập tức. Đánh đổi: độ phân giải của metric thấp hơn.
3. Monitoring của billing: Dùng metric monitoring.googleapis.com/billing/bytes_ingested để theo dõi volume ingestion theo loại metric. Cloud Monitoring tự generate metric này về việc bao nhiêu bytes đang được ingested — đây là metric miễn phí và là công cụ quan trọng nhất để kiểm soát cost.
4. Set budget alerts: GCP Budget API cho phép alert khi Cloud Monitoring bill đạt ngưỡng nhất định.
5. Cân nhắc sampling: Với high-frequency metrics không yêu cầu sub-minute precision, có thể aggregate tại nguồn trước khi push về Cloud Monitoring.
Failure mode: Cardinality explosion trong production
Scenario thực tế: team deploy service mới với Prometheus metrics. Service có label customer_id trong metrics (anti-pattern). Ban đầu chỉ có 100 customers → không thấy vấn đề. Sau 3 tháng, 50,000 customers → 50,000× số time series → bill Cloud Monitoring tăng 500x so với dự kiến.
Cách phát hiện sớm: monitor metric monitoring.googleapis.com/billing/bytes_ingested và alert khi tăng đột biến > 2x so với baseline.
Cách fix: không có cách nào xóa historical time series đã create. Phải remove label (deploy lại service không có label đó), chờ active time series tự expire sau 24 giờ không có new data points, rồi create lại.