Posted inMonitoring

Hướng dẫn cài đặt Sentry Self-hosted: Giám sát lỗi ứng dụng Web từ A-Z

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

Bối cảnh & Tại sao mình chọn Sentry Self-hosted?

Hệ thống monitoring của mình từng dựa hoàn toàn vào Prometheus và Grafana để theo dõi 15 server. Setup này hoạt động rất tốt trong việc cảnh báo sự cố hạ tầng. Tuy nhiên, khi gặp lỗi NullPointerException hay KeyError, Prometheus hoàn toàn “bó tay” vì nó không thể soi vào tầng code. Trước đây, mình thường phải SSH vào từng server, lục lọi hàng GB log trên Graylog để tìm dấu vết. Quá trình này cực kỳ nản và tốn thời gian.

Sau 6 tháng đưa Sentry Self-hosted vào vận hành, quy trình debug của team đã thay đổi 180 độ. Thay vì chỉ báo lỗi chung chung, Sentry cung cấp chi tiết stack trace, biến môi trường và cả thông tin trình duyệt của user. Mình chọn bản Self-hosted thay vì Cloud (SaaS) vì hai lý do lớn: Tiết kiệm khoảng $26/tháng (gói Team) khi lượng event tăng cao và đảm bảo dữ liệu người dùng không rời khỏi hạ tầng công ty.

Yêu cầu hệ thống: Đừng coi thường “con quái vật” này

Sentry thực chất là một hệ sinh thái phức tạp với PostgreSQL, Redis, ClickHouse, Kafka và hàng tá Workers. Nếu bạn định chạy nó trên một con VPS 1GB hay 2GB RAM, lời khuyên chân thành là: Hãy bỏ cuộc ngay từ đầu.

  • CPU: Tối thiểu 4 Cores (để xử lý các luồng Kafka và ClickHouse).
  • RAM: Tối thiểu 8GB (Mình khuyến nghị 16GB để hệ thống chạy mượt mà lâu dài).
  • Disk: 20GB+ dung lượng trống. Ưu tiên SSD vì tốc độ ghi log của ClickHouse rất lớn.
  • OS: Ubuntu 22.04 LTS hoặc các distro hỗ trợ Docker hiện đại.

Các bước cài đặt nhanh gọn

Sentry cung cấp script cài đặt tự động giúp giảm bớt gánh nặng cấu hình thủ công. Mình sẽ clone trực tiếp từ repository chính thức.

1. Tải bộ cài đặt

cd /opt
sudo git clone https://github.com/getsentry/self-hosted.git
cd self-hosted

2. Khởi chạy Script setup

Bạn nên kiểm tra các bản Release trên GitHub để checkout version ổn định nhất. Nếu không, script sẽ tự động lấy bản mới nhất trên nhánh master.

sudo ./install.sh

Quá trình này mất khoảng 15 phút tùy vào tốc độ mạng. Script sẽ kéo hàng chục Docker Image và thiết lập database. Khi màn hình hỏi tạo tài khoản admin, hãy chọn Y và nhập thông tin đăng nhập.

3. Kích hoạt hệ thống

Sau khi script hoàn tất, hãy đánh thức các container:

docker-compose up -d

Lúc này, giao diện Sentry đã sẵn sàng tại địa chỉ http://IP_SERVER:9000.

Tinh chỉnh để chạy ổn định trong thực tế

Để Sentry thực sự làm việc hiệu quả, bạn không nên giữ nguyên cấu hình mặc định. Dưới đây là hai thứ mình luôn chỉnh sửa ngay lập tức.

Cấu hình Email (SMTP)

Thiếu email, Sentry sẽ trở nên “câm điếc” vì không thể gửi cảnh báo hay reset mật khẩu. Hãy mở file sentry/config.yml và điền thông số SMTP:

mail.backend: 'smtp'
mail.host: 'smtp.gmail.com'
mail.port: 587
mail.username: '[email protected]'
mail.password: 'your-app-password'
mail.use-tls: true

Chặn đứng nguy cơ đầy ổ cứng

Dữ liệu event tích tụ rất nhanh. Nếu không kiểm soát, ổ cứng sẽ báo đỏ chỉ sau vài tuần. Mình thường chỉnh biến SENTRY_EVENT_RETENTION_DAYS trong file .env xuống còn 30 ngày. Con số này là vừa đủ để trace lỗi mà không làm quá tải storage.

Kết nối ứng dụng vào Sentry

Sau khi server đã chạy, việc tích hợp vào code chỉ mất vài phút. Dưới đây là ví dụ cho hai stack phổ biến nhất.

Với Python (Flask/FastAPI)

import sentry_sdk
from sentry_sdk.integrations.flask import FlaskIntegration

sentry_sdk.init(
    dsn="http://[email protected]/1",
    integrations=[FlaskIntegration()],
    traces_sample_rate=0.1, # Chỉ lấy mẫu 10% để tiết kiệm tài nguyên
)

Với Frontend (React/Vue)

Theo dõi lỗi phía Client là tính năng đáng tiền nhất. Bạn sẽ thấy được cả những lỗi JS mà user gặp phải nhưng không bao giờ báo lại.

import * as Sentry from "@sentry/react";

Sentry.init({
  dsn: "http://[email protected]/1",
  integrations: [new Sentry.BrowserTracing()],
  tracesSampleRate: 0.1,
});

Đúc kết sau 6 tháng vận hành

Tính năng Issue Grouping là cứu cánh thực sự. Khi 1.000 user cùng gặp một lỗi, Sentry sẽ gom chúng lại thành một dòng duy nhất thay vì dội bom inbox của bạn bằng 1.000 email rác. Điều này giúp team tập trung vào những lỗi có sức ảnh hưởng lớn nhất.

Vài kinh nghiệm “xương máu”:

  • Tránh dùng 100% Sample Rate: Với app có traffic lớn, gửi trace cho mọi request sẽ khiến network bị nghẽn. Hãy bắt đầu với 10% (0.1) và điều chỉnh dần.
  • Luôn upload Source Maps: Nếu không có Source Maps, lỗi Frontend sẽ chỉ là những dòng code minified vô nghĩa. Hãy tích hợp bước upload này vào CI/CD.
  • Bảo vệ DSN: Tuyệt đối không commit DSN vào các repo công khai để tránh bị kẻ xấu spam dữ liệu rác vào server.

Tự triển khai Sentry ban đầu có vẻ tốn sức, nhưng giá trị nó mang lại là vô giá. Chỉ số MTTR (thời gian xử lý sự cố) của team mình đã giảm từ vài giờ xuống còn vài phút. Chúng mình biết chính xác lỗi ở đâu ngay khi nó vừa phát sinh, thay vì ngồi đoán mò qua những dòng log khô khan.

Share:
Tags: