Docker 容器内存监控原理及应用
(window.slotbydup=window.slotbydup || []).push({
id: '2611110',
container: s,
size: '240,200',
display: 'inlay-fix'
您当前位置： &
[ 所属分类
作者 红领巾 ]
Docker 容器内存监控内存监控要明白docker容器内存是如何计算的，首先要明白linux中内存的相关概念。使用free命令可以查看当前内存使用情况。[ ~]$ free
total used free shared buffers cachedMem: 88 733516-/+ buffers/cache: 396052Swap: 8这里有几个概念: mem: 物理内存 swap: 虚拟内存。即可以把数据存放在硬盘上的数据 shared: 共享内存。存在在物理内存中。 buffers: 用于存放要输出到disk（块设备）的数据的 cached: 存放从disk上读出的数据 可以参考这里。为方便说明，我对free的结果做了一个对应。[ ~]$ free
total used free shared buffers cachedMem: total_mem used_mem free_mem shared_mem buffer cache-/+ buffers/cache: real_used real_freeSwap: total_swap used_swap free_swap
total_mem 物理内存总量
used_mem 已使用的物理内存量
free_mem 空闲的物理内存量
shared_mem 共享内存量
buffer buffer所占内存量
cache cache所占内存量
real_used 实际使用的内存量
real_free 实际空闲的内存量
total_swap swap总量
used_swap 已使用的swap
free_swap 空闲的swap
一般认为，buffer和cache是还可以再进行利用的内存，所以在计算空闲内存时，会将其剔除。因此这里有几个等式:real_used = used_mem - buffer - cachereal_free = free_mem + buffer + cachetotal_mem = used_mem + free_mem了解了这些，我们再来看free的数据源。其实其数据源是来自于/proc/memeinfo文件。[ ~]$ cat /proc/meminfo MemTotal:
kBMemFree:
kBBuffers: 2095356 kBCached:
kBSwapCached: 123688 kBActive:
kBInactive:
kBActive(anon):
kBInactive(anon): 4455076 kBActive(file):
kBInactive(file):
kBUnevictable: 362900 kBMlocked: 74696 kBSwapTotal:
kBSwapFree:
kBDirty: 2860 kBWriteback: 0 kBAnonPages:
kBSlab: 8374496 kBSReclaimable: 8163096 kBSUnreclaim: 211400 kBKernelStack: 45824 kBPageTables: 606296 kBNFS_Unstable: 0 kBBounce: 0 kBWritebackTmp: 0 kBCommitLimit:
kBCommitted_AS:
kBVmallocTotal:
kBVmallocUsed: 772092 kBVmallocChunk:
kBHardwareCorrupted: 0 kBAnonHugePages:
kBHugePages_Total: 0HugePages_Free: 0HugePages_Rsvd: 0HugePages_Surp: 0Hugepagesize: 2048 kBDirectMap4k: 7168 kBDirectMap2M: 2015232 kBDirectMap1G:
kBdocker说完linux的内存，我们再来看下docker的内存监控。docker自身提供了一种内存监控的方式，即可以通过docker stats对容器内存进行监控。该方式实际是通过对cgroup中相关数据进行取值从而计算得到。cgroupcgroup中的memory子系统为hierarchy提供了如下文件。[ ~]$ ll /cgroup/memory/docker/53a11f13c030dd2ddade54d5cdd7ae7e9e68f5ba055ad28498b6f/总用量 0--w--w--w- 1 root root 0 2月 22 12:51 cgroup.event_control-rw-r--r-- 1 root root 0 5月 25 17:07 cgroup.procs-rw-r--r-- 1 root root 0 2月 22 12:51 memory.failcnt--w------- 1 root root 0 2月 22 12:51 memory.force_empty-rw-r--r-- 1 root root 0 3月 30 17:06 memory.limit_in_bytes-rw-r--r-- 1 root root 0 2月 22 12:51 memory.max_usage_in_bytes-rw-r--r-- 1 root root 0 2月 22 12:51 memory.memsw.failcnt-rw-r--r-- 1 root root 0 3月 30 17:06 memory.memsw.limit_in_bytes-rw-r--r-- 1 root root 0 2月 22 12:51 memory.memsw.max_usage_in_bytes-r--r--r-- 1 root root 0 2月 22 12:51 memory.memsw.usage_in_bytes-rw-r--r-- 1 root root 0 2月 22 12:51 memory.move_charge_at_immigrate-rw-r--r-- 1 root root 0 2月 22 12:51 memory.oom_control-rw-r--r-- 1 root root 0 3月 30 17:06 memory.soft_limit_in_bytes-r--r--r-- 1 root root 0 2月 22 12:51 memory.stat-rw-r--r-- 1 root root 0 2月 22 12:51 memory.swappiness-r--r--r-- 1 root root 0 2月 22 12:51 memory.usage_in_bytes-rw-r--r-- 1 root root 0 2月 22 12:51 memory.use_hierarchy-rw-r--r-- 1 root root 0 2月 22 12:51 notify_on_release-rw-r--r-- 1 root root 0 2月 22 12:51 tasks这些文件的具体含义可以查看相关资料cgroup memory。这里主要介绍几个与docker监控相关的。
文件名 说明
memory.usage_in_bytes 已使用的内存量(包含cache和buffer)(字节)，相当于linux的used_meme
memory.limit_in_bytes 限制的内存总量(字节)，相当于linux的total_mem
memory.failcnt 申请内存失败次数计数
memory.memsw.usage_in_bytes 已使用的内存和swap(字节)
memory.memsw.limit_in_bytes 限制的内存和swap容量(字节)
memory.memsw.failcnt 申请内存和swap失败次数计数
memory.stat 内存相关状态
以下为一个容器的样例。[ 53a11f13c030dd2ddade54d5cdd7ae7e9e68f5ba055ad28498b6f]$ cat memory.usage_in_bytes [ 53a11f13c030dd2ddade54d5cdd7ae7e9e68f5ba055ad28498b6f]$ cat memory.memsw.usage_in_bytes [ 53a11f13c030dd2ddade54d5cdd7ae7e9e68f5ba055ad28498b6f]$ cat memory.stat cache rss mapped_file pgpgin pgpgout swap inactive_anon 4218880active_anon inactive_file active_file unevictable 0hierarchical_memory_limit hierarchical_memsw_limit total_cache total_rss total_mapped_file total_pgpgin total_pgpgout total_swap total_inactive_anon 4218880total_active_anon total_inactive_file total_active_file total_unevictable 0memory.statmemory.stat包含有最丰富的
cache 页缓存，包括 tmpfs（shmem），单位为字节
rss 匿名和 swap 缓存，不包括 tmpfs（shmem），单位为字节
mapped_file memory-mapped 映射的文件大小，包括 tmpfs（shmem），单位为字节
pgpgin 存入内存中的页数
pgpgout 从内存中读出的页数
swap swap 用量，单位为字节
active_anon 在活跃的最近最少使用（least-recently-used，LRU）列表中的匿名和 swap 缓存，包括 tmpfs（shmem），单位为字节
inactive_anon 不活跃的 LRU 列表中的匿名和 swap 缓存，包括 tmpfs（shmem），单位为字节
active_file 活跃 LRU 列表中的 file-backed 内存，以字节为单位
inactive_file 不活跃 LRU 列表中的 file-backed 内存，以字节为单位
unevictable 无法再生的内存，以字节为单位
hierarchical_memory_limit 包含 memory cgroup 的层级的内存限制，单位为字节
hierarchical_memsw_limit 包含 memory cgroup 的层级的内存加 swap 限制，单位为字节
active_anon + inactive_anon = anonymous memory + file cache for tmpfs + swap cacheactive_file + inactive_file = cache - size of tmpfsdocker原生内存监控再来说到docker原生的docker stats。其具体实现在libcontainer中可以看到。其将容器的内存监控分为cache,usage,swap usage,kernel usage,kernel tcp usage。其中cache是从memory.stat中的cache中获取。usage是使用memory.usage_in_bytes和memory.limit_in_bytes进行相除来计算使用率。这一方式有一个弊端，就是不够细化，没有区分出cache部分，不能真正反映内存使用率。因为一般来说cache是可以复用的内存部分，因此一般将其计入到可使用的部分。可以考虑的改进计算方式改进方式在统计内存使用量时将cache计算排除出去。类似于linux中计算real_used时将buffer和cache排除一样。cache并不能直接应用memory.stat中的cache，因为其中包括了tmpfs，而tmpfs算是实际使用的内存部分。tmpfs即share memory，共享内存因为在memory.stat中存在有active_file + inactive_file = cache - size of tmpfs因此可以计算实际使用的内存量为real_used = memory.usage_in_bytes - (rss + active_file + inactive_file)感谢阅读，希望能帮助到大家，谢谢大家对本站的支持！
本文运维安全相关术语:linux服务器代维 linux服务器搭建 运维管理 运维工程师 企业安全文章 企业安全管理 cf安全系统检测到游戏数据异常
转载请注明本文标题：本站链接：
分享请点击：
1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责；
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性，不作出任何保证或承若；
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
CodeSecTeam微信公众号
意识到自由意志是上天赐予的礼物的人，只有在奋力抗争之后，才知道如何善用！
手机客户端轻量级虚拟化容器 ，自发布以来便广受业界关注，在开源界和企业界掀起了一阵风。相对于 VM 有以下几个优势：启动速度快；资源利用率高；性能开销小。
从图中可以看出 Docker 和 虚拟机的差异，虚拟机的 Guest OS 和 Hypervisor 层在 Docker 中被 Docker Engine 层所替代，Docker 有着比虚拟机更少的抽象层。由于 Docker 不需要通过 Hypervisor 层实现硬件资源虚拟化，运行在 Docker 容器上的程序直接使用实际物理机的硬件资源。因此在 CPU、内存利用率上 Docker 略胜一筹。Docker利用的是宿主机的内核，而不需要 Guest OS，因此，当新建一个容器时，Docker 不需要和虚拟机一样重新加载一个操作系统内核，因此新建一个 Docker 容器只需要几秒钟。
既然 Docker 这么火，那么问题来了，为了能够更精确的分配每个容器能使用的资源，我们想要实时获取容器运行时使用资源的情况，怎样对 Docker 上的应用进行监控呢？Docker 的结构会不会加大监控难度？
我们都了解， container 相当于小型 host，可以说存在于 hosts 与应用之间的监控盲区，无论是传统的还是的方式，都很难有效地监控 Docker。了解了一下现有的 Docker 相关监测 App 和服务，包括简单的开源工具和复杂的企业整体解决方案，下面列举几种作为参考：
1. cAdvisor
谷歌的 container introspection 解决方案是 cAdvisor，这是一个 Docker 容器内封装的实用工具，能够搜集、集料、处理和导出运行中的容器的信息。通过它可以看到 CPU 的使用率、内存使用率、网络吞吐量以及磁盘空间利用率。然后，你可以通过点击在网页顶部的 Docker Containers 链接，然后选择某个容器来详细了解它的使用情况。cAdvisor 部署和使用简单，但它只可以监视在同一个 host 上运行的容器，对多节点部署不是太管用。
在我们列举的几个监控 Docker 的服务或平台中，这是唯一一款国内产品。 支持多种操作系统、云主机、数据库和中间件的监控，原理是在平台服务仪表盘和自定义仪表盘中，采集并处理 Metric，对数据进行聚合与分组等计算，提供曲线图、柱状图等多样化的展现形式。优点是监控的指标很全，简单易用，但目前正式版还未上线，可以期待一下。
Scout 是一款监视服务，并不是一个独立的开源项目。它有大量的插件，除了 Docker 信息还可以吸收其他有关部署的数据。因此 Scout 算是一站式监控系统，无需对系统的各种资源来安装各种不同的监控系统。 Scout 的一个缺点是，它不显示有关每个主机上单独容器的详细信息。此外，每个监控的主机十美元这样略微昂贵的价格也是是否选择 Scout 作为监控服务的一个考虑因素，如果运行一个有多台主机的超大部署，成本会比较高。
4. Sematext
Sematext 也是一款付费监控解决方案，计划收费方案是3.5美分/小时。同样也支持 ，还包括对容器级事件的监测（停止、开始等等）和管理容器产生的日志。
时间关系我们选择了其中安装最简单的 Cloud Insight 来试验监控基于 Docker 的一个应用——Acme 的运行情况，后期时间允许会将其他几种监控方式都试一遍。
Docker 监控实战
单方面监控 Docker 可能并不太适合与业务挂钩的应用，当业务量上涨，不单单是 Docker 的负载上升，其他 JVM 指标也能也会出现上升的趋势。
我们尝试使用一个支持比较多中间件、数据库、操作系统、容器的 Cloud Insight 来说明这个实际的场景。
Cloud Insight
Cloud Insight 由于是一个
监控方案，相对来说它的安装和部署都比较简单。在这次监控实战中，我们以 AcmeAir 为实验对象：一个可以模拟压力的电子商务类应用。
AcmeAir 是一款由原 IBM 新技术架构部资深工程师 Andrew Spyker，利用 Netflix 开源的 Netflix OSS 打造的开源电子商务应用。此应用具有如下特性：
模拟提供航班订票服务。用户可以通过移动设备或者 web 浏览器，完成新用户注册，用户登录，航班查询，订票等操作。
AcmeAir 融入了 Docker，微服务架构等理念。并采用 Tomcat、、 Application Server、WebSphere Extreme Scale、、 分别打造了不同版本的实现。
AcmeAir 利用 JMeter 模拟用户行为。可通过动态调整用户数量，模拟产生各种压力的事物流量。并可在应用中预先植入错误代码，模拟各种故障场景。该应用可做为压力测试，终端异常检测，故障诊断等各种测试场景的测试用例。
首先，我们要打开 Cloud Insight 监控，还好 Cloud Insight 安装简单，一条命令即可。接着，我们新建一个用于此次监控的仪表盘，依次将想要获取的指标统统添加进去。比如，选中 jvm.non_heap_memory 这个指标，选择按照 instance 分组。
我们添加以下指标：
docker.cpu.user
docker.cpu.sysytem
docker.containers.running
jvm.heap_memory
jvm.nonheapmemory
jvm.gc.cms.count
jvm.heapmemorymax
jvm.gc.parnew.time
应用 Acme 部署在四台 servers 上，我们开启四台 servers, 然后用 JMeter 给应用加压。随着时间 JMeter 不断给应用加压。
当 users 人数达到 188 时，我们再来看一下仪表盘的视图。
从图中可以看到，性能数据发生了变化，根据 JMeter 里的数据，此时 CPU 占用超过了50%，错误率也有所提升；对比来看，根据 Cloud Insight 里的曲线显示，蓝色的线所代表的 Container CPU 占用率已经超过50%，逐渐接近75%，系统剩余的 CPU 资源逐渐下降，该 Container 的系统 CPU 资源消耗也突然增大。我们可以通过这些定位到 CPU 占用率过高的 Container ，及时而主动地去了解性能瓶颈，从而优化性能，合理分配资源。
所抓取的性能指标算是较为全面，部署和展现方式都是相当简单易懂的，对这个产品可以期待一下。
集监控、管理、计算、协作、可视化于一身，帮助所有 IT 公司，减少在系统监控上的人力和时间成本投入，让运维工作更加高效、简单。想阅读更多技术文章，请访问 。Docker运维必备：监控宝Docker监控试用手记 - 云智慧 - 博客园
随笔 - 104
本文由肖远昊深度实践docker监控的报告
&&& 非常荣幸得到监控宝的邀请，试用了他们最近推出的新产品&&Docker监控。&
&&& 9月7日，中国APM厂商云智慧CloudWise正式发布上线Docker监控，该产品从部署到使用，整个过程都非常的简单。不仅能够实时监控宿主机和Docker容器的性能信息（包括CPU、Mem、磁盘、Net In/Out），还可以自定义相应的告警策略。以下将从部署、监控信息、告警这几个方面聊聊试用体会。大家可以[注册](/)监控宝，免费使用Docker监控。
&&& 阅读了Dockone上的文章《扒一扒监控宝Docker监控的技术原理》（http://dockone.io/article/692），了解到Docker监控的实现是基于SmartAgent架构来完成的，整个部署过程在几分钟内便可以完成。
&&& 第一步，点击&创建监控项目&，输入基本信息，包括名称和监控频率后，就可以看到具体的部署步骤。
第二步，在监控机器上安装代理和Docker插件。
l& 首先下载、解压和启动SendProxy，SendProxy是一个代理，作为发送引擎，可以在局域网内进行部署，将局域网内机器的监控信息高效地传输到云智慧的SaaS平台。SendProxy可以通过SendProxy.sh脚本进行启动，命令为 `./SendProxy.sh start`，执行之后，可以通过命令 `./SendProxy.sh status`来查看SendProxy的状态，如果&States&是&ok&状态，则表示SendProxy启动成功。
l& 其次，下载、解压和启动Docker插件&&Docker Agent，Docker Agent是Docker监控的主要模块，负责在监控机器上采集数据并通过SendProxy将数据传输到云智慧的SaaS平台，可直接使用start.sh脚本启动Docker Agent。
经过这两步后，在监控宝的Docker监控页面就可以看到，刚刚创建的监控项目已经获取到了监控机器上的数据了。
不知道大家会不会有个疑问，&数据是怎么定位到刚刚创建的监控项目？&斗胆猜测一下，创建监控项目时，输入的名称和设定的监控频率在保存监控项目后，将监控项目信息写入了Docker Agent的配置文件中,这样就能对应上这个监控项目了。但还有一个疑问，"那一个机器上如果有两个监控项目怎么办？"，仔细想想，一台机器上只对应一个监控项目，而一个监控项目可以监控多台机器。
& 根据亲身实践，对于部署流程中遇到的问题，提几个小建议。&
& （1）在部署提示中，向用户说明现在Docker Agent所支持的操作系统类型；&
& （2）提示用户，监控项目和Docker插件的关联关系； &
& （3）提示用户，如果Docker监控页面一直没有收到数据，可以使用bin目录下的docker_py脚本尝试Push监控信息。
监控信息展现
部署完成之后，可以进入具体的信息展示界面。所展示的信息比较全面，包括CPU、内存、磁盘和网络流量的监控信息以及监控机器上不同状态Docker容器的统计信息（这么全面的信息，妈妈再也不用担心Docker运维了）。以下就是监控信息的整体呈现。
监控信息统一使用折线图展示，比较直观，如果想知道具体数据的数值，可以在图表的右侧切换到数据视图。如果想知道某段时间内的数据，可以在页面最上方进行选择，默认提供了&今日&、&昨日&和&最近七天&这三个选项，当然也可以根据需要进行自定义时间范围。图标上的数据线免不了会出现重叠，可以通过点击上方的标题来关闭某些数据线。这些细节方便值得称赞。
具体数据数值的展示如下：
在具体类目监控信息的展示页面，比如说Net In/Out类目，可以看到不同容器的监控数据以及一些统计信息（最大值、平均值和最小值），默认情况下，会展示&资源消耗Top10&的10个容器，当然也可以通过左上角的下拉框选择具体某个容器的数据展示。
告警功能，无疑是运维人员和开发者最重视的一个功能。在云智慧监控宝的Docker监控中，用户可以自定义告警设置。告警对象主要是针对容器的资源使用情况以及容器的存活率。
告警策略根据统计数据（平均值、和值）进行相应阈值的设定，高于、低于或者等于设定阈值时，进行相应告警。对于资源的使用情况，可以针对所有容器或者单个容器进行告警设置。
值得一提的是，监控宝的的告警方式非常全面，可以通过电子邮件、手机短信、电话语音、APP推送、微信等方式进行通知，特别是通过电话语音和微信的方式能保证你不漏掉任何重要的告警信息。
自从Docker问世依赖，运维一直是Docker使用者的一个痛点。云智慧推出的Docker监控，填补了国内Docker监控的空白。从部署到监控，整体上的感觉就是简单易懂且易用。整个部署过程，只是简单地下载两个Zip安装包，然后修改相应权限，启动就好了，对于新手或者小白用户来说，这是非常简单的操作。
监控信息使用图表展示，但也没有忘记给需要具体数据的用户提供数据视图的接口，细节方面做的很到位。进入CPU、Mem等具体监控信息部分，能够看到具体单个容器的监控信息，效果不错。告警部分，策略比较明确，通过统计的平均值或者和值做衡量，以设定的条件和阀值来触发告警，可以对单个容器的某个性能监控信息做告警，还是比较细致的。
最后提个建议，是否能够加入&组&或者&集群&的相关概念，在监控展示时，可以选择展示这个&集群&的监控信息，在告警设置中，可以设定这个&集群&的告警信息。有时候在一个宿主机上会把几个容器当成一个集群来用，例如一个hadoop集群。如果对每个容器单独观察监控信息或者设置告警信息，就显得有些繁琐与不便。
最后，非常感谢监控宝给予了这次试用Docker监控的机会，希望监控宝能够给我们带来更多的惊喜。
监控宝Docker监控正在免费使用中，欢迎体验：
阅读(...) 评论()【活动】Docker监控，监控宝惹火上线，开放试用中 – 运维生存时间
你可能喜欢
有回复时邮件通知我
12345678910
关于本站 本站以分享运维技术为主，欢迎大家参与技术分享，同时也欢迎大家吐槽，本站提供以下交流圈：QQ群①：*****（满）QQ群②：6690706 QQ群③： QQ群④：（新） 微信公众号：ttlsacom 商务合作QQ：
记住我的登录信息
点击“立即注册”转到用户注册页面。
输入用户名或电子邮箱地址，您会收到一封新密码链接的电子邮件。
用户名或电子邮件地址业务运维如何做？Docker集群、监控来帮忙 - 推酷
业务运维如何做？Docker集群、监控来帮忙
在2017游戏行业全球同服和安全攻防技术沙龙上，来自心动网络的吴涵分享了《浅谈Docker业务运维》。他主要从运维职责（部署阶段、运行阶段）、潜在的问题、选择Docker的原因、Docker集群、Docker监控、Docker未来六个方面以运维人员的角度分享了Docker的使用经验。
以下内容根据直播视频整理而成。
大家对于Docker已经不陌生了，Docker产品在很多领域都比较火。心动网络从2015年开始接触Docker，发现Docker的整个产品模式比较适合游戏领域公司的快速发展模式，包括打包部署和发布都契合需求。
以前（比较大众的时期），运维同事都需要做一些部署阶段的工作，比如系统安装、编译环境、代码上传、执行编译、启动脚本。这些工作都需要运维人员在线上进行大量的手动操作，中间会出现许多问题需要人工进行定位和排查。
在部署完成之后，运维人员需要做服务运行阶段的工作和维护，包括配置更新、代码更新、系统更新、监控采集、故障处理。这些都是在整个运行时期，运维人员需要时刻关注的问题。
在接触Docker之前，心动网络也是以传统模式来部署业务和维护业务的，也遇到很多潜在问题。比如：编译环境迭代更新导致库版本升级使编译出现兼容性问题；在机器数量比较庞大的情况下去上传代码，导致代码有泄露的风险；开发部、安装部的版本出现问题，导致代码编译无法通过；在编译完成之后需要把整个服务打包，需要写启动脚本使其每次都能自己运行；代码管理方面，用到SVN或者GIT仓库管理工具，有办法去切换版本，但是发布二进制服务的时候需要很麻烦的做很多标签来定位服务对应的维护版本；服务运行之后，监控服务的运行状态比较困难；做大量工作之后发现最终高投入换来了低效率。
为何选择Docker？
在内部的测试环境使用Docker之后，发现Docker有很多优势：一次打包，各处运行；编译和运行环境分离；服务端只需安装Docker运行组件；Docker镜像标签用作版本管理；API调度管理容器，实时监控容器的运行状态；多种语言支持的SDK，可以与业务深度结合；部署模式统一，易于维护。使用Docker之后，大幅减少了在部署和监控上的精力，把更多的时间花在对接更高级的业务运行模式上。底层的很多东西直接使用Docker，时间成本大幅减少。
在机器节点非常庞大的情况下，由于Docker是单机的服务，所以会出现一些问题。心动网络的测试环境都是以小量机器为规模，不是特别注重节点之间的管理，但是上线之后，在庞大的集群（以百、千为计量单位）中需要一个能够统一管理的模式，即需要Docker集群模式。
在对比之后，最终选择了Docker内置的集群模式Docker Swarm。Swarm在Docker1.12之前是以独立进程的方式运行的。在Docker1.12之后，官方把Swarm集群模式集成在Docker Engine中。Swarm采用去中心化设计，分为很多角色，比如Manager和Worker，在各个节点之间的通信都是TS加密的，可以保障一定的通信安全。Swarm支持服务编排，可以把多个服务打包成一个Application来发布，比如采用Web+DB的模式。可伸缩性是指，比如定义集群里的一个启动数量为10，Swarm会根据预定的启动值以自动调度的策略来保证整个集群的预设值能够始终满足需求。Swarm具有自愈能力，很多服务是无状态的或者微服务，在一个集群里会有很多的容器，其实本地是不留存信息的，而是集中化的存在缓存或者数据库中，这些容器可以看作是一个Runtime环境，只负责处理不负责存储，自愈能力是针对这些服务出现Crash之后可以自动的在其他可用节点上再去启动新的容器来弥补已经Crash的容器，保证整个集群里的数量符合预期值。Swarm支持滚动更新，当滚动失败或者更新失败之后，需要进行回退，但是有些回退的操作比较复杂，需要回退所有的配置文件，基于Docker的滚动更新是比较方便的，因为是作为容器来发布，更新失败后，只要上一个版本的容器还存在就可以无缝切换过来，整个Runtime的环境可以保证一致。
关于Docker监控，官方一直没有给出一个比较好的方法，反而是很多第三方的开源项目在实现Docker监控。此时就需要对Docker API的调度非常熟悉，但是很多时候大家只是想能够很快的起一个服务能够调用Docker的API把数据存储在自己的存储中，通过前端的页面转接出来。
Docker 本地CLI有Docker state指令，可以关注比较通用的监控参数，包括CPU、内存、IO使用率、网络使用率等。在有一定研发能力的基础上，可以考虑使用Docker Remote API自己去抓监控数据，通过某种方式展现出来。Google Cadvisor是比较成熟的第三方项目，可以和Docker无缝贴合，能够监控单台物理机上面所有容器的状态，其本身是不存储数据的，但是支持加载后端的存储把数据写到存储中。Shipyard是Docker的一个核心成员开发的，带UI，本身不是做监控的，是作为Docker Front-end Web前端去管理Docker，也包含了对Docker API的调用，可以作为一个简单的监控工具来使用。
并不是完美无缺的，在以下方面期待改进：Docker对高密度写入场景并不是特别友好，不是作为存储直接写入数据到容器中，还需要通过加载第三方的Volume或者本地的主机目录关联到容器里面来实现，对数据库写入优化不适合；Docker Daemon API是中心化设计的，使用时如果Docker Daemon发生Crash，会导致所有的API不可用，此时不管通过命令行还是remote API都不能管理上面的容器，只能非常麻烦的重启Docker Daemon，造成业务的闪断或者各种各样的问题；API是完全没有验证的，只要抓到API地址就可以通过特定的协议交互，在内网环境问题不大，但是在外网开放API的风险成本比较高。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致