作者：伝逸

淘宝作为一个航母级的利用，每天都有数亿的用户在应用。保障客户端的稳定性是咱们的首要指标。为此，咱们也提出了 5 -15-60 的指标。即问题告警时，5 分钟响应，15 分钟定位，60 分钟复原。然而现有的排查体系并不能很好的达到这个指标，剖析下来次要起因是：

监控阶段

• 通过 Crash 堆栈、异样信息进行聚合统计，不够精密精确，不够灵活；
• 监控到异样后，端侧行为比拟繁多，只上报异样信息，无奈提供更多有用数据；
• 手淘大部分问题都和线上变更无关，然而短少对变更品质的监控。

排查阶段

• 监控上报的异样信息有余，依赖日志进行问题排查；
• Crash 或异样时不会被动上传日志，须要手动捞取，用户不在线获取不到日志；
• 获取日志之后：

1. 短少分类，不足规范，日志芜杂，看不懂其余模块的日志；
2. 短少场景信息，无奈残缺的重现异样时用户的操作场景；
3. 短少整个生命周期相干的事件信息，无奈把握 app 的运行状况；
4. 各个模块上下游的日志信息无奈无效关联造成残缺链路；
5. 现有日志可视化工具性能较弱，无奈进步排查效率；

• 问题排查靠人工剖析，效率低下，雷同问题短少积淀；
• 各个系统间的数据短少关联，须要到多个平台获取数据。

诊断体系降级思路

针对以上现有问题，咱们从新设计了整个无线运维排查诊断体系的架构。在新的架构中，咱们引入了场景的概念。以往端上产生的异样都是一个个独立的事件，没有方法针对不同的异样做更精密的解决和数据收集。而引入场景概念后，一个场景可能是一个异样和多种条件的组合，针对不同的场景能够做配置，使得异样信息的收集更加丰盛，更加精准。

同时咱们从新定义了端侧异样数据，次要包含规范的 Log 日志数据、记录调用链路的 Trace 全链路数据、运行时相干的 Metric 指标数据以及产生异样时的现场快照数据。平台侧能够利用异样数据进行监控和告警。也能够对这些数据进行可视化的解析，针对业务的差别，平台提供了插件化的能力来解析数据。利用这些语义化后的信息，平台能够进行初步的问题诊断。

所以接下来要实现的指标是：

• 实现端侧场景化的监控运维；
• 降级日志体系，实现 LOG、TRACE、METRIC 数据整合，提供更加丰盛和精准的排查信息；
• 实现高可用体系数据整合，提供面向问题排查的标准化接⼝和平台；
• 插件化撑持平台赋能，业务自定义诊断插件，实现诊断体系平台间对接；
• 平台根据诊断信息，给出诊断后果，能做到自动化、智能化；
• 根据诊断后果给出解决方案或提出整改需要，造成从需要 -> 研发 -> 公布 -> 监控 -> 排查 -> 诊断 -> 修复 -> 需要的闭环。

日志体系降级

目前剖析运行日志还是端侧排查问题的次要伎俩，后面也提到咱们的日志自身存在一些问题。所以咱们第一步是对日志体系进行了降级。（在此之前咱们欠缺了日志本身的根底能力，比方晋升写入性能、晋升日志压缩率、晋升上传成功率、建设日志的数据大盘等等）

为了进步日志的排查效率，咱们从日志内容着手，重新制定了端侧的规范日志协定。标准化的日志协定能够为咱们在平台侧进行日志可视化建设、自动化日志剖析提供帮忙。咱们从 Log、Trace、Metric 角度登程，按照手淘的理论状况将现有的日志分为以下几类：

• CodeLog: 兼容原有的日志，这些日志绝对芜杂；
• PageLog：记录端上页面跳转状况，排查问题时能够从页面维度对日志进行划分；
• EventLog：记录端侧各种事件，比方前后台切换、网络状态、配置变更、异样、点击事件等等；
• MetricLog: 记录端侧运行时的各种指标数据，比方内存、CPU、业务的各种指标数据；
• SpanLog: 全链路日志数据。把各个独立的点串联起来，定义对立的性能度量、异样检测的规范。基于 OpenTrace 的计划和服务端买通，造成端到端的全链路排查机制。

