docker stats 命令源码分析

本文是基于docker 1.10.3版本的源码,对docker stats命令进行源码分析,看看docker stats命令输出的数据是从cgroups fs中怎么怎么计算出来的。

docker client相关代码入口可参考:/docker/docker/api/client/stats.go#141

docker daemon相关代码入口可参考:/docker/docker/daemon/daemon.go#1474

源码分析结果

Cpu数据:

docker daemon会记录这次读取/sys/fs/cgroup/cpuacct/docker/[containerId]/cpuacct.usage的值,作为cpu_total_usage;

并记录了上一次读取的该值为pre_cpu_total_usage;

读取/proc/stat中cpu field value,并进行累加,得到system_usage;

并记录上一次的值为pre_system_usage;

读取/sys/fs/cgroup/cpuacct/docker/[containerId]/cpuacct.usage_percpu中的记录,组成数组per_cpu_usage_array;

docker stats计算Cpu Percent的算法:

cpu_delta = cpu_total_usage - pre_cpu_total_usage;
system_delta = system_usage - pre_system_usage;
CPU % = ((cpu_delta / system_delta) * length(per_cpu_usage_array) ) * 100.0

Memory数据:

读取/sys/fs/cgroup/memory/docker/[containerId]/memory.usage_in_bytes的值,作为mem_usage;

如果容器限制了内存,则读取/sys/fs/cgroup/memory/docker/[id]/memory.limit_in_bytes作为mem_limit,否则mem_limit = machine_mem;

docker stats计算Memory数据的算法:

MEM USAGE = mem_usage
MEM LIMIT = mem_limit
MEM % = (mem_usage / mem_limit) * 100.0

Networt Stats数据:

获取属于该容器network namespace veth pairs在主机中对应的veth*虚拟网卡EthInterface数组,然后循环数组中每个网卡设备,读取/sys/class/net//statistics/rx_bytes得到rx_bytes, 读取/sys/class/net//statistics/tx_bytes得到对应的tx_bytes。

将所有这些虚拟网卡对应的rx_bytes累加得到该容器的rx_bytes。

将所有这些虚拟网卡对应的tx_bytes累加得到该容器的tx_bytes。

docker stats计算Network IO数据的算法:

NET I = rx_bytes
NET O = tx_bytes

Blkio Stats数据:

获取每个块设备的IoServiceBytesRecursive数据:先去读取/sys/fs/cgroup/blkio/docker/[containerId]/blkio.io_serviced_recursive中是否有有效值,

如果有,则读取/sys/fs/cgroup/blkio/docker/[containerId]/blkio.io_service_bytes_recursive的值返回; 如果没有,就去读取/sys/fs/cgroup/blkio/docker/[containerId]/blkio.throttle.io_service_bytes中的值返回;

将每个块设备的IoServiceBytesRecursive数据中所有read field对应value进行累加,得到该容器的blk_read值;
将每个块设备的IoServiceBytesRecursive数据中所有write field对应value进行累加,得到该容器的blk_write值;

docker stats计算Block IO数据的算法:

BLOCK I = blk_read
BLOCK O = blk_write

原文地址:https://www.cnblogs.com/ohgenlong/p/8605896.html

时间: 2024-08-04 00:08:55

docker stats 命令源码分析的相关文章

memcached学习笔记——存储命令源码分析下篇

上一篇回顾:<memcached学习笔记——存储命令源码分析上篇>通过分析memcached的存储命令源码的过程,了解了memcached如何解析文本命令和mencached的内存管理机制. 本文是延续上一篇,继续分析存储命令的源码.接上一篇内存分配成功后,本文主要讲解:1.memcached存储方式:2.add和set命令的区别. memcached存储方式 哈希表(HashTable) 哈希表在实践中使用的非常广泛,例如编译器通常会维护的一个符号表来保存标记,很多高级语言中也显式的支持哈希

memcached学习笔记——存储命令源码分析上

原创文章,转载请标明,谢谢. 上一篇分析过memcached的连接模型,了解memcached是如何高效处理客户端连接,这一篇分析memcached源码中的process_update_command函数,探究memcached客户端的set命令,解读memcached是如何解析客户端文本命令,剖析memcached的内存管理,LRU算法是如何工作等等. 解析客户端文本命令 客户端向memcached server发出set操作,memcached server读取客户端的命令,客户端的连接状态

salt命令源码分析

/usr/bin/salt #!/usr/bin/python ''' Publish commands to the salt system from the command line on the master. ''' from salt.scripts import salt_main if __name__ == '__main__':     salt_main() 调用scripts程序中的salt_main函数 然后再调用/usr/lib/python2.6/site-packa

redis源码分析之事务Transaction(下)

接着上一篇,这篇文章分析一下redis事务操作中multi,exec,discard三个核心命令. 原文地址:http://www.jianshu.com/p/e22615586595 看本篇文章前需要先对上面文章有所了解: redis源码分析之事务Transaction(上) 一.redis事务核心命令简介 redis事务操作核心命令: //用于开启事务 {"multi",multiCommand,1,"sF",0,NULL,0,0,0,0,0}, //用来执行事

redis源码分析之事务Transaction(上)

这周学习了一下redis事务功能的实现原理,本来是想用一篇文章进行总结的,写完以后发现这块内容比较多,而且多个命令之间又互相依赖,放在一篇文章里一方面篇幅会比较大,另一方面文章组织结构会比较乱,不容易阅读.因此把事务这个模块整理成上下两篇文章进行总结. 原文地址:http://www.jianshu.com/p/acb97d620ad7 这篇文章我们重点分析一下redis事务命令中的两个辅助命令:watch跟unwatch. 一.redis事务辅助命令简介 依然从server.c文件的命令表中找

Docker源码分析之——Docker Client的启动与命令执行

在上文Docker源码分析之--Docker Daemon的启动 中,介绍了Docker Daemon进程的启动.Docker Daemon可以认为是一个Docker作为Server的运行载体,而真正发送关于docker container操作的请求的载体,在于Docker Client.本文从Docker源码的角度,分析Docker Client启动与执行请求的过程. Docker Client启动的流程与Docker Daemon启动的过程相仿.首先执行reexec.Init():随后解析f

Docker源码分析(二):Docker Client创建与命令执行

1. 前言 如今,Docker作为业界领先的轻量级虚拟化容器管理引擎,给全球开发者提供了一种新颖.便捷的软件集成测试与部署之道.在团队开发软件时,Docker可以提供可复用的运行环境.灵活的资源配置.便捷的集成测试方法以及一键式的部署方式.可以说,Docker的优势在简化持续集成.运维部署方面体现得淋漓尽致,它完全让开发者从持续集成.运维部署方面中解放出来,把精力真正地倾注在开发上. 然而,把Docker的功能发挥到极致,并非一件易事.在深刻理解Docker架构的情况下,熟练掌握Docker C

Linux c 开发 - Memcached源码分析之命令解析(2)

前言 从我们上一章<Linux c 开发 - Memcached源码分析之基于Libevent的网络模型>我们基本了解了Memcached的网络模型.这一章节,我们需要详细解读Memcached的命令解析. 我们回顾上一章发现Memcached会分成主线程和N个工作线程.主线程主要用于监听accpet客户端的Socket连接,而工作线程主要用于接管具体的客户端连接. 主线程和工作线程之间主要通过基于Libevent的pipe的读写事件来监听,当有连接练上来的时候,主线程会将连接交个某一个工作线

docker 源码分析 一(基于1.8.2版本),docker daemon启动过程;

最近在研究golang,也学习一下比较火的开源项目docker的源代码,国内比较出名的docker源码分析是孙宏亮大牛写的一系列文章,但是基于的docker版本有点老:索性自己就git 了一下最新的代码研读: docker是c/s的架构,分为docker client 和 docker daemon,client端发送命令,daemon端负责完成client发送过来的命令(如获取和存储镜像.管理容器等).两者之间可以通过TCP,HTTP和UNIX SOCKET来进行通信: docker的启动入口