Quan sát hệ thống trong Kubernetes

Quan sát hệ thống (observability) trong Kubernetes được xây dựng quanh ba loại dữ liệu: metric, log và trace. Mỗi loại có pipeline riêng nhưng chia sẻ chung pattern: thu thập trên node hoặc qua sidecar, xử lý/buffer trung gian, lưu trong store chuyên dụng, hợp nhất ở tầng visualize. Cấu trúc này quyết định cách chia namespace, cách scale và cách chịu lỗi của toàn bộ observability stack.

Nguồn: Monitoring, Logging, and Debugging — Kubernetes docs, The Three Pillars of Observability — Cindy Sridharan.

Ba pillar dữ liệu

Metric là số theo thời gian, organize theo timeseries với label. Trong Kubernetes, metric đến từ nhiều layer: kubelet (per-container qua cAdvisor), node (node-exporter), control plane (kube-state-metrics), application (/metrics endpoint Prometheus format). Cùng đặc tính: thấp về kích thước per data point, cao về tần suất, query bằng PromQL.

Log là text không cấu trúc hoặc semi-structured do container ghi ra stdout/stderr. Container runtime ghi log ra file trên host (mặc định /var/log/containers/); collector chạy DaemonSet trên mỗi node để tail file đó. Đặc tính: kích thước per record lớn hơn metric nhiều lần, cardinality cao, query bằng label + grep.

Trace là cây span thể hiện đường đi của một request qua nhiều service. Khác metric/log ở chỗ phải có context propagation (trace ID + span ID) qua header HTTP/gRPC. Trace data thường được sample (ví dụ 1% request) để giảm áp lực store.

Kiến trúc layer điển hình

flowchart LR
    APP[Application pod]
    NODE[Node]
    APP -->|metric pull| MC[Prometheus]
    NODE -->|metric pull| MC
    APP -->|stdout| LC[Log collector]
    NODE -->|file tail| LC
    APP -->|trace push| TC[Trace collector]
    MC -->|remote_write| MS[Metric store]
    LC -->|stream| LB[Log buffer]
    LB --> LS[Log store]
    TC --> TS[Trace store]
    MS --> DASH[Grafana]
    LS --> DASH
    TS --> DASH

Pipeline mỗi pillar đều có 4 vai trò:

Vai trò Metric Log Trace
Collector Prometheus scrape Fluent Bit / Promtail / Vector OTel collector / Jaeger agent
Buffer/Processor (thường không có) Kafka, Fluent Bit processor Kafka (tuỳ chọn)
Store Cortex / Mimir / Thanos Loki / Elasticsearch Jaeger backend (Cassandra/ES)
Visualize Grafana / Prometheus UI Grafana / Kibana Jaeger UI / Grafana

Tách bốn vai trò cho phép scale từng layer độc lập và đổi component mà không phải đập cả pipeline.

Chia namespace theo layer

Mô hình triển khai phổ biến là một namespace per layer: obs-storage (MinIO, Cassandra), obs-metric (Prometheus + Cortex), obs-log (Loki + Fluent Bit), obs-tracing (Jaeger), obs-dashboard (Grafana). Lý do: từng layer có thể redeploy/clean độc lập, RBAC tách bạch, và NetworkPolicy có thể policy-based isolation giữa các layer. Yêu cầu CNI hỗ trợ NetworkPolicy — kindnet trong kind không hỗ trợ, phải đổi sang Calico hoặc Cilium.

Storage backend chia sẻ

Trên on-prem không có S3 thật, một MinIO cluster có thể làm S3-compat backend cho cả Cortex (metric chunk/block) lẫn Loki (log chunk + index). Cassandra thường được Jaeger dùng riêng vì write pattern của trace (heavy write, append-only) khác với object-store cho metric/log. Phân tách backend theo workload thay vì theo team là quyết định kiến trúc quan trọng — nó giúp tối ưu chi phí và operational complexity.

Vai trò của service mesh

Service mesh (Linkerd, Istio) cung cấp một nguồn metric phụ rất mạnh: golden metrics (RPS, success rate, latency) cho mọi connection HTTP/gRPC giữa pod mà không cần code instrument. Mesh proxy tự scrape được bởi Prometheus. Đây là cách rẻ nhất để có “site reliability dashboard” cho legacy service không export metric. Chi tiết ở Service mesh làm tầng quan sát.

Cập nhật: 2026-05-29