首先出场的是运维界的明星——老王！优维的CEO王津银。

紧跟着老王提到的五大类数据，加之，前面几期分享也有多位老师讲到过CMDB和可观测的关系，CMDB作为优维的王牌产品，且优维可观测产品也是今年首批获得信通院可观测先进级能力认可的产品，那么优维是怎样把CMDB和可观测进行融合的呢？

优维的黄兆鹏老师给大家分享《云原生下基于企业IT资源图谱的超融合监控实践》

黄兆鹏老师主要围绕三个问题，分享优维的可观测实践。

一、云原生架构变化迅速，如何打造既兼顾实时性，又能兼顾准确型的IT资源图谱？

利用资源的特性，打造云原生的CMDB。

二、监控工具繁多，如何解决数据孤岛的问题？

深度结合CMDB的实例和关系，从采集、加工、存储、消费环节把不同模型的数据串联起来。

三、故障发生后，如何快速定位问题根源？

以服务为核心对象，把服务关联的标准化资源的指标尽可能多采集上来，利用CMDB服务与资源的关系快速分析定位问题。

本环节我们邀请了各个行业的可观测实践者来到我们的直播间，分享他们的原厂实践经验，我们希望能结合他们的经验，一起来进行一个行业交流，看看究竟会碰撞出怎样的火花。

希望可以从他们的交流过程中找到可观测最终的发展方向有哪些创新之处，给大家带来更多的启发。

>>话题1： 你对可观测性的理解是怎样的？可观测性对于以微服务架构为主要特点的云原生软件系统为什么重要？它与我们一般所说的“监控”是什么关系？

黄兆鹏："可观测性的英文单词是由Observe、ability，这两个单词组合起来的，意思就观察的能力，我们看一个系统是否具备可观测的能力。比如我们经常用到的数据库可观测性，系统安装了哪些可观测性工具。如果一个系统是可观测的，用户就可以看到它自己产生的一些数据，来识别性能问题的根本原因。一般我们说的监控是预定义好的指标、日志去评估系统的健康状况，而可观测会在这个基础上更进一步，加了分析能力上去，上报更多高价值的数据！能够感知到不同监控数据之间的一个关系。"

夏达："监控一般是针对特定的监控对象，它会产生一系列的监控指标，这些指标可能是相对孤立的，会缺乏上下文。可观测性会相对大一点，他们不是割裂的关系，监控是可观测性重要的一环。可观测性会解决传统监控一些不适应的场景，他可能提供了一些思路，包括在里面提到的一些敏态对象。还有就是思路的不同，用测试的话术来讲，监控类似黑盒测试，它告诉我们暴露出哪些指标，运维人员关注指标就可以了，而可观测性更强调内部状态的暴露，类似于白盒测试。监控本身是孤立的，要把不同的监控数据关联起来，或者当我们要定位问题的时候，有很多关联信息，包括知识、信息，它是存在那个专家的脑海里的，是以其他方式保存的，这个时候如果大家都足够专业，足够精通，其实监控可以提供一样的功能，但就是没有那么标准化，很多东西都停留在脑海里边，区别就在这里。"

蒋通通："我觉得可观测这个东西其实跟我们的整个架构演进，数字化转型等等，其实是脱离不开的。我们在早期整个架构会相对比较简单清晰，但是在做转型和新的一些云原生演进的时候，我们就发现整个架构会变得越来复杂。包括很多云基础设施的一些变化等等。传统的监控可能在这方面发挥不了太大的作用，而且传统监控其实更多偏向表层或者网源设备的基础异常告警等等。但是在可观测性上，会分析它相应的异常是为什么发生的。"

