# 【Sentry】 自架主機分析

當你要自建 Sentry 並希望個別安裝各個服務（非 all-in-one Docker 方式），需要了解 Sentry 背後實際上是一個 **分散式系統**，包含多個子服務。以下是簡要說明每個服務的用途，並提供 **最小部署需求建議（幾台機器）**。

---

## 🧩 Sentry 核心元件說明

<table id="bkmrk-%E6%9C%8D%E5%8B%99-%E7%94%A8%E9%80%94-%E6%98%AF%E5%90%A6%E5%BF%85%E8%A6%81-%E8%AA%AA%E6%98%8E-sentry"><thead><tr><th>服務</th><th>用途</th><th>是否必要</th><th>說明</th></tr></thead><tbody><tr><td>**Sentry Web**</td><td>Web UI + API</td><td>✅ 必要</td><td>使用者操作介面與事件接收入口。</td></tr><tr><td>**Worker**</td><td>背景任務處理</td><td>✅ 必要</td><td>發送通知、儲存事件、標記等。Celery 背後用 Redis 當 broker。</td></tr><tr><td>**Cron**</td><td>定期任務排程</td><td>✅ 必要</td><td>例如清除舊資料、定期檢查等。</td></tr><tr><td>**Relay**</td><td>邊界接收器</td><td>✅ 建議</td><td>前端 SDK 最先接觸的入口，可作為 proxy、限流、預處理。</td></tr><tr><td>**PostgreSQL**</td><td>資料庫</td><td>✅ 必要</td><td>儲存大部分結構化資料（專案、使用者、事件等）。</td></tr><tr><td>**Redis**</td><td>訊息佇列、快取</td><td>✅ 必要</td><td>Celery 任務排程、快取使用。</td></tr><tr><td>**Kafka**</td><td>事件串流</td><td>✅ 必要（新版）</td><td>訊息串流 backbone，傳輸異常事件。</td></tr><tr><td>**Zookeeper**</td><td>Kafka 依賴</td><td>✅ Kafka 必要</td><td>Kafka metadata 管理工具。</td></tr><tr><td>**ClickHouse**</td><td>高速查詢</td><td>✅ 建議</td><td>儲存事件 metadata，提供 Discover/Performance UI。</td></tr><tr><td>**Symbolicator**</td><td>原始碼還原符號</td><td>🟡 可選</td><td>用於原生 crash report（iOS/Android 原始符號對應）。</td></tr><tr><td>**Snuba**</td><td>查詢引擎</td><td>✅ 必要</td><td>Sentry 的查詢服務，轉發查詢給 ClickHouse。</td></tr><tr><td>**nginx**</td><td>Proxy</td><td>✅ 建議</td><td>當作入口，轉發請求給 Sentry、Relay 等。</td></tr></tbody></table>

---

## 📦 最小分布式部署建議（分機版本）

<table id="bkmrk-%E7%AF%80%E9%BB%9E-%E5%AE%89%E8%A3%9D%E9%A0%85%E7%9B%AE-%E8%AA%AA%E6%98%8E-node-1%EF%BC%9Aap"><thead><tr><th>節點</th><th>安裝項目</th><th>說明</th></tr></thead><tbody><tr><td>**Node 1：App Server**</td><td>`sentry-web` + `cron` + `worker`</td><td>最好有 2 核以上，主要承擔使用者 UI 與邏輯</td></tr><tr><td>**Node 2：資料庫**</td><td>PostgreSQL + Redis</td><td>可整合在同台，需穩定，重要資料所在</td></tr><tr><td>**Node 3：訊息處理**</td><td>Kafka + Zookeeper</td><td>Kafka 可與其他服務共用機器（但建議獨立）</td></tr><tr><td>**Node 4：查詢引擎**</td><td>Snuba + ClickHouse</td><td>查詢速度核心，可以跟 Kafka 共用</td></tr><tr><td>**Node 5：Symbolicator + Relay**</td><td>可再分出獨立機器</td><td>可選，針對原生應用及 SDK proxy</td></tr></tbody></table>

🧠 **最小建議：**  
最少可以從 **3 台機器** 起步：

- **機器 A（App）**：sentry-web、cron、worker、relay
- **機器 B（Storage）**：PostgreSQL、Redis、Symbolicator
- **機器 C（Streaming）**：Kafka、Zookeeper、ClickHouse、Snuba

這樣就可以支撐基本功能。當負載上來之後，再做橫向擴展。

---

## ✅ 補充：資源建議（單位：最小）

<table id="bkmrk-%E6%9C%8D%E5%8B%99-cpu-memory-%E7%A3%81%E7%A2%9F-pos"><thead><tr><th>服務</th><th>CPU</th><th>Memory</th><th>磁碟</th></tr></thead><tbody><tr><td>PostgreSQL</td><td>2C</td><td>4GB+</td><td>SSD 儲存，100GB 起跳</td></tr><tr><td>ClickHouse</td><td>2C</td><td>4GB+</td><td>SSD 快速查詢，空間依事件量調整</td></tr><tr><td>Kafka</td><td>2C</td><td>4GB</td><td>10GB 起</td></tr><tr><td>Snuba</td><td>1C</td><td>2GB</td><td>低</td></tr><tr><td>Redis</td><td>1C</td><td>1GB</td><td>幾乎沒磁碟需求</td></tr><tr><td>Web / Worker</td><td>2C</td><td>2~4GB</td><td>看使用者數</td></tr></tbody></table>

---

## 🧭 小結

<table id="bkmrk-%E6%83%B3%E6%B3%95-%E5%BB%BA%E8%AD%B0-%E5%8F%AA%E6%98%AF%E8%A6%81%E3%80%8C%E5%BF%AB%E9%80%9F%E7%8E%A9%E7%8E%A9%E7%9C%8B%E3%80%8D-%E2%9C%85-d"><thead><tr><th>想法</th><th>建議</th></tr></thead><tbody><tr><td>只是要「快速玩玩看」</td><td>✅ Docker self-hosted（1 台）</td></tr><tr><td>內網 demo、準生產環境</td><td>✅ 拆 3 台機器，參考上表</td></tr><tr><td>正式環境、日誌量大</td><td>✅ 至少 5 台，分出 ClickHouse 與 Kafka</td></tr><tr><td>已有 K8s 架構</td><td>✅ 用 Helm Chart 部署</td></tr></tbody></table>

---