使用阿里云容器监控服务与第三方监控框架集成搭建自己的容器看板
使用阿里云容器监控服务与第三方监控框架集成搭建自己的容器看板
阿里云容器监控服务日前正式上线，容器监控服务提供了非常简单快速地与第三方开源监控方案集成的能力。本篇文章就带领大家一起试用阿里云容器监控服务，并使用目前比较流行的第三方开源监控框架做集成，搭建自己的监控看板。
阿里云容器监控服务日前正式上线，容器监控服务提供了非常简单快速地与第三方开源监控方案集成的能力。本篇文章就带领大家一起试用阿里云容器监控服务，并使用目前比较流行的第三方开源监控框架做集成，搭建自己的监控看板。
1. 编排模板与注意事项
version: '2'
#定义influxdb
image: tutum/influxdb:0.9
- "" #暴露web界面端口
- "" #暴露数据api Web接口端口
container_name: "influxdb"
#“aliyun.monitoring.addon.influxdb” label为固定写法，表明influxdb要与monitoring-service集成
#需要注意的是，label的取值为： 协议://container_name或者host_name:端口
aliyun.monitoring.addon.influxdb: "http://influxdb:8086"
image: grafana/grafana:latest
- influxdb
上面的集成编排模板定义了influxdb和grafana两个服务，并且通过阿里云容器服务所支持的固定的label完成了与监控服务的对接，监控服务将采集到的容器运行状态数据自动写入influxdb中，开发者只需要使用该compose模板部署应用即可。
注意：目前容器服务监控集成只默认支持 influxdb 和 prometheus, label的写法为固定写法，分别为：aliyun.monitoring.addon.influxdb 或 aliyun.monitoring.addon.prometheus。其中我们这里使用 influxdb做集成，label的取值也需要注意，格式必须为：schema:container_name or host_name:port
2. 具体操作方式
使用编排模板创建应用，如下图：
应用创建成功后，查看应用的容器列表，然后复制grafana容器的IP和端口，如下图所示：
在浏览器地址栏中粘贴刚才复制的ip地址和端口，访问grafana 界面，创建属于自己的容器服务监控展板
登陆 grafana 系统以后，手动添加 Data Source，配置方式参考下图，点击 “save & test”
需要注意的是，配置Data Source 页面的 InfluxDB Details 中的 database 必须填写 "telegraf", Http Settings 的Url 填写 influxdb 的容器对外暴露的api Url。
配置好数据源以后，进入 dashboard 页面，选择新建，在页面最左边找到动态菜单，选择添加
grafaic，如下图所示：
配置图表的metrics，如下图所示：
注意： 1. 界面中的 “Panel data source” 数据源要选择刚才配置好的 telegraf 2.注意 Group By 部分点击后面的 “加号” 添加聚合维度，一般选择使用 serviceId 来聚合，聚合方式可以视情况选择 mean(平均值)或者 sum(求和)。
在按照上面的配置方式将其他监控指标配置好，最终效果如下图所示：
在指标较多的情况下，开发者可以使用阿里云容器服务提前配置好的dashboard 模板文件，直接使用grafana 的导入dashboard模板功能即可，这里给大家提供一个配置好的dashboard，大家下载附件以后，在grafana里面导入即可。 配置文件见附件
3、生产与安全
在实际生产环境中，本文中的模板需要做一些修改，其中influxdb的服务定义部分不要对宿主机暴露端口。应用创建成功后，grafana 系统要尽快修改admin用户名密码，限制不同账户的权限，确保自己生产监控数据的安全。
目前阿里云容器监控服务能提供的监控集成功能还是比较方便的，后续可以把配置好的grafana 作为镜像直接在编排模板里面使用，会更加简便。
想了解更多容器服务内容，请访问
附件下载：
用云栖社区APP，舒服~
【云栖快讯】直播推荐——现在报名3月12日编程语言系列讲座，与行业资深专家一起学习Python、C++、JavaScript、Java！还可在活动页面领取红包，百分百中奖哦！&&
提供了高性能可伸缩的容器应用管理服务，支持在一组云服务器上通过Docker容器来进行应用生命...
一款端到端一体化实时监控解决方案的PaaS级阿里云产品。通过该产品，用户可以基于海量的数据迅...
一项针对阿里云资源和互联网应用进行监控的服务。云监控服务可用于收集获取阿里云资源的监控指标，...
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效...你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
我用CAdvisor + influxdb + Grafana监控docker，想通过Grafana图形化的显示容器的资源使用情况，怎么配置？
解决了，主要是influxdb的查询语句。
其中container_name='' 就是想要查看的容器名称
要回复问题请先或
浏览: 5126
关注: 1 人posts - 315,&
comments - 1651,&
trackbacks - 0
当 Docker 部署规模逐步变大后，可视化监控容器环境的性能和健康状态将会变得越来越重要。
在本章中，我们将讨论几个目前比较常用的容器监控工具和方案，为大家构建自己的监控系统提供参考。
首先我们会讨论 Docker 自带的几个监控子命令：ps, top 和 stats。然后是几个功能更强的开源监控工具 sysdig, Weave Scope, cAdvisor 和 Prometheus。最后我们会对这些不同的工具和方案做一个比较。
Docker 自带的监控子命令
docker container ps&是我们早已熟悉的命令了，方便我们查看当前运行的容器。
前面已经有大量示例，这里就不赘述了。值得注意的是，新版的 Docker 提供了一个新命令&docker container ls，其作用和用法与&docker container ps&完全一样。不过&ls&含义可能比&ps&更准确，所以更推荐使用。
如果想知道某个容器中运行了哪些进程，可以执行&docker container top [container]&命令。
上面显示了 sysdig 这个容器中的进程。命令后面还可以跟上 Linux 操作系统&ps&命令的参数显示特定的信息，比如&-au。
docker container stats&用于显示每个容器各种资源的使用情况。
默认会显示一个实时变化的列表，展示每个容器的 CPU 使用率，内存使用量和可用量。
注意：容器启动时如果没有特别指定内存 limit，stats 命令会显示 host 的内存总量，但这并不意味着每个 container 都能使用到这么多的内存。
除此之外&docker container stats&命令还会显示容器网络和磁盘的 IO 数据。
默认的输出有个缺点，显示的是容器 ID 而非名字。我们可以在&stats&命令后面指定容器的名称只显示某些容器的数据。比如&docker container stats sysdig weave。
ps，top, stats 这几个命令是 docker 自带的，优点是运行方便，很适合想快速了解容器运行状态的场景。其缺点是输出的数据有限，而且都是实时数据，无法反应历史变化和趋势。接下来要介绍的几个监控工具会提供更丰富的功能。
下一节我们学习 sysdig。&
书籍：1.《每天5分钟玩转Docker容器技术》2.《每天5分钟玩转OpenStack》
阅读(...) 评论()从运维的角度看微服务和容器
我的图书馆
从运维的角度看微服务和容器
微服务在带来良好的设计和架构理念的同时，也带来了运维上的额外复杂性，尤其是在服务部署和服务监控上。那么，运维是如何看待微服务和容器的呢？传统的单体应用又该如何完成微服务拆分？如何进行微服务之间的依赖关系管理？七牛云美女布道师陈爱珍，在 6 月 18 日七牛云主办的「架构师实践日」上，带来了她的分享。以下是对她演讲内容的整理。
七牛云布道师
7 年以上企业级系统运维管理经验，对大型分布式系统架构设计及运维有丰富的经验。现转向 DevOps ，容器相关技术领域。
单体应用 VS 微服务 &
让我们先从运维的真实场景出发，来看一下单体应用存在的问题。这里先分享两个真实的生产案例。
案例一是某核心业务系统，所有的业务逻辑代码都打包在同一个 WAR 包里部署，运行了将近几百个同构的实例在虚拟机上。某次因为应用包中的一个功能模块出现异常，导致实例挂起，整个应用都不能用了。因为它是一个单体，所以尽管有几百个实例在运行，但是这几百个实例都是异常的。业务系统是经过多年建设起来的，排查起来也很复杂，最终整个业务系统瘫痪了近六个小时才恢复。同时，因为有多个前台系统也调用了这个后台系统，导致所有要调用的前台系统也都全部瘫痪了。设想一下，如果这个场景使用的是微服务架构，每个微服务都是独立部署的，那影响的也只是有异常的微服务和其他相关联的服务，而不会导致整个业务系统都不能使用。
另外的案例是一个客服系统，这个系统有一个特点，早上八点的时候会有大量的客服登录。这个登录点是全天中业务并发量最高的时间点，登录时系统需要读取一些客户信息，加载到内存。后来一到早上客服登录时，系统经常出现内存溢出，进而导致整个客服系统都用不了。当时系统应对这种场景做架构冗余时，并不是根据单独的业务按需进行扩展，而是按照单体应用的长板进行冗余。比如说早上八点并发量最高，单点登陆模块业务需求非常大，为适应这个时间点这个模块的业务压力，系统会由原来的八个实例扩展到十六个实例，这时的扩展是基于整个系统的。但事实上，在其他时间段，这个单点登陆模块基本不使用，且监控的数据显示，主机的资源使用情况基本在&40%&以下，造成了很大的资源浪费。所以在一个大型的业务系统中，每个服务的并发压力不一样，如果都按压力最大的模块进行整体扩展，就会造成资源的浪费，而在微服务的模式下，每个服务都是按自身压力进行扩展的，就可以有效的提高资源利用率。
从这两个例子中，我们可以看出，单体应用存在如下两个问题：一个是横向扩展时需要整体扩展，资源分配最大化，不能按需扩展和分配资源；另一个是如果单体中有一个业务模块出现问题，就会是全局性灾难，因为所有业务跑在同一个实例中，发生异常时不具备故障隔离性，会影响整个业务系统，整个入口都会存在问题。
因此，我们当时考虑把综合业务拆分，进行更好的资源分配和故障隔离。
下面我们看一下单体应用和微服务的对比，如图 1 所示。这里从微服务带来的好处和额外的复杂性来讲。
微服务的好处：
局部修改，局部更新。当运维对一个单体应用进行修改时，可能要先把整个包给停了，然后再去修改，而微服务只需逐步修改和更新即可。
故障隔离，非全局。单体应用是跑在一起，所以只要一个模块有问题，其他就都会有问题。而微服务的故障隔离性、业务可持续性都非常高。
资源利用率高。单体应用的资源利用率低，而使用微服务，可以按需分配资源，资源利用率会非常高。
微服务带来的复杂性：
微服务间较强的依赖关系管理。以前单体应用是跑在一起，无依赖关系管理，如果拆成微服务依赖关系该如何处理，比如说某个微服务更新了会不会对整个系统造成影响。
部署复杂。单体应用是集中式的，就一个单体跑在一起，部署和管理的时候非常简单，而微服务是一个网状分布的，有很多服务需要维护和管理，对它进行部署和维护的时候则比较复杂。
如何更好地利用资源。单体应用在资源分配时是整体分配，扩展时也是整体扩展，数量可控，而在使用微服务的情况下，需要为每一个微服务按需分配资源，那么该为每个微服务分配多少资源，启动多少个实例呢，这也是非常大的问题。
监控管理难。以前我们用 Java ，就是一个单体应用，监控和管理非常简单，因为它就是一个 1 ，但是使用微服务它就是 N 个，监控管理变得非常复杂。另外是微服务之间还有一个协作的问题。
基于容器构建微服务架构
使用微服务，第一步是要构建一个一体化的 DevOps 平台，如图 2 。如果你不使用 DevOps 做微服务的话，整个环境会变得非常的乱、非常的糟糕。它会给你的整个开发、测试和运维增加很多成本，所以第一步我们是提高 DevOps 的能力，能够把它的开发、部署和维护进行很完美的结合，才可以说我们真正能够享受到微服务架构的福利。
容器的出现给微服务提供了一个完美的环境，因为我们可以：
基于容器做标准化构建和持续集成、持续交付等。
基于标准工具对部署在微服务里面的容器做服务发现和管理。
透过容器的编排工具对容器进行自动化的伸缩管理、自动化的运维管理。
所以说，容器的出现和微服务的发展是非常相关的，它们共同发展，形成了一个非常好的生态圈。下面详细讲下&DevOps 的各个模块。
持续集成与持续发布
持续集成的关键是完全的自动化，读取源代码、编译、连接、测试，整个创建过程自动完成。我们来看一下如何用 Docker ,& Maven ,& Jenkins 完成持续集成。
如图 3 所示。首先是开发人员把程序代码更新后上传到&Git&，然后其他的事情都将由&Jenkins&自动完成。那&Jenkins&这边发生什么了呢？Git&在接收到用户更新的代码后，会把消息和任务传递给&Jenkins&，然后&Jenkins&会自动构建一个任务，下载&Maven&相关的软件包。下载完成后，就开始利用&Maven Build&新的项目包，然后重建&Maven&容器，构建新的&Image&并&Push&到&Docker&私有库中。然后删除正在运行的&Docker&容器，再基于新的镜像重新把&Docker&容器拉起来，自动完成集成测试。整个过程都是自动的，这样就简化了原本复杂的集成工作，一天可以集成一次，甚至是多次。
依赖关系管理
前面讲到，当微服务多的时候，依赖关系管理也会比较复杂，现在比较流行的是基于消费者驱动的契约管理 。在开发一个微服务时，并不需要另外一个微服务开发完后再做集成测试，而是使用契约的方式。契约通过提供标准化的输出，说明请求的内容、回复的内容、交换的数据，开发微服务时符合契约里这些条件即可。
如图 4 所示，微服务 A 通过模拟与微服务Ｂ的交互，将交互内容保存在契约里，而微服务 B 开发时需满足这个契约里的条件，这样就不需要 A 和 B 完全完成了才能做测试。当很多微服务与微服务 B 关联时，每个微服务通过契约告诉微服务Ｂ请求的内容、正确的响应和请示的数据，然后微服务Ｂ通过契约模拟这个测试过程，而其他的微服务则需要满足这个契约。当微服务进行升级时，也是要先满足所有契约，这样微服务间的关系就可以更好的进行管理。
典型的微服务架构
图 5 是典型的微服务架构模型，采用的是&Kubernetes&框架。把业务系统拆分成很多的微服务，然后通过服务注册的方式去发现整个生产环境中所有的微服务，通过负载均衡组件进行分发，再用服务调度去进行弹性伸缩，而客户端则只需要通过 API 网关访问微服务。除此之外，微服务的运维也很重要。开发是实现功能性需求，而在实际的生产环境中，我们更应该关心非功能性的需求。因为即使功能实现了，跑到生产上却不能用，功能开发再完美也没有用。
服务发现与负载均衡
服务发现与负载均衡使用的是&Kubernetes&的架构，如图&6&。每一个微服务都有一个 IP 和 PORT ，当调用一个微服务时，只需要知道微服务的 IP&，而不需要关心容器的 IP ，也不需要关心 pod 的&IP&。虽然每个&pod&也有&IP 和 PORT，但当一个 pod&启动时，就会把&pod&的IP 和 PORT&注册到服务发现模块，再进行负载均衡。所以当多个&pod&启动时，对于用户来说还是只需要知道&service&的 IP ，不需要知道后端启动了多少&pod&、IP是多少，这就解决了网络的问题。
日志集中式管理
以前单体的情况下，单体的数量少，日志数量也相应比较少，而在微服务架构下，因为拆分成了很多微服务，相应的日志会非常多且散，这种情况下需要对日志进行集中的管理。我们可以在每个容器里跑日志监控，把所有日志采集进行集中管理和存储，再通过简易操作的&UI&界面进行索引和查询。
然后就是监控方面了。微服务的量是非常大的，这个时候如何有效地监控是极其重要的。我们刚开始做监控的时候，有几百个实例对同一个关键字进行监控，出故障后会收到几百条短信，因为每一个实例都会发一条短信。这时候严重的致命性的报警就会看不到，因为手机信息已经爆炸了，所以要对报警进行分级，精确告警，最重要的是尽量让故障在发生之前灭亡。因此，在做监控时要对故障提前进行判断，先自动化处理，再看是否需要人为处理，然后通过人为的干预，有效的把故障在发生之前进行灭亡。
但如果所有事情都靠人为去处理，这个量也是非常大的，所以对故障进行自动化隔离和自动化处理也很重要。我们在写自动化故障处理的时候研究了很多常见的故障，写了很多算法去判断，精确到所有的故障，这样基本的常见的故障和可以策划处理的故障都可以自动化处理掉。之前没有出现的故障，出现之后我们就会去研究是否可以做成自动化处理。如果生产上做的不精确，对生产会是灾难性的，所以我们对生产的故障自动化处理也做了很多研究。
七牛的微服务架构实践 &
前面讲了很多运维，下面来了解一下 Docker 和微服务在七牛云中的实践，以七牛的文件处理服务架构演变为例。
文件处理服务是指，用户把原图存到七牛的云存储之后，然后使用文件处理服务，就可以把它变成自己想要的服务，比如剪裁、缩放和旋转等，如图 9 。
过去为适应不同的场景，用户需要针对同一图片自行处理后上传所有版本，但如果使用七牛的文件处理服务，则只需提供原图就可以了，其他版本的图片都可以通过七牛进行处理。如图 10 所示，我们把一张原图放进去之后，只需要在原图后面加一个问号和参数，就可以呈现出想要的方式，比如说加水印、旋转、缩放和剪裁。
文件处理服务的架构在早期是非常笨拙的,&如图 11 所示。FopGate&是业务的入口，通过&work config&静态配置实际进行计算的各种 worker 集群的信息，里面包含了图片处理、视频处理、文档处理等各种处理实例。集群信息在入口配置中写死了，后端配置变更会很不灵活，因为是静态配置，突发请求情况下，应对可能不及时，且&FopGate&成为流量穿透的组件（业务的指令流与数据流混杂在一起），比如说要读一张图片，这张图片会经过 FopGate 导过来。
于是，我们自己组建了一个叫 Discovery 的服务，由它进行负载均衡和服务发现，用于集群中 worker 信息的自动发现，每个 worker 被添加进集群都会主动注册自己，FopGate&从 Discovery 获取集群信息，完成对请求的负载均衡。同时在每个计算节点上新增 Agent 组件，用于向 Discovery 组件上报心跳和节点信息，并缓存处理后的结果数据（将数据流从入口分离），另外也负责节点内的请求负载均衡（实例可能会有多个）。此时业务入口只需负责分发指令流，但仍然需要对请求做节点级别的负载均衡。这是第二个阶段，如图 12 。
在第三个阶段，我们把文件处理架构迁移到了容器平台上，取消了业务的 Discovery 服务，转由平台自身的服务发现功能。每个 Agent 无需和 Discovery 维护心跳，也不再需要上报节点信息，每个 Agent 对应一个计算 worker，并按工种独立成 Service，比如 Image Service，Video Service，由于后端只有一个 worker&，因此也不需要有节点内的负载均衡逻辑，业务入口无需负载均衡，只需请求容器平台提供的入口地址即可，如图 13 所示。
上一个阶段中，每个 Agent 仍然和计算实例绑定在一起，而这么做其实只是为了方便业务的无痛迁移，因为 Agent 本身的代码会有一些逻辑上的假设。在第四阶段中，如图 14 ，我们进一步分离了 Agent 和 worker，Agent 独立成一个 Service，所有的 worker 按工种独立成 Service。这么分离的目的在于，Agent 可能会有文件内容缓存，属于有状态的服务，而所有的 worker 是真正干活、无状态的服务。分离之后的好处在于，worker 的数量可以随时调整和伸缩，而不影响 Agent 中携带的状态。可以看到，相比于最早的架构，业务方只需集中精力开发业务本身，而无需重复造轮子，实现各种复杂的服务发现和各种负载均衡的代码。另外，自从部署到容器平台之后，平台的调度器会自动根据节点的资源消耗状况做实例的迁移，这样使得计算集群中每个节点的资源消耗更加均衡。&&&
踩过的那些坑
数据库连接风暴
图 15 所示的是单体应用访问后端数据库使用的数据库连接池，连接池里的连接是可以复用的，而单体中所有的业务模块都可以调用同一个池里的连接。这个数据库连接池可以进行动态的伸缩，但它连接到后端数据库的连接是有上限的。拆分成微服务之后，可能每一个微服务都要创建一个数据库连接池，微服务间的数据库连接池并不能共享。当对微服务进行弹性伸缩时，并不知道它会弹性到什么程度，这时就可能会对后端数据库造成连接风暴，比如原本只有五千个长连接，但是由于弹性伸缩（可能根据前台业务情况进行了非常大的伸缩），会对数据库发生连接风暴，对数据库造成非常大的压力。
为了确保不会因某个服务的连接风暴把数据库拖垮，对其他服务造成影响，我们做了一些优化。首先是优化了我们的一些弹性算法，其次是限定了容器弹性伸缩的范围，因为没有限制的伸缩，可能会对后端数据库造成压力。另外一个是降低连接池初始化的大小，比如初始化设定为 10 ，它往数据库里面的长连接就是 100 个，如果设定为 1 ，往数据库里面长连接就只有 10 个&，如果太多则可能会对数据库造成压力。还有就是数据库端进行一些限定，当连接达到一定数量就进行预警，限制弹性扩展。
单体应用如何改造成微服务？
我在传统企业工作了七八年，我们一直在探讨单体应用如何拆分成微服务。其实对传统企业来讲，他们的单体是非常大的，而且内部的耦合性是非常强的，内部调用非常多。如果我们冒冒失失地将单体拆分成微服务，会占用非常大的网络传输。如果在拆成微服务的时候，没有进行很好的架构设计，拆成微服务并不是享受它带来的好处，而是灾难。所以在拆的时候，比如说前端、后端的拆分、耦合性不是特别强的拆分，我们提倡先跑到容器里面，看一下运维容器的时候有什么坑，然后解决这些坑，然后不断完善。我们可以把耦合性不是那么高的拆成大的块，然后把信息密集型的进行拆分，慢慢拆分成我们理想的架构。这是一个循序渐进的过程，不可一蹴而就。
图 16 是微服务的一些设计准则，例如设计提倡最小化功能，小到不能再小。这时需要每一个服务标准化的提供出来，有一个标准化的接口和其他微服务进行通信。还需要是异步通信，如果是同步会造成堵塞。每个微服务都要有独立的数据存储。此外，服务还需要是无状态的，因为如果有状态，弹性伸缩时可能会有数据丢失，可以用一些其他的方法处理这些有状态的数据。
ArchSummit 全球架构师峰会将于&7 月 15 日在深圳拉开帷幕。本次大会，七牛云将携手大会主办方 Infoq 于&7 月 15日 下午&带来免费技术专场： 容器云与微服务架构实践 。
来自 七牛云、华为、平安科技、北京简网 的技术大咖们，将会结合微服务设计思想，为大家带来容器虚拟化技术在大规模互联网应用或平台上的探索和最佳实践。
本次专场特设免费报名名额，点击
「 阅读原文 」
可以了解更多信息，期待你的参与。
TA的最新馆藏
喜欢该文的人也喜欢51CTO旗下网站
【博文推荐】Docker高级应用之资源监控
本篇博文出自51CTO博客博主dl528888。在本文中，博主将与大家分享他在开发Docker平台时是如何监控资源与进行图像展示的。
作者：dl528888来源：51CTO| 09:28
本篇博文出自51CTO博客博主，有任何问题请进入博主页面互动讨论！
博文地址：
最近忙着开发docker平台，所以挺久没有更新博客了，今天给大家分享一下，我开发docker平台里如何监控资源与进行图像展示的。
默认docker 1.5版本有stats命令查看容器的cpu使用率、内存使用量与网络流量，但此功能有2个必须：
1、必须是docker 1.5版本
2、必须使用默认docker0的网桥(如果你使用ovs这样非原生的网桥无法获取数据的)
我开发的监控里docker是1.5版本，并且通过使用ifconfig来获取容器rx或rx量来获取容器流量，解决了必须使用docker默认网桥才可以获取流量数据。
下面是容器资源监控效果图
1、平台里资源监控界面
2、查看容器yangjing-test的cpu使用率资源监控
3、查看内存使用量资源监控
4、查看容器网络流量信息
下面是监控数据收集脚本信息
使用python写的,由于需要往mysql里写入数据，所以需要安装MySQLdb模块以及服务端mysql开启账号
[root@ip-10-10-29-201&code]&&&&&from&docker&import&Client&import&os&import&socket,&struct,&fcntl&import&etcd&import&MySQLdb&import&re&import&multiprocessing&import&subprocess&import&time&def&get_local_ip(iface&=&'em1'):&&&&&sock&=&socket.socket(socket.AF_INET,&socket.SOCK_STREAM)&&&&&sockfd&=&sock.fileno()&&&&&SIOCGIFADDR&=&0x8915&&&&&ifreq&=&struct.pack('16sH14s',&iface,&socket.AF_INET,&'\x00'*14)&&&&&try:&&&&&&&&&res&=&fcntl.ioctl(sockfd,&SIOCGIFADDR,&ifreq)&&&&&except:&&&&&&&&&return&None&&&&&ip&=&struct.unpack('16sH2x4s8x',&res)[2]&&&&&return&socket.inet_ntoa(ip)&def&docker_container_all():&&&&&docker_container=docker_client.containers(all=True)&&&&&container_name=[]&&&&&container_stop_name=[]&&&&&for&i&in&docker_container:&&&&&&&&&container_name.append(i['Names'])&&&&&for&b&in&container_name:&&&&&&&&&for&c&in&b:&&&&&&&&&&&&&container_stop_name.append(c[1::])&&&&&return&container_stop_name&def&docker_container_run():&&&&&docker_container=docker_client.containers(all=True)&&&&&container_name=[]&&&&&container_stop_name=[]&&&&&for&i&in&docker_container:&&&&&&&&&if&re.match('Up',i['Status']):&&&&&&&&&&&&&container_name.append(i['Names'])&&&&&for&b&in&container_name:&&&&&&&&&for&c&in&b:&&&&&&&&&&&&&container_stop_name.append(c[1::])&&&&&return&container_stop_name&def&check_container_stats(name):&&&&&container_collect=docker_client.stats(name)&&&&&old_result=eval(container_collect.next())&&&&&new_result=eval(container_collect.next())&&&&&container_collect.close()&&&&&cpu_total_usage=new_result['cpu_stats']['cpu_usage']['total_usage']&-&old_result['cpu_stats']['cpu_usage']['total_usage']&&&&&cpu_system_uasge=new_result['cpu_stats']['system_cpu_usage']&-&old_result['cpu_stats']['system_cpu_usage']&&&&&cpu_num=len(old_result['cpu_stats']['cpu_usage']['percpu_usage'])&&&&&cpu_percent=round((float(cpu_total_usage)/float(cpu_system_uasge))*cpu_num*100.0,2)&&&&&mem_usage=new_result['memory_stats']['usage']&&&&&mem_limit=new_result['memory_stats']['limit']&&&&&mem_percent=round(float(mem_usage)/float(mem_limit)*100.0,2)&&&&&&&&&&&&&&&network_check_command=%name&&&&&network_old_result=eval(((subprocess.Popen(network_check_command,shell=True,stdout=subprocess.PIPE)).stdout.readlines()[0]).strip('\n'))&&&&&time.sleep(1)&&&&&network_new_result=eval(((subprocess.Popen(network_check_command,shell=True,stdout=subprocess.PIPE)).stdout.readlines()[0]).strip('\n'))&&&&&&&&&&network_rx_packets=(int(network_new_result['rx'])&-&int(network_old_result['rx']))/1024&&&&&network_tx_packets=(int(network_new_result['tx'])&-&int(network_old_result['tx']))/1024&&&&&collect_time=str(new_result['read'].split('.')[0].split('T')[0])+'&'+str(new_result['read'].split('.')[0].split('T')[1])&&&&&msg={'Container_name':name,'Cpu_percent':cpu_percent,'Memory_usage':mem_usage,'Memory_limit':mem_limit,'Memory_percent':mem_percent,'Network_rx_packets':network_rx_packets,'Network_tx_packets':network_tx_packets,'Collect_time':collect_time}&&&&&&&&&&return&msg&def&write_mysql(msg):&&&&&container_name=msg['Container_name']&&&&&search_sql=&select&dc.id&from&docker_containers&dc,docker_physics&dp&where&dc.container_name='%s'&and&dp.physics_internal_ip='%s';&%(container_name,local_ip)&&&&&n=mysql_cur.execute(search_sql)&&&&&container_id=[int(i[0])&for&i&in&mysql_cur.fetchall()][0]&&&&&insert_sql=&insert&into&docker_monitor(container_id,cpu_percent,memory_usage,memory_limit,memory_percent,network_rx_packets,network_tx_packets,collect_time)&values('%s','%s','%s','%s','%s','%s','%s','%s');&%(container_id,msg['Cpu_percent'],msg['Memory_usage'],msg['Memory_limit'],msg['Memory_percent'],msg['Network_rx_packets'],msg['Network_tx_packets'],msg['Collect_time'])&&&&&n=mysql_cur.execute(insert_sql)&if&__name__&==&&__main__&:&&&&&local_ip=get_local_ip('ovs1')&&&&&if&local_ip&is&None:&&&local_ip=get_local_ip('em1')&&&&&etcd_client=etcd.Client(host='127.0.0.1',&port=4001)&&&&&docker_client&=&Client(base_url='unix://var/run/docker.sock',&version='1.17')&&&&&mysql_conn=MySQLdb.connect(host='10.10.27.10',user='ops',passwd='1FE@!#@NVE',port=3306,charset=&utf8&)&&&&&mysql_cur=mysql_conn.cursor()&&&&&mysql_conn.select_db('devops')&&&&&&&&&&docker_container_run_name=docker_container_run()&&&&&if&len(docker_container_run_name)&==&1:&&&num=1&&&&&elif&len(docker_container_run_name)&&=&4&and&len(docker_container_run_name)&&=8:&&&num=4&&&&&elif&len(docker_container_run_name)&&8&and&len(docker_container_run_name)&&=15:&&&num=8&&&&&elif&len(docker_container_run_name)&&15&and&len(docker_container_run_name)&&=30:&&&num=20&&&&&else:&&&num=40&&&&&pool&=&multiprocessing.Pool(processes=num)&&&&&scan_result=[]&&&&&&&&&&for&i&in&docker_container_run_name:&&&&&&&&&pool.apply_async(check_container_stats,&(i,))&&&&&&&&&scan_result.append(pool.apply_async(check_container_stats,&(i,)))&&&&&pool.close()&&&&&pool.join()&&&&&result=[]&&&&&for&res&in&scan_result:&&&&&&&&&if&res.get()&is&not&None:&&&&&&&write_mysql(res.get())&&&else:&&&&&&&print&'fail&is&%s'%res.get()&&&&&mysql_conn.commit()&&&&&mysql_cur.close()&&&&&mysql_conn.close()&
下面是把此脚本放入crontab里每分钟收集一下
*/1&*&*&*&*&python&/root/collect_docker_monitor_data_multi.py&&&/root/docker_log/docker_monitor.log&2&&1&
另外说明一下，上面的监控数据图形化使用highstock，使用ajax进行动态加载数据，每次获取容器所有时间监控数据。有问题请留言。
【编辑推荐】
【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条头条热点热点关注
24H热文一周话题本月最赞
讲师：273人学习过
讲师：1514人学习过
讲师：1478人学习过
精选博文论坛热帖下载排行
本书是AJAX之父的经典之作。本书用简洁的语言系统化地诠释了设计、技术和商业融合是最重要的发展趋势。全书共8章，包括关于用户体验以及为...
订阅51CTO邮刊