My Awesome Project

Appearance

System & Workload Metrics — kube-state-metrics, cAdvisor, DCGM GPU ​

Why this matters in production ​

Nếu control plane metric (file 02) cho biết "bộ não cluster có khỏe không", thì system và workload metric ở tầng này cho biết "hạ tầng node và container có đủ tài nguyên để chạy không". Đây là tầng nơi phần lớn incident vận hành thực sự xảy ra: Pod bị OOMKilled vì memory working set vượt limit, container chạy chậm vì bị CPU CFS throttle dù node còn rảnh CPU, PVC đầy disk, GPU đắt tiền chạy ở 15% utilization mà không ai biết. Mọi triệu chứng này đều có một metric cụ thể phơi bày nó — và năng lực cốt lõi là biết metric nào cho hiện tượng nào.

Điểm cần hiểu rõ về tầng này là sự phân chia ba loại metric khác nhau về bản chất, dễ bị gộp nhầm:

  • System metrics đo tài nguyên ở mức node/Pod tổng hợp (CPU node, memory node, disk), bật mặc định.
  • kube-state-metrics (kube_*) đo trạng thái khai báo của Kubernetes object — không phải tài nguyên vật lý mà là "Deployment này muốn 5 replica, hiện có 3 ready". Đây là metric về API object, không phải về máy.
  • cAdvisor/kubelet (container_*) đo tài nguyên tiêu thụ thực tế ở mức container — CPU usage, memory working set, và đặc biệt là throttling.

Theo tài liệu view GKE observability metrics, system metric bật mặc định trên Standard và luôn bật trên Autopilot, trong khi kube-state-metrics, cAdvisor/kubelet, và DCGM là opt-in theo gói vì chúng làm tăng lượng sample ingest. Đây là quyết định chi phí có chủ đích: các gói này giá trị cao khi debug nhưng cardinality lớn ở cluster nhiều object.

Internal model: ba loại metric hạ tầng ​

System metrics — nền tảng luôn bật ​

System metric là tập cơ bản GKE thu tự động qua metric agent trên mỗi node, đẩy vào Cloud Monitoring với tiền tố kubernetes.io/. Chúng bao gồm:

  • Node: kubernetes.io/node/cpu/allocatable_utilization, kubernetes.io/node/memory/allocatable_utilization, disk, network, ephemeral storage.
  • Container/Pod tổng hợp: CPU/memory request utilization, restart count.

Đây là tập metric "sức khỏe hạ tầng" tối thiểu, đủ để biết node có quá tải không, nhưng không đủ chi tiết để debug sâu — đó là lý do tồn tại các gói mở rộng.

kube-state-metrics — trạng thái object dạng metric ​

kube-state-metrics (KSM) là một service lắng nghe Kubernetes API và sinh ra metric về trạng thái của object, tiền tố kube_*. Khác biệt then chốt: KSM không đo tài nguyên vật lý — nó phơi bày trạng thái khai báo và quan sát được của API object thành time series. Ví dụ điển hình:

  • kube_pod_status_phase — Pod đang ở phase nào (Pending/Running/Succeeded/Failed). Đếm Pod theo phase là cách phát hiện hàng loạt Pod kẹt Pending hoặc CrashLoop.
  • kube_pod_container_status_restarts_total — số lần restart container. Tăng nhanh = CrashLoopBackOff.
  • kube_deployment_status_replicas_available vs kube_deployment_spec_replicas — số replica sẵn sàng so với mong muốn; chênh lệch kéo dài = rollout kẹt hoặc thiếu capacity.
  • kube_horizontalpodautoscaler_status_current_replicas / _desired_replicas — quan sát HPA đang muốn scale tới đâu (Chương 9).
  • kube_persistentvolumeclaim_status_phase — PVC đã Bound chưa (Chương 11).

GKE cho bật KSM theo từng gói object qua flag --monitoring: POD, DEPLOYMENT, STATEFULSET, DAEMONSET, HPA, STORAGE (PV/PVC). Việc tách gói cho phép chỉ trả phí cho loại object bạn thực sự monitor.

Cảnh báo cardinality: KSM sinh time series tỷ lệ với số object × số label. Ở cluster có hàng chục nghìn Pod với nhiều label, KSM là nguồn cardinality lớn. Metric kube_pod_labels (phơi mọi label Pod thành metric) đặc biệt tốn kém nếu Pod có nhiều label động.

cAdvisor/kubelet — tài nguyên container thực tế ​

