对大规模容器进行监控所面临的挑战

Chris Crane：嗨，感谢你的邀请！我名叫Chris Crane，是Sysdig的产品VP，这是一家提供容器原生可视化服务的公司。

Kevin McGuire：嗨，我名叫Kevin McGuire，是New Relic的首席产品经理与运维分析师。我负责设定运维以及基础设施监控方面的策略。最近，我致力于开展云监控的产品与工程方面的工作，包括在Docker与Amazon EC2上开发及发布我们的监控解决方案的Beta版本。

Ilan Rabinovitch：很高兴加入这次访谈！我名叫Ilan Rabinovitch，我是Datadog的技术社区主管及传教士。在加入Datadog之前，我曾在Ooyala和Edmunds.com等大型web组织工作了很多年，负责领导基础设施与可靠性工程团队。

Alois Reitbauer：大家好，我名叫Alois Reitbauer，在Dynatrace和Ruxit担任首席技术战略师。我在职业生涯的大部分时间内都在从事与监控与性能有关的工作。我现在的主要工作方向是研究如何更好地对大规模环境进行监控，例如使用微服务、容器和IOT的环境，并研究如何让人们更方便地与监控系统进行交互。

Crane：容器以及基于容器技术的微服务的出现，让软件应用的开发与部署产生了一种范式变换。正如之前几次新范式的出现一样，我们看到了一个由各种支持性技术打造的生态系统正在冉冉升起，而这些支持性技术都是基于新的平台完全重新打造的。包括安全性、网络、存储，当然还包括监控与可视化。

这种“全新的开始”的方式对于监控工作尤为重要，这就产生了容器可视化的核心挑战：早期的监控工作是为了VM的应用而设计的，可将用于监控的agent部署在与应用的监控相同的地方。而这一方式已不适用于容器环境。

容器的核心原则要求他们必须保持轻量级、可再生，并且不受agent的影响。因此，如果监控方案真的打算做到对容器的原生支持，那么必须以一种可兼容每个容器的不可变性、可移植性以及可再生性的方造进行打造。如果你仍希望能够从容器中获得完整的应用可见性，那么实现这种方案是非常困难的，而这种可见性往往是监控的关键。

McGuire：随着人们不断深入探索微服务的益处，我们发现容器正在用于小型的、生存时间较短的工作。与此同时，容器也在用于大型的、运行时间较长的服务，这一点可视为对使用VM方式的优化。对于前一种情况来说，它需要以一种不同的方式对于容器进行监控，而这两者的同时存在就意味着以一种单一的方式进行监控无法满足这些完全不同的使用场景的需求。举例来说，监控工具应当能够提供应用程序的可见性以及每个容器的资源指标，同时还需要提供镜像级别的资源占用的汇总情况，这更适合短期容器的状况。

每个容器内都包含一个应用，但监控API往往专注于资源层面的信息。从host的角度来说，这是可以接受的。但最终，你总是需要能够从容器内部以及跨容器这两种角度来分析应用的性能。

最后，随着容器越来越小，数量越来越多，要了解这些容器之间的相互依赖、维护大规模环境中的运维健康情况，并且进行根本原因的分析也变得很有挑战性。

Rabinovitch：许多人在对容器监控时所遇到的最大挑战是高频率的变动，这就很难定义什么是“正常”情况，并对非正常情况发出警告。对于AWS、OpenStack和其他虚拟化解决方案来说，这个问题已经出现了很多年，但对于发展时间较短的容器技术来说，这一问题显得尤为严重。

我在此可以为你分析一下这些系统的规模与变更频率，我们近期对于 Docker的使用与实施情况 进行了一些调查，发现大多数主机倾向于并行地运行4个容器，每个容器的生命周期都小于主机生命周期的1/4。这就意味着我们的监控工具不能再向以往一样，将主机作为进行监控的主要单位了。

我们接下来又问了几个问题：“Redis集群或是NGINX服务器目前运行在哪里？Kubernetes是否出于可用资源的原因将其迁移至另一个主机，还是说出现了故障情况？”

如果你的监控方式是以主机为中心的，那么你的世界看起来就像是托勒密天文学理论（即地心说）一样复杂。如果你想将行星的移动与地球关联起来，将很难推导出他们的移动规律。而如果你将太阳作为太阳系的中心，整个计算就变得简单许多。这意味着你或许应当依赖于你的调度器的服务发现中的数据，以及容器相关标签以定义各种查询与监控问题。这样一来，无论在系统的任一时刻，服务运行在哪个主机或端口上都不会影响分析的结果。

Reitbauer：以我们在大多数企业中的工作经验来看，容器对于我们构建软件的方式产生了一种实际的范式转换，这也导致了大量挑战的出现。而大规模化很显然是其中的一种挑战，实施了容器技术的公司在大多数情况下会同时选择迁移至微服务架构。通常来说，当一体性应用被分解为服务时，所牵涉到的实体数量会大大提高。以我在Java开发方面的经验来看，通常在微服务环境中所运行的JVM数量比之以往提高了10至20倍。这也意味着一个合理大小的系统却需要这些工具管理“web规模”的系统。

我们所注意到的另一个变化就是对基于Mesos、Marathon或Kubernetes打造的编排层的应用。其结果就是应用程序架构具有极高的动态性，可迅速地进行向上或向下伸缩。对于这种动态性的理解是掌握系统的关键，而许多传统的监控工具并没有准备好应对这种需求。除了对这些环境的动态性的理解之外，还有大量的问题也浮出水面，例如如何在这些环境中进行日志的管理，以及基础设施的监控工具应当扮演怎样的角色，及采用怎样的方式。

至于最关键的挑战是什么，这取决于公司对于容器的应用达到了什么阶段。动态的编排能力仍然是一个高端领域，人们还在逐步地探索这一领域。而与之相比，应对web规模的环境是一旦应用容器后立即就需要着手实施的。

Crane：Adrian Cockcroft的说法是正确的。如果你已经完成了新的面向微服务的应用，却尝试用一个一体性的旧式工具进行监控，它是无法胜任监控的需求的，这正是最糟糕的情形。在Sysdig公司，我们将这应对这种挑战的解决方案称做“监控即微服务”，它的思想是你的监控方案应当能够和你的所有微服务一样方便地进行部署以及扩展。你的监控方案必须尽可能做到自动化、自服务、以及自动复原，并且集成自动服务发现的概念。如果你的监控工具本身就是按照微服务原生、容器原生的架构打造的，那么它更有可能跟上你的需求。不过，如果你做不到这一点，那么很不幸，Adrian的想法就是非常不实际的。

McGuire：监控系统的高可用性是非常重要的。如今的DevOps实践越来越依赖于通过监控系统对问题所发出的警告，因此监控系统就成了一道不可或缺的安全网。这也是为什么我们认为基于SaaS的监控方案是正确的选择，因为同时运行及维护一个监控系统以及一个需要进行监控的系统使得某个问题在你未留意的情况下影响整个系统的可能性被放大了。

微服务增加了监控系统的规模以及复杂性，但它也提供了各种能够增加可用性的实践，例如将相同的容器部署在不同主机，或是在相同的主机中部署不同容器的能力，并提供了各种应用模式。

Rabinovitch：Adrian的说法可谓一针见血。你必须理解一点：负责检测应用故障时间的系统必须保证在线及可用性。

但是，虽然这是一个明确的需求，但实现它要克服各种挑战，这也是为什么我们认为SaaS方案是最佳的选择。根据我们的调查来看，一个Linux主机平均会生成大约100个关键的操作系统级别的指标，而你的应用还会增加大约50个指标。随着每个主机中所运行的容器数量的提高，这些指标的数量会快速地上升。

这就给我们出了一个难题，如何才能够保存你的应用与基础设施每天所生成的几十亿指标数据呢？在很多情况下，这个问题的回答与你的核心应用的基础设施同样复杂，甚至是更为复杂。现代化的监控系统本质上就是一种“大数据”问题，这也意味着你需要管理这些复杂的分布式数据的存储，以及支持这些存储系统的大型计算基础设施。

Reitbauer：其实这已经不是什么新鲜的概念了。监控系统的主要目的就是当你的应用当机时向你发送通知，而这就要求这些系统基本上保持始终正常运行。为此，我们创建了一种全新的架构，以保证最大的在线时间。所有的组件都能够支持实时的故障转移，我们还创建了一个自动化管理层，以检测有问题的组件，并自动替换这些组件。为了支持实时故障转移，以及实时应对负载峰值，我们在集群中保留了三分之一的计算资源。

很显然，这与基于单一服务器的传统监控工具的概念是完全不同的。

Crane：监控系统的主要目的就是提供洞察力，不是吗？我认为这里的关键在于为每个指标与数字提供适当的上下文。举例来说，容器生态系统的一大发展趋势就是采用各种调度、编排以及管理工具，例如Kubernetes、Mesos，以及Docker自主设计的Swarm等等。这些工具为你的底层容器提供了一层额外的抽象，他们真正地促进了向基于容器的微服务的迁移。

编排系统会使监控与可视化增加很大的复杂度。系统的最终表现不再是一个经过良好组织的VM或容器集群，而是一个具有高度可伸缩性、分布式、分散的容器集合，他们在一个共享的资源池中以混合方式存在。如果你的监控方案只是简单地获取这种环境中的指标，哪怕是基于容器的指标，这种方案也没有很大的实用性。你的监控方案需要理解编排系统为容器产生的语义上下文。换句话说，你需要查看的是应用或微服务层面上的性能指标，甚至提供这些微服务的容器存在于多个不同的底层节点上。这就是洞察力的来源。

