Triển khai YugabyteDB Monitoring Stack trên Kubernetes
Bước đầu tiên là triển khai các thành phần giám sát gồm Prometheus và Grafana vào cluster Kubernetes của bạn. YugabyteDB cung cấp Helm chart riêng biệt để tự động hóa việc này, bao gồm cả cấu hình sẵn sàng để scrape metrics từ các node TServer và Master.
Việc sử dụng Helm chart chính chủ đảm bảo tính tương thích giữa các version của YugabyteDB và các công cụ giám sát, đồng thời giảm thiểu lỗi cấu hình thủ công.
Thực thi lệnh sau để thêm Helm repository và cài đặt monitoring stack vào namespace yugabyte (giả định bạn đã có cluster và namespace này từ các phần trước):
helm repo add yugabyte https://yugabyte.github.io/yugabyte-db-chart
helm repo update
helm install yb-monitoring yugabyte/yugabyte-db-monitoring --namespace yugabyte --set clusterName=yugabyte --set grafana.enabled=true --set prometheus.enabled=true
Kết quả mong đợi: Các pod yb-prometheus-server và yb-grafana chuyển sang trạng thái Running. Prometheus sẽ tự động phát hiện và bắt đầu thu thập metrics từ các pod YugabyteDB trong cùng namespace.
Verify kết quả bằng cách liệt kê các pod và kiểm tra trạng thái:
kubectl get pods -n yugabyte | grep -E "prometheus|grafana"
Cấu hình Prometheus để scrape metrics từ TServer và Master
Mặc định, Helm chart đã cấu hình cơ bản, nhưng để đảm bảo Prometheus scrape chính xác và đầy đủ các metrics hiệu năng từ các component TServer (t-node) và Master (m-node), bạn cần kiểm tra và tùy chỉnh file prometheus.yaml.
Bạn cần chỉnh sửa ConfigMap của Prometheus để xác định rõ các target scrape, đặc biệt là endpoint /metrics ở port 9000 (cho TServer) và 7000 (cho Master/YB-Master).
Truy cập vào ConfigMap yb-prometheus-config và chỉnh sửa nội dung như sau:
kubectl edit cm yb-prometheus-config -n yugabyte
Trong file cấu hình, đảm bảo phần scrape_configs có nội dung hoàn chỉnh sau để cover cả TServer và Master:
apiVersion: v1
kind: ConfigMap
metadata:
name: yb-prometheus-config
namespace: yugabyte
data:
prometheus.yaml: |
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'yugabyte-tserver'
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name]
action: keep
regex: yb-tserver
- source_labels: [__meta_kubernetes_pod_container_port_name]
action: keep
regex: metrics
metrics_path: /metrics
- job_name: 'yugabyte-master'
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name]
action: keep
regex: yb-master
- source_labels: [__meta_kubernetes_pod_container_port_name]
action: keep
regex: metrics
metrics_path: /metrics
Sau khi lưu file, bạn cần restart pod Prometheus để áp dụng cấu hình mới:
kubectl rollout restart deployment yb-prometheus-server -n yugabyte
Kết quả mong đợi: Vào web UI của Prometheus (thường là port 9090), mục Targets sẽ hiển thị trạng thái UP cho tất cả các pod yb-tserver và yb-master.
Verify bằng cách chạy lệnh curl để kiểm tra endpoint metrics từ một pod TServer cụ thể:
kubectl port-forward svc/yb-tserver 9000 -n yugabyte &
curl -s http://localhost:9000/metrics | grep yb_tserver_latency | head -n 5
Tạo dashboard Grafana để theo dõi Latency, Throughput và Replication Lag
Sau khi Prometheus đã có dữ liệu, bước tiếp theo là kết nối Grafana và import các dashboard chuẩn của YugabyteDB để trực quan hóa các chỉ số quan trọng như độ trễ (Latency), thông lượng (Throughput) và độ trễ sao chép (Replication Lag).
Grafana cần được cấu hình để sử dụng Prometheus làm nguồn dữ liệu (Data Source). Sau đó, bạn sẽ import dashboard ID chính thức từ thư viện cộng đồng YugabyteDB.
Đầu tiên, port-forward dịch vụ Grafana để truy cập web UI trên local:
kubectl port-forward svc/yb-grafana 3000 -n yugabyte
Mở trình duyệt truy cập http://localhost:3000. Đăng nhập với mặc định (admin/admin hoặc xem log pod để lấy password). Trong menu bên trái, chọn Configuration > Data Sources và thêm nguồn mới.
Cấu hình Data Source Prometheus với thông tin sau:
URL: http://yb-prometheus-server.yugabyte.svc.cluster.local:9090
Type: Prometheus
Access: ClusterIP (hoặc Browser nếu cấu hình đặc biệt)
Sau khi lưu (Save & Test), chọn menu Dashboards > New > Import. Nhập ID dashboard chính thức của YugabyteDB là 10783 (YugabyteDB Overview).
Sau khi import, bạn sẽ thấy các panel hiển thị:
- Latency (P99, P50): Thời gian phản hồi của các truy vấn YSQL/YCQL.
- Throughput (QPS): Số lượng truy vấn thực thi mỗi giây trên từng TServer.
- Replication Lag: Chênh lệch thời gian giữa Leader và Follower trong quá trình replication.
Verify kết quả bằng cách thực thi một truy vấn dummy để tạo tải và quan sát biểu đồ Latency tăng lên trên dashboard Grafana:
ycqlsh -u yugabyte -e "CREATE KEYSPACE test_load WITH replication = {'num_token_replicas': 3};"
ycqlsh -u yugabyte -e "USE test_load; CREATE TABLE test_table (id uuid PRIMARY KEY, data text, ts timestamp);"
ycqlsh -u yugabyte -e "INSERT INTO test_table (id, data, ts) VALUES (uuid(), 'load_test_' || totext(now()), now());"
Cấu hình Alerting Rules cho sự cố Node Down và Disk Full
Giám sát thụ động chưa đủ; bạn cần hệ thống cảnh báo chủ động khi gặp sự cố nghiêm trọng như một node bị down hoặc dung lượng đĩa đạt ngưỡng nguy hiểm. Prometheus sử dụng Alertmanager để xử lý các cảnh báo này.
Bạn cần tạo một file rules.yaml chứa các logic cảnh báo và mount nó vào ConfigMap của Prometheus.
Viết nội dung file /etc/prometheus/rules/yugabyte-alerts.yaml (trong container) hoặc tạo ConfigMap mới với nội dung sau:
apiVersion: v1
kind: ConfigMap
metadata:
name: yb-prometheus-alerts
namespace: yugabyte
data:
yugabyte-alerts.yaml: |
groups:
- name: yugabyte-critical
rules:
- alert: YBNodeDown
expr: absent(yb_tserver_is_running)
for: 1m
labels:
severity: critical
annotations:
summary: "YugabyteDB Node Down"
description: "TServer hoặc Master node {{ $labels.pod }} đã ngừng hoạt động."
- alert: YBDiskUsageHigh
expr: (node_filesystem_avail_bytes{mountpoint="/data"} / node_filesystem_size_bytes{mountpoint="/data"}) * 100 < 15
for: 5m
labels:
severity: warning
annotations:
summary: "Disk space running low"
description: "Dung lượng đĩa trên {{ $labels.instance }} còn dưới 15%."
- alert: YBReplicationLagHigh
expr: yb_tserver_replication_lag_seconds > 60
for: 2m
labels:
severity: warning
annotations:
summary: "High Replication Lag"
description: "Replication lag trên table {{ $labels.table }} vượt quá 60 giây."
- name: yugabyte-warning
rules:
- alert: YBHighLatency
expr: yb_tserver_latency_p99_us > 10000
for: 5m
labels:
severity: warning
annotations:
summary: "High Latency Detected"
description: "P99 Latency trên {{ $labels.pod }} vượt quá 10ms."
Để áp dụng file rules này vào Prometheus, bạn cần mount ConfigMap này vào đường dẫn /etc/prometheus/rules/ trong deployment của Prometheus. Chỉnh sửa deployment:
kubectl edit deployment yb-prometheus-server -n yugabyte
Thêm volume và volumeMount vào spec của container prometheus:
spec:
template:
spec:
containers:
- name: prometheus
volumeMounts:
- name: yb-alerts
mountPath: /etc/prometheus/rules
volumes:
- name: yb-alerts
configMap:
name: yb-prometheus-alerts
Sau khi lưu, restart pod Prometheus. Prometheus sẽ load các rules mới và bắt đầu đánh giá chúng theo chu kỳ evaluation_interval (mặc định 15s).
Verify kết quả bằng cách vào web UI Prometheus, chọn tab Alerting. Bạn sẽ thấy các rule đã được load. Để test, bạn có thể tắt một pod TServer và đợi 1 phút để cảnh báo YBNodeDown chuyển sang trạng thái Firing:
kubectl delete pod -l app.kubernetes.io/name=yb-tserver -n yugabyte --force --grace-period=0
kubectl get pods -n yugabyte
Phân tích các chỉ số hiệu năng quan trọng của YugabyteDB
Để tối ưu hóa hệ thống, bạn cần hiểu ý nghĩa sâu của các metrics đã thu thập được. Dưới đây là phân tích chi tiết các chỉ số cốt lõi mà bạn cần theo dõi trên dashboard Grafana hoặc qua PromQL.
1. YB TServer Latency (ybs_tserver_latency_p99_us): Đây là chỉ số quan trọng nhất về trải nghiệm người dùng. Nó đo thời gian xử lý một request từ khi nhận đến khi trả lời (P99 - 99% request nhanh hơn giá trị này). Nếu giá trị này tăng đột biến (>10ms cho YSQL), nguyên nhân thường do GC (Garbage Collection) nặng, disk I/O bottleneck, hoặc contention trên lock.
2. Throughput (ybs_tserver_requests_per_second): Đo lường khả năng xử lý của cụm. Nếu throughput giảm khi load tăng, hệ thống đang bị giới hạn tài nguyên (CPU hoặc Network). Cần so sánh giữa Read QPS và Write QPS để cân bằng workload.
3. Replication Lag (ybs_tserver_replication_lag_seconds): Chỉ số này đo độ trễ giữa Leader và Follower. Trong YugabyteDB, nếu lag > 0, có thể xảy ra tình trạng đọc dữ liệu cũ (stale read) nếu ứng dụng không cấu hình đọc từ Leader. Lag tăng cao thường do Follower bị quá tải CPU hoặc mạng bị nghẽn.
4. Table Leader Distribution (ybs_tserver_is_leader): YugabyteDB tự động cân bằng Leader của các Tablet. Nếu bạn thấy một TServer nắm giữ quá nhiều Leader so với các node khác, workload sẽ không đồng đều. Kiểm tra metric này để đảm bảo phân phối Leader đều trên tất cả các node.
Để phân tích nhanh một sự cố, hãy sử dụng PromQL trong tab Explore của Grafana hoặc Prometheus với các query mẫu:
# Tìm node có latency cao nhất trong 5 phút qua
max_over_time(yb_tserver_latency_p99_us[5m]) by (pod)
# Kiểm tra tỷ lệ lỗi (Error Rate)
rate(yb_tserver_requests_failed_total[5m]) / rate(yb_tserver_requests_total[5m]) * 100
# Phân tích Disk I/O wait
rate(node_disk_io_time_seconds_total[5m])
Kết quả mong đợi: Bạn có thể xác định chính xác pod nào gây ra bottleneck và nguyên nhân cụ thể (ví dụ: pod yb-tserver-2 có latency cao do disk full hoặc CPU usage 100%).
Verify phân tích bằng cách thực hiện stress test có chọn lọc và quan sát sự thay đổi của các metric trên dashboard Grafana theo thời gian thực.
Điều hướng series:
Mục lục: Series: Xây dựng hệ thống Database phân tán với YugabyteDB và Kubernetes
« Phần 6: Cấu hình sao lưu và phục hồi (Backup & Restore)
Phần 8: Nâng cao: Xử lý sự cố và tối ưu hóa hệ thống »