Troubleshooting & Dashboard — Tích Hợp Metrics, Logs, Traces

Why this matters in production

Tám file trước xây dựng từng mảnh của stack observability: control plane metric, system metric, application metric, log, Managed Prometheus, OpenTelemetry. File này trả lời câu hỏi cuối cùng và quan trọng nhất: khi một incident thực sự xảy ra lúc 03:00, bạn dùng tất cả những thứ đó như thế nào để đi từ triệu chứng tới nguyên nhân nhanh nhất? Observability chỉ có giá trị nếu nó rút ngắn được MTTR (mean time to resolution) — và điều đó đòi hỏi một workflow, không chỉ một đống dashboard.

Sai lầm phổ biến của các đội chưa trưởng thành không phải thiếu dữ liệu mà là không có quy trình correlate dữ liệu. Họ có metric, có log, có trace — nhưng khi sự cố xảy ra, họ nhảy ngẫu nhiên giữa các tab, đoán mò, và mất hàng giờ cho thứ lẽ ra mất vài phút. Đội trưởng thành có một workflow nhất quán: bắt đầu từ một điểm bất thường, dùng resource label chung làm sợi chỉ, đi xuống tầng đúng. File này hệ thống hóa workflow đó và đưa ra các runbook điều tra cho những kịch bản phổ biến nhất.

Nền tảng kỹ thuật khiến workflow này khả thi đã được đặt ở file 01: mọi signal GKE chia sẻ resource label nhất quán (cluster/namespace/pod/container). Đây là thứ cho phép nhảy từ một metric spike sang đúng log dòng đó sang đúng trace của request đó mà không ghép thủ công.

Internal model: GKE dashboard trong Cloud Console

GKE cung cấp các dashboard tích hợp sẵn trong Cloud Console, là điểm khởi đầu của mọi cuộc điều tra:

• Cluster overview / GKE dashboard: trạng thái tổng thể các cluster — node ready, Pod theo trạng thái, alert đang active. Đây là "màn hình đầu tiên" để nắm sức khỏe toàn cảnh.

• Observability tab (trên trang cluster/workload): tab này tổng hợp metric của cluster/workload thành các view dựng sẵn — CPU/memory utilization, request rate, error rate. Quan trọng: nhiều view trong Observability tab yêu cầu bật control plane metric (file 02) để hiển thị đầy đủ tín hiệu API server/scheduler. Đây là lý do thực tiễn nữa để bật chúng từ đầu.

• Health signal / Cluster details: các tín hiệu sức khỏe (control plane, node pool, add-on) và liên kết nhanh tới log/metric liên quan.

• Workload details: cho mỗi Deployment/StatefulSet — Pod, revision, event, log, metric tập trung một chỗ, với liên kết "View logs" lọc sẵn theo workload.

Giá trị của các dashboard này không phải là chúng đẹp mà là chúng đã gắn sẵn resource label và liên kết chéo — từ một workload, một cú click sang log của đúng Pod, sang metric của đúng container. Chúng là điểm vào của workflow correlate.

Internal model: workflow correlate dashboard → metric → log → trace

Đây là phần cốt lõi. Một workflow điều tra nhất quán có bốn bước, đi từ tổng quát đến cụ thể, dùng resource label làm sợi chỉ:

Bước 1 — Phát hiện (metric/dashboard): "cái gì bất thường, ở đâu". Bắt đầu từ alert hoặc dashboard. Một golden signal vượt ngưỡng (latency p99, error rate) hoặc một health signal đỏ. Mục tiêu bước này chỉ là khoanh vùng: tầng nào (control plane / node / workload), namespace/workload nào. Đừng vội kết luận nguyên nhân — chỉ xác định nơi nhìn tiếp.

Bước 2 — Khoanh tầng (metric): "triệu chứng phát sinh ở tầng nào". Dùng ma trận tầng (file 01): latency app cao → kiểm tra song song application metric (bug app?), cAdvisor throttling (file 03, container bị bóp CPU?), node saturation (node hết tài nguyên?), và control plane (API server chậm làm mọi thứ chậm?). Đây là bước phân biệt đội trưởng thành: họ kiểm tra nhiều tầng cùng lúc thay vì chỉ nhìn tầng app rồi đoán.

Bước 3 — Chẩn đoán (log): "chuyện gì đã thực sự xảy ra". Khi đã khoanh được tầng và workload, nhảy sang log của đúng Pod/container đó (cùng pod label) trong Logs Explorer. Tìm dòng ERROR, stack trace, lý do OOMKill từ kubelet log, sự kiện eviction. Log cho chi tiết per-event mà metric không có.

