HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

被 Gartner 列为“2023 年十大战略技术趋势”,爆火的可观测如何正确落地?

  • 2023-02-27
    北京
  • 本文字数:5467 字

    阅读完需:约 18 分钟

被Gartner列为“2023年十大战略技术趋势”,爆火的可观测如何正确落地?

Gartner 将应用可观测性列为“2023 年十大战略技术趋势”,为什么可观测性如此重要?有哪些值得关注的演进趋势?如何设计落地方案?近日,博睿数据创始人兼 CTO 孟曦东做客 InfoQ 极客有约,全方位解读可观测技术。以下根据直播内容整理,有不改变原意的删减,完整内容可点击查看回放视频

2023 年,如何正确理解可观测性?

 

InfoQ:近两年,大家对于可观测性的讨论逐渐多了起来,先请您给大家介绍下什么是可观测技术?可观测技术的演进趋势是怎样的?

 

孟曦东:可观测性是个老话题了,最早在控制学原理里就有类似的描述。可观测性本身是一种衡量系统内部状态的能力,通过外界的信息与数据,更好地了解系统内部的运行状态。从整个 IT 系统来说,可观测性是一个比较新的话题。2018 年,CNCF 才把可观测性这个词着重描述到云原生的技术能力之中。在这之前,IT 系统经过了多种形态的演进,由单一的、通过中央式的服务提供数据,逐渐发展到到分布式、高可用、云原生等。

 

所有系统都会部署到趋于复杂的环境之中,同时系统之间的调用也更加频繁。如果企业依旧使用传统的模型管理如今的 IT 系统,不可预知风险发生的几率会大幅增加。彼得·德鲁克曾说过,如果你无法衡量它,你就无法管理它。在如今复杂的 IT 世界中,我们如何能真实地看到可能发生的问题,或者说问题产生的原因,是一种更大的挑战。

 

从可观测性的发展历程来看,之前企业更多是获取数据,以及做整个系统的监控运维。监控是比较单一、简单的,只会借助一些特定的指标项,去看它的变化情况,进而知道现在发生了什么样的问题。

 

而可观测性的重点在于可解释性,不只是简单地看到问题的发生,更要了解问题发生的根因。它是一个观测-判断-优化-再观测的周而复始的闭环,从而让我们更好地了解 IT 世界中的一些变化的根因。可以说,可观测性是为业务服务的,业务在运行过程中也需要这种衡量的手段,以此来把控问题。不难看出,可观测性发展到今天,对于企业内部 IT 系统的交付及后续运营,起到了决定性的帮助。

 

InfoQ:可观测性的数据来源是什么?和传统监控之间存在哪些差异?

 

孟曦东:数据本身的三支柱,或者说最重要的三种类型的数据:描述状态的指标、描述业务内在关系的日志、追踪的数据。这三种数据在监控体系中单独去看的话,也是有自身价值的。但如果只通过一种数据的模型,很难构建出寻找问题核心的能力。所以说,我们现在需要做的是把这三种类型的数据有机的贯穿在一起,形成一个立体化的架构,使它们互相去发挥各自的专长。

 

在运维中,很大一部分的工作就是收集报警信息,以此来获取到系统的实时运行状态。这时候,我们用这种所谓的 metric 就是非常有效的。但如果我们想了解某个事务的完整流程,比如从第一步的操作到最后的这一流程,其中经过了多少个系统的衔接才得以实现,在此过程中存在什么样的问题?那就需要跟踪数据来帮助我们回溯整个链条,以此来定位问题发生的环节。所以数据不是孤立的,组合在一起才能发挥出最大的效果。

 

InfoQ:重视可观测性,对企业和开发侧能带来多大的价值?

 

孟曦东:在大数据时代,获取数据并不困难,困难的是如何挖掘数据的真实价值。而可观测性能力的提出帮助我们在运维体系中实现了一个方法论。最早在 Google 公司的定义中,可观测性的最大价值就体现在解决问题方面。面对突发的事件,如何保障业务的稳定性,不让业务受损,是需要一套合理的体系来支撑 IT 系统更好的发挥自身价值。虽然目前也存在各种类型的工具,但事故的发生依旧很频繁。所以说,可观测性要真实地衡量系统内部的状态,而不是仅仅为了收集数据。博睿数据希望看到的是可观测性对企业的业务产生正向的转变和影响。

 

另外,在可观测性构建的整体过程中,还存在三个可能被忽视的方面:

 

  • 首先就是用什么样的标准体系,我们需要通过方法论制定自己的 SLO;

  • 其次,我们要了解自身的 IT 业务架构与核心业务流程,因为不同业务有不同的模型;

  • 最后就是 AI,运维的整个过程是繁琐的,如果仅依靠人的经验,那么时效性的保障与知识体系的传递都是比较困难的。而 AI 拥有构建一种完整体系的能力,帮助我们去发掘数据之间的关联性、发现我们不易察觉的问题。

 

以上三个方面是埋在整个数据体系下面的,对于做好可观测性也是非常关键的。

 

大家不难看出,当今时代对于效率的追求是非常突出的,所以智能化的管理手段和深度的能力对于企业是非常有必要的,否则在市场竞争上面的优势是无法持久的。因此围绕整个可观测性来看,最核心的点就在于业务价值的实现。

基于 eBPF 的可观测探索

 

InfoQ:当前不少公司采用 eBPF 技术在可观测方面进行实践,eBPF 为可观测带来哪些新的解题思路?

 

孟曦东eBPF 技术是 BPF 技术的扩展,eBPF 技术扩展了整个寄存器的数量,同时引入了新的映射存储能力。简单来说,我们内核的修改难度和风险都是非常大的,而 eBPF 技术的引进,我们就可以实现网络和内核之间的交互,或者在内核的功能模块之间,在用户态与内核态,包括覆盖整个用户态的进程。

 

通俗来讲,我们想了解自己的应用程序运行的性能质量,那么通过 eBPF 技术,就可以看到用户态在这个函数的耗时及交互能力等。所以说 eBPF 技术覆盖了多种能力点,包括 CPU 的调度能力、内存管理能力等,都可以通过 eBPF 技术去很好地实现。

 

eBPF 技术的应用场景也是非常多样化的,从早期的网络到现在的云原生等等,如今想要拿到真实的流量数据,eBPF 技术是必不可少的。如果想了解用户态在运行过程中,CPU 是什么样的状态,诸如此类的状态变化需要在内核态中才能真正拿到,此时 eBPF 技术就可以帮我们去加强和加深数据的捕捉能力。所以 eBPF 技术能干的事情非常多,并且在多种场景之中都有用武之地。

 

InfoQ:博睿数据基于 eBPF 技术有哪些可观测方案实践?未来会有哪些规划?

 

孟曦东:博睿数据一直有在研究和引入 eBPF 技术,主要是基于云原生环境下数据流量的获取。在构建可观测性的过程中,反映内部系统变化的能力其实是一种度量单位,系统内出现的问题是需要流量数据来做有效补偿的。博睿数据希望能给客户提供完整的解决方案,而通过 eBPF 技术可以很好的捕捉流量数据,帮助我们去定位问题。

 

另外,如果不使用 eBPF 技术,部分系统级的指标就无法完整获取,因为这个过程在内核态与用户态都可以运转,所以 eBPF 技术可以帮助我们更好地进行性能捕捉,无需注入到进程里面,并且可以更往下一层,更适应于目前开发的模型。所以整体来说,博睿数据希望在今年发布更多引入 eBPF 技术的产品。

落地可观测需要注意哪些关键点?

 

InfoQ:从行业的角度来看,目前市场对于可观测性的认知和需求分别是怎样的?

 

孟曦东:这需要去做一个大体的拆分,因为博睿数据也一直专注于可观测领域的研究。2020 年 是博睿数据可观测性的元年,在这之前我们更多的把产品与能力集中在 APM 方面,还未能真正达到可观测性的要求。

 

从整个行业的使用客户中也可以看出,不同行业对于可观测性的诉求也是不同的。比如金融行业,他们已经针对可观测性做了很多方面的尝试,不论是在数量亦或是质量方面都是比较可观的。所以并不是说可观测性技术的渗透率有多高,而是说很多企业已经对此产生了共鸣。

 

可能很多企业依旧处于初实验阶段或者技术考察阶段,但在未来几年里,可观测性的发展速度可能会有指数级的变化,因为故障的产生的无可避免的,而可观测性技术可以覆盖到软件的整个的生命周期之中,形成完整的链条。同时可观测性技术还可以与自动化体系结合在一起,使企业的效率得到数倍的提升。

 

从目前的市场情况来看,可观测性已经有了一些落地的实践,之后也会有一个慢慢成长的过程。疫情过后,很多人对于数字化转型可能有了全新的认知,在新的系统架构和开发模型下,企业需要一种能力来规避问题的发生,降低问题的影响,所以可观测性恰好适应了现在整合技术的发展路径。

 

InfoQ:目前国内的可观测性发展处于什么样的阶段?背后的主要原因是什么?

 

孟曦东:可观测性所涉及到的环节是比较多的,目前国内可观测性的发展还处在前期的试探阶段。

 

