Phân tích chi phí lưu trữ và truyền tải dữ liệu giữa On-prem và Cloud
Trước khi tối ưu, bạn cần xác định chính xác lượng dữ liệu đang được gửi từ On-prem (máy chủ nội bộ) về Cloud (dịch vụ lưu trữ S3/GCS) để tính toán chi phí Bandwidth và Storage.
Sử dụng Prometheus và Loki để đo lường lưu lượng truyền tải thực tế qua các metric `prometheus_remote_write_bytes_total` và `loki_push_api_request_bytes_total`.
Thực hiện query trên Grafana để xem tổng dung lượng đã gửi trong 24h qua:
increase(prometheus_remote_write_bytes_total[24h])
Kết quả mong đợi: Một con số cụ thể (byte) thể hiện tổng lượng dữ liệu Metrics đã được gửi đi. Nếu con số này vượt quá 100GB/ngày, bạn cần cân nhắc ngay việc giảm tần suất thu thập hoặc áp dụng sampling.
Tương tự cho hệ thống Log, kiểm tra lượng data đã push về Loki backend:
increase(loki_push_api_request_bytes_total[24h])
Kết quả mong đợi: Con số byte tổng lượng log đã gửi. So sánh con số này với bảng giá của nhà cung cấp Cloud (ví dụ: AWS S3 + Data Transfer) để ước tính chi phí hàng tháng.
Cấu hình Data Sharding và Horizontal Scaling cho Prometheus/Loki
Để tránh nút cổ chai (bottleneck) khi dữ liệu tăng đột biến, chúng ta sẽ chia nhỏ dữ liệu (Sharding) dựa trên Tenant hoặc Job Name, và mở rộng chiều ngang (Horizontal Scaling) bằng cách chạy nhiều instance Prometheus/Loki với cùng một Storage Backend.
Bước 1: Cấu hình Prometheus để chỉ thu thập một phần dữ liệu (Sharding by job).
Tạo file cấu hình cho Instance 1 (chỉ thu thập các job chứa "frontend"):
cat > /etc/prometheus/prometheus-shard-1.yml
Kết quả mong đợi: Instance này chỉ gửi dữ liệu liên quan đến frontend, giảm tải 50% so với cấu hình toàn bộ.
Tạo file cấu hình cho Instance 2 (chỉ thu thập các job chứa "backend" và "db"):
cat > /etc/prometheus/prometheus-shard-2.yml
Kết quả mong đợi: Instance thứ 2 chịu trách nhiệm cho phần còn lại, đảm bảo không có instance nào bị quá tải CPU/RAM.
Bước 2: Cấu hình Loki cho Sharding dựa trên tenant ID.
Chỉnh sửa file cấu hình Loki để sử dụng cơ chế sharding tự động dựa trên tenant_id:
cat > /etc/loki/loki-sharded.yml
Kết quả mong đợi: Loki sẵn sàng phân tán dữ liệu vào nhiều bucket hoặc shard khác nhau dựa trên tenant, tránh việc một tenant làm chậm toàn bộ hệ thống.
Verify kết quả scaling:
curl -s http://localhost:9090/api/v1/status/ready
Kiểm tra dashboard Grafana để xem số lượng series được scrape tăng lên đều đặn trên các instance khác nhau mà không có lỗi 500/503.
Áp dụng Log Sampling và Trace Filtering để giảm tải cho hệ thống
Với môi trường Hybrid, chi phí truyền tải log và trace là lớn nhất. Chúng ta sẽ áp dụng Log Sampling (chỉ lưu 10% log INFO/DEBUG) và Trace Filtering (bỏ qua trace có status 2xx) ngay tại OpenTelemetry Collector.
Bước 1: Cấu hình OpenTelemetry Collector để thực hiện sampling và filtering.
Tạo file cấu hình `otel-collector-config.yaml` tại `/etc/otel/collector-config.yaml`:
cat > /etc/otel/collector-config.yaml
Kết quả mong đợi: Collector chỉ gửi các trace có lỗi (4xx/5xx) hoặc latency cao, và 5% trace ngẫu nhiên. Các trace 2xx bình thường sẽ bị lọc bỏ ngay tại gateway, giảm 80-90% lưu lượng.
Bước 2: Áp dụng Log Sampling cho các log mức độ thấp (DEBUG/INFO) bằng filter trong pipeline.
Chỉnh sửa lại phần pipeline logs trong file trên để thêm processor `filter` (cần cài đặt processor filter trước):
cat > /etc/otel/collector-config-sampling.yaml
Kết quả mong đợi: Các log DEBUG và INFO sẽ bị loại bỏ hoàn toàn trước khi gửi đi, chỉ còn lại WARN và ERROR được lưu trữ.
Verify kết quả sampling:
curl -s http://localhost:13133
Quan sát metric `otelcol_exporter_sent_spans` và `otelcol_exporter_sent_log_records` trên Grafana. Bạn sẽ thấy lượng data giảm drastical so với trước khi cấu hình sampling.
Tối ưu cấu hình retention policy dựa trên chính sách bảo mật và audit
Không phải dữ liệu nào cũng cần lưu vĩnh viễn. Để tối ưu chi phí, chúng ta sẽ áp dụng chính sách Retention phân cấp: Log lỗi lưu 90 ngày, Log thông thường lưu 7 ngày, Trace lưu 24 giờ.
Bước 1: Cấu hình Retention cho Loki (Log).
Chỉnh sửa file `loki-sharded.yml` (hoặc tạo file mới `loki-retention.yml`) để áp dụng `retention_period` khác nhau cho từng tenant hoặc job.
cat > /etc/loki/loki-retention.yml
Kết quả mong đợi: Loki sẽ tự động giữ log 7 ngày (168h) theo mặc định. Các log cũ hơn sẽ không còn index, giảm dung lượng tìm kiếm.
Bước 2: Thiết lập Retention cho Prometheus (Metrics).
Chỉnh sửa file `prometheus.yml` để giới hạn thời gian lưu trữ trong memory và trên disk (nếu dùng local storage) hoặc cấu hình remote_write để gửi về Long-term storage với retention riêng.
cat > /etc/prometheus/prometheus-retention.yml
Kết quả mong đợi: Prometheus local chỉ lưu 15 ngày, giúp tiết kiệm disk cho On-prem. Dữ liệu lịch sử được đẩy về Cloud để lưu trữ dài hạn theo chính sách của cloud provider.
Bước 3: Tự động xóa dữ liệu cũ (Trace) bằng script Cron.
Viết script để gọi API xóa của Tempo/Loki cho dữ liệu Trace quá 24h:
cat > /usr/local/bin/cleanup-old-traces.sh
Kết quả mong đợi: Script này sẽ chạy định kỳ để xóa các trace cũ, giảm dung lượng storage.
Cấu hình Cron job để chạy script mỗi ngày lúc 2 AM:
echo "0 2 * * * /usr/local/bin/cleanup-old-traces.sh >> /var/log/observability-cleanup.log 2>&1" | crontab -
Kết quả mong đợi: Hệ thống tự động dọn dẹp dữ liệu Trace cũ mỗi ngày, đảm bảo tuân thủ chính sách 24h.
Verify kết quả retention:
du -sh /var/lib/prometheus /var/lib/loki
So sánh dung lượng disk trước và sau khi áp dụng retention policy. Dung lượng sẽ ổn định ở mức giới hạn đã cấu hình (ví dụ: 50GB cho Prometheus, 10GB cho Loki local) bất kể thời gian chạy.
Điều hướng series:
Mục lục: Series: Series: Xây dựng hệ thống observability toàn diện (Logging, Metrics, Tracing) cho môi trường Hybrid Cloud với Prometheus, Grafana và OpenTelemetry
« Phần 7: An ninh và bảo mật cho hệ thống Observability
Phần 9: Troubleshooting nâng cao và bài học kinh nghiệm thực tế »