McGuire：从本质上说，这就是数据与信息的不同之处。仅有原始的指标数据是不够的，需要为他们提供上下文加以解释。因此，我们设计了一种展现客户所需了解的信息的UI，专注于那些需要我们展开相应行动的数据。对于设计和实用性的专注可帮助我们忽略那些无意义的数据，让运维人员快速地进行正确地判断，并迅速地进行重要的决策。

Rabinovitch：一般来说，监控系统依赖于运维人员定义什么是“正常的”行为。由于现今的动态环境会受到自动扩展以及调度的基础设施的影响而不断产生变化，对这种正常行为的定义就成为了一种挑战。目前为止，监控服务的社区在自动收集指标，并对于那些预定义的阀值发出警告这方面做得很好。我们现在需要的是专注于通过算法检测那些有问题的部分或反常情况，并发出这方面的警告。

Reitbauer：让我换一种方式描述这个问题，“监控工具如何为公司里每个需要某些信息的人提供洞察力”。DevOps与微服务的崛起产生了许多端到端的团队，他们负责应用的整个生命周期，从开发直至监控阶段。因此，每个人都必须了解这些监控数据。这也是为什么我们花费了大量时间以创建自解释的信息图表，让每个人都能够其中的意义。

另一个关键需求是对异常情况的检测。由于系统的巨大规模，没有任何人能够做到手动查看所有数字。因此，监控系统必须了解什么是正常的行为，并当系统的行为出现异常时进行提示。

最后一个方面在于具备上下文的语义信息。举例来说，监控系统需要“理解”指标所代表的意义，以及它与其他指标的关联。我们需要了解整个应用中的所有依赖，将这此信息用于问题的分析。

Crane：无论是在公有云、私有云或是数据中心环境中，在VM的基础上部署容器的方式目前来说似乎是最流行的方式。不过在我看来，无论这个市场选择哪种方式进行大规模实施，可以说每种方式都有适合它的大量用例。未来的发展结果或许会类似于这些年来混合云方式在企业中的逐渐发展，这种混合云是公有云、私有云、OpenStack、虚拟数据中心和裸机等方式的组合。我对此结果不会感到吃惊。对于监控来说，这就意味着你的可视化解决方案必须是与具体的技术栈无关的。谁都不希望在不同环境中来回切换，也没有人希望只为了尝试新的环境（还没到开始迁移的过程）就必须切换不同的供应商。

McGuire：我认为容器与PaaS之间存在着某种共性，他们都能够让开发者从基础设施的管理中解放出来，让他们专注于能够实际带来价值的东西，即应用程序本身。这是他们的商业价值所在。

对于基础设施的管理是需要投入成本的，你所能做的就是通过更高的效率与更好的可靠性进行成本优化。IaaS能够为你减少一部分这样的成本，因为你无需对物理基础设施进行维护，但你仍然要对服务进行管理，以确保你以最优的方式进行使用，并及时地响应变更。监控在此处的作用就是为服务的使用情况提供深度的可视化情形，由于这与应用程序的性能密切相关，你可以根据其结果调整系统的效率、可靠性与可用性。在云计算环境中，缺少效率就意味着账单上数字的增加。因此，成本即是最终的性能指标。

在理想的情况下，监控系统应当提供与你所要解决问题处于同一概念级别的可见性。当你的系统迁移至微服务架构时，“应用程序”的概念也变得模糊起来了。这就意味着你需要一些高层次的视图，从中了解高于个别的容器这一层次的信息，从总体上观察他们的表现。

我们未来将看到“计算即服务”这一概念的不断发展，它超越了IaaS与PaaS的概念。Docker容器已经通过微服务涉及了这一领域，而AWSLambda已处于概念的发展前沿。最终的挑战在于理解这一发展趋势对于监控计算的意义。

Rabinovitch：变更的频繁还将持续提高，包括来自调度器以和自动伸缩工具产生的变更，以及基于这些技术进行部署的速率的变更。这一趋势将继续驱动监控系统更好地与平台和调度方案进行集成，使监控系统能够在这些变更发生时以更自动化的方式进行响应。与之类似，我相信未来会看到这方面一些通用模式的产生，通过这些模式使监控系统直接将反馈信息发送至IaaS、PaaS以及调度方案中，使我们得以构建更自动化的响应，以及更紧凑的反馈循环。这将继续驱使监控与警告系统提高他们的实时性。

Reitbauer：对基础设施的关注已经开始减少。由于容器的使用，我们对于底层基础设施的具体情况的关注度也在不断减少。在很多场景中，同样的应用可能会部分运行在IaaS、另一部分运行在裸机上，这只是其中一种可能的情况。这对监控工作的最大影响在于其专注点已经转移至应用程序这一层面。由于故障节点会被自动替换，因此基础设施的故障其严重性已经在逐渐降低。监控工具的主要关注点转变化实际的服务与其质量，我所关心的是服务的响应时间以及故障率。老实说，如果你的监控工具主要的关注点是基础设施，那么就无法有效地获得运行基于容器的服务所必需的信息。