大家好，我是Tony Bai。

在云原生可觀測性的世界里，OpenTelemetry (OTel) 正如日中天。它被譽(yù)為“可觀測性的未來”，承諾用一個(gè)統(tǒng)一的標(biāo)準(zhǔn)，終結(jié) Metrics、Traces、Logs 各自為戰(zhàn)的混亂局面。無數(shù)的開發(fā)者和公司，都在熱情地?fù)肀н@個(gè)“一次插樁，到處發(fā)送”的美好愿景。

但就在這股幾乎不可阻擋的浪潮中，一個(gè)權(quán)威的聲音卻發(fā)出了一個(gè)略顯刺耳的警告。

這個(gè)人，就是 Prometheus 的聯(lián)合創(chuàng)始人，Julius Volz。

在他最新的博文中，Julius 毫不客氣地指出：如果你正在使用 Prometheus 作為你的核心監(jiān)控系統(tǒng)，并且你真正關(guān)心監(jiān)控的質(zhì)量和體驗(yàn)，那么，在使用 OpenTelemetry SDK 生成 Metrics 前，請務(wù)必三思！

他認(rèn)為，擁抱 OTel 這個(gè)“通用標(biāo)準(zhǔn)”的代價(jià)，可能是丟掉 Prometheus 作為一個(gè)完整監(jiān)控系統(tǒng)的“靈魂”，并背上丑陋、低效和復(fù)雜的“技術(shù)債”。

你正在丟掉 Prometheus 的靈魂

Julius 首先尖銳地指出了一個(gè)哲學(xué)問題：Prometheus 不僅僅是一個(gè)“指標(biāo)數(shù)據(jù)庫”，它是一個(gè)端到端的、有自己思想的監(jiān)控系統(tǒng)。而 OTel 的“后端無關(guān)”設(shè)計(jì)，恰恰破壞了這種端到端的自洽性。當(dāng)你選擇用 OTel 向 Prometheus 推送數(shù)據(jù)時(shí)，你正在放棄這些至關(guān)重要的原生特性：

失去靈魂：Target 健康監(jiān)控 (up 指標(biāo))

Prometheus 最核心的設(shè)計(jì)之一就是 Pull 模型 + 服務(wù)發(fā)現(xiàn)。這意味著 Prometheus 主動(dòng)拉取指標(biāo)，它清楚地知道“哪些目標(biāo)應(yīng)該存在”以及“它們現(xiàn)在是否健康”。如果一個(gè)目標(biāo)拉取失敗，Prometheus 會(huì)自動(dòng)生成一個(gè) up{job="demo"} = 0 的指標(biāo)。你可以用一條簡單的 PromQL 告警規(guī)則 up == 0 來發(fā)現(xiàn)任何失聯(lián)的服務(wù)。

然而，當(dāng)你使用 OTel 的 Push 模型時(shí)，Prometheus 變成了一個(gè)被動(dòng)的“無情的數(shù)據(jù)接收器”。它無法再區(qū)分一個(gè)服務(wù)是“正常下線”還是“已經(jīng)崩潰但沒來得及上報(bào)”。你可能擁有數(shù)百個(gè)已經(jīng)死掉的服務(wù)進(jìn)程，卻在監(jiān)控圖表上一無所知。

失去優(yōu)雅：丑陋的 PromQL 查詢

為了兼容 PromQL，OTel 的指標(biāo)在進(jìn)入 Prometheus 時(shí)，往往需要經(jīng)過“魔改”。

• 命名沖突： OTel 允許在指標(biāo)名中使用 .，而 Prometheus 的傳統(tǒng)是不允許的。所以，一個(gè) OTel 指標(biāo) k8s.pod.cpu.time 在進(jìn)入 Prometheus 后，會(huì)被翻譯成 k8s_pod_cpu_time_seconds_total。這種不一致性會(huì)給開發(fā)者帶來困惑。
• 繁瑣的查詢語法： 為了支持 OTel 更寬泛的字符集，如果你想查詢原始的 OTel 指標(biāo)名，你的 PromQL 查詢會(huì)從優(yōu)雅的 my_metric{...} 變成丑陋的 {"my.metric", ...}。

失去便利：復(fù)雜的標(biāo)簽 Join

Prometheus 的 target labels（如 instance, job）會(huì)被自動(dòng)附加到從該目標(biāo)拉取的所有指標(biāo)上。而 OTel 的 resource attributes（包含更多非關(guān)鍵元數(shù)據(jù)）則不會(huì)。為了避免高基數(shù)問題，大部分 OTel 的資源屬性被打包進(jìn)了一個(gè)單獨(dú)的 target_info 指標(biāo)里。

這意味著，如果你想在查詢時(shí)使用這些屬性，你必須寫出類似下面這樣繁瑣的 group_left join 查詢：

// 想加一個(gè) k8s_cluster_name 標(biāo)簽，查詢變得如此復(fù)雜
rate(http_server_request_duration_seconds_count[5m])
* on(job, instance) group_left(k8s_cluster_name)
target_info

這些問題，都在不斷地增加你的認(rèn)知負(fù)荷和工作復(fù)雜度。

性能鴻溝：Go SDK 的“血案”現(xiàn)場

如果說失去優(yōu)雅和可靠性還不足以讓你警醒，那么接下來的硬核性能數(shù)據(jù)，可能會(huì)讓你大吃一驚。Julius 特別對比了 Prometheus Go SDK 和 OpenTelemetry Go SDK 在執(zhí)行最常見操作——計(jì)數(shù)器遞增——時(shí)的性能。

結(jié)論是毀滅性的。

Julius 的基準(zhǔn)測試顯示，在不同的并行度和標(biāo)簽緩存條件下：

• 在最壞情況下，Prometheus Go SDK 比 OTel Go SDK 快 26 倍。
• 在有標(biāo)簽緩存的最佳情況下，Prometheus Go SDK 甚至可以比 OTel Go SDK 快 53 倍！
• 更致命的是，Prometheus Go SDK 在所有情況下都實(shí)現(xiàn)了零新內(nèi)存分配，而 OTel SDK 在設(shè)置標(biāo)簽時(shí)則會(huì)持續(xù)產(chǎn)生內(nèi)存分配。

為什么會(huì)有如此驚人的差距？

• 復(fù)雜性 vs. 專注性： OTel SDK 是一個(gè)試圖統(tǒng)一三駕馬車（Metrics, Traces, Logs）的龐大系統(tǒng)，內(nèi)部抽象層次多，路徑長。而 Prometheus SDK 的目標(biāo)極其單一和專注：用最高效的方式生成 Prometheus 指標(biāo)。
• 主觀代碼體驗(yàn)： Julius 更是用一個(gè)生動(dòng)的例子佐證了這一點(diǎn)——他想在兩個(gè) SDK 中找到核心的 Inc()函數(shù)實(shí)現(xiàn)。在 Prometheus Go SDK 中，他花了 5 秒；而在 OTel Go SDK 中，他在復(fù)雜的抽象和間接調(diào)用中迷失了 15 分鐘后，最終放棄了。

對于性能至關(guān)重要的 Go 后端服務(wù)來說，選擇 OTel SDK 進(jìn)行指標(biāo)插樁，無異于在你的性能快車道上，悄悄地鋪上了一層厚厚的瀝青。

結(jié)論：在“通用標(biāo)準(zhǔn)”與“原生體驗(yàn)”之間做出選擇

Julius 的文章并非是否定 OpenTelemetry 的價(jià)值。OTel 作為一個(gè)中立的、后端無關(guān)的“可觀測性瑞士”，在構(gòu)建異構(gòu)系統(tǒng)、避免廠商鎖定的場景中，依然具有不可替代的戰(zhàn)略意義。

但他的警告是在提醒我們一個(gè)深刻的權(quán)衡：

• OpenTelemetry 的世界觀： 追求最大的通用性和互操作性。它是一個(gè)數(shù)據(jù)生成和傳輸?shù)臉?biāo)準(zhǔn)，它不關(guān)心數(shù)據(jù)最終如何被使用。
• Prometheus 的世界觀： 追求一個(gè)深度整合、端到端優(yōu)化的系統(tǒng)體驗(yàn)。它的每一個(gè)設(shè)計(jì)——從 Pull 模型到 PromQL 語法——都在為最終用戶能以最優(yōu)雅、最高效的方式進(jìn)行監(jiān)控和告警服務(wù)。

如果你已經(jīng)選擇 Prometheus 作為你的核心監(jiān)控“城邦”，那么使用它原生的客戶端庫，并非是選擇“封閉”，而是選擇一個(gè)經(jīng)過千錘百煉的、高度自洽的、性能卓越的解決方案。

所以，在你為下一個(gè) Go 項(xiàng)目 go get OTel SDK 之前，請先問自己一個(gè)問題：我是在追求一個(gè)“放之四海而皆準(zhǔn)”的通用標(biāo)準(zhǔn)，還是在追求一個(gè)能將我的核心工具發(fā)揮到極致的原生體驗(yàn)？

答案，可能決定了你未來無數(shù)個(gè)夜晚的睡眠質(zhì)量。

資料鏈接：https://promlabs.com/blog/2025/07/17/why-i-recommend-native-prometheus-instrumentation-over-opentelemetry/