
上一期可观测性文章《可观测性(一)》里面聊了可观测性的定义、价值和三大支柱。
其中值得再次提及的是,可观测性的核心目的是以量化的方式管理企业的基础设施(包括中间件等)、平台和应用程序。
正所谓 “如果你无法量化它,你就无法管理它” -- 彼得·德鲁克。
同时还有一个要点,就是可观测性要完成闭环,终究需要告警管理平台来做连接--将问题指标即时反映给相关维护人员,以解决系统无法自修复的问题,同时提高系统自修复能力。
接着这个话题,这期我整理了构建一个优秀的可观测系统需要哪些核心能力。
(由于这个话题近乎实操,太过深入,本人暂时力不能及,但学习完之后又觉得很有价值,想分享给大家,同时留作日后回顾。因此以引用的方式将精髓呈现出来。)
原文来自公众号《成哥的世界》,作者:Cheng哥。有删改。
通常我们在IT领域看到的关于可观测性概念的介绍,都会提到它是Metrics, Traces以及Logs的结合,通常会以下图来呈现。

这里我找了一个Splunk的Demo,我们可以直观的感受一下,可观测性的实际效果是怎样的。

大家看完这个示意,对可观测性就有更直观的理解了,不做赘述。
但是这个Demo就只能作为Demo看一下,现实情况远比这个要复杂的多,原因我们后面会讲到。
不过,这里就有问题了,监控做了这么多年,Metric都是全的,日志系统也上了,Log一条都没拉下,调用链工具也引入了,Trace拓扑也能画出来,那上面这个效果是不是将三者结合一下就有了呢?
答案显而易见,是否定的。相反,现实情况下上述的效果并不容易达成,这里不仅仅是Metric、Trace和Log三者的技术结合在一起就OK,这只是外在的形,要想达成这个效果,其实更关键的是背后的神。
那这个神到底是什么,接下来我就换一个方式描述一下这个过程,把背后更为核心的内容呈现出来。
可观测性Observability的剖析
一图胜千言,我直接用一张图来描述,如下所示:

其实有了这张图,对Observability有一定理解的同学,应该就看的差不多了。
如果说Observability的内在的神是什么,总结下来就是3部分内容:
- SRE方法论
- AIOps算法能力
- 业务架构的理解,这里暗含着对领域知识的掌握

我们可以看到,这三部分的核心能力的掌握就不单纯是技术能力的体现了,这里要有非常深厚经验积累和时间,以及长时间对业务架构摸索和理解。
也只有在这三部分核心能力的指导下,像Metric、Trace和Log这样的技术手段才能发挥最大价值。
接下来我们再谈谈为什么这三个核心能力非常重要:
可观测性之SRE方法论
这里面要用到SLO的方法,帮助我们识别关键Metrics,快速感知问题发生,主要是在Detect阶段。
我们知道复杂系统下,会包含网络、应用、分布式中间件、容器、主机、存储、数据库等等多层设备和部件,每个部件都会有自己的各类指标。
但是指标这么多,出问题同时告警,那就告警风暴了,一个是会造成关键信息淹没,再就是信息多了,告警就变成了“狼来了”,接收告警的人就麻木了。
这个时候就要设定SLO,而且SLO得是要分层设定,业务层面,要关注业务SLO,比如GMV、订单量、支付成功率等等。
系统层面就要关注系统SLO,比如订单接口成功率、时延和TPS等等,应用就要关注应用的SLO,缓存、消息、存储、数据库,以及底层的网络、容器、虚拟机、硬件主机要也要有自己的SLO。
SLO怎么设计,我不详述了,之前讲了很多,大家自行了解SRE的SLO机制就好了。
不过,即使做分层设定,出问题告警依然很多,我可以通过选定最上层的业务SLO来感知出问题了,提升响应速度,但是问题出在哪儿依然未知,这个时候在这种复杂系统中,就必须依赖AIOps的能力了。
可观测性之AIOps
AIOps领域,针对Metric、Trace和Log,都有专门的算法来应对支持,对应三类,比如针对Metric,就是KPI Anomaly Detection,针对Trace就是Tracing Anomaly Detection,针对Log就是Log Anomaly Detecion。
所以,AIOps是会始终贯穿整个Observability过程的,关于AIOps推荐看一下清华裴丹教授的文章和课程,会有更详细的分享。
可观测性之业务架构的理解
如果SRE方法论和AIOps是落地Observability的两个核心,那对业务架构的理解,我对它的定位就是核心中的核心。
我们在架构领域经常听到的一句话就是,“脱离业务谈架构就是耍流氓”,其实也适用于Observability,适用于SRE和AIOps,脱离业务架构谈Observability就是耍流氓。
那对业务架构的理解为什么这么重要呢?我们看两个场景:
第一个,还是回到SLO设定上,当我们设定业务SLO时,我们是要根据业务类型和特点来的,或者换种说法,用户对我们业务的感知,是通过哪些指标来体现的?
首先,我们得能定义出来,比如电商可以是可以订单和支付维度来判定,对应会有下单成功率、下单量,支付成功率,支付笔数等等。
再进一步,正常这些指标都一个平滑的驼峰式曲线,等但是在做活动时,它可能就是一个个的尖峰和突刺,在节假日它的同环比会下降,遇到热点商品,可能会出现一段时间的波动,但是这些场景并不意味着系统出问题了,这种就要在AIOps的算法里识别出来。
那类似微信的IM又是什么指标和特点?社交软件微博又有什么不同?跨行业的电信运营商,以及银行、证券、保险等金融行业又各是什么特点。
这些都取决于对业务场景的深刻理解。
如果说第一个场景只要我懂业务就可以设定SLO,那如果我往深里看,那就不仅仅是对业务场景的理解了。
第二个,我们往业务架构深里看,我们都知道复杂分布式系统里,调用关系是异常复杂的,会呈现密布的网状调用关系。

