Kubernetes - Tony Bai

本文永久链接 – https://tonybai.com/2025/07/27/native-prometheus-instrumentation-over-opentelemetry

大家好，我是Tony Bai。

在云原生可观测性的世界里，OpenTelemetry (OTel) 正如日中天。它被誉为“可观测性的未来”，承诺用一个统一的标准，终结 Metrics、Traces、Logs 各自为战的混乱局面。无数的开发者和公司，都在热情地拥抱这个“一次插桩，到处发送”的美好愿景。

但就在这股几乎不可阻挡的浪潮中，一个权威的声音却发出了一个略显刺耳的警告。

这个人，就是 Prometheus 的联合创始人，Julius Volz。

在他最新的博文中，Julius 毫不客气地指出：如果你正在使用 Prometheus 作为你的核心监控系统，并且你真正关心监控的质量和体验，那么，在使用 OpenTelemetry SDK 生成 Metrics 前，请务必三思！

他认为，拥抱 OTel 这个“通用标准”的代价，可能是丢掉 Prometheus 作为一个完整监控系统的“灵魂”，并背上丑陋、低效和复杂的“技术债”。

你正在丢掉 Prometheus 的灵魂

Julius 首先尖锐地指出了一个哲学问题：Prometheus 不仅仅是一个“指标数据库”，它是一个端到端的、有自己思想的监控系统。而 OTel 的“后端无关”设计，恰恰破坏了这种端到端的自洽性。当你选择用 OTel 向 Prometheus 推送数据时，你正在放弃这些至关重要的原生特性：

失去灵魂：Target 健康监控 (up 指标)

Prometheus 最核心的设计之一就是 Pull 模型 + 服务发现。这意味着 Prometheus 主动拉取指标，它清楚地知道“哪些目标应该存在”以及“它们现在是否健康”。如果一个目标拉取失败，Prometheus 会自动生成一个 up{job=”demo”} = 0 的指标。你可以用一条简单的 PromQL 告警规则 up == 0 来发现任何失联的服务。

然而，当你使用 OTel 的 Push 模型时，Prometheus 变成了一个被动的“无情的数据接收器”。它无法再区分一个服务是“正常下线”还是“已经崩溃但没来得及上报”。你可能拥有数百个已经死掉的服务进程，却在监控图表上一无所知。

失去优雅：丑陋的 PromQL 查询

为了兼容 PromQL，OTel 的指标在进入 Prometheus 时，往往需要经过“魔改”。
* 命名冲突： OTel 允许在指标名中使用“.”，而 Prometheus 的传统是不允许的。所以，一个 OTel 指标 k8s.pod.cpu.time 在进入 Prometheus 后，会被翻译成 k8s_pod_cpu_time_seconds_total。这种不一致性会给开发者带来困惑。
* 繁琐的查询语法： 为了支持 OTel 更宽泛的字符集，如果你想查询原始的 OTel 指标名，你的 PromQL 查询会从优雅的 my_metric{…} 变成丑陋的 {“my.metric”, …}。

失去便利：复杂的标签 Join

Prometheus 的 target labels（如 instance, job）会被自动附加到从该目标拉取的所有指标上。而 OTel 的 resource attributes（包含更多非关键元数据）则不会。为了避免高基数问题，大部分 OTel 的资源属性被打包进了一个单独的 target_info 指标里。

这意味着，如果你想在查询时使用这些属性，你必须写出类似下面这样繁琐的 group_left join 查询：

// 想加一个 k8s_cluster_name 标签，查询变得如此复杂
rate(http_server_request_duration_seconds_count[5m])
* on(job, instance) group_left(k8s_cluster_name)
target_info

这些问题，都在不断地增加你的认知负荷和工作复杂度。

性能鸿沟：Go SDK 的“血案”现场

如果说失去优雅和可靠性还不足以让你警醒，那么接下来的硬核性能数据，可能会让你大吃一惊。Julius 特别对比了 Prometheus Go SDK 和 OpenTelemetry Go SDK 在执行最常见操作——计数器递增——时的性能。

结论是毁灭性的。

Julius 的基准测试显示，在不同的并行度和标签缓存条件下：
* 在最坏情况下，Prometheus Go SDK 比 OTel Go SDK 快 26 倍。
* 在有标签缓存的最佳情况下，Prometheus Go SDK 甚至可以比 OTel Go SDK 快 53 倍！
* 更致命的是，Prometheus Go SDK 在所有情况下都实现了零新内存分配，而 OTel SDK 在设置标签时则会持续产生内存分配。

为什么会有如此惊人的差距？
* 复杂性 vs. 专注性： OTel SDK 是一个试图统一三驾马车（Metrics, Traces, Logs）的庞大系统，内部抽象层次多，路径长。而 Prometheus SDK 的目标极其单一和专注：用最高效的方式生成 Prometheus 指标。
* 主观代码体验： Julius 更是用一个生动的例子佐证了这一点——他想在两个 SDK 中找到核心的 Inc() 函数实现。在 Prometheus Go SDK 中，他花了 5 秒；而在 OTel Go SDK 中，他在复杂的抽象和间接调用中迷失了 15 分钟后，最终放弃了。

对于性能至关重要的 Go 后端服务来说，选择 OTel SDK 进行指标插桩，无异于在你的性能快车道上，悄悄地铺上了一层厚厚的沥青。

结论：在“通用标准”与“原生体验”之间做出选择

Julius 的文章并非是否定 OpenTelemetry 的价值。OTel 作为一个中立的、后端无关的“可观测性瑞士”，在构建异构系统、避免厂商锁定的场景中，依然具有不可替代的战略意义。

但他的警告是在提醒我们一个深刻的权衡：
* OpenTelemetry 的世界观： 追求最大的通用性和互操作性。它是一个数据生成和传输的标准，它不关心数据最终如何被使用。
* Prometheus 的世界观： 追求一个深度整合、端到端优化的系统体验。它的每一个设计——从 Pull 模型到 PromQL 语法——都在为最终用户能以最优雅、最高效的方式进行监控和告警服务。

如果你已经选择 Prometheus 作为你的核心监控“城邦”，那么使用它原生的客户端库，并非是选择“封闭”，而是选择一个经过千锤百炼的、高度自洽的、性能卓越的解决方案。

所以，在你为下一个 Go 项目 go get OTel SDK 之前，请先问自己一个问题：我是在追求一个“放之四海而皆准”的通用标准，还是在追求一个能将我的核心工具发挥到极致的原生体验？

答案，可能决定了你未来无数个夜晚的睡眠质量。

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

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/07/23/go-surge-in-popularity

大家好，我是Tony Bai。

最近，在国外的 Go 语言社区（Reddit r/golang），有用户提出了一个我们许多人可能都想过的问题：“是只有我一个人觉得，还是 Go 近年来的人气确实在上升？”

这个问题迅速引爆了社区，收到了近百条来自全球一线开发者的回复。答案是响亮而一致的：不，不是你一个人。 Go 的崛起，早已超越了其在云原生领域的舒适区，正以一种不可阻挡的势头，渗透到软件工程的各个角落。

这篇文章，不谈空泛的理论，也不做单纯的布道。我想带你一起，潜入这场热烈的社区讨论，去倾听那些最真实、最鲜活的声音，看看开发者们自己，是如何解释 Go 成功的秘诀。

第一支柱：Go，新一代的“基础设施语言”

在所有的讨论中，一个观点被反复提及，并获得了最高的赞誉：

“我称 Go 为‘基础设施语言’（the language of infrastructure）。”

这个定义精准地抓住了 Go 的灵魂。当我们审视当今软件世界的基石时，会发现一个惊人的事实：那些支撑着我们数字世界的骨架，几乎都是用 Go 构建的。社区用户随手就列出了一份星光熠熠的名单：

Docker & Kubernetes
Podman & Helm
Etcd、Consul & Terraform
……等等等等

这些工具定义了容器化、编排和基础设施即代码（IaC）的现代范式。而一个更具冲击力的例子来自一位正在构建 Hypervisor 平台的开发者，他分享道：

“我们的核心分布式系统是用纯 Go 编写的，总共只用了 4 个 外部依赖。其余的一切，都来自 Go 的标准库和 FreeBSD。是的，你没看错，我没有打错字。”

仅凭标准库就能构建如此复杂的底层系统，这强有力地证明了 Go 语言的强大、自足与工程上的优越性。它不是玩具，而是真正能用来打造重型装备的工业级工具。

第二支柱：简单的“宿命”——生产力的终极来源

一个极具洞察力的观点在社区中引发了共鸣：

“Go 的简单性，注定了它会随着时间的推移而越来越受欢迎。”

这是一个奇妙的悖论。许多开发者初识 Go 时，可能会抱怨它“缺少功能”（比如早年关于泛型的激烈争论）。然而，随着项目的深入，大家逐渐意识到，简单性，恰恰是 Go 最强大的武器。

因为它带来了：

极高的可维护性：没有复杂的继承链，没有隐晦的语法糖，代码直截了当，易于理解和修改。
惊人的生产力：当你不再需要为语言的复杂特性而烦恼时，你就能更专注于解决业务问题本身。
极低的上手门槛：正如一位用户所说，“Go 很容易教给新员工”。在一个需要团队协作的工程世界里，这一点至关重要。

另一位开发者补充道：“我讨厌在晦涩的语言废话上浪费时间。我只需要交付高质量、可长期维护的生产级代码。Go 提供了最核心的骨架，这正是我所需要的。”

第三支柱：出色的性能与工程体验的完美平衡

如果说简单是 Go 的哲学，那么在性能与体验之间找到那个“甜点”（Sweet Spot），就是它在工程实践中取胜的关键。

社区对此有一个生动的总结：“我们用 Go 得到了 C 语言 95% 的好处，同时摆脱了它的那些麻烦。” 评论区里一句饱含情感的“NO CMAKE!”足以让无数系统程序员会心一笑。

同时，Go 语言“缓慢改进”（slowly improving）的策略也被认为是优点。对于生产环境而言，这意味着更少的破坏性变更和更稳定的生态系统。

在与另一门备受推崇的系统语言 Rust 的对比中，社区的看法也相当务实：“我们用 Rust 来做更接近底层硬件（close to the metal）的工作，用 Go 来做更高层次的事情。” 两者各有所长，Go 在应用层和中间件层提供了无与伦比的开发效率。

一个现代化的加分项：与 AI 工具的奇妙协同

在 AI 赋能开发的今天，Go 的简单性再次展现出意想不到的优势。社区里关于 Go 与 AI Code Assistants（如 Copilot）的讨论，揭示了一个新的增长点。

一方面，AI 更“喜欢”Go。 因为 Go 语言相对年轻，其在网络上的训练数据中，“历史垃圾代码”（比如陈旧的 WordPress/PHP 样例）较少。其简洁、统一的语法也让 AI 更容易学习和生成高质量的代码。
另一方面，开发者更喜欢用 AI 写 Go。 正如一位用户所说：“因为 Go 代码易于阅读和理解，AI 提出的建议可以在几秒钟内被接受或拒绝。”

这种奇妙的协同效应，恰恰体现了 AI 辅助开发的最佳实践：AI 作为一个强大的初稿生成器，而 Go 的简洁性则极大地降低了人类进行代码审查和最终决策的认知负荷。