Posted inMonitoring

Cài đặt Pyrra: Quản lý SLO và Alert theo phong cách Google SRE

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

Nghịch lý: Dashboard xanh mướt nhưng khách hàng vẫn phàn nàn

Bạn đã bao giờ rơi vào cảnh Dashboard Prometheus hiện thị CPU/RAM cực kỳ ổn định, nhưng Slack vẫn “nổ” liên tục vì user kêu ứng dụng chậm chưa? Trước đây mình từng quản lý hệ thống 15 server với đầy đủ alert cơ bản. Tuy nhiên, mình nhận ra mình đang đo những thứ máy móc quan tâm thay vì trải nghiệm thực tế của người dùng.

Đó là lúc SLO (Service Level Objectives) trở thành chìa khóa. Thay vì chỉ canh chừng server sống hay chết, chúng ta đo lường: “Có bao nhiêu % request thành công trong 30 ngày qua?”. Tuy nhiên, việc tự viết hàng trăm dòng PromQL để tính Error Budget hay Burn Rate là một cực hình. Pyrra ra đời để giải quyết chính xác sự phức tạp này.

4 khái niệm sống còn trong quản trị hệ thống

Để dùng Pyrra hiệu quả, bạn cần phân biệt rõ 4 thuật ngữ sau:

  • SLI (Indicator): Chỉ số đo lường thực tế, như tỷ lệ request trả về code 200.
  • SLO (Objective): Mục tiêu bạn nhắm tới. Ví dụ: 99.9% request phải thành công. Với mức này, bạn chỉ có 43.2 phút downtime mỗi tháng.
  • Error Budget (Ngân sách lỗi): Khoảng sai số cho phép (0.1%). Đây là “hạn mức” để bạn bảo trì hoặc thử nghiệm tính năng mới.
  • Burn Rate (Tốc độ tiêu thụ): Tốc độ bạn đang “đốt” ngân sách lỗi. Nếu Burn Rate là 14.4, bạn sẽ tiêu sạch ngân sách cả tháng chỉ trong vòng 2 ngày.

Pyrra giúp bạn định nghĩa SLO bằng file YAML ngắn gọn. Sau đó, nó tự động sinh ra các Prometheus Recording Rules cực kỳ phức tạp cho bạn.

Triển khai Pyrra với Docker Compose

Cách nhanh nhất để thử nghiệm là dùng Docker Compose. Pyrra cần kết nối trực tiếp với server Prometheus của bạn.

version: '3.8'
services:
  pyrra:
    image: ghcr.io/pyrra-dev/pyrra:v0.7.0
    container_name: pyrra
    ports:
      - "9099:9099"
    command:
      - api
      - --prometheus-url=http://prometheus:9090
    restart: always

  pyrra-filesystem:
    image: ghcr.io/pyrra-dev/pyrra:v0.7.0
    container_name: pyrra-filesystem
    volumes:
      - ./slo-definitions:/etc/pyrra/slo
    command:
      - filesystem
      - --prometheus-url=http://prometheus:9090
      - --config-files=/etc/pyrra/slo/*.yaml
    restart: always

Trong setup này, component api đảm nhận giao diện UI. Component filesystem sẽ quét và nạp các file định nghĩa SLO từ thư mục local.

Định nghĩa SLO đầu tiên của bạn

Giả sử bạn có service trả về metric http_requests_total. Bạn muốn thiết lập SLO 99% request thành công. Hãy tạo file slo-definitions/api-success-rate.yaml:

apiVersion: pyrra.dev/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: api-success-rate
  labels:
    service: backend-api
spec:
  description: Tỷ lệ request thành công của API backend phải đạt trên 99%.
  target: "99"
  window: 28d
  indicator:
    ratio:
      errors:
        metric: http_requests_total{job="backend", code=~"5.."}
      total:
        metric: http_requests_total{job="backend"}

Cấu trúc này minh bạch hơn nhiều so với việc tự tính toán rate trong 28 ngày bằng PromQL thủ công.

Tích hợp và theo dõi thực tế

Pyrra không lưu trữ dữ liệu mà chỉ tạo ra các Rule. Nếu dùng Kubernetes, Pyrra sẽ tự tạo PrometheusRule object thông qua Operator. Với server truyền thống, bạn chỉ cần copy các rule từ giao diện Pyrra vào file cấu hình Prometheus.

Khi truy cập http://localhost:9099, bạn sẽ thấy các chỉ số quan trọng:

  • Objective: Mục tiêu 99%.
  • Availability: Hiệu suất thực tế hệ thống đang chạy.
  • Error Budget Remaining: Phần trăm ngân sách lỗi còn lại trước khi vi phạm cam kết (SLA).

Cơ chế này giúp mình phát hiện sự cố từ sớm. Chỉ cần nhìn vào Burn Rate, mình biết ngay hệ thống đang “chảy máu” dù chưa chết hẳn.

Tự động hóa Alert theo tiêu chuẩn Google

Pyrra áp dụng triết lý Multi-window Multi-burn-rate của Google. Thay vì báo động ngay khi có 1 request lỗi, nó chỉ gửi alert dựa trên tốc độ tiêu thụ ngân sách:

  • Critical Alert: Bạn đang đốt ngân sách quá nhanh, hệ thống sẽ sập trong vài giờ nếu không xử lý.
  • Warning Alert: Tốc độ đốt lỗi chậm hơn nhưng sẽ gây nguy hiểm cho SLO trong vài ngày tới.

Cách tiếp cận này loại bỏ hoàn toàn các alert rác (flapping alerts) gây mệt mỏi cho kỹ sư on-call.

Lời kết

Dùng SLO giúp team Dev và Ops nói chung một ngôn ngữ. Thay vì tranh cãi CPU 80% có quan trọng không, hãy nhìn vào Error Budget. Nếu ngân sách vẫn còn, cứ tự tin deploy. Nếu sắp cạn, hãy dừng lại để tối ưu hệ thống.

Pyrra là công cụ đắc lực để bạn bắt đầu chuẩn hóa vận hành mà không cần giỏi PromQL. Nếu đang quản lý trên 10 microservices, bạn nên cài đặt thử ngay hôm nay.

Share:
Tags: