前言
Crash（形成用户无法运用客户端所承载的服务）作为客户端安稳办理的最首要问题之一。云信作为国内业界领先的 RTC/IM PaaS 服务商，关于客户端 SDK（PaaS 服务商对外服务的首要载体）的 Crash 办理再注重也不为过。关于客户端 Crash 安稳性办理，尽管业界已有多个成熟的监控渠道，完结了从埋点、上报、展现到报警一站式服务，如 Bugly 渠道、Fabric 渠道等，也有 Crash 捕捉的东西 SDK，便利在此基础上按需定制监控渠道，如 KSCrash、Breakpad 等。但关于云信这样的 RTC&IM PaaS 服务商来讲，无论是市面上现有 APP Crash 办理渠道，仍是 Crash 捕捉东西 SDK 都是无法处理针对 PaaS 服务商 Crash 反常办理痛点。
- 渠道类型支撑有限
业界渠道往往只掩盖干流的两个移动端渠道 iOS/Android、关于 Mac OS/PC/Linux/Flutter 不支撑。
- APP 与 SDK 监控数据无法有效阻隔
业界对外服务的 Crash 收集渠道基本都是规划服务于 APP，后台剖析与展现无法一起对 APP 和 SDK 进行区分。
- 问题办理完结不了闭环处理
以业界著名 Bugly 为例，只供给了对外闭源 SDK，Bugly 后端目前也没有敞开第三方接口，溃散信息都要人工去主动搜索处理，无法与 PaaS 服务商内部 Bug 办理体系进行联动，反常感知也无法主动感知与推送，形成不了 Crash 问题从捕获到研制人员呼应处理高效的闭环。
Crash 反常办理建设
为了处理以上 PaaS 服务商安稳性问题办理的痛点，构建一套从反常问题捕捉到研制人员高效问题处理的监控剖析体系就显得分外迫在眉睫了，云信研制团队从以下三个维度考虑：
- 怎么完结数字体会监控： 收集的指标有哪些，以及这些指标的影响是什么？
- 反常发现、盯梢及确诊： 反常指标怎么转化为具体可处理的方案，怎么快速找到问题模块？
- 面向技术人员的主动化运维： 怎么完结问题剖析的精准性，怎么下降研制剖析耗时与本钱？
经过大半年多的努力，终于落地了 Crash 安稳性办理渠道（以下简称 Marvel）渠道，完结了 Crash 问题的高效办理。该渠道基于 PaaS 服务商的特色，规划了三级的账号体系，渠道掩盖了 Android、iOS、Windows、MAC、Linux、Web 渠道、Flutter 框架, 终究完结从问题捕获、剖析处理问题、修复、复盘全链路的闭环，下文将针对该渠道做较为详细的介绍。
渠道架构规划
Marvel 渠道架构规划图
如上图所示, 从数据流视点可知，当 CI 构建服务完结产品各个客户端渠道 SDK 包的时候，体系会主动将 SDK 包对应渠道的符号表文件上传到 NOS（网易对象存储）文件服务，一起将 SDK 版别号、各个 SO 库的 build_id/uuid、Github 库房地址等元信息记录到渠道数据库中，为后续反常解析服务查找奔溃库所属的符号表文件做准备。当 C 端发生 Crash 问题的时候，体系首先会将 Crash 信息（栈信息、用户操作轨道、uuid/build_id 等信息）上传到 Marvel 后台服务，体系经过数据清洗以及反常解析之后，精准地剖析出该 Crash 属于哪个模块，渠道支撑依据模块归属人查询表或许依据 git commit 记录查找出最后代码改变人, 终究主动生成 Jira 工单，然后经过公司内部协作东西（POPO）同步反常待处理音讯给对应的研制同学。然后终究完结了线上反常处理的主动化闭环操作。
渠道全景视图
云信当时 Marvel 渠道除了要点落地完结了 Crash 安稳性问题办理之外，相同也完结了部分渠道其它安稳性问题的办理，如卡顿、内存泄漏、内存溢出、ANR、Watchdog 等客户端的安稳性问题，安稳性问题发生的上下文信息（用户的行为轨道、运用的上下文等信息数据），经过 ES 搜索引擎和 HBASE 数据库完结海量数据的存储以及快速数据聚合查询，终究可以快速完结场景复原，完结问题的重现，终究完结快速剖析定位问题。
账号体系规划
传统的反常捕获体系是基于 APP 维度来核算 Crash 等反常信息的，而作为 PaaS 服务商，期望看到的是从 PaaS 服务产品及对应的 SDK 维度来核算 Crash 信息，因而云信规划了三级的账号体系，以支撑每个层级来做聚合核算监控。
三级账号体系阐明如下：
- 公司级别。 如易盾、云信等 PaaS 服务厂商。
- 公司产品SKU。 如云信有 IM SDK、RTC SDK、播放器 SDK。
- SKU 下的子产品。 如 RTC SDK 下有美颜、布景替换、水印等插件化的子产品。
办理涵盖研制全周期
安稳性问题办理需求贯穿整个软件研制的完整生命周期，包含需求研制、测试、集成、灰度、上线等，上述每个阶段，研制同学都应该分外注重安稳性问题的发现和办理。所以针对各个阶段的数据收集也就分外的重要，当时云信的安稳性问题办理渠道现已完结了线下场景的全掩盖，以及线上场景的部分掩盖。当时上传到渠道的数据首要分为 Monitor、Logging、Tracing 三类。Trace 数据首要指的是代码调用栈数据；Log 首要是用户行为轨道数据、客户端体系日志等；Monitor 数据首要是与人们反常模型相匹配的反常数据。
端侧功用集
端侧 Marvel SDK 功用模块
端侧 SDK 层面功用以小的颗粒度接入。在规划开发上完结收集功用的模块化，各个运用可以依据自身需求选择性引证功用模块，然后保证安稳性监控 SDK 关于运用的包体积及功用到达最小影响。除了供给原子的监控收集能力外，为了完结监控 SDK 的容错与容灾能力，Marvel 渠道除了会对线上运用实时收集功用开关控制之外，监控 SDK 当遇到自身运转反常的时候也会主动进行功用封闭，关于问题可以做到主动阻隔。
仓库解析服务
在每个反常上报中，除了基础元信息外，还包含反常类型、反常音讯、反常仓库等运转时内容，特别是仓库信息，可以有效地协助研制去识别反常点。那么我们就可以依据仓库和反常类型来做聚合。
简略来说，可以依照仓库信息做 Hash 比对往来不断重，虽然该方案可以大幅减少重复反常，但仍是会存在很多同类问题归结为不同类别的情况，例如在递归情况下的反常，递归深度不同就会导致 hash 成果不一致。考虑 ROI 比当时我们只截取非体系的用户函数仓库，后期考虑引入些更高档的算法， 对相似的仓库可以更加精准的归因（如对仓库距离、TF-IDF 等手段对仓库的内容进行解析，然后利用相应的公式来核算两个仓库之间的相似性）。
从可观察性的指标来看仓库信息对应便是 Tracing 数据，仓库复原服务是决定后续是否能对问题进行精准剖析归因的要害。经过复原后仓库信息 Marvel 可以快速定位到代码行。然而线上运转时的程序为了安全和安装包体巨细等要素，会对代码进行混淆或许压缩，所以获取到的仓库文本是混淆压缩后的仓库信息。为了使开发人员直观快速地了解仓库意义，这就需求运用相关的符号文件来对混淆或许压缩的代码信息做复原处理。
早期 Marvel 符号化解析首要依靠原生渠道东西，但存在以下问题：
- 低功用
由于各个端供给的是命令行东西，所以需求在服务内部经过命令行调用，这种启动子进程的方式会带来很多的进程创立和毁掉的功用损耗。此外，由于需求启动命令行子进程处理，处理跨进程通信也会带来较大的功用开支；经过命令行每次调用都要重复读取解析符号文件，带来了额外的功用开支。
- 难保护
由于命令行是经过子进程处理，无法办理命令行子进程的状况，对命令行的反常的定位处理带来了复杂性；不同端的东西会依靠不同言语和运转环境，例如 iOS 的 atos 需求运转在 MacOS 环境下，这个对服务的一致部署非常不友好。
为了处理以上问题，当时 Marvel 选用 Rust 完结了各个端侧的符号解析，保证各个符号信息只做一次解析，并转为 KV 结构方式缓存处理。一致言语后也能下降程序运维复杂性，并服务 docker 容器化的需求。
当时仓库复原相关的首要有两个服务：
- 符号表办理服务
担任符号表的上传、下载、解析、缓存等流程的办理。符号表上传之后，该模块会实时解析文件，并将其解析为 KV 的方式写入 Redis 缓存之中。一起，还会担任符号表文件存储和缓存的办理。
- 仓库复原服务
担任仓库复原，以 gRPC 的方式供给复原服务。当接收到复原请求时，会在 Redis 中查找相关的符号信息，并将这些信息拼接为完整的仓库，回来给请求发送端。
反常问题主动化分发
上一章节介绍了 Marvel 渠道体系的整体架构规划、账号体系规划、端侧功用集、仓库解析服务等要点模块完结，本章节将要点解说渠道关于 Crash 反常问题的高效分发处理。
一个高效安稳性办理渠道,主动精准分发反常的能力是必不可少的, 帮助 PaaS 服务方快速收到报警、快速呼运用户遇到的问题。关于体系是怎么依据仓库信息来追寻与查询 Crash 处理研制人员了，上节第一 末节已详细阐明，这里就不再重复了。
问题分发云信当时首要采纳以下两个策略:
- 包含事务仓库的反常, 经过构建集成渠道的组件保护人员信息,直接指派到开发担任人。
- 关于没有事务栈帧的反常, 依据渠道上项目创立人进行指派。
下文以 iOS 安稳性办理为例展现渠道体系完结。
1. 聚类展现
2. 反常链接推送
3. 工单创立通知
4. 渠道反常与 Jira 相关
5. 反常项与 CI 产物符号表相关
6. 反常仓库复原展现
总结与展望
以上便是云信研制团队关于客户端 Crash 安稳性问题办理与总结，文章针对 Marvel 渠道的架构规划、账号体系规划、办理周期、端侧功用、仓库解析服务等进行了详细论述。该渠道的落地使得云信的研制效能得到了大大提高。在 Marvel 渠道上线前， Crash 等安稳性问题反常处理如下图所示，全流程人工作业，排查问题需求前后反复交流，而且数据源彻底依靠终端用户配合导出溃散数据，呼应链路长而且往往存在短少数据源而无法定位的问题，产研侧也无法主动感知线下/线上的安稳性问题。
旧流程：
新流程：
后续云信研制团队将继续从以下几方面进一步建设与完善 Marvel 渠道。
完善端侧疑难杂症的问题办理
- 掩盖与完善更多端侧的安稳性问题办理；
- 如 Android oom 办理 ， 完善内存办理手段与剖析 ，下一步完善问题断定规矩。
一站式服务
端侧的问题并非孤立存在，它可能会受到后端的服务质量影响，双端的数据联通与相关可以为事务构建起完整的运用质量地图。后续 Marvel 将与更多内部渠道联动如后台监控、后台日志团队在数据服务上做联动，为运用服务供给一站式监控、定位、容灾服务能力。
智能归因剖析
本着数据驱动的理念，以及高效挖掘并利用已有数据的思路。Marvel 后续将经过结合研制期间的数据，经过发布信息、代码改变信息、测试案例等，构建研制流程画像，一起结合线上观测数据与问题详情构建的线上质量画像，完结快速聚合剖析归因，做到研制内问题提前预警，以及线上问题的在代码和责任人层面的根因剖析，下降研制排查问题的时间耗费以及人员交流本钱，助力效能提高。
