Posted inMonitoring

Giám sát Redis: Đừng để ‘chết’ RAM rồi mới lo! (Prometheus + Redis Exporter)

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

Cảnh tượng quen thuộc: SSH check tay hay Monitoring tự động?

Hồi mới đi làm, mỗi lần hệ thống chậm hay app báo lỗi cache, việc đầu tiên mình làm là cuống cuồng SSH vào server. Mình gõ lệnh redis-cli info rồi căng mắt đọc đống text dài dằng dặc để xem RAM còn bao nhiêu. Cảm giác lúc đó rất thụ động. Giờ đây, mình chỉ cần mở dashboard Grafana khi đang nhâm nhi cafe là biết ngay node Redis ở Singapore đang “thở” thế nào. Sự khác biệt nằm ở hệ thống giám sát tự động.

Nhìn rộng ra, bạn thường sẽ rơi vào 3 kịch bản khi cần kiểm tra sức khỏe Redis:

  • Cách 1: Manual Check (Thủ công): Dùng redis-cli info. Cách này nhanh, không cần cài đặt. Tuy nhiên, nó chỉ là ảnh chụp tức thời. Bạn không thể biết lúc 2 giờ sáng RAM có bị nhảy vọt (spike) hay không.
  • Cách 2: Dùng SaaS (Datadog, New Relic): Rất xịn, chỉ cần vài click là xong. Nhưng chi phí rất “chát”. Nếu bạn có khoảng 10-20 node Redis, hóa đơn hàng tháng sẽ khiến sếp bạn phải nhíu mày.
  • Cách 3: Prometheus + Redis Exporter: Đây là tiêu chuẩn vàng hiện nay. Nó miễn phí, lưu trữ dữ liệu lịch sử lâu dài và cực kỳ linh hoạt.

Mỗi phương án đều có cái giá của nó

Để bạn chọn đúng công cụ, hãy cùng so sánh thực tế ưu và nhược điểm của từng ông:

1. Check tay qua CLI

  • Ưu điểm: Có sẵn trên mọi server.
  • Nhược điểm: Không có biểu đồ xu hướng. Dễ bỏ lỡ các lỗi xảy ra trong tích tắc (micro-bursts).

2. SaaS Monitoring

  • Ưu điểm: Giao diện cực đẹp, hỗ trợ tận răng.
  • Nhược điểm: Tốn kém. Dữ liệu đẩy ra ngoài có thể vi phạm chính sách bảo mật của các ngân hàng hoặc dự án lớn.

3. Prometheus + Redis Exporter

  • Ưu điểm: Làm chủ hoàn toàn dữ liệu. Tích hợp tốt với Alertmanager để bắn cảnh báo qua Telegram ngay khi Redis có biến.
  • Nhược điểm: Tốn công setup ban đầu.

Lý do mình luôn ưu tiên Redis Exporter

Nếu bạn đang chạy môi trường Production, đừng đắn đo, hãy chọn Prometheus. Redis là In-memory database nên nó cực kỳ nhạy cảm với RAM. Một logic code lỗi gây tràn RAM có thể khiến toàn bộ dịch vụ đứng hình trong vài giây. Redis Exporter đóng vai trò như một “thông dịch viên”. Nó chuyển đổi các thông số khô khan từ Redis sang định dạng mà Prometheus có thể đọc và vẽ biểu đồ.

Hướng dẫn triển khai thực tế

Mình giả định bạn đã có sẵn Prometheus. Nếu chưa, hãy xem lại bài hướng dẫn cài đặt Prometheus cơ bản trên blog nhé. Dưới đây là các bước để “thông nòng” dữ liệu.

Bước 1: Cài đặt Redis Exporter bằng Docker

Sử dụng Docker là cách nhanh và sạch nhất. Bạn có thể chạy Exporter ngay cạnh node Redis để tiện quản lý.

# Chạy Redis Exporter kết nối tới Redis (giả sử IP là 192.168.1.100)
docker run -d \
  --name redis_exporter \
  -p 9121:9121 \
  oliver006/redis_exporter:latest \
  --redis.addr=redis://192.168.1.100:6379

Lưu ý: Luôn đặt mật khẩu cho Redis ở môi trường thật. Khi đó, hãy thêm tham số auth:

docker run -d \
  --name redis_exporter \
  -p 9121:9121 \
  oliver006/redis_exporter:latest \
  --redis.addr=redis://192.168.1.100:6379 \
  --redis.password=MatKhauSieuKho2024

Bước 2: Cấu hình Prometheus Scrape

Sau khi Exporter chạy, nó sẽ mở cổng 9121. Bạn cần báo cho Prometheus ghé thăm địa chỉ này định kỳ. Mở file prometheus.yml và thêm:

scrape_configs:
  - job_name: 'redis_monitoring'
    static_configs:
      - targets: ['192.168.1.105:9121']
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance
        replacement: 'Redis-Core-Production'

Hãy khởi động lại Prometheus. Truy cập giao diện web, gõ redis_up. Nếu thấy kết quả trả về là 1, bạn đã thành công!

3 chỉ số “sinh tử” bạn cần đặc biệt lưu tâm

Đừng để lạc lối trong hàng trăm biểu đồ. Hãy tập trung vào 3 con số quyết định vận mệnh hệ thống:

1. Memory Usage (Mức chiếm dụng RAM)

Đây là chỉ số quan trọng nhất. Nếu used_memory chạm ngưỡng 90% maxmemory, hệ thống sẽ bắt đầu xóa key theo chính sách eviction hoặc từ chối ghi dữ liệu mới.

  • Metric: redis_memory_used_bytes
  • Kinh nghiệm: Hãy đặt Alert ở mức 80% để có thời gian nâng cấp RAM hoặc tối ưu lại code.

2. Cache Hit Rate (Tỷ lệ trúng cache)

Chỉ số này đo lường hiệu quả của cache. Nếu Hit Rate dưới 50%, tức là ứng dụng đang phải tìm dữ liệu trong Database chính quá nhiều. Điều này làm mất đi ý nghĩa của việc dùng Redis.

  • Công thức: hits / (hits + misses)
  • Mục tiêu: Một hệ thống ổn định thường có Hit Rate trên 80%.

3. Latency (Độ trễ)

Redis nổi tiếng với tốc độ phản hồi dưới 1ms. Nếu latency tăng vọt lên 10ms – 50ms, hãy kiểm tra ngay. Có thể ai đó đang chạy lệnh KEYS * trên Production — một sai lầm chết người gây nghẽn toàn bộ tiến trình đơn luồng của Redis.

Lời kết từ thực chiến

Một mẹo nhỏ: Đừng tốn thời gian tự vẽ Dashboard Grafana từ đầu. Hãy dùng Dashboard ID: 11835. Đây là mẫu chuẩn được cộng đồng tin dùng nhất. Bạn chỉ cần import ID này vào Grafana là có ngay một giao diện chuyên nghiệp.

Giám sát không chỉ để biết khi nào hệ thống sập. Mục tiêu cao nhất là biết khi nào nó sắp sập để can thiệp trước khi khách hàng kịp phàn nàn. Chúc các bạn quản trị Redis nhàn nhã hơn!

Share:
Tags: