Metrics Data Model — GAUGE, DELTA, CUMULATIVE

Tại sao phần này quan trọng

Cloud Monitoring không phải là một "time series database thông thường". Nó có một data model với những ràng buộc và semantics rất cụ thể được thiết kế để xử lý hàng tỉ điểm dữ liệu mỗi ngày từ hàng triệu resource. Hiểu data model này là điều kiện tiên quyết để:

• Viết query không cho kết quả sai (ví dụ: sum của CUMULATIVE counter là vô nghĩa)
• Thiết kế custom metrics không bị reject hoặc cho dữ liệu lệch
• Hiểu tại sao alert "trễ" so với thực tế và có thể làm gì để giảm độ trễ
• Tránh những chi phí ẩn từ việc dùng sai metric kind

Model bên trong: Time Series là gì

Mỗi measurement trong Cloud Monitoring tồn tại trong một time series — một chuỗi các data point được sắp xếp theo thời gian. Một time series được xác định duy nhất bởi tổ hợp của:

(metric type) + (metric labels) + (monitored resource type) + (resource labels)

Ví dụ: metric compute.googleapis.com/instance/cpu/utilization trên resource type gce_instance với labels {project_id: "my-project", zone: "us-central1-a", instance_id: "123456"} tạo thành một time series duy nhất.

MetricDescriptor là schema của metric, định nghĩa:

• metricKind: GAUGE, DELTA, hoặc CUMULATIVE
• valueType: INT64, DOUBLE, DISTRIBUTION, STRING, BOOL
• labels: danh sách label keys được phép
• unit: đơn vị đo (nếu có)

Khi một service muốn ghi metric, nó ghi các Point vào time series đó. Mỗi Point có:

• interval: khoảng thời gian (startTime, endTime) — quan trọng: ý nghĩa thay đổi tùy theo metricKind
• value: giá trị thực tế

Theo tài liệu chính thức GCP, "A metric time series is a set of data points that represents the evolution of a metric over time for a given set of label values."

Metric Kinds — Cốt lõi của Data Model

Ba metric kind không chỉ là nhãn — chúng định nghĩa ngữ nghĩa của khoảng thời gian (interval) trong mỗi Point. Đây là điểm quan trọng nhất để hiểu.

GAUGE — Đo tại một thời điểm

GAUGE đo giá trị tại một thời điểm cụ thể, không có ngữ nghĩa về khoảng thời gian. startTime và endTime trong interval của GAUGE point thường bằng nhau (hoặc startTime bị bỏ qua).

Ví dụ tiêu biểu:

• CPU utilization: bao nhiêu % CPU đang được dùng lúc này?
• Memory usage: bao nhiêu bytes đang được sử dụng?
• Active connections: có bao nhiêu connection đang mở?
• Temperature: nhiệt độ hiện tại là bao nhiêu?

Cơ chế alignment: Khi bạn chọn alignment period (ví dụ 1 phút), Cloud Monitoring group các điểm GAUGE trong cửa sổ đó lại và tính toán bằng aligner (mean, max, min, etc.). Nếu có nhiều điểm trong một window, chúng được gộp lại. Nếu không có điểm, window đó sẽ thiếu dữ liệu.

Khi dùng GAUGE: Mọi giá trị "tại thời điểm này là bao nhiêu" đều là GAUGE. Đây là metric kind phổ biến nhất cho infrastructure metrics.

DELTA — Thay đổi trong một khoảng thời gian

DELTA đo sự thay đổi xảy ra trong khoảng (startTime, endTime]. Point có cả hai thời điểm và giá trị biểu thị "đã tăng/thay đổi bao nhiêu" trong khoảng đó.

Ví dụ tiêu biểu:

• Request count: đã nhận bao nhiêu request trong 1 phút qua?
• Bytes received: đã nhận bao nhiêu bytes trong 5 phút qua?
• Error count: có bao nhiêu lỗi trong 1 giờ qua?

Cơ chế alignment: DELTA points không thể đơn giản "trung bình hóa" vì chúng là counts trong khoảng thời gian. Cloud Monitoring dùng aligner ALIGN_DELTA hoặc ALIGN_RATE (để chuyển thành rate per second). Khi bạn sum hai DELTA points liên tiếp, bạn có tổng count trong khoảng thời gian gộp — đây là phép toán có nghĩa.

