Retention, Storage & Cost Management

Tại sao Cost Management là kỹ năng bắt buộc

Cloud Logging có thể trở thành dòng chi phí lớn thứ 3-4 trong bill GCP của một tổ chức mà không ai nhận ra cho đến khi review billing. Không phải vì giá đắt, mà vì volume tăng tự nhiên theo scale của hệ thống, và nhiều source mặc định bật mà không có cảnh báo nào về chi phí.

Hiểu đúng cấu trúc chi phí — sự khác biệt giữa ingestion cost và storage cost, tại sao exclusion filter ở sink không giảm ingestion cost, field exclusion hoạt động như thế nào — là điều kiện cần trước khi implement bất kỳ optimization nào.

Internal Model: Cấu Trúc Chi Phí Hai Tầng

Cloud Logging tính phí theo hai chiều hoàn toàn độc lập:

Tầng 1: Ingestion Cost

Ingestion cost phát sinh khi log entry được ghi vào một log bucket. Đây là chi phí "viết vào disk".

Log Entry tạo ra
      │
      ▼
Cloud Logging API ← quota tính ở đây
      │
      ▼
Log Router evaluate sinks
      │
      ▼
Entry ghi vào bucket ← INGESTION COST tính ở đây

Quan trọng: Ingestion cost chỉ tính khi entry thực sự ghi vào bucket. Nếu exclusion filter trong sink loại bỏ entry trước khi ghi, không có ingestion cost cho entry đó ở sink đó.

Tuy nhiên, nếu entry được ghi vào nhiều buckets (qua nhiều sinks), ingestion cost tính mỗi lần ghi. Entry vào cả _Default bucket lẫn custom BigQuery sink sẽ tính hai lần ingestion.

Free tier: 50 GB/tháng/project (tổng tất cả log types gộp lại, không phải per-service)

Sau free tier: $0.50/GB

Log types không tính ingestion cost:

Admin Activity Audit Logs (luôn miễn phí)
System Event Audit Logs (luôn miễn phí)
Access Transparency Logs (miễn phí khi ghi vào _Required)

Tầng 2: Storage Cost

Storage cost phát sinh khi log entries được giữ lại trong bucket sau default retention period (30 ngày cho hầu hết buckets).

Giá: $0.01/GB/tháng cho storage vượt quá retention mặc định

Điều này nghe có vẻ rẻ, nhưng nếu bạn có 100 GB logs/tháng và muốn giữ 1 năm:

Tháng 1: 100 GB ingested, 70 GB retained (30 days standard), 30 GB "extra" → $0.30
Sau 12 tháng: 12 × 100 GB = 1.2 TB stored → ~$12/tháng chỉ storage

_Required bucket: Không có storage cost, kể cả sau 400 ngày. Google absorb cost này cho Admin Activity và System Event logs.

Log Buckets: Configuration và Trade-offs

Default Buckets

Mỗi project có hai built-in buckets được tạo tự động:

Bucket	Retention	Storage Location	Xóa được?
`_Required`	400 ngày (cố định, không đổi được)	Không chỉ định được	Không
`_Default`	30 ngày (default, có thể thay đổi)	Có thể chỉ định region	Không

_Default bucket có thể được cấu hình:

Thay đổi retention (1–3650 ngày)
Thay đổi storage location (sau khi tạo, không đổi được nữa)
Thêm field exclusion rules
Bật CMEK (Customer-Managed Encryption Keys)
Upgrade lên Log Analytics

Thay đổi region của _Default bucket: Sau khi project được tạo, _Default bucket có vị trí global. Bạn có thể thay đổi trước khi có logs, nhưng sau khi đã có logs, không thể thay đổi region của bucket. Đây là constraint quan trọng cho data sovereignty/GDPR compliance — nếu bạn cần logs ở EU region, phải cấu hình ngay từ đầu hoặc tạo custom bucket.

Custom Buckets

Custom buckets cho phép tổ chức tinh vi hơn:

bash

# Tạo custom bucket với retention 90 ngày, location eu
gcloud logging buckets create security-logs \
  --project=my-project \
  --location=europe-west1 \
  --retention-days=90 \
  --description="Security team audit logs"

