从业务开发视角聊聊可观测体系建设

作者：vivo 互联网服务器团队- Lei Zezheng

对于分布式框架状态下的可观察体系搭建实践展开了探讨，给出了基于业务角度上的可观测体系搭设架构，此架构需要分别明确业务内在核心界限，构建指标体系，也就是业务指标加上SLO指标，还要搭建多方面维度的观测，涵盖业务观测，链路观测，异常观测以及变更观测各方面，并且要使排除障碍的通道固定下来，以游玩中心项目当作实例，说明了该项目在问题发觉与对具体问题进行方位确定上的实践情况，有效地把问题发现在以及故障应对的效率得以提升。

1分钟看图掌握核心观点

相较于图 1 与图 2 相比较而言，您会更加倾向于选择哪一张图用以辅助对全文进行理解呢？欢迎在评论区留下您的言论。

一、背景介绍与痛点分析

在分布式架构逐渐成为主流的当下，可观测性，也就是Observability，于行业范围之内愈发受到重视。可观测性所指的是，系统能够依据其外部输出，进而推断出其内部状态，并且系统倘若可观测性越强，那么我们对于系统的可控制性便会越强。如今，怎样去提升整体系统具有的可观测性，借助应用可观测工具达成业务保证可用性这一目标，已然成为了每一个SRE以及业务开发都必定要思考的课题。但，随着业务复杂度的日益提高，以及“1 - 5 - 10”（即1分钟内发现问题，5分钟内定位问题原因，10分钟内恢复故障）可用性保障目标等的不断提升，我们，也察觉到了可观测体系在我们业务落地过程中的一些问题。

就此种种差异而言，于平台一侧所提供的观测工具同业务开发所使用工具之间，造成了蛮多令人苦恼之处。游戏中心身为toC的分发类业务里的一个颇具代表性的项目，其可观测体系的构建进程值得一提，现下归纳其中某些经验，期望对其他业务项目能有一定助益。

二、可观测体系的数据基座

就可观测而言，大家或多或少都听闻过可观测性所谓的“三大支柱”，即指标、日志和链路，在2017年，Peter Bourgon所撰写的文章《Metrics, Tracing, and Logging》 对这三者的定义进行了系统阐述：

那么，我们监控团队，已基本完备地采集好了这些数据，还呈现了像日志中心、应用监控、调用链指标监控等工具，这是否就意味着能确保我们系统的可观测性呢？答案显然是否定的，有了西红柿、鸡蛋、盐，并不意味着我们就能吃到西红柿炒鸡蛋了，三大指标都有其明显特征与使用场景：

运用各类指标单独进行操作，始终仅在部分情形下有着适用性，虽说并非全然毫无效用，然而若要借助系统化方式达成目标，必定会显得颇为费劲，并且缺乏条理。针对相对简单的问题，像是日志突然打印出空指针异常、数组越界这类错误，我们查看日志中心后便能很快确定具体代码行位置，进而剖析上层参数状况，并且迅速排除故障。可是当问题复杂度稍有提高，例如：

当这类问题出现之际，日志中心会有异常反应，应用指标会有异常反应，超时链路同样会有异常反应。除此之外，事实上绝大多数系统问题皆是因变更致使或者触发的，因而除了上述三个关键数据以外，还得结合一些与变更相关的系统事件来辅助进行根因定位。我们没办法全天候时刻留意各项指标，必定要借助配置检测以及告警以主动获得通知。

日志，以及指标，还有链路，再加上变更事件，以及告警这般，共同去构成了我们那可观测的数据基座。

三、业务视角的可观测体系建设框架3.1 业务核心分治

对于多数系统而言，我们构建可观测体系，皆是为了能及时察觉系统里出现的各种故障，然而身为业务开发，在实践当中我们会发觉，在这个标准之下：全是故障，可也存在差距。“游戏中心首页呈现白屏现象”、“登录遭遇失败状况”、“下载出现失败情形”，此等问题一旦出现，那便是致命性的伤害，等故障已然爆发之后才发现，这是无法接受的。可是对于“游戏评论进行刷新时出现延迟状况”，“我的页面成就进行刷新时出现延迟情况”之类的故障，在资源处于有限状态时，或许稍微迟缓一些去处理，也并无妨碍。

所以依照分治的想法，首先要去做的便是“明晰业务核心界限”。要是拆解出来的核心业务依旧相当繁杂，那么就应该持续把视角朝向内部，在将业务拆解成最小的核心单元之后，再分别开展观测，进行视察和测定。

3.2 指标体系的建立

业务系统的首要观测指标，无疑是业务指标，它能直接反映业务的健康状况，像“游戏下载成功率”，“游戏登录成功率”，“游戏订单成功率”之类。只是我们众多业务场景没办法直接确定业务指标，经实践，在一定程度上可借助SLO指标来替代。

