【华为云Stack】【大架光临】第10期：云原生时代，政企混合云场景IT监控和诊断的难点和应对之道

一、政企混合云的架构演进和监控诊断进化路线解析

随着2013年云原生(Cloud Native)概念的正式提出到现在，云原生架构发展已经历了快10年了。虽然发展过程中，其概念被CNCF组织、各大云厂商不断丰富和发展，但是其核心理念——面向大规模分布式场景的微服务和容器化架构，一直贯穿其中。伴随着政企的IT架构从传统的单体烟囱式架构朝着云化的云原生架构迈进，IT的监控诊断难度也随之指数级增加。正是因为政企IT架构云化的云原生架构，相比之前的单体烟囱式架构，在监控诊断方面有着更多的难点和挑战，这也在业界催生出大量相关的标准和工具。以下举出5个例子，分别从微服务架构、容器弹性架构、海量中间件、SDN网络、云管平台 五个维度加以说明。

海量微服务化的业务应用架构，催生出基于全链路追踪的APM工具

传统的政企IT架构，由于按照项目进行"烟囱式"建设，演化出一个个单体应用。虽然在架构扩展性上存在一定问题，但是对于运维人员来讲，运维难度相对较低。传统的IT运维人员只需要熟悉相关的OS, 中间件，和相关应用软件的运维操作即可。但是在微服务架构下，由于整体业务无论在横向还是纵向的划分上，都进行了很大程度上的拆分，导致运维难度快速上升。例如对于一个基于微服务架构改造后的电子商务系统，核心的交易应用突然异常的情况下，到底是应用本身某个单实例或所有实例出了问题，或是应用的下游中间件出现问题，还是应用的下游的某个应用出了问题，这些各种异常的可能性，都大大增加了微服务架构下的应用诊断难度。显然，常规的针对单体应用的上线看日志诊断故障的思路已经不能满足运维需求了。

基于以上问题，业界提出了分布式链路追踪的解决方案。其核心思路始于Google Dapper的论文，通过注入trace、span等信息打通微服务之间的调用，以对复杂微服务的环境下对业务问题进行面向微服务的故障定位。类似的开源界标准 Opentracing, 开源社区如Pinpoint，Jaeger等，包括各类商业化APM产品也大都基于此原理解决该场景的运维问题。

面向容器的弹性架构，强调故障时动态运行现场信息采集

相比于传统物理机或虚拟机架构，面向容器化架构的故障诊断又为运维难度带来新的挑战。首先，应用不再是静态地和计算资源绑定，而是动态地基于容器调度器实时调度。比如事发故障到底是在哪天物理机或虚拟机上？根因可能是因为什么资源故障引起的？这些都变得难以判断。其次，由于容器进程默认进程结束后，相关资源会被清理，导致现场信息收集难度进一步加大。比如，崩溃内核文件在哪里？现场日志文件哪里找？在默认情况下，由于文件系统会被清理，上诉关键文件或信息都无法获取。

由此衍生出的各类的容器监控服务、日志服务，重点解决此类问题。专业的容器服务除了收集容器性能指标以外（如cadvisor、promethues），还需要重点保留现场的容器拓扑快照（如kur8），以方便进行问题场景还原。与此同时，日志服务(如ElasticSearch+Logstash组合)被广泛用于容器场景，保证重要的日志文件都能动态地被服务采集收集到云端，在必要的时候在POD即便已被销毁的情况下，对第一故障事发现场进行有效还原。

分布式应用架构下海量中间件监控难度提高，引出面向标准化的Metrics、Log采集和分析工具

