Chọn ELK, Loki hay log của cloud

Không có đáp án chung; mỗi lựa chọn đổi một thứ lấy một thứ. Bài 17.11 đã bàn câu "đang dùng Loki có nên chuyển ELK" trong K8s; ở đây mình làm khung quyết định rộng hơn, cho cả VM và cloud.

1. Bài toán

A. shop-app startup: 4 dev, 3 VM trên AWS, ~20GB log/ngày, không có người chuyên ops
B. Khách doanh nghiệp: on-prem, không ra Internet, log audit 1 năm, tìm full-text, phân quyền chặt
C. Nhánh K8s: 40 service, ~300GB log/ngày, đã có Prometheus + Grafana + Tempo

2. Vấn đề

• Chọn theo "cái hot nhất" → tự vận hành ES với 4 dev, cuối tuần sửa cluster thay vì làm sản phẩm.
• Chọn theo giá ingest rẻ → tìm full-text chậm, compliance không chịu.
• Không tính chi phí ẩn: người vận hành, egress, retention.

3. Giải pháp: so sánh

Managed:

4. Code từng bước: giữ app trung lập với backend

Mấu chốt để đổi được về sau: app chỉ ghi JSON ra stdout/file, mọi việc gửi đi do shipper lo.

Bước 1: app (giống 19.7, không thêm appender gửi thẳng ES)

logging:
  structured:
    format:
      console: ecs

Bước 2: shipper gửi hai nơi khi chuyển đổi (Fluent Bit trên VM)

