OpenTelemetry 的采用率在过去两年增长很快。但一个随之而来的问题是当你的采集器数量从几个变成几百个分散在不同数据中心、不同 Kubernetes 集群、甚至不同云平台上时怎么统一管理它们这个问题的答案本周由 CNCF 官方博客给出了一个详细介绍。项目叫 OpAMP——开放 Agent 管理协议。它的定位很简单为运行中的遥测 Agent 提供统一的远程管理通道。采集器管理的碎片化问题在 OpAMP 出现之前各团队管理采集器的方式非常随意。OpAMP 的维护者 Andy Keller 在访谈中提到了一段经历他们团队内部至少开发过 3 到 4 套 Agent 管理协议有的是基于 HTTP 长轮询有的是 WebSocket有的是自有协议的通信。每套方案都是针对某个特定场景临时编写的。这种碎片化带来的问题是显而易见的。采集器的配置更新需要逐个登录服务器修改版本升级需要手动替换二进制文件健康监控依赖不同的工具链。当采集器数量达到几十上百的时候这些问题会变成运维的日常负担。OpAMP 解决的问题就是把这些管理功能标准化。它定义了一个通用的通信协议让中心管理端可以远程配置 Agent、推送更新、监控健康状态、收集状态信息。Agent 端只需要实现 OpAMP 客户端就能接入统一管理平台。OpAMP 的架构设计OpAMP 的核心是 Supervisor Agent 的双层架构。Supervisor 是一个独立的进程负责与管理端通信并管理 Agent 生命周期。Agent 本身可以专注于自己的采集任务不需要关心管理逻辑。这种分离设计的好处是明显的。Agent 不需要内置远程管理功能也不需要关心配置格式或者通信协议。所有管理相关的逻辑都在 Supervisor 中实现Agent 只需要接收本地配置变更即可。这意味着即使是 Fluent Bit 这样的非 OpenTelemetry 采集器也可以通过 OpAMP 纳入统一管理。技术上OpAMP 支持 WebSocket 和 HTTP 两种连接方式。WebSocket 适合需要实时推送的场景比如配置热更新、远程控制指令。HTTP 适合网络限制较严格的环境。两种方式都支持 TLS 加密和认证。对于正在大规模部署 OpenTelemetry 的团队来说OpAMP 解决的是一个实际而头疼的问题。很多团队在推广 OpenTelemetry 时最大的阻力不是技术本身而是运维复杂度——一个采集器挂了你不知道配置变了需要手动同步版本在多个环境间不一致。我见过一个团队在生产环境运行着五十多个 OpenTelemetry Collector但没有任何统一的监控面板能确认所有采集器都是正常工作的因为每个集群的部署方式不一样。OpAMP 至少把这些问题纳入了统一管理框架。从开发者视角来看OpAMP 的价值还在于它降低了 OpenTelemetry 的入门门槛。过去要管理大规模采集器集群团队需要自建一套管理平台或者依赖特定云厂商的工具。现在有了标准协议小团队也可以直接使用社区提供的管理工具。这有点像 Kubernetes 对容器编排的影响——标准化之后生态才能快速发展。对于刚开始搭建可观测性平台的团队来说这意味着他们不需要在第一天就解决 Agent 管理问题直接采用 OpAMP 就行了。当然OpAMP 也还在发展中。目前它的核心功能已经稳定但像自动升级、灰度发布等高级管理功能还在路线图上。不过从 CNCF 的重视程度来看——OpAMP 已经在最近的 KubeCon 上有了专门议题——它应该会成为 OpenTelemetry 生态中越来越重要的组件。还有一个值得关注的变化OpAMP 不仅仅用于 OpenTelemetry Collector。它的协议设计是通用的可以管理各类 Agent。这意味着未来你的日志采集器、指标采集器、链路追踪 Agent 可能都通过同一个 OpAMP 管理端来统一运维。对于一个完整的可观测性平台来说这比维护多套管理方案要省心得多。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版