简介：随着容器技术蓬勃发展与落地推广，越来越多企业的业务运行于容器中。作为支流部署形式之一，容器将团队的工作和关注点宰割开，开发团队只需关注利用程序逻辑和依赖项，而运维团队只需关注部署和治理，无需再为特定软件版本和应用程序特定配置等应用程序细节而胆战心惊。这意味着开发团队和运维团队能够破费更少工夫进行调试上线，将更多工夫用于向最终用户交付新性能。容器使企业能够更加轻松的进步应用程序可移植性和操作弹性。据 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 监测帮你解脱机械反复的运维工作～

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