Self-Managed Observability — Elastic Stack trên GKE

Why this matters in production

Sau sáu file về stack observability managed của Google, file này đặt một câu hỏi ngược: khi nào nên tự vận hành observability thay vì dùng managed? Đây không phải câu hỏi tu từ. Một bộ phận đáng kể tổ chức lớn chạy self-managed observability — Elasticsearch, Prometheus tự quản, Loki, Jaeger — trên chính GKE, và họ có lý do chính đáng. Nhưng tự vận hành một observability stack là vận hành một hệ stateful, data-intensive, có yêu cầu độ tin cậy cao hơn cả workload nó giám sát (nghịch lý: hệ giám sát phải sống sót qua chính sự cố mà nó cần giám sát). Quyết định này phải dựa trên đánh đổi rõ ràng, không phải quán tính "chúng tôi luôn dùng ELK".

File này dùng Elastic Stack làm ví dụ đại diện vì nó là stack self-managed phổ biến nhất cho log analytics, nhưng nguyên tắc áp dụng cho mọi lựa chọn self-managed (Prometheus+Thanos/Mimir cho metric, Loki cho log, Jaeger/Tempo cho trace). Trọng tâm không phải "cách cài Elasticsearch" mà là khung quyết định và các đánh đổi vận hành mà một platform engineer phải cân nhắc.

Internal model: vì sao tự vận hành — các lý do hợp lệ và không hợp lệ

Lý do hợp lệ

• Data sovereignty / compliance cứng: yêu cầu pháp lý buộc telemetry (đặc biệt log chứa PII) không được rời khỏi ranh giới do tổ chức kiểm soát, hoặc phải lưu ở hạ tầng riêng. Khi managed service không đáp ứng được ràng buộc residency cụ thể, self-managed là lựa chọn bắt buộc.

• Multi-cloud / hybrid cần một pane of glass thống nhất: tổ chức chạy GKE + EKS + on-prem cần một hệ observability duy nhất nhìn xuyên mọi môi trường. Managed service của một cloud thường ưu tiên cloud đó; một stack self-managed trung lập (Prometheus/Grafana/Elastic) cho góc nhìn thống nhất.

• Log analytics nâng cao mà managed không cung cấp: Elasticsearch mạnh ở full-text search, aggregation phức tạp, và phân tích log kiểu security analytics — vượt khả năng query của Cloud Logging. Khi log là sản phẩm phân tích chính (SIEM, fraud detection, observability-driven product), Elastic có thể là công cụ đúng.

• Anti-lock-in chiến lược: giữ observability trên công cụ open-source portable để không phụ thuộc một vendor — một quyết định kiến trúc dài hạn có chủ đích.

Lý do KHÔNG hợp lệ (nhưng hay được viện dẫn)

• "Tự host rẻ hơn" — gần như luôn sai khi tính đủ chi phí: PD/Hyperdisk cho data node, compute cho cluster Elastic, và quan trọng nhất là chi phí kỹ sư vận hành (Elasticsearch ở scale cần chuyên môn đáng kể). Managed thường rẻ hơn về TCO cho đa số.

• "Chúng tôi đã quen ELK" — quán tính tổ chức, không phải lý do kỹ thuật. Đáng xem lại khi lên cloud.

• "Cần linh hoạt" — thường mơ hồ; nếu không nêu được nhu cầu cụ thể managed không đáp ứng, đây là cái cớ.

Internal model: Elastic Stack trên GKE qua ECK

Cách chuẩn để chạy Elastic trên Kubernetes là Elastic Cloud on Kubernetes (ECK) — một operator quản lý vòng đời Elasticsearch, Kibana, Beats/Elastic Agent qua CRD. Kiến trúc điển hình trên GKE:

• Elasticsearch chạy như StatefulSet (cần stable identity + persistent volume, Chương 11), với các node role tách biệt:
  • master node: quản lý cluster state, bầu cử (cần số lẻ, thường 3 để tránh split-brain).
  • data node: lưu shard, phần chịu tải I/O và storage nặng nhất — gắn PD/Hyperdisk.
  • ingest/coordinating node: xử lý pipeline ingest và điều phối query.
• Kibana: UI query/dashboard, chạy như Deployment.
• Thu thập: Filebeat/Elastic Agent (DaemonSet) đọc log container, hoặc Fluentd/Fluent Bit đẩy vào Elasticsearch. Lưu ý quan trọng: phải gắn resource label nhất quán (cluster/namespace/pod) ở tầng thu thập để giữ khả năng correlation (file 01) — đây là việc managed stack làm tự động mà self-managed phải tự lo.

