淘宝客户端(淘宝特价版app官网下载)

作者:易易

淘宝作为一款航母应用，每天都有上亿用户在使用。确保客户的稳定性是我们的首要目标。为此我们也提出了5-15-60的目标。即问题报警时，5分钟响应，15分钟定位，60分钟恢复。然而，现有的筛选系统不能很好地实现这一目标。主要原因如下:

监控阶段

通过Crash堆栈、异常信息进行聚合统计，不够精细准确，不够灵敏；监控到异常后，端侧行为比较单一，只上报异常信息，无法提供更多有用数据；手淘大部分问题都和线上变更有关，但是缺少对变更质量的监控。

调查阶段

监控上报的异常信息不足，依赖日志进行问题排查；Crash或异常时不会主动上传日志，需要手动捞取， 用户不在线获取不到日志；获取日志之后：缺少分类，缺乏标准，日志杂乱，看不懂其他模块的日志；缺少场景信息，无法完整的重现异常时用户的操作场景；缺少整个生命周期相关的事件信息，无法掌握app的运行情况；各个模块上下游的日志信息无法有效关联形成完整链路；现有日志可视化工具功能较弱，无法提高排查效率；问题排查靠人工分析，效率低下，相同问题缺少沉淀；各个系统间的数据缺少关联，需要到多个平台获取数据。诊断体系升级思路

针对以上存在的问题，我们重新设计了整个无线运维诊断系统的架构。在新的架构中，我们引入了场景的概念。以前终端上发生的异常都是独立事件，没有办法对不同的异常做更细致的处理和数据收集。引入场景的概念后，场景可以是一个异常和各种条件的组合，可以针对不同的场景进行配置，使得异常信息的收集更加丰富和准确。

同时，我们重新定义了端异常数据，主要包括标准日志Log数据、记录调用链接的Trace全链接数据、运行时相关的度量指标数据、异常发生时的字段快照数据。平台可以利用异常数据进行监控和报警。你也可以直观地分析这些数据。根据业务的不同，平台提供了分析数据的插件能力。使用语义信息，平台可以进行初步的问题诊断。

所以下一个要实现的目标是:

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

目前，分析运行日志仍然是端到端故障排除的主要手段。如前所述，我们的日志本身存在一些问题。所以我们的第一步是升级日志系统。(在此之前，我们已经对日志本身的基础能力进行了改进，比如提高写性能、提高日志压缩率、提高上传成功率、建立日志的数据市场等。)

为了提高日志检查的效率，我们从日志内容入手，在端重新建立了标准的日志协议。标准化的日志协议可以帮助我们在平台端建立日志可视化和自动化日志分析。从日志、痕迹和度量的角度，我们根据手工冲刷的实际情况，将现有日志分为以下几类:

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

有了这些数据。借助平台侧的日志可视化平台，可以快速回放端侧的行为。得益于日志的标准化，可以从平台端分析日志，快速显示异常节点。

端侧诊断升级

客户端是整个诊断系统的源头，所有的异常数据和运行信息都由客户端上的各种工具进行采集和上报。目前，主要的端侧工具有:

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

可以看出，在端侧已经有很多成熟的工具在使用，但是在排查问题时经常会发现数据缺失等问题。主要原因是，一方面这些数据分散在平台端，没有统一的接口来查询；另一方面，客户端没有整合这些工具的数据，发生异常时这些工具之间的交互很少，导致数据丢失。

为了解决这些问题，我们在端侧引入了全新的诊断SDK和染色SDK。他们的主要职能是:

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

异常快照

边上的异常主要有崩溃、业务异常、舆论等。发生异常时，上报的数据格式、内容、渠道、平台都不一样。如果要增加一些数据，端侧和对应的平台都需要修改。因此，我们监控与端到端异常监控相关的SDK，并为业务提供异常通知接口。当诊断SDK收到异常时，它将使用当前收集的运行信息生成快照数据。每个快照数据都有一个唯一的snapshotID。我们只需要将这个ID传递给相应的SDK，这样对现有SDK的改动就很小了。

