SigNoz 把 Trace、Log、Metric 三種訊號塞進同一個 ClickHouse，靠 OpenTelemetry 原生協定接收資料，整套自架方案在 4 GB RAM 的 VPS 上就能跑起來。對於還在用 Prometheus + Loki + Tempo 三個 backend 拼出可觀測性，又付不起 Datadog 帳單的團隊來說，SigNoz 提供了一條操作成本明顯更低的路線。
可觀測性（observability）這幾年從「裝個 Prometheus 看 CPU」變成「Trace、Log、Metric 三種訊號要能互相跳轉」的複雜需求，工具鏈跟著爆炸。SigNoz 不是要做最強的單項，而是用單一資料庫把這三件事整合在同一個查詢介面下。
可觀測性會走到今天這麼複雜的原因
早期監控的世界很簡單：Nagios、Zabbix 之類的工具負責定期 ping 服務、看 CPU 高不高，出事就寄信。後來微服務跟容器化讓服務數量爆炸，光看單機指標不夠用，需要看「請求從 service A 走到 B 再到 C 中間哪一段慢」，distributed tracing 才成為必需品。再加上應用日誌也要集中收集才能查問題，三種訊號各自有不同的開源解法：
- Metric：Prometheus 主導，pull-based 模型，靠 PromQL 查詢
- Log：早期是 ELK（Elasticsearch + Logstash + Kibana），後來出現 Loki 走 label-based 索引
- Trace：Jaeger、Zipkin，後期被 Tempo 跟 OpenTelemetry 收編
Grafana 一家把 Loki、Tempo、Mimir、Pyroscope 全部做出來，包裝成 LGTM Stack（Loki + Grafana + Tempo + Mimir）。問題是這套東西要自己跑起來，至少要管四個 backend、四套儲存、四種查詢語言（PromQL、LogQL、TraceQL、自家 Profile 查詢）。對只有兩三個工程師的小團隊，光是運維這些 backend 就吃掉一個全職人力。
商業方案像 Datadog、New Relic 把這些整合得很好，但價格曲線非常陡——一個中型服務每月帳單破萬美元並不少見，而且資料一旦進去就很難搬走。
SigNoz 想解的就是這個夾在中間的空白。
一個 ClickHouse 就吃下三種訊號
SigNoz 的核心架構決策是把 Trace、Log、Metric 全部寫到同一個 ClickHouse 叢集。為什麼這件事重要？
ClickHouse 是 columnar OLAP 資料庫，設計來處理 PB 級別的分析查詢。它的壓縮率極高（trace span 這種重複欄位多的資料常見壓到 10:1），掃描速度也快。更關鍵的是，三種訊號共享同一個 schema 後，從 Metric 異常跳到對應時間區間的 Trace、再從 Trace 跳到該請求的 Log，整個過程在同一個查詢引擎下完成，不需要切換工具或對齊 label。
實際架構長這樣：
1 | 應用程式 (OTel SDK) |
四個服務外加一個 ZooKeeper（給 ClickHouse 做分散式協調），整套部署完是五個容器。對比之下，一個跑得起來的 LGTM Stack 至少要 Loki、Tempo、Mimir、Grafana、Prometheus、Promtail 六個元件，每個還可能拆成 write/read/backend 三種角色。
OpenTelemetry-native 這件事也值得一提。SigNoz 不收 Prometheus 格式、不收 Jaeger 原生協定（雖然支援，但屬於相容性模式）——主要管道就是 OTLP。這意味著應用程式只要裝一次 OpenTelemetry SDK，可以隨時換 backend，不會被 SigNoz 綁死。這點跟 Datadog 那種「裝自家 agent 才能用」的封閉模型剛好相反。
SigNoz 跟 LGTM Stack 的實際差異
把兩套東西攤開比較，差別主要在四個面向：
索引策略：Loki 為了壓縮成本，預設只索引少數低基數的 label（通常上限 15 個）。這代表 trace_id、user_id 這類高基數欄位查不到，得用 grep 全表掃。SigNoz 把所有 OpenTelemetry attribute 都當作可查詢欄位，不需要事先決定哪些要當索引。除錯時想到什麼就查什麼，這個體驗差距很明顯。
訊號關聯：在 LGTM Stack 裡，從 Tempo 的 trace 跳到 Loki 的 log，必須靠 exemplar 或 trace_id 對齊，而且要在 Grafana 的 panel 之間切換。SigNoz 在同一個 UI 內就能從 service map 的 latency spike 直接點進對應的 traces，再點 trace 內任何一個 span 看當下的 logs。
運維成本：4 GB RAM 的 VPS 跑得起 SigNoz 全套（雖然官方建議至少給 ClickHouse 8 GB 才好用）。LGTM Stack 的最小部署即使把所有元件壓到單機，記憶體基線通常也要 6–8 GB。多了一倍的元件數，等於多了一倍要更新、要監控、要排錯的維運表面。
生態廣度：這是 LGTM 勝出的地方。Grafana 的 dashboard 生態系成熟太多，社群現成的 panel 模板從 PostgreSQL、Kafka 到 Kubernetes 應有盡有。SigNoz 內建的 dashboard 數量遠不及，雖然支援匯入 Grafana 格式，但相容性不是 100%。
如果只看純技術觀點，OpenTelemetry-native 的單一資料庫架構是更乾淨的設計。但若團隊已經深度依賴 Grafana 的視覺化生態，要評估的就不只是 backend 好不好用，還包括轉移成本。
自架的硬體配置怎麼抓
SigNoz 官方文件給的數字是「最低 4 GB RAM」，但這個數字其實只夠跑示範用途。實際生產環境的需求要看每秒處理多少 span、要保留多久。
幾個實務參考點：
- 小型場景：每秒 100–500 span、保留 15 天 → 4 vCPU、8 GB RAM、100 GB NVMe SSD 通常夠用
- 中型場景：每秒 1k–5k span、保留 30 天 → 8 vCPU、16 GB RAM、500 GB SSD，ClickHouse 建議獨立部署
- 大型場景：每秒超過 5k span → ClickHouse 需要分片，OTel Collector 要起多個 replica 做負載分攤
ClickHouse 是整套架構裡最吃資源的元件，記憶體不足會導致 merge 跟不上，徵兆是 part count 飆破幾千。這時候不是加 CPU 能解決的，得加 RAM 或減少 ingestion 速率。
儲存方面，trace 跟 log 的資料量會遠大於 metric。實務上 trace 採樣率調到 1–10% 是常態，全收只在開發或除錯期間做。SigNoz 內建的採樣設定可以在 collector 層做機率採樣或 tail-based 採樣，後者會優先保留有錯誤的 trace。
Docker Compose 自架實作
SigNoz 官方提供 install script，但實務上直接用 Docker Compose 部署更可控。從 GitHub 拉下程式碼後，主要的 compose 檔案在 deploy/docker/clickhouse-setup/ 底下：
1 | git clone -b main https://github.com/SigNoz/signoz.git |
預設會開三個對外連線埠：
- 8080：Web UI 跟 Query API
- 4317：OTLP gRPC（給 SDK 推 telemetry）
- 4318：OTLP HTTP（同樣推 telemetry，給 browser 或 webhook 場景用）
實際上線前該調整的幾個地方：
ClickHouse 記憶體上限：預設沒有設 max_memory_usage，被一個大查詢吃光記憶體就會 OOM 整個服務。在 clickhouse-config.xml 加上 <max_memory_usage>4000000000</max_memory_usage>（4 GB 上限）是基本款。
資料保留策略：在 SigNoz UI 的「Settings → General」可以設定 trace、log、metric 各自的 TTL。預設 15 天對小流量沒問題，高流量場景要往下調。
反向代理：8080 不要直接對公網。實務上用 Caddy 或 Nginx 套一層 TLS 跟 basic auth，或者更安全的做法是讓 Web UI 只對內網開放，遠端存取走 WireGuard。
OTLP 端點認證：4317 跟 4318 預設沒有認證，誰連得到就誰能塞資料進來。生產環境一定要在 collector 層加 bearer token 或者把這兩個 port 鎖在內網。
驗證部署成功最快的方法是用 OpenTelemetry 官方的 sample app：
1 | docker run --rm \ |
等個一分鐘，SigNoz UI 的 Services 頁面就會出現 test-service，點進去能看到 trace 跟 metric。
把現有服務接上 OpenTelemetry
SigNoz 自架完成只是起點，真正的工程量在於應用程式端的儀器化（instrumentation）。OpenTelemetry 在主流語言都有 SDK：
- Node.js、Python、Java、.NET：支援 auto-instrumentation，幾乎不用改程式碼
- Go、Rust：需要手動加 tracer，但 SDK 設計乾淨，不會侵入業務邏輯
- PHP：8.0 以上版本有 OpenTelemetry extension，效能影響可接受
對於跑現成軟體（Nginx、PostgreSQL、Kafka）的場景，OpenTelemetry Collector 有 receiver 可以直接抓 Prometheus metric 跟 syslog，不需要改服務本身。
Kubernetes 環境的話，OpenTelemetry Operator 可以做 sidecar 自動注入，pod 啟動時就掛上 instrumentation agent。這部分配置比 Datadog 的 daemonset 模型複雜一些，但好處是換 backend 不用重新部署。
什麼情況下不該選 SigNoz
SigNoz 不是萬用解，幾個明顯不適合的場景：
團隊已經重度投資 Grafana：累積了幾十個 dashboard、團隊熟練 PromQL 跟 LogQL，從 LGTM 遷移到 SigNoz 的學習曲線跟 dashboard 重寫成本可能不划算。這種情況反而適合保留 Grafana 當前端，後面接 SigNoz 當 unified backend——SigNoz 有 Grafana datasource plugin 可以這樣用。
需要 long-term metric retention：ClickHouse 跑年單位的 metric 保留會吃很多儲存，沒有 Mimir 那種專門的長期儲存層划算。如果是合規或審計需求要保留兩年以上的指標，混合架構（SigNoz 處理近期、Cortex/Mimir 處理長期）會比較合理。
單機規模太小：如果只是想看一台 VPS 的 CPU、RAM、disk，SigNoz 整套架構是大砲打蚊子。Beszel、Netdata 這類輕量工具更合適。SigNoz 的甜蜜點是「有 5 個以上的微服務、想看完整呼叫鏈」。
完全純 metric 場景：如果根本沒有 trace 需求，純 Prometheus + Grafana 還是更直接的方案。SigNoz 的設計優勢來自三種訊號的整合，只用一種等於浪費掉它的核心價值。
何時值得把可觀測性從 SaaS 搬回自家
Datadog、New Relic 這類 SaaS 方案的價值在於零維運、立即上線。但隨著服務規模成長，月費爆炸式上漲是常態——尤其是 log ingestion 跟 high-cardinality metric 這兩塊。SigNoz 自架的成本曲線完全不同：硬體跟頻寬是固定支出，跟業務量沒有線性關係。
對於資料敏感度高的場景（金融、醫療、政府單位），把 trace 跟 log 留在自家機房而不是送到境外 SaaS，本來就是合規硬性需求。SigNoz 的開源授權（Apache 2.0）加上 OpenTelemetry 標準協定，意味著任何時候想換 backend 都還是可以——不會像當年用 Datadog Agent 那樣被卡死。
可觀測性走到 2026 年，OpenTelemetry 已經是事實上的標準，後端的競爭重新回到「誰的查詢體驗最好、運維最簡單」這個原始問題上。SigNoz 在小到中型團隊這個區間提供了一條清楚的路線。
要在臺灣本地部署 SigNoz 跑生產級可觀測性，硬體規格跟網路延遲都是關鍵。NCSE Network 提供搭載 Intel Xeon Gold CPU、NVMe SSD 的 VPS 主機，是方電訊機房直連臺灣骨幹，適合 ClickHouse 這類對 IO 跟記憶體敏感的服務。前往 ncse.tw 了解規格與方案細節。
