当容器应用越发广泛，我们又该如何监测容器？

简介：随着容器技术蓬勃发展与落地推行，越来越多企业的业务运行于容器中。作为主流部署方式之一，容器将团队的任务和关注点分割开，开发团队只需关注应用程序逻辑和依赖项，而运维团队只需关注部署和管理，无需再为特定软件版本和应用程序特定配置等应用程序细节而提心吊胆。这意味着开发团队和运维团队可以花费更少时间进行调试上线，将更多时间用于向最终用户交付新功能。容器使企业可以更加轻松的提高应用程序可移植性和操作弹性。据 CNCF 的调研报告显示，73% 受访者正在使用容器来提高生产敏捷性并加快创新速度。

作者 | 白玙

随着容器技术蓬勃发展与落地推行，越来越多企业的业务运行于容器中。作为主流部署方式之一，容器将团队的任务和关注点分割开，开发团队只需关注应用程序逻辑和依赖项，而运维团队只需关注部署和管理，无需再为特定软件版本和应用程序特定配置等应用程序细节而提心吊胆。这意味着开发团队和运维团队可以花费更少时间进行调试上线，将更多时间用于向最终用户交付新功能。容器使企业可以更加轻松的提高应用程序可移植性和操作弹性。据 CNCF 的调研报告显示，73% 受访者正在使用容器来提高生产敏捷性并加快创新速度。

为什么我们需要容器监测

在大规模使用容器过程中，面对高动态且需要持续监测的容器化环境，建立监测体系对于维持运行环境稳定、优化资源成本具有巨大意义。每个容器镜像可能有大量运行实例，由于新镜像和新版本的引入速度很快，故障很容易通过容器、应用程序和架构扩散。这使得在问题发生后，为了防止异常扩散，立即进行问题根因定位变得至关重要。经过大量实践，我们认为在容器使用过程中，以下组件的监测至关重要：

• 主机服务器；
• 容器运行时；
• Orchestrator 控制平面；
• 中间件依赖；
• 在容器内运行的应用程序。

在完整的监测体系下，通过深入了解指标、日志和链路，团队不仅可以了解在集群以及在容器运行时和应用程序中发生的事情，也可以为团队进行业务决策时提供数据支持，比如何时扩展/缩减实例/任务/Pod、更改实例类型。DevOps 工程师还可以通过添加自动化告警以及相关配置，来提高故障排除以及资源管理效率，比如通过主动监测内存利用率，当资源消耗接近所设定的阈值时通知运维团队对可用 CPU 、内存资源耗尽之前添加额外节点。这其中的价值包括：

• 及早发现问题，以避免系统中断；
• 跨云环境分析容器健康状况；
• 识别分配过多/不足的可用资源的集群，调整应用程序以获得更好性能；
• 创建智能警报，提高报警精准率，避免误报；
• 借助监测数据进行优化，获得最佳系统性能，降低运营成本。

但在实际落地过程中，运维团队会觉得以上价值相对浅显，似乎现有运维工具都能达到上述目的。但针对容器相关场景，如果无法构建相应监测体系，随着业务不断扩张，就不得不面临以下两个非常棘手的针对性问题：

1、排障时间拖长，SLA 无法满足。

开发团队与运维团队很难了解正在运行的内容及其执行情况。维护应用程序、满足 SLA 和故障排除异常困难。

2、可扩展性被拖累，无法实现弹性。

按需快速扩展应用程序或微服务实例的能力是容器化环境的重要要求。监测体系是衡量需求和用户体验的唯一可视化方法。扩展太晚，导致性能与用户体验的下降；过晚缩小规模，又会导致资源以及成本的浪费。

因此，当容器监测的问题以及价值，不断叠加且浮出水面，越来越多运维团队开始重视容器监测体系的搭建。但在实际落地容器监测这一过程中，又遇到各种各样意料之外的问题。

比如短暂存在特性带来的跟踪困难，由于容器自身存在着复杂性，容器不仅包含底层代码，还包含应用程序运行所需的所有底层服务。随着新部署投入生产，并更改代码和底层服务，容器化应用程序会频繁更新，这就增加了出错的可能。快速创建、快速销毁的特性，使得在大规模复杂系统中跟踪变化变得异常困难。

又比如，由于共享资源带来的监控困难，由于容器使用的内存和 CPU 等资源在一台或多台主机之间共享，因此很难监控物理主机上资源消耗情况，也导致很难获得容器性能或应用程序健康状况的良好指示。

最后，就是传统工具难以满足容器监测需求。传统的监测解决方案通常缺乏虚拟化环境所需的指标、跟踪和日志所需的工具，容器的健康和性能指标及工具更是如此。

因此，结合以上的价值、问题、难点，我们在建立容器监测体系时，需要从以下几个维度进行考量与设计：

