監控資料各自分家的時代要結束了：GreptimeDB 1.0 GA 把 metrics、logs、traces 收進同一個引擎

GreptimeDB 在 2026 年 4 月推出 1.0 GA，這是一個用 Rust 寫成、把 metrics、logs、traces 三種觀測訊號收進同一個列式引擎的時序資料庫。對於長期養著 Prometheus、Loki、Elasticsearch 三套儲存層的團隊來說，這個版本的意義不只是「又多一個選擇」，而是第一次有自架方案能在效能和成本上同時打平商業 SaaS。

可觀測性堆疊長期被切成三塊：Prometheus 管 metrics、Loki 或 Elasticsearch 收 logs、Tempo 或 Jaeger 處理 traces。每一塊都有自己的儲存格式、自己的查詢語言、自己的容量規劃，連同一個 trace ID 要跨 logs 和 traces 查都得寫一堆 ETL。Grafana 在 UI 層努力把這些黏起來，但底層的資料分裂是黏不回來的。

1.0 GA 之前發生了什麼

GreptimeTeam 從 2022 年底開始開發，定位一直很清楚——做一個能同時處理三類觀測訊號的列式時序引擎。Beta1 到 GA 之間累積了 474 個 PR、27 位貢獻者，1.0 標誌的不是功能凍結，而是公開承諾這套儲存格式進入長期維護階段，使用者可以放心把生產資料寫進去。

底層用的是 Apache Arrow 加 DataFusion，這套組合近年已經成為新一代列式引擎的事實標準——Apache Doris、DuckDB、Polars 全都建在類似的技術棧上。GreptimeDB 在這套基礎上加了倒排索引、全文索引和 skipping index，三類查詢——點查、範圍掃描、模糊比對——都能走到次秒級。

值得單獨提的是 Flat SST 格式。1.0 把預設儲存格式從 primary_key 換成 flat，這是針對高基數場景的重寫。在 TSBS benchmark 跑 200 萬條 series 的測試中，寫入吞吐量提升大約 4 倍，部分查詢延遲下降 10 倍。對於現代雲端原生環境動輒幾十萬個 pod、每個 pod 帶幾十個 label 的場景，這個改動是實打實的解圍。

對象儲存當底層，成本結構直接翻轉

Prometheus 預設是 local TSDB，要拉長保留期就得不停加 SSD，或者外接 Thanos、Cortex 做遠端寫入。Loki 雖然支援 S3，但 chunk 切得碎，小檔案問題在大規模下會把物件儲存的請求費用拉到很難看。

GreptimeDB 從第一天就把對象儲存當主要儲存層——S3、Azure Blob、GCS 都原生支援。計算和儲存徹底分離，compute node 是無狀態的，要擴容就拉新節點，不用考慮 rebalance。儲存按量計費，不需要為了應付尖峰預留磁碟容量。

實務上的成本差異很顯著。EMQ 公布的數據顯示，在 IoT 場景下 GreptimeDB 的儲存佔用大約是 InfluxDB 的 1/18。即使把對象儲存的 API call 費用算進去，整體成本還是有數量級的差距。對於需要把 metrics 保留半年以上做容量規劃、或者要存原始 log 做事後稽核的團隊，這個差距會直接反映在月帳單上。

一張表查 metrics、logs 跟 traces

GreptimeDB 1.0 真正的賣點不是個別效能數字，而是統一資料模型。三種訊號全部以列式表格儲存，metrics 是時間序列、logs 是帶時間戳的事件、traces 是有父子關係的 span——但在儲存層面它們長得一模一樣，都是「時間 + 維度欄位 + 數值或字串欄位」。

這代表可以直接寫一個 SQL 把三種訊號 JOIN 起來。比方說一個 API 請求超時，傳統做法是先在 Grafana 切到 Loki 看 log、抓出 trace ID、再切到 Tempo 看 span、再回 Prometheus 看當時的 CPU 和 memory。在 GreptimeDB 上可以直接寫：

SELECT l.message, t.duration, m.cpu_usage
FROM api_logs l
JOIN api_traces t ON l.trace_id = t.trace_id
JOIN host_metrics m ON m.host = l.host
  AND m.ts BETWEEN l.ts - INTERVAL '5 seconds' AND l.ts
WHERE l.level = 'ERROR' AND l.ts > NOW() - INTERVAL '1 hour';

這種跨訊號分析在分裂式架構下幾乎做不到——資料在不同的儲存裡，查詢語言不通用，硬要做就得拉一條 Kafka 把三邊資料倒進資料湖。

PromQL 跟 SQL 雙語接口

換新儲存層最大的阻力通常是 dashboard 和 alert 規則要重寫。GreptimeDB 直接相容 PromQL，原本 Grafana 上用 PromQL 寫的 dashboard 不用動，把資料來源換成 GreptimeDB 即可繼續使用。Prometheus 的 alertmanager 也可以直接接上去。

另一面是 SQL 接口，並且支援 MySQL 和 PostgreSQL 的 wire protocol。這意味著任何能連 MySQL 的工具——Grafana 的 MySQL data source、Metabase、Superset、甚至直接用 mysql CLI——都可以查 GreptimeDB。對於想做臨時分析、或者把可觀測性資料接到 BI 工具的場景，這個雙語接口省下大量整合工作。