[]()

有了这些数据之后。在平台侧配合日志可视化平台，能够对端侧的行为进行疾速回放。得益于日志的标准化，能够从平台侧对日志进行剖析，疾速展现存在异样的节点。

端侧诊断降级

客户端是整个诊断体系的源头，所有的异样数据，运行信息都是由客户端上的各种工具进行收集上报的。目前端侧次要工具有：

• APM：收集端侧的各种运行、性能等信息，数据上报到服务端；
• TLOG：收集端侧运行时的日志信息，日志文件寄存在本地，须要时服务端下发指令进行捞取；
• UT：端侧埋点工具，很多业务异样信息都会通过 UT 进行上报告警；
• 异样监控：这个以 Crash SDK 为代表，次要收集端侧的 Crash 信息，还有收集异样、用户舆情等相干的 SDK；
• 排查工具：内存检测、卡顿检测、白屏查看等工具。这些没有间接归类在 APM 中，因为这些工具是采样运行，有的甚至默认是敞开状态。

能够看到端侧其实曾经有不少成熟的工具在应用，然而在排查问题时候常常发现数据缺失等问题，次要起因在于一方面在平台侧这些数据比拟扩散，没有一个对立的接口进行查问；另一方面客户端没有对这些工具的数据做整合，产生异样时这些工具间少有交互，造成了数据缺失。

为了解决这些问题，咱们在端侧引入了全新的诊断 SDK 和染色 SDK。它们的次要性能有：

• 对接现有工具，收集端侧运行数据。把这些数据依照规范的日志协定写入到 TLOG 日志中；
• 监听端侧的变更信息，生成变更的染色标识；
• 监听端侧异样，异样产生时生成快照信息（包含运行信息、变更信息），上报服务端；
• 场景化诊断数据上报，依据服务端配置的规定，在特定场景进行数据收集和上报；
• 反对定向诊断，依据服务端下发的配置，调用对应的排查工具进行数据收集；
• 反对实时日志上传，针对特定用户和设施进行在线调试。

异样快照

端侧的异样次要包含 Crash、业务异样、舆情等。当异样产生时，上报的数据格式、内容、通道、平台都不一样。若想要减少一些数据，端侧和相应平台都须要进行革新。所以咱们对端侧异样监控相干的 SDK 进行了监听，对于业务提供了异样告诉接口。当诊断 SDK 接管到异样时，会利用以后收集到的运行信息生成一份快照数据。每个快照数据会有一个惟一的 snapshotID。咱们只须要把这个 ID 传递给对应的 SDK，这样对现有的 SDK 改变是最小的。

[]()

快照数据随着端侧能力的增强也会越来越丰盛。收集到的快照信息会上传到诊断平台，平台之间能够利用 snapshotID 进行数据关联。对于诊断平台来说，能够依据快照信息、日志信息对异样进行剖析，给出初步的诊断后果。

变更监控

手淘中大部分的问题是因为线上变更导致的。现有监控排查体系并没有专门对变更进行监控，次要还是依赖异样数量、异样趋势进行告警。这就有肯定的滞后性，导致很难在放量阶段疾速的发现问题。同时对于变更公布也没有一个对立的管控规范。所以咱们在端侧引入了染色 SDK 来收集变更数据，配合无线运维的变更诊断平台，对变更公布进行监控，做到可灰度、可观测、可回滚。

目前端侧的变更包含通用的配置变更（Orange 平台）、AB 试验变更和业务自定义的变更（试金石、平安、新奥创等等）。染色 SDK 在端侧和这些 SDK 进行对接，收集到端侧的变更数据后会生成对应的染色标识并上报。配合 TLOG 和诊断 SDK，记录这些变更，并且在产生异样时给异样信息打标。平台侧也会和各个公布平台、高可用数据平台买通，依据客户端上报的数据进行公布决策。

染色标识

变更其实是服务端向客户端下发数据，客户端应用的过程。

所以针对变更，咱们定义出：

• 变更类型：用来辨别变更的品种，比方配置变更（orange）、试验变更（ABTest）、业务 A 变更，业务 B 变更等等；
• 配置类型：一个变更类型下可能有多个配置，比方 orange 变更，每个配置有一个 namespace，用来辨别配置的类型；
• 版本信息: 代表了一个配置的一次具体的公布。不肯定所有配置变更都有明确的版本信息，能够把某个公布或配置的惟一标识作为版本信息。比方每个 orange 配置公布都有一个 version，每个 ABTest 公布都有一个 publishID。

有了这些信息咱们就能够给每一个变更生成一个惟一的染色标识。通过上报染色标识咱们能够统计出变更的失效数；通过在快照信息中携带染色标识，能够计算有变更标识的 crash 率、舆情数量；通过和高可用大盘数据进行比拟监控变更的品质。业务也能够在网络申请中带上染色标识，用于统计相干的接口是否存异样。

灰度定义

对于染色 SDK 咱们是心愿在灰度期间可观测，提前发现问题，不把变更导致的问题带到线上全量环境中，所以咱们把公布过程定位为三个阶段：

• 准备期：筹备变更数据，预发验证、提交审批、线上公布。这个阶段能够确定公布变更的类型、配置、版本；
• 灰度期：对局部用户下发变更配置。咱们的染色监控也次要是在这个阶段运行，次要为上报染色标识和在异样快照中携带染色标识。平台侧在这个阶段对数据进行解决，生成灰度相干数据；
• 全量期：当灰度达标之后，进入全量期。这个时候向所有满足条件的用户推送配置。

数据上报管制

因为手淘用户量太大，变更全量之后如果还持续上报失效数据，对服务端的压力会很大。同时异样信息中如果持续打标意义也不大了。所以咱们必须有一个机制来管控端侧的染色数据上报。

针对 orange、ABTest 这些通用的变更，咱们进行了独自适配，能够依据试验号、配置 namespace 进行黑白名单管制、采样管制或公布状态来管制。但对于自定义变更来说，可管制的条件千差万别，如果要做到精密的管制就必须要了解这个特定的变更。所以咱们定义了一些通用的条件：灰度标识、采样率、过期工夫来管制。

[]()

这些信息是通过配置文件的模式下发到端上。端侧无需关注这些条件设置的逻辑，而是在平台侧进行设置，平台侧对接公布平台、高可用平台，并依据上报数据进行决策。目前次要还是根据配置中的灰度标识 + 超时工夫来决定是否上报。

公布门禁

端侧上报了失效数、异样染色等数据之后，服务端就能够依据这些数据来监控变更。依据相干 Crash 数量、舆情数量、灰度工夫等来断定以后变更是否达到了全量公布的规范。

同时也会列出和这次变更相干的 crash 信息、舆情信息。辅助断定本次变更公布是否存在危险。

目前曾经有 Orange 配置变更、AB 试验变更、详情、下单等业务接入。成果还是不错，曾经胜利躲避了 4 个线上故障。

场景化上报

场景化数据上报，是诊断体系中的一个重要能力。以往都是当告警时咱们手动的从端上捞取相干数据进行排查，并且不同异样须要的数据也不雷同，常常要跨多个平台，进行屡次操作。这就导致数据获取滞后，整个排查时长不可控。所以在端侧具备了新的日志规范、异样快照收集、异样变更染色等根底能力后，咱们引入了场景化上报。

举个列子，依照现有的排查形式，当线上产生异样告警时，咱们个别先通过上报的异样信息来排查，但受限于现有信息不全，往往还须要通过拉取 TLOG 来做进一步排查，然而 TLOG 捞取又依赖用户在线，这就导致整个排查定位工夫十分长。

引入场景化概念之后，当平台检测到异样数量快要达到阈值的时候，能够主动生成一份场景规定配置，圈选一批用户下发到端上。当端上产生了雷同异样的时候，场景引擎会负责收集和上报所须要的数据，这样当告警达到阈值时平台上就曾经有足够的数据进行剖析定位。

场景规定

场景引擎次要用来执行服务端下发的场景规定，而一个场景规定次要由三局部形成：

触发 (Trigger)

能够是端上的一个行为或一个事件。绝对于以前只有在 Crash、业务异样时才上报数据，咱们对异样触发机会进行了裁减。

• 解体异样
• 用户截屏反馈
• 网络异样（mtop 谬误、network 谬误等）
• 页面异样（白屏、显示异样）
• 零碎异样（内存占用过高、cpu 占用过高、耗电过快、发热、卡顿）
• 业务异样 (业务错误码、逻辑谬误等)
• 启动（个别用于定向诊断）

条件 (Condition)

条件断定是整个场景化上传的外围。减少了场景条件之后，咱们能够从多个维度更精准的去划分异样类型。条件大抵上能够分为：

• 根底条件：从设施信息、用户信息、版本信息等维度去进行匹配和筛选；
• 状态条件：次要包含网络状态、以后页面、内存水位等运行时的信息；
• 特定条件：不同场景须要断定的条件是不同的。比方产生 Carsh 时，能够依据 Exception 类型、堆栈等信息进行匹配。而业务异样时可能依据错误码和网络谬误来进行匹配。

行为 (Action)

当端上某个规定被触发，并且满足设定的所有条件时，就会触发指定的行为，这样就能够依据不同的场景收集不同的数据。目前端侧次要行为有：

• 上传 TLOG 日志
• 上传快照信息
• 上传内存信息
• 协同其余排查工具依据下发的参数进行数据收集上报

场景下发

平台侧建设了一套新的场景治理平台，能够不便的配置各种场景和条件。并且也有规范的公布、审核、灰度流程。通过 PUSH + PULL 的形式，客户端能够及时的获取到场景规定。

平台和端侧也都反对定向下发配置的能力，通过指定一些根底的条件，能够针对不同设施，不同用户进行有针对性的场景下发。

数据流量管控

端上匹配了对应的场景规定后，就会上报各种异样数据。然而如果数据量过大，会对服务端存储产生较大压力。所以咱们针对场景上报的数据进行了流量管控。

从排查问题的角度登程，对于同一个问题咱们可能只须要几份相干的日志和数据。所以咱们在创立一个场景时会指定一个数据上报的阀值。当平台收集到足够的数据之后，这个场景就会进行，并告诉客户端规定下线。

同时端上为了保障用户不因为频繁上传诊断数据而对失常应用造成影响，端侧也有本人的限流策略。比方必须是 wifi 环境才能够上报、限度每天执行规定的数量、限度每天上传的数据量、设定数据的上传间隔时间等等。

自定义场景

目前咱们的触发都是一些通用的场景，从高可用工具中获取数据上报。然而业务可能有一套本人的异样监控体系。所以咱们也提供了相应的接口给业务来调用，利用咱们场景下发、规定表达式执行、获取运行数据等能力，来帮忙业务进行问题诊断。业务能够定义本人的触发机会、触发条件。后续咱们也能够退出自定义行为的能力，让业务也能够依据场景来上报相应的数据。

定向诊断

端上目前除了 TLOG，还有内存工具、性能工具、卡顿工具等其余一些排查工具。这些工具在排查特定问题时比拟有用。但目前在线上都是通过配置采样开启或默认敞开的。而现有的配置还无奈针对设施，用户进行定向下发。这就会导致排查问题时拿不到残缺无效的信息。所以咱们也是利用场景化定向下发能力，对现有工具进行了简略的革新，协同这些工具进行异样数据的收集和上报。

将来瞻望

目前端侧的诊断能力还在继续的建设中，咱们也针对现有排查过程中存在的痛点进行迭代，比方实时日志、近程调试、欠缺全链路数据、异样数据等等。此外，咱们也须要看到，端侧诊断不再是简略的堆砌工具，收集数据，咱们将来还须要更有针对性、更精细化的去收集和解决数据。

而随着诊断数据的欠缺，下个挑战将是平台如何利用数据进行问题根因定位、剖析问题影响面、对诊断后果进行积淀。对于端侧而言，也不仅仅只定位在数据收集，还能够依赖平台的诊断常识积淀，联合端智能的能力，在端侧实现问题诊断的能力。同时能够配合端侧的降级能力、动静修复等能力，在产生异样后实现自愈。

关注咱们，每周 3 篇挪动干货 & 实际给你思考！