Bước 4 — Định vị (trace): "độ trễ/lỗi nằm ở chặng nào". Nếu là vấn đề latency trong chuỗi microservice, mở trace (Cloud Trace, file 07) của request chậm để thấy span nào chiếm thời gian. Trace là bước cuối cô lập chính xác service/dependency thủ phạm.

Sợi chỉ xuyên suốt bốn bước là resource label: cùng cluster/namespace/pod cho phép mỗi bước lọc đúng phạm vi của bước trước. Đây chính là giá trị mà tích hợp native (hoặc nhãn nhất quán trong self-managed, file 08) mang lại — và là thứ một stack rời rạc không nhãn chung không làm được.

Production architecture patterns: runbook cho kịch bản điển hình

Pod kẹt Pending

1. Metric: scheduler_pending_pods{queue="unschedulable"} cao (file 02) → vấn đề scheduling, không phải app.
2. Event/log: kubectl describe pod hoặc Pod event trong Cloud Logging — thông điệp scheduler nêu rõ lý do (Insufficient cpu, node(s) didn't match affinity, had taint).
3. Khoanh nguyên nhân: thiếu capacity (kiểm tra Cluster Autoscaler log, Chương 9 — có noScaleUp không?), vi phạm affinity/taint (Chương 8), hay PVC chưa bind (Chương 11).

Pod bị OOMKilled

1. Metric: container_memory_working_set_bytes tiệm cận limit + kube_pod_container_status_restarts_total tăng (file 03).
2. Log: kubelet system log Memory cgroup out of memory: Killed process xác nhận; workload log ngay trước đó cho biết app đang làm gì (request batch lớn? memory leak?).
3. Nguyên nhân: limit quá thấp (nâng limit) vs leak thực sự (sửa app) — phân biệt bằng pattern working set (bậc thang đột ngột = batch; tăng tuyến tính = leak).

Latency spike

1. Metric: application latency p99 tăng; kiểm tra song song container_cpu_cfs_throttled_periods_total (throttling?), node saturation, downstream dependency metric.
2. Trace: mở trace request chậm → span nào chiếm thời gian (DB query? downstream call? gọi lặp N+1?).
3. Log: log của service thủ phạm tại thời điểm đó để biết chi tiết.

API server overload / kubectl chậm

1. Metric: apiserver_request_duration_seconds p99 cao, apiserver_current_inflight_requests chạm trần, apiserver_request_total{verb="LIST"} spike (file 02).
2. Khoanh thủ phạm: verb/resource nào spike → truy ra controller/operator gây tải (LIST thay vì watch?).
3. Nguyên nhân phụ: etcd latency cao (cluster chạm scale limit?), admission webhook chậm (apiserver_admission_webhook_admission_duration_seconds, Chương 10).

Node NotReady

1. Metric: node condition, node_collector_evictions_total spike (file 02).
2. Log: kubelet log của node, system event log (auto-repair?).
3. Nguyên nhân: hạ tầng (zone issue?), disk/memory pressure, network partition — tương quan với thời điểm và zone.

Internal model: alerting strategy — tránh alert fatigue

Có dashboard và metric chưa đủ; phải có alert đúng. Alert sai cách tạo hai thất bại đối xứng: quá nhiều alert (fatigue, đội ngũ tê liệt và bỏ qua cả alert thật) hoặc quá ít (sự cố không ai biết). Nguyên tắc:

• Alert trên symptom, không trên cause. Alert khi người dùng bị ảnh hưởng (latency/error vượt SLO), không phải mỗi khi một metric nội bộ chệch. "CPU node 80%" không đáng page nếu user không bị ảnh hưởng; "error rate vượt SLO" thì đáng. Cause để điều tra, symptom để alert.

• SLO-based alerting với burn rate. Thay vì ngưỡng tĩnh, alert theo tốc độ tiêu error budget (Chương 9): burn rate nhanh (đốt budget tháng trong vài giờ) → page ngay; burn rate chậm → ticket. Cách này tự động cân bằng độ nhạy.

• Phân cấp severity. page (đánh thức người, cần hành động ngay) vs ticket (xem trong giờ làm) vs info (chỉ ghi nhận). Chỉ symptom ảnh hưởng user mới page.

• Mọi alert phải actionable + có runbook. Một alert không nói được "phải làm gì" là noise. Gắn runbook (như các kịch bản trên) vào alert.

• Golden signal làm xương sống. Tập alert tối thiểu cho mỗi service: error rate vượt SLO, latency p99 vượt SLO, saturation gần trần. Thêm alert hạ tầng then chốt (control plane latency, pending pods kéo dài, node eviction spike).

Real-world scenarios

Kịch bản 1 — Workflow correlate cắt MTTR từ giờ xuống phút. Alert "checkout error rate vượt SLO" kích hoạt. Bước 1: dashboard khoanh vùng workload checkout, namespace production. Bước 2: application metric cho thấy lỗi là 503 từ downstream payment; cAdvisor và node bình thường → không phải hạ tầng. Bước 3: log của payment Pod (cùng filter pod) cho thấy timeout tới gateway bên thứ ba. Bước 4: trace xác nhận span payment→stripe timeout 30s. Toàn bộ mất 6 phút nhờ workflow nhất quán, thay vì hàng giờ đoán mò.

Kịch bản 2 — Alert fatigue suýt che một sự cố thật. Một đội có 200 alert, phần lớn là ngưỡng tài nguyên tĩnh kêu liên tục. Đội đã quen mute. Một đêm, alert "error rate" thật bị chìm trong noise và phát hiện muộn 40 phút. Sau đó họ tái thiết kế: xóa alert cause-based, chỉ giữ SLO symptom-based + burn rate, giảm từ 200 xuống 15 alert actionable. Lần sự cố sau, alert thật nổi bật và được xử lý trong 5 phút.

Common mistakes / anti-patterns

• Không có workflow, chỉ có dashboard. Nhảy ngẫu nhiên giữa tab khi sự cố, đoán mò. Đúng: workflow bốn bước nhất quán (phát hiện → khoanh tầng → chẩn đoán → định vị).

• Chỉ nhìn một tầng rồi kết luận. Thấy latency app cao là đổ tại app, bỏ qua throttling/node/control plane. Đúng: kiểm tra nhiều tầng song song ở bước 2.

• Alert trên cause thay vì symptom. CPU/memory ngưỡng tĩnh tạo noise. Đúng: alert SLO symptom-based, page chỉ khi user bị ảnh hưởng.

• Alert không có runbook. Đội bị đánh thức mà không biết làm gì. Đúng: mỗi alert gắn runbook actionable.

• Bỏ qua control plane metric trong điều tra. Quên rằng API server chậm làm mọi thứ chậm. Đúng: luôn kiểm tra control plane khi triệu chứng lan rộng bất thường.

GCP-native implementation guidance

Lọc nhanh log của một workload trong cuộc điều tra (Logs Explorer):

resource.type="k8s_container"
resource.labels.cluster_name="prod-cluster"
resource.labels.namespace_name="production"
resource.labels.pod_name=~"checkout-.*"
severity>=ERROR

Tạo SLO burn-rate alert (khái niệm, qua Cloud Monitoring / alerting policy): alert khi tỷ lệ lỗi đốt error budget nhanh hơn ngưỡng — page ở burn rate cao (ví dụ 14.4× trong 1h), ticket ở burn rate thấp.

Query nhanh khoanh tầng control plane khi triệu chứng lan rộng:

# API server có phải nút thắt không?
histogram_quantile(0.99, sum by (le) (rate(apiserver_request_duration_seconds_bucket{verb!="WATCH"}[5m])))
# Có Pod nào kẹt unschedulable không?
sum(scheduler_pending_pods{queue="unschedulable"})

Official references

• GKE observability & troubleshooting — dashboard, Observability tab
• Troubleshoot GKE — runbook chính thức
• SLO monitoring — SLO, error budget
• Alerting policies — burn-rate, notification
• Logs Explorer — query log
• Cloud Trace analysis — phân tích trace
• Google SRE — alerting on SLOs — burn-rate alerting

---

Tóm lại: observability chỉ có giá trị khi nó rút ngắn MTTR, và điều đó đòi hỏi một workflow chứ không chỉ dashboard. Workflow bốn bước — phát hiện (metric/dashboard) → khoanh tầng (kiểm tra nhiều tầng song song) → chẩn đoán (log) → định vị (trace) — dùng resource label chung làm sợi chỉ, biến đống telemetry rời rạc thành con đường nhanh nhất tới nguyên nhân. Kết hợp với alerting SLO symptom-based, burn-rate, và runbook actionable, observability chuyển từ "dữ liệu thụ động" thành năng lực vận hành đo lường được — đúng đích đến của cả chương.