可观测性指标监控云原生【免费下载链接】cadvisorAnalyzes resource usage and performance characteristics of running containers.项目地址https://gitcode.com/gh_mirrors/ca/cadvisor点击查看免费下载cAdvisorContainer Advisor是谷歌开源的容器资源监控组件其 docs/roadmap.md 由 Kubernetes SIG Node 提出2026 年 1 月更新系统性地规划了 cAdvisor 未来几年的走向K8s 侧逐步停止将 cAdvisor 作为内置库 vendoring 进 kubeletstandalone 独立模式则整体迁移至 OpenTelemetry Collector最终进入维护模式直至关闭。本文以该路线图为骨架结合当前仓库的源码、API 文档与运行时选项逐条拆解迁移计划、时间表与每个技术要点的取舍依据帮助读者理解 cAdvisor 的功能边界及其在可观测性生态中的定位演变。路线图定位一份面向未来的战略规划文档路线图文档开篇即声明其状态与性质提案方Kubernetes SIG Node更新日期2026 年 1 月后续步骤先达成 OpenTelemetryOtel社区协议再产出详细迁移计划detailed plans。它并不是一份已经冻结的实施方案而是待讨论的路线草案其直接触发因素是社区持续提出的 cAdvisor standalone 模式新需求——这些需求提醒维护者在 K8s 项目与工具生态都已发生深刻变化的今天有必要为 cAdvisor 明确一个长期方向。一、cAdvisor 的双重身份Kubelet 内置库与独立二进制理解这份路线图的前提是认清 cAdvisor 由两个相互交织的部分组成作为链接进 kubelet 的库向 Kubernetes 提供容器资源使用信息是 K8s 项目资源管理所依赖的关键数据源作为独立二进制供用户监控容器化工作负载覆盖范围不限于 Kubernetes还包括 Docker 容器、Mesos 等场景并支持 Intel PMU perf 等专用硬件指标。这种双重身份在当前仓库的代码结构中可以得到印证。核心抽象定义在 lib/container/container.go 中ContainerType枚举枚举了 cAdvisor 支持的容器来源类型const ( ContainerTypeRaw ContainerType iota ContainerTypeDocker ContainerTypeCrio ContainerTypeContainerd ContainerTypePodman )同时ContainerHandler接口lib/container/container.go定义了所有容器实现必须提供的能力获取ContainerReference、资源隔离规格GetSpec、当前统计值GetStats、子容器列表、进程列表、cgroup 路径、容器标签与 IP 等。各运行时的具体 handler 分布在 lib/container 目录的 docker、containerd、crio、podman、systemd、raw 等子包中。入口程序 cmd/cadvisor.go 通过空导入注册容器 provider、云厂商信息AWS/Azure/GCE与 resctrl 插件再启动 HTTP 服务这体现了 standalone 模式开箱即用的设计一个二进制即可承担全部监控职责。路线图指出这个项目诞生于行业环境完全不同的年代其双重身份今天已成为结构性问题的主要来源。二、为什么要制定路线图三个结构性矛盾路线图将当前困境归结为三点1. 项目归属错位cAdvisor 是 Google 项目而非 Kubernetes 项目但 Google 对项目拥有超比例的所有权与责任同时开源治理模型有限责任与权力并不匹配。2. 维护意愿错位当前实际维护 cAdvisor 的 K8s 贡献者对 standalone 模式的使用场景缺乏切身利益vested interest其投入重心天然偏向 kubelet 集成侧。3. 依赖地狱Kubernetes 每次发布都要把 cAdvisor vendoring 进 k8s 源码树这会带来显著的依赖地狱问题同时也反过来限制了 standalone 模式能做的事情——因为库形态的约束会传导到独立二进制的能力边界上。针对这一点仓库中已有去耦合的铺垫Kubernetes 的 cAdvisor-less, CRI-full Container and Pod Stats 增强提案KEP 2371是去 vendoring 的第一阶段KEP 合并后仍需继续推进机器级指标向 containerd 的迁移。路线图进一步给出两个方向性判断一旦容器指标向容器运行时CRI迁移完成cAdvisor 项目将不再处于 K8s 贡献者范围内而会与 OpenTelemetry 项目更对齐除非 SIG Instrumentation 接手维护否则 cAdvisor 端点kubelet 的cadvisorendpoint将被弃用类似Configurable cAdvisor Metrics Collection这类诉求也不会被接受——因为它们更贴近遥测场景而非编排场景。三、K8s 侧路线图按年度推进的去耦合时间表路线图给出了 K8s 侧清晰的三阶段时间线2026 年完成 Pod 指标向 K8s 的迁移落地 cAdvisor-less, CRI-full Container and Pod StatsKEP 2371启动机器级指标向容器运行时的迁移对应 KEP 待定 TBD决策cadvisor端点去向很可能宣布弃用 kubelet 的cadvisor端点。2027 年停止将 cAdvisor vendoring 进 K8s。2027 年及以后可能远超此时点移除 kubelet 的cadvisor端点。可以看出K8s 侧的策略是先迁移指标、再弃用端点、最后移除代码每一步都以对应 KEP 的推进为前提节奏偏保守。四、cAdvisor standalone 的未来整体迁移到 OpenTelemetry Collector对于 standalone 模式路线图的提案是将场景迁移到 OpenTelemetry Collector新的 receiver 将采集与 cAdvisor 今天采集的类似信息Otel Collector 可配置为以 Prometheus 端点或其他任意受支持的 exporter 导出因此存在一条从 cAdvisor standalone 到 Otel Collector 的过渡路径transition path。与此同时cAdvisor 项目将进入**维护模式maintenance mode**并最终关闭。如果未来有项目或第三方愿意接手并希望将项目移交给 CNCF 或其他组织路线图明确表示会就此展开开放讨论。这里需要强调路线图声称cAdvisor 的分布式分发模式优势不足以使其优于 Otel Collector原因是 Otel Collector 在采集更多场景遥测数据时更灵活且拥有广为人知的配置体系而 cAdvisor 使用的是自定义配置。五、迁移要点一分发模型与配置模式路线图明确说明本节不是迁移到 Otel Collector 的详细规范而是指出编写迁移规范时必须澄清的张力点tension points。分发模型对比维度cAdvisorOtel Collector定位面向容器指标采集的专用软件通用遥测采集器上手难度配置更简单需要按需编译 receiver / exporter 并正确配置资源占用可能更轻量取决于启用的组件配置体系自定义配置行业公认的通用配置模型灵活性聚焦容器监控可覆盖更多遥测场景路线图的判断是cAdvisor 在分发模型上的收益简单、轻量不足以让它在这场比较中胜出因此倾向整体迁移。六、迁移要点二指标体系路线图建议将所有指标迁移到 Otel Collector以保证经过时间检验的指标集合能够平滑迁移但最终决策仍需详细计划支撑。设计中允许将指标拆分为多个 receiver如果这样更便于实现和维护。作为背景参考当前 cAdvisor 暴露的指标体系非常庞大详见 docs/storage/prometheus.md容器指标container 系列涵盖 CPUcontainer_cpu_usage_seconds_total、CFS 周期与节流统计、内存container_memory_usage_bytes、container_memory_working_set_bytes、hugepage、NUMA 页、磁盘与 IOcontainer_fs_*、blkio 设备用量、网络收发字节/包/错误/丢弃、TCP/UDP 连接、进程与文件描述符、perf 事件、resctrlLLC 占用与内存带宽、OOM 事件等硬件指标machine 系列CPU 核数、内存、swap、NUMA 拓扑machine_node_*、machine_cpu_cache_capacity_bytes、DIMM 容量依赖内核 3.6 的 sysfs edac 接口、NVM 持久内存需 libipmctl 构建等。这些指标的开关由--disable_metrics/--enable_metrics参数控制完整参数说明见 docs/runtime_options.md迁移时需逐一映射到对应的 Otel receiver。文档也提示Prometheus 端点上的指标命名偏好用下划线而 Otel 倾向于点号且指标名会向 Otel Semantic Convention 对齐因此改名rename是迁移中不可避免的工作。七、迁移要点三端点分析路线图指出除 Prometheus 指标外cAdvisor 还支持若干端点完整清单见 docs/api.md迁移时必须逐项处理。7.1 Prometheus 端点cAdvisor 默认在/metrics端点暴露 Prometheus 指标注册逻辑见 cmd/internal/http/handlers.go 的RegisterPrometheusHandler该端点可通过-prometheus_endpoint、-disable_metrics、-enable_metrics等 flag 自定义。迁移到 Otel Collector 后的关键变化命名格式差异Prometheus 端点可能以不同于 Otel 偏好的格式暴露指标Otel 偏好下划线命名而非点号其他改名也可能发生因为指标名要与 Otel Semantic Convention 对齐单端点聚合Otel Collector 将暴露单一 Prometheus 端点包含所有容器、所有指标不再支持容器专属端点cAdvisor 现有的按容器维度的应用指标访问方式将不再提供。这类端点目前定义在 docs/application_metrics.md 中例如http://localhost:8080/api/v2.0/appmetrics/containerName http://localhost:8080/api/v2.0/spec/containerName http://localhost:8080/api/v2.0/stats/containerName应用指标application metrics是 cAdvisor 的独立能力通过容器 labelio.cadvisor.metric.*声明配置从容器内端点采集自定义指标如 nginx_status、Prometheus 格式端点配置样例同样见 docs/application_metrics.md。7.2 Events 端点路线图建议将事件作为Otel events采集但指出一个关键设计冲突Otel Collector 中没有与 events 端点对应的现成机制因此消费方需要从拉取模型pull改为推送模型push。cAdvisor 当前的 events 端点定义在 docs/api.md 中/api/v1.3/events/absolute container name支持如下查询参数参数说明默认值start_time查询事件起始时间streamfalse 时时间起点end_time查询事件结束时间streamfalse 时当前时刻stream是否流式推送新事件false 返回历史事件falsesubcontainers是否同时返回所有子容器的事件falsemax_events返回的最大事件数streamfalse 时10all_events是否包含所有支持的事件类型falseoom_events是否包含 OOM 事件falseoom_kill_events是否包含 OOM kill 事件falsecreation_events是否包含容器创建事件falsedeletion_events是否包含容器删除事件false事件的序列化对象定义在 info/v1/container.goEventJSON 对象。拉取到推送的转变意味着下游消费端架构需要重新设计。7.3 其余端点不支持与替代方案端点/能力迁移方案docker/api/v1.2/docker/...不支持无替代方案subcontainers/api/v1.1/subcontainers/...不支持无替代方案containers/api/v1.0/containers/...不支持无替代方案machine/api/vX.Y/machine不支持改用 Node Feature Discovery这些端点目前的行为在 docs/api.md 中有完整描述例如/api/v1.0/containers/返回容器规格、最近 N 秒N 在 cAdvisor 中全局可配置的详细资源统计以及自容器创建以来的资源使用直方图machine 端点返回逻辑 CPU 核数、内存容量、最大 CPU 频率、可用文件系统、网络设备以及 NUMA 拓扑对应MachineInfo结构体见 info/v1/machine.go。迁移后这些数据要么由 Otel Collector 的通用机制覆盖要么由 Node Feature Discovery 等专门组件承接cAdvisor 专属的 REST 语义将消失。八、迁移要点四运行时与操作系统支持8.1 运行时路线图建议将基于容器的指标采集迁移到 Otel Collector使 Otel Collector 支持与 cAdvisor 今天相同的一套环境与运行时——实现方式可以是直接从 cAdvisor 拷贝代码。cAdvisor 当前支持的运行时即 lib/container/container.go 中枚举的 raw、docker、crio、containerd、podman另有 systemd 支持各运行时均有对应的 handler、factory 与 fs 实现目录。同时路线图提出一个更轻量的替代实现基于 KEP 2371cAdvisor-less, CRI-full Container and Pod Stats中CRI 暴露的指标来实现 receiver。这种方案的权衡是更不灵活局限于 Kubernetes 场景更可靠不依赖直接访问容器运行时内部机制。最终提案是按完整场景集设计但不排斥 CRI-based 指标 receiver 的实现即全量设计、灵活实现。8.2 操作系统这里有一个明确的现状声明cAdvisor 不支持 Windows 容器监控而 Otel Collector 支持。Otel Collector 存在实现 Windows 容器监控场景的潜力但这属于本路线图文档范围之外的事项。换言之Windows 容器监控是迁移到 Otel Collector 后可能新增的能力而不是 cAdvisor 现有能力的平移。九、总结对使用者的启示综合整份路线图可以提炼出如下关键结论kubelet 集成侧Pod 指标先完成向 CRI/容器运行时的迁移KEP 2371随后机器级指标跟进2027 年停止 vendoring最终移除cadvisor端点依赖 cAdvisor 提供的 kubelet 指标的用户应关注对应 KEP 的演进。standalone 侧cAdvisor 单机监控场景的既定方向是迁移到 OpenTelemetry Collector——通过新 receiver 承接采集、以 Prometheus 或其他 exporter 输出形成平滑过渡路径迁移过程中指标命名将向 Otel Semantic Convention 对齐事件消费模型将从拉取改为推送。功能落差需要提前评估docker、subcontainers、containers 端点迁移后没有直接替代machine 端点改用 Node Feature Discovery容器专属的应用指标端点见 docs/application_metrics.md将让位于单一 Prometheus 端点。项目终局cAdvisor 将进入维护模式并最终关闭但前提讨论Otel 社区协议、详细迁移计划仍在进行中且不排除第三方接手并移交 CNCF 的可能。对仍在生产环境使用 cAdvisor standalone 的团队而言这份路线图的现实意义在于提前盘点自身依赖的端点与指标对照 docs/api.md 与 docs/storage/prometheus.md规划到 Otel Collector 的迁移路径并密切跟踪 KEP 2371 及后续机器级指标迁移 KEP 的进展以决定何时切换、如何切换。赞分享可观测性指标监控云原生【免费下载链接】cadvisorAnalyzes resource usage and performance characteristics of running containers.项目地址https://gitcode.com/gh_mirrors/ca/cadvisor点击查看免费下载相关推荐OpenTelemetry Collector Go API Changelog 深度解读组件开发者 API 演进与迁移指南OpenTelemetry Collector Go API Changelog 深度解读组件开发者 API 演进与迁移指南 OpenTelemetry Co可观测性后端运维观测Kubernetes 项目基础设施迁移实录SIG K8s Infra 2020 年度报告解读与 CNCF 迁移路线图Kubernetes 项目基础设施迁移实录SIG K8s Infra 2020 年度报告解读与 CNCF 迁移路线图 本文基于 SIG K8s Infra 2开源治理文档研发协作Flutter 2026 路线图深度解读Impeller 迁移、Wasm 默认化与 GenUI/Agentic 开发范式演进Flutter 2026 路线图深度解读Impeller 迁移、Wasm 默认化与 GenUI/Agentic 开发范式演进 Flutter 官方每年会在 d跨平台移动开发前端UI组件桌面应用上一篇Dagster 如何用 dagster/priority 标签自定义运行队列优先级下一篇fheroes2重燃英雄无敌II经典传奇的现代游戏引擎 创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考