Posted inMonitoring

Giám sát Longhorn trên Kubernetes: Thiết lập Prometheus, Grafana và kinh nghiệm bắt bệnh thực tế

Monitoring tutorial - IT technology blog
Monitoring tutorial - IT technology blog

Khi cụm lưu trữ âm thầm ‘đình công’

Triển khai PostgreSQL, MySQL hay Kafka trên Kubernetes thường kéo theo bài toán chọn storage. Với nhiều team, Longhorn là lựa chọn hàng đầu. Giải pháp Distributed Block Storage này cài gọn qua Helm, quản lý trực quan và tự động dựng lại replica khi một node sập nguồn.

Tuy vậy, lưu trữ phân tán có một điểm nguy hiểm: nó thường hư hỏng trong im lặng. Pod crash thì Lens hay k9s nhấp nháy đỏ ngay. Còn volume Longhorn bị degraded do mất một replica? Ứng dụng vẫn đọc ghi bình thường. Bạn cứ ngỡ mọi thứ ổn thỏa. Đến khi node thứ hai gặp sự cố, cả volume lập tức rơi vào trạng thái Faulted. Lúc này, database dừng hoạt động và toàn bộ dữ liệu bị gián đoạn.

Một rủi ro khác là nghẽn Disk I/O. Latency ghi vọt từ 3ms lên 250ms khiến database tắc nghẽn, nhưng CPU và RAM của node vẫn báo xanh ngắt. Muốn vận hành ổn định, bạn phải dựng monitoring chuyên sâu cho Longhorn ngay khi vừa setup cluster.

Longhorn xuất metrics như thế nào?

Longhorn manager chạy dưới dạng DaemonSet trên từng node. Thành phần này mở sẵn endpoint /metrics theo chuẩn Prometheus tại port 9500. Dưới đây là 4 nhóm chỉ số quan trọng nhất cần đưa lên màn hình theo dõi:

  • Volume Robustness: Metric longhorn_volume_robustness biểu thị tình trạng sống còn của volume. Giá trị 1 là Healthy (đủ replica), 2 là Degraded (mất replica, đang rebuild), và 3 là Faulted (hỏng hoàn toàn, không thể mount).
  • Trạng thái Replica: Dùng longhorn_replica_state kết hợp với longhorn_node_storage_capacity_bytes để phát hiện replica bị ngắt kết nối do đầy đĩa hoặc lỗi mạng nội bộ.
  • Hiệu năng đọc/ghi (IOPS & Throughput): Các metric longhorn_volume_read_ops, longhorn_volume_write_ops và byte rate giúp bạn chỉ mặt workload nào đang ‘vắt kiệt’ ổ cứng vật lý.
  • Mức độ cấp phát vượt ngưỡng (Over-provisioning): Longhorn mặc định cho phép over-provisioning đến 200%. Nếu cụm có 1TB SSD vật lý, bạn có thể cấp ra tới 2TB PVC. Chỉ cần các service ghi đồng loạt vượt 1TB, toàn bộ cluster sẽ cạn kiệt dung lượng đĩa trước khi bạn kịp nhận thông báo từ OS.

Thực hành: Cấu hình giám sát Longhorn với Prometheus Operator

Nếu cụm của bạn đã cài kube-prometheus-stack, hãy làm theo 3 bước sau để tự động cào dữ liệu và kích hoạt cảnh báo.

Bước 1: Tạo ServiceMonitor cho Longhorn Manager

Tạo file longhorn-servicemonitor.yaml để chỉ định Prometheus scrape metrics từ namespace longhorn-system định kỳ 30 giây một lần:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: longhorn-prometheus-servicemonitor
  namespace: longhorn-system
  labels:
    release: prometheus
spec:
  selector:
    matchLabels:
      app: longhorn-manager
  namespaceSelector:
    matchNames:
      - longhorn-system
  endpoints:
  - port: manager
    path: /metrics
    interval: 30s
    scrapeTimeout: 10s

Áp dụng cấu hình:

kubectl apply -f longhorn-servicemonitor.yaml

Đợi khoảng 1 phút, hãy mở giao diện Prometheus và gõ thử longhorn_volume_actual_size_bytes. Nếu đồ thị trả về dữ liệu, pipeline đã hoạt động thông suốt.

Bước 2: Cài đặt Grafana Dashboard

Bạn không cần tự thiết kế bảng điều khiển từ con số 0. Cộng đồng Longhorn đã chia sẻ sẵn template rất đầy đủ.

  1. Truy cập Grafana, vào menu Dashboards > New > Import.
  2. Nhập Dashboard ID: 13032 (Longhorn Overview chính thức) hoặc 13437 rồi nhấn Load.
  3. Chọn Prometheus Data Source tương ứng của cluster và bấm Import.