• 无侵入性：监测SDK或者探针集成到业务代码是否存在侵入性，影响业务稳定下；

• 整体性：是否可以观测整个应用程序在业务和技术平台方面的表现；

• 多源性：是否可以从不同数据源获取相关指标和日志集进行汇总显示、分析和警报；

• 便捷性：是否可以关联事件和日志，发现异常并主被动地排除故障并降低损失，相关告警策略配置是否便捷。

在明确业务需求以及设计监测体系过程中，有非常多开源工具供运维团队选择，但运维团队还需要评估可能存在的业务与项目风险。这其中包括：

• 存在影响业务稳定性的未知风险，监测服务是否可以做到“无痕”。监测过程本身是否影响系统正常运作。

• 开源或自研的人力/时间投入难以预计，关联组件或资源需要自行配置或搭建，缺乏相应支持与服务，随着业务不断变化，是否可能耗费更多人力及时间成本。且面对大规模场景下性能问题，开源或企业自有团队是否可以快速应对。

阿里云 Kubernetes 监测：让容器集群监测更直观、更简单

因此，基于上述洞察考量与大量实践经验，阿里云推出Kubernetes 监测服务。阿里云 Kubernetes 监测是一套针对 Kubernetes 集群开发的一站式可观测性产品。基于 Kubernetes 集群下的指标、应用链路、日志和事件，阿里云 Kubernetes 监测旨在为 IT 开发运维人员提供整体的可观测性方案。阿里云 Kubernetes 监测具备以下六大特性：

• 代码无侵入：通过旁路技术，无需代码埋点，即可获取到网络性能数据。
• 多语言支持：通过内核层进行网络协议解析，支持任意语言及框架。
• 低耗高性能：基于 eBPF 技术，以极低消耗获取网络性能数据。
• 资源自动拓扑：通过网络拓扑，资源拓扑展示相关资源的关联情况。
• 数据多维展现：支持可观测的各种类型数据（监测指标、链路、日志和事件）。
• 打造关联闭环：完整关联架构层、应用层、容器运行层、容器管控层、基础资源层相关可观测数据。

与此同时，相对于与开源容器监测，阿里云 Kubernetes 监测具备更加贴近业务场景的差异化价值：

• 数据量无上限：指标、链路、日志等数据独立存储，借助云存储能力确保低成本大容量存储。

• 资源高效关联交互：通过监测网络请求，完整构建网络拓扑，便于查看服务依赖状态，提升运维效率。除了网络拓扑之外，3D 拓扑功能支持同时查看网络拓扑和资源拓扑，提升问题定位速度。

• 多样化数据组合：指标、链路、日志等数据可视化展示并自由组合，挖掘运维优化点。

• 构建完整监测体系：与应用实时监测服务的其他子产品，共同构建完整监测体系。应用监测关注应用语言运行时、应用框架与业务代码；Kubernetes 监测关注容器化应用的容器运行时、容器管控层与系统调用，两个监测均服务于应用，关注应用的不同层次，两个产品互为补充。Prometheus 是指标采集，存储，查询的基础设施，应用监测与 Kubernetes 监测的指标类数据均依赖 Prometheus。

基于以上产品特性与差异化价值，我们应用在以下场景：

• 通过 Kubernetes 监测的系统默认或者自定义巡检规则，发现节点，服务与工作负载的异常。Kubernetes 监测从性能、资源、管控三个维度对节点、服务与工作负载进行异常巡检，将分析结果直观地通过正常、警告、严重等状态配合特定颜色进行展示，帮助运维人员直观感知用户节点，服务与工作负载运行状态。

• 使用 Kubernetes 监测定位服务与工作负载响应失败根因，Kubernetes 监测通过分析网络协议对失败请求进行明细存储，利用失败请求指标关联的失败请求明细定位失败原因。

• 使用 Kubernetes 监测定位服务与工作负载响应慢根因，Kubernetes 监测通过抓取网络链路关键路径的指标，查看 DNS 解析性能，TCP 重传率，网络包 rtt 等指标。利用网络链路关键路径的指标定位响应慢的原因，进而优化相关服务。

• 使用 Kubernetes 监测探索应用架构，发现预期外的网络流量。Kubernetes 监测支持查看全局流量构建起来的拓扑大图，支持配置静态端口标识特定服务。利用拓扑图直观强大的交互进行应用架构探索，验证流量是否符合预期，架构形态是否合理。

• 使用 Kubernetes 监测发现节点资源使用不均匀的问题，提前进行节点资源调配，降低业务运行风险。

目前，Kubernetes 监测已经开启全面公测，公测期间免费使用。让 Kubernetes 监测帮你摆脱机械重复的运维工作～

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。