Posted inMonitoring

Hướng dẫn giám sát HashiCorp Vault với Prometheus và Grafana: Theo dõi token lease, request latency và trạng thái unseal

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

Ba hướng tiếp cận khi giám sát HashiCorp Vault

Trong môi trường Production, Vault sập đồng nghĩa với tê liệt toàn hệ thống. Mọi service từ backend, worker đến CI/CD pipeline đều không lấy được database credential hay API key. Do đó, bài toán đặt ra là: theo dõi cụm Vault bằng cách nào cho chuẩn? Thực tế anh em DevOps thường cân nhắc giữa 3 phương án:

  • Cách 1: Health check định kỳ qua HTTP endpoint — Dùng Prometheus Blackbox Exporter hoặc uptime robot ping liên tục vào endpoint /v1/sys/health. Cách này chỉ đơn thuần kiểm tra status code 200 (active), 429 (standby) hay 503 (sealed).
  • Cách 2: Gom audit log về SIEM/ELK — Bật audit device (file hoặc syslog), sau đó đẩy toàn bộ sang Loki hoặc Elasticsearch. Mục đích chính là đếm lượng request và truy vết truy cập trái phép.
  • Cách 3: Bật telemetry native qua Prometheus & Grafana — Tận dụng engine telemetry tích hợp sẵn trong Vault. Cụm node sẽ trực tiếp xuất metrics theo chuẩn OpenMetrics qua endpoint /v1/sys/metrics.

Mỗi phương án có ưu và nhược điểm gì?

Mỗi cách tiếp cận sinh ra để giải quyết một mục tiêu riêng biệt:

1. HTTP Health Check (Blackbox)

  • Ưu điểm: Cực kỳ dễ làm. Bạn chỉ mất 5 phút cấu hình bên ngoài mà không cần sửa file config của Vault.
  • Nhược điểm: Hoàn toàn “mù” thông số bên trong. Bạn không thể biết Vault đang gánh 50.000 hay 500.000 token lease dở dang, độ trễ ghi vào Raft storage là bao nhiêu, hay node standby có đang bị trễ replication hay không.

2. Phân tích Audit Log

  • Ưu điểm: Ghi lại chính xác danh tính: token nào, gọi path nào, từ IP nào và lúc mấy giờ. Đây là dữ liệu bắt buộc cho compliance và audit.
  • Nhược điểm: Tốn I/O đĩa và băng thông kinh khủng. Đáng sợ nhất là cơ chế an toàn mặc định của Vault: nếu audit device bị nghẽn (ví dụ đĩa đầy hoặc log forwarder bị treo), Vault sẽ từ chối toàn bộ request gửi đến để chống lộ lọt dữ liệu. Biến log thành công cụ alert thời gian thực là con dao hai lưỡi.

3. Telemetry native với Prometheus

  • Ưu điểm: Nhẹ và an toàn. Số liệu được tổng hợp trực tiếp trên RAM rồi chờ Prometheus pull theo chu kỳ (thường là 15s hoặc 30s). Bạn nắm được mọi chỉ số sống còn: tình trạng unseal, phân phối latency p99, số lease sắp hết hạn, cho tới tình trạng snapshot của Raft backend.
  • Nhược điểm: Cần tính toán access control hợp lý để Prometheus cào được data mà không để lộ metrics nhạy cảm ra ngoài internet.

Setup chuẩn cho hệ thống Production

Kinh nghiệm thực tế cho thấy, mô hình tối ưu nhất là dùng native telemetry qua Prometheus + Grafana làm nguồn giám sát chính, kèm một job HTTP check đơn giản từ ngoài VPC làm fallback báo động mạng.

Trước đây khi chưa có dashboard tập trung, team mình từng gặp sự cố toát mồ hôi: một node worker reboot xong thì Vault bị sealed. Node này nằm im lìm suốt 3 ngày mà không ai hay biết. Đến khi node Active chính quá tải failover sang, toàn bộ hệ thống payment ngã gục vì node standby kia chưa được unseal. Có metrics Prometheus đẩy về Slack alert, tình huống đó đã được chặn từ phút đầu tiên.

Các bước triển khai thực tế

Bước 1: Kích hoạt Telemetry trên HashiCorp Vault

Truy cập vào từng node Vault trong cụm (thường là cluster 3 hoặc 5 node Integrated Storage – Raft) và mở file cấu hình:

sudo nano /etc/vault.d/vault.hcl

Bổ sung cấu hình telemetry và mở quyền truy cập unauthenticated cho endpoint metrics trong mạng nội bộ:

telemetry {
  prometheus_retention_time = "30s"
  disable_hostname          = true
}

# Listener lắng nghe kết nối nội bộ
listener "tcp" {
  address         = "0.0.0.0:8200"
  cluster_address = "0.0.0.0:8201"
  tls_disable     = 0
  tls_cert_file   = "/etc/vault.d/tls/vault.crt"
  tls_key_file    = "/etc/vault.d/tls/vault.key"
  
  # Bật metrics không cần token (chỉ an toàn khi nằm trong private subnet)
  telemetry {
    unauthenticated_metrics_access = true
  }
}

Lưu file và reload lại tiến trình Vault mà không làm gián đoạn traffic:

sudo systemctl reload vault
# Test thử curl ngay tại node
curl -k https://127.0.0.1:8200/v1/sys/metrics?format=prometheus

Nếu bạn quản lý nhiều server với config phức tạp, việc nhầm lẫn giữa định dạng HCL, JSON và YAML của Prometheus rất dễ xảy ra. Khi cần đối chiếu hoặc validate syntax nhanh, mình hay dùng YAML ↔ JSON Converter và JSON Formatter của ToolCraft. Điểm cộng lớn là các tool này chạy 100% bằng JavaScript trên trình duyệt của bạn, dữ liệu nhạy cảm không hề bị gửi về backend của họ.

Bước 2: Cấu hình Scrape Job trên Prometheus

Thêm cấu hình scrape target vào file prometheus.yml. Bạn nên liệt kê toàn bộ các node trong cluster để theo dõi cả node Active lẫn Standby:

scrape_configs:
  - job_name: 'hashicorp_vault'
    metrics_path: '/v1/sys/metrics'
    params:
      format: ['prometheus']
    scheme: 'https'
    tls_config:
      insecure_skip_verify: true # Đổi thành ca_file nếu hệ thống dùng Private CA
    static_configs:
      - targets:
          - '10.0.1.10:8200'
          - '10.0.1.11:8200'
          - '10.0.1.12:8200'

Kiểm tra tính hợp lệ của file cấu hình rồi reload service Prometheus:

promtool check config /etc/prometheus/prometheus.yml
curl -X POST http://localhost:9090/-/reload

Bước 3: Xây dựng PromQL Queries và Dashboard trên Grafana

Mở Grafana, tạo một Dashboard mới và tập trung vào 3 nhóm chỉ số quan trọng nhất dưới đây:

1. Trạng thái Unseal và Node Role (Active/Standby)

Metric vault_core_unsealed trả về 1 là bình thường, 0 nghĩa là node đang bị khóa. Dùng panel kiểu Stat với query:

vault_core_unsealed{job="hashicorp_vault"}

Để nhận diện node nào đang nắm quyền Leader xử lý ghi, dùng query:

vault_core_active{job="hashicorp_vault"}

Trong một cluster lành mạnh, luôn luôn phải có đúng 1 node trả về giá trị 1 cho metric này.

2. Đo lường Request Latency (Độ trễ xử lý)

Secret engine phản hồi chậm sẽ kéo theo cả ứng dụng khởi động lâu và tăng thời gian xử lý API. Query dưới đây tính thời gian xử lý request trung bình trong cửa sổ 5 phút:

rate(vault_core_handle_request_sum[5m]) / rate(vault_core_handle_request_count[5m])

Nếu latency vọt quá 100ms liên tục (thông thường chỉ khoảng 5ms – 15ms), hãy kiểm tra ngay IOPS của ổ cứng chứa Raft data hoặc nghẽn mạng giữa các node.

3. Kiểm soát Token Leak và Lease dở dang

Token leak là thủ phạm phổ biến nhất làm Vault cạn kiệt RAM. Trường hợp này xảy ra khi các pod microservices liên tục authenticate lấy token mới nhưng không revoke và không tái sử dụng. Theo dõi sát 2 metric này trên biểu đồ Time Series:

# Tổng số lease đang active trong hệ thống
vault_expire_num_leases

# Số lượng token đang còn hiệu lực
vault_token_count

Nếu thấy vault_expire_num_leases tăng đều hình bậc thang và chạm mốc trên 100.000 mà không hạ xuống, chắc chắn ứng dụng của bạn đang bị rò rỉ token hoặc đặt TTL quá dài.

Bước 4: Thiết lập Rule cảnh báo qua Alertmanager

Đừng chờ sự cố xảy ra mới mở Grafana xem. Hãy cấu hình alert tự động gửi về Slack/Telegram ngay khi có dấu hiệu bất thường:

groups:
  - name: vault_alerts
    rules:
      - alert: VaultNodeSealed
        expr: vault_core_unsealed == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Node Vault đang bị sealed: {{ $labels.instance }}"
          description: "Node {{ $labels.instance }} bị sealed hơn 1 phút. Cần SSH unseal ngay lập tức."

      - alert: VaultHighRequestLatency
        expr: (rate(vault_core_handle_request_sum[5m]) / rate(vault_core_handle_request_count[5m])) > 0.1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Latency của Vault tăng cao (>100ms)"
          description: "Thời gian phản hồi trung bình trên {{ $labels.instance }} vượt ngưỡng 100ms suốt 5 phút qua."

Chỉ cần kiểm soát tốt trạng thái unseal, độ trễ read/write và biểu đồ tăng trưởng token lease, bạn đã loại bỏ được 95% nguy cơ downtime bất ngờ cho cụm HashiCorp Vault.

Share:
Tags: