容器和实时资源监控的必知要素

您是否实时监控您的容器资源？若是没有，那意味着您可能没有对之进行有效监控。在快速变化的、动态的微服务环境中，即便是几秒钟之前的监视数据也可能再也不可行。为了防止中断，您须要实时监控。

在这篇文章中，我解释了为何对容器资源进行实时监控是很重要的，以及实时监控中您应该关注的容器指标。

首先要明确的是，这篇文章并不是在为哪一个特定的容器监控产品站台。虽然如今有不少可供容器使用的实时监控平台，但我认为最好的作法，仍是充分了解容器监控的基本要素，而不是只关注特定产品的某些特性。若是您知道为保证容器基础设施正常运行须要实时监视什么，那么你必定能选出最佳的、最能知足你的实时监控需求的工具。

实时容器监控面临的挑战

在讨论如何对容器进行实时监视以前,有必要指出实时监视容器所带来的特殊挑战。

最明显的是，在一个容器化的环境中，组件老是会消失。在传统环境中，您监控的大可能是相对静态的服务器和应用程序。但容器是不断变化的。

所以，在容器化的环境中，你须要监控更多的东西，甚至会受到更多的干扰。所以，在混乱繁多的数据中甄别有意义的数据是比较困难的，特别是当你须要实时监控的时候，更不该把时间浪费在甄别过程上。

因为Docker将容器从主机中抽离的方式，实时监控容器化的环境可能会更加困难。当您处理容器时，您是没法简单地经过在主机上运行诸如top或ps之类的监控命令，来准确了解容器内发生的状况的。

大规模地从容器内部进行实时监控是几乎没法实现的，所以，解决这一难题的方法是使用代理或换一种更巧妙的监控解决方案，为容器及其支持的服务提供实时可见性。

你能够监控什么？

咱们来看看您能够监控哪些实时容器指标。将Docker做为最直观的例子（尽管如下大部分适用于其余容器系统，包括Linux-native LXD），咱们能够将实时容器指标分为四个基本类别：

Memory

Docker能够监视单个容器使用的总内存，以及高速缓存和交换内存的数量，以及表示进程使用的、且未缓存或存储在磁盘上的内存（如匿名内存映射）的驻留集大小或RSS 和栈。

RSS和高速缓存能够分解为活动和非活动内存。在Docker的内存统计信息中，也包含了次要（复制或分配）和主要（彻底从磁盘读取）页面错误。

CPU

Docker监控用户CPU时间（进程自己使用的CPU）和系统CPU时间（进程的系统调用）。若是执行CPU节流(限制给定容器可用的时间)，则还将报告容器的节流计数和时间。

I/O

对于I/O，Docker监控 I/O的操做数和I/O的字节数。在这两种状况下，它分别计数同步/异步和读写。Docker还提供读写扇区（512字节）的计数（读写统计在一块儿）以及当前队列中的操做数。

网络资源

Docker还报告了单个容器的整体网络指标，包括数据包数、字节流量、丢弃数据包以及发送和接收错误。

更多…

其余须要考虑的指标包括存储（和与存储相关的性能指标），以及正在使用的容器总数。除了容器的特定指标以外，还须要对诸如整个系统性能、流量、用户行为模式和应用程序性能等传统因素进行监控，全部这些均可能直接或间接地影响容器活动。

最佳监控方式

监控方法和监控服务固然也很重要。Docker的原生监控工具备一个简单的接口，但在这些工具上构建或包含的许多服务具备很是强大的功能，其中可能包括非Docker资源监控、仪表板、容器和聚合级别的分析，以及用于警报和其余自动响应的API。

选择完一系列监控工具以后，若想让从此的工做更简便、更易操做，能够选择一个能够快速方便地与这些工具完成集成的容器管理平台，如开源的容器管理平台Rancher。这些工具不少均可以轻易与Rancher进行集成，而且能够用于监控（和分析）通常容器中的常见资源以及Rancher特定的资源。

容器监控为什么重要？

为何监控诸如此类的指标很重要？这绝不奇怪，监控容器的主要缘由与监控其余应用程序的主要缘由密切相关：性能、错误检测和异常行为的检测。对于容器，监控能够帮助您检测系统、容器和应用程序级别的问题。

顺便说一下，这并不意味着您对容器监控的方法与您在传统环境中使用的方法相同。如上所述，容器监控带来了特殊的挑战。可是，不管在哪一种状况下，容器监控的好处其实都同样。

实时容器监控和性能优化

监控容器性能最明显的指标也许是那些涉及CPU和内存使用的指标。某个特定的容器（或者更典型的，组成特定微服务器的容器的多个或大多数实例）占用过多的CPU时间？或过多内存？若是是这样，那么您就有机会经过查找和修复问题来优化性能。

如下是一些能够经过实时监控来解决性能问题的具体策略。

CPU节流

仅仅经过执行CPU节流，就能够解决一些CPU过分使用的问题。然而，在其余状况下，此类性能问题可能代表设计中存在问题(在总体应用或微服务级别)，或编码错误。这些与性能相关的问题也可能出如今I/O甚至网络指标中。

节流能够起到相似于传统负载均衡功能的做用，但当遇到与CPU相关的性能问题时，不要简单地限制并假设可以解决问题，这一点很重要。若是某个关键服务使用过多的CPU时间，则扼制它可能会以其余方式下降性能。

当CPU或内存问题或相似的性能问题频发时，在设计级别上查找瓶颈和应用程序错误尤其重要，由于这些问题可能会致使内存、CPU服务或其余资源使用不正确或效率低下。

资源调配

性能问题也可能源于系统级资源配置不足。您可能须要提供更多的内存，更多的存储空间，更多的CPU访问权限或切换到云服务协定，从而使您在访问资源时得到更高的优先级。

资源调配并非灵丹妙药

与节流同样，重要的是不要简单地认为应该提供更多的资源，并但愿借助它解决性能问题。您应该首先查看应用程序体系结构、微服务设计以及在编码级别可能出现的功能问题。您不能经过简单粗暴地提供更多资源，来解决设计问题或bug。以这种方式，也许您可以克服明显且直接的效率低下方面的问题，但问题的其它方面可能会继续隐匿乃至升级，在某一时刻形成更大的麻烦。

容器监控：错误和异常行为

性能问题并非实时监控可以帮助您找到和解决的惟一问题。如下是其余类型的问题（与成本优化\安全性和用户体验相关），在执行实时容器监控时也应该牢记。

未充分利用的资源

容器在低于预期水平的状况下使用资源，可能会被视为滥用资源。例如，信用卡受权微服务致使I/O或网络资源几乎被闲置，这多是重大问题的征兆——不管是受权微服务自己，仍是使用一个或多个的微服务，或可能仅间接涉及信用受权的应用程序的其余部分。

可疑流量

容器监控还可能发现其余形式的异常行为。若是容器正在访问（或只是请求）一般不会使用的资源，或显示I/O模式或网络流量异常，则表示可能存在安全问题。

未知足的需求

容器的异常行为也可能预示着不那么严峻 (但仍然很重要) 的问题，如用户活动的异常模式。例如，若是用户（出于合法缘由）以比原来预期的更高级别访问特定服务，那么您可能须要查看总体架构、部署模式、或者添加新服务以知足当前未知足的（ 或不知足）用户需求。

尽管单个容器更迭速度太快、存续时间可能不长，但关于容器生态系统的一切(基础设施、存储数据、用户交互、资源可用性)却持续焕发着强大的生命力，这些容易受到容器行为的强烈影响，并可能会对您的应用程序性能和您的整个组织产生重大影响。所以，实时容器监控不只重要、并且必要。