連續 profiling 這個概念已經被 Google、Netflix、Datadog 講了六七年，但真的把它塞進自架觀測性堆疊裡跑起來的臺灣團隊仍然屈指可數。原因不是技術理解跟不上，而是過去的開源方案要不就是抄了 Cortex 那套「寫入三份、讀取要 Redis 協調」的架構、單機根本跑不動，要不就是儲存跟符號解析的成本堆到比 metrics 加 logs 加起來還高，光是資源需求就把 VPS 級部署踢出候選名單。這個門檻在 2026 年 4 月被 Pyroscope 2.0 直接拉低——寫入路徑的複製整個拔掉、讀取路徑改成 stateless、符號資訊去重率高達 95%——加上 OpenTelemetry Profiles 訊號同年 3 月進 public alpha、把 pprof 收進 OTLP，這兩件事合起來讓自架連續 profiling 第一次成為 VPS 上真的裝得起來的東西。
寫入路徑三份複製是怎麼變成連續 profiling 的原罪
Pyroscope 1.x 的架構基本上是照 Grafana 自家的 Mimir、Loki、Tempo 那套抄過來的——ingester 端每收到一筆資料就往三個節點複製、之後才算 ack、確保任何單一 ingester 掛掉都不會丟資料。這套設計在 metrics 跟 logs 上是合理的，因為單筆資料只有幾十到幾百 bytes、複製兩份的網路與磁碟成本感受不到。
Profile 就完全不是這回事。單個 CPU profile 抓下來動輒 5 到 20 MB，含符號資訊時上百 MB 也不奇怪，而且熱門服務每分鐘會產出好幾份。三倍複製直接讓寫入 IOPS 跟儲存空間各膨脹三倍，加上 ingester 記憶體要撐得住三份 in-flight 資料，單臺機器動不動需要 32 GB RAM 才能起得順。Grafana 官方自己的部署經驗是分散式 Pyroscope 1.x 從安裝到穩定跑起來平均要花 8 到 12 小時、需要協調 5 到 7 個元件（ingester、querier、store-gateway、compactor、distributor、Consul、Redis），這個複雜度在企業 K8s 環境或許還算合理，但拿到 4 核 8 GB 的 VPS 上想跑「就是我自己一個人用」的觀測性堆疊，完全不成比例。
Pyroscope 2.0 把寫入複製整個拿掉
2.0 的核心決定是承認 profile 資料型態跟 metric、log 不同，該用不同架構。寫入路徑改成單寫入直接落到物件儲存——S3、MinIO、Garage、Cloudflare R2 都行——由物件儲存本身的多副本保證資料耐久性，Pyroscope 自己不再做應用層複製。這個改動的前提是 write path 上的資料在 flush 到 object storage 之前只暫存在單一節點的記憶體 buffer，看起來風險提高了，但 Grafana Cloud Profiles 自己從 2025 年 4 月就在生產跑 2.0 至今沒有大規模資料遺失事件，實務上這個 trade-off 站得住腳。
第二個決定是把符號資訊的儲存做去重。同一支 Go binary 在同一小時內產出的 100 份 profile，函數名稱、原始碼位置、堆疊 frame 幾乎完全一樣，1.x 把這些字串重複塞進每一份 profile 裡，2.0 則把符號資訊拉出來單獨 dedupe、同服務的 profile 共用一份符號表。官方在 Grafana Cloud 上量到的結果是符號儲存足跡最多可以降 95%，對於自架環境意味著同樣的 S3 或 MinIO 帳單能撐 20 倍長度的保留期。
Address-level 的 symbolizer 也在 2.0 拉成公開 API。過去要在自架環境上讓 profile 顯示對的函數名稱、行號，得靠 client-side symbolizer 或部分商業 profiler 內建的符號解析，2.0 直接把這條路徑內建到 server 端，跑 Go、Java、Python、Rust、C/C++ 的 binary 都能靠上傳 debug info 或 buildid 讓 Pyroscope 自己解出符號來。這對 eBPF profile 特別關鍵——kernel 端抓回來的 stack trace 只有 address、沒有符號，過去要在 Agent 端裝一堆 symbol resolution 工具，現在集中在 Pyroscope 一邊就結束。
讀取路徑 stateless 帶來的部署簡化
1.x 的 store-gateway 是有狀態元件，query 進來時要靠它在記憶體裡維護 tenant 對 tenant 的 index、chunk 位置、bloom filter，掛掉一次要重建這些狀態動輒十幾分鐘。2.0 把 store-gateway 整個拿掉，querier 直接從 object storage 讀 index、每次 query 都是獨立事件、沒有暖機時間、沒有狀態同步。
實務上的意義是自架部署可以完全把 Pyroscope 當成無狀態 web service 跑——docker restart 或 systemctl restart 秒回、不用擔心 warm-up、也不用擔心某個 querier 節點掛掉之後查詢會少一段時間的資料。對只有一臺機器的部署場景，Pyroscope 直接跑 all-in-one binary、資料寫進本機 MinIO 或 Garage 就結束，開機到能查詢平均低於 30 秒。這個體感差異對「就是想在自己的 VPS 上跑 profiling 看看應用程式熱區」的個人開發者來說，是從「試過幾次就放棄」跳到「日常開著」的分水嶺。
OpenTelemetry Profiles 進 alpha 把採集端統一
寫入端的存活壓力解掉之後，下一個門檻是採集端。Pyroscope 1.x 時代要把 profile 送進去得挑一個特定的 pusher——Pyroscope agent、Grafana Alloy、或各種語言 SDK——每個都有自己的 wire format 跟 label semantics，換 backend 幾乎等於重新裝一次採集器。
OpenTelemetry Profiles 訊號在 2026 年 3 月進入 public alpha，收成第四個觀測性訊號跟 traces、metrics、logs 並列。OTLP 的 profile payload 跟 pprof 無損互換——同一份資料可以用 pprof 工具直接開、也可以在 OpenTelemetry 管線上跑 processor 加 label 或 sampling。相對於 pprof 原生格式，OTLP 靠 shared string dictionary 又把 wire size 縮了大約 40%，這對頻寬受限的 VPS 環境不無小補。
OpenTelemetry Collector 從 v0.148.0 起有 pprof receiver、支援直接吃 pprof 端點；下游可以用 OTLP exporter 把資料轉發給 Pyroscope 2.0 或任何支援 OTLP profile 的後端。這意味著採集端統一用 OTel Collector（順便處理 metrics、logs、traces）、後端只需要選一個支援 OTLP 的 profile store，不用再為 profile 額外維護一條採集管線。實務上跑 Grafana Alloy 也一樣——Alloy 在 1.x 時就是官方推薦的 Pyroscope pusher，2.0 開始 Alloy 內建 OTLP profile 轉發，切換 backend 不用改採集端設定。
一臺 VPS 上該怎麼把整條連續 profiling 堆疊跑起來
實務部署最小組合是四樣東西：Pyroscope（server + object storage backend）、物件儲存（MinIO 或 Garage 選一個）、Grafana（前端查詢介面）、以及 OpenTelemetry Collector 或 Grafana Alloy（採集端）。這四樣用 docker compose 起在同一臺機器上，2 核 4 GB RAM 的 VPS 就能撐得住每分鐘幾十份 profile 的量。
Object storage 選型上，Garage 對小規模自架比較合適——單 binary、無外部依賴、預設就跑得動；MinIO 生態成熟但社群版被凍在最後一次 commit 之後就沒動了，維運上比較尷尬；RustFS 是這幾個月從 MinIO fork 出來繼續維護的 Rust 重寫方案，值得評估但生態還在起步。三者跟 Pyroscope 2.0 的 S3 相容協定都能對接，選擇比較是根據整體堆疊風格。
Retention 策略上，Pyroscope 2.0 的預設保留期是 30 天，符號資訊去重後單服務每月大概吃 5 到 20 GB 空間，對 100 GB SSD 的 VPS 完全可以撐一年以上不用清。這是跟 metrics/logs 完全不同等級的儲存效率，也是「連續 profiling 在自架環境變成可行」的關鍵之一。
eBPF profile 採集在 Linux kernel 5.10+ 有完整 BTF 支援時最順，官方推薦的 Grafana Alloy 內建 eBPF profiler、跑起來只吃單核 1% 到 3% 的 CPU。Ubuntu 24.04、Debian 12、以及即將普及的 Ubuntu 26.04 都符合這個 kernel 要求。要注意的是 eBPF profile 對 container 環境有一些額外限制——rootless podman 上 eBPF profiler 抓不到 host 層級 stack、需要走 pod 內獨立部署，這在 K8s 環境會多一步規劃。
現階段的邊界跟風險
OpenTelemetry Profiles 訊號還在 alpha，SIG 官方明確建議不要拿來承載關鍵生產工作負載——不是說會壞，而是 wire format 還可能在後續版本微調、跨版本相容性目前不保證。對於「先試著理解自己的應用程式在哪浪費 CPU」這種診斷用途完全夠用，但要把 profile 資料當成長期 SLO 或告警的原始資料源，2026 年還太早。
Pyroscope 2.0 本身的另一個 trade-off 是熱門查詢的第一次冷啟動會慢——因為 querier 無狀態、每次 query 都要從 object storage 拉 index，第一次跑某個查詢的延遲會在幾秒範圍。1.x 因為 store-gateway 有記憶體 cache 會比較快，但代價是那個記憶體常駐、失效重建痛苦。實務上這個 trade-off 對自架環境比較划算，因為自架環境的查詢通常是「事後查一次找熱點」而非「儀表板每 5 秒重跑一次」。
長期依賴風險方面，Pyroscope 主線由 Grafana Labs 主導，AGPL-3.0 授權提供了 fork 保護。但過去兩年 HashiCorp、Redis、Elastic 連環改授權的先例還在，Grafana 目前商業模式健康、但長期看仍值得留意。要降低這個風險，最實際的做法是把採集端統一到 OpenTelemetry 生態、backend 保持可換掉的能力——這也正是 OTel Profiles 訊號存在的意義之一。
結論：連續 profiling 從企業級能力變成 VPS 也扛得住的觀測訊號
過去 profiling 一直是自架觀測性堆疊裡最貴、最難搞的一環。Pyroscope 2.0 把寫入複製拔掉、讀取路徑無狀態化、符號儲存去重之後，硬體門檻從 32 GB RAM 的專用 profile 節點掉到 4 GB VPS；OpenTelemetry Profiles 進 alpha 把採集端統一，長期背了 OTel 這面大旗表示這個訊號會繼續被主流生態支持。這兩件事合起來讓「在自己的 VPS 上跑一整套 profiling + metrics + logs + traces」在 2026 年下半年變成合理選項，不再需要靠 Datadog、New Relic、Sentry 這些 SaaS 綁定。
NCSE Network 在臺灣是方電訊機房提供的 VPS 主機採用 Intel Xeon Gold CPU 與 NVMe SSD，單核心效能對 eBPF profiling 這類敏感型工作負載有實際差異，NVMe 對 object storage 的隨機讀寫也讓 Pyroscope 2.0 的冷啟動延遲控制在合理範圍。想在臺灣機房自架整套連續 profiling 堆疊、跟現有 observability 一併托管，前往 ncse.tw 了解 VPS 規格與方案細節。
