从业务开发视角聊聊可观测体系建设
<blockquote data-first-child="" data-pid="Ydq6N3W9">作者：vivo 互联网服务器团队- Lei Zezheng<br>本文探讨了分布式架构下可观测体系的建设实践，提出了基于业务视角的可观测体系建设框架：明确业务核心边界、建立指标体系（业务指标+SLO指标）、构建多维度观测（业务观测、链路观测、异常观测、变更观测）和固化排障路径，以游戏中心项目为例，介绍了项目在问题发现与问题定位上的实践，有效提升了问题发现与故障处理的效率。</blockquote><p data-pid="U95utP7f">1分钟看图掌握核心观点👇</p>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal">
<div class="GifPlayer css-1isopsn" data-size="normal" data-za-detail-view-path-module="GifItem"><img alt="动图封面" class="ztext-gif lazyload" width="864" data-thumbnail="https://pic3.zhimg.com/v2-2bc1df1e6d57fe56b60333c207732b52_b.jpg" data-size="normal" data-src="https://pic3.zhimg.com/v2-2bc1df1e6d57fe56b60333c207732b52_b.jpg">
<div class="GifPlayer-icon css-d39tw7"> </div>
</div>
</div>
</figure>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal">
<div class="GifPlayer css-1isopsn" data-size="normal" data-za-detail-view-path-module="GifItem"><img alt="动图封面" class="ztext-gif lazyload" width="864" data-thumbnail="https://pic3.zhimg.com/v2-e4d7c911780d1ee9250cf238db4ad3c0_b.jpg" data-size="normal" data-src="https://pic3.zhimg.com/v2-e4d7c911780d1ee9250cf238db4ad3c0_b.jpg">
<div class="GifPlayer-icon css-d39tw7"> </div>
</div>
</div>
</figure>
<p data-pid="003NiTFP"><em>图 1 VS 图 2，您更倾向于哪张图来辅助理解全文呢？欢迎在评论区留言</em></p>
<h2>一、背景介绍与痛点分析</h2>
<p data-pid="NGgxSOLO">当分布式架构渐成主流，可观测性（Observability）在行业内也越来越受到重视。可观测性是指系统可以由其外部输出，来推断其内部状态，系统的可观测性越强，我们对系统的可控制性就越强。现如今如何提升整体系统的可观测性，应用可观测工具达成业务保障可用性目标，成为了每个SRE与业务开发都必须思考的课题。但是随着业务复杂度与”1-5-10"(1分钟内发现问题，5分钟内定位问题原因，10分钟内恢复故障)可用性保障目标等的日益提升，我们也发现了可观测体系在我们业务落地上的一些问题。</p>
<ul>
<li data-pid="k5XLXAPY"><strong>观测视角的差异。</strong>可观测工具建设与落地方向大多处于运维视角，而非业务视角。</li>
<li data-pid="K-6k99xk"><strong>业务的差异。</strong>不同的业务、业务发展的不同阶段，对于观测的建设重点差异很大。</li>
</ul>
<p data-pid="aetoofBL">这些差异，为平台侧提供观测工具与业务开发使用工具之间带来了不少痛点。游戏中心作为toC的分发类业务的一个典型项目，可观测体系的建设过程可圈可点，现总结其中一些经验，希望对于其他业务项目有所帮助。</p>
<h2>二、可观测体系的数据基座</h2>
<p data-pid="1rs-fbR8">对于可观测，大家或多或少都听过可观测性的”三大支柱“：指标、日志和链路，2017 年Peter Bourgon 撰写的文章《Metrics, Tracing, and Logging》 系统地阐述了这三者的定义：</p>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="400" width="613" data-caption="" data-size="normal" data-rawwidth="613" data-rawheight="400" data-original-token="v2-22fcf77e36695610f9bd95edfd609765" data-original="https://pic4.zhimg.com/v2-22fcf77e36695610f9bd95edfd609765_r.jpg" data-actualsrc="https://pic4.zhimg.com/v2-22fcf77e36695610f9bd95edfd609765_1440w.jpg" data-lazy-status="ok" data-src="https://pic4.zhimg.com/80/v2-22fcf77e36695610f9bd95edfd609765_720w.webp"></div>
</figure>
<p data-pid="O2k1argI">那么我们监控团队已经基本很完备的采集好了这些数据，并且呈现了诸如日志中心，应用监控，调用链指标监控等工具，是否就代表了能保证我们系统的可观测性？答案当然是否定的，有了西红柿、鸡蛋、盐，并不能代表我们就已经能吃到西红柿炒鸡蛋了，三大指标都有着自己的明显特征与使用场景：</p>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="550" width="1080" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="550" data-original-token="v2-2f9602d5712d83608f9a4a4d5c0652f4" data-original="https://pic3.zhimg.com/v2-2f9602d5712d83608f9a4a4d5c0652f4_r.jpg" data-actualsrc="https://pic3.zhimg.com/v2-2f9602d5712d83608f9a4a4d5c0652f4_1440w.jpg" data-lazy-status="ok" data-src="https://pic3.zhimg.com/80/v2-2f9602d5712d83608f9a4a4d5c0652f4_720w.webp"></div>
</figure>
<p data-pid="mlGghZO_">独立的使用各种指标，永远只适用于部分场景，虽不能说完全无效，但想系统化达成目标一定会比较吃力，且无条理。面对较为简单的问题，比如日志突然打印了空指针异常、数组越界的错误，我们看下日志中心就很快能定位到具体代码行上，进而分析上层参数的情况，并去迅速排除故障。但是当问题复杂度略微提升，比如：</p>
<ul>
<li data-pid="fzXpjYCE">我们依赖的服务耗时缓慢上升，直至导致我们服务的可用性下降；</li>
<li data-pid="-SNYaKND">服务调用者缺陷导致对我们某个服务的调用流量异常上涨，进而影响redis、mysql等基础组件，最终导致同样依赖该组件的核心服务受损。</li>
</ul>
<p data-pid="PSY9vF2A">出现这类问题时，日志中心、应用指标，超时链路都会有异常反应。除此以外，绝大多数系统问题其实都是由于变更导致或触发的，所以除了以上三个核心数据外，还需要结合一些变更系统事件来做辅助根因定位。我们无法24小时时刻关注各项指标，必须通过配置检测与告警来主动通知。</p>
<p data-pid="CBcIcY_w"><strong>日志、指标、链路、变更事件以及告警</strong>，共同构成了我们可观测的数据基座。</p>
<h2>三、业务视角的可观测体系建设框架</h2>
<h2>3.1 业务核心分治</h2>
<p data-pid="Jdvjcr6d">对于大多数系统来说，我们建设可观测体系都是为了及时发现系统中出现的各类故障，但是作为业务开发，实践中我们会发现在这个标准下：都是故障，亦有差距。“游戏中心首页白屏”、“登录失败”、“下载失败” 这类问题出现即是致命伤，等故障爆发后再发现是不可接受的。但是对于“游戏评论刷新延迟”，“我的页成就刷新延迟”之类的故障，在资源有限时，可能慢一点处理也无妨。</p>
<p data-pid="UMtjkN7R">所以基于分治的思路，首先要做的就是“明确业务核心边界”。如果拆解出的核心业务依然很复杂，那么应当持续视角向内，将业务拆解至最小的核心单元后，再分部进行观测。</p>
<h2>3.2 指标体系的建立</h2>
<p data-pid="uUqdPcxq">对于业务系统，首要的观测指标当然是业务指标，能够直接反应业务的健康度，比如：“游戏下载成功率”，“游戏登录成功率”，“游戏订单成功率”等。不过我们很多业务场景无法直接拟定业务指标，经过实践，一定程度上可以通过SLO指标进行替代。</p>
<p data-pid="UBMCutEO">SLO指标是我们观测可用性的重要手段，但不是越多越好，SLO的意义在于通过告警帮助我们快速发现影响服务SLI的异常，配置过多会带来告警过多的困扰。上文已经提及到核心业务的拆分，对于微服务架构我们大部分服务是以接口调用的形式去对外提供的，那么抽离出一组或多组的核心服务接口，并对于这一批接口的SLI指标进行度量，就可以制定自己系统的SLO目标。</p>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="476" width="703" data-caption="" data-size="normal" data-rawwidth="703" data-rawheight="476" data-original-token="v2-408249decc1415551680966307fc473f" data-original="https://picx.zhimg.com/v2-408249decc1415551680966307fc473f_r.jpg" data-actualsrc="https://picx.zhimg.com/v2-408249decc1415551680966307fc473f_1440w.jpg" data-lazy-status="ok" data-src="https://picx.zhimg.com/80/v2-408249decc1415551680966307fc473f_720w.webp"></div>
</figure>
<h2>3.3 明确数据观测目的与意义</h2>
<p data-pid="G0kqkDpE">通过建立指标体系，我们就能够识别出系统中包含各式各样的指标数据，通过对数据进行分类，我们也能够进一步理解其对于系统的价值所在。</p>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="584" width="1080" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="584" data-original-token="v2-8cd8eb5759ca6444e7df7ccb01e2188c" data-original="https://pica.zhimg.com/v2-8cd8eb5759ca6444e7df7ccb01e2188c_r.jpg" data-actualsrc="https://pica.zhimg.com/v2-8cd8eb5759ca6444e7df7ccb01e2188c_1440w.jpg" data-lazy-status="ok" data-src="https://pica.zhimg.com/80/v2-8cd8eb5759ca6444e7df7ccb01e2188c_720w.webp"></div>
</figure>
<p data-pid="jXZyreut">分象限观测</p>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="640" width="1080" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="640" data-original-token="v2-feacefc943907b32e93fd170f8ca9b52" data-original="https://pica.zhimg.com/v2-feacefc943907b32e93fd170f8ca9b52_r.jpg" data-actualsrc="https://pica.zhimg.com/v2-feacefc943907b32e93fd170f8ca9b52_1440w.jpg" data-lazy-status="ok" data-src="https://pica.zhimg.com/80/v2-feacefc943907b32e93fd170f8ca9b52_720w.webp"></div>
</figure>
<h2>四、游戏中心可观测体系实践</h2>
<h2>4.1 明确核心边界</h2>
<p data-pid="Vkw7AKV3">首先我们对游戏中心进行了核心业务的划分：游戏中心首页、游戏下载、游戏预约，对这三块业务进行最高优先级的保障。由于可观测体系的搭建必须依赖平台能力，相关能力最终也必须沉淀回平台，所以在边界划分上需要结合整体微服务架构设计：</p>
<p data-pid="jVvoA1PF">公司的微服务拓扑视角</p>
<ul>
<li data-pid="wblXaYOr">上游节点调用，重要调用方</li>
<li data-pid="MOutXxjN">下游节点调用，核心依赖方</li>
</ul>
<p data-pid="YSshA9zY">游戏中心服务架构视角</p>
<ul>
<li data-pid="P16HLaRu">客户端</li>
<li data-pid="lGUB2xVN">网络环境</li>
<li data-pid="5eDPG8bl">容器环境</li>
<li data-pid="QPHQWoXO">代码</li>
<li data-pid="n7M1gz6E">中间件、核心依赖组件</li>
<li data-pid="R7L8lUSN">运营后台</li>
</ul>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="1151" width="1080" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="1151" data-original-token="v2-80645712b3a6e84201d014e485354b30" data-original="https://pic3.zhimg.com/v2-80645712b3a6e84201d014e485354b30_r.jpg" data-actualsrc="https://pic3.zhimg.com/v2-80645712b3a6e84201d014e485354b30_1440w.jpg" data-lazy-status="ok" data-src="https://pic3.zhimg.com/80/v2-80645712b3a6e84201d014e485354b30_720w.webp"></div>
</figure>
<h2>4.2 指标体系建立</h2>
<p data-pid="7mWPhpLs"><strong>（1）业务指标的观测</strong></p>
<p data-pid="oas31ZE_">对于游戏中心下载业务，下载CPD指标是很核心的业务指标，且直接与收入数据挂钩，可以通过检测cpd接口的状态来反映业务情况。</p>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="207" width="1080" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="207" data-original-token="v2-f92bd3deae1429328084d44500e452bb" data-original="https://pic4.zhimg.com/v2-f92bd3deae1429328084d44500e452bb_r.jpg" data-actualsrc="https://pic4.zhimg.com/v2-f92bd3deae1429328084d44500e452bb_1440w.jpg" data-lazy-status="ok" data-src="https://pic4.zhimg.com/80/v2-f92bd3deae1429328084d44500e452bb_720w.webp"></div>
</figure>
<p data-pid="z-ypFz2_"><strong>（2）SLO指标的观测</strong></p>
<p data-pid="xomCRg2h">对于首页上游客户端调用，无法简单与日活、营收等数据相关联，为了达成“1-5”的目标，对于游戏中心的SLO指标的制定我们选取了核心接口的P95耗时与可用性指标，并配置相关监控。首页接口的pageData/home p95范围大概在200-300ms，根据akamai研究用户体验能明显感知到慢的程度大概是加载2秒以上，附带算上网络传输与客户端渲染时间，我们的服务目标定为P95<800ms，在可用性上全年项目SLA可用性级别为4个9，在接口服务上也保持一致。</p>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="390" width="787" data-caption="" data-size="normal" data-rawwidth="787" data-rawheight="390" data-original-token="v2-13599ff24beaf85ed6c464ea8fe4e17e" data-original="https://pica.zhimg.com/v2-13599ff24beaf85ed6c464ea8fe4e17e_r.jpg" data-actualsrc="https://pica.zhimg.com/v2-13599ff24beaf85ed6c464ea8fe4e17e_1440w.jpg" data-lazy-status="ok" data-src="https://pica.zhimg.com/80/v2-13599ff24beaf85ed6c464ea8fe4e17e_720w.webp"></div>
</figure>
<h2>4.3 多维度的观测</h2>
<p data-pid="prVsyGFx"><strong>（1）整体健康度的定时观测与发版后观测</strong></p>
<p data-pid="g47vjw-3">抽离核心观测数据来快速实现整体核心SLI指标的观测，是发现一些全局影响故障最直接的手段。如果一段时间所有接口的rt都缓慢上涨，那么一定代表着系统出现了影响面最大的故障。通过定时报告的配置，既防范了个人的观测习惯风险，也提升了移动端的观测能力。版本发布后的定期报告观测，也是我们当前观测版本变更后可用性的主要手段。</p>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="923" width="1080" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="923" data-original-token="v2-4c2011d28bd12ad0ebd86d23488256d0" data-original="https://pic3.zhimg.com/v2-4c2011d28bd12ad0ebd86d23488256d0_r.jpg" data-actualsrc="https://pic3.zhimg.com/v2-4c2011d28bd12ad0ebd86d23488256d0_1440w.jpg" data-lazy-status="ok" data-src="https://pic3.zhimg.com/80/v2-4c2011d28bd12ad0ebd86d23488256d0_720w.webp"></div>
</figure>
<p data-pid="PEzLmbCq"><strong>（2）服务的核心依赖观测</strong></p>
<p data-pid="GJpf1Mzg">在游戏中心业务中，需要从推荐、dmp标签、游戏资讯、大数据四个业务方获取核心数据，那么这四个服务相关接口的SLO就需要作为核心依赖观测项。</p>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="386" width="708" data-caption="" data-size="normal" data-rawwidth="708" data-rawheight="386" data-original-token="v2-afbce0a033d63d503613abfbb058739c" data-original="https://pic1.zhimg.com/v2-afbce0a033d63d503613abfbb058739c_r.jpg" data-actualsrc="https://pic1.zhimg.com/v2-afbce0a033d63d503613abfbb058739c_1440w.jpg" data-lazy-status="ok" data-src="https://pic1.zhimg.com/80/v2-afbce0a033d63d503613abfbb058739c_720w.webp"></div>
</figure>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="639" width="1080" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="639" data-original-token="v2-851be86d10339d64352916ae2fc0eb77" data-original="https://pic4.zhimg.com/v2-851be86d10339d64352916ae2fc0eb77_r.jpg" data-actualsrc="https://pic4.zhimg.com/v2-851be86d10339d64352916ae2fc0eb77_1440w.jpg" data-lazy-status="ok" data-src="https://pic4.zhimg.com/80/v2-851be86d10339d64352916ae2fc0eb77_720w.webp"></div>
</figure>
<p data-pid="YgkFtKwU"><strong>（3）服务的日志观测</strong></p>
<ul>
<li data-pid="kN5jcRLg">通过错误日志治理，降低error数量，来有效呈现异常error数据。</li>
<li data-pid="9XUq1OUU">除了进行阈值数量监控外，对ERROR日志聚合1分钟级别的趋势分析，聚合topN，有效识别异常error的变化。</li>
</ul>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="487" width="1080" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="487" data-original-token="v2-fca974b2f7ee929eeecd9f9a1a1dc06f" data-original="https://pic2.zhimg.com/v2-fca974b2f7ee929eeecd9f9a1a1dc06f_r.jpg" data-actualsrc="https://pic2.zhimg.com/v2-fca974b2f7ee929eeecd9f9a1a1dc06f_1440w.jpg" data-lazy-status="ok" data-src="https://pic2.zhimg.com/80/v2-fca974b2f7ee929eeecd9f9a1a1dc06f_720w.webp"></div>
</figure>
<p data-pid="SE27B11M"><strong>（4）中间件的观测</strong></p>
<p data-pid="YARTJba7">对于游戏中心业务，redis是最为核心的中间件，redis的稳定直接影响首页各个业务的健康度。对于redis的ops、实例cpu都进行检测，结合热key、大key分析，能够有效识别问题和风险。</p>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="460" width="1080" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="460" data-original-token="v2-02050bc3300847aca21f7088519fdc52" data-original="https://pic3.zhimg.com/v2-02050bc3300847aca21f7088519fdc52_r.jpg" data-actualsrc="https://pic3.zhimg.com/v2-02050bc3300847aca21f7088519fdc52_1440w.jpg" data-lazy-status="ok" data-src="https://pic3.zhimg.com/80/v2-02050bc3300847aca21f7088519fdc52_720w.webp"></div>
</figure>
<h2>4.4 固化排障路径</h2>
<p data-pid="syZqEa0W">通过告警入口的下钻串联，搭建了 “<strong>告警通知→问题详情→业务看板→关联拓扑</strong>” 的通用问题排障路径。</p>
<p data-pid="TfoGx4GQ">在专家经验的沉淀上，对于业务、SLO等相关告警，通过处理流程建议文档、文档知识库、日志知识库，构建agent值班助手来共享团队知识。</p>
<figure data-size="normal">
<div class="RichText-ConditionalImagePortal"><img class="origin_image zh-lightbox-thumb lazy lazyload" height="806" width="573" data-caption="" data-size="normal" data-rawwidth="573" data-rawheight="806" data-original-token="v2-91110e397d03ec0254f465593e7eef78" data-original="https://pica.zhimg.com/v2-91110e397d03ec0254f465593e7eef78_r.jpg" data-actualsrc="https://pica.zhimg.com/v2-91110e397d03ec0254f465593e7eef78_1440w.jpg" data-lazy-status="ok" data-src="https://pica.zhimg.com/80/v2-91110e397d03ec0254f465593e7eef78_720w.webp"></div>
</figure>
<h2>五、总结与展望</h2>
<ul>
<li data-pid="M3sXzR1Q">在问题<strong>发现</strong>上：对于游戏中心的三大核心业务场景明确了业务边界之后，用户侧接口访问变慢、出错的风险告警可以在3分钟内完成告警推送；通过与监控团队合作提升自定义监控数据采集，对于游戏预约首发、游戏礼券发放等业务，可以做到1分钟的问题告警推送。</li>
<li data-pid="I-tRvK_b">在问题<strong>定位</strong>上：通过关联到下游依赖、服务基础指标与专家经验，游戏核心业务的组件、服务异常等问题，基本可以5分钟内做到识别风险和问题边界或原因。</li>
</ul>
<p data-pid="dfNYdNuU">可观测体系建设并非一劳永逸的事情，随着业务变化而变化，也随着团队组织架构变化而变化。对于监控平台，构建统一可观测体系的难点，一方面在于技术本身的制约，如何应对大规模数据的存储、性能挑战；另一方面则在于如何与千差万别的业务进行沟通、合作，融合业务专家经验，抽象出共性的问题。那么作为业务开发，持续提升可观测理解水平，深入挖掘沉淀业务专家经验，才能协同好平台一起做好这件事。现如今，行业AIOPS的发展日新月异，我们系统化的构建可观测体系也是融入该浪潮中，在实现的工具自动化的目标之后，我们也希望朝着智能化的建设迈出一步。</p>
</div>
<div id="MySignature" role="contentinfo">
分享 vivo 互联网技术干货与沙龙活动，推荐最新行业动态与热门会议。<br><br>
来源：https://www.cnblogs.com/vivotech/p/19707241
頁:
[1]