GKE Logs — System, Workload, Audit & Log Control

Why this matters in production

Metric trả lời "cái gì bất thường"; log trả lời "chuyện gì đã thực sự xảy ra". Khi một Pod bị OOMKilled, metric container_memory_working_set_bytes cho thấy working set chạm trần, nhưng chỉ log mới cho biết stack trace cuối cùng trước khi process chết. Khi một resource bị xóa bí ẩn, chỉ audit log mới cho biết principal nào, lúc nào, qua API call gì. Log là signal không thể thay thế cho forensics (điều tra sau sự cố) và audit/compliance (ai làm gì) — nhưng cũng là signal đắt nhất và dễ bùng nổ chi phí nhất trong cả stack observability.

Đây là nghịch lý trung tâm của logging ở quy mô production: log vừa thiết yếu vừa nguy hiểm về chi phí. Một cluster vài trăm node với workload verbose có thể ingest hàng TB log mỗi ngày vào Cloud Logging, và vì Cloud Logging tính phí theo volume ingest, hóa đơn log dễ vượt cả compute nếu không kiểm soát. Kỹ năng cốt lõi ở đây không phải "thu thập log" — GKE làm điều đó mặc định — mà là biết loại log nào cần giữ, giữ bao lâu, ở đâu, và loại nào nên loại bỏ hoặc sampling.

Theo tài liệu about GKE logs, GKE triển khai một logging agent per-node (dựa trên fluent-bit) tự động route log tới Cloud Logging. Agent thêm metadata (resource label cluster/namespace/pod/container) — chính bộ nhãn này khâu log với metric và trace (file 01).

Internal model: kiến trúc logging và các gói log

Logging agent và đường đi của log

Mỗi node GKE chạy một logging agent (fluent-bit-based) như một DaemonSet do GKE quản lý. Agent:

1. Đọc log từ container runtime (stdout/stderr của mọi container) và từ các nguồn hệ thống (kubelet, container runtime, VM startup).
2. Thêm metadata Kubernetes (pod, namespace, container, node, label).
3. Đẩy lên Cloud Logging, nơi log đi qua Log Router.

Log Router là điểm điều khiển then chốt: mọi log entry chảy qua đây, và tại đây bạn quyết định nó được ingest vào bucket nào, bị exclude, hay export sang BigQuery/Pub/Sub/Cloud Storage. Hiểu Log Router là chìa khóa kiểm soát chi phí log.

Các gói log bật qua --logging

Tương tự metric, log được tổ chức thành gói, bật qua flag --logging:

Gói	Giá trị	Nội dung	Mặc định
System	SYSTEM	kubelet, container runtime, VM startup, kube-system Pod	Bắt buộc
Workload	WORKLOAD	stdout/stderr của container non-system	Bật (có thể tắt)
API server	API_SERVER	Log chi tiết kube-apiserver	Opt-in
Scheduler	SCHEDULER	Log scheduler	Opt-in
Controller-manager	CONTROLLER_MANAGER	Log controller-manager	Opt-in

Có thêm các gói control plane chuyên biệt (ví dụ liên quan đến HPA decision, connection, sshd) tùy phiên bản. Điểm thiết kế quan trọng: bạn có thể tắt workload log (--logging=SYSTEM) để cắt phần lớn volume nếu dùng stack log khác cho workload (file 08) — nhưng giữ system log để vẫn quan sát hạ tầng.

System component logs

Log của các thành phần hệ thống: kubelet (quyết định eviction, mount volume, probe), container runtime (containerd, pull image, start container), và Pod trong kube-system (DNS, CNI, csi driver). Đây là nơi tìm nguyên nhân khi Pod không start, volume không mount, hay node NotReady. Ví dụ: log kubelet ghi rõ lý do OOMKill, lý do evict, kết quả image pull với thời lượng.

Workload logs — stdout/stderr và structured logging

GKE thu mọi thứ container ghi ra stdout/stderr và đẩy lên Cloud Logging. Đây là cơ chế "miễn phí có sẵn" cho app log — chỉ cần ghi ra stdout, không cần cấu hình. Điểm tối ưu quan trọng: structured logging. Nếu app ghi log dạng JSON, Cloud Logging tự parse thành jsonPayload với các field truy vấn được, và quan trọng nhất là parse đúng severity (INFO/WARNING/ERROR). Ngược lại, log text thuần được lưu là textPayload không cấu trúc, severity mặc định, khó query và lọc. Pattern đúng cho production: log JSON với field severity, message, và các field nghiệp vụ — để có thể lọc "mọi log ERROR của service X trong namespace Y" hiệu quả.