Docker 起步：單機部署的最小組合

GreptimeDB 提供 standalone 模式，單一 binary 就能跑起來。生產級的 Docker Compose 設定可以這樣寫：

services:
  greptimedb:
    image: greptime/greptimedb:v1.0.1
    container_name: greptimedb
    restart: unless-stopped
    command: >
      standalone start
      --http-addr 0.0.0.0:4000
      --rpc-bind-addr 0.0.0.0:4001
      --mysql-addr 0.0.0.0:4002
      --postgres-addr 0.0.0.0:4003
      --config-file /etc/greptimedb/config.toml
    ports:
      - "127.0.0.1:4000:4000"
      - "127.0.0.1:4002:4002"
      - "127.0.0.1:4003:4003"
    volumes:
      - greptimedb-data:/greptimedb_data
      - ./config.toml:/etc/greptimedb/config.toml:ro

volumes:
  greptimedb-data:

四個 port 各司其職：4000 是 HTTP（同時提供內建 dashboard）、4001 是內部 gRPC、4002 是 MySQL 協議、4003 是 PostgreSQL 協議。生產環境通常只把 4000 和需要的 SQL port 開放出去，gRPC 留給 cluster 內部用。

config.toml 裡可以指定對象儲存後端：

[storage]
type = "S3"
bucket = "your-greptimedb-bucket"
root = "data"
access_key_id = "AKIA..."
secret_access_key = "..."
endpoint = "https://s3.example.com"
region = "ap-northeast-1"

把儲存放到 S3 之後，本地磁碟只需要放 WAL 和快取，VPS 的磁碟壓力會大幅降低。對於想跑大量保留時間但又不想為 SSD 付高價的場景，這個架構特別合適。

從 Prometheus 搬遷的實際路徑

直接全量切換風險太高，建議分階段走：

第一階段——雙寫驗證：在 Prometheus 旁邊架一台 GreptimeDB，用 remote_write 把 metrics 同時寫進兩邊。Prometheus 設定加上：

1 2	remote_write: - url: http://greptimedb:4000/v1/prometheus/write?db=public

跑個一兩週，確認資料一致、查詢結果對齊。

第二階段——查詢切換：在 Grafana 上新增一個 GreptimeDB 的 data source，把部分 dashboard 切過去測試 PromQL 相容性。多數情況下 query 不用改，但複雜的 subquery 或者用到 Prometheus 特定函式的地方需要驗證。

第三階段——alert 切換：把 alertmanager 的查詢來源換成 GreptimeDB，觀察告警觸發是否與原本一致。

第四階段——關閉 Prometheus 本地儲存：確認穩定後，把 Prometheus 改成純粹的 scraper + remote_write，或者直接換成 OpenTelemetry Collector + Vector 的組合，把資料直接送進 GreptimeDB。

Loki 的搬遷類似——把 Promtail 或 Alloy 的輸出改寫到 GreptimeDB 的 logs ingestion endpoint 即可。Trace 則透過 OTLP，標準的 OpenTelemetry Collector 設定指過去就能用。

還沒解決的問題

GreptimeDB 1.0 確實成熟很多，但有幾個地方還沒走到位。

Distributed 模式的營運心智負擔：standalone 部署很乾淨，但 cluster 模式需要管 metasrv、frontend、datanode、flownode 四個角色。對於不熟悉 cluster 架構的團隊，營運門檻仍比直接跑 Prometheus 高。如果規模不到需要橫向擴展，先在 standalone 跑就好。

生態系成熟度：相比 Prometheus 十年累積的 exporter 生態和告警規則，GreptimeDB 仍處於追趕階段。多數 exporter 透過 remote_write 可以無痛接上，但一些第三方整合（例如 Datadog agent forwarder）還沒有官方支援。

Flow Engine 仍在迭代：連續聚合的 Flow Engine 是 GreptimeDB 在 stream processing 上的關鍵組件，但在 1.0 GA 後仍列為持續強化方向。對於倚賴 downsampling 做長期儲存的場景，目前的做法相對手動。

一個值得長期投入的方向

可觀測性堆疊的整併是技術趨勢，不是單一產品的銷售故事。當 OpenTelemetry 把採集端統一、Grafana 把展示端統一，儲存層的整併是邏輯上的下一步。GreptimeDB 1.0 GA 在這個方向上交出了第一份可信的答案——對象儲存當底層、列式引擎做運算、SQL 和 PromQL 雙語接口讓既有工具鏈不用重寫。

對於現在正在規劃可觀測性架構的團隊，把 GreptimeDB 列入評估清單是合理的。不論最終選不選，至少要知道「三套儲存層」這個假設已經被挑戰了——而且挑戰來自一個工程成熟度足以擺脫實驗性質的開源專案。

需要一台規格穩定的 VPS 來部署 GreptimeDB 跟對應的 OpenTelemetry Collector？NCSE Network 提供搭載 Intel Xeon Gold CPU 與 NVMe SSD 的臺灣本地 VPS 主機，是方電訊機房直連，網路品質適合對監控資料延遲敏感的觀測性服務部署。前往 ncse.tw 了解方案細節。