可观测性涉及到的环节较多:

 

  • 第一,可观测性需要数据作为支撑,并且对于数据的质量有一定要求。数据需要经过标准化的处理过程,才能真正作为基座来使用。

  • 第二,数据量,需要海量的数据,并且涉及到不同的类型。博睿数据追求的是每一笔交易、每一个动作都能有完整的链条,所以我们面对的数据规模是十分庞大的。同时,可观测性技术本身就是一个大数据汇总的平台,因此需要高技术引擎和关系图谱引擎的支撑,来将数据有机的结合到一起。

  • 第三,若要真正发挥可观测性带来的价值,不能仅仅只把数据做一个简单的罗列,我们需要剖析数据,做关联分析,而这一过程需要 AI 的加持,这样才能让效率真正提升上来,这其中涉及到一整套的系统工程。

 

以上三点做好之后,我们才能真正体会到可观测性的优势,体会到数据作为大脑引擎的驱动力,让企业的运维管理更智能、更便捷、更高效。

 

InfoQ:企业在实际落地可观测的过程中通常会陷入哪些误区?

 

孟曦东:首先是开源和商业化如何平衡的问题。不管是可观测性还是之前的监控技术,都有大量的开源能力在支持,有很多的免费方案供使用。对于任何一个企业来说,是否在专注地去做这样一个系统,还是说只是为了辅助主营业务来做系统叠加,前期的投入与最后的结果很可能是有较大落差的。

 

其次我们在可观测性的建设过程中,总是期望大而全,这就需要考虑到几点因素。第一点,系统需要人为去操作,组织架构中人的水平与素质很大程度上决定了系统的使用能力上限。第二点,技术栈的繁杂性导致了数据治理需要较长的时间,而到了数据的实际使用场景,我们会发现,这其中涉及运维、研发、测试、业务等各部门的人员,部门间的数据孤岛会对数据产生一定的割裂,导致数据无法真正统一在一起。

 

最后是成本问题,技术并不是一成不变的,从基础监控到网络监控,从 APM 到可观测性,技术是不停在发展的,包括研发的过程,经过了多次的更新迭代,才到了现在微服务的架构。因此要维护一个复杂的技术栈,后续的模型是不是能够真正跟得上就很重要,这需要一个团队持续去迭代,所以企业需要从综合成本方面去考虑可观测性的方案。

 

InfoQ:自建可观测基础设施和引入可观测软件产品,对于不同的企业而言应该怎么选?分别有哪些注意事项?

 

孟曦东:这个首要要从企业的发展阶段来看,包括人力情况、技术栈的成熟度与稳定性等各个方面,不同的阶段可能会用不同的技术来覆盖。自建可观测性,不管使用开源技术还是自研,都可以切实解决一些问题。但核心点在于,后台如何去解决?我们不能只着眼于采集数据、传输数据层面,要考虑如何用 AI 赋能。

 

另外,开源或者自研的技术涉及的环节链条是很长的,它可能只解决了前端数据来源的问题,后面的标准化、治理、AI 能力等如果不能做到位,就无法真正体现可观测性的价值。另外,将多种开源技术组合在一起,可能会有不可抗风险的出现,因此在做之前一定要做好评估。

 

还有就是团队的流动性问题,企业在使用开源技术的时候,非核心业务系统人员的变更频率要更高一些,人员变更导致的风险也需要去做一定的评估。

 

如果已经做好了相应的评估,并拥有完善的团队和前期的建设经验,那么自研也可以说是一种不错的方案,也可以多看一些成功或失败的案例经验。同时,尽量要避免盲从的问题,仅仅将技术堆砌在一起的话,后期需要做的工作只会越来越多,因为不把每一个环节都夯实的话,最终呈现的效果很难达到预期。

 

InfoQ:博睿数据博此前发布了一体化智能可观测平台 ONE 2.0,它的整体设计思路是什么样的?后续还有哪些规划?

 

孟曦东:Bonree ONE是博睿数据基于可观测领域发布的一款新的产品。博睿数据从 2008 年开始,就专注在 APM 的赛道上,在 Bonree ONE 推出之前,博睿数据的产品模型是比较分散的,客户在使用过程中需要面对多个系统,举例来说,假如客户使用了 A 系统和 B 工具,就需要在不同的系统之间切换数据,没有真正形成数据的一体化,工作中的效率就会打折扣。

 

另外就是博睿数据之前的产品架构相对冗余,同时使用多种工具就会涉及到相关的公用组件和不公用组件,给实施部署和维护增加了不少难度。

 

基于这方面的考虑,博睿数据在 2021 年底根据国内情况,希望能将一种能力或平台提供给客户,因此决定推出 Bonree ONE,这其中融合了几个我们迫切想解决的问题。首先是一体化的问题,不管是前端的用户体验,还是后端的 IT 运转流程,亦或是业务代码的运转状态,都可以通过 Bonree ONE 来实现数据的关联分析,真正做到数据的有机一体化。第二部分是智能化,割裂的数据在做分析的时候,其效果往往是差强人意的,所以我们希望借助 Bonree ONE 实现数据质量的高可用和真正的 AI 赋能,让问题预警、根因定位等方面达到前所未有的高度。第三部分是可观测性,博睿数据突出了其中的开放性和兼容性,可以兼容第三方的数据,并且很方便的把数据接入到 Bonree ONE 中去。

 

Bonree ONE 在使用场景的规划上也推出了灵活定制的分析模型,通过构建指标 PPI 让入门级的使用者也可以很容易了解各种指标的价值及用法。同时在使用场景上,也不再以可视化分析为主体,而是将应急管理、报警响应作为主体来驱动自动化系统或 ITSM 系统,这是 1.0 版本我们着重提升的点。

 

到了 2.0 版本,Bonree ONE 的发布会涉及几个大的能力点,包括 eBPF 技术的流量数据的接入、业务模型的分析、数据价值的产生、云资源的评估等。所以整体来看,博睿数据专注到了 Bonree ONE 这样一个平台之中,后续我们也会在 Bonree ONE 上嫁接更多微应用,并且在适当的时间点开放微应用的开发能力,推动更有价值的落地实践的出现。

2023-02-27 10:423431

评论

发布
暂无评论
发现更多内容

探索语言交互技术在政务数字化的应用

华为云开发者联盟

语音 政务 语言交互 VUI G2c

统一数据管理工具——CloudQuery v1.3.3 上线!

BinTools图尔兹

数据库 运维 开发工具 dba 数据库管理工具

区块链终将彻底改变医疗行业,但哪些因素制约当前的采用?

CECBC

区块链

为您收录的操作系统系列 - 进程管理(中篇)

鲁米

操作系统 进程 同步

Mybatis【18】-- Mybatis自关联多对一查询方式

秦怀杂货店

mybatis

回顾与总结 | 视频号28天(28)

赵新龙

28天写作

你会在车里唱K吗? (28天写作 Day27/28)

mtfelix

28天写作 智能汽车 MaaS 出行方案

Kubernetes安装篇(下):基于Kubeadm方式的集群部署

xcbeyond

Kubernetes kubeadm 部署 28天写作 Kubernetes从入门到精通

口碑销量双爆的数据分析丛书再添新成员!

博文视点Broadview

面试官:请讲一下Redis主从复制的功能及实现原理

华为云开发者联盟

redis 数据 节点 redis哨兵 主从复制

机器学习笔记之:Addition and Scalar Multiplication

Nydia

速看!教育上云 让学习战“疫”两不误

教育云

Spring Boot Admin 集成诊断利器 Arthas 实践

阿里巴巴云原生

Java Docker 容器 云原生 Arthas

5步教你将MRS数据导入DWS

华为云开发者联盟

数据 MRS GaussDB 集群 DWS

Webpack | 如何提升构建速度,进行体积优化?

梁龙先森

大前端 webpack 28天写作 2月春节不断更

十倍效率背后的管理逻辑

Ian哥

28天写作

【JS】异常处理

德育处主任

JavaScript 大前端 js 28天写作 2月春节不断更

Elasticsearch Bulk API 奇特的 JSON 格式

escray

七日更 28天写作 死磕Elasticsearch 60天通过Elastic认证考试 2月春节不断更

Spark Shuffle 内部机制(一)

hanke

大数据 spark 开源

Kafka架构介绍

架构精进之路

kafka 七日更 28天写作 2月春节不断更

如果生命的长度可以被改写「幻想短篇 27/28」

道伟

28天写作

人员培养,不是捷径的捷径(下)

一笑

管理 人才培养 28天写作

让我们与内心聊聊,寻找一段思考发展之路。

叶小鍵

程序员成长第三篇:好的代码和好的工程师

石云升

28天写作 2月春节不断更 工程师等级

一个合格的初级前端工程师需要掌握的模块笔记

我是哪吒

程序员 面试 Vue 大前端 2月春节不断更

RocketMQ-Spring 毕业两周年,为什么能成为 Spring 生态中最受欢迎的 messaging 实现?

阿里巴巴云原生

Docker 容器 微服务 云原生 API

区块链+电力,又擦出什么新火花?

CECBC

区块链

SpringIOC的注解开发

小马哥

Java spring 七日更

驱动力读书笔记之三

张老蔫

28天写作

信任从对自己诚实开始

Justin

心理学 信任 28天写作

Elasticsearch+Fluentd+Kafka搭建日志系统

远鹏

kafka ELK EFK Fluentd 日志系统

被Gartner列为“2023年十大战略技术趋势”,爆火的可观测如何正确落地?_文化 & 方法_凌敏_InfoQ精选文章