给一个大集群手工加插桩，要花多少功夫？小编先给结论：Grafana Labs 在 ObservabilityCon 2025 上宣布，Grafana Cloud 的 Instrumentation Hub（插桩中心）已正式可用（GA），可以选择性地注入 OpenTelemetry SDK，让团队不必花数周手工插桩，也能获得更深入的运行时洞察。
这个平台基于开源的 eBPF 和 OpenTelemetry 注入技术，GA 版本在早前预览版的基础上，扩展了对多种语言的选择性 SDK 部署。Grafana Labs 把它定位为一种有引导、可规模化的方式，既能铺开可观测性覆盖，又让运维人员掌握采集什么、怎么采集。官方称：“Instrumentation Hub 是远程发现与选择性自动插桩的控制平面，它去掉了手工插桩这个瓶颈，帮您在几分钟内从零走到有意义的遥测数据。”
一条 Helm 命令，自动编目
部署从 Kubernetes 集群上的一条 Helm 命令开始，它会安装 Alloy（Grafana 发行的 OpenTelemetry Collector），之后 Hub 自动盘点集群上运行的一切，并按命名空间和技术栈整理，团队马上能看到有什么、哪些已插桩、哪些还没有。
配置按“声明意图”的方式进行：用户通过 Grafana Cloud 界面、API 自动化或 LLM 智能体，描述想采集什么、怎么采集，Hub 再把这些选择转成可观测性管道，无需手工配置。官方拿它与传统插桩对比，称后者要获得有意义的覆盖，需要“数月的人工劳动”，每一层都要用各自的方法，步骤还很脆弱。
它的运行是持续的，而非一次性的。团队可以随时按命名空间调整范围，启用或关闭特定信号的采集，以平衡可观测性预算：给出问题的服务临时打开一个配置，排除嘈杂的日志源，在需要压缩开支的地方降低采集量。
无需重启的 SDK 注入
这款产品落地的，是 Grafana 在去年的 ObservabilityCon 上提出的“可观测性需求层级”模型：
| 层级 | 内容 | 操作成本 |
|---|---|---|
| 基础层 | Kubernetes Monitoring，基础设施可见性 | 一键启用 |
| 中间层 | 基线服务可见性：RED 指标与服务关系，填充 Grafana Cloud 的知识图谱，为人和智能体提供上下文 | 自动 |
| 顶层 | 特定技术栈的、事务级深度，通过分布式追踪实现 | 一键选择性部署 OpenTelemetry SDK |
选择性 SDK 注入，作用就在顶层。过去要达到这一层，得安装新的 Operator、部署插桩 CRD、给目标应用加注解，再重启 Pod，一共四个手动步骤，每一步都可能出错。现在 Hub 部署的还是同样的上游 SDK，但不再需要那些额外的环节，也无需造成中断的重启。
Grafana Labs 认为，组织层面的问题让情况更糟：覆盖不均、盲区长期存在，团队还会怀疑这番折腾值不值得。公司称，Instrumentation Hub 建立在基于开放标准的可观测性之上，由 eBPF 和 OTel 注入来完成运维人员原本要手工做的覆盖工作。
这个上线模式贯穿三个层级，从基础设施可见性，到基线服务可见性，再到事务级追踪；无论是启用 Kubernetes Monitoring，还是选择性部署 OpenTelemetry SDK，交互成本都压缩到了一次点击。
对 AI 智能体也想做追踪的团队，可以接着看小编的另一篇：Anthropic 接入 Databricks MLflow，Claude 追踪数据原生导出。
常见问题（FAQ）
Instrumentation Hub 是什么？
Grafana Cloud 里用于远程发现和选择性自动插桩的控制平面，基于 eBPF 与 OpenTelemetry 注入。
怎么开始部署？
在 Kubernetes 集群上运行一条 Helm 命令，安装 Alloy，随后 Hub 会自动编目集群里运行的一切。
注入 SDK 还需要重启 Pod 吗？
据 Grafana Labs 说法，Hub 无需额外的 Operator、CRD 和注解，也避免了造成中断的重启。
能控制采集范围和成本吗？
可以。团队可随时按命名空间调整范围，启用或关闭特定信号的采集，以平衡可观测性预算。