Lời Mở ĐầuTiếp nối Bài 4 về động cơ phát hiện gian lận và định danh thiết bị, Bài 5 tiếp tục phân tích hạ tầng giúp hệ thống Z18 duy trì tính minh bạch, khả năng phát hiện sự cố sớm và đảm bảo độ tin cậy đạt chuẩn $99.999\%$: Hạ Tầng Giám Sát Thời Gian Thực (Observability), Cụm Nhật Ký Tập Trung (Centralized Logging) và Quy Trình Ứng Phó Sự Cố (Incident Response
https://xhz18.com/ Framework).Với quy mô hàng trăm Microservices phân tán trên nhiều cụm Kubernetes Clusters, việc giám sát trong Z18 không chỉ dừng lại ở các chỉ số CPU/RAM đơn thuần mà đòi hỏi khả năng truy vết từng Request qua ma trận dịch vụ (Distributed Tracing) và phân tích hàng triệu dòng Log mỗi giây theo thời gian thực.Phần 1: Mô Hình Giám Sát Ba Trụ Cột (The Three Pillars of Observability)Z18 áp dụng mô hình Observability toàn diện dựa trên 3 trụ cột cốt lõi: Metrics, Logs và Traces. [ OBSERVABILITY PLATFORM ]
│
┌─────────────────────────────┼─────────────────────────────┐
▼ ▼ ▼
[ METRICS ] [ TRACES ] [ LOGS ]
(Prometheus / Grafana) (Jaeger / OpenTelemetry) (Vector / OpenSearch)
│ │ │
Đo lường chỉ số Truy vết hành trình Nhật ký chi tiết
định lượng hệ thống Request qua các service sự kiện & lỗi
1. Thu Thập & Cảnh Báo Chỉ Số (Metrics Engine)Prometheus Cluster Federation: Thu thập Metrics mỗi ngày mà không làm ảnh hưởng đến hiệu năng của các Microservices chính, Z18 sử dụng đường ống thu gom Log bất đồng bộ tải cao:[ Application Pods ] ──(Log File)──► [ Vector Agent (DaemonSet) ]
│
▼
[ Apache Kafka ]
(Topic: sys-logs-v1)
│
▼
[ Logstash / Vector Aggregator ]
│
▼
[ OpenSearch Cluster ]
│
▼
[ Grafana / Kibana UI ]
Các Kỹ Thuật Tối Ưu Báo Nhật Ký:Log Level Dynamic Switching: Ở điều kiện bình thường, hệ thống chỉ ghi nhận Log cấp độ INFO và ERROR. Khi cần điều tra sự cố ở một Service cụ thể, hạ tầng cho phép bật nhanh cấp độ DEBUG qua ConfigMap mà không cần khởi động lại Pod.Structured JSON Logging: Toàn bộ Log bắt buộc phải định dạng JSON có cấu trúc bao gồm các trường chuẩn: timestamp, service_name, trace_id, user_id, level, message.Mã Hóa & Che Chắn Dữ Liệu Nhạy Cảm (Log Masking): Trước khi Log rời khỏi Pod, Vector Agent sẽ chạy các luật Regex để che thông tin nhạy cảm (Số thẻ ngân hàng, Mật khẩu, OTP) tránh bị rò rỉ vào hệ thống lưu trữ.Phần 3: Quy Trình Cảnh Báo & Ứng Phó Sự Cố Tự Động (Automated Incident Response)1. Phân Tầng Mức Độ Cảnh Báo (Alert Severity Levels)Mức ĐộĐiều Kiện Kích HoạtKênh Cảnh BáoThời Gian Phản Hồi Tối Đa (SLA)P1 - CRITICALSập toàn bộ Gateway, Tỷ lệ lỗi Wallet Engine $> 1\%$, Mất kết nối CSDL chính.PagerDuty Call / SMS tới On-Call Engineer, Auto-Trigger Runbook.$< 5\text{ phút}$P2 - HIGHP99 Latency của Gaming Engine $> 100\text{ms}$, Tỷ lệ nghẽn Kafka Topic $> 10\%$.Slack / Telegram P1 Channel, Cảnh báo PagerDuty.$< 15\text{ phút}$P3 - WARNINGSử dụng CPU Node $> 80\%$, Dung lượng đĩa đệm sắp đầy ($> 85\%$).Ticket Jira / Slack Notification.$< 2\text{ giờ}$2. Tự Động Phục Hồi (Auto-Remediation Runbooks)Z18 tích hợp các Kịch bản Phục hồi Tự động (Automated Runbooks) kết hợp với Kubernetes Operators:Auto-Healing & Self-Recovery: Khi một Microservice có dấu hiệu Memory Leak hoặc CPU Throttling liên tục, Kubernetes HPA (Horizontal Pod Autoscaler) sẽ tự động nhân bản Pod; nếu Pod mất Liveness Probe, K8s sẽ tự động tiêu hủy và tạo mới Pod.Traffic Shedding / Graceful Degradation: Trong kịch bản lưu lượng vượt quá $200\%$ năng lực dự phòng, hệ thống tự động ngắt các tính năng phụ (như thống kê lịch sử, bảng xếp hạng) để dành toàn bộ tài nguyên cho luồng Đặt cược và Wallet.Kết LuậnHạ tầng Observability & Logging của Z18 cung cấp khả năng quan sát toàn diện theo thời gian thực từ mạng biên đến tầng CSDL. Việc kết hợp giữa Prometheus/Grafana, OpenTelemetry và OpenSearch Pipeline giúp hệ thống chủ động phát hiện bất thường, giảm thiểu chỉ số MTTD (Mean Time To Detect) và MTTR (Mean Time To Resolve), duy trì sự ổn định tối đa cho nền tảng.
