CN103019879A - 浏览器崩溃信息的处理方法及系统 - Google Patents

Abstract

本发明公开了一种浏览器崩溃信息的处理方法及系统。其中方法包括：接收浏览器崩溃时上传的浏览器崩溃状态信息；根据所述浏览器崩溃状态信息生成指示是否允许浏览器上传崩溃数据包的崩溃标识信息；反馈所述崩溃标识信息到所述浏览器；在所述崩溃标识信息表明允许浏览器上传崩溃数据包的情况下，接收所述浏览器上传的包括崩溃数据包的崩溃信息；启动崩溃数据包自动分析程序，对所述崩溃数据包进行分析；将所述崩溃数据包的分析结果数据下发到所述上传崩溃数据包的浏览器。本发明提供了一种云系统级的方案，能够有针对性地对浏览器的崩溃信息进行收集、处理、分析以及鉴定。

Description

浏览器崩溃信息的处理方法及系统

技术领域

本发明涉及计算机网络技术领域，具体涉及一种浏览器崩溃信息的处理方法及系统。

背景技术

云计算（cloud computing）是分布式计算技术的一种，其最基本的概念是通过网络将庞大的计算处理程序自动拆分成无数个较小的子程序，再交由多部服务器所组成的庞大系统经搜寻、计算分析之后将处理结果回传给用户。通过该技术，网络服务提供者可以在数秒之内达成处理数以千万计甚至数以亿计的信息的目的，从而达成和“超级计算机”同样强大效能的网络服务。

在浏览器进行网页加载的过程中，常常由于种种原因使得浏览器反应变得很慢，或者造成浏览器失去响应，甚至会导致机器无法进行其他的操作。这种现象被称之为浏览器崩溃。导致浏览器崩溃的原因主要包括：内存泄露、网页代码复杂和浏览器的故障（Bug）、网页数据过多、网络服务漏洞等。

在windows系统中，一般通过windows错误报告来上传操作系统出现的各类问题。由于windows系统中IE浏览器是与操作系统绑定的，所以当IE出现崩溃时，操作系统会收集浏览器的状态信息，并将信息封装到一个错误报告中回传给服务器端。而对于浏览器端产生崩溃后，现有技术没有提供一种云系统级的方案，能够有针对性地对浏览器的崩溃信息进行收集、保存、分析以及鉴定。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的浏览器崩溃信息的处理系统和相应的浏览器崩溃信息的处理方法。

根据本发明的一个方面，提供了一种浏览器崩溃信息的处理方法，包括：接收浏览器崩溃时上传的浏览器崩溃状态信息；根据所述浏览器崩溃状态信息生成指示是否允许浏览器上传崩溃数据包的崩溃标识信息；反馈所述崩溃标识信息到所述浏览器；在所述崩溃标识信息表明允许浏览器上传崩溃数据包的情况下，接收所述浏览器上传的包括崩溃数据包的崩溃信息；启动崩溃数据包自动分析程序，对所述崩溃数据包进行分析；将所述崩溃数据包的分析结果数据下发到所述上传崩溃数据包的浏览器。

根据本发明的另一方面，提供了一种浏览器崩溃信息的处理系统，包括：第一接口，用于接收浏览器崩溃时上传的浏览器崩溃状态信息；第一云崩溃服务器，用于根据所述浏览器崩溃状态信息生成指示是否允许浏览器上传崩溃数据包的崩溃标识信息，通过所述第一接口反馈所述崩溃标识信息到所述浏览器；第二接口，用于在所述崩溃标识信息表明允许浏览器上传崩溃数据包的情况下，接收所述浏览器上传的包括崩溃数据包的崩溃信息；分析设备，用于启动崩溃数据包自动分析程序，对所述崩溃数据包进行分析；下发设备，用于通过所述第二接口将所述崩溃数据包的分析结果数据下发到所述上传崩溃数据包的浏览器。

根据本发明提供的方案，在接收到浏览器崩溃时上传的浏览器崩溃状态信息之后，根据该浏览器崩溃状态信息生成指示是否允许浏览器上传崩溃数据包的崩溃标识信息，并反馈给浏览器，以供浏览器根据崩溃标识信息确定是否得到上传崩溃数据包的允许。在得到允许的情况下，浏览器上传崩溃数据包，云端启动自动分析程序对崩溃数据包进行分析，并将分析结果数据下发给浏览器。本发明提供了一种云系统级的方案，能够有针对性地对浏览器的崩溃信息进行收集、处理、分析以及鉴定。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的浏览器崩溃信息的处理方法的流程图；

图2示出了根据本发明另一个实施例的浏览器崩溃信息的处理方法的流程图；

图3示出了根据本发明一个实施例的浏览器崩溃信息的处理系统的结构框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了根据本发明一个实施例的浏览器崩溃信息的处理方法100的流程图。如图1所示，方法100始于步骤S101，其中接收浏览器崩溃时上传的浏览器崩溃状态信息。在浏览器产生崩溃时，首先向云端上传浏览器崩溃状态信息。可选地，浏览器使用云端提供的Get接口向其上传浏览器崩溃状态信息。浏览器崩溃状态信息是浏览器反馈的有关崩溃状态的信息，其至少包括浏览器崩溃公共参数信息（pubkey），可选地还可包括命令行、浏览器产品名称以及第一浏览器侧数据校验信息，其中第一浏览器侧数据校验信息是浏览器根据浏览器崩溃公共参数信息和预设密钥生成的。浏览器崩溃公共参数信息至少包括如下信息：崩溃模块的相关信息、具体崩溃偏移、崩溃堆栈、浏览器版本号以及操作系统版本号。

随后，方法100进入步骤S102，其中根据浏览器崩溃状态信息生成指示是否允许浏览器上传崩溃数据包的崩溃标识信息（dumpid）。云端主要是根据上述浏览器崩溃公共参数信息生成崩溃标识信息。具体来说，云端从浏览器崩溃状态信息中提取出崩溃模块的相关信息、具体崩溃偏移、崩溃堆栈、浏览器版本号、操作系统版本号等浏览器崩溃公共参数信息，按照预设算法对这些信息进行处理，生成崩溃键值（dumpkey），例如：按照MD5算法对上述信息进行处理生成dumpkey。云端累计对相同的浏览器崩溃状态信息的接收次数，具体做法就是累计相同dumpkey的数目，如果相同dumpkey的数目大于或等于预设阈值（比如3），表明云端对相同的浏览器崩溃状态信息的接收次数已大于或等于3次，则生成的dumpid为0，即不允许浏览器上传崩溃数据包；如果相同dumpkey的数目小于3，则生成的dumpid大于0，即允许浏览器上传崩溃数据包。

随后，方法100进入步骤S103，其中反馈崩溃标识信息到浏览器。云端将崩溃标识信息反馈给浏览器，可选地云端反馈给浏览器的信息为JSON格式的信息。浏览器接收到崩溃标识信息后，如果获知不允许上传崩溃数据包，那么此次交手结束。如果获知允许上传崩溃数据包，则进入步骤S104。

在步骤S104中，接收浏览器上传的包括崩溃数据包的崩溃信息。在崩溃标识信息表明允许浏览器上传崩溃数据包的情况下，云端接收浏览器上传的崩溃数据包。可选地，云端使用Post接口接收浏览器上传的崩溃数据包。

在步骤S104之后，方法100进入步骤S105，其中启动崩溃数据包自动分析程序，对崩溃数据包进行分析。云端可以通过部署的自动崩溃数据包分析程序，随时监控浏览器上传的崩溃数据包，一旦发现有新的崩溃数据包，立即进行分析，并及时返回分析结果数据，这样达到了实时分析的目的。云端也可以调用自动化分析接口对浏览器上传的崩溃数据包进行分析。

随后，方法100进入步骤S106，将崩溃数据包的分析结果数据下发到上传崩溃数据包的浏览器。云端根据崩溃数据包的分析结果数据所对应的浏览器的MID或QID将崩溃数据包的分析结果数据下发到对应的浏览器。

图2示出了根据本发明另一个实施例的浏览器崩溃信息的处理方法200的流程图。如图2所示，方法200始于步骤S201，其中使用Get接口接收浏览器崩溃时上传的浏览器崩溃状态信息。本方法中，在浏览器产生崩溃时，浏览器使用云端提供的Get接口向其上传浏览器崩溃状态信息。表1示出了浏览器崩溃状态信息所包含的具体内容。其中，浏览器崩溃公共参数信息（pubkey）、浏览器产品名称（src）和第一浏览器侧数据校验信息（cverify1）是必选内容，命令行（cmd）和自定义信息（custom）是可选内容，这些信息的类型均为string类型。

表1.浏览器崩溃状态信息的示意表

进一步的，表2示出了pubkey的具体内容。pubkey除了包括崩溃模块的相关信息、具体崩溃偏移、崩溃堆栈、浏览器版本号以及操作系统版本号等信息以外，还包括很多其它信息。

表2.浏览器崩溃公共参数信息的示意表

随后，方法200进入步骤S202，其中通过效验浏览器产品名称（src）来对浏览器产品的合法性进行校验。在接收到浏览器上传的浏览器崩溃状态信息之后，提取其中的src，根据src可判断出浏览器产品是否合法，如合法，则进入步骤S203；如不合法，本方法结束。

在步骤S203中，通过验证第一浏览器侧数据校验信息（cverify1）是否正确来对崩溃状态信息的合法性和完整性进行校验。其中cverify1是浏览器根据pubkey和预设密钥生成的，例如：cverify1=MD5(pubkey+密钥)，即对pubkey和预设密钥进行MD5算法加密得到cverify1。在接收到浏览器上传的浏览器崩溃状态信息之后，提取其中的cverify1，判断cverify1是否正确，如正确，表明崩溃状态信息是合法且完整的，则进入步骤S204；否则，本方法结束。

在步骤S204中，对预先定义的时间段内从相同地址的浏览器再次接收的浏览器崩溃状态信息进行丢弃处理。为了防止浏览器在短时间内（比如2s）连续提交相同的信息，通过进行缓存进行提交限制，在短时间内连续提交的信息视为一次提交，判断规则可基于cverify1。