石鹏："可观测性它并不是一个新的概念，上世纪60年代就已经有了这个概念。它跟可控制性属于对偶的概念。为什么到现在尤其是近几年，这个概念被更多的提及，并付诸实践和探索。确实是跟刚才各位老师讲的，和我们目前的环境变化，基础设施越来越复杂，云原生的持续推进等是密不可分的。在这样大的背景下，传统的监控的手段确实不足以满足工作了，需要我们用可观测的理念来帮助我们更好地做监控。我们之前讲监控可能更多的是把资源对象，或者说一堆服务的状态监控到。我们所有做的这些事情，其实最终都是要面向价值的，从这个监控数据也好，可观测数据也好，你挖掘出了它的某些特征，基于这些数据做某些决策，最终是给业务服务去创造价值，这才是可观测性更大的一个意义。"

>>话题2：构建可观测体系的过程中，大家肯定需要借助很多开源软件，可以分享一些经验吗？

夏达: "我可以介绍一下我们这边的经验，也有教训在里面。我们公司属于券商，我们的系统架构跟网络架构特别复杂。但是变更频率其实没有那么高，这是一个特点。在我们建立这个指标体系的时候对一些历史的监控工具，或者是他们历史的一些监控项应该去采取一个怎样的态度？首先我们是没法回避的，所以在对接不同的各个间隔系统的数据的时候，我们做很多探索。

有些监控系统，是用了实际输出库存的，有些是用的prometheus数据库,这种是比较好对接的，我们直接读，很容易抠出来。另外还有一种，zabbbix，zabbix本身就是一个监控体系，它的指标去重之后可能也有3000项。这些指标怎么样对接进来呢？zabbix的数据结构指标全部存在一个叫history的表里边，这个表比较简单，它内部全部是用一个id来关联的，我们去给它做数据对接的时候就比较不太好对接，没有简单一眼能够看到可行的方式，这个时候我们就采用了另外一种方式，阅读源码或者是开个通道出来，同步到我们这边，我们分析风险会比较大，成本也会比较高。在我们这种模式下，我们不会投入太大的精力去改开源的产品。我们要么就二开，要么就直接从数据怼过来，要么是调api，基本上就这种模式，因为成本可控，风险也比较小。

蒋通通："刚刚夏老师的确讲了很多经验。我来自浙江移动，移动其实更偏向传统的运营商，比较大的特点是，我们不仅有很多新增的系统，而且是可能会来自各个合作厂商。同时那些历史的系统可能会因为国家政策，法律法规规定，就算是十年前的业务也不允许下线，会导致我们的系统五花八门，它所建设的厂商，不同历史时期，有不同的厂商介入，造成我们整个观测体系需要对接的源头、数据等等，很复杂。我们在做体系的时候是从早期，是用的那套ELK或者说EFK那套表大家比较熟知的技术站。甚至在早期，我们还对比个类似的东西，那么，然后在这一整套就是说日志落地的过程中，其实是我们可以发现，其实刚开始用开源很爽，2014年早期比较弱，所有日志可能都还得登主机看，当时把ELK那种到体系引进来，觉得用的很爽，但是随着不同的系统往里面不断的灌数据的时候，其实碰到的问题还是挺大的。

第一个是数据处理，我们在采集端可能做到分布式，比如说不同的客户端他安排采集过来就可以了，在我们的整个数据处理端，我们在刚开始。就是原有的那个方案，其实它也是用那个方案，但是我们在自己这里，我们把那个做了一定的结合。我们把后端的那个解析集群去搭成一个比较自主或者说比较大的一个K8S的一个节气集群，所有的那个容器化的那个形式部署。我们一旦碰到，比如说有一些日志量爆炸情况下，我们会快速拉取相应的扩容，然后去满足它相应的解析要求，这块也是相对独立的。在指标方面，一个是采集上，在技术栈上也比较通用，对我们移动这种组织形式来说，这里会涉及到一个点，主机平台是一组管，中间件可能是中间件在维护的，数据库是数据库在维护的，这里会涉及到不同数据的融合。那会碰到一个问题，这个数据到底谁来采？到底是可观测系统工具的主责方去统一的进行一个采集，还是由专业组用自己的工具去采出来，不管是他用开源的，或者说他自己写代码去捞相应的一些指标也好。我们最终在这种组织结构下，我们把数据的采集权做了下放，我们把所有时间信息都滑到了专业组身上。让他们把相应性的所有的数据去做一个上报，然后我们会在做后面观测的数据的使用或者分析上会反向去考核相应的专业组，它是不是在某次故障或者说某次问题分析上它是不是有把相应的一些观测数据去做一个突出或者说一些他自己分析一些事件数据做一个突出，那这样去反向推动我们去做一个数据的拉通。"