Dashboard này cung cấp ngay góc nhìn tổng quan: dung lượng thực tế so với dung lượng cam kết, biểu đồ Read/Write IOPS thời gian thực của từng volume và danh sách các replica đang hỏng hóc.

Bước 3: Thiết lập Alerting Rule chống cháy

Dashboard chỉ phục vụ lúc bạn chủ động rà soát. Cảnh báo tự động mới là công cụ cứu hệ thống lúc 2 giờ sáng. Hãy tạo file longhorn-alerts.yaml:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: longhorn-alerts
  namespace: longhorn-system
  labels:
    release: prometheus
spec:
  groups:
  - name: longhorn.rules
    rules:
    - alert: LonghornVolumeDegraded
      expr: longhorn_volume_robustness == 2
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "Volume {{ $labels.volume }} đang ở trạng thái Degraded"
        description: "Volume {{ $labels.volume }} bị thiếu ít nhất 1 replica hơn 10 phút. Cần kiểm tra disk hoặc node storage."

    - alert: LonghornVolumeFaulted
      expr: longhorn_volume_robustness == 3
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: "Volume {{ $labels.volume }} bị FAULTED!"
        description: "Volume đã mất toàn bộ replica hoặc không mount được. Dữ liệu đang gián đoạn!"

    - alert: LonghornDiskUsageHigh
      expr: (longhorn_node_storage_usage_bytes / longhorn_node_storage_capacity_bytes) * 100 > 85
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Ổ cứng trên node {{ $labels.node }} vượt 85%"
        description: "Dung lượng Longhorn trên node {{ $labels.node }} đã chạm {{ $value | printf `%.1f` }}%. Cần bổ sung đĩa hoặc dọn dẹp snapshot."

Triển khai rule vào cluster:

kubectl apply -f longhorn-alerts.yaml

Kinh nghiệm thực chiến: Tinh chỉnh để tránh báo động giả

1. Giảm thiểu Alert Fatigue do restart node

Khi mới vận hành, nhiều kỹ sư đặt cảnh báo longhorn_volume_robustness == 2 kích hoạt chỉ sau 1 phút. Hậu quả là mỗi đợt rolling update hoặc khởi động lại node worker để vá kernel, Longhorn cần 3-7 phút đồng bộ lại một volume 50GB. Kênh Telegram và Slack liên tục réo chuông báo động giả.

Giải pháp là nâng khoảng trễ for: lên 10m đến 15m đối với mức cảnh báo warning. Nếu sau 10 phút mà quá trình re-sync chưa hoàn tất, đó chắc chắn là sự cố vật lý thật sự: ổ cứng bad sector, network phân mảnh hoặc phân vùng đĩa bị read-only.

2. Dò lỗi Noisy Neighbor qua thông số IOPS

Khi API đột ngột tăng thời gian phản hồi, đừng chỉ kiểm tra CPU utilization. Hãy bật tab IOPS trên Grafana và chạy query sau:

topk(5, rate(longhorn_volume_read_ops[5m]) + rate(longhorn_volume_write_ops[5m]))

Query này lập tức lọc ra 5 volume đang ngốn tài nguyên I/O lớn nhất. Trong thực tế, chỉ cần một truy vấn báo cáo thiếu index chạy full scan trên MySQL tạo ra 3.500 IOPS liên tục là đủ làm tê liệt các container khác đang chia sẻ chung ổ SSD SATA (giới hạn ~500-600 IOPS) trên cùng node.

3. Kiểm soát Snapshot ‘Zombie’

Cơ chế recurring snapshot của Longhorn hoạt động hiệu quả, nhưng nếu thiếu chính sách xóa định kỳ (retain), dữ liệu snapshot sẽ âm thầm nuốt sạch ổ cứng. Bạn nên lập biểu đồ so sánh longhorn_volume_actual_size_bytes với dung lượng yêu cầu trong PersistentVolumeClaim (PVC).

Nếu một volume 20GB lại đang chiếm tới 60GB dung lượng thực tế trên disk, chắc chắn bạn có hàng chục snapshot cũ chưa được purge. Hãy cài đặt CronJob định kỳ chạy snapshot purge hoặc cấu hình Retain hợp lý (ví dụ: chỉ giữ 3-5 bản gần nhất) để giải phóng block lưu trữ thừa.

Tóm lại

Vận hành storage trên Kubernetes không cho phép bạn suy đoán mơ hồ. Chỉ cần kết hợp ServiceMonitor, Grafana Dashboard ID 13032 và ngưỡng alert hợp lý, bạn đã kiểm soát được toàn bộ tình trạng đọc/ghi, dung lượng thực tế cũng như tuổi thọ replica. Hãy áp dụng ngay vào staging, mô phỏng thử nghiệm ngắt một node và quan sát nhịp rebuild của Longhorn trước khi đưa vào production.

Share:
Tags: