OpenTelemetry eBPF Instrumentation（下稱 OBI）在 2026 年 4 月的 KubeCon + CloudNativeCon Europe 進到 beta，這個名字是 Grafana Beyla 2025 年 11 月捐給 OpenTelemetry 之後的正式牌照。名字換了，能力也不再綁在 Grafana Cloud 這一家：OBI 用 eBPF 直接掛在 kernel 上抓 HTTP、gRPC、PostgreSQL、Redis 的流量，把 RED metrics 跟 distributed trace 用 OTLP 送出去，應用程式二進位一行都不用動。這件事對臺灣 VPS 上跑一堆舊 Go、Java、Node 服務、又懶得回頭塞 SDK 的團隊，是這一輪 zero-code 觀測工具裡最直接的一條路。
比較容易被忽略的是 OBI 不是只能跑在 Kubernetes 上。官方支援三種部署形態：Kubernetes DaemonSet、Docker 容器、以及純 Linux 主機的 standalone 模式。中小型服務跑在單臺 VPS 上時，standalone 才是主線，Kubernetes 的討論反而是雜訊。
Beyla 為什麼要捐出去
Beyla 從 2023 年就一直是 Grafana 家自己維護的 eBPF instrumentation agent。它做得很好，2024 到 2025 之間把 Go 的 uprobe 掛法、TLS 解密、SQL/Redis 支援都塞得差不多，可是「Grafana 家」這三個字讓它進不了那些不用 Grafana Cloud 的環境。Splunk、Coralogix、Datadog 這些後端要用 Beyla 就得繞遠路：拿 Beyla 的 OTLP 輸出送到自家 collector，再重新對齊 semantic conventions。這種形狀的整合每個廠商都會做，可是每個廠商都做得不太一樣，結果是 Beyla 明明是 OTLP-native 的工具，市場上還是被當成 Grafana 專屬。
Grafana Labs 2025 年 11 月 3 日的第一個 alpha release 把它上交給 OpenTelemetry，改名為 OpenTelemetry eBPF Instrumentation，maintainer 從單一廠商換成 Grafana、Splunk、Coralogix、Odigos 幾家共治。OpenTelemetry 底下有正式的 SIG 每週 call，這一步之後開發速度明顯拉起來，2026 年 4 月的 v0.8.0 beta 距離第一個 alpha 只隔五個月，功能已經覆蓋 Beyla 全部能力並多出兩塊：HTTP header enrichment 跟實驗性的 OTEL_CTX 資源屬性映射。
要不要繼續用舊 Beyla 的判斷很簡單：如果環境完全綁 Grafana Cloud、又已經上生產，繼續用；其他所有情境從現在起新專案直接切 OBI，Beyla 的功能開發已經 freeze。
eBPF 兩層架構讓 overhead 壓得住
OBI 走的是「kernel 少做、userspace 多做」的兩層架構。kernel 那層掛 uprobes、kprobes、tracepoints，只負責從 socket、SSL 函式、系統呼叫這些點截取原始 event，然後透過 ring buffer 丟給 userspace 的 Go agent 解析、組 span、對 OTLP schema。這個切法讓 kernel-side 的 CPU cost 壓在單位數百分比，因為真正花時間的 parsing 都不在 kernel 裡跑。
跟 Cilium Hubble 的差異在這裡就分開了。Hubble 抓的是 L3/L4 網路流，看到的是 IP、port、packet 統計。OBI 走的是 L7，掛 uprobe 到 SSL_read / SSL_write 直接把 TLS payload 拆出來，抓得到 HTTP method、path、header、SQL statement。CNI 那層跟 application 那層可以並存，事實上官方文件建議在 Cilium 或 Calico 的 eBPF dataplane 環境裡把 OBI 的 network probe 關掉（network.enabled: false），角色分清楚：CNI 管 L3/L4、OBI 管 L7，兩邊 eBPF program 不會撞在同一個 hook point 上。
TLS 解密這一段是 OBI 相對其他工具的關鍵優勢。傳統 sidecar proxy 的做法要 terminate TLS、加解密一次、再重新加密，對 latency 跟金鑰管理都不友善。OBI 掛在 OpenSSL、BoringSSL、GnuTLS、Go 的 crypto/tls 這些 library 函式的入口，資料在應用程式記憶體裡本來就是明文，抓完之後 kernel 那層繼續走它的加密路徑，一個 byte 都沒動到 wire format。
支援的協定跟語言涵蓋度
Beta 版本的協定清單已經拉得很長，client 跟 server 兩邊都有：HTTP/HTTPS、HTTP/2、gRPC、Kafka、NATS、MQTT、Memcached、SunRPC（含 NFS）、JSON-RPC。AMQP 1.0 跟 DNS 目前只有 client 側。資料庫涵蓋 PostgreSQL、MySQL、MSSQL、Redis 雙向，MongoDB 跟 Elasticsearch 只有 client 側。GenAI API（OpenAI、Anthropic）也在 2026 年的加入清單裡，這對跑 AI agent 或 LLM proxy 的環境是新增的觀察面。
語言支援不是靠特定 runtime hook，而是 eBPF 掛在 syscall 跟 socket 層，天然跨語言。Go、Rust、C++、Java、.NET、Python、Node 這些主要 runtime 都能抓到。Go 額外做了 uprobe 到 net/http、grpc-go 的內部函式，能拿到 goroutine ID 這種語言特定的細節。其他語言拿到的資訊會少一點，但 RED metrics 跟 request/response 的基本 span 是齊全的。
有一個限制值得先講清楚：OBI 抓不到應用程式自己定義的 custom span、business event、或需要 in-process context 的屬性。它填補的是「binary 已經上線、沒法回頭改」的空白，而不是取代 SDK。組合起來用是官方推薦的模式：新程式碼用 SDK 拿 business layer 的可見度，舊 binary 跟第三方服務用 OBI 補上 L7 的 baseline。
在 VPS 上用 standalone 模式跑起來
Kubernetes 環境用 Helm 一行裝完就結束，這種 case 網路上的資料已經夠多。標準 VPS 上跑非容器化或用 docker-compose 的服務，走的是另一條路。OBI 提供 systemd unit 跟 standalone 二進位，直接跑在 host 上、指向要觀察的 process 就行。
基本設定只要三個環境變數：OTEL_EXPORTER_OTLP_ENDPOINT 指向 collector、OTEL_SERVICE_NAME 給服務命名、OBI_OPEN_PORT 或 OBI_EXECUTABLE_PATH 告訴 agent 要觀察誰。前者用 port number 認 process，後者用 binary 路徑，兩個擇一。監聽 port 8080 的 HTTP 服務直接 OBI_OPEN_PORT=8080，Go binary 路徑固定就用 OBI_EXECUTABLE_PATH=/opt/myapp/server。
kernel 需求是硬條件：Linux 5.8 以上，並且要啟用 BTF（BPF Type Format）。Debian 12、13，Ubuntu 24.04、26.04 這幾個主流 distro 的預設 kernel 都符合。RHEL/Rocky/Alma 是特例，官方回移 eBPF 到 4.18，明確列在支援清單裡。Alpine Linux 打包的 kernel 常常沒開 BTF，用 Alpine 當 base image 前要先確認。權限方面需要 CAP_BPF 加 CAP_SYS_PTRACE，systemd unit 裡設 AmbientCapabilities=CAP_BPF CAP_SYS_PTRACE 就好，不必給 root。
資源預算：單臺 VPS 上跑一個 OBI process 觀察 3 到 5 個服務，經驗值是 100 到 200 MB RAM、CPU 峰值 15% 到 30%（觀察 10k RPS 的環境）。這個數字比裝 Java agent 或 sidecar proxy 便宜得多，也是選它的核心理由。
跟 Coroot、Pixie、Tetragon 的區隔
臺灣圈子提到 eBPF observability 常直接想到 Coroot、Pixie、Tetragon，這三個工具跟 OBI 的定位完全不重疊，混在一起講會誤事。
Coroot 是完整的 APM 產品，自帶 UI 跟 storage backend，抓的東西類似 OBI 但整包端到端。適合不想自己組觀測 stack、只要一個 all-in-one 面板的環境。OBI 是純 agent，只吐 OTLP，後端要自己接 Tempo、Jaeger、SigNoz、Grafana、Datadog 都可以。彈性跟工作量之間的 tradeoff。
Pixie 已經被 New Relic 收購，雖然還開源但商業版跟 New Relic 綁得緊。OBI 是 Apache 2.0、廠商中立，這個差異對長期選型很關鍵。
Tetragon 走的是安全方向，掛 eBPF 在 syscall 上做 runtime security enforcement，能攔截、能阻擋。OBI 只做觀察，不做 enforcement。同一臺 host 上兩個工具可以並存，實際上這是很合理的搭配：Tetragon 管 policy、OBI 管 telemetry。
header enrichment 為什麼是 v0.7 之後的分水嶺
v0.7.0 加進來的 HTTP header enrichment 是 OBI 從「基本觀測工具」走向「incident response 工具」的關鍵。多租戶 SaaS 服務出問題時，工程師第一件事是問「是哪個 tenant 中的？」如果 header 裡本來就帶 x-tenant-id、x-user-segment 這種欄位，OBI 可以把這些值直接寫進 span attribute，往下游查詢時就能用 tenant 過濾。
問題是 header 也常裝 PII，這條路容易踩到隱私法規。OBI 用 allowlist plus obfuscation 的預設策略：default_action: exclude 讓沒明講的 header 一律不收，只有 include 清單裡的 header 才會進 span，敏感欄位（authorization、cookie）在 obfuscate 清單裡會被 mask 成 ***。這個預設方向是對的——先安全再開放，比 opt-out 的模式安全得多。
1.0 GA 之前該不該上生產
v0.8.0 是 beta，官方 roadmap 顯示大約完成 60% 的 1.0 checklist。剩下的項目包含 JSON Schema 設定驗證、telemetry schema 定版、.NET Framework 4.x 相容性驗證、跟 SDK trace 的 hybrid instrumentation 語意對齊。GA 預計 2026 年底。
建議做法是分階段：非關鍵服務、內部工具、測試環境直接跑 beta 沒問題，OBI 只讀不寫，出事最壞就是丟掉 span。跨大版本升級要注意 semantic conventions 的變動，v0 階段的 attribute 名稱還在動。生產環境的付費服務再等 1.0 GA，或至少 pin 住小版本、驗過再升。
一個實用的規則：OTLP 輸出的 collector 那邊做好 buffer 跟 retry，OBI 端不管怎麼跌都不會影響應用程式，這是 zero-code 觀測相對於 sidecar proxy 或 in-process SDK 的最大安全網。
臺灣 VPS 上跑 OBI 的實務考量
kernel 版本、BTF 支援、CAP_BPF 這三件事決定 OBI 能不能跑起來，這也是 VPS 選型的隱藏門檻。臺灣機房裡跑舊 kernel 的 OpenVZ VPS 直接出局，KVM 才是主線，這一點跟其他 eBPF 工具的門檻一致。
NCSE Network 的臺灣 VPS 主機跑在是方電訊機房，Intel Gold CPU 加 NVMe SSD 的組合對觀察性 agent 的 CPU 開銷相對友善，Debian 13、Ubuntu 26.04 等映像檔開機即用，kernel 6.x 全開 BTF、eBPF、io_uring 這些近代功能，OBI 跟 Coroot、Tetragon 這類 eBPF 工具都能直接部署。想了解 VPS 方案的細節，可以到 ncse.tw 查看。
