錯誤追蹤這件事的官方選項一直只有 Sentry。SDK 幾乎每個語言都有、UI 打磨得漂亮、breadcrumbs 跟 source map 都做完了，但代價是 SaaS 版按 event 計費會在流量爆量時直接把帳單推到四位數美金，而想自架就得吞下一份 40 個容器起跳的 Kubernetes 級部署。這個落差讓 GlitchTip、Bugsink、Highlight.io 這類「Sentry SDK 相容、但架構重寫」的專案在 2025 到 2026 年之間一個接一個冒出來。其中 Bugsink 走得最徹底——一支 Docker 容器、預設 SQLite、無 Redis、無 Celery，直接接下 Sentry SDK wire protocol。
Bugsink 的定位在最近幾個月開始被自架社群認真討論，跟它 2026 年初把授權改成 Polyform Shield、把自架這條路完全免費開放有關。這篇文章拆解它的架構決策、跟 Sentry 官方自架及 GlitchTip 的實際差異，以及在自架 VPS 場景下該不該選它。
Sentry 自架這條路的實際體感
Sentry 的原始碼是可取用的（Functional Source License，source-available，不是 OSI 定義的開源），docker-compose 也是官方維護的，理論上「拉下來跑起來」就好。實務上的落差在打開 docker-compose.yml 那一刻——PostgreSQL、Redis、Kafka、Zookeeper、ClickHouse、Snuba、Symbolicator、Relay、Sentry Web、Sentry Worker、Sentry Cron、加上 nginx 前端跟一堆 sidecar，光是列出來的服務就 20 多個，實際跑起來的容器超過 40 支。RAM 底線 16 GB，磁碟預留 100 GB 起跳。
這個架構在 Sentry 內部完全合理——Kafka 撐 event ingest 的緩衝、ClickHouse 撐 event 查詢的 columnar 儲存、Snuba 是 Sentry 對 ClickHouse 寫的抽象層——但對「一臺 VPS 想接住自家幾支服務的 exception」這個場景是巨型 overkill。SIG 上有無數討論在問「能不能只跑 error tracking、拿掉 performance monitoring」，官方回覆是這個組合是硬綁的，拆不出來。實務上多數團隊評估過就退回 SaaS。
Sentry 自己在 self-hosted 頁面上寫得也直接：「這個部署形態是給進階使用者的，我們不保證支援。」翻成中文就是「別自架、來付錢」。
GlitchTip 減掉 Kafka 之後還是三隻容器
第一個接手這個空缺的是 GlitchTip。用 Django 重寫、砍掉 Kafka 跟 ClickHouse、event 直接進 PostgreSQL，架構乾淨很多。MIT 授權，Sentry SDK wire protocol 相容，能直接把應用程式裡的 dsn 換成 GlitchTip 的網址就開始收 event。
但 GlitchTip 沒有走到最底——PostgreSQL、Redis、Celery worker 三個服務還是要一起拉起來。Docker Compose 跑得動，Kubernetes 部署也能做，但對想在一臺 2 vCPU / 4 GB 的 VPS 上塞十來個小服務的自架玩家來說，「錯誤追蹤要吃三個 container」還是有點多。加上 GlitchTip 的 issue tracker 從 2025 中開始就有幾個 alert 送不出來、tag 搜尋卡頓的 bug 拖著沒修完，社群裡陸續有人在找替代品。
Bugsink 把架構砍到一支容器
Bugsink 的答案是把整個後端塞進一支 Django 容器。預設用 SQLite 當應用資料庫、拿掉 Redis、拿掉 Celery，背景任務由自己寫的 snappea 接手。啟動指令是一句 docker run，記憶體 idle 大約 700 MB，官方 benchmark 顯示 2 vCPU / 4 GB 的 VPS 可以撐到每天 150 萬個 event。
這個架構的合理性建立在一個判斷上：錯誤追蹤是「寫入密集但單筆很小、查詢頻率低」的工作負載。Kafka 那套設計是給每秒幾十萬 event 的 SaaS 用的，單一使用者的自架場景不會遇到這個量級。SQLite 的單寫入者瓶頸在這個工作負載上根本撞不到——每分鐘幾百個 exception 已經算大量，SQLite 隨手就撐得住。
要跑生產、預期 event 量比較大的場景，Bugsink 支援換成 PostgreSQL 或 MySQL，但 Redis 跟 Celery 這條路徑始終沒進來。這是有意識的架構選擇，不是還沒實作。
snappea：用 inotify + SQLite 取代 Celery
Bugsink 拿掉 Celery 的關鍵是 snappea 這個自製 task runner。設計目標很直接——不引入 broker、不引入額外進程、要跟 Django 進程一起活。
實作上 snappea 拿 SQLite 當訊息佇列。當 web request 需要非同步處理一個 event（比如寫入 issue grouping、送 alert），snappea decorator 把 task 寫進 SQLite 的 snappea_task table，然後在某個監控目錄下建立一個空檔案。這個檔案的用途只有一個——讓 Linux 的 inotify subsystem 送出一個 IN_CREATE 事件，把 Foreman 進程從 blocking 的 inotify wait 裡叫醒。Foreman 收到訊號就掃 SQLite 撿新任務、丟給 worker thread 執行。
這個設計避開了 polling 那條路線最頭痛的取捨——輪詢間隔設太短 CPU 空轉、設太長延遲高。inotify 只有真的有事件才會醒，一整天沒 event 進來，Foreman 的 CPU 使用率是 0%。同時因為 SQLite 就在同一個檔案系統上、Foreman 就在同一支 Python 進程樹裡，沒有網路 hop、沒有序列化、沒有 broker 認證。
snappea 的限制也很直白——它綁 Linux（inotify 是 Linux 專屬）、綁單機（跨機分派得靠額外的架構）。這兩個限制對自架單機 VPS 完全不痛。
Sentry SDK wire protocol 是不是真的能直接換
Bugsink 官網一直強調「Sentry SDK 相容」，實務上這句話的意思是它接受 Sentry 官方 SDK 走 HTTP 送過來的 envelope 格式。從應用程式端看，改動只有一個——把環境變數的 SENTRY_DSN 換成 Bugsink 給的 DSN。SDK 端零改動、程式碼零改動，重啟服務之後 exception 就開始進 Bugsink。
這個相容性覆蓋到 Python、JavaScript、Node.js、Java、Go、Rust、PHP、Ruby、iOS、Android 等 SDK，也就是 Sentry 官方支援的絕大多數語言。stacktrace、breadcrumb、tag、user context、release、environment 這些欄位都認得。差別在 Sentry 那些超出「錯誤追蹤」的功能——APM、tracing、profiling、session replay——Bugsink 不做，也沒打算做。
現實上這是個乾脆的取捨。想要 APM 跟 tracing 的應該去看 Grafana Tempo、SigNoz、Coroot 這條線；想要純錯誤追蹤的用 Bugsink 就對了。混在同一個工具裡是 Sentry 自己的路線，Bugsink 沒打算追。
Smart Retention 是自架場景很少被討論但真的會踩的坑
自架錯誤追蹤最容易忽略的維運痛點是資料保留。SaaS 版按 event 量收錢，超過就收更多；自架版預設無限制，撞到磁碟塞爆的那天才發現沒設 retention policy。GlitchTip 這件事得手動寫 cron 去刪、Sentry 有內建但參數要調。
Bugsink 走的路線是 smart retention——每個 project 設一個目標容量，超過的時候不是刪最舊的，而是保留每個 issue 的代表樣本（第一次出現、最近一次、還有幾個中間的），把重複的 event 丟掉。這個策略對「同一個 bug 一小時吐 10 萬次」這種爆炸情境特別有用，維運端不用手動介入、UI 上還是看得到這個 issue 有多少 volume。
實務用起來的體感是——設完初始容量之後大概就不會再管它了。這個對「架起來讓它自己跑」的自架場景是重要的。
Polyform Shield 授權跟這件事的信任問題
Bugsink 2026 年初把授權從舊的雙軌制改成 Polyform Shield License。這是 Polyform Project 定義的一系列 source-available 授權裡的一個——允許任何非競爭用途，但禁止拿去做直接的商業競爭產品。
對自架使用者的實務意義是：完全免費、無限制、不用付費、不用購買授權。不管是個人、公司、政府單位，只要不是拿 Bugsink 的原始碼去做另一個錯誤追蹤 SaaS 賣，都在允許範圍內。Sentry 目前的 Functional Source License 有類似精神但條款細節不同——Sentry 是「四年後轉 Apache 2.0」，Bugsink 沒這個承諾。
這條路線比 MIT 保守，比 Sentry 的 FSL 寬鬆。純粹自架的人不會感覺到差別；如果需要包在自家 SaaS 產品裡當「附贈的錯誤追蹤」轉賣，那就要看具體用法夠不夠邊界。
該選哪一個
放下意識形態的判斷其實清楚：
繼續用 Sentry SaaS：event 量不大（每月 10 萬以下）、預算撐得住、不想維運任何東西——SaaS 的 free tier 加低階付費夠用。時間成本永遠比機器成本貴。
自架 Sentry：team 有專職 SRE、Kubernetes cluster 現成、需要完整的 APM/tracing/replay 全套、規模大到 SaaS 帳單月付四位數美金。這條路值不值得看邊際效益。
自架 GlitchTip：熟悉 Django、PostgreSQL 已經在跑、Redis 反正也有一份、要 MIT 授權方便未來 fork。GlitchTip 現在的維護節奏跟過去比慢一點，但基本功能穩定。
自架 Bugsink：想要一支容器解決錯誤追蹤、VPS 資源不多、不想額外拉 Redis 或 PostgreSQL、event 量在每天百萬以內。這是本文要主推的組合，因為它跟臺灣自架社群的常見場景最契合——單機 VPS、預算敏感、幾個到十幾個應用要接錯誤追蹤。
Beta 之外還在演進的部分
Bugsink 目前的功能覆蓋算成熟——錯誤收集、grouping、retention、alert、tag 搜尋、release tracking 都做完了。還在推進的幾條線包括：source map 對 minified JavaScript 的支援（0.6 之後已經可用但邊界情境還有 bug）、SSO 整合（LDAP/SAML 目前在企業版路線圖上）、以及 replay 這類「不只錯誤追蹤」的功能（明確說不會做）。
實務上把它拿來當純錯誤追蹤系統穩定度已經到位。1400 多個團隊在生產跑、GitHub 上 2000 顆星、社群回報的 bug 收斂速度算快。跟 SaaS 版 Sentry 或自架 Sentry 相比缺的功能都是明確的取捨結果，不是還沒做。
對自架社群這是難得的好消息——過去自架錯誤追蹤要嘛付 Sentry SaaS、要嘛吞 Kubernetes 級部署、要嘛選功能收斂的替代品。Bugsink 把「一支容器 + SQLite + 700 MB RAM」這個組合驗證起來之後，把自架的門檻壓低到跟 Uptime Kuma、Beszel 這類輕量工具同一個等級。
要平穩跑 Bugsink 的底層條件很直白：一臺穩定的 Linux VPS（inotify 對 kernel 版本不敏感）、足夠的 IOPS（SQLite 對隨機寫入敏感）、足夠的磁碟空間放 event（100 GB 起是合理數字）、以及一份定期備份。搭配自架的其他服務——Coolify 或 Dokploy 管 PaaS、Beszel 管監控、Bugsink 管錯誤——一整套自架 stack 可以完全跑在單臺中型 VPS 上。
NCSE Network 在臺灣是方電訊機房提供採用 Intel Xeon Gold CPU 與 NVMe SSD 的 VPS 主機，單核心效能與磁碟 IOPS 對 Bugsink 這類仰賴 SQLite 寫入的自架工作負載有實際差異，搭配臺灣本地的低延遲線路適合作為錯誤追蹤、監控、CI/CD 這類自架後端服務的落腳點。前往 ncse.tw 了解規格與方案細節。