传统架构下的单一应用仅需传统关系型数据库即可。由于架构和业务简单，除了传统的事务类信息，其他信息比如日志、时序数据、甚至消息 (参考rabbitmq实现) 都有可能通过数据库实现。因此在传统架构下，往往核心中间件只需要掌握数据库运维一个核心技能即可。但是在云原生时代，随着业务的多样化，规模化，各种极限场景下发挥出色的 NoSQL数据库和其他各类中间件 层出不穷。例如使用缓存解决高性能场景、使用消息进行业务系统解耦、使用搜索引擎解决各类复杂搜索场景，使用列存数据库应对时序时空数据，使用ZooKeeper、Etcd确保分布式场景下的数据一致性等等。复杂系统对人员的运维水平提出新的挑战。如何针对这些中间件提供有效统一的运维手段，也成为运维的关键难点。

为了统一运维语言，业界也基于Promethues演化出了OpenMetircs的实时标准。由此，各中间件自行提炼出核心关键的性能指标，并以OpenMetrics标准对外予以暴露，逐渐变成了行业标准。再加上流行的Promethues + Grafana架构不仅可以基于数据采集标准进行实时数据收集和报警的同时，还可以基于采集数据快速定制可视化的报表或大盘，大大方便了业务人员第一时间定位业务问题。借此，虽然专业的各中间件专业级运维难度仍然居高不下，但是核心的业务指标的提炼和开发直接下层到了各商业或开源中间件社区本身，从而大大降低了运维人员的入门门槛。

虚拟化SDN网络架构普及，面向软硬一体的网络监控成为刚需

传统架构下，物理网络、VLAN、VxLAN的应用基本上能应对大部分网络需求。但是在云原生架构下，往往需要借助更复杂的SDN和网络虚拟化来进一步解决网络问题。从容器、虚拟机网络出口，到虚拟机交换机、虚拟机路由器、虚拟防火墙、虚拟网络负载均衡、虚拟终端节点，再到底层物理网络设备，中间任何一个节点出现问题，将导致上层应用链路出现故障。而由于中间的网络链路往往过于复杂，导致诊断难度也同样无限放大。

为应对复杂的云网络监控需求，大量针对SDN的NPM网络监控技术也运营而生。此时的网络监控工具不仅能对各个维度，譬如vlan，站点,vxlan, QoS等进行自由组合分析，还需要全面支持虚拟化的网元监控。这里面既包括通过主动拨测技术监控宿主机内部虚拟机之间的流量；又能够基于SDN控制器通过ERSPAN技术创建虚拟镜像端口或者其它方式来获得镜像流量，进行特定场景的问题诊断或后续大数据分析。最终，结合相应AI算法和网络知识图谱，运维人员针对SDN的网络运维得到极大简化。

由于云平台本身的复杂运维，专业的云管平台运维工具成为标配

云计算相对于传统IT架构来讲来讲，云管平台本身的运维是一个复杂的课题。试想一个IOE架构下的网络设计，在小型机上的网络设置，无论是中间件运维和还是数据库运维，都是针对业务本身的运维，并不涉及复杂的平台运维。但是在云时代，由于云平台的管理本身是一个非常复杂的系统，对租户应用一般不可见，再加上其本身之上承载了很多租户面的运维工具，为了防止循环依赖，因此如何针对云管平台本身的运维是各个云厂商需要亟待解决的问题。

二、混合云全栈中的监控诊断的工具孤岛问题

在云计算方面，对于以上各个领域的组件运维，似乎业界都有比较明确的架构思路和相关产品。但是当各类方案和架构放一起的时候，往往运维人员会变得无所适从。

试想，在基于云原生业务架构的混合云运维场景中，您的记忆中是否出现过以下扯皮问题：

• 业务黄金指标异常，到底该把哪些运维人员召集起来一起诊断？云平台运维人员还是应用运维人员？

• 中间件故障频发，到底是业务使用问题，还是云平台故障，抑或是中间件自身问题？

• 为啥物理网络显示正常，业务网络还是频现闪断？中间的虚拟网元链路到底是否异常？又有哪些涉及到的虚拟网元？

以上问题都无疑加剧了运维的困难。究其原因，无外乎因为以下原因，

• 众多工具，往往由于面向各自运维领域和专业技术略有不同，导致工具形成了一个个工具孤岛。

