笔者从 12 年开始入行,从事 DevOps 研发工作,做过部署零碎、监控零碎、可观测性相干产品,也做过 SRE 一线和管理工作,对于可观测性的了解和实际,有一些小小的见解,利用本文和大家做一个探讨分享。本文次要内容包含:
- 可观测性在整个商业体系中的地位和价值
- 如何疾速发现故障,应用哪类指标告警
- SRE 在议论故障定位的时候,谈的是什么
- 如何找到故障间接起因,找到止损根据
- 如何让可观测性零碎出现观点,辅助洞察,定位故障
可观测性在整个商业体系中的地位和价值
做一个事,首先得有价值,如果价值太小不值得投入。可观测性也不例外,咱们首先剖析一下可观测性在整个商业体系中的地位和价值。思考第一个问题:作为在线类产品,咱们心愿客户 / 用户有一个好的产品体验,那怎么算一个好的产品体验?
很显著,产品体验包含性能体验和可靠性体验。性能体验依赖产品设计和迭代速度,跟明天的话题关系不大暂且按下不表。可靠性体验呢?可靠性体验外围就是谋求高可用、低提早,艰深讲就是每次关上站点或 app,都不报错,速度嗖嗖的。那如何能力具备好的可靠性体验呢?
其实如果一切正常,就应该是可用且速度快的,除非哪里出了问题,也就是产生了故障,才会报错或者提早大增。那技术团队要做的,除了继续优化架构和性能,就是一直和故障做奋斗了。升高故障产生的频率,升高故障的影响范畴,升高故障的复原工夫。演绎为 6 个字:降产生、降影响!
怎么做?有没有方法论来领导?咱们能够从故障的生命周期着手,来优化生命周期的各个环节,每个环节都做好了,实践上后果就是好的。故障生命周期的梗概图如下:
从大面上,能够分成事先、事中、预先三个大的阶段:
- 事先:及时发现危险,做好架构、预案、演练
- 事中:及时发现故障,及时定位,及时止损
- 预先:排查根因,落实复盘改良项
看起来寥寥数语,没有非凡的货色,但实际上每个环节要做好,都不容易。那可观测性,在这整个过程的职能是什么?在哪个环节施展价值?
显然,可观测性,是在故障发现、定位环节发挥作用的,外围价值就是帮咱们疾速发现故障、疾速定位故障,进而升高故障的影响。如此,可观测性的地位和价值就很明确了,用一张图概括:
客户 / 用户须要好的产品体验,好的产品体验包含可靠性体验,要想有好的可靠性体验,就得缩小故障,所谓的降产生、降影响,而这,又依赖了可观测性的能力。所以:可观测性最终是服务于产品体验、服务于商业胜利的(想不想获得商业胜利?依据方才的剖析可观测性可是重点因素哦),外围指标是疾速发现、定位故障。
那么,如何疾速发现故障?
如何疾速发现故障,应用哪类指标告警
要想可能疾速发现故障,得先定义什么是故障!简略来看,产品体验受损,就是故障!比方:
- 电商产品:用户无奈下单、无奈领取、无奈查看商品、无奈查看历史订单
- 存储系统:用户无奈读、无奈写、或者读写提早过高
- 流媒体产品:无奈开启播放、无奈拉流、无奈浏览视频信息
既然可能定义如何算是产品体验受损,那就能够梳理出相干的监控指标,比方:
- 电商产品:订单量、领取量、商品 / 订单拜访成功率 / 提早
- 存储系统:读 / 写成功率、读 / 写提早
- 流媒体产品:播放量和成功率、拉流提早、视频浏览成功率 / 提早等
大家有没有发现这类指标的特点?显然,都是能够量化客户体验的指标,这类指标咱们称为后果类指标(前面会介绍起因类指标),大面上能够分为两类,一类是业务指标,另一类是 SLO 指标。
个别公司做监控的时候,可能会意识到要做 SLO 指标的监控,容易疏忽业务类指标的监控。其实,业务类指标才是老板更为关注的指标,而且,SLO 指标失常的时候,业务指标未必失常。比方客户到服务端的网络出问题了,服务端的成功率、提早指标都是失常的,然而客户无奈下单,订单量会上涨。所以,肯定要器重业务指标体系的构建和监控。
听起来,业务指标和 BI 数据很像有没有?的确,最大的相同点是:都是老板关注的,哈哈。不同点呢?BI 数据对准确性要求很高,对实时性要求没有那么高,而业务指标监控,对准确性要求没有那么高(只有能发现数据趋势出问题了就能够了),对实时性要求很高,毕竟是用来发现故障的,如果实时性太差,黄花菜都凉了。
指标体系的构建,除了后果类指标,与之对应的还有起因类指标。都须要,然而咱们配置告警的时候,个别是针对后果类指标来配置。因为 产品的外围业务性能是可枚举的,每个性能对应的后果类指标就是可枚举的,做好后果类指标的告警,就能够保障告警是全的,做到有故障必有告警!举个例子:实时交易类零碎,交易量忽然上涨。
如果,面向起因类指标配置告警,则永远无奈配全,无奈做到有故障必有告警!实际上,起因类指标不用肯定要配置告警,出故障的时候可观测,其实也根本够了。
如上,要构建可观测性体系,首先要建设齐备的指标体系,其中十分要害的是后果类指标,即业务指标和 SLO 指标,后果类指标配合告警零碎能够疾速发现故障!从这里也能够看出,监控(monitoring)和可观测性(observability)是相辅相成的,非代替关系。
OK,既然能够发现故障了,下一步就是定位故障了。
SRE 在议论故障定位的时候,谈的是什么
在探讨这个问题之前。先分享一个信息层级的概念。说:信息分 4 个层级,最底下是数据,横七竖八,比方海量的指标、日志、链路追踪的数据;数据下面是特色,比方最大值、最小值、同环比等,比方 5 个服务实例,提早的最大的是哪个,这叫数据特色;特色下面是观点,从故障定位场景来举例,比方依据特色数据分析之后发现,数据库没有问题,依赖的第三方服务也没问题,这就是观点;观点之上就是洞察,或称洞见,综合所有观点,得出故障定位论断,得悉具体是哪个模块的什么起因导致了本次故障,就是最终洞察。画个图示例一下:
要想得到最终的洞察(定位到故障),首先要依赖底层的数据齐备性,否则就是巧妇难为无米之炊!然而故障起因形形色色,数据能全 么?做过 SRE 或者运维的敌人必定感触颇深,故障可能是电源模块坏了、机房空调坏了、机柜压住网线了、供电不稳、某个盘故障了、中间件配置错了、被黑客攻击了、分布式中间件脑裂了、写日志 hang 住了、程序配置错了、程序连贯第三方的地址错配成线下地址了、DNS 配错了、证书过期了、代码 Bug 了、疏漏了某个常见用户流程 … 等等等等。
这么多可能的故障起因,要通过可观测性数据分析进去,这数据能全么?比方代码 Bug,要想能依据可观测性数据分析出是哪一行代码的问题,岂不是要像在 IDE 里调试那样,每一行代码的输入输出都得拿到啊,这老本谁扛得住啊,性能损耗谁扛得住啊 …
如果咱们的指标只是定位间接起因,找到止损根据尽快止损,这个底层数据需要就少多了。比方咱们不须要晓得是哪行代码出了问题,咱们只有晓得是某个模块做了变更导致了故障,就能够去止损(这个场景的止损动作就是回滚)了。再比方,多活的服务,有时仅仅晓得是 A 机房的问题就能够了,把流量切到 B 机房就能够解决。
综上,个人观点:应用可观测性数据定位根因,几无可能 100% 笼罩全副场景!因为数据就不可能全!但如果只是用可观测性数据定位间接起因,找到止损根据,则 100% 是能够做到的,而这,才是咱们应该致力的方向。
当 SRE 在议论故障定位的时候,其实议论的时是如何找到间接起因,尽快止损。而根因,能够留在复盘阶段缓缓找的。
如何找到故障的间接起因
答复这个问题之前,咱们先来看看一个服务要想失常运行,依赖了哪些内容,或者说一个服务如果出故障,可能会是哪里的问题。如果咱们可能枚举故障类别,那么咱们就能够针对每个类别去剖析,找到故障的间接起因。
首先,依赖的基础设施(根底网络、硬件、Runtime 环境)不能出问题,依赖的第三方其余服务不能出问题,这两个方面大家比拟容易了解,不多说了。还有就是服务自身的变更,比方二进制变更、配置的变更、部署形式的变更、流量接入形式的变更,等等,也可能引发问题。最初就是上游拜访的形式,比方流量突增,显然也可能会带来故障。
那针对这些故障场景,咱们应该去看哪些数据呢?这其实就是可观测性数据底座的建设方向。
咦?说来说去,还是要建设 metrics、logs、traces、events?是的,但不仅是,只有数据还远远不够,咱们须要通过平台工具,通过数据经营整顿,帮忙用户找到数据特色,建设初步观点,最终造成洞察定位故障间接起因。还记得那张信息层级的图吧:
网上有人批评可观测性三支柱的说法,外围要点是:不能只关注 raw data,就像一道菜,只有原料还不能称之为一道菜,没有炊具、菜谱、厨师,无奈最终产出那道菜(客人要的是那道菜,那道菜才是后果,应该没有哪个餐厅说,你看我原料都有,完活了,让客人吃吧,应该没有这样的餐厅 …)。
Martin Mao 已经也写过一篇文章《Beyond the 3 Pillars of Observability》来阐述这个事件。
他的外围观点是:只关注三支柱 raw data,认为有了三支柱数据就建设了可观测性,是不对的,咱们更应该面向后果来思考如何构建整个体系,Martin Mao 认为,所谓的后果,就是 Remediate,就是止损!英雄所见略同。
可观测性体系具体要如何做能力辅助技术团队止损
还是参考方才信息层级的图,有了 raw data 数据底座之后,可观测性体系还须要利用平台能力、通过数据经营整顿,出现数据特色、帮用户建设初步观点,最终造成洞察,定位故障间接起因。
可观测性体系要通知我故障模块
这应该是可观测性体系提供给客户 / 用户的第一个观点,故障产生了,当初都是微服务的,你得高深莫测的通知我具体是哪个模块故障了不是。总不能让我写一条有一条的 promql,看一个又一个监控大盘,能力找到故障模块吧。故障解决可是要争分夺秒的,一个一个查看太浪费时间了。
既然要高深莫测,初始页面上的内容不能太多,从技术角度来看,个别模块都是有层级关系的,首先是零碎,而后是子系统,而后是模块。所以,初始页面应该展现零碎的健康状况,如果某个零碎有问题,应该能够点击进去查看详情(这个过程称为下钻),下钻到子系统,再下钻到模块,最终找到故障模块。
那如何掂量一个模块是否衰弱呢?这其实就能够应用 SLO/SLI 这套体系,每个模块都有几个 SLI,每个 SLI 异样,这个模块就能够定义为异样,进而定义子系统异样、零碎异样,这个过程也有种故障冒泡上浮的感觉。
我以咱们的产品来举例这种效果图:
这样的零碎咱们称为灭火图,最上层是一个个的零碎卡片,如果有问题就会有个飘红的小火苗,点击详情进入,能够看到相干子系统,点击故障子系统,能够看到模块以及外围接口的列表,进而能够定位到故障模块或外围接口。产品通过色彩做疏导,而且具备层级关系,即可做到高深莫测。
可观测性体系要通知我故障模块的各项依赖是否衰弱
模块依赖的数据库、中间件、根底网络、机器硬件、第三方服务等等,都会影响模块的健康状况。所以,当模块异样的时候,咱们须要晓得各项依赖是否衰弱,如果依赖也异样,那么模块异样的间接起因根本能够判定是异样的依赖项导致的。
要用可观测性产品建设这样的视图,外围有两点,一个是依赖的关联关系,一个是依赖项的 SLO 视图(通常体现为 metrics 仪表盘)。下图是一个逻辑示意图:
可观测性体系要通知我是否是变更导致的
线上故障,大略 70% 都是变更导致的,所以运维行业中流传一句话叫:“变更是万恶之源”。所以,当故障产生的时候,咱们须要晓得是否是变更导致的,如果是变更导致的,就要尽快止损。
如果迭代比拟快,每周的变更数量会很多,那么如何疾速定位到是哪个变更导致的故障呢?这须要可观测性产品提供一些数据特色给用户,用户能力不便剖析。典型的是在工夫维度上做文章。把故障和变更放到一张图上,在工夫维度上做比照,比方从故障时刻往前看 1 小时,看看有没有变更,如果有,那个变更很可能就是罪魁祸首。示意图如下:
留神,这里的变更不仅仅是代码变更,还包含配置变更、机器变更、网络变更等等,变更事件收集得越全,越有价值。
下面,我举例了三个可观测性产品须要为用户输入的观点:
- 可观测性体系要通知我故障模块
- 可观测性体系要通知我故障模块的各项依赖是否衰弱
- 可观测性体系要通知我是否是变更导致的
当然,还有其余观点能够输入,比方是否是容量有余导致的故障,大家能够自行思考看看还能够让可观测体系输入哪些观点。然而,罗马不是一天建成的,在某个阶段,可观测性体系输入的观点无限,不足以帮咱们定位故障,此时,可观测性体系还能够做什么呢?
至多,还须要提供工具帮咱们剖析数据特色,别让用户陷入海量散乱的可观测性 raw data 中。这须要多维分析疏导能力、数据串联买通能力。举一个数据串联的例子:
总结
可观测性体系不能仅仅只有散乱的数据,而应让数据出现特色,让特色出现观点,让特色和观点辅助洞察:洞悉故障间接起因,实现止损!这才是建设可观测性体系的外围指标。诸君共勉。如果您认同咱们的建设思路和价值主张,也欢送关注咱们的产品:https://flashcat.cloud/,咱们违心成为您向上的台阶,让您的可观测性体系更加欠缺,让技术体系底气更足。快来聊聊吧: