您是否实时监控您的容器资源？如果没有，那意味着您可能没有对之进行有效监控。在快速变化的、动态的微服务环境中，即使是几秒钟以前的监视数据也可能不再可行。为了防止中断，您需要实时监控。
在这篇文章中，我解释了为什么对容器资源进行实时监控是很重要的，以及实时监控中您应该关注的容器指标。
首先要明确的是，这篇文章并非在为哪个特定的容器监控产品站台。虽然现在有很多可供容器使用的实时监控平台，但我认为最好的做法，还是充分了解容器监控的基本要素，而不是只关注特定产品的某些特性。如果您知道为保证容器基础设施正常运行需要实时监视什么，那么你一定能选出最佳的、最能满足你的实时监控需求的工具。
实时容器监控面临的挑战
在讨论如何对容器进行实时监视之前,有必要指出实时监视容器所带来的特殊挑战。
最明显的是，在一个容器化的环境中，组件总是会消失。在传统环境中，您监控的大多是相对静态的服务器和应用程序。但容器是不断变化的。
因此，在容器化的环境中，你需要监控更多的东西，甚至会受到更多的干扰。因此，在混乱繁多的数据中甄别有意义的数据是比较困难的，特别是当你需要实时监控的时候，更不应把时间浪费在甄别过程上。
由于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模式或网络流量异常，则表示可能存在安全问题。
未满足的需求
容器的异常行为也可能预示着不那么严峻 (但仍然很重要) 的问题，如用户活动的异常模式。例如，如果用户（出于合法原因）以比原来预期的更高级别访问特定服务，那么您可能需要查看整体架构、部署模式、或者添加新服务以满足当前未满足的（ 或不满足）用户需求。
尽管单个容器更迭速度太快、存续时间可能不长，但关于容器生态系统的一切(基础设施、存储数据、用户交互、资源可用性)却持续焕发着强大的生命力，这些容易受到容器行为的强烈影响，并可能会对您的应用程序性能和您的整个组织产生重大影响。因此，实时容器监控不仅重要、而且必要。