• 不同的工具孤岛间接导致不同的使用群体，出现问题时由于信息流、沟通语言不统一，不仅导致问题困难，又容易造成各类推诿扯皮。、

因此，在全栈云体系中，如何构建一个底层的系统，其具备统一的运维体系和语言，使得业务黄金指标出现故障时，能有效通过该系统，综合各个系统维度的日志、指标、链路、事件信息，快速进行根因定位和故障恢复，成为混合云全栈监控的新的挑战。我们把这个目标系统简称为：混合云的全息排查系统。

三、未来方向：构建面向政企混合云全栈的全息排查系统

为解决混合云全栈中的监控诊断的工具孤岛问题，我们提出全息排查系统。混合云的全息排查系统核心思路是，在不破坏各专业运维工具边界情况下，基于业界各类标准进行核心数据采集，构筑一个统一的北向实时分析系统。该系统的核心模块有两个，

• 面向Metrics、Log、Tracing的异常检测模块。该异常检测模块可基于各类数据标准 (参考OpenCensus、OpenTracing、OpenMetrics等标准) 上收数据，通过各类AI算法，对各类异常事件进行有效检测。通过此模块，全息排查系统不仅可大幅度提高异常检测精度、降低人工干预的报警配置工作量，还可以进一步降低和各类标准运维工具的耦合程度，即：各类标准运维工具专注原生数据(Native Data)采集和处理、以及特定技术场景的运维辅助流程；智能的异常诊断交由异常检测模块统一处理。

• 结合基于各类系统、应用拓扑 和 运维经验的知识图谱和全栈各类事件的根因诊断模块。根因诊断算法业界有很多种，但是基于知识图谱的根因诊断无疑可以大大增加根因诊断的精确度。在混合云的根因诊断中，知识图谱的核心是构筑混合云全栈的资源拓扑关系，包括虚拟机和物理机、网络各类SDN网元、容器、数据库和中间件、应用和应用实例、以及业务数据流的调用走向等。结合相关运维经验，通过数据挖掘算法，既可以针对业务黄金指标异常事件快速进行根因定位，也可以针对特定的异常事件进行爆炸半径估算，控制爆炸半径范围。

基于混合云全息排查系统，混合云全栈故障诊断的复杂问题有望得到极大程度解决。这里最核心的逻辑是，全息排查提供了一个基于全栈云架构的统一模型之上的全景监控平台，方便来自各个领域的运维专家汇聚于此进行专家会诊。

• 首先，各个领域的运维专家都能在全息排查系统以其独有的视角观察其关心的核心组件的健康状态。

• 其次，各个领域的运维专家还能直接在其之上观察其直接或间接关联的组件的监控状态。

− 核心业务负责人可以观测其核心依赖链路上所有相关的上下游应用 以及其底层虚拟和物理资源的监控状况。

− 中间件负责人可以观测其上游应用和其所在虚拟资源和物理硬件的监控情况。

− 业务负责人还可以详细观测基于业务流量实际跨过的物理和虚拟网元的状态，到底是虚拟交换机还是物理交换机出问题，一目了然。

• 最重要的，针对各类故障场景，全息排查系统提供各类场景化页面，供运维人员在各类场景进行诊断。

− 针对特定业务的黄金指标异常，运维人员可以通过系统进行快速根因诊断，并提供对应的故障恢复建议。

− 针对特定重要组件异常，运维人员可以通过系统进行爆炸半径估算，及时采取措施，进行风险防控。

− 对于特定的运维场景，全息排查系统还可以通过特定事件信息，跳转到特定的运维系统页面(如APM、AOM、等)，方便运维人员进行事件明细查看。

混合云的全息排查系统无疑在诊断方面可以弥补各孤岛工具中的断裂点，为用户构建一个整合过的监控诊断平台，从而大大可提高混合云全栈的监控诊断效率。

在最近的华为云Stack中，我们将会推出相关的工具和平台，以帮助IT管理人员大幅降低混合云全栈监控的难度，敬请期待。

云原生 华为云Stack 混合云 运维

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。