作者： Sentry 替代方案：自架錯誤追蹤 RAM 比較
Sentry 自架版至少需 16 GB RAM，GlitchTip 可在 512 MB 執行。比較磁碟成長、容器數量與升級負擔，再選適合的方案。
儲存第一筆事件前，自架錯誤追蹤的成本
自架錯誤追蹤有一項數值會決定整體選擇：RAM 下限。Sentry 的自架文件要求 4 個 CPU 核心、16 GB RAM 加上 16 GB swap，以及 20 GB 可用磁碟空間；這些資源都必須在應用程式傳送第一筆事件前準備妥當。GlitchTip 的文件則記載 512 MB。此處列出的所有選項都能接收相同的 Sentry SDK 事件，因此這不是如何植入程式碼的決策，而是你願意付費維持運作的伺服器規模。
各專案公布的資源數據並列
以下是各專案截至 2026 年 8 月自行公布的數據。這些數據並非同一種測量值，請先閱讀各列的說明，再進行比較。
The data behind this chart
[
{
"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"
}
]Sentry 的 16 GB 是有文件記載的最低需求，同一頁也建議使用 32 GB。GlitchTip 的 0.5 GB 是建議值；該專案表示，實際可運作的最低值為 256 MB，或在審慎設定下使用 128 MB 加上 swap。Bugsink 的 4 GB 則兩者皆非，而是該廠商用於自身吞吐量基準測試的主機規格。公布數據只能作為起點，不能代表能應付你的事件量。
Sentry self-hosted：完整產品，也包含完整帳單
官方堆疊是 getsentry/self-hosted，這是一個 Docker Compose 專案，會執行 Sentry 在正式環境中使用的相同元件。其文件將此專案描述為「功能完整，並封裝成適合低流量部署與概念驗證的套件」。這句話就是最準確的總結。你會取得所有功能，也會取得讓這些功能運作所需的所有元件。
請從標記版本安裝，不要從 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接著啟動：
docker compose up --waitSentry 預設監聽 http://127.0.0.1:9000。需要 Docker Engine 19.03.6 或更新版本，以及 Docker Compose 2.32.2 或更新版本。較舊的 Compose 會因檔案語法而失敗，與 Sentry 本身無關。
查看實際啟動的內容：
docker compose ps
free -hdocker compose ps 會列出堆疊中的所有服務，而且清單很長：Postgres、ClickHouse、Kafka、Redis、Relay、Snuba、Symbolicator，以及數個 worker 和 cron 程序。請先計算一次數量，因為這就是你的維護負載。每個項目都是可能當機、填滿磁碟或遷移失敗的程序。
如果某個服務停留在 Restarting 狀態，請先檢查記憶體：
dmesg -T | grep -i 'out of memory'像 Out of memory: Killed process 3412 (java) 這樣的行表示核心的 OOM killer（out of memory killer）終止了容器，原因是主機的 RAM 已耗盡。因此該服務不會變成 healthy 狀態，整個堆疊也無法完成啟動。在低於文件所述最低需求的環境中執行完整堆疊，通常就會出現這種結果。文件也特別指出磁碟速度：iowait 超過 10% 表示主機無法跟上資料擷取管線。你可以從 top 的 wa 欄讀取，或在安裝 sysstat 後從 iostat -x 5 讀取。
升級是最容易被低估的部分
Sentry self-hosted 依 CalVer（以行事曆為基礎的版本配置）每月發布，主要版本會在每月 15 日發布。你不能直接從舊版本跳到最新版本。專案定義了數個強制停留版本，必須依序切換到每個版本，以套用其資料庫遷移。截至 2026 年 8 月，已發布的強制停留版本為 9.1.2、21.5.0、21.6.3、23.6.2、23.11.0、24.8.0、25.5.1、26.5.0 和 26.7.0。文件也列出因遷移問題而應跳過的版本，包括 23.7.0、25.9.0、25.12.0，以及 26.3.0 到 26.4.0 的版本範圍。
升級的流程是切換版本後重新執行安裝程式：
git fetch
git checkout 26.7.0
./install.sh
docker compose up --wait開始前請先建立伺服器快照，因為大型 ClickHouse 資料集的遷移可能執行數小時；若中途失敗，資料庫會停留在兩種 schema 之間。多數 self-hosted Sentry 升級失敗的直接原因是：主機整整一年都停留在同一版本，因此一次跨越多個強制停留版本，而其中一個被跳過的遷移正是必要的遷移。
在決定採用前，還有一點需要了解。Sentry self-hosted 採用 Functional Source License（FSL），此授權由 Sentry 自行推出。它屬於 fair source，而非經 OSI 核准的 open source：你可以自行執行，但不得將其作為競爭服務銷售。每個版本在發布 2 年後會轉換為 Apache 2.0。
GlitchTip：512 MB 的解法
GlitchTip 採用 MIT 授權，能接收 Sentry 開放原始碼 SDK 傳送的事件。因此，已完成監控埋點的應用程式只需修改一個值即可遷移：DSN（data source name，SDK 傳送事件所用的 URL）。它需要 PostgreSQL 14 或更新版本。Valkey 或 Redis 7 或更新版本為選用元件，能讓較大型的執行個體提升速度。
安裝方式是 Docker 加上一個 compose 檔案：
sudo apt install docker.io
curl -O https://glitchtip.com/assets/compose.sample.yml
mv compose.sample.yml compose.yml啟動任何服務前，先編輯環境變數區段。必須設定的值包括 secret、網域和郵件路徑：
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範例已將 DATABASE_URL 連接至自有的 postgres 服務。除非你要連接其他地方執行的資料庫，否則請保留該行。GLITCHTIP_DOMAIN 必須包含 scheme。開頭若沒有 https://，警示郵件中的連結就會產生錯誤，並指向沒有回應的 URL。
啟動服務，並監控第一次啟動過程：
docker compose up -d
docker compose logs -f web截至 August 2026，範例中的 image tag 分別是 postgres:18、valkey/valkey:9 和 glitchtip/glitchtip:6。請固定這些版本。若 compose 檔案使用 latest，下一次 docker compose pull 時就會升級資料庫引擎。在執行中的執行個體上直接跳升 Postgres major version，可能導致原本正常運作的錯誤追蹤器無法啟動。
若要控制在 256 MB 到 512 MB 的記憶體範圍內，範例檔案中的註解會說明可停用哪些功能。建議先停用 Valkey，以及選用的 log 和 uptime 功能。不使用 Valkey 時，GlitchTip 會改用資料庫處理快取與佇列工作。速度較慢，但功能仍正確。All in one 模式會將 worker 置於 web process 中，因此只需維護一個應用程式容器，而不是兩個。
在前方設定 proxy。GlitchTip 文件要求使用能緩衝請求並處理分段 Transfer-Encoding 的 proxy 或 load balancer，並以 nginx 作為操作範例。未啟用緩衝時，速度緩慢的用戶端會在整個上傳期間占用一個應用程式 worker。因此，少數速度緩慢的傳送端就可能占滿所有 worker，導致正常用戶端開始逾時。
升級是最簡單的部分：
docker compose pull
docker compose stop
docker compose up -d資料庫 migration 會在啟動時自動執行。不過仍應先建立 dump，因為自動 migration 仍然是 migration。
Bugsink：單一容器，以及必須閱讀的授權條款
Bugsink 是三者中最輕量的方案。它支援 Sentry SDK 通訊協定，不需要訊息佇列，也不需要資料庫以外的外部服務。預設使用 SQLite；若規模超出 SQLite 的適用範圍，也支援 MySQL 和 PostgreSQL。
若要先查看介面再決定是否正式採用，可先建立一次性執行個體：
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開啟 http://localhost:8000/，使用你在 CREATE_SUPERUSER 中傳入的電子郵件地址和密碼登入。此容器停止後不會保留任何資料。正式部署時，請採用專案提供的 compose 範例，該範例會將 bugsink/bugsink:2 與 postgres:17-alpine 配對，並設定 DATABASE_URL、BASE_URL 和 BEHIND_HTTPS_PROXY。請正確產生 secret：
openssl rand -base64 50BASE_URL 必須符合使用者和 SDK 實際使用的 URL，包括 scheme。若主機可透過 https://errors.example.com 存取，卻將其保留為 http://localhost:8000，通知電子郵件中的每個連結都會指向收件者無法解析的主機。若由前方的 nginx 或 Caddy 終止 TLS（transport layer security），請將 BEHIND_HTTPS_PROXY 設為 true；否則 Bugsink 會在 https:// proxy 後方建立 http:// URL，瀏覽器會封鎖混合內容。
廠商公布的吞吐量資料為：每秒 18 個事件，每個事件 50 KB；在 2 vCPU 和 4 GB VPS 上，換算後每天可處理 1.5 million 個事件。請將這項數據視為工具的能力範圍，而不是你工作負載的保證。這仍表示其上限遠高於單一小型應用程式產生的事件量。
接著是授權條款。這部分應在將它部署到你的技術堆疊前閱讀。Bugsink 採用 PolyForm Shield License 1.0.0 發布。這是可取得原始碼的軟體，不是開放原始碼軟體：你可以執行和修改它，但不得用它建立與 Bugsink 競爭的產品。對內部錯誤追蹤工具而言，這項限制通常不會造成問題。如果你的公司銷售開發者工具，請先請人閱讀授權條款全文。
錯誤追蹤與 LLM 可觀測性仍是兩種工具
搜尋能同時處理錯誤追蹤與大型語言模型（LLM）可觀測性的工具時，會找到宣稱兩者皆支援的產品。但兩者處理的資料結構不同，因此一直難以真正整合。錯誤追蹤工具會接收含有 stack trace 的例外，依此計算指紋，將數千次發生的事件彙整為一個問題並計算次數。LLM tracing 工具則會接收包含 prompt、response、token 數量與 latency 的 span，且必須保留每一筆資料，因為即使兩次呼叫的輸入完全相同，仍是值得檢視的獨立事件。
因此，請同時使用兩者。將例外傳送至錯誤追蹤工具，並將模型呼叫傳送至專為此類資料設計的工具：自架 Langfuse 進行 agent tracing 可處理這一側，自架 AI 可觀測性 則從不同角度處理相同工作。你的應用程式本來就會產生這兩類故障。模型呼叫即使回傳語氣肯定但內容錯誤的結果，也完全不會擲出例外，因此錯誤追蹤工具永遠不會顯示這類問題。
磁碟成長是之後才找上門的故障
每個錯誤追蹤器本質上都是寫入量很高、輸入沒有上限的資料庫。應用程式會決定寫入量，而熱點程式路徑中的一個新錯誤，就可能在一夜之間產生一百萬個事件。
GlitchTip 提供了一個值得據以規劃的數字：每月處理一百萬個事件的執行個體，可能需要 30 GB 磁碟空間。這只涵蓋該處理量下 1 個月的資料寫入量；實際同時儲存幾個月的資料，則取決於保留期間。
Bugsink 則從另一個方向處理這個問題。它不使用固定配額，而是依事件數量與事件存留時間套用保留演算法，並直接公開各項上限：整個安裝的 MAX_RETENTION_EVENT_COUNT、每個專案的 MAX_RETENTION_PER_PROJECT_EVENT_COUNT，以及 MAX_EVENT_AGE_DAYS 所表示的絕對上限。設定整個安裝的事件預算，才是誠實的磁碟容量規劃方式，因為這個預算就是磁碟需求。
請監控伺服器上的實際數值：
df -h /
docker system df -v
du -sh /var/lib/docker/volumes/*docker system df -v 會列印各個 volume 的大小，讓你看出是哪個服務持續成長。若某個 volume 每週增加數 GB，而網路流量沒有變化，通常表示尚未設定資料保留政策，因此資料從未刪除，唯一的限制就是分割區容量。
記憶體問題只是換了另一種形式。未設定限制的堆疊會耗盡 kernel 提供的所有資源；機器記憶體用盡時，OOM killer 會選擇最大的程序，而被終止的可能是 web server，不一定是造成問題的 tracker。請為每個服務設定上限：Docker Compose 的記憶體限制 說明設定語法，以及 container 達到上限時的行為。Container 因自身限制而被終止，屬於局部故障。Container 若由 kernel 終止，則可能連帶使鄰近服務停止。
哪種技術堆疊適合哪種 VPS
- 1 GB，或有餘裕的 2 GB： GlitchTip 的 all in one 模式（停用 Valkey），或使用 SQLite 的 Bugsink。這兩者都足以應付少量應用程式。
- 4 GB： 搭配 PostgreSQL 的 Bugsink，或啟用 Valkey 並使用獨立 worker service 的 GlitchTip。這是可以停止微調、直接執行的規格。
- 8 GB： 仍不足以執行官方 Sentry stack。無論選擇哪個輕量方案，都應將資源用於延長保留期間及擴充磁碟容量。
- 至少 16 GB，建議 32 GB： 官方 Sentry self-hosted stack。只有在需要輕量專案未實作的 Sentry 功能時，才應選擇此方案。請先對照各專案的文件確認特定功能，因為相容的專案已涵蓋常見功能。
無論執行哪個方案，錯誤追蹤器都無法回報自身停止運作。請從另一台機器進行監控：由另一台主機監控的 Uptime Kuma 會告知你追蹤器已停止運作；這正是應用程式開始產生錯誤、卻無人記錄的時刻。
託管方案更划算的情況
當資料駐留規範要求自行託管，或事件量高到按事件計價造成負擔時，自行託管錯誤追蹤系統才值得。除此之外，請如實計算成本。Sentry 文件列出的最低需求是 16 GB 記憶體、4 個核心與快速磁碟，而符合這種規格的 VPS 並不便宜。接著還要加上維運工作：依序排除每個硬性阻礙，並在每次遷移前建立 snapshot；一年可能要進行幾次。
GlitchTip 和 Bugsink 會完全改變這項成本計算，因為 512 MB 到 4 GB 的主機價格低廉，而升級只是 docker compose pull。因此，多數提出這個問題的人最後會選擇其中一個相容專案，而不是官方堆疊。他們需要的是錯誤追蹤，不是一條必須持續維護的分散式資料管線。
如果你仍在整理哪些服務值得放在伺服器上，值得自行託管的完整服務清單會將錯誤追蹤與其他爭用相同 RAM 的服務放在一起比較。
FAQ
我可以在 2 GB VPS 上自行代管 Sentry 嗎？
不行。Sentry 的自架文件指出，最低需求為 4 個 CPU 核心、16 GB RAM 加上 16 GB swap，以及 20 GB 可用磁碟空間。這個堆疊會同時執行 Postgres、ClickHouse、Kafka、Redis 和數個 worker process，因此在小型主機上，kernel 會在安裝完成前終止容器。使用 dmesg -T | grep -i 'out of memory' 即可確認，該指令會輸出包含被終止 process 名稱的行。若使用 2 GB VPS，請改用 GlitchTip；其文件記載需求為 512 MB。也可以使用 Bugsink，它會以單一容器搭配 SQLite 執行。
從 Sentry 切換至 GlitchTip 或 Bugsink 時，必須修改應用程式程式碼嗎？
不必。兩者都接受 Sentry 開放原始碼 SDK 傳送的事件，因此可以保留已安裝的 SDK，只需修改一個值：DSN，也就是 SDK 張貼事件的 URL。如果 DSN 仍硬編碼在程式碼中，請將它移至環境變數，指向新的主機，然後觸發測試例外並監看事件是否抵達。若沒有顯示事件，請確認 DSN 中的 project identifier 對應到新伺服器上已存在的 project，並確認防火牆允許應用程式連線至該主機和 port。
自架錯誤追蹤需要多少磁碟空間？
這取決於事件量和保留期間，而不是工具本身。GlitchTip 公布的數值為：處理每月 1 million 個事件的 instance 需要 30 GB。Bugsink 可透過 MAX_RETENTION_EVENT_COUNT 和 MAX_EVENT_AGE_DAYS 直接設定容量上限，因此可以自行選擇上限，磁碟需求也會隨之決定。請在第一天就設定保留政策。沒有保留政策的追蹤器會持續成長，直到 df -h 顯示 100%；此時事件接收會停止，並遺失最需要查看的錯誤。
為什麼升級自架 Sentry 一直失敗？
因為升級略過了必要的中止版本。Sentry self-hosted 定義了數個包含資料庫 migration 的特定版本，必須依序經過這些版本。截至 August 2026，這些版本為 9.1.2、21.5.0、21.6.3、23.6.2、23.11.0、24.8.0、25.5.1、26.5.0 和 26.7.0。直接從舊版升級到最新版會略過這些 migration，導致 schema 與程式碼不一致，升級因此在中途停止。請依序 checkout 每個必要的中止版本，並在每個版本執行 ./install.sh。開始前先建立伺服器 snapshot，並閱讀文件列出的應避免版本，其中包括 23.7.0、25.9.0 和 25.12.0。