99 Ngày Spring — Ngày 93: Monitoring với Prometheus và Grafana

Log kể chuyện của từng request; metric cho biết sức khỏe của cả hệ thống theo thời gian. Bộ đôi phổ biến là Prometheus để thu thập và truy vấn, Grafana để vẽ biểu đồ. Spring Boot đã đo sẵn rất nhiều thứ qua Micrometer, nên việc của bạn chủ yếu là phơi ra, hỏi đúng câu và cảnh báo đúng lúc.

1. Phơi metric qua Actuator

Thêm spring-boot-starter-actuator và micrometer-registry-prometheus, rồi mở endpoint prometheus. Ứng dụng sẽ trả metric dạng văn bản tại /actuator/prometheus: HTTP server, JVM, pool kết nối, Kafka và nhiều thứ khác. Chỉ mở những endpoint cần thiết và đặt chúng trên cổng quản trị riêng hoặc sau lớp xác thực, vì chúng tiết lộ thông tin nội bộ.

management.endpoints.web.exposure.include=health,info,prometheus
management.server.port=9091
management.metrics.tags.application=orders
management.metrics.distribution.percentiles-histogram.http.server.requests=true

2. Prometheus scrape theo chu kỳ

Prometheus dùng mô hình kéo: cứ mỗi chu kỳ nó gọi endpoint của từng instance và lưu giá trị kèm thời điểm. Ba loại metric cần nhớ: counter chỉ tăng, như số request; gauge lên xuống, như số kết nối đang dùng; timer hoặc histogram ghi phân bố thời gian. Tự thêm metric nghiệp vụ qua MeterRegistry, và giữ tag ở số lượng giá trị nhỏ: đưa userId hay URL thô vào tag sẽ làm số chuỗi thời gian bùng nổ.

scrape_configs:
  - job_name: orders
    metrics_path: /actuator/prometheus
    scrape_interval: 15s
    static_configs:
      - targets: ["orders:9091"]

3. PromQL cho ba câu hỏi chính

Với một service, ba con số nói lên gần hết: lưu lượng, tỷ lệ lỗi và độ trễ. Counter chỉ có ý nghĩa khi lấy tốc độ thay đổi bằng rate() trên một cửa sổ thời gian. Độ trễ nên nhìn bằng phân vị như p99 chứ không phải trung bình, vì trung bình giấu mất nhóm người dùng chậm nhất. Phân vị tính từ histogram bằng histogram_quantile, nên cần bật histogram như ở phần một.

# requests per second
sum(rate(http_server_requests_seconds_count{application="orders"}[5m]))

# error ratio
sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m]))
  / sum(rate(http_server_requests_seconds_count[5m]))

# p99 latency per endpoint
histogram_quantile(0.99, sum by (le, uri)
  (rate(http_server_requests_seconds_bucket[5m])))

4. Dashboard và alert

Trong Grafana, thêm Prometheus làm data source rồi dựng một dashboard cho mỗi service với ba hàng: lưu lượng, lỗi và độ trễ ở trên cùng, tiếp theo là tài nguyên như heap, GC, pool kết nối. Alert nên dựa trên triệu chứng người dùng cảm nhận được, có điều kiện kéo dài đủ lâu để tránh báo động giả, và mỗi alert phải dẫn tới một hành động cụ thể.

• Alert theo tỷ lệ lỗi và p99, không theo CPU đơn thuần.

• Thêm for: 5m để bỏ qua các đỉnh ngắn.

• Mỗi alert kèm link dashboard và hướng dẫn xử lý.

• Theo dõi pool kết nối đang chờ và số luồng: chúng báo trước sự cố.

groups:
  - name: orders
    rules:
      - alert: OrdersHighErrorRate
        expr: |
          sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m]))
            / sum(rate(http_server_requests_seconds_count[5m])) > 0.02
        for: 5m
        labels: { severity: page }

Metric tốt trả lời được người dùng có đang bị ảnh hưởng không. Ngày 94 tự động hóa đường đi từ commit tới môi trường chạy với CI/CD.

Tài liệu đối chiếu

• https://docs.spring.io/spring-boot/reference/actuator/metrics.html

• https://prometheus.io/docs/prometheus/latest/querying/basics/