【Prometheus】cAdvisor工作原理介绍

cAdvisor（Container Advisor）是Google开源的容器监控工具，专注于实时采集和暴露容器级别的资源使用数据。其底层实现基于Linux内核的多项技术，结合高效的事件驱动架构，实现对容器资源的细粒度监控。以下从核心机制、数据采集原理和架构实现三方面详细解析：

一、核心依赖技术

cAdvisor的监控能力建立在Linux内核提供的底层机制之上：
cgroups（控制组）

资源隔离与统计：cAdvisor通过读取/sys/fs/cgroup目录下各子系统（如cpuacct、memory、blkio）的文件，获取容器的CPU、内存、磁盘I/O等资源的使用量和限制值。例如：

CPU使用时长：cpuacct.usage（纳秒级累计值）

内存使用量：memory.usage_in_bytes

实时性：cgroups提供容器资源占用的实时快照，cAdvisor以固定周期（默认1~10秒）轮询这些文件更新数据。
procfs与sysfs

进程级数据：/proc文件系统提供进程信息（如/proc/[pid]/stat），cAdvisor借此分析容器内进程的CPU、内存占用。

硬件与内核指标：/sys文件系统暴露磁盘I/O统计（/sys/block/[device]/stat）、网络设备数据（/sys/class/net/[iface]/statistics）等。
inotify 事件监听

容器动态发现：通过inotify API监听cgroup目录的文件变化事件（如创建/删除），实时感知容器启停，自动调整监控对象。

⚙️ 二、数据采集流程与指标类型

cAdvisor的采集过程分为三层，覆盖容器全维度指标：
指标类型 采集方式 典型数据

资源使用指标 定期轮询cgroup文件（如 memory.usage_in_bytes, cpuacct.usage） CPU耗时、内存占用、磁盘I/O字节数
性能事件 监听内核事件（如OOM Kill通过/dev/kmsg解析） OOM发生次数、容器异常退出事件
进程级数据 扫描/proc目录，关联容器cgroup ID与进程树 容器内进程数、各进程资源占比

容器级资源采集

CPU：从cpuacct.usage读取累计使用时间，计算单位时间内的使用率。

内存：综合memory.usage_in_bytes（当前用量）和memory.stat（缓存/交换分区细节）。

网络：解析/sys/class/net/[iface]获取容器网络接口的收发字节数、丢包率。

磁盘：通过blkio.io_service_bytes读取各设备的读写数据量。
事件驱动机制

OOM事件：监听/dev/kmsg内核日志流，捕获Out of memory事件并关联容器ID。

容器生命周期：利用inotify监听cgroup目录变更，触发新容器监控或旧容器清理。
进程树关联

遍历/proc/[pid]/cgroup文件，将进程映射到其所属容器，实现“容器-进程”资源关联分析。

️ 三、架构设计与数据处理
事件分层架构

监听层：rawWatcher（inotify监听cgroup）、oomParser（解析OOM事件）向事件通道推送消息。

处理层：消费事件并触发容器创建/销毁操作，更新内部容器对象状态。
数据暴露与集成

Prometheus格式：默认通过http://:8080/metrics暴露指标，支持Prometheus直接抓取。

存储与可视化：需配合时序数据库（如Prometheus）和可视化工具（如Grafana）长期存储和展示数据。
Kubernetes深度集成

在K8s中，cAdvisor作为Kubelet内置组件运行，数据路径为/metrics/cadvisor，无需独立部署。

⚠️ 四、局限性
无历史存储：仅保留1~2分钟数据，需外部存储方案。

依赖cgroups：若宿主机未启用cgroups或权限不足，监控功能受限。

内核兼容性：部分指标（如磁盘IO）需高版本内核支持。

总结

cAdvisor的底层核心是通过cgroups获取资源隔离数据，结合procfs/sysfs补充系统级指标，并利用inotify实现动态监听。这种设计使其成为轻量高效的容器监控方案，尤其适合Kubernetes环境下的实时资源分析。但其数据持久化和高级分析需依赖外部生态（如Prometheus），实际部署时需结合场景扩展。