容器时代下的 IT 监控：利用 eBPF 可观测性

作者：Daniella Pontes / 用例，开发者
2019 年 7 月 15 日

Daniella Pontes 和 Luca Deri 撰写的文章

容器对每个人来说都是一场变革。作为基础设施和应用层之间的抽象，容器是一个团队游戏，涉及 IT 系统工程师、运维、网络运维和 DevOps。然而，不同角色的专业人士从不同的角度接近容器监控，所有这些都是有效且重要的，对于构建完整的监控策略是必要的。

随着应用程序被分离成在集群中运行的容器化微服务，每个容器都打包了执行其部分所需的所有资源。然而，除非其工作负载、对应关系以及将这些组件组合在一起的网络的性能同样出色，否则各部分的组合将无法提供满足性能和服务级别目标的完整应用程序环境。

针对容器和网络的新的监控指标

容器监控——从基础设施的角度来看——已经随着像 Kubernetes 这样的系统取得了长足的进步。重点已经从单个容器的健康状况转向集群的健康状况。这是因为 Kubernetes 通过提供逻辑层来简化编排，将微服务运行的基础设施层商品化，同时自动化部署并优化资源分配。降低了基础设施成本，提高了灵活性——这是一个非常好的价值主张！然而，这种新的方法有其优点和缺点。

一方面，在符合预期最佳状态的集群上运行的运行不良或性能不佳的微服务，仍然可能对网络和整体应用程序性能产生破坏性影响。另一方面，观察容器内处理工作负载的方式以及哪些服务在生成这些工作负载，可以提供关于应用程序性能改进的非常积极的结果。由于容器的可丢弃性和观察这些现象的短暂时间窗口，这比说起来容易做起来难。

遇到问题或表现不佳的微服务可以在容器之间、主机之间、接口之间移动。仅从外部观察容器化微服务环境中的低性能应用程序的中心，就需要追踪一个移动的、间歇性的目标：这是诊断团队最糟糕的噩梦。

IT 经理必须保持对编排系统、容器和节点指标的监控敏锐；而网络运维必须保持网络延迟、服务可用性、响应性和带宽消耗在可控范围内。除非对运行在容器化基础设施上的微服务的健康状况及其庞大的、交织的容器间网络也保持关注，否则容器化应用程序监控将受到短视的影响。

很明显，仅仅从外部进行监控是不够的，尤其是对于全栈团队来说。对于这些团队来说，每一层和每一个活动部件都需要协同工作。因此，微服务性能监控及其对容器间流的影响，不仅包括资源可用性（通过终止和启动新的Pod和容器来实现），更能显示出问题所在。为了做到这一点，我们需要了解内部发生的情况。

测量资源和服务指标

基线资源监控指标——如CPU、内存和磁盘空间——在Kubernetes中有三个主要方向：容器、节点和主节点。通过部署边车可以进行额外的应用程序特定指标和事件监控。然而，当与从微服务性能角度收集的信息相关联时，可以更好地理解资源使用、饱和和失败的症状，这包括

• 延迟：处理请求的时间
• 流量生成：与其他服务的通信
• 错误：错误发生的频率

容器活动影响基础设施、网络利用率和应用程序性能；因此，不应被忽视。没有任何事情可以想当然，因为速度和复杂性留给猜测的空间不多。一个有思想的容器化应用程序环境监控计划必须包括验证容器内部和之间的活动的方法——识别表现出故障、滥用或可疑行为的使用者、进程、Pod和容器。

例如，通过入出包检查和根据IP、端口和协议对包进行分组的方法，可以提供一个可行的带宽利用率监控以及检测非合法、恶意和畸形流量的方法。然而，在容器数量激增之前是这样的。对于容器化应用程序，仅使用包范式已不足以提供必要的可见性，因为它们不携带上下文（即应用程序、用户、进程、Pod或容器），因此监控它们不会提供所追求的责任感。有时服务是在系统内部而不是在网络上交互，而在网络中可以捕获数据包。更糟糕的是，今天网络和应用程序的运行速度要求网络数据包分析器提高数据包处理速度，这给CPU带来了巨大的负载。也可以说，使用数据包仅仅是因为网络基于它们，但应用程序并不看到数据包。它们根据发送/接收的数据、操作延迟和代码响应来操作。因此，与其使用数据包级别的数据来推断应用程序信息，不如直接读取系统指标以提取所需信息，无需“翻译”。此外，采用系统内省方法还可以在系统上产生较轻的计算负载。

获取容器上运行的工作负载的系统信息的一种方法是通过eBPF收集内核事件。这项技术最初作为伯克利数据包过滤（BPF）由Lawrence Berkeley国家实验室的Steven McCanne和Van Jacobson引入，是一种Linux内核技术，用于内核中的数据包过滤。eBPF扩展到处理多种类型的事件，执行除数据包过滤之外的操作。在使用eBPF时，可以将内核事件与网络流数据相关联，客观地识别哪些容器参与了通信会话。这将指向哪些用户、进程和容器表现出异常行为。

InfluxData及其合作伙伴ntop正在利用扩展的伯克利包过滤(eBPF)技术，迈出监控容器化应用环境的新步伐。这项工作将揭示容器内部的活动，帮助IT部门找出问题所在，以及导致性能问题的责任人。

将网络指标与eBPF事件数据进行关联

通过eBPF进行系统自省在基础设施和网络监控中扮演着添加上下文的角色。这使得可以快速识别根本原因，并在容器部署场景中成为唯一可行的交互信息来源，主要原因有两个：

在当前的网络速度下，任何有意义的采样率都会生成庞大的数据包处理量，消耗宝贵的CPU周期。如果部署在托管云环境中，这些周期将逐渐消耗预算。

微服务之间的流量无法真正达到监控接口。因此，将无法捕获这些流量。

将eBPF监控添加到数据包检查中，将系统事件与网络流量绑定，这样做提供了减少监控数据熵并针对可操作信息进行警报的上下文多维度性。将活动缩小到谁和什么是监测过程中需要负责的，任何一种方法都无法独立完成——更不用说高效有效地完成了。

在这个新的快速和复杂的世界中，临时容器基础设施和碎片化应用，组织必须成为数据驱动的，以应对不断增长的性能预期。监控必须超越孤立资源的可用性、消费和性能。它必须提供双重视角和全景视图，以便更好地了解正在发生的事情和可能未被发现的潜在问题。监控必须揭示趋势，同时提供实时洞察——最终寻求预测和自动化。

为了实现这些目标，IT部门应考虑容器间流量和容器内事件，并将这些数据与其他指标和信息关联起来，从而确定问题开始的地方：容器、进程和用户。

一个地方收集指标、事件和网络流量

eBPF为在分布式容器化环境中连接异常行为和性能变化所需的内部系统提供了另一个可观察的渠道。但为了连接这些点，所有来自指标、事件和容器内/容器间事件的 信息都需要在一个平台上进行整合，该平台能够充分利用这些数据，并对其进行联合交叉分析。

所有数据都应该汇聚到同一个地方，并减轻从设置、启动、管理以及从多个孤立源收集信息片段的负担。ntop eBPF解决方案使用InfluxDB作为其时间序列存储引擎，因此可以包括所有类型的监控数据，如指标、内核事件、日志、跟踪和业务KPI。这组汇聚的指标和事件在用于警报和预测建模时非常有用。容器时代的复杂性要求一个集成的数据源，一个用于多种数据类型分析的分析引擎，以及一个用于所有可视化的UI。将所有这些整合在一起将增强洞察力和视角，从而形成一个能够实现更智能警报和可操作信息的监控解决方案。