当然现在有各类Trace工具能帮我们把调用拓扑呈现出来,也可以根据TraceID或业务ID单独看某次的调用链,确实方便了很多。
但是这么复杂的调用关系全部呈现出来,我到底应该怎么看?
答案是基本没法看!
所以这个时候就必须得事先规划出一条核心的业务链路,也就是我们常说的业务关键路径Critical Path,再进一步,关键路径上就会有核心应用,只有对照着这个路径去看,Observability才会有针对性和指导意义。
所以上面的那个Splunk的Demo,我们为什么说就是个Demo,因为现实中的调用关系要比Demo复杂N多倍,但是它想呈现的效果,就是针对Critical Path关键路径路来的。
关于Critical Path,核心应用,强弱依赖关系等等,在我的课程和之前的文章中都有,可以自行查阅。
所以讲到这里,我们可以看到,Observability从业务来讲,其实是需要事先定义出如下一条业务分析链路的:
业务SLO—Critical Path—核心应用SLO—核心分布式组件SLO—容器SLO—IAAS SLO
只有这个链路清晰了,AIOps才会发挥最大的优势,Observability的效果才会呈现出来。
一开始可以冗余,不那么清晰,但是必须得有,就像杭州到深圳,大家得知道杭州打车去机场,飞机去深圳机场,到了深圳再打车或地铁去目的地,这就是一条主线,这个都没有,基本就没法出门了。
所以,要做到这个程度,你就得懂业务、懂业务架构、懂技术架构、还要有一定的经验积累和沉淀,不然没法做判断。
上面讲了那么多,我放个示例,就不多讲了。

当然,可能会有人挑战我说,AIOps可以做到无监督学习,自行分析关键路径,不用这么麻烦还要人工分析。
当然,我相信未来有一天或许会做到,但是到目前为止,我觉得这还不现实,即使能分析出链路来,但是已然离不开架构师的梳理和确认。
这个状态,我觉得就跟现在的无人驾驶一样,绝大多数情况下,他可以自动巡航,但是关键时刻还是离不开人的判断和控制。而人的判断又是来自于驾驶经验、交通法规、伦理道德以及当时的精神面貌等很多因素。
从这个角度,自动巡航能力只是人的决策依据的一部分而已,只能做辅助,永远离不开也取代不了人的判断。
最后,总结一下:
当前看到的Observability的产品只有Metric、Trace和Log的技术描述,额外再加上部分AIOps的加持,但是这些只是形,没有神。
要想有神,最关键不能离开业务和场景,所以SRE方法论、领域知识(业务和架构)以及AIOps才是Observability的落地的关键所在。
而这三者之中,对业务场景及业务架构的理解程度,决定了SRE和AIOps可以发挥的效果如何,也最终决定了落地的效果。
再就是,为什么之前很少有人提Observability,这两天如此火热,我觉得还是技术应用发展到一定程度的结果,大家前几年都在分头搞监控、链路跟踪和日志系统,这两年搞差不多了,自然就会有更高的应用诉求。
所以,从技术上讲,并无新鲜的东西,关键还是得有更清晰的判断和思考。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库