在政府企业数字化转型的背景下，诸多大型政企客户选择混合云作为业务上云的整体方案。然而，混合云客户场景下的可观测领域，却面临着和公有云场景和大型互联网企业内部场景截然不同的几大困难：异构的基础设施和混合云架构下复杂的应用和云平台网络环境让监控系统本身难于部署和稳定运行，面向传统应用架构和旧应用极高的改造成本让指标、链路、日志监控难以落地；基于云平台监控和客户自建及第三方应用级监控工具相互割裂难以整合，客户侧技术栈老旧、云原生化程度不足等。
面对这些技术挑战，我们在面向业务指标实施计算和应用基础监控的阿里集团监控平台的基础上，通过全方位监控架构升级和开源架构融合，以及多项的监控能力创新，打造了面向混合云客户的一体化监控平台，并在数十家大型政企客户侧落地了面向混合云的全景可观测能力，显著提升了客户侧云上业务故障发现、定界及处理的时效性，保障了诸多关系到国计民生的云上政企业务应用的稳定运行。
本文整理自阿里巴巴阿里云基础产品事业部高级技术专家王肇刚（花名梓弋）的演讲分享，主题为“混合云全景可观测技术架构探索和实践”。分享主要分为三部分：1、混合云场景下落地可观测能力的技术挑战；2、面向混合云客户的企业级监控平台技术架构探索；3、混合云可观测实战案例。
混合云场景下落地可观测能力的技术挑战
从监控到可观测
什么是监控？什么是可观测？监控可能更多的是通过一个采集和分析看某一个具体单点的单指标状态。可观测强调一个可字，希望通过被监控对象的系统自己暴露出一些信息，你能够通过信息和上下文感知到更多的东西。细分来看，监控可能是一个被动的，像外挂式的设施。我们的 Agent 采集数据会有探针，监控对象本身是独立存在的。而可观测性强调主动透出，从我自己的从业经历来看过去十多年的运维行业的发展趋势是一致的，我们在很多时候面临的问题非常复杂，比如说十年前我在百度负责百度贴吧的运维，我们有 2600 台物理机，当时每天的 PV 是 24 亿，那个时候面临环境一致性问题，这个问题跟监控关系不大，但是跟运维部署关系很大。那个时候没有 Docker，没有 Kubernetes，2600 台物理机上有大概八九百台需要部署前端 UI。
我们希望是统一的环境，结果做了一下线上环境的扫描，发现有 500 多种 Diff(配置差异），为什么？因为我们在线上要做灰度发布，几十个模块在不同的迭代，靠手工维护是很难的。有了容器化之后，你会发现问题解决了。在监控领域发生的很多事情跟在运维部署领域是一样的，我们希望通过外力施加去观测，慢慢变成它自己对外暴露信息，可被观测。这是我说的第一个特点。
第二个特点是监控可能只关注一个具体的指标，或者是一个报警，而可观测性则希望能够通过一个单点看到更多的全局，看到上下文，透过现象看到本质，也不仅仅只关注报警，还要处理，我们希望知道背后的原因是什么，以后怎么预防。所以监控到可观测性是一个由主动到被动、在空间上由单点到全面、在时间上由告警响应这个单一时间段到故障处理，全生命周期的演变。
混合云客户运维可观测需求及挑战
由监控演进到可测性技术领域的变迁过程中，混合云领域的客户群体对可观测性也有自己的需求。什么叫混合云？各行各业的客户在使用云的时候可能主要会有两种模式，一种是我们熟知的公有云。还有一批客户，他们由于安全合规的需要，可能无法直接使用公有云，需要使用我们称之为专有云的私有化部署的技术体系。混合云的客户都是谁？我们每天交电费、交水费、交燃气费，像这样关系到国计民生和各行各业的日常生活的很多业务，背后的企业更多的是政府国企和一些大型的头部企业，它们的 IT 系统往往跑在混合云上，对他们来讲，混合云上系统越来越复杂，要保持业务的稳定对于可观测能力或者我们称之为监控能力有非常多的需求。
监控可观测本身也在演进，比如现在的监控已经不按垂直领域划分了，我们更多的是叫全栈监控，同时监控也不只是报个警，看个图，我们更希望监控系统能够提出一些分析的能力。客户的基础设施架构从单体架构变成了混合的架构，监控也需要去适配这种架构，同时随着客户上云的过程办的越来越多，监控本身也需要回答关于成本运营的问题，受监控业界这四大领域趋势的影响，混合云客户对于可观测性的需求也有扩展。比如希望能够全方位地全栈监控，希望能够做多层的全景监控，希望监控报警不仅仅能够解决问题，发现的问题也能够服务于整个 IT 管理的生命周期。
我们也希望能够在混合云客户侧把可观测能力做得更好，但实际上问题是很明显的，就是我们在混合云客户的复杂基础栈下，落地这个我们称之为全栈、全景、全生命周期监控有很大的挑战。
我们先看全栈。说到全栈这个词，大家很容易联想到技术栈，我们的应用程序使用不同的语言开发，有不同的框架跑在不同的操作系统和基础设施上，都是各异的。应用架构的差异，技术栈的差异，研发模式的差异，还有运维模式的差异，都会给我们做可观测带来很多的挑战。
如何在割裂的运维体系下落地全景可观测
全栈更多的偏执于不同的技术栈，而全景则指的是分层的，不同的运维或监控对象。这张图是一个全景的架构，在实操过程中大家会发现，我们存在着至少有四种割裂，第一种是应用运维跟平台运维之间的割裂，这种割裂一开始不是因为技术造成的，我作为一个一直在互联网大厂工作的同学，接触客户之后挺困惑，客户侧管平台那级的人跟管应用那级的人割裂非常严重，导致这两层在系统上是不联动的，如果出现一个问题，需要去判断是应用程序自己的问题，还是底下云平台的问题，这个事情是很困难的，很难系统化实现。第二个是平台运营跟运维之间也会有割裂。很多的客户在采购了云服务商提供的云产品之后，会把它二次分包出去。有一部分人需要拿云平台的资源对不同的二级使用者做资源运营。这个时候它不得不关注平台的稳定性，而关注稳定性的又是另外一拨人，所以从人到系统也存在割裂。第三个是监控报警处理之间的割裂，很多的企业会有值班的同学，但是值班的同学往往只能够响应报警。真正出问题之后可能报警来自各处，不见得一个人就能处理，所以缺少系统化报警间联系比较容易出现低效的问题。最后一个是不同的垂直应用系统之间的割裂，很多政企的客户 IT 系统之间存在着孤岛现象，技术栈也不一样，接口也不一样，数据的形式也不一样。
存在着这四种割裂会导致我们很难把数据连起来，但是数据能不能不连起来？不能。因为他们之间是牵一发动全局的关系。这种割裂会影响我们通过技术化的手段去获取运维对象之间横向和纵向的拓扑，我们要获取的拓扑包括：
业务和业务之间的横向拓扑
业务和应用之间的纵向拓扑
应用与应用之间的横向拓扑
应用与云产品实例（中间件、 DB）之间的纵向拓扑
云产品实例和云平台组件之间的纵向拓扑
我们希望业务报警和其他报警之间有有机的联系，能够服务于故障的发现、定级、快恢和定界的四个环节。但实际上客户侧可能达不到这个理想态，究其原因可能有四方面：
第一个方面是告警风暴很多，大家就不知道是不是业务出问题，还是系统出问题了，业务监控会淹没在系统的报警之中。
第二个是如何确定故障级别，故障级别的确定需要依赖两个因素，一个因素是你的 IT 系统、应用和基础设施故障到底到什么程度了。第二个是上面跑的业务重不重要，有没有很多客户在用。
第三个是告警和快恢入口 割裂，快恢决策 依赖人工判断。
第四个是针对不同监控对象的告 警杂乱发送，无法结构 化地服务于故障定界。
面向混合云客户的企业级监控平台技术架构探索
混合云可观测能力
第二部分给大家介绍一下我们面对这些挑战做了哪样的架构方面的探索和实践。首先这张图不是架构图，它是个功能图，是截止现在为止，阿里云混合云对于政企客户推出的全景可观测产品功能架构，有场景化的监控能力，还有事件处理，有业务监控、应用监控和应用视角的云产品监控，我们也有能力去帮助客户监控它的应用和业务，我们可以有很强的抽象集成能力，客户侧有不一样的技术架构和技术选型，我们都有办法做集成。
大家可能会问说，为什么要做这么多功能？这张图解释了我们为什么要研发这么多功能。大家可以看这个图有三个坐标。第一个坐标是我们称之为云+应用一体化运维对象，是我们的纵轴，或者是 y 轴。它上面有三个刻度，业务、应用、云平台。还有我们的 Z 轴，就是纵深的那个轴。它就是我们最熟悉的云原生可观测性的三大技术支柱，Tracing、Matric 和 Logging。大家可能会问，既然有两个轴了，这两个轴各有三个刻度点，是不是三三得九，你得做九个功能？也不是的，因为你每一个监控对象，或者每类监控对象不见得一定要用三种监控，比如对于业务指标，可以通过指标监控做，也可以通过日志监控做，也可以通过链路监控做，但以指标监控做的效果可能是最好的。应用监控就明显是指标和链路会多一些，平台监控指标跟日志会多一些，链路会少一些，我们需要在监控对象上采取最有效的组合监控的方式，这是个技术手段。
做出这么多监控能力为了干啥？是为了服务于日常运维的业务。从运维人员看，出现报警之后的处理流程可能分为几个节点，首先是故障发现，第二个不是故障定界，而是事件定级。第三个是故障处理，第四个是故障定界。事件定级从业务流程上位于故障发现和故障处理之间。
混合云可观测架构实现路径
接下来我们再谈谈技术，我们演进的起点是这张图，它是阿里巴巴集团内部用的阿里集团监控平台的架构图。这张图所画的架构承载的功能无法支持刚才上面那么多能力，这是一个非常重实时计算的架构，它的核心价值是什么？是在千万级别的容器节点上采集业务的痕迹，也就是日志，去做实时计算，然后以非常高的时效性把指标算出来，它计算的是每秒钟淘宝有多少人能下单，有多少个人退款，多少个人添加购物车。所以它的架构特点是什么？需要处理海量数据，同时需要具备非常强的容灾能力。
大家可能也知道阿里巴巴的混沌工程也是我们的一个做的比较好的领域，它会在内部不提前告诉你的情况下给你搞断网，然后把模块注入故障。监控系统曾经在前年和大前年被两次生产突袭验证过，一个局部单元断网之后，这套系统必须要正确回答到底是业务量下跌导致的指标下跌，还是你的单元的网络中断导致下跌，所以它需要有比较好的容灾能力。
我们采取了异步调度的模式，每层的任务调度都会容错。如图左上角是阿里巴巴的元数据 CMDB，监控配置和 CMDB 一起定时触发监控任务的生成。我们的每一个应用都会在每一个实例上打印日志，或者对外暴露一些数据，但是我们要看到是一个全局的空间上经过汇聚的数据，而且汇聚时还带业务规则，所以需要一个任务本身的生成机制，这个任务会有两级的分发到我们称之为 Map Reduce 的模块。它的命名参考了当年的 Hadoop，但是实际的功能不太一样，我们的 Reduce 模块会去 Map 上拉，然后 Map 会去遍布在千万级别容器上的客户端拉取数据，然后计算后将结果存到阿里巴巴自研的时间序列存储里面，最终进行展示和报警。我们整个的架构特点是高效、稳定和准确。
但是大家可能会问，你这个架构非常适合实时计算，它在功能层面扩展性并不是那么强，为什么要做这个架构？它是跟业务相关的。这张图给大家展示的就是阿里巴巴集团的监控的方法和理念，是一个非常重业务监控的方法论，这个系统超过一半的负载都在算什么？都在算如左边这样的数据，我们称之为交易量，这些业务指标中以交易量为主，它带的是业务含义，比如说会把电商体系的拆单比考虑进去，而且很多是秒级的。所以阿里巴巴集团的业务监控为主这个特点，在这个系统中体现的淋漓尽致。但是当我们希望这套东西能不能站在阿里云上服务于企业客户的时候，发现遇到了很大的问题，我们也经历了一个很痛苦的这个过程，我们直面的转型之痛包括：
大规模监控计算调度和在混合云现有客户场景下并非刚需
客户侧数据迟延较大，秒级监控几无用武之地
客户普遍缺失业务监控的理念
客户侧技术栈不统一、部署环境复杂多变
我们这个系统在最开始从集团内部转到商业化的时候，面临着这些困难，也需要补全很多能力，比如：
客户侧专有云资源严格规划，小型化瘦身和部署能力
增强是当务之急，需要兼容全栈监控能力，增加链路监控和日志监控能力
集成和兼容客户侧多样监控数据源和监控工具报警事件的能力。
接下来给大家展开介绍一下，第一步是我们把实时计算架构跟 Prometheus 架构相融合。左边这张图是我们自己内部传统的 Map Reduce 架构，它怎么跟 Prometheus 融合？这个时候 Prometheus Server 上的计算任务调度是被 Sunfire 原生的 Brain 和 Map Reduce 所驱动的，这样的好处是什么？因为原来任务驱动有比较强的容灾能力，所以当计算任务出现失败迟延、超时的时候，可以被容灾，这是跟原生的 Prometheus 不太一样的地方。我们的存储复用了 Sunfire 自己的时序存储，就是阿里巴巴自研的时序存储数据库，Prometheus 的存储能力得到了扩展。Prometheus Server 本身也需要一个高可用的扩展，在社区有很多的方案，我们采取了社区用过的一种方案，就是对它的计算任务做了分发，我们有主和备，我们自己做了一个哈希的规则去做分发，这样就比较好地结合了 Prometheus 本身生态的特点，同时也复用了我们原来监控平台有的高可用架构和调度架构，这是第一个融合。
这之后，我们往前再走了一步，跟 SkyWalking 融合。这个时候我们会对开源的东西做一些修改，当然严格遵守了开源协议，并且给出了合规的声明。技术层面，我们分享两点修改。第一点是在 SkyWalking 架构图里，把自己的 Tracing 和 Metric 信息都放到它的中心去算。我们在这里做了一个分流，把里面的指标数据走一个通路，汇入 Sunfire 计算架构里。Tracing 本身往上走的链路保持不变，但是它里面的指标部分可以跟共享计算 Sunfire 调度和存储，再向上去接大盘各方面的外部设施。
这样原生 SkyWalking 的能力我们还保留，同时跟我们现在能力做很好的结合和增强。因为和阿里云 Sunfire、混合云的元数据平台，包括我们的运维部署平台做了联动，我们有比较好的服务自发现能力，你在用了阿里云之后，自己部署发生的扩容缩容我们是可以感知的，不管底下是原生的虚拟机架构，还是 Kubernetes 的架构。这个感知也被透穿到 SkyWalking 里面，当应用对象的实例发生变化之后，探针里面的应用标识会自动更新。我们几个系统不是简单的堆砌在一起，而是有机的联合。
在工程层面做了演进之后，可以看到我们的算法也有很大迭代需求。我们现在在商业化的监控产品中会有我们最早的智能基线，经过不断的迭代，放在我们商业版本之后发现效果还不错，但是我们觉得还不够，因为很多时候我们的监控需要对应用或业务的黄金指标做监控。这个时候它应该是一个多指标异常发现的场景，就是需要对一个指标的成功率做综合的监控。我们会有黄金指标异常检测的能力,包括可以基于调用链分析，有应用故障诊断的能力，包括在配业务监控的时候可能需要在日志里筛关键字，然后去配正则表达式。现在我们的新能力是什么呢？我们通过算法去分析你的日志的格式，然后去看哪些关键字流量最高，哪些最可能被监控捕获，进行算法自动推荐。
这些算法本身的功能背后还需要一些产品化的手段，比如需要把算法参数转化为运维人员友好的参数可调节，让运维人员可视化地看到算法检测边界。你可能需要在算法的配置调整之后做回溯，原来的架构就跟不上了，所以我们对算法专门做了一个工程架构，这个架构也比较简单，就是把算法本身的任务做成调度的模式，调度策略跟计算任务、报警任务、调度策略做融合，这样能复用策略，也能适用算法的特点，只要在算法框架里自己去实现即可。实现完之后就可以被框架以比较高的时效性跟原生的报警放在一起调度。在客户侧对于资源极其苛刻的要求下，算法也能够尽它的可能性去挖掘任何资源，因为它不会单独占资源，是弹性的。这样容错性和资源利用率也能得到提升。
接下来是事件层面，就是对报警处理。这张图也是一个功能图，我们有事件中心，业界的商业化竞品都有这样一个功能，我们希望突出架构的冗余性、可用性和集成能力，客户侧在使用你的产品之前可能已经有 N 个产品、N 个监控系统，开源的 Zabbix、Prometheus，或者其他的监控系统，我们希望数据能够融合在一起，但可能很困难。在实操层面把报警事件集中在一起，可能是一个更务实的选择，那怎么把事件集成在一起？需要能够解析事件的格式。大家知道事件就是字符串，它很多情况下就是纯文本或者副文本的消息。如果有 Meta 的话，可以对它解析。但你会发现，如果堆积的系统多了之后，对于事件本身的字段抽象也是比较大的挑战。同时，哪怕监控趋势图挂掉了，报警也不能挂，所以它的稳定性要求很高。所以我们跟专有云的架构组去做联动和合作，引入了阿里巴巴专有云在多云或者一云多 Region 层面下的高可用架构能力，让报警本身能够做到最稳定。
同时我们也做了很多的抽象设计，让报警系统能够做很好的南北向集成，南向集成是指能够去接驳不同数据源的异构报警，同时尽可能去感知报警背后的元数据。这点挺重要的，大家可以想象一下，如果你用了多个监控系统。很可能这些监控系统之间对于某一类监控对象或者同一个故障会有重复的报警，如果事件中心不能感知这些系统的 Meta，很难去跨系统做集成，做报警的压缩和治理。所以我们需要去对系统的 Meta 做一定的感知，一方面靠对报警字符串解析的感知，一方面靠专有云底座的 CMDB 以及运维部署方面的感知，同时我们也通过链路分析的方式，能够自动追踪客户在阿里云上的应用对客户购买的云产品之间发起的调用，调用链的信息跟 CMD 里面静态的注册信息做比对，很多数据流向的 Meta 就清晰了，这些 Meta 会帮助我们在事件中心做报警的收敛。
混合云可观测实战案例
架构的演进之后，问题解决的好不好？可能还是要到实际的场景中去打磨一番。今天给大家介绍几个案例，看一下效果如何。
第一个案例是国内某大著名的能源企业，它之前监控是割裂分层的，应用我们系统尝试可以把它穿起来，不管是下面的基础设施和应用，还是上面的这个业务。之后也可以通过智能化能力去发现一些以前需要人工巡检，或者说静态报警规则所能发现的问题。静态的规则可能比算法在单指标下效果会好，但需要大量的维护成本。能源行业用户量非常大，而且有和互联网行业不一样的规律，所以算法也需要一些迭代。得益于我们这套工程和算法的架构，这个系统能够比较好的部署在总部和全国 N 个省的中心，这样能够就从空间上监控总部和省，同时在时间上也能够做纵向的上下钻取。基于事件中心对报警做得收敛，我们也取得了很好的效果，之前每天会有很多杂乱的报警，后面被我们压到非常小，并且没有损失信息，一旦出现问题，报警会串联起来，自动生成一个树状结构，数据就变得很高效了。
第二个是某党建类项目，全国的党员天天在用。它的业务量也非常大，规模是我们客户中比较大的。它的运维活动很频繁，所以监控跟运维的联动，监控的部署也成了一个很大的问题。随着业务应用的扩容、缩容，监控需要跟业务伴生，同时不同的业务应用会采取不同的监控手段去监控。我们的监控插件也需要动态根据客户业务的变迁和应用的变迁去做部署，我们自研了一套和 K8S 一样的机制，借用 K8S 里面的 Operator 机制去做监控客户端，包括 Agent 自动部署。这样我们可以在客户侧把业务应用和云资源一起监控起来，完成一个整套的监控方案。
第三个案例是某一个省份的政务厅或者政务中台，阿里巴巴的钉钉协同工具跟阿里云在战略上是云钉一体，也服务了很多省的政府企业客户。政府客户内部有很多的功能点，有时候网页点不开了，有可能是后端接口不想用了，也有可能前端 JS 报错了这两种原因。但很难判断，一开始都是等到客户去投诉的时候才会有业务人员去找 IT 人员响应这个问题。但是有这套系统之后，就能对业务的使用量做实时的监控，当业务量出现问题，马上能够看到应用，马上能够看到云平台。所以我们就能够做到一个全栈的监控，客户能感知到自己业务的运行状态了。
有多少个人用？什么时候用量大，什么时候用量小，这个统计的粒度是分钟级，甚至一些核心指标可以到秒级的。而如果希望能够保障这些业务功能点的稳定性，需要对我的业务功能到底有没有被监控，监控出来的报警有没有被响应也要做及时的感知，所以我们也跟阿里云的故障管理的产品和服务做了集成，这样客户能够看到云上的业务有哪些功能点已经被业务监控覆盖，哪些功能点的监控质量是什么样的，每次出现报警是不是有人被响应。大概几个月之后，你会发现不同级别的事件数量有明显的收敛趋势，同时单个报警的响应和处理时长也有明显的收敛，这就是产品技术加运营得到的综合的效果。
相关阅读：
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论