Giới hạn: Tối đa 100 custom buckets per project.

Khi nào cần custom bucket:

Data residency requirements (GDPR, data sovereignty)
Khác nhau về retention per log type (security logs giữ lâu hơn debug logs)
Phân quyền truy cập: Log Views trên custom bucket cho phép IAM granular hơn

Log Views: Access Control Granular

Log Views là cơ chế cho phép control ai được đọc logs trong một bucket mà không cần tách bucket.

bash

# Tạo Log View cho production logs, chỉ cho phép SRE team đọc
gcloud logging views create prod-sre-view \
  --bucket=_Default \
  --project=my-project \
  --location=global \
  --log-filter='resource.labels.namespace_name="production"'

# Grant SRE team permission đọc view này
gcloud projects add-iam-policy-binding my-project \
  --member="group:sre@company.com" \
  --role="roles/logging.viewAccessor" \
  --condition="expression=resource.name==\"projects/my-project/locations/global/buckets/_Default/views/prod-sre-view\""

Developer chỉ có quyền đọc prod-sre-view — họ thấy logs của namespace production nhưng không thấy logs của namespaces khác trong cùng bucket. Đây là cách giảm thiểu data exposure trong multi-team environment mà không cần tạo nhiều buckets riêng biệt.

Field Exclusion: Cơ Chế Giảm Ingestion Cost

Field exclusion là tính năng cho phép drop specific fields khỏi log entries trước khi ghi vào bucket. Không phải exclude cả entry (như exclusion filter trong sink), mà chỉ trim bớt data.

Cơ chế hoạt động

Log Entry (full, 5 KB)
      │
      ▼
Log Router → Sink evaluation
      │
      ▼ (Field exclusion rules applied)
Log Entry (trimmed, 1.5 KB) → ghi vào bucket

Với VPC Flow Logs, một entry đầy đủ có khoảng 30+ fields. Nếu bạn chỉ cần src_ip, dst_ip, bytes_sent, protocol để compliance, bạn có thể trim phần lớn còn lại và giảm storage size xuống 60-70%.

Cấu hình Field Exclusion

Field exclusion được cấu hình trên bucket, không phải trên sink:

bash

# Xem bucket config hiện tại
gcloud logging buckets describe _Default \
  --project=my-project \
  --location=global

# Update bucket để exclude fields
gcloud logging buckets update _Default \
  --project=my-project \
  --location=global \
  --field-exclusions='logName,receiveTimestamp,httpRequest.latency'

Hoặc qua gcloud với json:

bash

gcloud logging buckets update my-custom-bucket \
  --project=my-project \
  --location=global \
  --field-exclusions-from-file=exclusions.json

Trong exclusions.json:

json

[
  {
    "name": "vpc-flow-trim",
    "filter": "resource.type=\"gce_subnetwork\"",
    "fields": [
      "jsonPayload.reporter",
      "jsonPayload.rtt_msec",
      "jsonPayload.connection.dest_port"
    ]
  }
]

Quan trọng: Field exclusion là irreversible — một khi field bị drop, nó không thể recovered. Nếu bạn sau này cần field đó, bạn không có nó trong historical logs.

Field Exclusion vs Sink Exclusion Filter: Sự Khác Biệt Then Chốt

Cơ chế	Loại bỏ gì?	Giảm ingestion cost?	Giảm storage?
Sink exclusion filter	Cả entry	Có (entry không ghi vào bucket)	Có
Field exclusion trên bucket	Một số fields của entry	Không (entry vẫn ghi)	Có

Sink exclusion filter mới là cơ chế giảm ingestion cost. Field exclusion chỉ giảm storage cost (và một phần nhỏ ingestion cost vì entry nhỏ hơn).

Retention Configuration

Thay đổi retention

bash

# Tăng retention _Default bucket lên 90 ngày
gcloud logging buckets update _Default \
  --project=my-project \
  --location=global \
  --retention-days=90