黄兆鹏："刚才我的分享，其实也提到过，构建这个可观测系统的这么一个过程中，其实我们也是借鉴甚至直接使用到不少的开源项目。比如我们经常提到这个项目，在他刚启动的时候，其实我们就发现了他啊，就觉得他很棒，它是一个统一的标准，它提供了很好的接收可观测性，可观测数据的标准！我们的Trace的数据在很早就应用上这个项目的一个框架，还有数据结构，但是有一个比较坑的是我们用它的时候，因为它还处于比较早期的阶段。它那个1的版还没有发布，导致后面它真正发布了1.0了，会有很多的问题存在，我们的程序升级改造的成本比较高，就是因为用开源项目带来的风险。"

>>话题3：要建设好系统的可观测性关键步骤有哪些？你们是怎么打通链路、日志、指标等多套不同的监控系统的数据？主要运营场景有哪些？

蒋通通："首先建立全局分层的体系，中间做每个层级的数据处理，最后把关联起来的数据运用到具体实践上，即建标准、采数据、运用数据。

可观测最重要还是数据。在建立体系的时候，我们建立的是数据的标准，相当于我们在这套体系内我们要需要观测多少的数据，我们需要观测哪些范围？这其实要求我们对整个运维体系做可观测性的体系分层，我们把用户、服务、业务、应用、基础平台等等做了分层的结构，定义每一层需要观测的范围，以及观测指标的内容，对每一层我们先建立了我们需要在每一层去干什么去、对接哪些数据，这样会有一个大体上的了解，然后在这个基础上我们会去想每一层数据到底该怎么拿，这里就会回到，刚刚提到的，我们在去做一些数据采集的时候，我们会在分层的视角上，再去做一些分层的处理，不同层数据会有不同的专业组去做相应的提供，不同专业组会引入不同的一些观测数据的技术栈。第二个动作是我们要把全局的数据去做融合贯通，如果还是原来的离散，或者说独立那种状态，跟传统的监控没有特别大的差异，但是在我们整个观测性的系统上我们更想去做一些关联的分析，甚至是不同层级的观测数据能不能追踪到相应的业务，这样的话就把我们整个观测数据的价值可以去做一个放大了，那这样我们最终的观测数据，是可以体现我们最终业务的好坏，而不是原有比如说只是一台主机宕没宕，或者说一个进程挂没挂这种状态。在这个基础上，我们一直在强调或者说在做的一个事情，就是我们想去做一个应用的观测性，就相当于是我们所有的观测，可以从业务出发，可以从应用出发，这样会形成我们自己对每个系统架构的数字化的理解，或者说会形成相应的图谱，在整个图谱也会有一个类似分层的一个结构，那这样的话，在每一层的结构上我们会去把我们相应的观测数据或者说观测的一些分析的一些异常结果，去做相应的填充，在我们观测的拓补或者脉络上会快速体现相应的问题，最终收敛到整个观测体系最终运用，或者说场景。"

黄兆鹏: "我非常认同蒋老师刚才说的观点。想要建设好系统的可观测性，最重要的是底层基础设施标准化的能力。首先我们的系统就要求是具备可观测性的，像我刚才分享所说，要把准确的原数据做好，然后通过他们的关系来打通不同领域的数据，包括每个服务要提供可观测的指标，接入trace的标准化程度是怎样的，日志能不能去关联到这个trace？这些都要求我们从底层的基础设施开始，把所有的这些都准备好，这就是我一直跟大家强调的标准化的东西，后续有了标准化的东西以后，更上层的系统建设才会更加轻松，我们在这基础上做一些慢查询优化的场景，这就非常好做了，我们有trace的数据、系统指标、各种各样资源的指标，我其实是可很好的去进行一些慢的接口进行优化的。"