Internal model: audit logs

Audit log là một loại telemetry đặc biệt — nó không về performance mà về trách nhiệm giải trình: ai đã làm gì, lúc nào, qua API nào. Theo tài liệu Cloud Audit Logs, có bốn loại:

• Admin Activity — ghi mọi thao tác thay đổi cấu hình (tạo/sửa/xóa cluster, node pool, IAM binding). Luôn bật, không tắt được, miễn phí. Đây là dấu vết "ai thay đổi gì" — không thể thiếu cho mọi cluster.

• Data Access — ghi thao tác đọc dữ liệu/metadata và thao tác do người dùng khởi tạo trên dữ liệu. Phải bật tường minh, tốn phí (volume lớn vì đọc rất nhiều). Đây là loại log dễ bùng nổ chi phí nhất — bật toàn bộ Data Access trên cluster bận có thể tạo hàng TB log. Bật có chọn lọc theo service và principal.

• System Event — ghi sự kiện do hệ thống GCP tự thực hiện (ví dụ GKE auto-repair, auto-upgrade). Luôn bật, miễn phí.

• Policy Denied — ghi khi một request bị từ chối bởi policy (Org Policy, VPC Service Controls). Hữu ích để debug "vì sao bị chặn" (Chương 10, 12).

Ngoài bốn loại trên ở tầng GCP API, GKE còn phơi bày Kubernetes audit log — audit của chính kube-apiserver, ghi mọi request tới Kubernetes API (ai gọi gì, được/bị từ chối). Đây là dấu vết forensics quan trọng nhất khi điều tra security incident trong cluster (ai tạo Pod privileged, ai đọc Secret). Kubernetes audit log ánh xạ vào Cloud Logging với resource type tương ứng và query được như log khác.

Internal model: log control và kiểm soát chi phí

Đây là phần phân biệt một stack log trưởng thành. Cloud Logging tính phí theo volume ingest, nên kiểm soát volume là kỹ năng vận hành cốt lõi. Các cơ chế:

• Exclusion filter (ở Log Router): loại bỏ log khớp một filter trước khi ingest — không tính phí. Đây là công cụ mạnh nhất. Ví dụ: loại health check log (/healthz 200), loại log của một namespace dev nhiễu, loại log severity thấp của một service verbose. Log bị exclude vẫn có thể route sang nơi khác (export) trước khi exclude.

• Sampling: giữ một phần log thay vì toàn bộ. Hữu ích cho log volume cực lớn nhưng cần giữ một mẫu đại diện (ví dụ giữ 10% access log).

• Tắt workload log: --logging=SYSTEM cắt toàn bộ workload log nếu dùng stack khác (Elastic, file 08). Quyết định mạnh, dùng khi đã có pipeline log riêng.

• Log bucket và retention: tách log vào các bucket với retention khác nhau. Audit log cần giữ lâu (compliance) → bucket retention dài; debug log chỉ cần vài ngày → bucket retention ngắn (rẻ hơn). Mặc định log giữ 30 ngày; tùy chỉnh theo nhu cầu.

• Export qua sink: route log sang BigQuery (phân tích SQL, file 09), Pub/Sub (streaming tới SIEM/Elastic), hoặc Cloud Storage (lưu trữ rẻ dài hạn cho compliance). Sink cho phép giữ cái cần ở nơi rẻ mà không ingest đắt vào Cloud Logging.

Production architecture patterns

Phân tầng log theo giá trị và retention

Pattern chuẩn production: (1) Audit log → bucket retention dài + export Cloud Storage cho compliance; (2) System log → giữ 30 ngày trong Cloud Logging cho troubleshooting; (3) Workload ERROR/WARNING log → giữ; (4) Workload DEBUG/INFO verbose → exclusion hoặc sampling. Nguyên tắc: giá trị forensics cao + tần suất thấp = giữ lâu; volume cao + giá trị thấp = exclude/sample.

Structured logging bắt buộc qua platform standard

Pattern platform engineering: chuẩn hóa mọi service ghi log JSON với schema chung (severity, trace, span_id, message, business fields). Field trace đặc biệt giá trị — nó cho phép Cloud Logging liên kết log entry với trace tương ứng (file 07), hoàn thiện correlation metric↔log↔trace.

Export sang SIEM cho security

Pattern security (Chương 12): route audit log và Kubernetes audit log qua Pub/Sub sink tới SIEM (Chronicle, Splunk) để phát hiện threat real-time, đồng thời giữ bản sao Cloud Storage cho điều tra. Audit log là nguồn detection chính cho lateral movement và privilege escalation.