随后，方法200进入步骤S205，其中根据浏览器崩溃状态信息生成指示是否允许浏览器上传崩溃数据包的崩溃标识信息（dumpid）。具体来说，云端从pubkey中提取出崩溃模块的相关信息、具体崩溃偏移、崩溃堆栈、浏览器版本号、操作系统版本号等信息，根据这些信息生成崩溃键值（dumpkey），例如：dumpkey=MD5(崩溃模块+具体崩溃偏移+崩溃堆栈md5+IE版本号+操作系统版本号)，即对这些信息进行MD5算法加密得到dumpkey。云端累计对相同的浏览器崩溃状态信息的接收次数，具体做法就是累计相同dumpkey的数目，如果相同dumpkey的数目大于或等于预设阈值（比如3），表明云端对相同的浏览器崩溃状态信息的接收次数已大于或等于3次，则生成的dumpid为0，即不允许浏览器上传崩溃数据包；如果相同dumpkey的数目小于3，则生成的dumpid大于0，如dumpid=dump_id，dump_id为大于0的值，即允许浏览器上传崩溃数据包。

随后，方法200进入步骤S206，其中反馈崩溃标识信息到浏览器。进一步的，在反馈崩溃标识信息的同时，还需反馈第一服务器侧数据校验信息（sverify1），以供浏览器对崩溃标识信息的合法性和完整性进行校验。该第一服务器侧数据校验信息是云端根据dumpid和预设密钥生成的，例如：sverify1=MD5(dumpid+密钥)，即对dumpid和预设密钥进行MD5算法加密得到sverify1。云端将崩溃标识信息和第一服务器侧数据校验信息封装为回传信息，反馈给浏览器。该回传信息可为JSON格式。例如，云端反馈给浏览器的回传信息如下：

{＂dumpid＂:＂０＂,"sverify1:＂sverify1_val"}

或{″dumpid":"dump_id","sverify1:"sverify1_val"}

其中sverify_val为sverify1的具体取值。

浏览器接收到上述回传信息后，提取dumpid，如果dumpid为0，表明云端不允许浏览器上传崩溃数据包，那么此次交手结束。如果dumpid为dump_id，表明云端允许浏览器上传崩溃数据包，则进入步骤S207。

在步骤S207中，使用Post接口接收浏览器上传的包括崩溃数据包的崩溃信息。在崩溃标识信息表明允许浏览器上传崩溃数据包的情况下，云端接收浏览器上传的包括崩溃数据包的崩溃信息。表3示出了崩溃信息所包含的具体内容，具体为浏览器产品名称（src），崩溃标识信息（dumpid），崩溃数据包（file）和第二浏览器侧数据校验信息（cverify2）。

表3.崩溃信息

随后，方法200进入步骤S208，其中通过效验浏览器产品名称（src）来对浏览器产品的合法性进行校验。在接收到浏览器上传的崩溃信息之后，提取其中的src，根据src可判断出浏览器产品是否合法，如合法，则进入步骤S209；如不合法，本方法结束。

在步骤S209中，通过验证第二浏览器侧数据校验信息（cverify2）是否正确来对崩溃信息的合法性和完整性进行校验。其中cverify2是浏览器根据崩溃数据包、崩溃标识信息和预设密钥生成的，例如：cverify2=MD5(file内容+dump_id+密钥)，即对file内容、dump id和预设密钥进行MD5算法加密得到cverify2。在接收到浏览器上传的崩溃信息之后，提取其中的cverify2，判断cverify2是否正确，如正确，表明崩溃信息是合法且完整的，则进入步骤S210；否则，本方法结束。

在步骤S210中，将崩溃数据包存入队列中。云端接收的崩溃数据包来自很多客户端的浏览器。一方面，云端的云崩溃服务器将上传的崩溃数据包保存为临时文件，移动到临时目录；另一方面，云崩溃服务器将通过Post接口上传的崩溃数据包存入到队列中（每一台服务器都可以有一个队列），然后，给浏览器返回信息，通知浏览器上传数据是否成功。云端给浏览器返回的信息如下：

{＂status＂:＂0＂,＂sverify2:"sverify2_val"}

或{＂status＂:＂1″，＂sverify2:＂sverify2_val＂}

其中status为0表示浏览器上传数据失败，status为1表示浏览器上传数据成功。sverify2为第二服务器侧数据校验信息，它是根据status，dump_id和预设密钥生成的，例如：sverify2=MD5(status+dump_id+密钥)，即对status，dump_id和预设密钥进行MD5算法加密得到sverify2。sverfy2_val为sverify2的取值。

云崩溃服务器可以将崩溃数据包存储到持久化存储器中，如Cassandra数据库。

随后，方法200进入步骤S211，其中读取队列，将来自不同浏览器产品的崩溃数据包分送给不同的分析设备。云崩溃服务器读取队列，将来自不同浏览器产品的崩溃数据包同步到多台Windows环境下的Windows机器目录下。以云崩溃服务器为Linux操作系统为例，Linux系统向Windows同步文件可以采用基于C/S模式软件的rsync实现，rsync是数据镜像备份工具，可以镜像保存整个目录树和文件系统。在同步到Windows机器目录下后，在临时目录下的已被同步的崩溃数据包被删除。