Internal model: performance tuning — nơi self-managed đòi hỏi chuyên môn

Đây là phần phân biệt "chạy được" và "chạy ở production scale". Elasticsearch có nhiều điểm tuning quyết định độ ổn định:

Storage: StatefulSet với Hyperdisk

Data node cần IOPS và throughput cao. Pattern đúng (Chương 11): dùng Hyperdisk Balanced/Extreme (tách IOPS/throughput khỏi dung lượng) thay vì PD thường, với volumeBindingMode: WaitForFirstConsumer để volume tạo đúng zone với Pod. Storage là nút cổ chai số một của Elasticsearch ở scale log lớn.

JVM heap: quy tắc 50% và trần ~31GB

Elasticsearch chạy trên JVM. Hai quy tắc cứng:

• Heap = 50% RAM container (nửa còn lại cho filesystem cache của Lucene, thứ Elasticsearch dựa vào nặng).
• Không vượt ~31GB heap — trên ngưỡng này JVM mất compressed object pointers, hiệu quả memory giảm. Cần dung lượng lớn hơn thì thêm data node, không tăng heap.

Đặt request=limit cho memory (QoS Guaranteed, Chương 8) để tránh OOMKill data node — một data node bị kill có thể trigger shard reallocation tốn kém.

Shard sizing: tránh over-sharding

Lỗi phổ biến nhất: quá nhiều shard nhỏ. Mỗi shard tốn overhead (memory, file handle, cluster state). Quy tắc: shard size mục tiêu 10–50GB, số shard per node tỷ lệ với heap (kinh nghiệm ~20 shard/GB heap). Over-sharding làm phình cluster state, chậm master node, và bất ổn cluster.

ILM: hot-warm-cold tiering

Log có giá trị giảm theo tuổi. Index Lifecycle Management (ILM) tự động chuyển index qua các tier:

• Hot: index mới, ghi nhiều, query nhiều — node mạnh, Hyperdisk nhanh.
• Warm: vài ngày tuổi, read-only, query thưa — node rẻ hơn, storage chậm hơn.
• Cold/Frozen: lưu trữ, query hiếm — storage rẻ nhất (có thể searchable snapshot trên GCS).
• Delete: tự xóa sau retention.

ILM là cơ chế kiểm soát chi phí tương đương "bucket retention" của Cloud Logging (file 05) — không có nó, cluster phình vô hạn.

Production architecture patterns

Pattern hybrid: managed metric + self-managed log

Pattern thực dụng nhất cho tổ chức cần log analytics nâng cao mà không muốn tự host toàn bộ: giữ metric và trace trên managed (Managed Service for Prometheus + Cloud Trace — rẻ, ít ops, file 06/07), chỉ tự host log analytics trên Elastic cho full-text search và security analytics. Cách này cô lập gánh nặng vận hành stateful vào đúng phần cần nó, thay vì self-host mọi thứ. Cloud Logging vẫn nhận log (cho audit/compliance), đồng thời route bản sao qua Pub/Sub sink (file 05) vào Elastic cho phân tích.

Pattern dual-write có kiểm soát

Tránh anti-pattern "log đi hai nơi đầy đủ" (trả phí ingest hai lần). Thay vào đó: Cloud Logging giữ system + audit log (compliance), Elastic chỉ nhận log workload cần phân tích sâu, với exclusion ở Log Router để không trùng lặp tốn kém.

Pattern cô lập observability cluster

Anti-pattern nguy hiểm: chạy Elastic trên chính cluster nó giám sát. Khi cluster gặp sự cố, observability stack chết cùng — mất quan sát đúng lúc cần nhất. Pattern đúng: chạy observability stack trên cluster/node pool riêng (hoặc thậm chí project riêng), cô lập failure domain. Hệ giám sát phải sống sót qua sự cố của hệ được giám sát.

Real-world scenarios

Kịch bản 1 — Compliance buộc self-host. Một fintech bị quy định buộc mọi log giao dịch (chứa PII) phải lưu trong hạ tầng họ kiểm soát hoàn toàn, không qua managed service đa tenant. Họ chạy ECK trên node pool riêng với Hyperdisk mã hóa CMEK, ILM giữ hot 7 ngày / warm 90 ngày / cold (searchable snapshot trên GCS CMEK) 7 năm. Đây là trường hợp self-managed là bắt buộc, không phải lựa chọn.