夏达: "我的观点跟前面几位老师都比较类似啊，我可能更强调统一模型，我认为这是我们这里的关键，这个模型范围是有大有小的，其实很多情况，我们都是按照数据治理的思路来做可观性系统的。数据治理有两个比较大的领域，一个是叫主数据治理，一个是叫元数据治理。运维数据治理里，指标体系是运维数据的主数据。这个模型属于主数据的一种，我们怎么样去建立这个模型呢？我们参考了开发部门的建模方式。比如说thoughtworks的四色法建模，根据它的规则，在业务建模的时候，抓住钱这个要素，根据钱的流转来建模，然后在我们这边，我们是根据变更，以变更作为key要点来进行建模的，比如说每次变更的最小单元是啥，变更的影响范围怎么样去界定？根据这些东西来建模的，然后我们以cmdb为主要的模型，我们每次变更是以cmdb里面的一个叫组件的作为变更的最小单位，然后我们以这些为模型，建立了一个统一的模型，包括指标，比如说以zabbix为采集指标，我们之前提到的，zabbix是以主机为依据进行监控的，它没有组件这些信息，然后我们就会把cmdb的模型数据，比如说一个主机属于什么组件，属于什么系统，我们的flink里面给每一条指标都会打上标签，打上标签后，zabbix就很好地融入了我们的整个体系了。然后比如说prometheus这边的。我们的维度标签是建立了一个是叫服务，一个是叫服务，一个是方法，然后可能在不同的监控器里面有不同的名字，但是总体而言，比如说一个服务。我们内部概念上理解也是把它理解为一个组件的，它是对应的一个服务，然后组件下面提供的一些子服务就叫方法,我们也通过这种方式把prometheus的服务也给对接到我们体系来了，不管你原来是用的什么模型，能解释成我们一统一模型的，就都解释成统一模型，统一一个话语体系，就是大家说话就是不同的监控系统里边大家其实是概念是统一的，然后互相能够理解的，然后再构建一个统一的查询平台，这样的话，虽然我们的数据存在不同平台，尽管大部分都统一到大数据平台来了，尽管还是会有一些零散的，但只要符合我们体系,都能够直接对接起来，跟数据库的概念有点像，但是它并没有统一存储。"

石鹏: "我认为可能有两个点，然后比较重要，第一个点的话就是刚才Paul有分享优维的产品，就是元数据建设，在可观测的整个体系打造里边太重要了。元数据又分为两层，一个是资源的元数据，另外一个是业务的元数据。这两层信息都完备了之后，它才是一个完整的元数据平台，不管你叫CMDB或者叫什么，总之它是提供了一个完整的元数据，有了它之后你才能够更方便的去做业务的各种资源对象之间的拓谱，才能够更方便的去把那些各种监控数据去做关联，这是一个基础。另外我有一个观点是我们在建设过程中，可以以终为始，我们建设的过程中，可以先从场景出发，从实际的需求，我有什么样的场景需要用到这个可观测性的数据，需要这种监控平台支持，然后我们目前的这个平台所提供的能力，它还有哪些欠缺，我们以这样的思路去推导，可能会更贴近用户，使用的场景可能会有更高效的价值的产出。"

>>话题4：更细粒度、更深层次的可观测性技术是否有现实需求和应用前景？哪些特质企业/单位有必要做？