cAdvisor (nhúng trong kubelet) đo tài nguyên tiêu thụ thực tế ở mức container, tiền tố container_*. GKE cung cấp một tập con chọn lọc (không phải toàn bộ cAdvisor metric, vốn rất nhiều) qua gói CADVISOR và KUBELET. Các metric quan trọng nhất:

  • container_cpu_usage_seconds_total — counter thời gian CPU container đã dùng. rate() của nó cho CPU usage hiện tại theo core. So với request/limit để đánh giá rightsizing.

  • container_memory_working_set_bytes — đây là metric memory đúng để theo dõi, không phải container_memory_usage_bytes. Working set là phần memory không thể reclaim được; đây chính là con số kubelet so với limit để quyết định OOMKill. Theo dõi working set tiệm cận limit là cách dự báo OOMKill trước khi nó xảy ra.

  • container_cpu_cfs_throttled_periods_total và container_cpu_cfs_periods_total — đây là cặp metric quan trọng nhất và bị bỏ qua nhiều nhất. Khi container có CPU limit, kernel áp CFS quota (Chương 8): trong mỗi period 100ms, container chỉ được chạy tối đa quota; vượt thì bị throttle (đình chỉ tới period sau). Tỷ lệ throttled_periods / periods cao nghĩa là container đang bị bóp CPU dù node còn rảnh CPU — một nguyên nhân latency cực kỳ phổ biến và khó thấy. App "chậm không rõ lý do", CPU node thấp, nhưng container bị throttle 40% số period vì limit quá thấp. Không có metric này, đây là một trong những bug khó chẩn đoán nhất.

  • container_fs_usage_bytes / container_fs_writes_bytes_total — disk I/O và usage của container, để debug ephemeral storage pressure (Chương 11).

DCGM — observability cho GPU ​

Trên node có GPU (AI/ML, Chương 8), DCGM (NVIDIA Data Center GPU Manager) cung cấp metric GPU qua DCGM-Exporter. Theo tài liệu DCGM metrics, bật DCGM sẽ cài DCGM-Exporter, cài Google-managed GPU driver, và deploy một ClusterPodMonitoring resource. Yêu cầu bắt buộc: dùng Google-managed GPU driver (--gpu-driver-version=default hoặc latest); từ GKE 1.32.1-gke.1357000 trở đi, DCGM bật mặc định.

Các metric GPU then chốt (tiền tố prometheus.googleapis.com/ trong Cloud Monitoring):

  • DCGM_FI_DEV_GPU_UTIL — % thời gian GPU core bận. Đây là metric số một cho FinOps GPU: GPU đắt khủng khiếp, và chạy GPU ở 15% utilization là lãng phí lớn. Phát hiện GPU under-utilized → cân nhắc GPU time-sharing/MIG (Chương 8) hoặc giảm số GPU.
  • DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_FREE / DCGM_FI_DEV_FB_TOTAL — framebuffer (VRAM) đã dùng/còn trống/tổng. Theo dõi để tránh OOM trên GPU (model quá lớn so với VRAM) và để rightsize loại GPU.
  • DCGM_FI_DEV_POWER_USAGE — công suất tiêu thụ (watt), cho phân tích hiệu quả năng lượng.
  • DCGM_FI_DEV_GPU_TEMP / DCGM_FI_DEV_SM_CLOCK — nhiệt độ và xung nhịp SM; nhiệt cao tương quan với thermal throttling (clock giảm).
  • DCGM_FI_PROF_SM_ACTIVE, DCGM_FI_PROF_PCIE_*, DCGM_FI_PROF_NVLINK_* — profiling metric: độ bận SM, throughput PCIe/NVLink. Dùng để xác định bottleneck là compute, PCIe, hay NVLink — quyết định kiến trúc cho training phân tán.
  • XID errors — lỗi phần cứng/driver GPU; là tín hiệu node GPU cần auto-repair.

Production architecture patterns ​

Tập metric tối thiểu cho production cluster ​

Một baseline hợp lý: system (mặc định) + POD + DEPLOYMENT (hoặc STATEFULSET/DAEMONSET tùy workload) + HPA + CADVISOR. Tập này đủ để: đếm Pod theo phase, theo dõi rollout, quan sát HPA, và quan trọng nhất là phát hiện CPU throttling + dự báo OOMKill. Thêm STORAGE nếu chạy stateful workload, DCGM nếu có GPU.

Dùng cAdvisor metric để rightsizing có dữ liệu ​

Pattern FinOps cốt lõi: dùng container_memory_working_set_bytes và rate(container_cpu_usage_seconds_total) so với request/limit để phát hiện over-provisioning (request cao hơn nhiều usage thực) và under-provisioning (throttling cao, OOM thường xuyên). Đây là nguồn dữ liệu nuôi VPA recommender (Chương 9) và quyết định rightsizing thủ công.

GPU observability như một hạng mục FinOps riêng ​

Với cluster AI/ML, GPU thường là chi phí lớn nhất. Pattern đúng: dashboard GPU riêng theo dõi DCGM_FI_DEV_GPU_UTIL và DCGM_FI_DEV_FB_USED per-Pod, với alert khi utilization thấp kéo dài — vì một GPU rảnh là tiền đốt mỗi giây. Đây là nơi observability trực tiếp tạo ra tiết kiệm đo lường được.

Real-world scenarios ​

