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

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

作者：Daniella Pontes 和 Luca Deri

容器对每个人来说都是游戏规则改变者。容器是基础设施层和应用程序层之间的抽象，是一种集体协作，关系到 IT 系统工程师、运维、网络运维和开发运维。然而，不同角色的专业人员从不同的角度看待容器监控，这些角度都是有效且重要的，并且是构建完整监控策略所必需的。

随着应用程序分离为在集群中运行的容器化微服务，每个容器都打包了执行其部分任务所需的资源。然而，除非其工作负载、对等方以及将各个部分组合在一起的网络同样具有高性能，否则各部分的总和将不足以交付满足性能和服务级别目标的应用程序环境。

容器和网络的新监控指标

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

一方面，在符合所需最佳声明状态的集群上运行的不良或性能不佳的微服务仍然会对网络和整体应用程序性能产生破坏性影响。另一方面，观察进程如何处理工作负载以及哪些服务从容器内部生成它们，可以为改进应用程序性能提供非常积极的结果。由于容器的一次性性质和进行这些观察的短暂时间窗口，说起来容易做起来难。

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

IT 经理必须保持其监控的敏锐性，以关注来自编排系统、容器和节点的指标；网络运维必须控制网络延迟、服务可用性、响应速度和带宽消耗。除非也密切关注在此容器化基础设施上运行的微服务的健康状况及其庞大的网状容器间网络，否则容器化应用程序监控将受到目光短浅的影响。

很明显，仅从外部进行监控是不够的，尤其是对于那些全栈团队而言。对于这些团队来说，每一层和每个移动部件都需要和谐地工作。考虑到这一点，微服务的性能监控以及它如何影响容器间流量，比资源可用性（通过终止和启动新的 Pod 和容器来实现）更能显示问题正在酝酿的地方。为此，有必要了解内部发生的事情。

测量资源和服务指标

基本资源监控指标（例如 CPU、内存和磁盘空间）在 Kubernetes 上得到了很好的覆盖，主要在三个方面：容器、节点和主节点。其他特定于应用程序的指标和事件监控可以通过部署 Sidecar 来完成。然而，当与从微服务性能角度收集的信息相关联时，可以更好地理解资源使用率、饱和度和故障的症状，其中包括

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

容器活动会影响基础设施、网络利用率和应用程序性能；因此，不应忽视它。任何事情都不应被认为是理所当然的，因为速度和复杂性没有留下太多猜测的空间。容器化应用程序环境的周密监控计划必须包括验证容器内部和容器之间正在发生的事情的方法——识别出现故障、滥用或可疑行为的用户、进程、Pod 和容器。

诸如进出数据包检查和基于 IP、端口和协议将数据包分组为流的方法提供了一种可行的方法来监控带宽利用率以及检测非法的、恶意的和格式错误的数据包。然而，那是在容器激增之前。对于容器化应用程序，数据包范例已不再足以提供必要的可见性，因为它们不携带上下文（即应用程序、用户、进程、Pod 或容器），因此监控它们不会提供对问责制的预期理解。有时服务在系统内部而不是通过网络进行交互，在网络中可以捕获数据包。更糟糕的是，当今网络和应用程序的运行速度要求网络数据包分析器提高数据包处理速度，从而给 CPU 带来巨大的负载。人们也可以说，使用数据包仅仅是因为网络是基于数据包的，但应用程序看不到数据包。它们根据发送/接收的数据、操作延迟和代码响应来运行。因此，与其使用数据包级数据来推断应用程序信息，不如直接读取系统指标来提取所需信息，而无需“转换”，这更有意义。作为额外的奖励，采用系统内省方法对系统造成的计算负载更轻。

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

InfluxData 及其合作伙伴ntop正在使用扩展伯克利数据包过滤器 (eBPF)，在监控容器化应用程序环境方面迈出下一步。这项工作将揭示容器内的活动，以指导 IT 部门找出哪些地方已损坏或正在损坏，以及谁是造成性能问题的原因。

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

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

以当前的网络速度，任何有意义的采样率都会生成大量数据包进行检查，消耗宝贵的 CPU 周期。如果部署在托管云环境中，这些周期将缓慢而肯定地耗尽预算。

微服务之间的流量可能永远无法到达受监控的接口。因此，将没有机会捕获它们。

将 eBPF 监控添加到数据包检查会将系统事件绑定到网络流量，这样做可以提供必要的上下文多维度，以减少监控数据的熵并将警报定向到可操作的信息。缩小活动范围，确定谁以及什么对正在监控的进程负责，这是两种方法都无法单独完成的事情——更不用说高效且有效地完成了。

在这个瞬息万变且复杂的临时容器基础设施和碎片化应用程序世界中，组织必须变得数据驱动，才能应对日益增长的性能期望。监控必须超越孤立资源的可用性、消耗和性能。它必须提供双筒和全景视图，以便充分了解正在发生的事情以及可能正在酝酿但未被发现的事情。监控必须揭示趋势，同时提供实时洞察力——并最终寻求预测和自动化。

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

指标、事件和网络流量的统一位置

eBPF 开辟了一条新的通道，可以在分布式容器化环境中获得内部系统所需的观测性，从而将异常行为和性能变化联系起来。但是，为了连接各个点，来自指标、事件和容器内/容器间事件的所有信息都需要在一个能够充分利用这些数据并结合对其进行交叉分析的平台上。

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