一种产品Crash数据监测方法及系统与流程

一种产品crash数据监测方法及系统
技术领域
[0001]
本发明涉及网络应用技术领域，特别地涉及一种产品crash数据监测方法及系统。


背景技术：

[0002]
随着网络应用技术的发展，各种功能、类型的应用(application，简称app)为人们的生产、生活带来了极大的便利。网络应用企业会根据用户需求发展多种不同的app，对于企业而言，可将不同的app称为相应业务的产品。产品在上线后是否能够按照预期设计健康运行，是该产品能够生存下去的重要因素之一。为了保证产品上线后能够健康运行，通常从以下几个方面入手：一是在设计、开发阶段，二是在测试、调试阶段，三是进行灰度测试。在现有技术中，由于各种原因，虽然经过以上几个阶段后的产品已经符合要求，但是在上线后仍然可能会出现各种问题，如各种原因的崩溃(crash)、用户反映的各种出现在冷启动、页面加载时的不好体验等等。其中，crash是产品中经常出现、又对用户体验影响非常大的一类问题，因而，对crash数据的监测在查找原因、获取产品的整体健康状态等操作中起着重要的作用。


技术实现要素：

[0003]
针对现有技术中存在的技术问题，本发明提出了一种crash数据监测方法及系统，用以从多方面监测crash数据，以快速获取产品健康度。
[0004]
为了解决上述技术问题，本发明提供了一种产品crash数据监测方法，包括以下步骤：
[0005]
收集目标产品的crash数据；
[0006]
按照多个预置分类维度分析所述crash数据以得到所述crash数据的多个分类维度指标；以及
[0007]
按照统计指标统计crash数据的相应分类维度指标数据以获得对应维度的统计数据。
[0008]
根据本发明的另一个方面，本发明还提供了一种产品crash数据监测系统，包括数据收集模块、预处理模块和分析模块，其中，所述数据收集模块，经配置以收集产品的crash数据；所述预处理模块，经配置以按照预置的多个分类维度分析所述crash数据以得到所述crash数据的多个分类维度指标数据；所述分析模块，经配置以按照统计指标统计crash数据的相应分类维度指标数据以获得对应维度的统计数据。
[0009]
本发明按照不同的维度对crash数据进行分类，从多个不同侧面分析crash数据，从而可以快速了解到当前产品的健康状态；通过各个维度的crash统计数据，可以快速定位出现问题的crash；通过跟踪管理与crash相关联的缺陷达到控制产品整体crash率、保证项目质量的目的。
附图说明
[0010]
下面，将结合附图对本发明的优选实施方式进行进一步详细的说明，其中：
[0011]
图1是根据本发明的一个实施例的一种产品crash数据监测系统的原理框图；
[0012]
图2是根据本发明的一个实施例的crash数据的详细信息示意图；
[0013]
图3是根据本发明的一个实施例的创建缺陷的界面示意图；
[0014]
图4是根据本发明的一个实施例的统计48小时内每个小时内的针对缺陷发生的crash增量数据示意图；
[0015]
图5是根据本发明的一个实施例的crash排序表；
[0016]
图6是根据本发明的一个实施例的按照“创建线程”和“sdk”两个维度指标进行统计得到的crash统计数据示意图；
[0017]
图7是根据本发明的一个实施例的crash小时环比增量超过阈值时的报警信息及统计数据示意图；
[0018]
图8是根据本发明的一个实施例的crash的总次数占比超过阈值时的报警通知示意图；
[0019]
图9是根据本发明的一个实施例的crash同比增加数量超过阈值而报警的报警通知示意图；
[0020]
图10是根据本发明的一个实施例的事件信息的统计信息示意图；以及
[0021]
图11是根据本发明的一个实施例的首页数据显示示意图。
具体实施方式
[0022]
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0023]
在以下的详细描述中，可以参看作为本申请一部分用来说明本申请的特定实施例的各个说明书附图。在附图中，相似的附图标记在不同图式中描述大体上类似的组件。本申请的各个特定实施例在以下进行了足够详细的描述，使得具备本领域相关知识和技术的普通技术人员能够实施本申请的技术方案。应当理解，还可以利用其它实施例或者对本申请的实施例进行结构、逻辑或者电性的改变。
[0024]
本发明提供了一种产品crash数据监测系统和方法，所述的产品包括各种app。在现实情况中，一个app由于增加功能、完善性能等原因可能包括多个版本，本发明在监测一个产品的crash数据时可根据需要选择或设定监测的版本。
[0025]
图1为根据本发明一个实施例的一种产品crash数据监测系统原理框图。在本实施例中，所述系统包括数据收集模块1、预处理模块2及分析模块3，其中，所述数据收集模块1包括各种数据采集单元和数据接口，所述数据采集单元可作为一段采集数据的代码集成在产品应用包的客户端或/和服务端中。在用户下载应用的客户端或升级包时，采集数据的代码随之一起安装到客户端终端上，在用户端采集crash数据。集成在服务端的采集数据代码可获取到服务端的crash数据。数据收集模块1还包括与其他数据平台、监测系统等现有平台连接的数据接口，以获取相应的数据。
[0026]
收集到的所述crash数据包括用户id、发生的产品版本、对应的业务模块、发生的时间、发生次数、对应的用户数量、发生时正在创建的线程、基本类型(如oom、非oom、系统native或者非系统native)、发生crash的页面类型等等信息。每发生一次crash，将该次crash的上述信息记录为一条crash记录，并为其编号以方便管理。
[0027]
所述预处理模块2经配置以按照预置的多个分类维度分析所述crash数据以得到所述crash数据的对应分类维度指标数据。其中，所述的分类维度包括crash出现阶段、sdk类型、crash基本类型、crash出现的页面和crash状态，每一个分类维度又包括多个指标。其中，所述crash出现阶段是指当前的crash是该产品的当前最新版本，还是从前的版本。在“crash出现阶段”这一维度，一个实施例中，将当前最新版本首次发生的crash设置为“新增”，将最近n天在其他版本中发生的crash设置为“近期”，将n天之前在其他版本中发生的crash设置为“历史”。通过“crash出现阶段”这一维度的不同指标可以对crash进行分级，可以快速确定该crash是否为新增问题，以避免重复分析历史问题，进而提高分析效率。
[0028]“sdk类型”这一分类维度用于代表发生crash的业务线的相应业务模块，以业务模块作为该维度的指标。例如，对于一个企业或公司而言，其产品包括不同类型的各种应用，如广告类、直播类、阅读类的应用等等，因而sdk维度的指标可以为“音视频”、“广告”、“直播”等，从而方便相应业务部门的相应工作人员在查看各种crash统计数据时可以选择出与其业务相关的crash数据，从而可以快速跟进。
[0029]“crash基本类型”这一分类维度的指标包括oom(out of memory)/非oom、系统native/非系统native、java或创建线程，用以区分crash的类型。
[0030]“crash出现的页面”这一分类维度的指标用于标记crash发生的页面类型，例如游戏页面、广告页面、应用服务页面等等。
[0031]“crash状态”这一分类维度的指标用于标记当前收集到的crash是否已经根据所述crash创建缺陷，如果已创建缺陷，则获取其处理状态，如已处理、待处理等状态。
[0032]
对于一条crash数据按照上述分类维度进行分类标记，从而得相应的分类维度指标数据。如图2所示，为对应部分crash数据的详细信息示意图。图2中的上半部中列出了各个分类维度及该分类维度中具体的指标，下半部分列出了在选定分类维度及其中的具体指标时的crash数据。其中，根据选定的分类维度，crash数据表中展现对应的类型(即具体的指标)及通用crash数据。例如，其中的第一条id为92906286的crash数据，其出现阶段为“近期”，即所述crash在n天内发生在其他版本中。其缺陷状态为“待建”，即还未建缺陷，对比下一条crash数据，其状态为“已修复”，则说明针对该条crash数据已建立缺陷，并且已经修复好该缺陷。在本实施例中，预留了缺陷创建/查看的接口，通过该缺陷创建接口，可以创建一个缺陷，在已创建缺陷时，可通过查看接口查看已创建的缺陷的状态，如图3所示，其为创建缺陷的界面。在创建缺陷时，可为所述缺陷建立标题并增加描述信息，以方便工作人员了解所述缺陷。在缺陷创建后，自动生成缺陷id号。
[0033]
所述分析模块3经配置以按照统计指标统计crash数据的各种分类维度指标数据以获得对应维度的统计数据。其中的统计指标可以有多种，并根据不同的分类维度设置不同的统计指标。例如单纯地统计全部的crash数据，对应的一些通用统计指标如：当日crash率、用户数、用户占比、crash发生次数、与前一次统计相比的趋势等。另外，可以以某个分类维度指标作为统计指标来统计对应指标的crash数据或根据crash数据创建的缺陷。
[0034]
如图4所示，以缺陷作为统计单位，统计48小时内每个小时内的选定版本的所有crash中针对缺陷发生的crash增量数据。其中，图中的issue-id为缺陷的id号，每一个缺陷的统计数据中包括了发生的crash总次数和每个小时的crash次数增量在线上出现crash突增的时候，可以通过该统计数据，快速判断出现问题的具体crash。
[0035]
本发明还可以根据发生的次数对crash进行排序。在进行排序统计时，还需要进行相应指标的计算，例如占比、与前一天相比的波动对比等。如图5所示，为本实施例中提供的非native分类维度指标时的crash排序表，关于排序数量可按需要确定，如20-200。在进行排序时，可以选择具体分类维度指标进行排序。在图5所示的例子中，通过选择“crash基本类型”中的“非native”指标，可以筛选出非系统native的问题，通过计算每天crash的增量数据，可以识别异常变化的crash，方便快速定位。在输出时通过颜色、符号等对一些数据进行标识，以便于观察。如图中波动一项的数据，通过上升箭头符号表示该crash数据增加，并用红色进行标注；用下降箭头符号表示该crash数据下降，并用绿色表示。
[0036]
由于业务方开启线程时会为线程命名，因而通过统计crash发生时候的线程创建情况，可以识别异常的业务使用行为，如图6所示，选择“crash基本类型”这一分类维度指标中的“创建线程”和“sdk”分类维度指标对当前的crash数据进行统计，如对应某个业务模块发生的crash次数、线程数量及对应线程列表，并在线程列表中记载了当前线程的详细信息。
[0037]
进一步地，本发明在对于一些场景提供监控报警功能，即还包括监控报警模块4，以按照监控指标监控crash统计数据，在达到对应的报警条件时报警。在一个实施例中，本发明对单个crash进行监控，在一种情况中，以小时作为一个监控时间单位，统计并计算一个crash小时环比增量，并与阈值进行比较，如果crash小时环比增量超过了阈值则报警。如图7所示，为一则报警通知及对crash数据的48小时统计图表。在该报警通知中，记载了对应的crash id及其缺陷(或问题)。通过这种监测方法，可以更好地监测新版本上线、插件变更、配置变更。在另一种情况中，以天作为一个监控时间单位，统计一个crash的总次数占比，并与阈值进行比较，在一个crash的总次数占比超过了对应的阈值则报警。如图8所示，为一则在一个crash的总次数占比超过了对应的阈值时的报警通知，该通知记载了对应的crash id及相关信息。在另一种情况中，以小时为监控单位，统计某一个版本一小时的crash次数的同比增加数量，并与对应的阈值进行比较，如果同比增加数量超过了阈值则报警。如图9所示，为一则因同比增加数量超过了阈值而报警的报警通知。在该通知中记录了对应crash id及相关信息，如阈值，即图中的基准值等具体的同比数据。
[0038]
由于crash的发生对应着一定的问题，因而，在本实施例中，还包括缺陷管理模块5，所述缺陷可以由专人在专用模块中创建，也可以在本系统，通过缺陷管理模块5提供的接口创建。创建接口如图2、图5所示，创建窗口如图3所示。在创建缺陷时，根据crash发生的sdk可确定对应的业务及其模块，因而在缺陷中关联对应模块归属、负责人，并为所述缺陷创建相关的描述信息。缺陷管理模块5根据缺陷的处理信息定期同步缺陷的状态，如图2中的待修复、已修复状态。根据前所述的分类维度指标中的crash状态可以确定是否根据该crash创建了缺陷。缺陷管理模块5定期统计缺陷，生成缺陷的统计数据以便查看，如通过图2、图5“缺陷”一项中可查看具体的缺陷信息，也可以查看一段时间内的所有的缺陷统计数据。统计数据可以列表的形式标记出每一个缺陷的id、发生次数、负责人、对应的业务或业
务模块及最近一次发生时间等，还可以以图表(柱状、饼图)的形式表现出具体负责人应解决的缺陷数量。统计数据的展现方式可以多种多样，并不局限于本实施例所述的形式。
[0039]
在另一个实施例中，数据收集模块1还获取可导致crash发生的事件信息，本发明中的系统还包括事件分析模块6。所述事件分析模块6根据收集到事件信息，按照服务关联关系中发生的时间顺序生成事件链路。如图10所示，所述的事件链路信息包括标题名称、具体的说明、以及发生时间、更新时间等，并在具体的说明中以序号表达事件链路的顺序。其中，序号可以为时间顺序，也可以是按事件调用关系生成的调用顺序。
[0040]
为了输出用户感兴趣的数据，本发明所述的监控系统还包括输出模块7。其分别与分析模块3、监控报警模块4、缺陷管理模块5和事件分析模块6相连接，以输出各个模块的处理结果。其中，图11是输出模块7输出显示的一个平台的首页整体显示数据，其中包括了本发明中对crash数据的监测结果71。输出时采用的形式根据处理结果选择不同的输出方式，如图11所示，在显示趋势时选择图形加文字说明方式，也可以如图2、图4等的表格方式，或者如图9等所示的文字说明窗口方式。
[0041]
本发明按照不同的维度对crash数据进行分类，可以从多个不同侧面获取受crash影响的产品及其具体业务模块，通过各个维度的crash统计数据，可以快速定位出现问题的crash；本发明将crash和缺陷相关联，并跟踪管理所述缺陷，从而达到控制产品整体crash率、保证项目质量的目的。
[0042]
上述实施例仅供说明本发明之用，而并非是对本发明的限制，有关技术领域的普通技术人员，在不脱离本发明范围的情况下，还可以做出各种变化和变型，因此，所有等同的技术方案也应属于本发明公开的范畴。