Kịch bản 2 — Over-sharding làm sập cluster. Một team tạo index theo ngày với 50 shard mặc định cho mỗi index, dù mỗi index chỉ vài GB. Sau vài tháng: hàng chục nghìn shard, cluster state khổng lồ, master node quá tải, cluster yellow/red liên tục. Khắc phục: shrink index, dùng ILM với rollover theo size (50GB/shard), giảm shard count xuống đúng mức. Bài học: tuning Elasticsearch là chuyên môn, không phải "deploy là xong".

Kịch bản 3 — Hybrid giảm ops mà giữ năng lực. Một tổ chức ban đầu self-host toàn bộ (Prometheus+Thanos+Elastic+Jaeger), tốn hai kỹ sư full-time. Chuyển metric/trace sang managed (GMP + Cloud Trace), chỉ giữ Elastic cho security log analytics. Gánh nặng vận hành giảm còn một phần, nhưng vẫn giữ năng lực log analytics nâng cao mà Cloud Logging không có.

Common mistakes / anti-patterns

• Self-host vì quán tính, không vì nhu cầu. Tốn chi phí kỹ sư khổng lồ cho thứ managed làm tốt hơn. Đúng: chỉ self-host khi có lý do hợp lệ (sovereignty, multi-cloud, analytics nâng cao).

• Chạy observability stack trên cluster nó giám sát. Mất quan sát đúng lúc sự cố. Đúng: cô lập sang cluster/node pool riêng.

• Over-sharding. Quá nhiều shard nhỏ làm bất ổn cluster. Đúng: 10–50GB/shard, ILM rollover theo size.

• Heap > 31GB hoặc heap = 100% RAM. Mất compressed pointer và bỏ đói filesystem cache. Đúng: heap = 50% RAM, ≤ 31GB, scale ngang bằng thêm data node.

• Không có ILM. Cluster phình vô hạn, chi phí storage bùng nổ. Đúng: ILM hot-warm-cold + delete theo retention.

• Mất nhãn nhất quán. Self-managed gắn nhãn khác managed nên không correlate được. Đúng: chuẩn hóa cluster/namespace/pod ở tầng thu thập.

GCP-native implementation guidance

Ví dụ Elasticsearch qua ECK với node role tách biệt và Hyperdisk (rút gọn):

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: logging
spec:
  version: 8.x.x
  nodeSets:
  - name: master
    count: 3                      # số lẻ tránh split-brain
    config: { node.roles: ["master"] }
  - name: data-hot
    count: 6
    config: { node.roles: ["data_hot", "ingest"] }
    podTemplate:
      spec:
        containers:
        - name: elasticsearch
          resources:
            requests: { memory: 16Gi, cpu: 4 }
            limits:   { memory: 16Gi, cpu: 4 }   # Guaranteed QoS
          env:
          - name: ES_JAVA_OPTS
            value: "-Xms8g -Xmx8g"               # heap = 50% RAM, < 31GB
    volumeClaimTemplates:
    - metadata: { name: elasticsearch-data }
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: hyperdisk-balanced     # Chương 11
        resources: { requests: { storage: 1Ti } }

Khung quyết định nhanh:

Tiêu chí	Managed (Google)	Self-managed (Elastic/ECK)
Chi phí vận hành	Gần như 0	Cao (cần chuyên môn)
Data sovereignty cứng	Hạn chế	Toàn quyền
Multi-cloud pane of glass	Khó	Tốt
Log analytics nâng cao	Cơ bản	Mạnh (full-text, aggregation)
Correlation tự động	Có sẵn	Phải tự dựng
Scale storage/cardinality	Tự động	Tự lo (shard, ILM, Thanos)

Official references

• Elastic Cloud on Kubernetes (ECK) — operator deploy Elastic
• Elasticsearch sizing & shards — shard sizing best practice
• Index Lifecycle Management — hot-warm-cold
• GKE Hyperdisk for stateful — storage cho data node (Chương 11)
• Route logs to Pub/Sub — sink sang Elastic
• Cost optimization observability — so sánh chi phí

---

Tóm lại: self-managed observability (Elastic/ECK làm ví dụ) chỉ hợp lý khi có lý do cứng — data sovereignty, multi-cloud, log analytics nâng cao, anti-lock-in — chứ không vì quán tính hay ảo tưởng "rẻ hơn". Nó là vận hành một hệ stateful đòi hỏi chuyên môn: Hyperdisk cho data node, heap 50%/≤31GB, shard 10–50GB tránh over-sharding, ILM hot-warm-cold để khống chế chi phí, và tuyệt đối cô lập khỏi cluster nó giám sát. Pattern thực dụng nhất với đa số là hybrid: managed cho metric/trace, self-managed chỉ cho phần log analytics thực sự cần.