過去兩年最常被點名退訂的雲端服務，第一名是 Datadog。月底帳單動輒新臺幣幾十萬、log ingest 跟 indexed span 各算一份錢、APM host 又另外計算——對於只有幾十台機器、月營收還沒爬到能養得起一個 SRE 團隊的公司來說，這是一筆很尷尬的固定支出。但要自架 APM 又卡在一個老問題：所有開源方案都要先在程式碼裡插 OpenTelemetry SDK，PHP、Ruby、舊版 Node、內部小工具往往沒人想去碰。
Coroot 是這幾年裡少數把 eBPF 真的拿來做完整 APM 的開源方案。寫在 Go 與 Rust 之上、Apache 2.0 授權、2026 年 6 月發到 1.22 版，GitHub 上累積近 8000 顆星。它能在不改任何一行程式碼的前提下抓出 trace、CPU profile 與 service map，這是 SigNoz 跟 Grafana Stack 都沒有直接提供的能力。
SDK 插樁這件事正在變成 APM 的瓶頸
OpenTelemetry 已經是事實標準，但實際導入時的痛點從來不是規格本身，而是「誰要去幫每個服務接 SDK」。後端用 Spring Boot 的還好，auto-instrumentation agent 解決一半問題；換成 Express 加一堆內部 npm 套件就會卡在某些函式抓不到 span。再加上 PHP 老站、CRM 廠商打包好的封閉容器、用 Bash 與 systemd timer 串起來的 cron job，每一塊都得另外排工時去處理。
落到實作層面，這代表的是兩到三個月的工程工時，外加跨團隊溝通成本。中小型團隊根本不會把這件事排進當季 OKR——結果就是 APM 只覆蓋到核心 API，邊緣服務出問題依然得靠 SSH 進去翻 log。
把同樣的事丟給商用 SaaS 也不會更輕鬆，只是把「插樁工時」換成「月費」。Datadog 與 New Relic 的 agent 通常會自動掛上常見執行環境，但對於非主流語言或自製框架還是要寫客製 instrumentation。真正不一樣的是 eBPF。
eBPF 把觀測點從應用層搬進核心
eBPF 不是新東西，Cilium、Tetragon、Falco 都已經把它用在網路與安全層。Coroot 走的是另一條路：把 eBPF 程式掛在 Linux 的 socket 系統呼叫、TCP 連線事件與排程點上，當任何程序送出 HTTP 請求、開 PostgreSQL 連線、把資料推進 Kafka，核心就會把這些事件回報給 node agent。
這代表的不只是抓網路流量，而是抓「應用層協定」的呼叫。Coroot node agent 內建了 HTTP、HTTP/2、PostgreSQL、MySQL、Redis、MongoDB、Kafka、AMQP 的解析器，連 TLS 加密過的流量都能透過 uprobe 掛到 OpenSSL、GnuTLS、Go 的 crypto/tls 上抓 plaintext。從程式的角度看，什麼都沒發生；從觀測平台的角度看，每次資料庫查詢的 SQL、每次外部 API 呼叫的路徑、每次 cache 命中與否，都已經被記下來。
CPU profile 走的是另一條 eBPF 路線：透過 perf_event_open 取得堆疊樣本，再對齊容器 metadata 寫進 Pyroscope 後端。對於想知道「上週四下午那波 CPU 飆高到底是哪段程式碼在燒」的場景，這比事後翻 metric 直觀得多。
零插樁的代價當然存在：eBPF 程式只能看到核心層可見的東西，例如業務語意上的 trace_id 它不會自動產生。Coroot 處理的方式是針對標準 HTTP header（W3C Trace Context、B3）做 in-kernel 解析，能跨進程接上就接，接不上的退回成獨立的 span。對絕大多數 RESTful 微服務架構，這個機制夠用；如果整套系統大量用 gRPC 加客製 metadata 傳 context，效果會打折扣。
從 service map 倒推系統健康狀態
Coroot 的核心 UI 不是傳統的 metric dashboard，而是一張自動產生的 service map。每個節點代表一個服務或外部資源，邊代表它們之間的呼叫關係，顏色代表 SLO 健康度。從這張圖上點下去，可以直接跳到該服務的 latency 分位數、錯誤率、相關 log、相關 trace。
這個設計的價值要實際出過事才看得出來。傳統 APM 的工作流是「拿著 alert 上的 metric 名稱去 dashboard 翻」，找關聯服務還要記得它叫什麼名字。service map 直接把拓樸畫出來，當下游的 PostgreSQL 連線數爆掉時，上游的哪幾個 service 在打它一目了然，不需要先去查服務目錄。
Coroot 還把這套 service map 跟 SLO 綁在一起。每個服務預設都會有 latency 與 availability 的 SLO，達不到就在地圖上標成紅色；點進紅色節點會直接列出最有可能的根因（連線飽和、磁碟 I/O、特定 query 慢），這就是它官網一直在講的「AI Root Cause Analysis」。實務上這個 AI 不是大型語言模型，而是規則引擎加上時序資料關聯——夠用，但別期待它能解出複雜的分散式 race condition。
跟 SigNoz、Grafana Stack 的定位差異
SigNoz 與 Coroot 表面看起來都是「自架的 OTel observability 平台」，但實際工作流幾乎是反過來的。SigNoz 預設假設你已經接好 OTel SDK，它負責把 trace、metric、log 收進 ClickHouse 然後給漂亮的 UI；如果還沒接 SDK，SigNoz 等於少了大半功能。Coroot 預設假設你「不想接 SDK」，它先用 eBPF 把可觀測性的最低保證打起來，OTel SDK 是 nice to have。
Grafana Stack（Prometheus、Loki、Tempo、Pyroscope）走的是「拼裝」路線：每個元件都很強，但要自己接 Alloy、寫 PromQL、設 alerting rule、串 dashboard。對工程團隊已經養出 Grafana 文化的公司，這條路會繼續是首選。對「需要 APM 但不想再花三個月接元件」的團隊，Coroot 的單一安裝包會省掉很多事。
務實的選法：團隊規模 10 人以內、沒有專職可觀測性工程師，直接上 Coroot；已經有 Prometheus 加 Grafana 跑了兩年、要加進階 trace 與 profile，疊一層 SigNoz 或 Tempo；Kubernetes 規模上百節點、SRE 團隊願意自己拼，Grafana Stack 還是天花板最高的選項。
單機 VPS 跟 Kubernetes 的部署實際樣貌
Coroot 在 Kubernetes 上有官方 Helm chart，裝完會跑出一組 deployment：coroot server（UI 與 API）、ClickHouse（儲存 trace、log、profile）、Prometheus（儲存 metric）、Pyroscope（profile 後端），加上以 DaemonSet 形式部署的 coroot-node-agent。對既有 K8s 叢集這是最順的安裝路徑。
VPS 單機部署也支援。官方提供的 docker-compose 大致長這樣：
1 | services: |
privileged: true、pid: host 與 debugfs mount 都是 eBPF 載入所需，避不掉。也因此 node agent 必須跑在每一台要被觀測的主機上，無法把它放在另一台機器遠端抓。Linux kernel 需要 4.16 以上（推薦 5.10 以上），CentOS 7 那種還停在 3.10 的環境裝不上。
資源開銷實測：node agent 大約吃 100 到 200 MB 記憶體加上 1% 到 3% CPU，視服務數量與流量而定。Coroot server 加 ClickHouse 在中等規模（20 到 50 個服務）下大約需要 4 GB 記憶體與 50 GB 磁碟，跑在 4 vCPU 的 VPS 上綽綽有餘。
哪些團隊裝了會有感、哪些不會
最有感的場景是「服務數量不少、語言混雜、沒人有時間去接 OTel」的中小型團隊。電商後端有 Node 加 PHP 加 Python 三種語言、財報系統綁了一堆內部套件、資料平台有 Airflow 拋的 Python job，這種環境裝完 Coroot 大約 30 分鐘就能看到完整的 service map。同樣的工作如果走傳統路線，光是排程跨團隊改程式碼就要一季。
不太適合的是兩種：一是純單體應用、只有一個 service，service map 沒什麼意義，直接用 Prometheus 加 Pyroscope 就好；二是已經完整接好 OpenTelemetry SDK 的成熟系統，Coroot 的 eBPF 資料反而會跟現有 trace 重複，這時 SigNoz 或 Grafana Stack 更能利用既有插樁。
還有一個常被忽略的限制：Coroot 看不到 serverless 與 managed runtime。AWS Lambda、Cloudflare Workers、託管的 Kubernetes 控制面，這些沒有 root 權限的環境裝不了 node agent。混合架構下，Coroot 適合罩住自家機房與 VPS 那部分，雲端 managed 服務還是得回頭走 vendor 自己的 metric。
把可觀測性的入場費降下來
eBPF 之所以重要，不是因為它新潮，而是因為它真的把可觀測性的入場成本降到「裝一個 agent 就有」的等級。Coroot 不會取代所有 APM 方案，但對於那些一直被「先去插樁」卡住的團隊，它把第一步從三個月縮短到一個下午。
如果手上的服務還在靠 SSH 進去翻 log 抓問題，或是雲端 APM 帳單已經佔到月支出的兩成以上，自架一套 eBPF observability 的投資報酬率通常很可觀。NCSE Network 提供臺灣本地的高效能 VPS 主機（Intel Gold CPU、NVMe SSD、是方電訊機房），核心規格與較新的 Linux kernel 都符合 eBPF observability 的部署需求，需要評估自架 APM 的硬體配置時可以參考。