Grace period: Khi bạn giảm retention (ví dụ từ 90 ngày xuống 30 ngày), entries đã cũ không bị xóa ngay lập tức — có 7 ngày grace period trước khi xóa. Điều này cho phép bạn recover nếu thay đổi nhầm.

Locking retention: Có thể lock retention để không ai có thể giảm xuống (compliance requirement):

bash

gcloud logging buckets update my-compliance-bucket \
  --project=my-project \
  --location=global \
  --retention-days=365 \
  --lock-retention

Sau khi lock, retention chỉ có thể tăng, không thể giảm. Không thể unlock.

Chiến Lược Cost Optimization Thực Tế

1. Identify high-volume sources

Bước đầu tiên luôn là biết mình đang log gì và bao nhiêu:

# Dùng Cloud Monitoring để xem log ingestion theo resource type
# Trong Metrics Explorer, chọn metric:
logging.googleapis.com/billing/bytes_ingested
# Group by: resource.type

Hoặc qua Logs Explorer với query:

# Xem distribution của log volume theo resource type (dùng Log Analytics)
SELECT
  resource.type,
  SUM(proto_size(log_entry_proto)) / 1e9 as gb_ingested
FROM
  `_Default._AllLogs`
WHERE
  timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY resource.type
ORDER BY gb_ingested DESC
LIMIT 20

2. VPC Flow Logs: Nguồn volume lớn nhất thường gặp

VPC Flow Logs mặc định có sampling rate 50% và aggregation interval 5 giây. Trong hệ thống production với traffic cao, có thể tạo ra hàng chục GB logs/ngày.

Tối ưu hóa:

bash

# Tăng aggregation interval (giảm số entries)
gcloud compute networks subnets update my-subnet \
  --region=us-central1 \
  --logging-aggregation-intervals=interval-30-sec \
  --logging-flow-sampling=0.1  # Giảm sampling rate xuống 10%

Giảm từ 5 giây xuống 30 giây và sampling 50% xuống 10% có thể giảm 97% volume VPC Flow Logs trong khi vẫn giữ đủ data cho security analysis.

Field trimming cho VPC Flow Logs:

json

{
  "name": "vpc-flow-minimal",
  "filter": "resource.type=\"gce_subnetwork\" AND log_id(\"compute.googleapis.com/vpc_flows\")",
  "fields": [
    "jsonPayload.connection.dest_port",
    "jsonPayload.tcp_flags",
    "jsonPayload.rtt_msec"
  ]
}

3. GKE Container Logs: Application-level control

Container logs (stdout/stderr) là nguồn volume lớn thứ hai. Không nên exclude toàn bộ — nhưng có thể:

Exclude DEBUG và TRACE severity trong non-prod workloads
Exclude health check logs (các request 200 từ load balancer health probes)

# Exclusion filter trong _Default sink
resource.type="k8s_container" AND
severity<WARNING AND
labels."k8s-pod/app"!="critical-service"

Hoặc exclude health check logs từ GKE:

resource.type="k8s_container" AND
httpRequest.requestUrl=~"/health" AND
httpRequest.status=200

4. Cloud Load Balancing Access Logs

Request logs từ HTTP(S) Load Balancer tạo ra rất nhiều volume trong hệ thống traffic cao. Sampling 10% successful requests trong khi giữ 100% errors là chiến lược phổ biến:

# Exclusion filter: bỏ 90% 2xx logs (dùng sample function)
resource.type="http_load_balancer" AND
httpRequest.status<400 AND
NOT sample(insertId, 0.1)

sample(insertId, 0.1) là hàm built-in trong Logging Query Language — giữ ngẫu nhiên 10% entries dựa trên hash của insertId. Deterministic: cùng insertId luôn cho cùng kết quả.

5. Tránh Log Duplication

Pattern thường thấy gây cost tăng gấp đôi không cần thiết:

_Default sink → _Default bucket (30 ngày)
Custom sink → BigQuery (long-term)

Nếu cả hai sinks không có exclusion filter, mỗi entry tính ingestion cost hai lần — một lần vào bucket, một lần vào BigQuery.

Fix: Nếu BigQuery là long-term archive, exclude khỏi _Default sink:

