这一部分主要是从API的角度进行分析,cadvisor提供的API是怎样暴露的,怎样注册上来的,以及具体功能是怎样的,由于内容比较琐碎,也是一点一点逐步再完善。
具体API分析
现在从另外一个维度进行分析,看cadvisor究竟提供了哪些服务出来。 具体api的实现在./cadvisor/api文件中,可以看到目前有newversion1_1 1_2 1_3 2_0几种版本,我们以2_0版本分析。
从start函数中的cadvisorhttp.RegisterHandlers
执行具体注册的功能,可以看到除了注册普通的api,还注册了用于性能调优的一些api。这里注册api也没有使用什么特别的框架,直接使用golang自带的serverMux的相关操作,比较容易理解,不再赘述。
这里基本上把所有的request的情况写在了一个函数里,显的比较low,比起kube-apiserver来说,注册api这部分的复杂程度上,简直是差了好几个档次,别的不知道,就扩展性来说,显然不太行,不过考虑cadvisor也都仅仅是需要处理一些get请求,估计不会用到太复杂的api的参数,这样也算是满足需求,不需要杀鸡用牛刀了。
在handleRequest函数中,对传来的request做了第一层处理,即截取出用户输入的api版本,并且交给对应的APIVersion的HandleRequest函数来处理,还要注意,这里每次都要把manager传进去,因为实际的取信息的操作都是通过manager来进行的。
我们这里直接以2.0版本的api为例,分析下对外都暴露出了哪些信息,这些信息是怎样获取到的:
v2.0版本有对应的option通过URL的query传递过来:
- IdType string 指定通过哪种方式识别容器名称,可以是name dockerid 或者 dockeralias
- Count int指定返回的stats的数目
- Recursive bool 是否递归地返回childrencontainer的信息
下面分析下几种不同的requestType:
/api/v2.0/stats
具体的每个容器的特别详细的信息可以通过这个API得到。
containerStats的信息比较丰富,包含每个子系统中的具体的信息。ContainerInfo中包含ContainerSpec以及ContainerStats数组,每隔一段时间就会记录一次ContainerStat信息。通过cout的参数控制,可以输出最新的几条containerstats信息。
通过管理篇的分析,可以知道,在createContainer的最后一步,是通过houskeeping的操作不断地updateStats然后存到memoryCache中,这里关键是看下updateStates的时候各部分信息是如何获取到的。
这部分的信息比较复杂,应该是容器主要搜集的信息来源,可以通过下面的图大致看一下具体那部分信息在程序中是怎么得到的。关于每一部分的具体含义来源,以及搜集时候的具体实现可以参考这一篇
/api/v2.0/version
注意下使用golang自带的system package进行系统调用的方式(之前每次都是自己写一个命令之后去system.run),注意一些获取信息的技巧,可以避免很多繁琐的操作。虽然这一步内部manager得到的信息比较多,但是实际返回回来的之后cadvisor的version信息
指标 | 来源 |
---|---|
主机的os版本信息 | uname系统调用 |
容器所运行的os版本 | /etc/os-release 文件中 读取PRETTY_NAME |
dockerdeamon的版本信息 | dockerdaemon get version |
cadvisor本身的版本信息 | gobuild的时候从ldflags参数传入 |
/api/v2.0/attributes
指标 | 来源 |
---|---|
machine info | manager中的machine info结构体 主要是/proc/文件系统 |
version info | /api/v2.0/version中所提到的操作 |
具体实例是在new manager的时候生成的
1 | type MachineInfo struct { |
/api/v2.0/machine
这些信息包含在attribute中,直接返回machineinfo。
/api/v2.0/ps
这个会返回所有cgroup中的容器的信息,这个容器作为一个进程会显示出哪些信息,后面可以添加容器id信息,显示对应容器的ps信息(从manager存储的map中取出对应的containerData之后从中再进行筛选): 比如:
1 | curl 127.0.0.1:8080/api/v2.0/ps/docker/4f61cb209b685085d5b575173bfa7a5bca822233ae47131ed43033e41fe6505d |python -m json.tool[ |
/api/v2.0/spec/
返回对应的ContainerSpec,比如,这个显示的是容器的spec的信息,显然比起machine的信息要少了好多,就相当于是一个统计清单,看哪些指标包含,哪些指标不包含,比较宏观的一个统计结果:
1 | curl 127.0.0.1:8080/api/v2.0/spec/docker/4f61cb209b685085d5b575173bfa7a5bca822233ae47131ed43033e41fe6505d |python -m json.tool{ |
/api/v2.0/storage
主要是文件系统的信息,比如下面结果
1 | curl 127.0.0.1:8080/api/v2.0/storage/ |python -m json.tool |
/api/v2.0/summary
通过containerData中的summaryreader来获取某个cgroups下面容器的某段时间的摘要信息。目前主要追踪的是cpu以及memory的信息。在statsSummary结构中有具体计算每个属性的方式,包括小时的平均信息,分钟的平均信息,等等。
/api/v2.0/appmetrics
可以自定义metrics信息。
从对外暴露的api的角度进行分析
info结构得到的信息
1 | { |