随后，方法200进入步骤S212，其中不同的分析设备启动各自的崩溃数据包自动分析程序，对崩溃数据包进行分析。该分析步骤可以采取以下两种方式：一种是Windows机器上部署了自动崩溃数据包分析程序，随时监控当前目录下的文件，一旦发现有新的崩溃数据包，立即进行分析，并及时返回分析结果数据；另一种是Windows机器调用另一云崩溃服务器的自动化分析接口对崩溃数据包进行分析。

随后，方法200进入步骤S213，其中将崩溃数据包的分析结果数据下发到上传崩溃数据包的浏览器。

进一步的，本方法还可以包括：按照预设时间间隔，以增量索引的方式将崩溃数据包的分析结果数据存储在数据库中。具体来说，分析结果数据采用MYSQL（主+从）+SPHINX的架构，所采用的技术为主从数据库分离、按月分表的技术，其中MYSQL为永久存储引擎，MYSQL的主从之间的数据自动同步。主MYSQL专门用于分析结果数据的插入，如上述云崩溃服务器将分析得到的分析结果数据插入到主MYSQL中。从MYSQL用于后台管理员管理，也可作为SPHINX服务器的索引源头，使得SPHINX索引服务器可以对于不断更新的崩溃数据包的分析结果数据进行增量索引，实现管理员的实时数据的检索。具体来说，SPHINX索引服务器每隔5分钟利用增量索引、合并索引方式达到数据实时更新。当数据库中已有数据量很大，又不断有新数据加入到数据库时，如果全部重新建立索引很消耗资源，事实上，在原有数据上需要更新的数据相比较而言很少，例如原来的数据有几百万条，而新增的只是几千条，这样就可以使用“主索引+增量索引”的模式来实现近乎实时更新的功能。

本方法还可以包括：将接收到的崩溃状态信息放入队列，启动进程将队列中的崩溃状态信息存入到主MYSQL中。

一方面，管理员借助SPHINX索引服务器对于从MySQL中收集的崩溃状态信息进行检索以获取例如哪个IE版本的崩溃最多、哪个主程序（浏览器）的崩溃最多、哪种类型的崩溃最多等信息，其直接在崩溃状态信息中依据上述列举消息的请求量给出崩溃的预警信息。将这些检索得到的数据发送到提交崩溃数据包的浏览器进行显示，对用户进行预警哪些浏览器中的崩溃最多。例如可以显示浏览器的各种版本单独监控结果或版本间的对比结果，可以显示每个浏览器版本的各种问题的数据量统计，或者问题数据量超过预期阀值也可以直接通过短信方式报警以提醒用户。

另一方面，存储在MySQL的崩溃数据包的分析结果数据可以包含以下信息：已经分析出来的崩溃模块或函数名称（也可以是关键模块的崩溃情况，即依据收集的崩溃信息中分析、统计出来的关键崩溃模块的信息）；调用上述崩溃模块或函数之前的行为、动作（例如变量名冲突、内存崩溃等）；待依据需求再定的内容（后续扩展的内容）。这样管理者可以进一步检索MySQL中的分析结果记录，通过SPHINX索引服务器获取指定机器标识（MID）的分析结果，然后依据MID显示在客户端的浏览器，对客户端的浏览器进行提示和预警。可选地，除了上述MID，还可以进一步在云崩溃服务器侧获取分析结果的浏览器用户的标识（QID），该QID为浏览器用户的唯一标识，在用户登录时就使用该QID进行唯一标识，这样可以实现对于特定用户（对应着QID）的崩溃分析，从而实现特定用户的预警提示。

综上，根据浏览器的登录用户和非登录用户上报的崩溃数据包或崩溃状态信息，能够及时的获取到基于崩溃状态信息和/或该次崩溃分析结果的预警告示，实现实时化、个性化的预警。

根据上述实施例提供的方法，在接收到浏览器崩溃时上传的浏览器崩溃状态信息之后，根据该浏览器崩溃状态信息生成指示是否允许浏览器上传崩溃数据包的崩溃标识信息，并反馈给浏览器，以供浏览器根据崩溃标识信息确定是否得到上传崩溃数据包的允许。在得到允许的情况下，浏览器上传崩溃数据包，云端启动自动分析程序对崩溃数据包进行分析，并将分析结果数据下发给浏览器。该方法提供了一种云系统级的方案，能够有针对性地对浏览器的崩溃信息进行收集、处理、分析以及鉴定。

图3示出了根据本发明一个实施例的浏览器崩溃信息的处理系统的结构框图。如图3所示，该系统包括第一接口310、第一云崩溃服务器320、第二接口330、分析设备340和下发设备350。