bash

# Thêm exclusion vào _Default sink để không double-ingest
gcloud logging sinks update _Default \
  --project=my-project \
  --add-exclusion=name=no-audit-duplication,filter='log_id("cloudaudit.googleapis.com/activity")'

6. Budget Alerts cho Logging

bash

# Tạo alert khi logging ingestion spike
# Qua Cloud Monitoring alert policy:
# Metric: logging.googleapis.com/billing/bytes_ingested
# Threshold: 10 GB/ngày (điều chỉnh theo baseline)
# Duration: 1 ngày

Cấu hình alert từ Logs Explorer:

Vào Logs-based Metrics → System Metrics
Tìm billing/bytes_ingested
Create alert từ metric đó với threshold phù hợp

Log Analytics: SQL trên Log Data

Log Analytics là tính năng upgrade cho buckets, cho phép query bằng SQL thay vì chỉ LQL.

sql

-- Tìm top error messages trong 24 giờ qua
SELECT
  jsonPayload.message,
  COUNT(*) as count,
  MIN(timestamp) as first_seen,
  MAX(timestamp) as last_seen
FROM `my-project._Default._AllLogs`
WHERE
  timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND severity IN ('ERROR', 'CRITICAL')
  AND resource.type = 'k8s_container'
GROUP BY jsonPayload.message
ORDER BY count DESC
LIMIT 20

Chi phí: Log Analytics query tính tiền theo volume scanned (tương tự BigQuery on-demand pricing: ~$5/TB). Luôn filter theo timestamp để giới hạn partition scan.

Khi nào bật Log Analytics: Khi cần analytics phức tạp trên log data (GROUP BY, aggregations, JOINs). Không cần nếu chỉ dùng simple filter queries trong Logs Explorer.

Lưu ý không thể hoàn tác: Sau khi upgrade bucket lên Log Analytics, không thể downgrade. Và không thể link BigQuery dataset đến một bucket đã upgrade.

Retention, Storage & Cost Management ​

Tại sao Cost Management là kỹ năng bắt buộc ​

Internal Model: Cấu Trúc Chi Phí Hai Tầng ​

Tầng 1: Ingestion Cost ​

Tầng 2: Storage Cost ​

Log Buckets: Configuration và Trade-offs ​

Default Buckets ​

Custom Buckets ​

Log Views: Access Control Granular ​

Field Exclusion: Cơ Chế Giảm Ingestion Cost ​

Cơ chế hoạt động ​

Cấu hình Field Exclusion ​

Field Exclusion vs Sink Exclusion Filter: Sự Khác Biệt Then Chốt ​

Retention Configuration ​

Thay đổi retention ​

Chiến Lược Cost Optimization Thực Tế ​

1. Identify high-volume sources ​

2. VPC Flow Logs: Nguồn volume lớn nhất thường gặp ​

3. GKE Container Logs: Application-level control ​

4. Cloud Load Balancing Access Logs ​

5. Tránh Log Duplication ​

6. Budget Alerts cho Logging ​

Log Analytics: SQL trên Log Data ​

References ​

Retention, Storage & Cost Management

Tại sao Cost Management là kỹ năng bắt buộc

Internal Model: Cấu Trúc Chi Phí Hai Tầng

Tầng 1: Ingestion Cost

Tầng 2: Storage Cost

Log Buckets: Configuration và Trade-offs

Default Buckets

Custom Buckets

Log Views: Access Control Granular

Field Exclusion: Cơ Chế Giảm Ingestion Cost

Cơ chế hoạt động

Cấu hình Field Exclusion

Field Exclusion vs Sink Exclusion Filter: Sự Khác Biệt Then Chốt

Retention Configuration

Thay đổi retention

Chiến Lược Cost Optimization Thực Tế

1. Identify high-volume sources

2. VPC Flow Logs: Nguồn volume lớn nhất thường gặp

3. GKE Container Logs: Application-level control

4. Cloud Load Balancing Access Logs

5. Tránh Log Duplication

6. Budget Alerts cho Logging

Log Analytics: SQL trên Log Data

References