随着端到端能力的增强，快照数据会越来越丰富。采集的快照信息会上传到诊断平台，平台可以使用snapshotID进行数据关联。对于诊断平台，可以根据快照信息和日志信息对异常进行分析，给出初步的诊断结果。

变更监控

淘客的大部分问题都是因为线上的变化造成的。现有的监视和调查系统并不专门监视变化，而是主要依靠异常的数量和趋势来发出警报。这有一定的滞后性，很难在放量阶段快速发现问题。同时，变更发布也没有统一的控制标准。所以我们在最后引入了染色SDK来收集变更数据，配合无线运维的变更诊断平台来监控变更发布，做到灰色、可观察、可回滚。

目前端到端的改动包括通用配置改动(橙平台)、AB测试改动和业务定制改动(试金石、安全、新奥创等。).染色SDK在端侧与这些SDK连接，在端侧采集到变化数据后，会生成相应的染色标识并上报。配合TLOG和诊断SDK记录这些变化，并在出现异常时标记异常信息。该平台还将与各种发布平台和高可用数据平台进行通信，并根据客户端上报的数据做出发布决策。

1个染色标记

实际上，变化就是服务器向客户端发送数据，客户端使用数据的过程。

因此，对于变化，我们定义为:

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

有了这些信息，我们可以为每个变化生成一个独特的染色标识。我们可以通过报告染色标记来统计变化的有效次数；通过在快照信息中携带染色标记，可以计算标记改变后的崩溃率和舆情数量；通过将变更与高可用性大规模数据进行比较来监控变更的质量。服务也可以在网络请求中用dye标记，用来统计相关接口是否异常。

2灰度定义

对于染色SDK，我们希望能在灰度期间观察到，及早发现问题，不要把变化带来的问题带到线上全尺度环境，所以我们把发布过程定位为三个阶段:

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

3数据报告控制

因为用户数量太大，如果改变总量后继续上报有效数据，服务器压力会很大。同时，如果继续标记异常信息，意义也不大。因此，我们必须有一个机制来控制端到端的染色数据报告。

对于orange和ABTest的一般性改动，我们做了个别适配，可以根据实验号、配置命名空间、黑白名单控制、采样控制或者发布状态来控制。但是，对于自定义更改，可控条件千差万别。想要达到精细控制，就必须了解这个具体的变化。所以我们定义了一些通用条件:灰度识别、采样率和到期时间来控制。

这些信息以配置文件的形式发送给客户端。端不需要关注这些条件设置的逻辑，而是在平台端设置。平台端连接发布平台和高可用平台，根据上报的数据进行决策。目前主要是根据配置的灰标+超时时间来决定是否上报。

4释放访问控制

客户端上报有效号、染色异常等数据后，服务器可以根据这些数据监控变化。根据相关崩溃量、舆情量、灰色时间等。，确定当前变化是否达到完全释放的标准。

与此变化相关的崩溃信息和舆论信息也会被列出。协助确定此变更发布中是否存在任何风险。

目前有橙配置变更、AB测试变更、详情、订单等业务接入。效果还是不错的，已经成功避免了4次在线故障。

现场报道

场景数据报告是诊断系统中的一项重要功能。以前我们在报警时都是手动从终端中捞出相关数据进行调查，不同异常所需的数据也不一样，经常要跨多个平台，进行多次操作。这就导致了数据采集的滞后性，整个调查时间是不可控的。所以在端侧有了日志标准、异常快照采集、异常变化染色等新的基础能力之后。，我们引入了情景报告。

比如，根据现有的故障排查方法，当出现在线异常告警时，我们通常首先通过上报的异常信息进行故障排查。但由于现有信息不完整，往往需要拉TLOG进一步排查。然而，TLOG钓鱼依赖于用户的在线，这导致了非常长的故障排除和定位时间。

引入场景概念后，当平台检测到异常数量即将达到阈值时，可以自动生成一个场景规则配置，选择一组用户发送到底。当终端发生同样的异常时，场景引擎会负责收集和上报所需的数据，这样当告警达到阈值时，平台上就会有足够的数据进行分析和定位。