其中第一接口310用于接收浏览器崩溃时上传的浏览器崩溃状态信息。可选地，第一接口310为Get接口。浏览器崩溃状态信息至少包括如下信息中的一种或多种：浏览器崩溃公共参数信息、命令行、浏览器产品名称以及第一浏览器侧数据校验信息，其中第一浏览器侧数据校验信息是浏览器根据浏览器崩溃公共参数信息和预设密钥生成的。浏览器崩溃公共参数信息至少包括如下信息：崩溃模块的相关信息、具体崩溃偏移、崩溃堆栈、浏览器版本号以及操作系统版本号。浏览器崩溃状态信息的具体内容可以参见上述方法实施例的描述。

进一步的，该系统还可包括：第一校验模块311和/或第一验证模块312。在图3中，第一校验模块311和第一验证模块312集成在第一接口310中，但本发明不仅限于此。其中，第一校验模块311用于通过验证第一浏览器侧数据校验信息是否正确来对崩溃状态信息的合法性和完整性进行校验。第一验证模块312用于通过效验浏览器产品名称来对浏览器产品的合法性进行校验。

该系统还可包括：第二缓存服务器360，用于丢弃在预先定义的时间段内从相同地址的浏览器再次接收到的浏览器崩溃状态信息。为了防止浏览器在短时间内（比如2s）连续提交相同的信息，通过进行缓存进行提交限制，在短时间内连续提交的信息视为一次提交，判断规则可基于第一浏览器侧数据校验信息。

第一云崩溃服务器320用于根据浏览器崩溃状态信息生成指示是否允许浏览器上传崩溃数据包的崩溃标识信息，通过第一接口310反馈崩溃标识信息到浏览器。可选的，该系统还包括：第一缓存服务器370，用于按照预设算法对浏览器崩溃公共参数信息进行处理，生成崩溃键值；第一云崩溃服务器320具体用于根据崩溃键值，得到指示是否允许浏览器上传崩溃数据包的崩溃标识信息。具体来说，第一缓存服务器370从浏览器崩溃公共参数信息中提取出崩溃模块的相关信息、具体崩溃偏移、崩溃堆栈、浏览器版本号、操作系统版本号等信息，根据这些信息生成崩溃键值（dumpkey），例如对这些信息进行MD5算法加密得到dumpkey。第一云崩溃服务器320累计对相同的浏览器崩溃状态信息的接收次数，具体做法就是累计相同dumpkey的数目，如果相同dumpkey的数目大于或等于预设阈值（比如3），表明云端对相同的浏览器崩溃状态信息的接收次数已大于或等于3次，则生成的dumpid为0，即不允许浏览器上传崩溃数据包；如果相同dumpkey的数目小于3，则生成的dumpid大于0，如dumpid=dump_id，dump_id为大于0的值，即允许浏览器上传崩溃数据包。

可选的，第一云崩溃服务器320还用于根据崩溃标识信息和预设密钥生成第一服务器侧数据校验信息，并在反馈崩溃标识信息到浏览器的同时，反馈第一服务器侧数据校验信息到浏览器，以供浏览器通过验证第一服务器侧数据校验信息来对崩溃标识信息的合法性和完整性进行校验。

浏览器接收到上述回传信息后，提取dumpid，如果dumpid为0，表明云端不允许浏览器上传崩溃数据包，那么此次交手结束。如果dumpid为dump_id，表明云端允许浏览器上传崩溃数据包。

该系统还包括：数据库380和数据队列服务器390。数据队列服务器390用于将崩溃状态信息放入队列，启动进程将队列中的崩溃状态信息存入到数据库380中。

第二接口330用于在崩溃标识信息表明允许浏览器上传崩溃数据包的情况下，接收浏览器上传的包括崩溃数据包的崩溃信息。可选地，第二接口330为Post接口。崩溃信息可以包含浏览器产品名称，崩溃标识信息，崩溃数据包和第二浏览器侧数据校验信息，其中第二浏览器侧数据校验码是根据崩溃数据包、崩溃标识信息和预设密钥而生成的。崩溃信息的具体内容可以参见上述方法实施例的描述。

进一步的，该系统还可包括：第二校验模块331和/或第二验证模块332。在图3中，第二校验模块331和第二验证模块332集成在第二接口330中，但本发明不仅限于此。第二校验模块331用于通过验证第二浏览器侧数据校验信息是否正确来对崩溃信息的合法性和完整性进行校验。第二验证模块332用于通过效验浏览器产品名称来对浏览器产品的合法性进行校验。

该系统还可以包括：第二云崩溃服务器410和持久化存储器420。其中第二云崩溃服务器410用于从崩溃信息中提取出崩溃数据包，将崩溃数据包存入队列中；以及，读取队列，将来自不同浏览器产品的崩溃数据包分送给不同的分析设备；持久化存储器420用于存储崩溃数据包。第二云崩溃服务器410接收的崩溃数据包来自很多客户端的浏览器。一方面，第二云崩溃服务器410将上传的崩溃数据包保存为临时文件，移动到临时目录；另一方面，第二云崩溃服务器410将通过Post接口上传的崩溃数据包存入到队列中（每一台服务器都可以有一个队列），然后，给浏览器返回信息，通知浏览器上传数据是否成功。第二云崩溃服务器410还将崩溃数据包存储到持久化存储器420中，持久化存储器420可以为Cassandra数据库。