夏达：首先我们得问自己一个问题，就是我们做到什么程度了。从两个角度来看，一个是看我们当前的故障数量、恢复时间、变更发布时长，根据这些数据来判断我们的可观测性是不是足够深，足够细。另外一个角度是从运营跟业务层面来看，有没有更极致的诉求。我们最近是做了一个类似的系统，这个系统就是属于极速交易类的，是给机构客户用的，这类用户对时延极度敏感，微秒级别，从下一笔单给券商，然后把数据上报给交易所大概要多少微秒，这个数据用常规的调用链分析不太好分析，所以在这种情况下就有必要去做可观测性。更细粒度的话成本非常高。是不是有足够的理由去说服领导来投这个钱，所以总结一下，一个是从当前的故障处理这方面来看，第二个是业务层面，他有没有要求，他想要的话，他们想要啥，啥都能做。

蒋通通："我的观点和夏老师的挺像。第一个还是看真正生产诉求跟可投入资源的平衡，如果说你确实没有极致交易类的那种业务需要更细致的一些观测数据的话，我觉得对普通的一些系统，基础的观测基本上也是够的。但是我还想提一个比较有意思的事情，就是我们在做可观测性，其实我们还提了一个重症ICU的概念。我们搞了一个蛮有意思的东西，我们在生产的平面，我们取了0.1的容量，然后搭建了一个新的一个弹性的平面，在这个平面我们会去尝试各种各样的观测性的技术，包括trace、skywalking、opentelemetry等等，我们在这个小平面上把很重的一些观测性的东西都上到那里去，这个平面拿来干什么呢，就是把用户碰到的一些疑难问题、分析不出来的问题，可能只是部分用户影响，那我们就把那些用户引流到这个平面，然后就是想通过各种手段，看看能不能把最终的问题抓出来，这是一个比较有意思一点。还有一个其实是相当于是什么呢，可能不一定有现实需求，是老板有创新需求，那如果说是有类似创新的需求，但是我们又不会在生产平面上真正去落实这种东西，那怎么办？我们肯定要有一定的技术演进，通过我们这样一个小型的运行平面，其实也可以做这样的一些尝试。”

黄兆鹏（paul）:“ 可观测的趋势力度是变得越来越细，它需要收集越来越多程序的上下文，会更有利于对我们的系统进行分析。刚才老王也提到，以前我在腾讯的时候其实还没有tracing这种技术，它只靠两点服务间调用的成功率，还有系统一些指标来进行监控，如果出问题就去看日志排查问题。但现在，随着技术的发展tracing已经成为了我们微服务的一个标配了啊！有了tracing更细力度的可观测的技术，可以帮我们更快发现问题、定位问题。如果后面有比这个观测技术更细粒度的，那可能就是从业务的一些代码堆栈去分析，比如刚才蒋老师提到的，最近很火的eBPF的技术，它可以在出问题的时候从代码级别去找出那个堆栈，定位出慢的问题，相当于从trace又下钻了一层，从服务级别去到代码级别的观测，但是增加这种更细粒度的可观测技术都是有代价的，比如tracing，依赖我们在程序去做埋点和进行改造，一不小心程序可能会挂，对我们后台存储压力也是大很多，eBPF也要有更新的内核才能支持到，对技术有比较高的追求或者说对故障定位时间要求更高的企业，做这个事情会更加合适。”

>>话题5：有些传统企业底子薄弱，如何才能利用可观测性提高故障解决的效率？

夏达："如果是比较缺少经验就只能主观想一想。我们做可观测性，一般都是要先定规范，但是在传统企业里，一边先定规范，再推着大家去改，但又拿不出价值来，可能比较难说服大家一起来适配可观测性来做比较大的改造。要么就业务比较老了，不太好改。这种反而只能从后面往前做了，就不能先定规范，然后大家去适备这个规范的，只能去先拿数据，做点东西来。然后让他们看到价值，再反过来从单个业务场景单点突破，再扩散一下，复制推广。"

