天旦在容器化应用的业务性能监控的技术突破
本文将以Kubernetes 架构为例（以下简称 k8s）分享技术思路，以促进行业的共同进步。
随着应用开发和部署流程进一步跟上需求迭代速度，调度资源更灵活、方便集群化部署的容器架构逐渐推广开来。相比虚拟机为单位的云架构，封闭程度更高的容器化应用更难以实现监控。经过专享技术公关，天旦在容器化应用的业务性能监控上取得了瞩目的技术突破，在此以 Kubernetes 架构为例（以下简称 k8s）分享技术思路，以促进行业的共同进步。
容器化应用的原有监控方式
K8s 架构中，应用连同其依赖组件被打包为高度独立的单元，称为「容器」。容器化的业务应用尽可能降低了对外部环境的依赖程度，因此可以由控制器快速创建、配置和调整，灵活性非常高。但容器是一个相对完整而封闭的结构单元，使得对其中的业务应用进行监控十分困难。
现有技术方案的痛点与不足
- 虽然上述从物理机底层捕获流量的方式可以满足应用监控需要，但仍存在诸多不足：
- 底层插入 agent 的技术模式对系统侵入程度较深。在金融业特别是银行业，业务系统的连续性与可用性是拥有至高优先级的，对系统的深层嵌入与修改可能会引发很多不确定性技术隐患，对业务系统的影响较大，引发客户对系统稳健性的担忧；同时，私有云的技术解决方案多种多样，部分公有云的私有化部署方案甚至不允许对系统底层进行变动，影响了技术实施；
- 深入系统底层的 agent 拥有远超一般应用的权限，可能在企业和机构的安全策略上形成特例；金融行业的高敏感性使得企业的安全合规要求十分严格，过多权限让客户对安全性有所顾虑；
- Agent 通过网络组件捕获到的流量数据是全部经过本机的数据包，数据量十分庞大，需要经过过滤后再送往 BPC。这一过程不仅影响了数据的实时性，更消耗了大量的计算资源。
在业务上云前期，从物理机底层获取流量的技术方案很好地解决了业务环境变动带来的监控挑战。但随着企业对于云的应用程度加深、集群技术愈发成熟，次世代业务环境下的应用性能与业务监控需要更高效、灵活的技术解决方案来满足。
为容器集群而生
K8s 架构下，应用虽然被打包为一个个容器，但系统对其管理是通过名为 Pod 的结构实现的：一个 Pod 中可以放置单个或多个应用容器，这些同 Pod 的容器共享 Pod 内的网络、存储等资源，彼此之间可见。利用这一特性，天旦技术团队通过深入研究与技术公关，实现了 Sidecar 模式的应用监控。具体原理如下：
在同一个 Pod 内配置业务应用容器与用于流量采集的 packet-agent。由于两者共用该 Pod 的网络资源，packet-agent 可以通过网卡端口捕获同 Pod 内的应用容器的网络数据，并通过 GRE 等方式将捕获到的流量实时转发至 BPC。
通过向集群控制器制定配置文件，在控制器对 Pod 进行升级、转移、重启等操作时，Pod 内的应用容器与 packet-agent 会同时关联启动，自动恢复应用流量的捕获与转发。
这种共生结构就是 K8s 中非常成熟的 Sidecar 技术模型，过去常用来采集应用日志。天旦团队开创性地借助这一思路实现了业务应用网络流量的采集，成为为容器集群架构而生的应用性能监控方案。
新技术方案的巨大优势
为容器集群而生的 Sidecar 流量捕获技术带来了巨大的技术收益：
- 容器的变更相比虚拟机更加灵活多便，而通过设置 Pod 的启动配置文件，可实现应用监控的自动化部署，大大提升运维效率，减少机械操作的人天资源浪费；
- packet-agent 与应用容器通过 pod 共生，因此应用重启、升级等变更后可以及时恢复流量捕获，避免监控盲区；
- 对 Pod 配置文件的设置是用户现有权限，不必增加特殊权限与安全特例；无需侵入系统，对系统底层的适配性非常广，同时不影响整个工作节点稳定性；
- 最大的优势是，packet-agent 针对同 Pod 应用进行流量捕获，可按照实际需求指定所监控的对象，实现性能监控的精细化管理；「按需捕获」极大减少了与业务监控无关的数据包，减少了计算负载，提高了数据实时性和处理效率。
不断进化的技术未来
联系我们
在线咨询
马上与我们的销售代表取得联系，
了解更多天旦产品性能以及如何提升您的业务。
或通过以下方式联系我们
微信