Tại sao DELTA quan trọng: DELTA cho phép bạn tính throughput và rate một cách chính xác. Nếu một service ghi "100 requests" vào một DELTA time series, bạn biết chính xác 100 requests đó xảy ra trong khoảng startTime đến endTime. Không có ambiguity.

Khi dùng DELTA: Mọi metric đếm discrete events theo thời gian — request counts, byte counts, error counts, task completions. Theo docs GCP: "All metrics that count discrete items over a time interval are delta metrics."

CUMULATIVE — Giá trị tăng đơn điệu

CUMULATIVE đo giá trị luôn tăng từ một điểm bắt đầu (start time cố định của time series). Mỗi Point biểu thị tổng tích lũy kể từ khi time series bắt đầu đến thời điểm endTime của Point đó.

Ví dụ tiêu biểu:

• Total bytes sent kể từ khi service start: networking.googleapis.com/vm_flow/egress_bytes_count
• Total requests served kể từ khi process khởi động
• Total errors từ đầu

Cơ chế alignment: CUMULATIVE là metric kind phức tạp nhất để làm việc. Bạn không thể directly chart hoặc alert trên CUMULATIVE value vì nó chỉ có ý nghĩa khi so sánh với điểm trước. Cloud Monitoring tự động convert CUMULATIVE sang DELTA khi bạn dùng trong alerting policies hoặc chart, thông qua aligner ALIGN_DELTA (tính difference giữa hai điểm liên tiếp).

Theo tài liệu GCP: "Cumulative metrics can't be used directly for charting or alerting in Monitoring, but they can be aggregated into non-cumulative metrics."

Reset handling: CUMULATIVE time series có thể reset về 0 khi service restart. Cloud Monitoring phát hiện reset (khi giá trị giảm đột ngột) và điều chỉnh calculation tránh tạo ra spike âm giả.

Khi dùng CUMULATIVE: Thường thấy trong hệ thống dạng Prometheus Counter (chỉ tăng). Nhiều GCP built-in metrics dùng CUMULATIVE. Khi bạn query CUMULATIVE metrics, luôn phải dùng rate() hoặc delta() để có giá trị có nghĩa.

So sánh thực tế — Tại sao sai kind gây ra kết quả sai

Giả sử bạn có một service ghi "requests per second" vào Cloud Monitoring:

• Nếu dùng GAUGE: mỗi point là "tại thời điểm này, rate là X req/s". Alignment mean hợp lý.
• Nếu dùng DELTA: mỗi point là "trong khoảng này, có X requests". Alignment sum hợp lý.
• Nếu dùng CUMULATIVE: mỗi point là "từ khi start đến giờ, có tổng X requests". Bạn cần ALIGN_RATE để có req/s.

Nếu bạn ghi "total requests served" (ngày càng tăng) vào GAUGE:

• Cloud Monitoring sẽ "mean" các giá trị trong alignment window
• Kết quả là một con số vô nghĩa (mean của các giá trị tăng)
• Alert threshold sẽ không bao giờ trigger đúng

Value Types — Kiểu dữ liệu của metric

Value type định nghĩa kiểu dữ liệu được lưu trong mỗi Point. Không phải mọi kết hợp (MetricKind, ValueType) đều hợp lệ.

INT64

Số nguyên 64-bit. Phù hợp cho counts, queue depths, port numbers.

GAUGE + INT64: số connections hiện tại
DELTA + INT64: số requests trong khoảng thời gian
CUMULATIVE + INT64: tổng số bytes từ khi start

DOUBLE

Số thực dấu chấm động. Phù hợp cho tỉ lệ, percentages, throughput với decimal.

GAUGE + DOUBLE: CPU utilization (0.0 - 1.0)
DELTA + DOUBLE: bytes received (có thể có decimal)
CUMULATIVE + DOUBLE: total latency accumulated

DISTRIBUTION

Không phải một giá trị đơn — là tập hợp thống kê gồm count, mean, sum of squared deviations, và histogram buckets. Distribution cho phép tính percentiles mà single value không thể làm được.