Kịch bản 1 — "App chậm nhưng CPU node thấp". Một service Java có latency p99 tăng gấp đôi vào giờ cao điểm. System metric cho thấy CPU node chỉ 40% — có vẻ thừa tài nguyên. Nhưng container_cpu_cfs_throttled_periods_total / container_cpu_cfs_periods_total của Pod đó là 0.55: container bị throttle 55% số period vì CPU limit đặt quá thấp (500m) trong khi nó cần burst lên 1.5 core. Nâng limit (hoặc bỏ limit cho workload latency-sensitive) giải quyết triệt để. Không có cAdvisor throttling metric, đội ngũ sẽ loay hoay với CPU node và không bao giờ tìm ra.

Kịch bản 2 — OOMKill âm thầm theo chu kỳ. Một Pod bị restart mỗi vài giờ, kube_pod_container_status_restarts_total tăng đều nhưng không ai để ý. Nhìn container_memory_working_set_bytes, working set tăng tuyến tính theo thời gian (memory leak) cho đến khi chạm limit và bị OOMKilled, rồi lặp lại. Metric phơi bày cả triệu chứng (restart) lẫn nguyên nhân (working set leak) — kết hợp với log OOMKilled (file 05) để xác nhận.

Kịch bản 3 — Cluster GPU đốt tiền. Một training cluster với 16 GPU A100. DCGM_FI_DEV_GPU_UTIL trung bình chỉ 22% vì pipeline data loading là bottleneck (CPU không feed kịp GPU). DCGM_FI_PROF_PCIE_RX_BYTES thấp xác nhận GPU đói dữ liệu. Phát hiện này dẫn đến tối ưu data loader và giảm số GPU — tiết kiệm trực tiếp hàng nghìn đô/tháng.

Common mistakes / anti-patterns ​

  • Theo dõi container_memory_usage_bytes thay vì working set. usage_bytes bao gồm cache có thể reclaim, nên cao hơn con số kubelet dùng để OOMKill. Dùng nó để alert sẽ báo động giả. Đúng: dùng container_memory_working_set_bytes.

  • Bỏ qua CPU throttling hoàn toàn. Đặt CPU limit thấp cho mọi workload "để an toàn" rồi không bao giờ nhìn throttling metric. Hệ quả: latency cao kinh niên không ai giải thích được. Đúng: monitor cfs_throttled_periods, cân nhắc bỏ CPU limit cho workload latency-sensitive (chỉ giữ request).

  • Bật kube_pod_labels với Pod nhiều label động. Phơi mọi label thành metric tạo cardinality khổng lồ. Đúng: chỉ bật gói KSM cần thiết, dùng metricRelabeling (file 06) để drop label cao.

  • Mua GPU nhưng không bật DCGM. Chạy GPU đắt tiền mà không quan sát utilization — không biết nó chạy 20% hay 90%. Đúng: bật DCGM với Google-managed driver, dashboard GPU riêng, alert utilization thấp.

  • Bật mọi gói KSM trên cluster lớn không cân nhắc. POD+DEPLOYMENT+STATEFULSET+DAEMONSET+HPA+STORAGE đầy đủ trên cluster vạn Pod tạo lượng sample lớn. Đúng: bật theo loại object thực sự monitor.

GCP-native implementation guidance ​

Bật system + KSM (Pod/Deployment/HPA) + cAdvisor:

bash
gcloud container clusters update CLUSTER_NAME \
  --location=LOCATION \
  --monitoring=SYSTEM,POD,DEPLOYMENT,STATEFULSET,DAEMONSET,HPA,STORAGE,CADVISOR,KUBELET

Bật DCGM (yêu cầu Google-managed GPU driver):

bash
gcloud container clusters update CLUSTER_NAME \
  --location=LOCATION \
  --monitoring=SYSTEM,DCGM

Query vận hành (PromQL trong Cloud Monitoring):

promql
# Tỷ lệ CPU throttling theo Pod — phát hiện container bị bóp CPU
sum by (pod) (rate(container_cpu_cfs_throttled_periods_total[5m]))
  /
sum by (pod) (rate(container_cpu_cfs_periods_total[5m]))

# Memory working set tiệm cận limit — dự báo OOMKill
max by (pod, container) (container_memory_working_set_bytes)

# Pod đếm theo phase — phát hiện Pending/Failed hàng loạt
sum by (phase) (kube_pod_status_phase)

# GPU under-utilized — tín hiệu lãng phí FinOps
avg by (pod) (DCGM_FI_DEV_GPU_UTIL)

Official references ​

Tóm lại: tầng system/workload metric là nơi phần lớn incident vận hành lộ diện. kube-state-metrics (kube_*) cho trạng thái object; cAdvisor (container_*) cho tài nguyên container — đặc biệt container_memory_working_set_bytes để dự báo OOMKill và container_cpu_cfs_throttled_periods_total để phát hiện throttling ẩn; DCGM cho GPU observability và FinOps. Bật theo gói có chủ đích, ưu tiên cAdvisor throttling/working set, và biến GPU utilization thành một hạng mục tiết kiệm chi phí đo lường được.