蒋通通："还是回到场景上来说，故障解效率在我们这边其实我们提了一个1-5-10的处理要求，大致可以把故障处理分成三个阶段。1--故障感知阶段，快速发现故障，有业务风险；5--故障定界阶段，是否能快速把故障的出血点定界出来；10--故障修复，怎么给出血点止血，有没有相应的预案。可观测能够发挥价值的，其实还是在1和5，10如果说没有预案也恢复不了,1其实感知，我们不用做的那么重，不一定要求把所有的系统网源等等，每个节点都都覆盖掉，第一个要做的是去引入一些SRE、SLO的一些概念，我们先把一些业务的SLO给定出来，甚至是每个组自己关心的一些黄金指标，通过黄金指标的一些观测，先去把相应的一个问题发现，发现问题才能快速去解决相应的问题，这样也可以就是把用户的影响时间去做一个降低。5上面可观测性能做到的程度也不多，我个人观点，我觉得提高解决效率，更多是靠一些稳定性的方案，比如说做一些应用多活、预案体系，这样才能去达到快速解决故障的目标，单纯的做可观测性，可能就是发现了问题，也不知道能怎么办。"

石鹏: "这个其实跟我的观点是有些类似的。我更大的观点是这样，可观测数据，或者叫监控数据，它本身其实并没有价值，我们对它这些数据的这些分析理解，洞察，由此得出来的一些动作，决策它才能够产生价值。就包括故障处理的场景，监控发现我的系统挂了，但是我只看这个系统挂了它并不能好，而是说我知道它哪里挂了，哪里有问题，然后指导我去怎么去快速的精准的去修复，这才能够这个这个产生价值，才能够把我的系统快速的恢复回来。所以说这就这个，这也是我们很多公司可能是需要去建设和补齐的地方，当然有很多公司有，快速恢复平台、预案管理平台，怎么去快速的去执行一些已经有的预案，然后应对到一些故障场景上来，快速恢复。"

黄兆鹏（paul）："关于这个问题我分享一个我几年前也做过的传统企业的咨询，刚开始底子算是比较弱的，故障定位问题难，链路处理不清楚，后来建议他们先把CMDB给建设起来，先搞清楚你究竟有多少个服务，多少个应用，关系给梳理好先，关联的基础设施有哪些，再基于CMDB的基础上把分布式链路追踪给做起来，拿到trace数据以后，做可观测就准确很多了，但还是依赖上层，需要强有力的推动才能快速落地，特别是研发运维，对这个事情的重要性，要一致认同。如果这个业务实在是改不了，那么针对这种场景我们也有相应的算法去给他进行分析，当然准确度肯定没那么高，所以我觉得统一认同还是非常重要，只有大家都认可他的价值，才能齐心协力把可观测的事情给做好。"

石鹏："是的，其实从在一个企业里面想完整的去推行可观测，从上而下达成一致，这个真的非常重要。首先在理念上要达成一致，在行动上可能还是得有一些行政手段。然后有比较有大能量的leader来共同的推动，然后才能更好落地一些。说到给传统企业建议的话，我觉得倒不如我们先把这个现状先盘一下，看一下我们处理故障的现状是什么样子的，比如说像刚才这个蒋老师说的这个1-5-10的目标，目前我们大概是什么样的水平？然后我们先分析一下目前我们这个在故障处理过程中，然后我们哪个环节耗时会更多。然后我们再去各个击破。建设可观测性肯定是可以帮助你至少在这个感知发现的环节，可以去这个帮你提升速度，但是至于说你的问题。症结点到底是不是在这里，可能并不见得可以，这个详细盘一下看看。"

从几位老师的讨论中不难看出，可观测性的确是个非常具有可探讨性的热门话题，从 2021 下半年到今天，对可观测问题的讨论，不断见诸多技术圈，而且还大有愈演愈烈之势，直播活动已至尾声，对于可观测性的探讨却不会结束。

公众号后台聊天框回复

「大咖说」

即可领取全年可观测盛宴

虎牙、百度YY、OPPO、阿里、浙江移动、京东、美图、顺丰、联通、哔哩哔哩等等！还有讲师ppt哦~

我们还会准备直播的部分精彩片段

届时会发布在视频号上

大家可关注「优维科技EasyOps」视频号观看~