[INPUT]
    Name   tail
    Path   /var/log/shop/*.json
    Parser json
    Tag    shop.*
[OUTPUT]
    Name   opensearch
    Match  shop.*
    Host   ${OS_HOST}
    Port   443
    tls    On
    AWS_Auth On
    AWS_Region ap-southeast-1
    Index  logs-shop-prod
    Suppress_Type_Name On
[OUTPUT]
    Name   loki
    Match  shop.*
    Host   ${LOKI_HOST}
    labels service=$service['name'], env=$service['environment']
    tls    On
    http_user   ${LOKI_USER}
    http_passwd ${LOKI_TOKEN}

Bước 3: so cùng một câu hỏi trên hai bên

# ES/OpenSearch (KQL):  service.name:payment-service and log.level:error and message:"timeout"
# Loki (LogQL):         {service="payment-service"} | json | log_level="ERROR" |= "timeout"
# CloudWatch Insights:  fields @timestamp, message | filter `service.name`="payment-service" and `log.level`="ERROR" and message like /timeout/

Bước 4: đo trước khi quyết

curl -s -H "Authorization: ApiKey $ES_API_KEY" "$ES_URL/_cat/indices/logs-shop-*?v&h=index,docs.count,pri.store.size&s=index"
# so: GB/ngày thực lưu, thời gian query 5 câu hay dùng nhất, giờ công vận hành/tháng

5. Cách hoạt động: cây quyết định

Bắt buộc on-prem / không ra Internet?
 ├─ có ─► cần full-text, audit, SIEM? ─ có ─► ELK hoặc OpenSearch tự chạy (B)
 │                                     └ không ─► Loki tự chạy (rẻ, nhẹ hơn)
 └─ không ─► có người chuyên vận hành search cluster?
             ├─ không ─► team nhỏ, log < ~50GB/ngày? ─ có ─► log của cloud (A: CloudWatch)
             │                                       └ không ─► managed: Grafana Cloud / Elastic Cloud
             └─ có ─► đã dùng Grafana + Prometheus + Tempo, tìm theo service/time là chính?
                      ├─ có ─► Loki (C), thêm ELK riêng cho audit nếu cần
                      └─ không ─► Elastic Cloud / Amazon OpenSearch Service

6. So sánh: ba nhóm của bạn

7. Khi nào nên dùng / không nên dùng

• Chuyển đổi: dual-write qua shipper 2–4 tuần, chuyển dashboard/alert, rồi tắt bên cũ; log cũ để hết retention hoặc snapshot, đừng cố migrate.
• Không gắn app với backend (appender gửi thẳng ES) → khóa chặt, mất log khi backend lỗi.
• Không chọn chỉ theo giá GB; tính cả giờ người và thời gian điều tra sự cố.

Bạn nghi đúng hướng: với CloudWatch, phần ingest thường chiếm phần lớn hóa đơn.

• Tìm log group lớn: metric IncomingBytes theo log group trong CloudWatch, hoặc Cost Explorer lọc usage type DataProcessing-Bytes.
• Thường thủ phạm là một service vừa bật DEBUG, hoặc log mỗi request health check, hoặc in cả payload lớn.
• Cắt ở nguồn: logging.level.root: INFO, bỏ log health check, cắt payload; cắt ở agent bằng filter trước khi gửi.
• Đặt retention cho mọi log group (mặc định là giữ mãi mãi).
• Log ít đọc: dùng lớp Infrequent Access, hoặc gửi thẳng S3 rồi query Athena.

Thêm alarm trên IncomingBytes để lần sau biết trong ngày, không đợi cuối tháng.

Ổn, và khá phổ biến, miễn là bạn giữ kỷ luật:

• Một shipper định tuyến theo field (event.category: audit → OpenSearch, còn lại → Loki), không chạy hai agent.
• Một schema (ECS) cho cả hai, để chuyển query không phải học lại tên field.
• Cùng trace.id để từ Grafana nhảy sang log audit khi cần.
• Cho phạm vi OpenSearch thật nhỏ (audit chỉ vài GB/ngày) → cụm nhỏ, dễ vận hành, hoặc dùng managed.

Nếu log audit rất ít và chỉ cần khi kiểm toán, có khi S3 + Object Lock + Athena là đủ, không cần cả OpenSearch.

Q1. ELK và Loki khác nhau căn bản ở đâu?

🇻🇳 Tiếng Việt:

ELK index toàn bộ nội dung nên tìm full-text và aggregation rất mạnh, nhưng lưu trữ và vận hành đắt. Loki chỉ index label như service và môi trường, nội dung nén trên object storage, nên rẻ và đơn giản, nhưng tìm chuỗi trên khoảng rộng thì chậm. Tôi chọn ELK khi cần full-text, audit hay security; chọn Loki khi đã dùng Grafana và chủ yếu tìm theo service và thời gian.

🇬🇧 English:

ELK indexes the full content, so full-text search and aggregations are powerful, but storage and operations are expensive. Loki indexes only labels like service and environment and stores compressed content on object storage, so it is cheap and simple, but searching strings across a wide range is slower. I pick ELK for full-text, audit or security needs, and Loki when we are already on Grafana and mostly search by service and time.

Q2. Khi nào nên dùng log managed của cloud?

🇻🇳 Tiếng Việt:

Khi team nhỏ, không có người chuyên vận hành cluster, đã ở một cloud và lượng log vừa phải. Đổi lại phải kiểm soát chi phí ingest bằng mức log, filter và retention, và chấp nhận query yếu hơn hoặc lock-in. Tôi giữ app chỉ ghi JSON ra stdout để có thể đổi backend sau này.

🇬🇧 English:

When the team is small, has nobody dedicated to running a cluster, is already on one cloud, and log volume is moderate. The trade-off is controlling ingest cost through log levels, filters and retention, and accepting weaker queries or lock-in. I keep applications writing JSON to stdout so we can change the backend later.

Q3. Bạn chuyển từ hệ log này sang hệ khác thế nào?

🇻🇳 Tiếng Việt:

Cho shipper ghi song song cả hai nơi vài tuần, dựng lại dashboard và alert trên hệ mới, so kết quả các query quan trọng, rồi tắt hệ cũ. Log lịch sử thường để hết retention hoặc giữ snapshot thay vì migrate. Việc này dễ nếu app chưa từng gắn chặt với backend.

🇬🇧 English:

I have the shipper dual-write to both systems for a few weeks, rebuild dashboards and alerts on the new one, compare results for key queries, then switch off the old one. Historical logs usually age out or stay in snapshots rather than being migrated. This is easy as long as the application was never coupled to the backend.

Cách nhớ ngắn gọn

• ELK: index mọi thứ, mạnh và đắt. Loki: index label, rẻ. Cloud: không vận hành, trả tiền ingest.
• Hỏi theo thứ tự: on-prem? có người vận hành? cần full-text? đã dùng Grafana?
• App ghi JSON ECS ra stdout/file; shipper quyết định gửi đi đâu.
• Chuyển đổi = dual-write rồi cắt, không migrate log cũ.

Tổng kết chương 19: Observability