DELTA + DISTRIBUTION: latency distribution — histogram của tất cả request latencies trong khoảng thời gian
GAUGE + DISTRIBUTION: (ít dùng) snapshot của distribution tại thời điểm

Tại sao DISTRIBUTION quan trọng: Nếu bạn đo latency bằng DOUBLE GAUGE (ví dụ, mean latency), bạn mất thông tin về tail latency. p99 latency có thể là 10x mean. DISTRIBUTION lưu histogram đầy đủ, cho phép bạn query percentile(latency, 99) chính xác.

Cloud Monitoring tự động tính p50, p95, p99, p99.9 từ DISTRIBUTION. Đây là lý do hầu hết latency metrics của GCP (như HTTP request latency của Load Balancer) dùng DELTA + DISTRIBUTION.

Bucket configuration: Distribution histogram cần được cấu hình với buckets phù hợp. GCP cung cấp:

• Linear buckets: khoảng cách đều nhau
• Exponential buckets: tăng theo lũy thừa (phù hợp cho latency)
• Explicit buckets: tùy chỉnh ranh giới

STRING

Giá trị chuỗi. Chỉ hỗ trợ với GAUGE. Có giới hạn nghiêm ngặt về độ dài và cardinality vì mỗi unique string tạo một time series mới.

Trong thực tế, STRING metric rất ít được dùng. Nếu cần encode trạng thái (state), nên dùng INT64 với labels, hoặc BOOL cho trạng thái nhị phân.

BOOL

Boolean. Chỉ hỗ trợ với GAUGE. Phù hợp cho "feature enabled/disabled", "service up/down".

GAUGE + BOOL: uptime check result (true = UP, false = DOWN)

Ma trận hợp lệ

	BOOL	INT64	DOUBLE	STRING	DISTRIBUTION
GAUGE	✅	✅	✅	✅	✅
DELTA	❌	✅	✅	❌	✅
CUMULATIVE	❌	✅	✅	❌	✅

Custom metrics có thêm ràng buộc: DELTA + STRING và một số DISTRIBUTION combinations bị cấm.

Alignment và Reduction — Cách Cloud Monitoring xử lý dữ liệu trước khi hiển thị

Raw time series thường không đủ sạch để query trực tiếp — các điểm có thể đến không đều, có thể có gaps, và nhiều time series cần được gộp lại. Cloud Monitoring xử lý điều này qua hai bước: alignment và reduction.

Alignment — Chuẩn hóa time series

Alignment chia thời gian thành các buckets đều nhau (alignment period) và tính một giá trị đại diện cho mỗi bucket.

Alignment Period: Khoảng thời gian của mỗi bucket. Phải đủ lớn để có đủ data points để align, nhưng đủ nhỏ để không mất detail.

Aligners — Cách tính giá trị đại diện:

Aligner	Dùng với	Ý nghĩa
ALIGN_MEAN	GAUGE + số	Trung bình các points trong bucket
ALIGN_MAX	GAUGE + số	Giá trị lớn nhất trong bucket
ALIGN_MIN	GAUGE + số	Giá trị nhỏ nhất trong bucket
ALIGN_SUM	GAUGE + số	Tổng các points trong bucket
ALIGN_COUNT	GAUGE + bất kỳ	Số points trong bucket
ALIGN_RATE	DELTA, CUMULATIVE	Tốc độ thay đổi (per second)
ALIGN_DELTA	DELTA, CUMULATIVE	Thay đổi tổng trong bucket
ALIGN_PERCENTILE_99	DISTRIBUTION	P99 của distribution
ALIGN_PERCENTILE_95	DISTRIBUTION	P95 của distribution
ALIGN_PERCENTILE_50	DISTRIBUTION	Median (P50)

Constraint quan trọng: Một số aligners không hợp lệ với một số metric kinds. ALIGN_RATE trên GAUGE sẽ cho kết quả vô nghĩa (tính "tốc độ thay đổi" của một điểm đo tức thời). Cloud Monitoring sẽ cảnh báo hoặc từ chối.

Reduction — Gộp nhiều time series

Sau alignment, bạn thường muốn gộp nhiều time series thành một — ví dụ, tổng CPU utilization của tất cả VMs trong một zone.