分析设备340用于启动崩溃数据包自动分析程序，对崩溃数据包进行分析。在本系统中，分析设备340可以为多台Windows环境下的Windows机器，以第二云崩溃服务器410为Linux操作系统为例，Linux系统向Windows同步文件可以采用基于C/S模式软件的rsync实现，rsync是数据镜像备份工具，可以镜像保存整个目录树和文件系统。在同步到Windows机器目录下后，在临时目录下的已被同步的崩溃数据包被删除。分析设备340进一步用于：通过部署的自动崩溃数据包分析程序，随时监控浏览器上传的崩溃数据包，一旦发现有新的崩溃数据包，立即进行分析，并及时返回分析结果数据；或者，调用自动化分析接口对浏览器上传的崩溃数据包进行分析。

下发设备350用于通过第二接口330将崩溃数据包的分析结果数据下发到上传崩溃数据包的浏览器。下发设备350进一步用于根据崩溃数据包的分析结果数据所对应的浏览器的机器标识或浏览器用户的标识，将崩溃数据包的分析结果数据下发到对应的浏览器。

本系统还可以包括：第三云崩溃服务器430和索引服务器440。第三云崩溃服务器430用于将分析设备340分析得到的数据传输给索引服务器440。索引服务器440用于按照预设时间间隔，以增量索引的方式将崩溃数据包的分析结果数据存储在数据库380中。具体来说，本系统采用MYSQL（主+从）+SPHINX的架构，即数据库380包括主MYSQL和从MYSQL，索引服务器440为SPHINX索引服务器。数据库380所采用的技术为主从数据库分离、按月分表的技术，MYSQL为永久存储引擎，MYSQL的主从之间的数据自动同步。主MYSQL专门用于分析结果数据的插入，如上述第三云崩溃服务器430向分析设备340提供自动化分析接口，将分析得到的分析结果数据插入到主MYSQL中。从MYSQL用于后台管理员管理，也可作为SPHINX服务器的索引源头，使得SPHINX索引服务器可以对于不断更新的崩溃数据包的分析结果数据进行增量索引，实现管理员的实时数据的检索。

本系统还可以包括：预警设备450，用于对数据库中存储的数据进行统计，如果统计结果超出预设阀值则进行报警。一方面，管理员借助SPHINX索引服务器对于从MySQL中收集的崩溃状态信息进行检索以获取例如哪个IE版本的崩溃最多、哪个主程序（浏览器）的崩溃最多、哪种类型的崩溃最多等信息，其直接在崩溃状态信息中依据上述列举消息的请求量给出崩溃的预警信息。将这些检索得到的数据发送到提交崩溃数据包的浏览器进行显示，对用户进行预警哪些浏览器中的崩溃最多。例如可以显示浏览器的各种版本单独监控结果或版本间的对比结果，可以显示每个浏览器版本的各种问题的数据量统计，或者问题数据量超过预期阀值也可以直接通过短信方式报警以提醒用户。另一方面，存储在MySQL的崩溃数据包的分析结果数据可以包含以下信息：已经分析出来的崩溃模块或函数名称（也可以是关键模块的崩溃情况，即依据收集的崩溃信息中分析、统计出来的关键崩溃模块的信息）；调用上述崩溃模块或函数之前的行为、动作（例如变量名冲突、内存崩溃等）；待依据需求再定的内容（后续扩展的内容）。这样管理者可以进一步检索MySQL中的分析结果记录，通过SPHINX索引服务器获取指定机器标识（MID）的分析结果，然后依据MID显示在客户端的浏览器，对客户端的浏览器进行提示和预警。可选地，除了上述MID，还可以进一步在云崩溃服务器侧获取分析结果的浏览器用户的标识（QID），该QID为浏览器用户的唯一标识，在用户登录时就使用该QID进行唯一标识，这样可以实现对于特定用户（对应着QID）的崩溃分析，从而实现特定用户的预警提示。综上，根据浏览器的登录用户和非登录用户上报的崩溃数据包或崩溃状态信息，能够及时的获取到基于崩溃状态信息和/或该次崩溃分析结果的预警告示，实现实时化、个性化的预警。

根据上述实施例提供的系统，在第一接口接收到浏览器崩溃时上传的浏览器崩溃状态信息之后，第一云崩溃服务器根据该浏览器崩溃状态信息生成指示是否允许浏览器上传崩溃数据包的崩溃标识信息，并通过第一接口反馈给浏览器，以供浏览器根据崩溃标识信息确定是否得到上传崩溃数据包的允许。在得到允许的情况下，浏览器上传崩溃数据包，云端通过第二接口接收该崩溃数据包，分析设备启动自动分析程序对崩溃数据包进行分析，并由下发设备将分析结果数据下发给浏览器。该系统提供了一种云系统级的方案，能够有针对性地对浏览器的崩溃信息进行收集、处理、分析以及鉴定。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例的浏览器崩溃信息的处理系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (35)

1.一种浏览器崩溃信息的处理方法，包括：

接收浏览器崩溃时上传的浏览器崩溃状态信息；

