当容器应用愈加普遍，咱们又该如何监测容器？

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

做者 | 白玙

为何咱们须要容器监测

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

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

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

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

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

一、排障时间拖长，SLA 没法知足。

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

二、可扩展性被拖累，没法实现弹性。

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

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

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

又好比，因为共享资源带来的监控困难，因为容器使用的内存和 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 监测帮你摆脱机械重复的运维工做～

原文连接
本文为阿里云原创内容，未经容许不得转载。

​