cAdvisor 应用指标Application Metrics采集完全指南配置、容器标签发现与 API 使用【免费下载链接】cadvisorAnalyzes resource usage and performance characteristics of running containers.项目地址: https://gitcode.com/gh_mirrors/ca/cadvisorcAdvisor 不仅采集 CPU、内存等资源使用指标还支持通过统一的应用指标Application Metrics机制从运行中的容器内部主动抓取业务层面的自定义指标如 Nginx 连接数、Prometheus 暴露的服务指标等。本文以 docs/application_metrics.md 为主线结合仓库内 collector 包与 cmd/internal/appmetrics 包的源码实现系统讲解应用指标配置文件的编写规范、通过 Docker 标签把配置注入容器的机制、采集器在底层的调度与解析原理以及通过 API 读取应用指标的完整方法帮助你为任意容器快速接入自定义业务指标的采集与展示。注意原文提示应用指标支持目前仍处于 Alpha 阶段接口仍在持续演进中。文档原文明确标注了这一点使用前请确认你所用 cAdvisor 版本的行为与本文描述一致。一、应用指标是什么在资源指标之外的业务数据采集除了 CPU、内存、网络、文件系统等资源使用情况指标外cAdvisor 还可以配置采集应用指标。一个容器可以通过多种方式暴露应用指标一个纯文本状态页如 Nginx 的/nginx_status结构化指标接口如 Prometheus 的/metrics端点一个独立的统计查询 API。cAdvisor 为这些场景提供了一套通用采集框架你只需要告诉它指标从哪里来、怎么解析剩下的轮询、解析、存储、导出到 UI 与各类后端都由 cAdvisor 完成。对于业界常见且接口稳定的采集模式如 Prometheus 文本格式仓库还提供了专门的模板化采集器让配置可以极度精简。从源码结构看这套机制由仓库根目录的 collector 包实现collector/config.go配置文件 JSON 的结构定义与反序列化collector/generic_collector.go基于正则解析的通用采集器GenericCollectorcollector/prometheus_collector.goPrometheus 文本格式采集器PrometheusCollectorcollector/collector_manager.go采集器管理器负责按调度时间驱动各采集器cmd/internal/appmetrics/appmetrics.go在完整 cAdvisor 二进制中装配采集器管理器的入口。二、配置文件编写规范告诉 cAdvisor去哪里采、采什么应用指标配置的启用分为两步创建配置文件把配置文件位置传递给 cAdvisor见下一节标签发现。2.1 配置的核心字段一个应用指标配置文件告诉 cAdvisor 去哪里采集应用指标以及如何把这些指标导出到 UI 和后端。配置由以下要素组成字段含义Endpoint采集指标的地址URLName指标名称Type指标类型Counter、Gauge 等Data Type数据类型int、floatUnits单位kbps、seconds、count 等Polling Frequency轮询频率Regexps正则表达式指定采集哪些指标以及如何解析这些字段与源码中的结构体一一对应。在 collector/config.go 中Config结构体由Endpoint和MetricsConfig一组MetricConfig组成MetricConfig.Name指标名MetricConfig.MetricType指标类型枚举。取值定义在 info/v1/metric.gogauge瞬时值可增可减与cumulative计数器类预期只增不减MetricConfig.Units指标单位仅用于 UI 和存储展示MetricConfig.DataType数据类型int或floatMetricConfig.PollingFrequency该指标的采集频率秒MetricConfig.Regex用于从响应文本中提取指标值的正则表达式。Endpoint 的两种写法值得特别注意对应 collector/config.go 的EndpointConfig完整 URL 字符串直接写死完整地址如endpoint: http://localhost:8000/nginx_statusURL 配置对象只写protocol、port、path由 cAdvisor 用容器自身的 IP 地址拼接出实际 URL实现见 collector/util.go 的EndpointConfig.configure。UnmarshalJSON中默认协议为http、默认端口为8000在反序列化时若字符串不是合法 URL 则会尝试按 URLConfig 解析。2.2 示例一无结构化信息的通用文本采集Nginx 状态页对于没有任何结构化信息的纯文本接口必须给出完整的metrics_config。文档给出了 Nginx 状态页的通用采集配置{ endpoint : http://localhost:8000/nginx_status, metrics_config : [ { name : activeConnections, metric_type : gauge, units : number of active connections, data_type : int, polling_frequency : 10, regex : Active connections: ([0-9]) }, { name : reading, metric_type : gauge, units : number of reading connections, data_type : int, polling_frequency : 10, regex : Reading: ([0-9]) .* } ] }仓库 collector/config/sample_config.json 提供了该场景的更完整版本在 reading 之外还采集了 writing 与 waiting 两个指标可供直接参考{ endpoint : http://localhost:8000/nginx_status, metrics_config : [ { name : activeConnections, metric_type : gauge, units : number of active connections, data_type : int, polling_frequency : 10, regex : Active connections: ([0-9]) }, { name : reading, metric_type : gauge, units : number of reading connections, data_type : int, polling_frequency : 10, regex : Reading: ([0-9]) .* }, { name : writing, metric_type : gauge, data_type : int, units : number of writing connections, polling_frequency : 10, regex : .*Writing: ([0-9]).* }, { name : waiting, metric_type : gauge, units : number of waiting connections, data_type : int, polling_frequency : 10, regex : .*Waiting: ([0-9]) } ] }正则解析的底层行为见 collector/generic_collector.go采集时 cAdvisor 用 HTTP GET 拉取 endpoint 内容对每条regex执行FindStringSubmatch取第一个捕获组matchString[1]作为指标值按data_type分别用strconv.ParseIntint或strconv.ParseFloatfloat解析并去掉首尾空白。因此正则务必包含且仅包含一个你需要的捕获组。若某一指标的正则没有匹配到内容或数据类型不合法该指标的采集会被记录为错误但不会中断其他指标的采集。2.3 示例二Prometheus 结构化端点——配置可以精简到只剩 endpoint对于 Prometheus 这类结构化指标端点指标名、类型、单位等信息都可以从暴露内容中直接解析因此配置可以大幅精简。文档给出了两种 Prometheus 配置全量采集所有指标——只写端点即可{ endpoint : http://localhost:9100/metrics }只采集指定指标子集——用字符串数组列出指标名{ endpoint : http://localhost:8000/metrics, metrics_config : [ scheduler_binding_latency, scheduler_e2e_scheduling_latency, scheduling_algorithm_latency ] }Prometheus 采集器的结构体见 collector/config.go 的Prometheus还额外支持顶层polling_frequency字段秒用于覆盖默认轮询频率。仓库 collector/config/sample_config_prometheus.json 给出了一个同时设置端点与polling_frequency : 10、metrics_config为空的示例此外 collector/config 目录下还提供了sample_config_endpoint_config.json基于容器 IP 拼接 URL 的写法与sample_config_prometheus_filtered.jsonPrometheus 指标过滤写法等更多变体可供参考。Prometheus 采集器的底层实现collector/prometheus_collector.go说明如下类型映射metricType见第 153-162 行Prometheus 的COUNTER映射为 cAdvisor 的cumulativeGAUGE映射为gauge其他类型直接沿用 Prometheus 类型名指标过滤MetricsConfig会被转成map[string]bool集合采集时见第 244-275 行Collect跳过不在集合中的指标集合为空时采集全部标签处理Prometheus 指标的多维标签被序列化为单字符串Label如namevalue排序拼接与结构化Labels映射写入MetricValHTTP 校验仅当响应状态码为200 OK时才解析指标见第 227-229 行。2.4 两类采集器的自动选择在 cmd/internal/appmetrics/appmetrics.go 的NewManager中cAdvisor 依据标签名自动决定使用哪类采集器标签名以prometheus开头不区分大小写则创建NewPrometheusCollector否则创建通用的NewCollector。也就是说配置文件里的 endpoint 是 Prometheus 端点时应让对应标签以prometheus前缀命名下文标签发现会再提到。2.5 采集频率与数量的硬性限制无论哪类采集器都存在两个由源码确认的约束最小轮询频率为 1 秒在 collector/generic_collector.go 与 collector/prometheus_collector.go 中minSupportedFrequency 1 * time.Second任何小于 1s 的配置都会被钳制到 1s。通用采集器还会取所有指标polling_frequency的最小值作为实际采集间隔没有填写的指标按 0 处理不参与取小这保证每个指标的采集都不晚于其自身要求指标数量上限采集器会校验MetricsConfig数量与metricCountLimit对应启动参数collector_metric_count_limit相关机制超出限制会报错Prometheus 采集过程中若抓到的指标数量超过该限制也会中止本次采集并返回 too many metrics to collect。三、把配置交给 cAdvisor基于 Docker 标签的发现机制3.1 标签命名规则cAdvisor 通过容器的 Docker 标签label来发现应用指标配置。规则如下任何以io.cadvisor.metric.前缀开头的标签都会被解析为 cAdvisor 的应用指标标签标签值就是配置文件的路径在容器内的路径cAdvisor 会在运行时进入容器读取该文件形如io.cadvisor.metric.prometheus-xyz的标签名表示该配置指向一个 Prometheus 指标端点。该前缀常量定义在 collector/collector_manager.goconst metricLabelPrefix io.cadvisor.metric.GetCollectorConfigs遍历容器标签剥离前缀后得到采集器名 → 配置路径的映射。3.2 配置文件的两种放置方式配置文件既可以打进容器镜像也可以在运行时通过 volume 挂载进容器。这保证了应用指标配置与宿主机完全解耦——容器对自身的指标信息是自包含的原文原意运维在任意宿主机上运行该容器都能得到一致的指标采集行为。文档给出的 Redis 示例Dockerfile 或运行时均可FROM redis ADD redis_config.json /var/cadvisor/redis_config.json LABEL io.cadvisor.metric.redis/var/cadvisor/redis_config.json其中标签名io.cadvisor.metric.redis的采集器名是redis标签值指向镜像内的/var/cadvisor/redis_config.json。cAdvisor 启动后会在容器运行时读入该配置创建采集器并开始轮询与暴露这些应用指标。3.3 配置读取与采集器装配的源码链路从 cmd/internal/appmetrics/appmetrics.go 的NewManager可以看到完整的装配过程通过handler.GetContainerLabels()取得容器标签调用collector.GetCollectorConfigs过滤出io.cadvisor.metric.前缀的标签得到名称 → 配置路径映射对每个配置路径调用readFile由调用方注入用于从容器内部读取文件按标签名是否以prometheus开头分别调用NewPrometheusCollector或NewCollector解析配置文件通过cm.RegisterCollector注册到CollectorManager之后由管理器按各自的nextCollectionTime统一调度采集见 collector/collector_manager.go 的Collect到期的采集器才会执行并推算出下一次采集时间。3.4 采集端点的 HTTP/TLS 行为cAdvisor 抓取应用指标时使用进程级共享的 HTTP 客户端cmd/internal/appmetrics/appmetrics.go默认配置InsecureSkipVerify: true接受任意 TLS 证书——因为容器内的采集端点常常是自签名证书可通过启动参数--collector_cert与--collector_key配置客户端证书mTLS在 cmd/cadvisor.go 中定义并在启动早期第 136-139 行调用appmetrics.SetHTTPClient(*collectorCert, *collectorKey)完成配置若只设置了 cert 而未设置 key或证书加载失败进程会直接klog.Fatal退出校验策略与上游一致。四、通过 API 访问应用指标为采集指定容器的应用指标cAdvisor 在 API v2.0 中新增了一个端点http://localhost:8080/api/v2.0/appmetrics/containerName其中containerName是容器名默认typename的 id 类型也可以按 docker/podman 方式查询对应typedocker与typepodman。从源码看该端点由 cmd/internal/api/versions.go 中customMetricsAPI appmetrics第 45 行对应的处理逻辑实现它调用GetContainerInfoV2获取容器信息遍历各条统计记录中的CustomMetrics输出结构为容器 → 指标名 → 标签 → 值列表的嵌套映射每个值为MetricValBasic时间戳 IntValue/FloatValue。同时可以配合以下端点获取元数据与完整统计获取指标定义spec通过容器 spec 可以发现当前正在采集哪些应用指标http://localhost:8080/api/v2.0/spec/containerName普通统计 API 中也携带应用指标应用指标会被追加到常规的 stats 接口返回中http://localhost:8080/api/v2.0/stats/containerName在 cmd/internal/api/versions.go 的 stats 处理中容器统计经DeprecatedStatsFromV1转换其CustomMetrics字段即来自采集器上报的应用指标。API 请求还支持通用查询参数见GetRequestOptions第 537-578 行typename/docker/podman默认 name、count采样条数默认 64-1 表示全部、recursive是否递归子容器、max_age最大历史时间窗口如1m。五、UI 展示启用应用指标后它们会显示在容器详情页container page资源指标之后的位置与资源使用情况一同呈现便于在 Web 界面上一眼看到业务指标的变化趋势。六、正在进行的开发方向Roadmap文档末尾列出了应用指标功能正在进行的后续工作可以从中了解该功能的演进方向6.1 预置模板Templates下一步计划为统计 API 稳定的知名容器提供预置采集模板。模板通过一个新的标签io.cadvisor.metric.type指定如果标签值是一个已知类型cAdvisor 将自动开始采集无需任何额外配置此时配置仍可用于覆盖具体参数例如指定要采集的指标子集。这可以进一步把接入常见中间件指标的成本降到零。6.2 UI 增强UI 方面有一系列增强计划更好地处理与展示指标——例如允许在同一张图上叠加多条指标支持百分位数等特殊指标类型把应用指标移动到独立的标签页增加控制项UI 上只显示选中的指标但 API 仍导出全部指标。七、快速上手指引与参考路径一个完整的接入流程可以归纳为编写 JSON 配置文件通用文本格式见 collector/config/sample_config.jsonPrometheus 全量格式见 collector/config/sample_config_prometheus.json更多变体见 collector/config 目录将文件打进镜像或用 volume 挂载进容器为容器设置形如io.cadvisor.metric.name容器内配置路径的标签Prometheus 端点请使用io.cadvisor.metric.prometheus-name形式启动 cAdvisor 容器并挂载 Docker socket 与相关 cgroup/sysfs 目录让其能发现并进入容器读取配置通过http://localhost:8080/api/v2.0/appmetrics/containerName验证采集结果并在容器页面查看指标曲线。关于 Docker 1.8 的兼容性提示原文明确指出cAdvisor 是专门从容器标签提取上述信息的。在 Docker 1.8 中容器不会继承镜像的标签因此必须在运行时docker run/ Dockerfile 的 RUN 阶段之外显式指定标签。进一步深入源码可以参考配置结构定义collector/config.go通用正则采集器collector/generic_collector.goPrometheus 采集器collector/prometheus_collector.go采集器管理器与标签前缀collector/collector_manager.go采集器接口定义collector/types.go装配入口与 mTLS 配置cmd/internal/appmetrics/appmetrics.go、cmd/cadvisor.goAPI 端点实现cmd/internal/api/versions.go指标类型与数据类型定义info/v1/metric.go【免费下载链接】cadvisorAnalyzes resource usage and performance characteristics of running containers.项目地址: https://gitcode.com/gh_mirrors/ca/cadvisor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
cAdvisor 应用指标（Application Metrics）采集完全指南：配置、容器标签发现与 API 使用
cAdvisor 应用指标Application Metrics采集完全指南配置、容器标签发现与 API 使用【免费下载链接】cadvisorAnalyzes resource usage and performance characteristics of running containers.项目地址: https://gitcode.com/gh_mirrors/ca/cadvisorcAdvisor 不仅采集 CPU、内存等资源使用指标还支持通过统一的应用指标Application Metrics机制从运行中的容器内部主动抓取业务层面的自定义指标如 Nginx 连接数、Prometheus 暴露的服务指标等。本文以 docs/application_metrics.md 为主线结合仓库内 collector 包与 cmd/internal/appmetrics 包的源码实现系统讲解应用指标配置文件的编写规范、通过 Docker 标签把配置注入容器的机制、采集器在底层的调度与解析原理以及通过 API 读取应用指标的完整方法帮助你为任意容器快速接入自定义业务指标的采集与展示。注意原文提示应用指标支持目前仍处于 Alpha 阶段接口仍在持续演进中。文档原文明确标注了这一点使用前请确认你所用 cAdvisor 版本的行为与本文描述一致。一、应用指标是什么在资源指标之外的业务数据采集除了 CPU、内存、网络、文件系统等资源使用情况指标外cAdvisor 还可以配置采集应用指标。一个容器可以通过多种方式暴露应用指标一个纯文本状态页如 Nginx 的/nginx_status结构化指标接口如 Prometheus 的/metrics端点一个独立的统计查询 API。cAdvisor 为这些场景提供了一套通用采集框架你只需要告诉它指标从哪里来、怎么解析剩下的轮询、解析、存储、导出到 UI 与各类后端都由 cAdvisor 完成。对于业界常见且接口稳定的采集模式如 Prometheus 文本格式仓库还提供了专门的模板化采集器让配置可以极度精简。从源码结构看这套机制由仓库根目录的 collector 包实现collector/config.go配置文件 JSON 的结构定义与反序列化collector/generic_collector.go基于正则解析的通用采集器GenericCollectorcollector/prometheus_collector.goPrometheus 文本格式采集器PrometheusCollectorcollector/collector_manager.go采集器管理器负责按调度时间驱动各采集器cmd/internal/appmetrics/appmetrics.go在完整 cAdvisor 二进制中装配采集器管理器的入口。二、配置文件编写规范告诉 cAdvisor去哪里采、采什么应用指标配置的启用分为两步创建配置文件把配置文件位置传递给 cAdvisor见下一节标签发现。2.1 配置的核心字段一个应用指标配置文件告诉 cAdvisor 去哪里采集应用指标以及如何把这些指标导出到 UI 和后端。配置由以下要素组成字段含义Endpoint采集指标的地址URLName指标名称Type指标类型Counter、Gauge 等Data Type数据类型int、floatUnits单位kbps、seconds、count 等Polling Frequency轮询频率Regexps正则表达式指定采集哪些指标以及如何解析这些字段与源码中的结构体一一对应。在 collector/config.go 中Config结构体由Endpoint和MetricsConfig一组MetricConfig组成MetricConfig.Name指标名MetricConfig.MetricType指标类型枚举。取值定义在 info/v1/metric.gogauge瞬时值可增可减与cumulative计数器类预期只增不减MetricConfig.Units指标单位仅用于 UI 和存储展示MetricConfig.DataType数据类型int或floatMetricConfig.PollingFrequency该指标的采集频率秒MetricConfig.Regex用于从响应文本中提取指标值的正则表达式。Endpoint 的两种写法值得特别注意对应 collector/config.go 的EndpointConfig完整 URL 字符串直接写死完整地址如endpoint: http://localhost:8000/nginx_statusURL 配置对象只写protocol、port、path由 cAdvisor 用容器自身的 IP 地址拼接出实际 URL实现见 collector/util.go 的EndpointConfig.configure。UnmarshalJSON中默认协议为http、默认端口为8000在反序列化时若字符串不是合法 URL 则会尝试按 URLConfig 解析。2.2 示例一无结构化信息的通用文本采集Nginx 状态页对于没有任何结构化信息的纯文本接口必须给出完整的metrics_config。文档给出了 Nginx 状态页的通用采集配置{ endpoint : http://localhost:8000/nginx_status, metrics_config : [ { name : activeConnections, metric_type : gauge, units : number of active connections, data_type : int, polling_frequency : 10, regex : Active connections: ([0-9]) }, { name : reading, metric_type : gauge, units : number of reading connections, data_type : int, polling_frequency : 10, regex : Reading: ([0-9]) .* } ] }仓库 collector/config/sample_config.json 提供了该场景的更完整版本在 reading 之外还采集了 writing 与 waiting 两个指标可供直接参考{ endpoint : http://localhost:8000/nginx_status, metrics_config : [ { name : activeConnections, metric_type : gauge, units : number of active connections, data_type : int, polling_frequency : 10, regex : Active connections: ([0-9]) }, { name : reading, metric_type : gauge, units : number of reading connections, data_type : int, polling_frequency : 10, regex : Reading: ([0-9]) .* }, { name : writing, metric_type : gauge, data_type : int, units : number of writing connections, polling_frequency : 10, regex : .*Writing: ([0-9]).* }, { name : waiting, metric_type : gauge, units : number of waiting connections, data_type : int, polling_frequency : 10, regex : .*Waiting: ([0-9]) } ] }正则解析的底层行为见 collector/generic_collector.go采集时 cAdvisor 用 HTTP GET 拉取 endpoint 内容对每条regex执行FindStringSubmatch取第一个捕获组matchString[1]作为指标值按data_type分别用strconv.ParseIntint或strconv.ParseFloatfloat解析并去掉首尾空白。因此正则务必包含且仅包含一个你需要的捕获组。若某一指标的正则没有匹配到内容或数据类型不合法该指标的采集会被记录为错误但不会中断其他指标的采集。2.3 示例二Prometheus 结构化端点——配置可以精简到只剩 endpoint对于 Prometheus 这类结构化指标端点指标名、类型、单位等信息都可以从暴露内容中直接解析因此配置可以大幅精简。文档给出了两种 Prometheus 配置全量采集所有指标——只写端点即可{ endpoint : http://localhost:9100/metrics }只采集指定指标子集——用字符串数组列出指标名{ endpoint : http://localhost:8000/metrics, metrics_config : [ scheduler_binding_latency, scheduler_e2e_scheduling_latency, scheduling_algorithm_latency ] }Prometheus 采集器的结构体见 collector/config.go 的Prometheus还额外支持顶层polling_frequency字段秒用于覆盖默认轮询频率。仓库 collector/config/sample_config_prometheus.json 给出了一个同时设置端点与polling_frequency : 10、metrics_config为空的示例此外 collector/config 目录下还提供了sample_config_endpoint_config.json基于容器 IP 拼接 URL 的写法与sample_config_prometheus_filtered.jsonPrometheus 指标过滤写法等更多变体可供参考。Prometheus 采集器的底层实现collector/prometheus_collector.go说明如下类型映射metricType见第 153-162 行Prometheus 的COUNTER映射为 cAdvisor 的cumulativeGAUGE映射为gauge其他类型直接沿用 Prometheus 类型名指标过滤MetricsConfig会被转成map[string]bool集合采集时见第 244-275 行Collect跳过不在集合中的指标集合为空时采集全部标签处理Prometheus 指标的多维标签被序列化为单字符串Label如namevalue排序拼接与结构化Labels映射写入MetricValHTTP 校验仅当响应状态码为200 OK时才解析指标见第 227-229 行。2.4 两类采集器的自动选择在 cmd/internal/appmetrics/appmetrics.go 的NewManager中cAdvisor 依据标签名自动决定使用哪类采集器标签名以prometheus开头不区分大小写则创建NewPrometheusCollector否则创建通用的NewCollector。也就是说配置文件里的 endpoint 是 Prometheus 端点时应让对应标签以prometheus前缀命名下文标签发现会再提到。2.5 采集频率与数量的硬性限制无论哪类采集器都存在两个由源码确认的约束最小轮询频率为 1 秒在 collector/generic_collector.go 与 collector/prometheus_collector.go 中minSupportedFrequency 1 * time.Second任何小于 1s 的配置都会被钳制到 1s。通用采集器还会取所有指标polling_frequency的最小值作为实际采集间隔没有填写的指标按 0 处理不参与取小这保证每个指标的采集都不晚于其自身要求指标数量上限采集器会校验MetricsConfig数量与metricCountLimit对应启动参数collector_metric_count_limit相关机制超出限制会报错Prometheus 采集过程中若抓到的指标数量超过该限制也会中止本次采集并返回 too many metrics to collect。三、把配置交给 cAdvisor基于 Docker 标签的发现机制3.1 标签命名规则cAdvisor 通过容器的 Docker 标签label来发现应用指标配置。规则如下任何以io.cadvisor.metric.前缀开头的标签都会被解析为 cAdvisor 的应用指标标签标签值就是配置文件的路径在容器内的路径cAdvisor 会在运行时进入容器读取该文件形如io.cadvisor.metric.prometheus-xyz的标签名表示该配置指向一个 Prometheus 指标端点。该前缀常量定义在 collector/collector_manager.goconst metricLabelPrefix io.cadvisor.metric.GetCollectorConfigs遍历容器标签剥离前缀后得到采集器名 → 配置路径的映射。3.2 配置文件的两种放置方式配置文件既可以打进容器镜像也可以在运行时通过 volume 挂载进容器。这保证了应用指标配置与宿主机完全解耦——容器对自身的指标信息是自包含的原文原意运维在任意宿主机上运行该容器都能得到一致的指标采集行为。文档给出的 Redis 示例Dockerfile 或运行时均可FROM redis ADD redis_config.json /var/cadvisor/redis_config.json LABEL io.cadvisor.metric.redis/var/cadvisor/redis_config.json其中标签名io.cadvisor.metric.redis的采集器名是redis标签值指向镜像内的/var/cadvisor/redis_config.json。cAdvisor 启动后会在容器运行时读入该配置创建采集器并开始轮询与暴露这些应用指标。3.3 配置读取与采集器装配的源码链路从 cmd/internal/appmetrics/appmetrics.go 的NewManager可以看到完整的装配过程通过handler.GetContainerLabels()取得容器标签调用collector.GetCollectorConfigs过滤出io.cadvisor.metric.前缀的标签得到名称 → 配置路径映射对每个配置路径调用readFile由调用方注入用于从容器内部读取文件按标签名是否以prometheus开头分别调用NewPrometheusCollector或NewCollector解析配置文件通过cm.RegisterCollector注册到CollectorManager之后由管理器按各自的nextCollectionTime统一调度采集见 collector/collector_manager.go 的Collect到期的采集器才会执行并推算出下一次采集时间。3.4 采集端点的 HTTP/TLS 行为cAdvisor 抓取应用指标时使用进程级共享的 HTTP 客户端cmd/internal/appmetrics/appmetrics.go默认配置InsecureSkipVerify: true接受任意 TLS 证书——因为容器内的采集端点常常是自签名证书可通过启动参数--collector_cert与--collector_key配置客户端证书mTLS在 cmd/cadvisor.go 中定义并在启动早期第 136-139 行调用appmetrics.SetHTTPClient(*collectorCert, *collectorKey)完成配置若只设置了 cert 而未设置 key或证书加载失败进程会直接klog.Fatal退出校验策略与上游一致。四、通过 API 访问应用指标为采集指定容器的应用指标cAdvisor 在 API v2.0 中新增了一个端点http://localhost:8080/api/v2.0/appmetrics/containerName其中containerName是容器名默认typename的 id 类型也可以按 docker/podman 方式查询对应typedocker与typepodman。从源码看该端点由 cmd/internal/api/versions.go 中customMetricsAPI appmetrics第 45 行对应的处理逻辑实现它调用GetContainerInfoV2获取容器信息遍历各条统计记录中的CustomMetrics输出结构为容器 → 指标名 → 标签 → 值列表的嵌套映射每个值为MetricValBasic时间戳 IntValue/FloatValue。同时可以配合以下端点获取元数据与完整统计获取指标定义spec通过容器 spec 可以发现当前正在采集哪些应用指标http://localhost:8080/api/v2.0/spec/containerName普通统计 API 中也携带应用指标应用指标会被追加到常规的 stats 接口返回中http://localhost:8080/api/v2.0/stats/containerName在 cmd/internal/api/versions.go 的 stats 处理中容器统计经DeprecatedStatsFromV1转换其CustomMetrics字段即来自采集器上报的应用指标。API 请求还支持通用查询参数见GetRequestOptions第 537-578 行typename/docker/podman默认 name、count采样条数默认 64-1 表示全部、recursive是否递归子容器、max_age最大历史时间窗口如1m。五、UI 展示启用应用指标后它们会显示在容器详情页container page资源指标之后的位置与资源使用情况一同呈现便于在 Web 界面上一眼看到业务指标的变化趋势。六、正在进行的开发方向Roadmap文档末尾列出了应用指标功能正在进行的后续工作可以从中了解该功能的演进方向6.1 预置模板Templates下一步计划为统计 API 稳定的知名容器提供预置采集模板。模板通过一个新的标签io.cadvisor.metric.type指定如果标签值是一个已知类型cAdvisor 将自动开始采集无需任何额外配置此时配置仍可用于覆盖具体参数例如指定要采集的指标子集。这可以进一步把接入常见中间件指标的成本降到零。6.2 UI 增强UI 方面有一系列增强计划更好地处理与展示指标——例如允许在同一张图上叠加多条指标支持百分位数等特殊指标类型把应用指标移动到独立的标签页增加控制项UI 上只显示选中的指标但 API 仍导出全部指标。七、快速上手指引与参考路径一个完整的接入流程可以归纳为编写 JSON 配置文件通用文本格式见 collector/config/sample_config.jsonPrometheus 全量格式见 collector/config/sample_config_prometheus.json更多变体见 collector/config 目录将文件打进镜像或用 volume 挂载进容器为容器设置形如io.cadvisor.metric.name容器内配置路径的标签Prometheus 端点请使用io.cadvisor.metric.prometheus-name形式启动 cAdvisor 容器并挂载 Docker socket 与相关 cgroup/sysfs 目录让其能发现并进入容器读取配置通过http://localhost:8080/api/v2.0/appmetrics/containerName验证采集结果并在容器页面查看指标曲线。关于 Docker 1.8 的兼容性提示原文明确指出cAdvisor 是专门从容器标签提取上述信息的。在 Docker 1.8 中容器不会继承镜像的标签因此必须在运行时docker run/ Dockerfile 的 RUN 阶段之外显式指定标签。进一步深入源码可以参考配置结构定义collector/config.go通用正则采集器collector/generic_collector.goPrometheus 采集器collector/prometheus_collector.go采集器管理器与标签前缀collector/collector_manager.go采集器接口定义collector/types.go装配入口与 mTLS 配置cmd/internal/appmetrics/appmetrics.go、cmd/cadvisor.goAPI 端点实现cmd/internal/api/versions.go指标类型与数据类型定义info/v1/metric.go【免费下载链接】cadvisorAnalyzes resource usage and performance characteristics of running containers.项目地址: https://gitcode.com/gh_mirrors/ca/cadvisor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
代码包深度解析与实践指南)