SLO这一指标，是我们用于观测可用性的关键方式，然而并非数量越多便越好，其意义在于借助告警，助力我们迅速察觉影响服务SLI的异常状况，若配置过多将会引发告警过量的麻烦。上文已然提到核心业务的拆分，对于微服务架构而言，我们多数服务是以接口调用的形式对外进行提供的，如此一来，抽离出一组或者多组核心服务接口，并且针对这一批接口的SLI指标予以度量，便能够制定自身系统的SLO目标。

3.3 明确数据观测目的与意义

藉由构建指标体系，我们便可识别出系统里涵盖的形形色色的指标数据，经由对数据予以分类，我们同样能够进一步领会其于系统的价值所在。

分象限观测

四、游戏中心可观测体系实践4.1 明确核心边界

首先，我们针对游戏中心开展了核心业务的区分工作，将其区分为游戏中心首页、游戏下载以及游戏预约这三块业务，随后对这三块业务给予了最高优先级别的保障。鉴于可观测体系的构建定然要依附平台能力，且相关能力最终必定要沉淀至平台，因而在进行边界划分之际需要结合整体微服务架构设计：

公司的微服务拓扑视角

游戏中心服务架构视角

4.2 指标体系建立

（1）业务指标的观测

在游戏中心下载业务里，下载CPD指标，那可是核心的业务指标，并且它还直接跟收入数据相挂钩，能够借助检测cpd接口的状态，以此去反映业务状况。

（2）SLO指标的观测

至于首页上游客户端的调用，没办法轻易同日活、营收等数据相互关联起来，为了实现“1 - 5”的目标，在游戏中心 SLO 指标的制定方面，我们挑选了核心接口的 P95 耗时以及可用性指标，并且配置了相关监控。首页接口的 pageData/home p95 范围大概于 200 - 300ms 之间，依据 akamai 对用户体验的研究，能明显察觉到慢的程度大概是加载超过 2 秒，再加上附带算上网络传输与客户端渲染时间，我们把服务目标设定为 P95。

4.3 多维度的观测

（1）整体健康度的定时观测与发版后观测

设法快速达成整体核心SLI指标的观测，借助抽离核心观测数据来实现，这是察觉一些有着全局影响故障最为直接的办法。倘若在某段时间里，所有接口的rt都呈现出缓慢上升的态势，那就必然意味着系统出现了影响范围最大的故障。经由定时报告的配置设定，一方面防范了个人观测习惯所带来的风险，另一方面也提高了移动端的观测能力。-version发布之后开展定期报告观测，这同样是我们当前用以观测版本变更后可用性的主要方式。

（2）服务的核心依赖观测

于游戏中心这一业务范畴之内，得要从进行推荐的业务方那里，去获取核心数据，还得从dmp标签业务方那里，去拿到核心数据，也必须从提及游戏资讯的业务方那里，来取得核心数据，并且要从大数据业务方那里，获取核心数据，如此一来，那涉及这四个服务的相关接口的SLO，便需要被当作核心依赖观测项。

（3）服务的日志观测

（4）中间件的观测

在游戏中心业务范畴内，redis属于最为关键核心的中间件，其稳定性会直接对首页各个业务的健康状况产生影响。针对redis的ops以及实例cpu展开检测，再结合热key、大key的分析，可有效识别出问题与风险。

4.4 固化排障路径

利用告警入口展开下钻串联，从而搭建起一条通用问题排障路径，这条路径是从告警通知开始，接着到问题详情，再到业务看板，最后关联到拓扑。

在专家过往经验积累沉淀形成的基础之上，针对业务方面、关涉SLO等相关的告警情况，借助处理流程建议文档、用于专门存放文档的知识库、记录日志的知识库，去构建agent值班助手，以此达成共享团队知识的目标。

五、总结与展望

可观测体系的建设，压根不是那种能一劳永逸的状况，是跟着业务变化才发生变化的，同样也是跟着团队组织架构的变化而出现改变的。就监控平台而言，去构建统一可观测体系时存在的难点，一方面是受到技术自身的限制，要考虑怎样去应对大规模数据的存储问题，还有性能方面的挑战；另一方面难点在于怎样跟各种各样差异极大的业务展开沟通交流并且合作，把业务专家的经验进行融合，从中抽象出具有共性的问题。那么身为业务开发人员，要持续提高可观测理解层次，深入挖掘并沉淀业务专家的经验，如此才能够跟平台协同合作把这件事情做好了。到如今，行业AIOPS的发展呈现出日新月异的态势，我们以系统化的方式构建可观测体系，该体系也是融入到这一浪潮之中，在达成工具自动化的目标以后，我们同样期望朝着智能化的建设向前迈出一大步，至此。

相关标签： # 可观测体系 # 业务视角 # 指标体系 # 链路观测 # 故障处理