1场景规则

场景引擎主要用于执行服务器发布的场景规则，场景规则主要由三部分组成:

触发器(触发器)

它可以是一个动作，也可以是一个事件。相对于以前只在崩溃或业务异常时上报数据，我们扩大了异常触发的时机。

崩溃异常用户截屏反馈网络异常 （mtop错误、network错误等）页面异常 （白屏、显示异常）系统异常 （内存占用过高、 cpu占用过高、 耗电过快、发热、卡顿）业务异常 (业务错误码、逻辑错误等)启动 （一般用于定向诊断）

条件(条件)

条件确定是整个场景上传的核心。添加场景条件后，我们可以更准确地从多个维度划分异常类型。条件大致可以分为:

基础条件：从设备信息、用户信息、版本信息等维度去进行匹配和筛选；状态条件：主要包括网络状态、当前页面、内存水位等运行时的信息；特定条件：不同场景需要判定的条件是不同的。比如发生Carsh时，可以根据Exception类型、堆栈等信息进行匹配。而业务异常时可能根据错误码和网络错误来进行匹配。

行动(行动)

当某个规则被触发，设定的条件全部满足时，就会触发指定的行为，这样就可以根据不同的场景采集不同的数据。目前，端侧的主要行为有:

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

2场景分布

平台侧搭建了全新的场景管理平台，可以轻松配置各种场景和条件。此外，还有一个标准的发布、审核和灰度处理流程。通过推+拉的方式，客户端可以及时获取场景规则。

平台侧和端侧也支持定向分布配置的能力。通过指定一些基本条件，可以针对不同的设备和用户进行有针对性的场景分发。

3数据流控制

匹配相应的场景规则后，会上报各种异常数据。但如果数据量过大，会给服务器存储带来很大压力。所以我们对现场上报的数据进行了流量控制。

从故障排除的角度来看，对于同一个问题，我们可能只需要几个相关的日志和数据。因此，当我们创建一个场景时，我们将为数据报告指定一个阈值。当平台收集到足够的数据时，这个场景将会停止，并通知客户端规则已经离线。

同时，为了保证用户不会因为频繁上传诊断数据而受到影响，端侧也有自己的限流策略。比如必须是wifi环境才能上报，限制每天执行的规则数量，限制每天上传的数据量，设置数据的上传间隔等等。

4自定义场景

目前我们的触发器都是常见场景，从高可用的工具中获取数据报告。但是企业可能有自己的异常监控系统。所以我们也提供相应的接口给业务调用，利用我们发布场景、执行正则表达式、获取运行数据的能力帮助业务诊断问题。服务可以定义自己的触发机会和触发条件。我们还可以在后续加入自定义行为的能力，让业务也能根据场景上报相应的数据。

5定向诊断

目前，除了TLOG，还有其他故障排除工具，如内存工具，性能工具和卡顿工具。这些工具在排除特定问题时非常有用。但目前默认开启或关闭在线采样。但是，现有的配置不能针对设备和用户。这将导致在排除故障时无法获得完整有效的信息。因此，我们还利用面向场景分发的能力，对现有工具进行简单改造，并与这些工具合作收集和报告异常数据。

未来展望

目前端到端的诊断能力还在持续建设中，我们也在对现有故障排查过程中存在的痛点进行迭代，比如实时日志、远程调试、全链路数据的完善、异常数据等等。此外，我们还需要看到，端到端的诊断不再是简单的堆叠工具来收集数据，未来需要更有针对性和精细化的数据收集和处理。

随着诊断数据的完善，接下来的挑战将是如何利用数据定位问题根源，分析问题影响面，沉淀诊断结果。对于端侧来说，不仅仅定位于数据采集，还要依靠平台的诊断知识沉淀，结合端智能的能力，实现端侧的问题诊断。同时可以配合端侧退化、动态修复等能力。，并在出现异常后实现自愈。

关注我们，每周3篇移动干货&为你的思想而实践！