LGTM stack 四支服務綁在一起、SigNoz 拖著 ClickHouse：OpenObserve 用一支 Rust binary 把 log、metric、trace 全塞進 Parquet on S3

自架 observability 走到 2026 年還在為服務數量頭痛。Grafana 生態的 LGTM 組合——Loki、Grafana、Tempo、Mimir——湊完至少四支服務，加上 Prometheus、Alertmanager、各種 exporter，光是 Helm chart 拉起來就是十幾個 pod。SigNoz 把架構壓成三支主要服務，代價是綁死 ClickHouse。OpenObserve 走了第三條路：一支 Rust 編譯出來的 binary，資料寫成 Parquet 檔案，後端直接指到 S3-compatible 物件儲存。

這個專案 2022 年底開源，2026 年 7 月更新到 v0.91.5，GitHub 累積 20.5k star。它處理的訊號類型包山包海——logs、metrics、traces、real user monitoring、pipelines、LLM observability——全部在同一個 process 裡跑，前端 UI 也自己帶進來。

儲存成本差 140 倍的關鍵在 Parquet

多數 log 系統把資料塞進 inverted index，Elasticsearch 是典型：一條 log 進來，原文存一份、每個 token 拆進倒排索引又一份，總量常常是原始資料的 3 到 5 倍。Loki 走另一個極端，只索引 label、原始 log body 用 gzip 或 snappy 壓，查詢時全靠 chunk scan，遇到 label cardinality 爆炸就很難救。

OpenObserve 選的是 Apache Parquet。這格式從 Hadoop 生態走出來，被 Snowflake、DuckDB、DataFusion 大量採用。columnar 排列讓相同型別的欄位可以做字典編碼、run-length encoding、bit packing 三層壓縮，log 這種重複性極高的資料實測可以壓到原始體積的 2% 到 3%。官方跟 Elasticsearch 對比宣稱 140 倍儲存差距，實際部署到雲端 S3 上，同樣 30 天保留、每天 100 GB 進來的環境，儲存費從兩千美金一路砍到十幾美金。

查詢引擎接的是 Apache DataFusion，同一個 Rust 生態出來的向量化 SQL engine。這選擇避開了自造輪子——DataFusion 已經內建向量化執行、predicate pushdown、partition pruning，OpenObserve 只要決定怎麼切 partition、怎麼建 secondary index，剩下的計算路徑交給引擎處理。

一支 binary 到底裝了什麼

openobserve 這支 binary 出廠時大約 130 MB，內容包括：資料 ingestion API（OTLP over HTTP/gRPC、Prometheus remote write、Fluentd forward、原生 JSON API）、儲存層、查詢引擎、告警排程、前端 React UI，以及 SSO、RBAC、multi-tenant organization 管理。

啟動只需要幾行環境變數：

export ZO_ROOT_USER_EMAIL="[email protected]"
export ZO_ROOT_USER_PASSWORD="Complexpass#123"
export ZO_DATA_DIR="/data/openobserve"
./openobserve

預設走 local disk 儲存，適合單機驗證。切換成 S3 只要再加上：

export ZO_S3_ACCESS_KEY="..."
export ZO_S3_SECRET_KEY="..."
export ZO_S3_BUCKET_NAME="observe-data"
export ZO_S3_REGION_NAME="ap-northeast-1"
export ZO_S3_SERVER_URL="https://s3.example.com"

這裡的關鍵字是 stateless——資料寫進 S3 之後 binary 本身完全無狀態，掛掉重開、水平擴充都不需要處理 replication。Distributed mode 把架構拆成 ingester、querier、compactor、router、alert manager 五個 role，同一支 binary 用不同的 -role 參數啟動就切換角色，不需要另外編譯或部署不同的 image。

SigNoz 走 ClickHouse、OpenObserve 走 DataFusion 的取捨

SigNoz 這幾年是自架 APM 的預設答案，但它從第一天就綁 ClickHouse 這個 OLAP 資料庫。優勢是 ClickHouse 的成熟度——sharding、replication、materialized view 都有現成方案——代價是多維運一個 stateful 資料庫，磁碟規劃、備份、升級都得額外處理，容量規劃錯了 rebalance 也不是輕鬆的事。

OpenObserve 把 metadata 存 PostgreSQL 或 MySQL、實際訊號資料寫 S3，兩層都是通用元件。要 HA 的時候，metadata DB 用託管服務或已經在跑的 Postgres 都行，S3 這層雲端本來就三備份。多數企業裡這兩樣早就存在，不用為了 observability 專案再引入新的 stateful component。

query 語言則是另一個顯著差距。Grafana 生態學了 LogQL、PromQL、TraceQL 三套 DSL，遇到跨訊號類型的分析還得手動關聯。OpenObserve 全部用 SQL：log 是 SQL、metric 是 SQL、trace 也是 SQL，join 起來就是普通的 SQL join。從資料工程背景進來的工程師零學習曲線，但對已經很熟 PromQL 的 SRE 反而要重新適應——這點在導入評估時要誠實列進來。

v0.91 加進來的多租戶跟 LLM observability

v0.91 系列在 2026 年 6 月推出，把架構往企業場景推。Super Organization 這個概念讓服務商可以在同一個 cluster 底下開多個獨立 org，每個 org 有自己的 ingestion token、儲存配額、user 名單；適合 MSP 或內部平台團隊拿來當多租戶基礎設施。這是過去自架 observability 一直缺的一塊：VictoriaMetrics 的 multi-tenancy 只做到 tenant ID 隔離，權限跟計費得自己另外接。

LLM observability 這塊則是這一版另一個焦點。跟 Langfuse 定位不太一樣：Langfuse 專注在 prompt、trace、evaluation 的迭代循環，OpenObserve 則把 LLM 呼叫當成一種特殊的 span 塞進通用 tracing 系統，可以跟後端服務的 trace 直接關聯。做 RAG pipeline 或 agent 系統時，可以在同一張圖上看到「這個 request 打了 3 次 GPT、觸發 5 次向量搜尋、其中一次向量檢索花了 2 秒」，不用切換工具。想深度優化 prompt 還是選 Langfuse，但要在營運層面看整條 pipeline，OpenObserve 這種統一 tracing 就夠了。

v0.91.5 版本另外多了一件小事：官方前端把繁體中文放進正式支援語系，對臺灣團隊來說少了自己拉翻譯或忍受簡體的麻煩。

什麼時候該選、什麼時候別碰

適合 OpenObserve 的場景很明確：從零開始建 observability、資料量在 TB 到 PB 之間、團隊人手不足以維運 ClickHouse 或 LGTM 全套、成本敏感。特別是自架 VPS 的中小型服務，跑一台 4 core 8 GB 的機器加一個 S3 bucket 就能撐日均 100 GB log 進來，這在傳統 ELK 架構要三台機器起跳。

已經有龐大 Grafana dashboard 資產的組織要三思。OpenObserve 有 Grafana datasource plugin，但仍然是外掛層級——複雜的 PromQL 面板轉 SQL 需要人工重寫。同樣的，Prometheus alerting rule 沒辦法直接搬過來，OpenObserve 用自己的 rule 格式，遷移成本要事先算進來。若組織內部有半年以上累積的 dashboard 跟 alert，實務上多半是新環境用 OpenObserve、舊環境慢慢淘汰，而不是一次性搬遷。

生態成熟度也還在追趕。Grafana 從 2014 年至今有兩萬多個社群 dashboard、幾百個 datasource plugin，OpenObserve 的內建 dashboard template 目前不到一百個，很多還是要自己拉。若「有現成 dashboard 可以用」這件事很重要，SigNoz 或 Grafana 仍然是穩妥選擇。

訊號統一化這條路正在收斂

觀察 2026 年 observability 工具的分化，會發現一個清楚的方向：把 stateful 資料庫外包給 S3，用 columnar 格式壓儲存成本，然後把所有訊號類型統一到同一個查詢層。OpenObserve、GreptimeDB、VictoriaLogs 都在這條路上，只是選了不同的 trade-off——OpenObserve 押注 DataFusion 生態、GreptimeDB 自造 query engine、VictoriaLogs 走純 log 專精路線。

對自架 VPS、需要控制成本的團隊，一支 Rust binary 加 S3 這個組合已經足夠取代過去要拉四支服務才能達成的觀測能力。而且相較於雲端託管方案動輒每 GB 幾美金的 log ingestion 費用，這種架構的邊際成本幾乎只剩 S3 儲存費，日誌量再怎麼長也不會爆預算。

想在臺灣本地機房自架 OpenObserve、又不想為了幾張 dashboard 開跨境雲端帳號的團隊，可以考慮 NCSE Network 位於是方電訊機房的 VPS 服務，搭配自架 MinIO 或 Garage 當 S3 後端，整套 observability 系統從資料到儲存都留在境內，延遲低、頻寬便宜，也不用擔心跨境資料主權問題。