Cross-series Reducers:

Reducer	Ý nghĩa
REDUCE_SUM	Tổng tất cả time series
REDUCE_MEAN	Trung bình tất cả time series
REDUCE_MAX	Giá trị lớn nhất
REDUCE_MIN	Giá trị nhỏ nhất
REDUCE_COUNT	Số time series
REDUCE_PERCENTILE_99	P99 cross-series

Group By: Thường kết hợp với reduction để gộp theo một dimension:

Group by zone → Reduce Sum → Tổng CPU per zone
Group by instance_type → Reduce Mean → Average CPU per type

Tại sao alignment period ảnh hưởng đến độ chính xác của alert

Khi bạn tạo alerting policy với threshold condition, Cloud Monitoring evaluate condition sau mỗi alignment period. Một alignment period ngắn (ví dụ 1 phút) → alert phản ứng nhanh nhưng sensitive với noise. Alignment period dài (ví dụ 5 phút) → alert ổn định hơn nhưng có thể miss spike ngắn.

Ví dụ: CPU spike 100% trong 30 giây sẽ không trigger alert có alignment period 5 phút nếu mean CPU trong 5 phút đó là 30%.

Label Cardinality — Điểm chết của custom metrics

Mỗi unique combination của label values tạo ra một time series riêng biệt. Nếu bạn có label user_id với 1 triệu users, bạn sẽ có 1 triệu time series cho một metric. Điều này:

1. Tốn tiền: Custom metrics tính phí theo số time series (active samples) — xem phần billing
2. Làm chậm query: Khi aggregate, Cloud Monitoring phải read hàng triệu time series
3. Hit limit hệ thống: Cloud Monitoring có giới hạn về số active time series per project

Anti-pattern: Dùng user ID, order ID, trace ID, session ID làm metric label. Cardinality không có giới hạn thực sự và sẽ explode.

Pattern đúng: Aggregate sẵn trước khi ghi metric, hoặc dùng Logging (thay vì Metrics) cho per-entity data.

Constraints và giới hạn kỹ thuật

Giới hạn custom metrics:

• Tối đa 500 time series có thể được ghi trong một lần API call
• Mỗi time series có thể có tối đa 10 labels
• Tên metric phải bắt đầu với custom.googleapis.com/
• Data points không thể ghi vào quá khứ quá 25 giờ
• Data points không thể ghi vào tương lai quá 10 phút

Data retention:

• Metric data lưu 6 tuần (mặc định) cho most metrics
• Một số metrics có retention 30 ngày (user-defined metrics)
• Không thể extend retention cho individual metrics

Ingestion latency:

• GCP system metrics: thường available trong 60-120 giây sau khi event xảy ra
• Custom metrics qua API: có thể mất đến vài phút
• GKE metrics qua Managed Prometheus: tùy thuộc vào scrape interval (thường 30-60 giây cộng với thời gian push đến Monarch)

Query rate limits:

• Cloud Monitoring API có quota theo project — mặc định 6,000 requests/phút
• Phức tạp queries (nhiều time series, aggregation nặng) có thể timeout nếu quét quá nhiều dữ liệu

Failure mode: CUMULATIVE reset và spike giả

Khi bạn monitor một CUMULATIVE metric (như request_count_total từ Prometheus), và service restart, counter reset về 0. Nếu không handle đúng:

1. Điểm cuối trước restart: value = 1,000,000
2. Điểm đầu sau restart: value = 100 (vừa restart, đã phục vụ 100 requests)
3. Delta = 100 - 1,000,000 = -999,900 → spike âm khổng lồ

Cloud Monitoring tự handle điều này: khi phát hiện CUMULATIVE value giảm đột ngột, nó bắt đầu một "cumulative run" mới từ điểm reset. Nhưng điều này có nghĩa là có một "gap" trong dữ liệu tại thời điểm reset, và bất kỳ alert nào đang evaluate tại thời điểm đó có thể behave không như mong đợi.

Tham khảo chính thức

• Metric Kinds and Value Types
• Aggregation: Alignment and Reduction
• MetricDescriptor Reference
• Custom Metrics Overview
• Time Series Data