Sentry hay GlitchTip: So sánh self-hosted

Chi phí của hệ thống theo dõi lỗi self-hosted trước khi lưu event đầu tiên

Theo dõi lỗi self-hosted có một thông số quyết định toàn bộ lựa chọn: mức RAM tối thiểu. Tài liệu self-hosted của Sentry yêu cầu 4 lõi CPU, 16 GB RAM cùng 16 GB swap và 20 GB dung lượng đĩa trống, trước khi ứng dụng gửi một event. GlitchTip ghi rõ mức 512 MB. Tất cả lựa chọn trong bài đều nhận event từ cùng các Sentry SDK, nên đây không phải là quyết định về cách instrument code. Đây là quyết định về kích thước server mà bạn sẵn sàng trả tiền để duy trì hoạt động.

Các số liệu tài nguyên do dự án công bố, đặt cạnh nhau

Đây là các con số mà từng dự án tự công bố, tính đến tháng 8 năm 2026. Chúng không đo cùng một loại chỉ số, vì vậy hãy đọc ghi chú ở từng dòng trước khi so sánh.

[
  {
    "tool": "Sentry self-hosted",
    "published_ram_gb": 16,
    "notes": "documented minimum, plus 16 GB of swap"
  },
  {
    "tool": "Bugsink",
    "published_ram_gb": 4,
    "notes": "the vendor's own published benchmark box, 2 vCPU"
  },
  {
    "tool": "GlitchTip",
    "published_ram_gb": 0.5,
    "notes": "documented recommendation, 256 MB stated as the minimum"
  }
]

16 GB của Sentry là mức tối thiểu được ghi rõ trong tài liệu, và cùng trang đó khuyến nghị 32 GB. 0.5 GB của GlitchTip là mức khuyến nghị; dự án nêu 256 MB là mức tối thiểu để chạy, hoặc 128 MB cộng với swap nếu cấu hình cẩn thận. 4 GB của Bugsink không thuộc hai loại trên: đây là cấu hình máy mà nhà cung cấp dùng cho benchmark throughput của chính họ. Số liệu được công bố chỉ là điểm bắt đầu, không phải cam kết về lưu lượng event của bạn.

Sentry self-hosted: toàn bộ sản phẩm và toàn bộ chi phí

Stack chính thức là getsentry/self-hosted, một dự án Docker Compose chạy cùng các thành phần mà Sentry chạy trong môi trường production. Tài liệu của dự án mô tả đây là "đầy đủ tính năng và được đóng gói cho các môi trường triển khai có lưu lượng thấp và mục đích proof-of-concept". Đây là phần tóm tắt chính xác nhất. Bạn có mọi tính năng, đồng thời phải vận hành mọi thành phần cần thiết để các tính năng đó hoạt động.

Cài đặt từ một tagged release thay vì từ master:

VERSION=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/getsentry/self-hosted/releases/latest)
VERSION=${VERSION##*/}
git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
git checkout ${VERSION}
./install.sh

Sau đó khởi động:

docker compose up --wait

Mặc định, Sentry lắng nghe trên http://127.0.0.1:9000. Cần Docker Engine 19.03.6 trở lên và Docker Compose 2.32.2 trở lên. Compose cũ hơn sẽ lỗi do cú pháp trong file, không phải do Sentry.

Kiểm tra những gì bạn thực sự đã khởi động:

docker compose ps
free -h

docker compose ps liệt kê mọi service trong stack, và danh sách này khá dài: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator cùng nhiều worker và cron process. Hãy đếm một lần, vì đó chính là khối lượng bảo trì của bạn. Mỗi mục là một process có thể crash, làm đầy disk hoặc fail migration.

Nếu một service ở trạng thái Restarting, hãy kiểm tra memory trước tiên:

dmesg -T | grep -i 'out of memory'

Một dòng như Out of memory: Killed process 3412 (java) có nghĩa là OOM killer (out of memory killer) của kernel đã dừng một container vì máy hết RAM. Vì vậy service đó không bao giờ chuyển sang trạng thái healthy và stack không thể khởi động hoàn tất. Đây là kết quả thường gặp khi chạy full stack dưới mức tối thiểu được ghi trong tài liệu. Tài liệu cũng lưu ý về tốc độ disk: iowait trên 10% nghĩa là máy không xử lý kịp ingest pipeline. Đọc chỉ số này từ cột wa trong top, hoặc từ iostat -x 5 nếu bạn đã cài sysstat.

Upgrade là phần thường bị đánh giá thấp

Sentry self-hosted phát hành hàng tháng theo CalVer, một scheme version dựa trên lịch, với bản release chính vào ngày 15 mỗi tháng. Bạn không thể nhảy thẳng từ version cũ lên version mới nhất. Dự án quy định các hard stop version, và bạn phải checkout từng version theo đúng thứ tự để chạy các database migration tương ứng. Tính đến tháng 8 năm 2026, các hard stop đã công bố là 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 và 26.7.0. Tài liệu cũng liệt kê các release cần bỏ qua do vấn đề migration, gồm 23.7.0, 25.9.0, 25.12.0 và khoảng từ 26.3.0 đến 26.4.0.

Một lần upgrade gồm checkout rồi chạy lại installer:

git fetch
git checkout 26.7.0
./install.sh
docker compose up --wait

Hãy tạo snapshot cho server trước khi bắt đầu, vì migration trên một ClickHouse dataset lớn có thể chạy trong nhiều giờ. Nếu lỗi xảy ra giữa chừng, database sẽ nằm giữa hai schema. Nguyên nhân trực tiếp của phần lớn lần upgrade Sentry self-hosted thất bại là máy đã giữ nguyên một version trong một năm. Vì vậy, lần upgrade phải đi qua nhiều hard stop cùng lúc, và một trong các migration bị bỏ qua chính là migration cần thiết.

Bạn cũng cần biết thêm một điểm trước khi quyết định sử dụng. Sentry self-hosted được phát hành theo Functional Source License (FSL), do chính Sentry đưa ra. Đây là source code công khai nhưng không phải open source được OSI phê duyệt: bạn có thể tự chạy, nhưng không được bán nó dưới dạng một dịch vụ cạnh tranh. Mỗi release sẽ chuyển sang Apache 2.0 sau 2 năm kể từ khi phát hành.

GlitchTip: đáp án cho 512 MB

GlitchTip được cấp phép theo MIT và nhận event từ các SDK mã nguồn mở của Sentry. Vì vậy, ứng dụng đã được instrument chỉ cần đổi một giá trị để chuyển sang dùng GlitchTip: DSN (data source name, URL mà SDK gửi event đến). GlitchTip yêu cầu PostgreSQL 14 trở lên. Valkey hoặc Redis 7 trở lên là tùy chọn và giúp các instance lớn xử lý nhanh hơn.

Cài đặt chỉ cần Docker và một file compose:

sudo apt install docker.io
curl -O https://glitchtip.com/assets/compose.sample.yml
mv compose.sample.yml compose.yml

Chỉnh sửa phần environment trước khi khởi động. Bạn phải đặt các giá trị cho secret, domain và đường dẫn mail:

SECRET_KEY: <output of openssl rand -base64 50>
GLITCHTIP_DOMAIN: https://errors.example.com
DEFAULT_FROM_EMAIL: errors@example.com
EMAIL_URL: smtp://user:password@smtp.example.com:587

Mẫu cấu hình đã kết nối DATABASE_URL với service postgres riêng, vì vậy hãy giữ nguyên dòng đó trừ khi bạn trỏ đến database chạy ở nơi khác. GLITCHTIP_DOMAIN phải bao gồm scheme. Nếu thiếu https:// ở đầu, các liên kết trong email cảnh báo sẽ được tạo sai và trỏ đến một URL không phản hồi.

Khởi động và theo dõi lần boot đầu tiên:

docker compose up -d
docker compose logs -f web

Các image tag trong mẫu, tính đến tháng 8 năm 2026, là postgres:18, valkey/valkey:9 và glitchtip/glitchtip:6. Hãy cố định các tag này. File compose chứa latest sẽ nâng cấp database engine ở lần docker compose pull tiếp theo. Việc nhảy major version của Postgres trên một instance đang chạy có thể khiến error tracker đang hoạt động không khởi động được nữa.

Để chạy trong mức 256 MB đến 512 MB, hãy làm theo các comment có sẵn trong file mẫu để tắt các thành phần cần thiết, bắt đầu với Valkey và các tính năng log, uptime tùy chọn. Khi chạy không có Valkey, GlitchTip dùng database để xử lý cache và queue thay thế. Cách này chậm hơn nhưng vẫn đúng chức năng. Chế độ all in one chạy worker bên trong web process, vì vậy bạn chỉ cần duy trì một application container thay vì hai.

Đặt một proxy phía trước GlitchTip. Tài liệu GlitchTip yêu cầu proxy hoặc load balancer có khả năng buffer request và xử lý Transfer-Encoding dạng chunked. Tài liệu dùng nginx làm ví dụ triển khai. Nếu không buffer, một client chậm sẽ giữ application worker mở trong toàn bộ thời gian upload. Vì vậy, chỉ vài sender chậm cũng có thể chiếm hết worker, khiến các client bình thường bắt đầu timeout.

Nâng cấp là phần đơn giản:

docker compose pull
docker compose stop
docker compose up -d

Database migration tự động chạy khi khởi động. Tuy vậy, hãy tạo dump trước, vì migration tự động vẫn là một migration.

Bugsink: một container và một license cần đọc kỹ

Bugsink là lựa chọn nhẹ nhất trong ba công cụ. Nó dùng protocol của Sentry SDK và chạy mà không cần message queue hay service bên ngoài nào ngoài database. SQLite là mặc định. MySQL và PostgreSQL được hỗ trợ khi hệ thống vượt quá khả năng của SQLite.

Để thử giao diện trước khi quyết định, hãy chạy một instance tạm thời:

docker pull bugsink/bugsink:latest
docker run \
  -e SECRET_KEY=PUT_AN_ACTUAL_RANDOM_SECRET_HERE_OF_AT_LEAST_50_CHARS \
  -e CREATE_SUPERUSER=admin@example.org:admin \
  -e PORT=8000 \
  -p 8000:8000 \
  bugsink/bugsink

Mở http://localhost:8000/ rồi đăng nhập bằng địa chỉ và mật khẩu bạn đã truyền vào CREATE_SUPERUSER. Container này không giữ lại dữ liệu khi dừng. Với instance thực tế, hãy dùng compose sample của dự án. Sample này kết hợp bugsink/bugsink:2 với postgres:17-alpine và thiết lập DATABASE_URL, BASE_URL cùng BEHIND_HTTPS_PROXY. Hãy tạo secret đúng cách:

openssl rand -base64 50

BASE_URL phải khớp với URL mà người dùng và SDK thực sự sử dụng, bao gồm cả scheme. Nếu truy cập máy chủ tại https://errors.example.com mà vẫn để giá trị này là http://localhost:8000, mọi link trong email thông báo sẽ trỏ đến một host không resolve được đối với người đọc. Đặt BEHIND_HTTPS_PROXY thành true khi nginx hoặc Caddy thực hiện TLS termination (transport layer security) ở phía trước Bugsink. Nếu không, Bugsink sẽ tạo các URL http:// phía sau proxy https:// của bạn và trình duyệt sẽ chặn mixed content.

Nhà cung cấp công bố các số liệu throughput riêng: 18 event mỗi giây, mỗi event 50 KB, tương đương 1.5 triệu event mỗi ngày trên VPS 2 vCPU và 4 GB. Hãy xem đây là quy mô tham khảo của công cụ, không phải cam kết cho workload của bạn. Tuy vậy, con số này cho thấy giới hạn của nó cao hơn nhiều so với lượng event mà một ứng dụng nhỏ tạo ra.

Tiếp theo là license. Đây là phần cần đọc trước khi đưa Bugsink vào stack của bạn. Bugsink được phát hành theo PolyForm Shield License 1.0.0. Đây là source available, không phải open source: bạn có thể chạy và sửa đổi phần mềm, nhưng không được dùng nó để xây dựng một sản phẩm cạnh tranh với Bugsink. Với một error tracker nội bộ, hạn chế này thường không phát sinh. Nếu công ty bạn bán developer tooling, hãy để một người đọc license trước.

Theo dõi lỗi và quan sát LLM vẫn là hai công cụ

Tìm một công cụ vừa theo dõi lỗi vừa quan sát mô hình ngôn ngữ lớn (LLM), bạn sẽ thấy nhiều sản phẩm tuyên bố hỗ trợ cả hai. Hai loại dữ liệu này có cấu trúc khác nhau, nên việc hợp nhất vẫn chưa thực sự xảy ra. Công cụ theo dõi lỗi nhận một exception kèm stack trace, tính fingerprint từ đó, rồi gộp hàng nghìn lần xuất hiện thành một issue có bộ đếm. Công cụ tracing LLM nhận một span chứa prompt, response, số token và latency. Nó phải giữ lại từng bản ghi, vì hai lần gọi có input giống hệt nhau vẫn là hai event riêng biệt đáng xem.

Vì vậy, hãy chạy cả hai. Gửi exception đến công cụ theo dõi lỗi, còn gửi các lần gọi model đến một hệ thống được thiết kế cho mục đích đó: Langfuse self-host để tracing agent xử lý phần này, còn quan sát AI tự host tiếp cận cùng một bài toán theo hướng khác. Ứng dụng của bạn vốn đã tạo ra cả hai loại lỗi. Một lần gọi model trả về nội dung vô nghĩa nhưng đầy tự tin có thể không ném ra exception nào, nên công cụ theo dõi lỗi sẽ không bao giờ hiển thị nó cho bạn.

Disk tăng dần là lỗi sẽ quay lại sau này

Mọi error tracker đều là database có nhiều thao tác ghi và nhận dữ liệu đầu vào không có giới hạn. Ứng dụng của bạn quyết định lượng dữ liệu được ghi. Chỉ một bug mới trong đường chạy được gọi thường xuyên cũng có thể tạo ra một triệu event chỉ trong một đêm.

GlitchTip công bố một con số đáng dùng để lập kế hoạch: instance xử lý một triệu event mỗi tháng có thể cần 30 GB disk. Con số này đủ cho một tháng ingest ở tốc độ đó. retention window quyết định bạn lưu đồng thời bao nhiêu tháng.

Bugsink tiếp cận vấn đề từ hướng ngược lại. Thay vì quota cố định, nó áp dụng thuật toán retention dựa trên số lượng event và tuổi của event. Nó công khai các giới hạn: MAX_RETENTION_EVENT_COUNT cho toàn bộ installation, MAX_RETENTION_PER_PROJECT_EVENT_COUNT cho mỗi project và MAX_EVENT_AGE_DAYS làm giới hạn tuyệt đối. Đặt ngân sách event cho toàn bộ installation là cách trung thực để tính dung lượng disk, vì ngân sách đó chính là dung lượng disk.

Theo dõi các số liệu thực tế trên máy:

df -h /
docker system df -v
du -sh /var/lib/docker/volumes/*

docker system df -v in kích thước theo từng volume, nên bạn có thể biết service nào đang tăng dung lượng. Nếu một volume tăng vài gigabyte mỗi tuần nhưng network traffic không đổi, thường là retention chưa bao giờ được cấu hình. Khi đó không có gì bị xóa và giới hạn duy nhất là partition.

Memory cũng gặp cùng một vấn đề nhưng dưới dạng khác. Một stack không có giới hạn sẽ dùng hết lượng memory kernel cung cấp. Khi máy hết memory, OOM killer sẽ chọn process lớn nhất. Process đó có thể là web server của bạn thay vì tracker gây ra vấn đề. Đặt giới hạn cho mọi service: giới hạn memory trong Docker Compose giải thích cú pháp và cách container xử lý khi chạm giới hạn. Container bị kill khi chạm giới hạn của chính nó là một lỗi được cô lập. Container bị kernel kill có thể kéo theo một service khác.

Ngăn xếp nào phù hợp với VPS nào

• 1 GB hoặc 2 GB và còn dư tài nguyên: Chạy GlitchTip ở chế độ all in one với Valkey tắt, hoặc chạy Bugsink trên SQLite. Cả hai đều hoạt động ổn với một vài ứng dụng.
• 4 GB: Chạy Bugsink với PostgreSQL, hoặc GlitchTip với Valkey bật và một worker service riêng. Đây là mức tài nguyên mà bạn không cần tiếp tục tinh chỉnh, chỉ cần chạy hệ thống.
• 8 GB: Vẫn chưa đủ cho Sentry stack chính thức. Hãy dùng tài nguyên này để kéo dài thời gian lưu trữ và tăng dung lượng disk cho light option bạn đã chọn.
• Tối thiểu 16 GB, khuyến nghị 32 GB: Chạy Sentry self-hosted stack chính thức, và chỉ khi bạn cần một tính năng Sentry mà các project nhẹ hơn không triển khai. Trước tiên, hãy kiểm tra tính năng cụ thể đó trong documentation của từng project, vì các project tương thích đã hỗ trợ những tính năng phổ biến.

Dù bạn chạy lựa chọn nào, error tracker cũng không thể tự báo khi nó dừng hoạt động. Hãy đặt một check từ một máy khác: Uptime Kuma giám sát từ một máy khác sẽ cho bạn biết tracker đã down. Đây chính là lúc application bắt đầu phát sinh lỗi nhưng không có hệ thống nào ghi nhận chúng.

Khi gói dịch vụ host là lựa chọn rẻ hơn

Tự host hệ thống theo dõi lỗi có lợi khi quy định về nơi lưu trữ dữ liệu bắt buộc bạn phải làm vậy, hoặc khi số lượng event đủ lớn khiến chi phí tính theo từng event trở nên đắt đỏ. Ngoài các trường hợp đó, hãy tính toán một cách thực tế. Mức tối thiểu được Sentry công bố là server có 16 GB RAM, 4 core và ổ đĩa nhanh; VPS có cấu hình như vậy không phải là VPS giá rẻ. Sau đó còn có công việc vận hành: lần lượt vượt qua từng hard stop và tạo snapshot trước mỗi lần migration, vài lần mỗi năm.

GlitchTip và Bugsink thay đổi hoàn toàn bài toán chi phí này, vì một máy có 512 MB đến 4 GB RAM có giá thấp, còn việc nâng cấp chỉ là một docker compose pull. Đó là lý do hầu hết những người đặt câu hỏi này cuối cùng chọn một trong các project tương thích thay vì stack chính thức. Họ cần theo dõi lỗi, không cần một data pipeline phân tán phải liên tục giám sát.

Nếu bạn vẫn đang xác định những gì thực sự nên chạy trên server, danh sách rộng hơn về những gì đáng tự host sẽ đặt hệ thống theo dõi lỗi bên cạnh các service khác đang cạnh tranh cùng lượng RAM.

FAQ

Tôi có thể tự host Sentry trên VPS 2 GB không?

Không. Tài liệu self-hosted của Sentry nêu yêu cầu tối thiểu là 4 CPU core, 16 GB RAM cùng 16 GB swap và 20 GB disk trống. Stack đồng thời chạy Postgres, ClickHouse, Kafka, Redis và nhiều worker process, nên trên máy nhỏ, kernel sẽ kill các container trước khi quá trình cài đặt hoàn tất. Xác nhận bằng dmesg -T | grep -i 'out of memory'; lệnh này in ra một dòng nêu tên process đã bị kill. Với VPS 2 GB, hãy dùng GlitchTip, công cụ công bố yêu cầu 512 MB, hoặc Bugsink, chạy dưới dạng một container duy nhất trên SQLite.

Tôi có phải sửa code ứng dụng khi chuyển từ Sentry sang GlitchTip hoặc Bugsink không?

Không. Cả hai đều nhận event từ các SDK mã nguồn mở của Sentry, nên bạn giữ nguyên SDK đã cài và chỉ thay đổi một giá trị: DSN, tức URL mà SDK gửi event đến. Nếu DSN vẫn đang hardcode, hãy chuyển nó vào biến môi trường, trỏ đến host mới, rồi tạo một exception thử nghiệm và theo dõi xem event có đến nơi không. Nếu không thấy gì, kiểm tra project identifier trong DSN có khớp với một project tồn tại trên server mới không, đồng thời kiểm tra firewall có cho phép ứng dụng truy cập host và port đó không.

Error tracking tự host cần bao nhiêu disk?

Điều đó phụ thuộc vào volume event và thời gian retention, không phụ thuộc vào tool. GlitchTip công bố mức 30 GB cho một instance xử lý một triệu event mỗi tháng. Bugsink cho phép bạn đặt budget trực tiếp bằng MAX_RETENTION_EVENT_COUNT và MAX_EVENT_AGE_DAYS, nên bạn tự chọn giới hạn và yêu cầu disk sẽ phụ thuộc vào giới hạn đó. Hãy cấu hình retention ngay từ ngày đầu tiên. Tracker không có retention policy sẽ tăng dữ liệu cho đến khi df -h báo 100%; lúc đó ingest dừng và bạn mất những error mà mình cần xem nhất.

Vì sao nâng cấp Sentry tự host liên tục thất bại?

Vì quá trình nâng cấp đã bỏ qua một hard stop. Sentry self-hosted quy định các version cụ thể có chứa database migration mà bạn phải đi qua; tính đến August 2026, các version đó là 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 và 26.7.0. Chuyển thẳng từ release cũ sang release mới nhất sẽ bỏ qua các migration này, khiến schema không khớp với code và quá trình nâng cấp dừng giữa chừng. Hãy checkout từng hard stop theo đúng thứ tự và chạy ./install.sh tại mỗi version, tạo snapshot cho server trước khi bắt đầu, đồng thời đọc danh sách release cần tránh trong tài liệu; danh sách này gồm 23.7.0, 25.9.0 và 25.12.0.