根据所述浏览器崩溃状态信息生成指示是否允许浏览器上传崩溃数据包的崩溃标识信息；

反馈所述崩溃标识信息到所述浏览器；

在所述崩溃标识信息表明允许浏览器上传崩溃数据包的情况下，接收所述浏览器上传的包括崩溃数据包的崩溃信息；

启动崩溃数据包自动分析程序，对所述崩溃数据包进行分析；

将所述崩溃数据包的分析结果数据下发到所述上传崩溃数据包的浏览器。

2.根据权利要求1所述的方法，所述接收浏览器崩溃时上传的浏览器崩溃状态信息的步骤进一步为：使用Get接口接收浏览器崩溃时上传的浏览器崩溃状态信息。

3.根据权利要求1所述的方法，所述接收所述浏览器上传的包括崩溃数据包的崩溃信息的步骤进一步为：使用Post接口接收所述浏览器上传的包括崩溃数据包的崩溃信息。

4.根据权利要求1至3任一项所述的方法，所述浏览器崩溃状态信息至少包括如下信息中的一种或多种：浏览器崩溃公共参数信息、命令行、浏览器产品名称以及第一浏览器侧数据校验信息，其中所述第一浏览器侧数据校验信息是所述浏览器根据所述浏览器崩溃公共参数信息和预设密钥生成的。

5.根据权利要求4所述的方法，所述浏览器崩溃公共参数信息至少包括如下信息：崩溃模块的相关信息、具体崩溃偏移、崩溃堆栈、浏览器版本号以及操作系统版本号。

6.根据权利要求4或5所述的方法，所述根据所述浏览器崩溃状态信息生成指示是否允许浏览器上传崩溃数据包的崩溃标识信息进一步包括：

按照预设算法对所述浏览器崩溃公共参数信息进行处理，生成崩溃键值；

根据所述崩溃键值，得到所述指示是否允许浏览器上传崩溃数据包的崩溃标识信息。

7.根据权利要求6所述的方法，在所述按照预设算法对所述浏览器崩溃公共参数信息进行处理，生成崩溃键值的步骤之前还包括：通过验证所述第一浏览器侧数据校验信息是否正确来对所述崩溃状态信息的合法性和完整性进行校验。

8.根据权利要求6所述的方法，在所述按照预设算法对所述浏览器崩溃公共参数信息进行处理，生成崩溃键值的步骤之前还包括：通过效验浏览器产品名称来对浏览器产品的合法性进行校验。

9.根据权利要求1所述的方法，所述接收浏览器崩溃时上传的浏览器崩溃状态信息的步骤之后还包括：丢弃在预先定义的时间段内从相同地址的浏览器再次接收到的浏览器崩溃状态信息。

10.根据权利要求1所述的方法，在所述反馈崩溃标识信息到浏览器的同时，反馈第一服务器侧数据校验信息到所述浏览器，以供所述浏览器通过验证所述第一服务器侧数据校验信息来对崩溃标识信息的合法性和完整性进行校验；所述第一服务器侧数据校验信息是根据所述崩溃标识信息和预设密钥而生成的。

11.根据权利要求1所述的方法，在所述接收浏览器上传的包括崩溃数据包的崩溃信息的步骤之后还包括：将所述崩溃数据包存入队列中；读取所述队列，将来自不同浏览器产品的崩溃数据包分送给不同的分析设备；

所述启动崩溃数据包自动分析程序，对所述崩溃数据包进行分析具体为：不同的分析设备启动各自的崩溃数据包自动分析程序，对所述崩溃数据包进行分析。

12.根据权利要求11所述的方法，所述崩溃信息还包括第二浏览器侧数据校验信息；所述第二浏览器侧数据校验码是根据所述崩溃数据包、崩溃标识信息和预设密钥而生成的；

在所述将崩溃数据包存入队列中的步骤之前还包括：通过验证所述第二浏览器侧数据校验信息是否正确来对所述崩溃信息的合法性和完整性进行校验。

13.根据权利要求11所述的方法，所述崩溃信息还包括：浏览器产品名称；在所述将崩溃数据包存入队列中的步骤之前还包括：通过效验浏览器产品名称来对浏览器产品的合法性进行校验。

14.根据权利要求1所述的方法，所述启动崩溃数据包自动分析程序，对所述崩溃数据包进行分析的步骤进一步包括：

通过部署的自动崩溃数据包分析程序，随时监控浏览器上传的崩溃数据包，一旦发现有新的崩溃数据包，立即进行分析，并及时返回分析结果数据；

或者，调用自动化分析接口对浏览器上传的崩溃数据包进行分析。

15.根据权利要求1所述的方法，还包括：按照预设时间间隔，以增量索引的方式将所述崩溃数据包的分析结果数据存储在数据库中。

16.根据权利要求15所述的方法，还包括：对所述数据库中存储的数据进行统计，如果统计结果超出预设阀值则进行报警。

