Chương 14: GKE Observability — Metrics, Logs, Traces
Vì sao observability là kỹ năng phân biệt giữa "vận hành may rủi" và "vận hành có kiểm soát"
Một GKE cluster ở quy mô production sinh ra một lượng telemetry khổng lồ và phân tầng: control plane phát ra metric về API server latency và etcd; mỗi node phát ra metric về CPU/memory/disk pressure và container throttling; mỗi workload phát ra log stdout/stderr và (nếu được instrument) application metric cùng distributed trace. Vấn đề trung tâm của chương này không phải là "làm sao thu thập được nhiều telemetry hơn" — GKE thu thập rất nhiều thứ mặc định — mà là biết signal nào nằm ở tầng nào, signal đó trả lời câu hỏi gì, và làm sao correlate chúng để đi từ triệu chứng đến nguyên nhân gốc.
Đây là điểm phân biệt giữa một đội ngũ vận hành trưởng thành và một đội ngũ chữa cháy. Khi một dịch vụ chậm đi, đội chưa trưởng thành nhìn vào latency của dịch vụ rồi đoán; đội trưởng thành biết ngay phải hỏi: độ trễ này phát sinh ở tầng nào — ở application code (application metric + trace), ở container bị CPU throttle (cAdvisor container_cpu_cfs_throttled_periods_total), ở node bị memory pressure (system metric), ở Pod không schedule được (scheduler_pending_pods), hay ở chính API server đang quá tải (apiserver_request_duration_seconds)? Mỗi tầng có một bộ signal riêng, và năng lực cốt lõi là biết bắt đầu nhìn từ đâu.
Có ba kiểu thất bại observability phổ biến ở quy mô production, và cả ba đều bắt nguồn từ việc không hiểu cấu trúc phân tầng của telemetry:
Thu thập mù — ingest mọi thứ rồi trả hóa đơn khổng lồ. Bật toàn bộ control plane metric, kube-state-metric, cAdvisor, audit Data Access log, application metric high-cardinality — mà không bao giờ query phần lớn chúng. Cloud Logging và Managed Service for Prometheus tính phí theo lượng dữ liệu ingest. Một label
user_idhoặcrequest_idnhúng vào metric sinh ra cardinality explosion, và hóa đơn observability vượt cả hóa đơn compute. Observability không phải là "thu càng nhiều càng tốt" — nó là "thu đúng signal cần để trả lời câu hỏi vận hành, với chi phí có kiểm soát".Mù tầng control plane. Đội ngũ monitor workload rất kỹ nhưng không bật control plane metric, nên khi API server bị nghẽn do một controller hỏng spam request, hoặc khi scheduler không xếp được Pod vì resource fragmentation, họ thấy triệu chứng (Pod Pending, kubectl chậm) mà không thấy nguyên nhân. Control plane là "bộ não" của cluster (Chương 5); không quan sát nó nghĩa là debug trong bóng tối.
Không correlate được các signal. Có metric, có log, có trace — nhưng nằm rời rạc ở ba nơi, không có chung resource label (
cluster,namespace,pod) để nối lại. Khi một incident xảy ra, không thể nhảy từ một metric spike sang đúng log dòng đó sang đúng trace của request đó. Giá trị của observability không nằm ở từng signal đơn lẻ mà ở khả năng correlate — và correlate chỉ hoạt động khi mọi signal mang cùng một bộ nhãn tài nguyên nhất quán.
Điểm mấu chốt mà chương này nhấn mạnh xuyên suốt: observability trên GKE là một stack phân tầng, mỗi tầng có một bộ signal, một cơ chế thu thập, một mô hình chi phí riêng — và mục tiêu của một platform engineer là thiết kế một hệ quan sát nơi mọi tầng đều có signal đủ để debug, mọi signal đều correlate được, và tổng chi phí được kiểm soát có chủ đích. GKE tích hợp sẵn với Google Cloud Observability (Cloud Monitoring, Cloud Logging, Cloud Trace) và Google Cloud Managed Service for Prometheus; hiểu cách các thành phần này khớp với nhau là nội dung của chương.
Điều kiện tiên quyết
- Chương 5 (GKE Control Plane Internals): để hiểu control plane metric, phải nắm vai trò API server, scheduler, controller-manager, etcd, và mô hình managed control plane của GKE. Toàn bộ file 02 giả định bạn đã hiểu API Priority and Fairness, reconciliation loop, và etcd. Chương này quan sát những thứ Chương 5 giải thích cơ chế.
- Chương 6–8 (Node Lifecycle, Networking, Scheduler): system metric phản ánh node condition, eviction, scheduling. Hiểu node-pressure eviction và scheduling queue (Chương 8) là điều kiện để đọc đúng cAdvisor và scheduler metric.
- Chương 9 (Autoscaling): HPA tiêu thụ metric. File 07 (custom metric cho HPA) nối thẳng vào pipeline autoscaling đã trình bày ở Chương 9 — chương này cung cấp nguồn metric, Chương 9 cung cấp control loop tiêu thụ chúng.
- Chương 12–13 (Security, Workload Identity): audit log là một loại security telemetry; Managed Service for Prometheus và OpenTelemetry collector dùng Workload Identity để xác thực khi đẩy dữ liệu lên Google Cloud. File 05 và 06 cross-reference các chương này.
- Cloud Monitoring/Cloud Logging basics: metric, time series, resource type, log entry, log sink, MQL/PromQL. Chương này đi sâu vào mô hình GKE-specific, không dạy lại khái niệm nền tảng của Cloud Observability.
Mức độ sâu
5/5 — Chương đi tới mức: danh sách metric cụ thể của từng control plane component (apiserver_request_total, apiserver_request_duration_seconds, apiserver_storage_objects, apiserver_current_inflight_requests, scheduler_pending_pods, scheduler_scheduling_attempt_duration_seconds, scheduler_preemption_victims, workqueue_depth, node_collector_evictions_total) và câu hỏi vận hành mỗi metric trả lời; cơ chế DaemonSet scraping của managed collection và lý do nó scale tốt hơn central Prometheus; spec chi tiết của PodMonitoring/ClusterPodMonitoring/Rules/ClusterRules CRD; mô hình cardinality và công thức chi phí của Managed Service for Prometheus; kiến trúc Instrumentation CRD và in-cluster OTLP endpoint của Managed OpenTelemetry; sự khác biệt giữa Custom Metrics Stackdriver Adapter và Prometheus Adapter cho HPA; bốn loại audit log và hệ quả chi phí/compliance; cAdvisor throttling metric và cách đọc CPU CFS throttling; DCGM GPU metric (DCGM_FI_DEV_GPU_UTIL, DCGM_FI_DEV_FB_USED, DCGM_FI_DEV_POWER_USAGE); và workflow correlate dashboard → metric → log → trace khi điều tra một incident thật. Mọi tuyên bố kỹ thuật đối chiếu trực tiếp tài liệu Google Cloud.
Cấu trúc chapter
1. Observability Stack — Telemetry Phân Tầng & Mental Model
Khung tư duy nền tảng: ba tầng telemetry và ba loại signal.
- Ba tầng telemetry: control plane (Google quản lý, bạn opt-in quan sát) → system (node, kubelet, container) → workload (application metric, log, trace)
- Ba loại signal: metric (time series, rẻ để lưu, tốt cho alerting), log (sự kiện rời rạc, đắt, tốt cho forensics), trace (request path qua nhiều service, tốt cho latency breakdown)
- Tích hợp GKE ↔ Google Cloud Observability: Cloud Monitoring, Cloud Logging, Cloud Trace, Managed Service for Prometheus
- Mô hình resource label nhất quán (
project_id,location,cluster,namespace,pod) — nền tảng của correlation - Khung quyết định: signal nào cho câu hỏi nào, và mô hình chi phí của mỗi loại
2. Control Plane Metrics — Quan Sát Bộ Não Cluster
Metric của API server, scheduler, controller-manager, etcd và cách bật.
- Vì sao control plane metric không bật mặc định, và cách opt-in qua
--monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER - API server:
apiserver_request_total(rate/error theo verb/code),apiserver_request_duration_seconds(latency percentile),apiserver_storage_objects,apiserver_current_inflight_requests, etcd op latency, admission webhook duration - Scheduler:
scheduler_pending_pods(active/backoff/unschedulable queue),scheduler_scheduling_attempt_duration_seconds,scheduler_schedule_attempts_total, preemption metric - Controller-manager:
workqueue_depth,workqueue_adds_total, reconciliation duration,node_collector_evictions_total - Mô hình chi phí: control plane metric đi qua Managed Service for Prometheus, tính phí theo sample ingest
3. System & Workload Metrics — kube-state-metrics, cAdvisor, DCGM GPU
Metric tầng hạ tầng: trạng thái Kubernetes object, tài nguyên container, GPU.
- System metrics (bật mặc định): CPU/memory/disk node, network, ephemeral storage
- kube-state-metrics (
kube_*): trạng thái Pod/Deployment/StatefulSet/DaemonSet/HPA/PVC — bật theo gói (POD,DEPLOYMENT,STATEFULSET,DAEMONSET,HPA,STORAGE) - cAdvisor/kubelet (
container_*):container_cpu_usage_seconds_total,container_memory_working_set_bytes, và đặc biệtcontainer_cpu_cfs_throttled_periods_totalđể phát hiện CPU throttling - DCGM GPU metrics:
DCGM_FI_DEV_GPU_UTIL,DCGM_FI_DEV_FB_USED/FREE,DCGM_FI_DEV_POWER_USAGE, profiling metric, XID error — yêu cầu Google-managed GPU driver - Mô hình chi phí và cardinality của kube-state-metrics ở cluster lớn
4. Application Metrics, Startup Latency & Cost Allocation
Metric tầng workload, đo độ trễ khởi động, và phân bổ chi phí theo namespace.
- Application metrics: auto-instrumentation vs custom metric, golden signals (rate/error/duration/saturation), cách app đẩy metric lên Cloud Monitoring/Managed Prometheus
- Monitor startup latency: phân rã Pod initialization — image pull, init container, readiness probe — bằng Pod/container metric và event
- GKE cost allocation / usage metering: phân bổ chi phí theo namespace/label, requested vs consumed, label
k8s-namespace/k8s-workload-name, export qua detailed billing BigQuery - Mối liên hệ giữa observability và FinOps: metric utilization → rightsizing → tiết kiệm
5. GKE Logs — System, Workload, Audit & Log Control
Toàn bộ logging stack và cách kiểm soát chi phí log.
- Logging agent fluent-bit per-node, các gói log:
SYSTEM,WORKLOAD,API_SERVER,SCHEDULER,CONTROLLER_MANAGER - System component logs: kubelet, container runtime, kube-system Pod
- Workload logs: stdout/stderr → Cloud Logging, structured logging (JSON payload), severity parsing
- Audit logs: bốn loại (Admin Activity, Data Access, System Event, Policy Denied), Kubernetes audit log, retention, routing qua log sink
- Log control: exclusion filter, sampling, tắt workload log (
--logging=SYSTEM), tách bucket, export BigQuery/Pub/Sub
6. Managed Service for Prometheus — PodMonitoring, Rules, PromQL
Stack Prometheus được Google quản lý — chuẩn de facto cho application metric trên GKE.
- Kiến trúc managed collection:
gmp-operator,collectorDaemonSet (scrape colocated node),rule-evaluator,alertmanager— và vì sao push model scale tốt - PodMonitoring (namespace-scoped) và ClusterPodMonitoring (cluster-wide): spec
selector/endpoints/interval/port/metricRelabeling - Rules / ClusterRules / GlobalRules và AlertmanagerConfig: recording rule, alerting rule, routing thông báo
- PromQL trong Cloud Monitoring: query qua giao diện, Grafana với Cloud Monitoring làm datasource
- High cardinality: label explosion,
exported_prefix,metricRelabelingdrop/keep để kiểm soát chi phí
7. Managed OpenTelemetry & Custom Metrics cho HPA
Pipeline trace/metric/log qua OpenTelemetry và cách metric nuôi HPA.
- Managed OpenTelemetry cho GKE: managed collection (in-cluster OTLP endpoint
:4318) + automatic configuration quaInstrumentationCRD; signal routing tới Cloud Trace/Monitoring/Logging - Google-Built OpenTelemetry Collector: khi nào cần collector tự quản để filter/transform
- Custom metric cho HPA: Custom Metrics Stackdriver Adapter vs Prometheus Adapter (không chạy đồng thời), External/Pods metric, ví dụ HPA tham chiếu Prometheus metric
- ServiceMonitor/PodMonitor pattern: tương thích prometheus-operator, cross-ref Chương 9 KEDA
8. Self-Managed Observability — Elastic Stack trên GKE
Khi nào tự vận hành observability stack và đánh đổi gì.
- Vì sao một số tổ chức chạy self-managed (data sovereignty, multi-cloud, log analytics nâng cao, tránh lock-in)
- Elastic Stack (ECK): Elasticsearch + Kibana + Beats/Fluentd trên GKE qua Elastic Cloud on Kubernetes operator
- Performance tuning: StatefulSet với PD/Hyperdisk, JVM heap, shard sizing, ILM (index lifecycle management), hot-warm-cold tiering
- Đánh đổi managed vs self-managed: chi phí vận hành, scale, độ tin cậy — khung quyết định
- Pattern hybrid: managed metric (Cloud Monitoring) + self-managed log analytics (Elastic)
9. Troubleshooting & Dashboard — Tích Hợp Metrics, Logs, Traces
Đưa mọi thứ về một workflow điều tra incident thực tế.
- GKE dashboard trong Cloud Console: cluster overview, health signal, Observability tab, tích hợp control plane metric
- GKE-native troubleshooting: từ dashboard → metric spike → log entry → trace
- Workflow correlate: dùng resource label chung để nhảy giữa các signal
- Các kịch bản điều tra điển hình: Pod Pending, OOMKill, latency spike, API server overload, node not ready
- Alerting strategy: SLO-based alert, golden signal, tránh alert fatigue
Bản đồ tinh thần: ba tầng telemetry của GKE
Trước khi đi vào từng file, hãy ghim mô hình ba tầng này. Nó là khung tham chiếu cho mọi quyết định observability trong chương. Mỗi tầng có một chủ thể quản lý, một bộ signal đặc trưng, và một mô hình bật/chi phí riêng.
| Tầng | Ai sinh ra | Signal đặc trưng | Cách bật | File |
|---|---|---|---|---|
| Control plane | Google (managed) | apiserver_*, scheduler_*, workqueue_*, etcd latency | Opt-in --monitoring=API_SERVER,SCHEDULER,CONTROLLER_MANAGER | 2 |
| System / node | kubelet, cAdvisor, OS | CPU/mem/disk node, container_*, kube_*, DCGM GPU | System mặc định; kube-state/cAdvisor/DCGM opt-in | 3 |
| Workload / application | Code của bạn | Golden signals, custom metric, log stdout/stderr, trace | Instrument app + PodMonitoring/OTel | 4, 6, 7 |
| Logs (xuyên tầng) | Mọi tầng | System/workload/audit log | --logging packages | 5 |
Ba quan sát quan trọng từ mô hình này:
Tầng càng cao (gần workload), bạn càng chịu trách nhiệm nhiều hơn. Control plane metric do Google phát ra, bạn chỉ cần bật; system metric do agent GKE thu tự động; nhưng application metric và trace chỉ tồn tại nếu bạn instrument code. Observability ở tầng cao nhất không phải là thứ bật được bằng một flag — nó là một kỷ luật engineering xuyên suốt vòng đời phát triển.
Mỗi tầng có một mô hình chi phí khác nhau, và chi phí là một quyết định thiết kế. Metric rẻ và nén tốt; log đắt hơn nhiều theo volume; audit Data Access log có thể bùng nổ; application metric high-cardinality là cái bẫy chi phí lớn nhất. Một stack observability tốt là stack mà mỗi signal được bật có chủ đích vì nó trả lời một câu hỏi vận hành cụ thể, không phải bật theo quán tính.
Correlation chỉ hoạt động khi mọi tầng chia sẻ resource label chung.
project_id,location,cluster,namespace,podlà sợi chỉ xuyên qua metric, log, trace. Đây là lý do tích hợp native GKE ↔ Google Cloud Observability có giá trị: mọi signal tự động mang cùng bộ nhãn, nên có thể nhảy từ một điểm bất thường trên dashboard sang đúng log và đúng trace mà không cần ghép thủ công.
Khung quyết định observability (tóm tắt)
Đây là ma trận quyết định cốt lõi của chương. Mỗi dòng là một câu hỏi vận hành thật, file tương ứng đào sâu.
| Câu hỏi vận hành | Signal cần nhìn | Nơi tìm | File |
|---|---|---|---|
kubectl chậm, API timeout | apiserver_request_duration_seconds, inflight, APF | Control plane metric | 2 |
| Pod kẹt Pending | scheduler_pending_pods, scheduler event, CA log | Scheduler metric + event | 2, 9 |
| Pod bị OOMKilled | container_memory_working_set_bytes, kube event, log | cAdvisor + log | 3, 5 |
| Service chậm bất thường | application latency metric + distributed trace | App metric + Cloud Trace | 4, 7 |
| Container bị throttle CPU | container_cpu_cfs_throttled_periods_total | cAdvisor | 3 |
| GPU under-utilized / lãng phí | DCGM_FI_DEV_GPU_UTIL, DCGM_FI_DEV_FB_USED | DCGM metric | 3 |
| Chi phí cluster phân bổ ra sao | cost allocation label theo namespace | Billing export | 4 |
| Ai đã xóa/sửa resource | Admin Activity / Data Access audit log | Cloud Logging | 5 |
| Cần autoscale theo metric tùy biến | custom/external metric qua adapter | Managed Prometheus + adapter | 6, 7 |
| Hóa đơn observability tăng vọt | cardinality metric, log volume | metricRelabeling + log exclusion | 5, 6 |
Năm sai lầm xuyên suốt thường gặp ở cấp chương
Không bật control plane metric cho đến khi đã có sự cố. Khi API server quá tải hoặc scheduler không xếp được Pod, không có dữ liệu lịch sử để biết baseline bình thường là gì. Đúng: bật
API_SERVER,SCHEDULER,CONTROLLER_MANAGERtừ đầu, thiết lập alert trên latency percentile và pending pods (file 2).Cardinality explosion trong application metric. Nhúng
user_id,request_id,emaillàm label Prometheus. Mỗi giá trị duy nhất tạo một time series mới; vài triệu series làm hóa đơn Managed Prometheus bùng nổ và query chậm. Đúng: chỉ dùng label bounded (route, status code, method), drop label cao bằngmetricRelabeling(file 6).Coi log là kho lưu trữ vô hạn miễn phí. Bật toàn bộ Data Access audit log và workload log debug mà không có exclusion, để Cloud Logging ingest hàng TB/ngày. Đúng: exclusion filter cho log nhiễu, sampling, tách bucket retention ngắn, export cái cần forensics sang BigQuery (file 5).
Có metric/log/trace nhưng không correlate được. Dùng stack rời rạc không chia sẻ resource label, nên khi điều tra phải ghép thủ công giữa ba hệ thống. Đúng: dùng tích hợp native GKE với resource label nhất quán, hoặc đảm bảo self-managed stack cũng gắn cùng nhãn (file 1, 9).
Instrument tất cả hoặc không instrument gì. Hoặc bỏ qua application observability hoàn toàn (chỉ có system metric, không biết gì về business logic), hoặc auto-instrument mọi thứ không suy nghĩ rồi ngập trong noise. Đúng: instrument theo golden signal cho mỗi service quan trọng, sampling trace có chủ đích (file 4, 7).
Cross-reference với Google Cloud Architecture Framework
- Operational excellence pillar: observability là nền tảng của vận hành xuất sắc — không thể vận hành thứ bạn không quan sát được. Toàn bộ chương là hiện thân của trụ cột này (Operational excellence pillar).
- Reliability pillar: SLO, golden signal, alerting dựa trên error budget đều xây trên metric của chương này. Quan sát đúng là tiền đề của độ tin cậy đo lường được (Reliability pillar).
- Cost optimization pillar: cost allocation, cardinality control, log exclusion — observability vừa là công cụ FinOps (rightsizing từ utilization metric) vừa là một hạng mục chi phí cần tối ưu (Cost optimization pillar).
References chung của chapter
- Observability for GKE
- Control plane metrics
- View GKE observability metrics
- About GKE logs
- Google Cloud Managed Service for Prometheus
- Managed collection setup
- Managed OpenTelemetry for GKE
- HPA with Managed Service for Prometheus
- DCGM GPU metrics
- GKE cost allocation
- GKE audit logging
Bảng thuật ngữ then chốt của chương
| Thuật ngữ | Ý nghĩa ngắn gọn |
|---|---|
| Control plane metrics | Metric API server/scheduler/controller-manager/etcd, opt-in (file 2) |
| System metrics | Metric node/kubelet, bật mặc định (file 3) |
| kube-state-metrics | Trạng thái Kubernetes object dạng metric kube_* (file 3) |
| cAdvisor | Metric tài nguyên container container_* (file 3) |
| DCGM | NVIDIA Data Center GPU Manager, metric GPU (file 3) |
| Golden signals | Rate, Error, Duration, Saturation (file 4) |
| Cost allocation | Phân bổ chi phí cluster theo namespace/label (file 4) |
| Audit log (4 loại) | Admin Activity, Data Access, System Event, Policy Denied (file 5) |
| Log Router / sink | Định tuyến log tới bucket/BigQuery/Pub/Sub (file 5) |
| Managed Service for Prometheus | Stack Prometheus do Google quản lý (file 6) |
| PodMonitoring / ClusterPodMonitoring | CRD khai báo scrape target (file 6) |
| Managed collection | Collector DaemonSet scrape colocated node, push model (file 6) |
| Cardinality | Số lượng time series; cao = đắt + chậm (file 6) |
| Managed OpenTelemetry | OTLP collector in-cluster + Instrumentation CRD (file 7) |
| Custom Metrics Stackdriver Adapter | Expose Cloud Monitoring metric cho HPA (file 7) |
| ECK | Elastic Cloud on Kubernetes operator (file 8) |
| Correlation | Nối metric/log/trace qua resource label chung (file 1, 9) |
Kết luận của chapter
Observability trên GKE là môn học về cấu trúc telemetry phân tầng và nghệ thuật correlate. Mỗi signal trong chương này tồn tại để trả lời một câu hỏi ở một tầng cụ thể: control plane metric trả lời "bộ não cluster có khỏe không"; system metric trả lời "hạ tầng node có đủ tài nguyên không"; application metric và trace trả lời "code của tôi hành xử ra sao"; log trả lời "chuyện gì đã thực sự xảy ra"; audit log trả lời "ai đã làm gì". Giá trị không nằm ở việc thu thập nhiều — nó nằm ở việc biết nhìn tầng nào cho câu hỏi nào, và nối các tầng lại qua resource label chung để đi từ triệu chứng tới nguyên nhân.
Cách dùng chương hiệu quả nhất là biến mỗi file thành một chuẩn vận hành: chuẩn về quan sát control plane (file 2), chuẩn về metric hạ tầng và GPU (file 3), chuẩn về application observability và FinOps (file 4), chuẩn về logging và audit (file 5), chuẩn về metric pipeline với Managed Prometheus (file 6), chuẩn về trace và autoscaling metric (file 7), chuẩn về lựa chọn managed vs self-managed (file 8), và chuẩn về workflow điều tra incident (file 9). Khi đó observability chuyển từ "một đống dashboard không ai nhìn" thành một hệ thống quan sát có chủ đích, nơi mọi signal đều có lý do tồn tại, mọi tầng đều debug được, và chi phí được kiểm soát — đúng tinh thần vận hành mà mọi production cluster ở quy mô lớn buộc phải theo.