Real-world scenarios

Kịch bản 1 — Hóa đơn Cloud Logging tăng gấp ba. Một team bật toàn bộ Data Access audit log "cho an toàn" trên cluster production bận. Trong một tuần, volume log tăng gấp ba, hóa đơn observability vượt compute. Phân tích cho thấy 80% volume là Data Access log của các read operation thường lệ không ai từng query. Giải pháp: tắt Data Access toàn cục, chỉ bật cho service nhạy cảm + thêm exclusion filter cho health check log. Volume giảm 75%.

Kịch bản 2 — Forensics một resource bị xóa. Một Deployment production biến mất lúc 02:00. Admin Activity audit log (luôn bật) cho thấy chính xác: principal ci-deployer@project.iam.gserviceaccount.com đã gọi delete lúc 02:00:13 — một CI pipeline có bug chạy kubectl delete nhầm namespace. Không có audit log, đây sẽ là một bí ẩn không bao giờ giải được.

Kịch bản 3 — Debug OOMKill liên hoàn. Pod restart theo chu kỳ (file 03). Kết hợp: metric container_memory_working_set_bytes cho thấy working set chạm trần, kubelet system log ghi rõ Memory cgroup out of memory: Killed process, và workload log (JSON, severity ERROR) ngay trước đó cho thấy một request xử lý batch lớn bất thường ngốn memory. Ba nguồn log/metric khâu lại bằng cùng pod label cho bức tranh đầy đủ.

Common mistakes / anti-patterns

• Bật toàn bộ Data Access audit log không chọn lọc. Volume bùng nổ, chi phí vượt tầm kiểm soát. Đúng: chỉ bật cho service/data nhạy cảm cần compliance, dùng exclusion cho phần nhiễu.

• Log text thuần thay vì JSON. Mất khả năng query theo field và severity, mất correlation với trace. Đúng: structured logging JSON với severity và trace field.

• Không exclusion health check / probe log. Health check chạy mỗi vài giây × hàng nghìn Pod = volume khổng lồ giá trị bằng không. Đúng: exclusion filter cho /healthz, /readyz 200.

• Coi mọi log cùng một retention. Giữ debug log 30 ngày đắt vô ích, giữ audit log chỉ 30 ngày vi phạm compliance. Đúng: tách bucket theo retention phù hợp giá trị.

• Không export audit log cho compliance. Audit log mặc định 30–400 ngày tùy loại; compliance thường yêu cầu lâu hơn. Đúng: sink sang Cloud Storage retention dài.

GCP-native implementation guidance

Cấu hình gói log (giữ system + workload + control plane chọn lọc):

gcloud container clusters update CLUSTER_NAME \
  --location=LOCATION \
  --logging=SYSTEM,WORKLOAD,API_SERVER

Tắt workload log khi dùng stack log riêng (cắt volume):

gcloud container clusters update CLUSTER_NAME \
  --location=LOCATION \
  --logging=SYSTEM

Exclusion filter loại health check log (giảm chi phí ingest) — qua Log Router:

gcloud logging sinks update _Default \
  --add-exclusion=name=exclude-health-checks,filter='
    resource.type="k8s_container"
    AND httpRequest.requestUrl=~"/healthz|/readyz"
    AND httpRequest.status=200'

Query forensics điển hình (Logs Explorer) — tìm ai xóa resource:

logName=~"cloudaudit.googleapis.com%2Factivity"
resource.type="k8s_cluster"
protoPayload.methodName=~"delete"
protoPayload.resourceName=~"deployments/critical-app"

Official references

• About GKE logs — agent, gói log, routing
• Configure GKE logs — flag --logging
• GKE audit logging — Kubernetes audit log
• Cloud Audit Logs overview — bốn loại audit log
• Log Router & sinks — exclusion, export
• Structured logging — JSON payload, severity
• Manage logging costs — kiểm soát volume

---

Tóm lại: log là signal không thể thay thế cho forensics và audit, nhưng đắt và dễ bùng nổ. System log cho hạ tầng, workload log (nên là JSON structured) cho app, audit log cho trách nhiệm giải trình — với Admin Activity luôn bật miễn phí và Data Access tốn phí phải bật chọn lọc. Làm chủ Log Router (exclusion, sampling, bucket retention, sink export) là kỹ năng quyết định để giữ chi phí log trong tầm kiểm soát mà không mất khả năng điều tra.