17.根据权利要求1所述的方法，所述将崩溃数据包的分析结果数据下发到所述上传崩溃数据包的浏览器的步骤进一步包括：根据所述崩溃数据包的分析结果数据所对应的浏览器的机器标识或浏览器用户的标识，将所述崩溃数据包的分析结果数据下发到对应的浏览器。

18.一种浏览器崩溃信息的处理系统，包括：

第一接口，用于接收浏览器崩溃时上传的浏览器崩溃状态信息；

第一云崩溃服务器，用于根据所述浏览器崩溃状态信息生成指示是否允许浏览器上传崩溃数据包的崩溃标识信息，通过所述第一接口反馈所述崩溃标识信息到所述浏览器；

第二接口，用于在所述崩溃标识信息表明允许浏览器上传崩溃数据包的情况下，接收所述浏览器上传的包括崩溃数据包的崩溃信息；

分析设备，用于启动崩溃数据包自动分析程序，对所述崩溃数据包进行分析；

下发设备，用于通过所述第二接口将所述崩溃数据包的分析结果数据下发到所述上传崩溃数据包的浏览器。

19.根据权利要求18所述的系统，所述第一接口为Get接口。

20.根据权利要求18所述的系统，所述第二接口为Post接口。

21.根据权利要求18至20任一项所述的系统，所述浏览器崩溃状态信息至少包括如下信息中的一种或多种：浏览器崩溃公共参数信息、命令行、浏览器产品名称以及第一浏览器侧数据校验信息，其中所述第一浏览器侧数据校验信息是所述浏览器根据所述浏览器崩溃公共参数信息和预设密钥生成的。

22.根据权利要求21所述的系统，所述浏览器崩溃公共参数信息至少包括如下信息：崩溃模块的相关信息、具体崩溃偏移、崩溃堆栈、浏览器版本号以及操作系统版本号。

23.根据权利要求21或22所述的系统，还包括：第一缓存服务器，用于按照预设算法对所述浏览器崩溃公共参数信息进行处理，生成崩溃键值；

所述第一云崩溃服务器具体用于根据所述崩溃键值，得到所述指示是否允许浏览器上传崩溃数据包的崩溃标识信息。

24.根据权利要求23所述的系统，还包括：第一校验模块，用于通过验证所述第一浏览器侧数据校验信息是否正确来对所述崩溃状态信息的合法性和完整性进行校验。

25.根据权利要求23所述的系统，还包括：第一验证模块，用于通过效验浏览器产品名称来对浏览器产品的合法性进行校验。

26.根据权利要求18所述的系统，还包括：第二缓存服务器，用于丢弃在预先定义的时间段内从相同地址的浏览器再次接收到的浏览器崩溃状态信息。

27.根据权利要求18所述的系统，所述第一云崩溃服务器还用于根据所述崩溃标识信息和预设密钥生成第一服务器侧数据校验信息，并在反馈崩溃标识信息到浏览器的同时，反馈第一服务器侧数据校验信息到所述浏览器，以供所述浏览器通过验证所述第一服务器侧数据校验信息来对崩溃标识信息的合法性和完整性进行校验。

28.根据权利要求18所述的系统，还包括：

数据库；

数据队列服务器，用于将崩溃状态信息放入队列，启动进程将队列中的崩溃状态信息存入到所述数据库中。

29.根据权利要求18所述的系统，还包括：

第二云崩溃服务器，用于从崩溃信息中提取出崩溃数据包，将所述崩溃数据包存入队列中；以及，读取所述队列，将来自不同浏览器产品的崩溃数据包分送给不同的所述分析设备；

持久化存储器，用于存储所述崩溃数据包。

30.根据权利要求29所述的系统，所述崩溃信息还包括第二浏览器侧数据校验信息；所述第二浏览器侧数据校验码是根据所述崩溃数据包、崩溃标识信息和预设密钥而生成的；

所述系统还包括：第二校验模块，用于通过验证所述第二浏览器侧数据校验信息是否正确来对所述崩溃信息的合法性和完整性进行校验。

31.根据权利要求29所述的系统，所述崩溃信息还包括浏览器产品名称；

所述系统还包括：第二验证模块，用于通过效验浏览器产品名称来对浏览器产品的合法性进行校验。

32.根据权利要求18所述的系统，所述分析设备进一步用于：

通过部署的自动崩溃数据包分析程序，随时监控浏览器上传的崩溃数据包，一旦发现有新的崩溃数据包，立即进行分析，并及时返回分析结果数据；

或者，调用自动化分析接口对浏览器上传的崩溃数据包进行分析。

33.根据权利要求18所述的系统，还包括：

数据库；

第三云崩溃服务器，用于将分析设备分析得到的数据传输给索引服务器；

索引服务器，用于按照预设时间间隔，以增量索引的方式将所述崩溃数据包的分析结果数据存储在数据库中。

34.根据权利要求33所述的系统，还包括：预警设备，用于对所述数据库中存储的数据进行统计，如果统计结果超出预设阀值则进行报警。

35.根据权利要求18所述的系统，所述下发设备进一步用于根据所述崩溃数据包的分析结果数据所对应的浏览器的机器标识或浏览器用户的标识，将所述崩溃数据包的分析结果数据下发到对应的浏览器。

Images