故障定位方法、日志格式的配置方法、设备及存储介质

技术领域

本发明涉及通信技术领域，尤其涉及一种故障定位方法、日志格式的配置方法、设备及存储介质。

背景技术

随着网络技术的飞速发展，应用程序的适用范围越来越广泛。在用户使用应用程序或者应用平台时，有可能会遇到无法解决的问题或者故障，此时，用户可以通过预设控制平台、预设沟通方式进行问题咨询或者故障上报操作。但是，在进行问题咨询或者故障上报的过程中，用户往往因为专业名词表述不同或者因使用环境比较复杂，不能准确描述遇到的问题，从而导致问题排查比较困难。

发明内容

本发明实施例提供了一种故障定位方法、日志格式的配置方法、设备及存储介质，在用户在提工单时，无需进行大量不准确的问题描述操作，从而避免了因文字表达不清而导致故障定位困难的问题，这样不仅可以减少故障排查过程中的沟通成本，并且还可以提高故障排查效率。

第一方面，本发明实施例提供故障定位方法，包括：

接收用户端所发送的数据上报请求；

确定与所述数据上报请求相对应的数据定位标识；

获取所述用户端所产生的与所述数据定位标识相对应的用户数据，所述用户数据包括：用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志；

基于所述用户数据进行故障定位操作。

第二方面，本发明实施例提供一种故障定位装置，包括：

第一接收模块，用于接收用户端所发送的数据上报请求；

第一确定模块，用于确定与所述数据上报请求相对应的数据定位标识；

第一获取模块，用于获取所述用户端所产生的与所述数据定位标识相对应的用户数据，所述用户数据包括：用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志；

第一处理模块，用于基于所述用户数据进行故障定位操作。

第三方面，本发明实施例提供一种电子设备，包括：存储器、处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行时实现上述第一方面中的故障定位方法。

第四方面，本发明实施例提供了一种计算机存储介质，用于储存计算机程序，所述计算机程序使计算机执行时实现上述第一方面中的故障定位方法。

第五方面，本发明实施例提供了一种计算机程序产品，包括：存储有计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行上述第一方面所示的故障定位方法中的步骤。

第六方面，本发明实施例提供了一种故障定位方法，包括：

获取数据上报请求，所述数据上报请求用于进行故障定位操作；

确定与所述数据上报请求相对应的预置日志格式；

基于所述预置日志格式，生成上报数据，所述上报数据包括用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志；

对所述上报数据进行上报，以基于所述上报数据进行故障定位操作。

第七方面，本发明实施例提供了一种故障定位装置，包括：

第二获取模块，用于获取数据上报请求，所述数据上报请求用于进行故障定位操作；

第二确定模块，用于确定与所述数据上报请求相对应的预置日志格式；

第二生成模块，用于基于所述预置日志格式，生成上报数据，所述上报数据包括用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志；

第二处理模块，用于对所述上报数据进行上报，以基于所述上报数据进行故障定位操作。

第八方面，本发明实施例提供一种电子设备，包括：存储器、处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行时实现上述第六方面中的故障定位方法。

第九方面，本发明实施例提供了一种计算机存储介质，用于储存计算机程序，所述计算机程序使计算机执行时实现上述第六方面中的故障定位方法。

第十方面，本发明实施例提供了一种计算机程序产品，包括：存储有计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行上述第六方面所示的故障定位方法中的步骤。

第十一方面，本发明实施例提供一种故障定位方法，包括：

获取用于进行故障定位操作的上报数据，所述上报数据包括用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志；

判断对所述上报数据进行日志排查操作能否定位故障信息；

若不能定位故障信息，则基于所述上报数据进行场景还原，以进行故障定位操作。

第十二方面，本发明实施例提供一种故障定位装置，包括：

第三获取模块，用于获取用于进行故障定位操作的上报数据，所述上报数据包括用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志；

第三判断模块，用于判断对所述上报数据进行日志排查操作能否定位故障信息；

第三处理模块，用于若不能定位故障信息，则基于所述上报数据进行场景还原，以进行故障定位操作。

第十三方面，本发明实施例提供一种电子设备，包括：存储器、处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行时实现上述第十一方面中的故障定位方法。

第十四方面，本发明实施例提供了一种计算机存储介质，用于储存计算机程序，所述计算机程序使计算机执行时实现上述第十一方面中的故障定位方法。

第十五方面，本发明实施例提供了一种计算机程序产品，包括：存储有计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行上述第十一方面所示的故障定位方法中的步骤。

第十六方面，本发明实施例提供了一种日志格式的配置方法，包括：

获取用户端所能够运行的场景信息以及与所述场景信息相对应的日志配置信息；

基于所述日志配置信息，生成与所述场景信息相对应的预置日志格式，所述预置日志格式用于获取所述用户端的至少部分日志数据。

第十七方面，本发明实施例提供了一种日志格式的配置装置，包括：

第四获取模块，用于获取用户端所能够运行的场景信息以及与所述场景信息相对应的日志配置信息；

第四处理模块，用于基于所述日志配置信息，生成与所述场景信息相对应的预置日志格式，所述预置日志格式用于获取所述用户端的至少部分日志数据。

第十八方面，本发明实施例提供一种电子设备，包括：存储器、处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行时实现上述第十六方面中的日志格式的配置方法。

第十九方面，本发明实施例提供了一种计算机存储介质，用于储存计算机程序，所述计算机程序使计算机执行时实现上述第十六方面中的日志格式的配置方法。

第二十方面，本发明实施例提供了一种计算机程序产品，包括：存储有计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行上述第十六方面所示的日志格式的配置方法中的步骤。

本实施例提供的技术方案，通过接收用户端所发送的数据上报请求，确定与数据上报请求相对应的数据定位标识，而后获取用户端所产生的与数据定位标识相对应的用户数据，由于用户数据包括用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志，从而有效地实现了可以快速获取到用户端所对应的日志运行数据，而后可以通过所获得的用户数据进行故障定位操作，这样不仅可以减少故障排查过程中的沟通成本，提高故障排查效率；同时，在用户在提工单时，无需进行大量不准确的问题描述操作，从而有效地避免了因文字表达不清而导致故障定位操作困难的问题，进一步提高了故障定位操作的质量和效率，保证了该方法的实用性，有利于市场的推广与应用。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种故障定位方法的原理示意图；

图2为本发明实施例提供的一种故障定位方法的流程示意图；

图3为本发明实施例提供的基于所述用户数据进行故障定位操作的流程示意图；

图4为本发明实施例提供的获取所述用户端所产生的与所述数据定位标识相对应的用户数据的流程示意图；

图5为本发明应用实施例提供的用户执行故障定位方法的流程示意图；

图6为本发明应用实施例提供的研发人员执行故障定位方法的流程示意图；

图7为本发明应用实施例提供的故障定位方法的原理示意图；

图8为本发明实施例提供的另一种故障定位方法的流程示意图；

图9为本发明实施例提供的又一种故障定位方法的流程示意图；

图10为本发明实施例提供的又一种故障定位方法的流程示意图；

图11为本发明实施例提供的另一种故障定位方法的流程示意图；

图12为本发明实施例提供的又一种故障定位方法的流程示意图；

图13为本发明实施例提供的还一种故障定位方法的流程示意图；

图14为本发明应用实施例提供的用户执行故障定位方法的流程示意图；

图15为本发明应用实施例提供的研发人员执行故障定位方法的流程示意图；

图16为本发明应用实施例提供的故障定位方法的原理示意图；

图17为本发明实施例提供的一种日志格式的配置方法的流程示意图；

图18为本发明实施例提供的一种故障定位装置的结构示意图；

图19为与图18所示实施例提供的故障定位装置对应的电子设备的结构示意图；

图20为本发明实施例提供的另一种故障定位装置的结构示意图；

图21为与图20所示实施例提供的故障定位装置对应的电子设备的结构示意图；

图22为本发明实施例提供的又一种故障定位装置的结构示意图；

图23为与图22所示实施例提供的故障定位装置对应的电子设备的结构示意图；

图24为本发明实施例提供的一种日志格式的配置装置的结构示意图；

图25为与图24所示实施例提供的日志格式的配置装置对应的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义，“多种”一般包含至少两种，但是不排除包含至少一种的情况。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

取决于语境，如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。

另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

术语解释：

预置数据：提前设计排查问题需要的数据，以脚本形式携带在用户端，可用于数据上报。

用户提单：在用户使用控制台遇到问题时，可以通过工单平台、预设沟通软件等方式提出咨询或者进行故障上报操作。

下面结合附图，对本发明的一些实施方式作详细说明。在各实施例之间不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

图1为本发明实施例提供的一种故障定位方法的原理示意图；图2为本发明实施例提供的一种故障定位方法的流程示意图；参考附图1-图2所示，本实施例提供了一种故障定位方法，该方法的执行主体为故障定位装置，可以理解的是，该故障定位装置可以实现为软件、或者软件和硬件的组合，具体实现时，该故障定位装置可以实现为一研发人员所对应的终端/服务器。该故障定位方法可以包括：

步骤S201：接收用户端所发送的数据上报请求。

其中，在物理实现上，用户端可以是任何能够提供计算服务，并进行数据处理方法的设备，例如，手机、平板电脑、个人电脑、设定应用程序等等。在用户使用用户端时，用户端可能会出现故障，例如：无法实现正常的网页访问操作或者无法执行某一数据处理操作等等。在用户端出现故障时，用户可以通过预设平台或者预设沟通软件来进行故障上报操作或者问题咨询操作，此时，用户端可以生成一数据上报请求，该数据上报请求中可以包括与用户端相对应的用户身份标识、数据定位标识等等，而后用户端可以将所生成的数据上报请求发送至故障定位装置，从而使得故障定位装置可以接收到用户端所发送的数据上报请求。

步骤S202：确定与数据上报请求相对应的数据定位标识。

在获取到数据上报请求之后，可以对数据上报请求进行分析处理，以确定与数据上报请求相对应的数据定位标识，该数据定位标识用于获取进行故障分析操作的用户数据，其中，数据定位标识可以为用户端出现故障时所对应的数据时间段，数据时间段可以为5min、10min、15min或者20min等等。

具体的，在数据上报请求中包括数据定位标识时，在获取到数据上报请求之后，可以对数据上报请求进行数据提取操作，从而直接获得数据定位标识。或者，在数据上报请求中不包括数据定位标识时，在获取到数据上报请求之后，可以基于数据上报请求获取用户针对数据定位标识输入的执行操作，基于执行操作获取数据定位标识。

步骤S203：获取用户端所产生的与数据定位标识相对应的用户数据，用户数据包括：用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志。

在用户使用用户端时，用户端可以产生成千上万的数据，并且，在不同的运行环境中可以生成不同的数据。例如：用户端上配置有浏览器应用程序、电商交易平台、即时聊天应用程序，那么，用户在使用浏览器应用程序可以产生浏览器数据，在用户使用电商交易平台可以产生电商交易数据，在用户使用即时聊天应用程序可以生成即时聊天数据，可以理解的是，上述的浏览器数据、电商交易数据和即时聊天数据各不相同，并且以上的浏览器数据、电商交易数据和即时聊天数据均为用户数据。

在用户端出现故障时，为了能够使得研发人员快速、准确地进行故障定位操作，在获取到数据定位标识之后，可以获取用户端所产生的与数据定位标识相对应的用户数据，其中，与数据定位标识相对应的用户数据可以为用户端所产生的所有用户数据中的一部分。具体的，用户数据可以包括：用户侧账户信息(例如：用户侧账号名称信息、用户侧账号ID信息等等)、用户侧配置信息(例如：操作配置信息、界面配置信息等等)、用户侧运行环境(例如：浏览器环境、及时聊天应用程序的环境)、应用程序接口API调用日志、用户操作日志(可以包括：用户在操作界面输入的点击操作、用户对文件的增、删、查、改操作等等)。

需要说明的是，用户数据不仅可以包括上述所描述的信息，还可以包括其他数据，例如：历史故障信息、用户端运行状态等等，本领域技术人员可以根据具体的应用需求对用户数据进行配置，在此不再赘述。

步骤S204：基于用户数据进行故障定位操作。

在获取到用户数据之后，可以对用户数据进行分析处理，以实现故障定位操作。在一些实例中，基于用户数据进行故障定位操作可以包括：获取预先训练的神经网络模型，神经网络模型被训练为用于基于用户数据进行故障定位操作；将用户数据输入至神经网络模型中，可以获得神经网络模型所输出的故障定位结果，从而实现了故障定位操作。

在另一些实例中，在获取到用户数据之后，为了能够保证数据处理的安全可靠性，可以识别用户数据中是否存在机密数据，具体的，可以获取用户数据的数据安全等级，在数据安全等级大于或等于预设等级是，则确定与数据安全等级相对应的用户数据为机密数据，否则为非机密数据。或者，可以获取用户数据的数据属性，而后将数据属性与预设的标准机密数据所对应的数据进行分析比较，若存在与数据属性相对应的标准机密数据，则将数据属性所对应的用户数据确定为机密数据，否则为非机密数据。

若用户数据中不存在机密数据，则可以直接基于用户数据进行故障定位操作；若用户数据中存在机密数据，则可以对用户数据中所包括的机密数据进行混淆处理，获得混淆后用户数据，而后基于混淆后用户数据进行故障定位操作，这样不仅可以提高用户数据的安全程度，并且还可以有效地避免用户数据出现非法泄露的情况。

本实施例提供的故障定位方法，通过接收用户端所发送的数据上报请求，确定与数据上报请求相对应的数据定位标识，而后获取用户端所产生的与数据定位标识相对应的用户数据，由于用户数据包括用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志，从而有效地实现了可以快速获取到用户端所对应的日志运行数据，而后可以通过所获得的用户数据进行故障定位操作，这样不仅可以减少故障排查过程中的沟通成本，提高故障排查效率；同时，在用户在提工单时，无需进行大量不准确的问题描述操作，从而有效地避免了因文字表达不清而导致故障定位操作困难的问题，进一步提高了故障定位操作的质量和效率，保证了该方法的实用性，有利于市场的推广与应用。

图3为本发明实施例提供的基于用户数据进行故障定位操作的流程示意图；参考附图3所示，本实施例提供了一种基于用户数据进行故障定位操作的实现方式，具体的，本实施例中的基于用户数据进行故障定位操作可以包括：

步骤S301：判断对用户数据进行日志排查操作能否定位故障信息。

步骤S302：若能够定位故障信息，则获得与用户数据相对应的故障信息。

步骤S303：若不能定位故障信息，则基于用户数据进行场景还原，以进行故障定位操作。

对于用户端而言，所生成的故障大致可以分为两种：比较简单的故障、比较复杂的故障，在用户端发生比较简单的故障时，通过对用户数据进行简单的日志排查操作即可大概率的定位故障信息，日志排查操作可以简单理解为对所获得的用户数据逐一进行字符、数据、界面检查操作，检查操作可以为人工检查操作或者机器检查操作。在用户端发生比较复杂的故障时，通过对用户数据进行日志排查操作大概率无法定位故障信息，此时，则需要基于用户数据进行场景还原操作。

基于用户端所发生不同类型的故障对应有不同的故障排查方式，而且对用户数据进行日志排查操作所需要的数据资源比较少，操作简单且比较容易实现，若能够直接定位故障信息，则可以极大地提高了对故障信息进行定位操作的质量和效率。因此，在基于用户数据进行故障定位操作时，可以先判断对用户数据进行日志排查操作能否定位故障信息，即先对用户数据进行日志排查操作，检测能否定位故障信息，若能够定位故障信息，则可以直接获取到与用户数据相对应的故障信息。若不能定位故障信息，为了能够实现故障定位操作，则可以基于用户数据进行场景还原操作。

具体的，在需要基于用户数据进行场景还原操作时，本实施例对于基于用户数据进行场景还原操作的实现方式不做限定，在一些实例中，预先训练有用于实现场景还原操作的机器学习模型，在获取到用户数据之后，可以将用户数据输入至机器学习模型实现场景还原操作，以实现故障定位操作。

在另一些实例中，本实施例中的基于用户数据进行场景还原可以包括：建立与用户侧运行环境相同的模拟运行环境；在模拟运行环境中，基于用户侧账号信息和用户侧配置信息，生成与用户数据相对应的界面信息；在界面信息中，基于API调用日志和用户操作日志进行场景还原。

由于用户数据可以包括：用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志，为了能够实现场景还原操作，可以先建立与用户侧运行环境相同的模拟运行环境，而后在模拟运行环境中，基于用户侧账号信息和用户侧配置信息生成与用户数据相对应的界面信息，该界面信息与用户在使用用户端时的界面相同。在生成界面信息之后，在界面信息中可以基于API调用日志和用户操作日志进行场景还原操作，从而使得研发人员可以直观地查看到在用户端发生故障的特定时间段内用户的所有操作行为，这样有利于提高故障定位操作的质量和效率。

本实施例中，通过判断对用户数据进行日志排查操作能否定位故障信息，若能够定位故障信息，则获得与用户数据相对应的故障信息；若不能定位故障信息，则基于用户数据进行场景还原，从而有效地实现了可以基于不同的实现方式对用户数据进行分析处理，实现故障定位操作，这样不仅提高了该故障定位方法使用的灵活可靠性，还能够提高故障排查操作的质量和效率。

图4为本发明实施例提供的获取用户端所产生的与数据定位标识相对应的用户数据的流程示意图；参考附图4所示，在进行故障定位操作的过程中，本实施例提供了一种对与数据定位标识相对应的用户数据进行获取的实现方式，具体的，本实施例中的获取用户端所产生的与数据定位标识相对应的用户数据可以包括：

步骤S401：获取用户端所产生的用户侧实时数据。

在用户端与故障定位装置进行通信连接之后，为了能够减少用户所需要执行的操作，故障定位装置可以实时地采集用户端生成的所有数据，即故障定位装置可以获取到用户端所产生的用户侧实时数据，并可以将用户侧实时数据存储在预设区域。

在一些实例中，获取用户端所产生的用户侧实时数据可以包括：获取与用户端相对应的预置日志格式；基于预置日志格式对用户端所生成的数据进行实时采集，获得用户侧实时数据。

其中，预置日志格式用于限定所获得的用户侧实时数据所包括的数据类型，例如：预置日志格式至少包括：用于获取用户侧账户信息的日志格式、用于获取用户侧配置信息的日志格式、用于获取用户侧运行环境的日志格式、用于获取API调用行为的日志格式、用于获取用户操作行为的日志格式等等。由于在用户端处于不同的运行环境时，所需要获得的用户侧实时数据不同，因此，为了能够获取用户端所产生的用户侧实时数据，可以先获取与用户端相对应的预置日志格式，在一些实例中，故障定位装置中可以配置有多个预置日志格式，在用户端与故障定位装置进行通信连接之后，可以确定与用户端相对应的预置日志格式，与用户端相对应的预置日志格式可以是预先配置的多个预置日志格式中的任意一个，并且，不同的用户端可以对应有相同或者不同的预置日志格式。

在另一些实例中，获取与用户端相对应的预置日志格式可以包括：获取与用户端相对应的场景信息；基于场景信息，确定与用户端相对应的预置日志格式。

由于用户端可以基于用户的使用需求或者设计需求运行在不同的场景信息中，而不同的场景信息可以对应有不同的预置日志格式，因此，为了能够准确地获取与用户端相对应的预置日志格式，则可以先获取与用户端相对应的场景信息，具体的，场景信息可以通过对数据上报请求进行分析处理进行获取的，其中，数据上报请求中包括场景标识，通过数据上报请求中的场景标识可以确定场景信息。或者，在获取到数据上报请求之后，可以获取与数据上报请求相对应的场景数据，基于场景数据来确定与用户端相对应的场景信息。

在获取到场景信息之后，可以对场景信息进行分析处理，以确定与用户端相对应的预置日志格式，具体的，预先配置有不同场景信息与各自对应的预置日志格式之间的映射关系，基于场景信息和上述映射关系即可确定与用户端相对应的预置日志格式。

在获取到预置日志格式之后，可以基于预置日志格式对用户端所生成的数据进行实时采集，从而可以获得与用户端和场景信息相对应的用户侧实时数据，需要注意的是，不同的用户端所生成的用户侧实时数据不同，不同的场景信息所对应的用户侧实时数据不同。

步骤S402：基于数据定位标识，确定与数据上报请求相对应的数据标识时间段。

由于用户侧实时数据的数据量较大，而进行故障排查操作所需要的数据仅需要用户端出现异常操作时段所对应的数据即可，因此，为了能够提高故障定位的质量和效率，在确定与数据上报请求相对应的数据定位标识之后，可以对数据定位标识进行分析处理，以确定与数据上报请求相对应的数据标识时间段，当数据标识时间段包含在数据上报请求中时，可以通过对数据上报请求进行信息提取操作，从而获得数据标识时间段；或者，在数据上报请求与数据标识时间段之间存在映射关系时，则可以通过映射关系来确定数据标识时间段。

另外，数据标识时间段的长短可以基于用户端所出现的故障类型、应用场景而有所不同，具体的，在用户端的故障类型较为复杂时，则时间段可以优选为比较长的时间段；在用户端的应用场景比较典型、简单时，则时间段可以优选为比较短的时间段。

步骤S403：在用户侧实时数据中，获取与数据标识时间段相对应的用户数据。

在获取到数据标识时间段和用户侧实时数据之后，可以在用户侧实时数据中，获取与数据标识时间段相对应的用户数据，其中，用户侧实时数据中的各个数据对应有时间标识，从而可以有效地保证用户数据获取的准确可靠性。

本实施例中，通过获取用户端所产生的用户侧实时数据，基于数据定位标识确定与数据上报请求相对应的数据标识时间段，而后在用户侧实时数据中获取与数据标识时间段相对应的用户数据，有效地保证了对用户数据进行获取的准确可靠性，并且由于进行故障定位操作的用户数据的数据量相对较少，进而提高了故障定位的质量和效率。

具体应用时，本应用实施例提供了一种故障定位方法，该故障定位方法的执行主体可以包括用户所对应的用户端以及研发人员相对应的故障定位装置，其中，用户端与故障定位装置通信连接。参考附图5所示，在用户通过用户端执行上述故障定位方法时，包括以下步骤：

步骤1：用户在用户端上的操作遇到故障/问题。

步骤2：基于所遇到的故障/问题触发故障工单的提交操作。

步骤3：在提交工单数据时，可以根据预设工单中的问题模板描述问题。

具体的，在用户进入提单页面之后，可以立刻触发故障工单的上报操作，之后可以根据提单模板提供一些日志分析的必要信息，提单模板一般可以包括：用户账号、发生问题时段等信息。

步骤4：在填写完工单数据之后，可以将所填写的工单数据提交至故障定位装置，以使研发人员可以基于工单数据进行故障定位操作。

参考附图6-图7所示，在研发人员(开发者)通过故障定位装置(即平台侧)执行上述故障定位方法时，包括以下步骤：

步骤11：接收用户端所发送的工单数据。

其中，故障定位装置中包括日志存储系统和工单系统，在故障定位装置接收到用户端所发送的工单数据之前，故障定位装置可以与用户端通信连接，此时，故障定位装置可以基于用户端的应用环境进行预置日志格式的配置操作，具体的，故障定位装置中可以包括有多个预置日志格式，基于用户端的应用环境配置相对应的预置日志格式，而后将预置日志格式发送至用户端，或者用户端主动拉取所配置的预置日志格式，需要注意的是，在用户端在进入特定页面时，就会主动拉取并应用预置日志格式。

在用户端获取到预置日志格式之后，可以基于预置日志格式记录日志信息，日志信息包括但不限于：用户账号信息、用户侧基础配置信息、前端加载资源记录、API调用日志、用户操作日志等等。在用户端记录日志信息之后，故障定位装置可以实时或者实时地获取用户端所记录的日志信息，此时，上报至故障定位装置的日志数据量比较大，故障定位装置可以将日志信息存储在日志存储系统中。

步骤12：根据工单数据中所包括的问题模板触发自动诊断任务，还原用户行为。

在工单系统接收到用户端所发送的工单数据之后，可以根据用户提单模板在所存储的日志信息中拉取对应的日志数据，即可以基于用户端出现故障时所对应的应用场景时间等特征对日志数据进行筛选操作，获得用于进行故障定位操作的目标日志信息。

步骤13：基于自动诊断结果快速定位问题。

基于目标日志信息进行故障定位操作，以实现故障的快速定位，具体的，当用户侧提单成功之后，工单流程到平台侧的研发人员处，故障定位装置(即平台侧)可以基于所获得的目标日志信息进行故障定位操作，首先可以先在平台侧启动一个本地容器，该容器可以根据用户账号和发生问题时段，自动拉取该时段所对应的目标日志信息，由于目标日志信息的数据量巨大，为了能够快速甄别用户的故障问题，平台侧可以先利用智能算法快速提取异常日志并进行智能诊断，智能算法可以是基于规则匹配模式或者自主学习形式所实现的。

若利用智能算法不能定位故障信息，则可以基于目标日志信息进行场景还原操作，具体的，可以先建立与用户侧运行环境相同的模拟运行环境；而后在模拟运行环境中，基于用户侧账号信息和用户侧配置信息，生成与用户数据相对应的界面信息；在界面信息中，基于API调用日志和用户操作日志进行场景还原，以进行故障定位操作。具体的，在进行场景还原操作时，可以分析出问题时间段内共用多少js报错日志、多少API报错日志，以一个js报错日志为例，拉取用户js报错日志发生前后的用户点击行为和API请求，注入到用户场景还原容器中，可以快速复现js报错问题，并给出js报错原因。

步骤14：解决所定位的故障/问题，以保证用户端的正常操作。

在确定故障信息之后，可以利用预设运维方式解决故障，以使得用户端可以进行正常的数据处理操作，从而实现了可以快速地定位、并解决用户端所出现的故障，提高了对用户端的良好体验。

本应用实施例提供的技术方案，由开发者提供故障上报脚本工具，在故障定位装置和用户端的操作界面中注入，在故障定位装置与用户端进行通信连接之后，若用户端进入到预设应用或者预设界面时，可以根据预置日志格式记录用户当前操作的相关日志，该日志可以直接上传到故障定位装置，以使得故障定位装置可以基于所上传的日志进行故障定位操作，从而有效地实现了在用户提工单时，无需再进行大量不准确的问题描述，避免文字表达不清的问题，另外，由于能够快速获取用户侧所有相关运行日志，从而可以快速还原用户场景，减少问题排查过程中沟通成本，提高排查效率，进一步提高了该方法的实用性。

图8为本发明实施例提供的另一种故障定位方法的流程示意图；参考附图8所示，本实施例提供了另一种故障定位方法，该方法的执行主体为故障定位装置，可以理解的是，该故障定位装置可以实现为软件、或者软件和硬件的组合，具体实现时，该故障定位装置可以实现为一用户端。在物理实现上，用户端可以是任何能够提供计算服务，并进行处理的设备，例如，手机、平板电脑、个人电脑、设定应用程序等等。具体的，该故障定位方法可以包括：

步骤S801：获取数据上报请求，数据上报请求用于进行故障定位操作。

在用户使用用户端时，可能会出现故障，例如：无法实现正常的网页访问操作或者无法执行某一数据处理操作等等。在用户端出现故障时，用户可以通过预设平台或者预设沟通软件来进行故障上报操作，此时，用户端可以基于用户输入的执行操作生成一用于进行故障定位操作的数据上报请求，该数据上报请求中可以包括与用户端相对应的用户身份标识、数据定位标识等等，而后用户端可以将所生成的数据上报请求发送至故障定位装置，以使得故障定位装置可以接收到用户端所发送的数据上报请求。

步骤S802：确定与数据上报请求相对应的预置日志格式。

由于用户端可以对应有不同的场景信息，而不同的场景信息中所需要生成的用于进行故障定位操作的日志数据不同，因此，为了能够准确地进行故障定位操作，在获取到数据上报请求之后，可以对数据上报请求进行分析处理，以确定与数据上报请求相对应的预置日志格式。需要说明的是，预置日志格式用于限定所获得的用户侧实时数据所包括的数据类型，例如：预置日志格式至少包括：用于获取用户侧账户信息的日志格式、用于获取用户侧配置信息的日志格式、用于获取用户侧运行环境的日志格式、用于获取API调用行为的日志格式、用于获取用户操作行为的日志格式等等。

在一些实例中，平台侧配置有多个预置日志格式，在用户端与平台侧进行通信连接之后，可以基于用户端的类型或者属性信息确定与用户端相对应的预置日志格式，与用户端相对应的预置日志格式可以是预先配置的多个预置日志格式中的任意一个，并且，不同的用户端可以对应有相同或者不同的预置日志格式。

在另一些实例中，预置日志格式可以是基于数据上报请求所对应的场景信息进行确定的，具体的，确定与数据上报请求相对应的预置日志格式包括：获取与数据上报请求相对应的场景信息；基于场景信息，确定与数据上报请求相对应的预置日志格式。

由于用户端可以基于用户的使用需求运行在不同的应用场景中，而不同的应用场景可以对应有不同的预置日志格式，因此，为了能够准确地获取与数据上报请求相对应的预置日志格式，则可以先获取与数据上报请求相对应的场景信息，其中，在数据上报请求中包括场景标识时，通过提取数据上报请求中的场景标识可以确定场景信息。或者，在获取到数据上报请求之后，可以获取与数据上报请求相对应的场景数据，基于场景数据来确定与数据上报请求相对应的场景信息。

在获取到场景信息之后，可以对场景信息进行分析处理，以确定与数据上报请求相对应的预置日志格式，具体的，预先配置有不同场景信息与预置日志格式之间的映射关系，基于场景信息和上述映射关系即可确定与数据上报请求相对应的预置日志格式。

步骤S803：基于预置日志格式，生成上报数据，上报数据包括用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志。

在获取到预置日志格式之后，可以基于预置日志格式进行日志采集操作，从而可以生成上报数据，具体的，上报数据可以包括：用户侧账户信息(例如：用户侧账号名称信息、用户侧账号ID信息等等)、用户侧配置信息(例如：操作配置信息、界面配置信息等等)、用户侧运行环境(例如：浏览器环境、及时聊天应用程序的环境)、应用程序接口API调用日志、用户操作日志(可以包括：用户在操作界面输入的点击操作、用户对文件的增、删、查、改操作等等)。

需要说明的是，上报数据所包括的内容可以基于预置日志格式进行灵活配置，从而使得该故障定位方法可以适用于不同场景，具体的，上报数据不仅可以包括上述所陈述的信息，还可以包括其他数据，例如：历史故障信息、用户端运行状态等等，本领域技术人员可以根据具体的应用需求对上报数据进行配置，在此不再赘述。

步骤S804：对上报数据进行上报，以基于上报数据进行故障定位操作。

在获取到上报数据之后，可以将上报数据上报至平台侧，以使得平台侧可以基于所接收到的上报数据进行故障定位操作，此时，进行故障定位操作的执行主体为平台侧。

在另一些实例中，在获取到上报数据之前，为了能够保证数据使用的安全可靠性，可以识别用户数据中是否存在机密数据(或者敏感数据)，其中，机密数据(或者敏感数据)可以包括：用户账号密码、用户身份信息等等；若用户数据中不存在机密数据，则可以直接基于用户数据进行故障定位操作；若用户数据中存在机密数据，则可以对用户数据中所包括的机密数据进行混淆处理，获得混淆后数据，而后将混淆后数据上报至平台侧，以使得平台侧可以基于混淆后数据进行故障定位操作，这样可以提高用户数据使用的安全程度，并可以有效地避免用户数据出现非法泄露的情况。

本实施例提供的故障定位方法，通过获取数据上报请求，确定与数据上报请求相对应的预置日志格式，而后基于预置日志格式，生成上报数据，从而有效地实现了可以快速获取到用户端中的与故障相关的上报数据，而后可以对上报数据进行上报，以基于上报数据进行故障定位操作，这样不仅可以减少故障排查过程中的沟通成本，提高故障排查效率；同时，在用户在提工单时，无需再次进行大量不准确的问题描述操作，从而有效地避免了因文字表达不清而导致故障定位操作困难的问题；此外，由于本实施例提供了一种可以基于不同场景下的数据上报请求确定不同的预置日志格式，而不同的预置日志格式用于获取不同场景下的不同日志数据，从而有效地解决了现有技术中所存在的“个别用户所出现的问题只能在特定浏览器、特定场景中才能复现，开发人员往往难以复现场景，从而无法进行故障排查操作”的问题，进一步提高了故障定位操作的质量和效率，保证了该方法的实用性，有利于市场的推广与应用。

图9为本发明实施例提供的又一种故障定位方法的流程示意图；参考附图9所示，在确定与数据上报请求相对应的预置日志格式之后，本实施例中的方法还可以包括：

步骤S901：生成与预置日志格式相对应的日志采集提示。

其中，对于用户端而言，所生成的故障大致可以分为：比较简单的故障、比较复杂的故障，在用户端发生比较简单的故障时，则无需日志采集操作，通过简单的故障描述操作就可以进行故障定位操作；在用户端发生比较复杂的故障时，此时，通过简单的故障描述操作可能无法进行故障定位操作，因此为了能够准确地进行故障定位操作，需要进行日志采集操作来获得上报数据，以基于上报数据进行故障定位操作。

由于用户端可能会发生不同类型的故障，因此，在确定与数据上报请求相对应的预置日志格式之后，可以先生成与预置日志格式相对应的日志采集提示，日志采集提示可以通过弹窗形式、对话框的形式在界面中进行显示，该日志采集提示可以用于询问用户是否基于预置日志格式生成上报数据，即是否基于预置日志格式进行日志采集操作。

步骤S902：在获取到与日志采集提示相对应的确认执行信息时，允许基于预置日志格式生成上报数据。

其中，日志采集提示可以为“是否基于预置日志格式进行日志采集操作”，在生成与预置日志格式相对应的日志采集提示之后，用户可以基于日志采集提示输入确认执行信息，例如：日志采集提示中可以包括用于标识确认执行信息的控件“是”和用于标识取消执行操作的控件“否”。当用户针对上述控件“是”输入点击操作时，则获取到与日志采集提示相对应的确认执行信息，此时，则说明需要进行日志采集操作生成上报数据，以基于上报数据进行故障定位操作，进而允许基于预置日志格式生成上报数据。

步骤S903：在获取到日志采集提示相对应的取消执行信息时，禁止基于预置日志格式生成上报数据。

在生成与预置日志格式相对应的日志采集提示之后，当用户针对控件“否”输入点击操作时，则获取到与日志采集提示相对应的取消执行信息，在获取到与日志采集提示相对应的取消执行信息时，则说明此时无需进行日志采集操作即可实现故障定位操作，进而可以禁止基于预置日志格式生成上报数据。

本实施例中，通过生成与预置日志格式相对应的日志采集提示，在获取到与日志采集提示相对应的确认执行信息时，允许基于预置日志格式生成上报数据，在获取到日志采集提示相对应的取消执行信息时，禁止基于预置日志格式生成上报数据，从而有效地实现了可以基于用户端所生成的不同故障类型灵活地选择不同的方式进行故障定位操作，进一步提高了该方法使用的灵活可靠性。

图10为本发明实施例提供的又一种故障定位方法的流程示意图；在上述实施例的基础上，参考附图10所示，为了进一步提高故障定位的质量和效率，本实施例中的方法还可以包括：

步骤S1001：在生成上报数据的过程中，获取与用户操作行为相对应的截图信息和/或录像信息。

步骤S1002：将截图信息和/或录像信息添加至上报数据中。

由于上报数据具有多样性，为了能够使得研发人员更加快速、准确地进行故障定位操作，在生成上报数据的过程中，可以获取与用户操作行为相对应的截图信息和/或录像信息，具体的，在生成上报数据的过程中，可以基于用户输入的执行操作启用屏幕截图操作和/或屏幕录屏操作，这样在显示界面上显示用户的操作行为时，可以获得截图信息和/或录像信息，即获取到用户操作行为的图像信息和/或视频信息，在获取到截图信息和/或录像信息之后，可以将截图信息和/或录像信息添加至上报数据中，这样不仅保证了对上报数据进行获取准确可靠性，而且还使得上报数据具有多样性。

本实施例中，有效地实现了采用截图或者录屏方式结合日志采集操作来生成上报信息，这样使得研发人员可以通过截图信息和/或录像信息直观地获得用户的操作行为，从而便于提高故障定位的质量和效率。

图11为本发明实施例提供的另一种故障定位方法的流程示意图；参考附图11所示，本实施例提供了另一种故障定位方法，该方法的执行主体为故障定位装置，可以理解的是，该故障定位装置可以实现为软件、或者软件和硬件的组合，具体实现时，该故障定位装置可以实现为一研发人员所对应的终端/服务器(平台侧)。具体的，该故障定位方法可以包括：

步骤S1101：获取用于进行故障定位操作的上报数据，上报数据包括用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志。

其中，在用户端生成上报数据，并对上报数据进行上报之后，故障定位装置(平台侧)可以获取到用于进行故障定位操作的上报数据，该上报数据包括：用户侧账户信息(例如：用户侧账号名称信息、用户侧账号ID信息等等)、用户侧配置信息(例如：操作配置信息、界面配置信息等等)、用户侧运行环境(例如：浏览器环境、及时聊天应用程序的环境)、应用程序接口API调用日志、用户操作日志(包括：用户在操作界面输入的点击操作、用户对文件的增、删、查、改操作等等)。

步骤S1102：判断对上报数据进行日志排查操作能否定位故障信息。

步骤S1103：若不能定位故障信息，则基于上报数据进行场景还原，以进行故障定位操作。

在另一些实例中，本实施例中的方法还可以包括：若能够定位故障信息，则获得与上报数据相对应的故障信息。

其中，对于用户端而言，所生成的故障大致可以分为：比较简单的故障、比较复杂的故障，在用户端发生比较简单的故障时，可能通过对用户数据进行日志排查操作即可定位故障信息。在用户端发生比较复杂的故障时，通过对用户数据进行日志排查操作可能无法定位故障信息，此时，则需要基于用户数据进行场景还原操作。

基于用户端可能会发生不同类型的故障，并且由于对用户数据进行日志排查操作的动作比较容易实现、操作简单，若能够直接定位故障信息，则可以极大地提高了对故障信息进行定位操作的质量和效率。因此，在基于用户数据进行故障定位操作时，可以先判断对用户数据进行日志排查操作能否定位故障信息，即先对用户数据进行日志排查操作，检测能否定位故障信息，若能够定位故障信息，则可以直接获取到与用户数据相对应的故障信息。若不能定位故障信息，为了能够实现故障定位操作，则可以基于用户数据进行场景还原操作。

具体的，本实施例对于基于用户数据进行场景还原操作的实现方式不做限定，在一些实例中，预先训练有用于实现场景还原操作的机器学习模型，在获取到用户数据之后，可以将用户数据输入至机器学习模型实现场景还原操作，以实现故障定位操作。

在另一些实例中，本实施例中的基于用户数据进行场景还原可以包括：建立与用户侧运行环境相同的模拟运行环境；在模拟运行环境中，基于用户侧账号信息和用户侧配置信息，生成与用户数据相对应的界面信息；在界面信息中，基于API调用日志和用户操作日志进行场景还原。

由于用户数据可以包括：用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志，为了能够实现场景还原操作，可以先建立与用户侧运行环境相同的模拟运行环境，而后在模拟运行环境中，基于用户侧账号信息和用户侧配置信息生成与用户数据相对应的界面信息，该界面信息与用户在使用用户端时的界面相同。在生成界面信息之后，在界面信息中可以基于API调用日志和用户操作日志进行场景还原操作，从而使得研发人员可以直观地查看并了解到在用户端运行故障的特定时间段内用户的所有操作行为，这样有利于提高故障定位的质量和效率。

本实施例提供的故障定位方法，通过获取用于进行故障定位操作的上报数据，而后判断对用户数据进行日志排查操作能否定位故障信息，若能够定位故障信息，则获得与用户数据相对应的故障信息；若不能定位故障信息，则基于用户数据进行场景还原，从而有效地实现了可以基于不同的实现方式实现故障定位操作，这样不仅提高了该故障定位方法使用的灵活可靠性，还能够提高故障排查的质量和效率，进一步提高了该方法的实用性。

图12为本发明实施例提供的又一种故障定位方法的流程示意图；参考附图12所示，由于用户端可以对应有不同的场景信息，而不同的场景信息可以获取到不同的上报数据，在获取上报数据时，可以通过不同的预置日志格式来获取到上述的上报数据，为了能够实现对用户端各个应用场景的上报数据进行采集操作，本实施例中的方法还可以包括为用户端配置预置日志格式，具体的，本实施例中的方法可以包括：

步骤S1201：获取用户端所能够运行的场景信息以及与场景信息相对应的日志配置信息。

步骤S1202：基于日志配置信息建立与场景信息相对应的预置日志格式，预置日志格式至少用于获取上报数据。

其中，预置日志格式用于限定所获得的用户侧实时数据所包括的数据类型，例如：预置日志格式至少包括：用于获取用户侧账户信息的日志格式、用于获取用户侧配置信息的日志格式、用于获取用户侧运行环境的日志格式、用于获取API调用行为的日志格式、用于获取用户操作行为的日志格式等等。

为了能够为不同的用户端、不同的场景信息配置不同的预置日志格式，可以先获取用户端所能够运行的场景信息，用户端所能够运行的场景信息可以是指研发人员所能预见的用户端能够运行的所有场景信息、用户端所能实际运行的所有场景信息，为了能够覆盖所有场景信息，并对所有应用出纳经进行预置日志格式的配置操作，可以将用户所能够运行的场景信息进行场景分类，以场景类别来进行预置日志格式的配置操作。

此外，为了能够实现预置日志格式的配置操作，还需要获取到与场景信息相对应的日志配置信息，该日志配置信息可以包括用户在配置页面中所输入的执行操作。在获取到日志配置信息和场景信息之后，可以基于日志配置信息建立与场景信息相对应的预置日志格式，该预置日志格式至少用于获取上报数据。

需要注意的是，当故障定位装置连接用户端之后，用户端处于一个新的场景信息，而故障定位装置并未对上述新的场景信息进行预置日志格式的配置操作时，为了能够针对用户端实现故障定位操作，可以将上述的新的场景信息确定预先配置的兜底场景类型，例如“其他场景”，而后可以将上述“其他场景”所对应的预置日志格式确定为上述新的场景信息所对应的预置日志格式，从而可以实现对所有的用户端、所有的应用场景进行稳定地故障定位操作。

举例来说，故障定位装置所获得的场景信息可以包括：浏览器场景、社交软件场景、电商平台场景、特定软件场景以及其他场景，预先配置的预置日志格式可以包括：日志格式一、日志格式二、日志格式三，在获取到与上述各个场景信息相对应的日志配置信息之后，可以基于日志配置信息对上述各个场景信息所对应的预置日志格式进行配置操作，例如：可以将浏览器场景所对应的预置日志格式配置为日志格式二、社交软件场景所对应的预置日志格式配置为日志格式三、电商平台场景和特定软件场景所对应的预置日志格式配置为日志格式一，其他场景所对应的预置日志格式配置为日志格式二，从而完成了对用户端的各个场景信息进行预置日志格式的配置操作。

当故障定位装置进行通信连接的用户端的应用场景为自动驾驶场景时，由于故障定位装置中并不存在自动驾驶场景的单独配置操作，因此，可以将自动驾驶场景确定为“其他场景”，而后可以将其他场景所对应的预置日志格式(即日志格式二)确定为与自动驾驶场景相对应的预置日志格式。

本实施例中，通过获取用户端所能够运行的场景信息以及与场景信息相对应的日志配置信息，基于日志配置信息建立与场景信息相对应的预置日志格式，从而有效地实现了对用户端的各个场景信息进行预置日志格式的配置操作，这样有效地实现了对不同场景中的日志进行灵活的采集操作，进一步提高对上报数据进行获取的准确可靠性。

图13为本发明实施例提供的还一种故障定位方法的流程示意图；在上述任意一个实施例的基础上，参考附图13所示，在获取用于进行故障定位操作的上报数据之前，本实施例中的方法还可以包括：

步骤S1301：响应于用户端所发送的数据上报请求，确定与数据上报请求相对应的预置日志格式。

在用户端出现故障时，用户可以通过预设平台或者预设沟通软件来进行故障上报操作，此时，用户端可以生成一数据上报请求，该数据上报请求中可以包括与用户端相对应的用户身份标识、数据定位标识等等，而后用户端可以将所生成的数据上报请求发送至故障定位装置，从而使得故障定位装置可以接收到用户端所发送的数据上报请求。

由于用户端可以对应有多个场景信息，而不同的场景信息中的数据上报请求可以对应有不同的预置日志格式，因此，为了能够准确地进行故障定位操作，在获取到用户端所发送的数据上报请求之后，可以对数据上报请求进行分析处理，以确定与数据上报请求相对应的预置日志格式。在一些实例中，平台侧配置有多个预置日志格式，在用户端与平台侧进行通信连接之后，可以基于用户端的类型或者属性信息来确定与用户端相对应的预置日志格式，与用户端相对应的预置日志格式可以是预先配置的多个预置日志格式中的任意一个，并且，不同的用户端可以对应有相同或者不同的预置日志格式。

在另一些实例中，确定与数据上报请求相对应的预置日志格式包括：获取与数据上报请求相对应的场景信息；基于场景信息，确定与数据上报请求相对应的预置日志格式。

由于用户端可以基于用户的使用需求运行在不同的应用场景中，而不同的应用场景可以对应有不同的预置日志格式，因此，为了能够准确地获取与数据上报请求相对应的预置日志格式，则可以先获取与数据上报请求相对应的场景信息，其中，在数据上报请求中包括场景标识时，通过数据上报请求中提取的场景标识可以确定场景信息。或者，在获取到数据上报请求之后，可以获取与数据上报请求相对应的场景数据，基于场景数据来确定与数据上报请求相对应的场景信息。

在获取到场景信息之后，可以对场景信息进行分析处理，以确定与数据上报请求相对应的预置日志格式，具体的，预先配置有不同场景信息与各自对应的预置日志格式之间的映射关系，基于场景信息和上述映射关系即可确定与数据上报请求相对应的预置日志格式。

步骤S1302：将预置日志格式发送至用户端，以基于预置日志格式获得与用户端相对应的上报数据。

在获取到预置日志格式之后，为了能够稳定地获取用户端所对应的上报数据，可以将预置日志格式发送至用户端，在用户端获取到预置日志格式之后，可以基于预置日志格式进行日志采集操作，从而获得与用户端相对应的上报数据，进而实现了在不同的场景中可以获取到不同的上报数据，进一步提高了对上报数据进行获取的灵活可靠性。

本实施例中，响应于用户端所发送的数据上报请求，通过确定与数据上报请求相对应的预置日志格式，而后将预置日志格式发送至用户端，以基于预置日志格式获得与用户端相对应的上报数据，有效地实现了在不同的场景中可以获取到不同的上报数据，进一步提高了对上报数据进行获取的灵活可靠性。

具体应用时，本应用实施例提供了一种故障定位方法，该故障定位方法的执行主体可以包括用户所对应的用户端以及与研发人员相对应的故障定位装置，其中，用户端与故障定位装置通信连接。参考附图14所示，在用户通过用户端执行上述故障定位方法时，包括以下步骤：

步骤21：用户在用户端上的操作遇到故障/问题。

步骤22：基于所遇到的故障/问题触发故障工单的提交操作。

步骤23：基于提交工单的操作，询问用户是否采用录制形式进行提单？

其中，在用户端上预埋日志上报脚本，当用户选择提单过程，开启日志采集或者录制操作，在用户端通过平台侧拉取与用户端的场景信息相对应的预置日志类型之后，则可以基于预置日志格式提醒用户开始进行日志录制操作。

步骤24：若用户采用录制形式进行提单时，则可以开启日志录制操作，从而可以获得日志数据。

若用户不采用录制形式进行提单，则利用传统提单方式进行提单操作，具体的，在用户进入提单页面以后，立刻触发故障工单的上报操作，之后可以根据提单模板提供一些日志分析的必要信息，提单模板一般可以包括：用户账号、发生问题时段。

步骤25：在开启日志录制操作时，可以在用户端的操作界面中复现问题，以获得与用户端所出现问题的日志数据。

在日志录制开始之后，用户可以在显示界面上进行相关操作，复现其遇到的问题，在日志录制过程中，预埋的日志上报脚本可以记录相关需要的日志，比如：用户侧账号信息、用户侧基础配置数据、用户侧运行环境信息、API调用日志、用户操作日志。

步骤26：在完成日志数据之后，可以结束日志录制操作，并将日志数据提交至故障定位装置，以使研发人员可以进行故障定位操作。

用户选择录制结束后，日志上报脚本弹出提单界面，用户可补充一些其他的相关信息，点击提交后，可以将所采集的日志数据上传到平台侧进行存储，以使得平台侧可以基于日志信息进行故障定位操作。

参考附图15-图16所示，在研发人员通过故障定位装置(即平台侧)执行上述故障定位方法时，包括以下步骤：

步骤31：接收用户端所发送的工单数据(包括日志数据和其他相关信息)。

其中，故障定位装置中包括日志存储系统和工单系统，在故障定位装置接收到用户端所发送的工单数据之前，故障定位装置可以与用户端通信连接，此时，故障定位装置可以基于用户端的应用环境进行预置日志格式的配置操作，具体的，故障定位装置中可以包括有多个预置日志格式，基于用户端的应用环境配置相对应的预置日志格式，而后将预置日志格式发送至用户端，或者用户端主动拉取所配置的预置日志格式，需要注意的是，在用户端在进入特定页面时，就会主动拉取并应用预置日志格式。

在用户端获取到预置日志格式之后，可以基于预置日志格式记录日志信息，日志信息包括但不限于：用户账号信息、用户侧基础配置信息、前端加载资源记录、API调用日志、用户操作日志等等。在用户端记录日志信息之后，故障定位装置可以实时或者实时地获取用户端所记录的日志信息，此时，上报至故障定位装置的日志数据量比较大，故障定位装置可以将日志信息存储在日志存储系统中。

步骤32：根据工单数据进行场景还原操作，以能够快速故障定位问题。

当用户侧提单成功之后，工单流程到平台侧的研发人员处，故障定位装置(即平台侧)可以基于所获得的目标日志信息进行故障定位操作，首先可以先在平台侧启动一个本地容器，该容器可以根据用户账号和发生问题时段，自动拉取该时段所对应的目标日志信息，由于目标日志信息的数据量巨大，为了能够快速甄别用户的故障问题，平台侧可以先利用智能算法快速提取异常日志并进行智能诊断，智能算法可以是基于规则匹配模式或者自主学习形式所实现的。

若利用智能算法不能定位故障信息，则可以基于目标日志信息进行场景还原操作，具体的，可以先建立与用户侧运行环境相同的模拟运行环境；而后在模拟运行环境中，基于用户侧账号信息和用户侧配置信息，生成与用户数据相对应的界面信息；在界面信息中，基于API调用日志和用户操作日志进行场景还原，以进行故障定位操作。具体的，在进行场景还原操作时，可以分析出问题时间段内共用多少js报错日志、多少API报错日志，以一个js报错日志为例，拉取用户js报错日志发生前后的用户点击行为和API请求，注入到用户场景还原容器中，可以快速复现js报错问题，并给出js报错原因。

步骤33：解决所定位的故障/问题，以保证用户端的正常操作。

在确定故障信息之后，可以利用预设运维方式解决故障，以使得用户端可以进行正常的数据处理操作，从而实现了可以快速地定位、并解决用户端所出现的故障，提高了对用户端的良好体验。

此外，在接收用户端所发送的工单数据之前，本应用实施例中的方法还可以包括为用户端的各个场景信息进行预置日志格式进行配置的操作，具体的，该方法可以包括：

步骤41：获取用户端所能够运行的场景信息以及与场景信息相对应的日志配置信息。

其中，平台侧可以提前根据用户端所对应的各应用场景定义预置日志格式，以进行故障排查操作，具体的，预置日志格式一般可以包括以下几类日志：用户侧账号信息、用户侧基础配置数据、用户侧运行环境信息、API调用日志、用户操作日志(页面点击、页面切换信息等)，各个应用场景以及所配置的预置日志格式可以保存在平台侧。

步骤42：基于日志配置信息建立与场景信息相对应的预置日志格式，预置日志格式至少用于获取上报数据。

需要注意的是，在生成上报数据的过程中，对于上报数据中所包括的机密数据或者高机密数据而言，可以在上报脚本中增加对机密数据的混淆处理操作，这样使得平台侧获得的上报数据中是经过混淆处理后的数据，从而可以避免暴露用户机密的问题。

本应用实施例提供的故障定位方法，由开发者(研发人员)提供故障上报脚本工具，在平台侧界面注入上述故障上报脚本工具，并将故障上报脚本开启流程加入到用户端的故障提单流程，在用户进行故障提单时，可以提醒用户进行用户操作行为的日志采集操作，具体的，用户统一开启故障提单操作之后，故障上报脚本可以根据预置日志格式记录用户当前操作的相关日志，从而可以获得日志上报数据，并可以将日志上报数据直接上传到平台侧(服务端)，以使得平台侧可以基于日志上报信息进行故障定位操作。

总的来说，本应用实施例提供的故障定位方法可以实现如下效果：通过平台侧容器结合用户上报日志还原用户场景，避免直接接入用户系统，进而也不会出现对用户配置误操作的行为；在用户提工单时，无需进行大量不准确的问题描述，避免文字表达不清的问题；能够快速获取用户侧的所有与故障相关的运行日志，并可以基于上报日志数据快速还原用户场景，减少问题排查过程中沟通成本，提高排查效率；日志的上报内容可以灵活配置，适用于不同场景；日志定义可以区分机密数据，提升用户数据安全，进一步提高了该方法的实用性，有利于市场的推广与应用。

图17为本发明实施例提供的一种日志格式的配置方法的流程示意图；参考附图1-图2所示，本实施例提供了一种日志格式的配置方法，该方法的执行主体为日志格式的配置装置，可以理解的是，该日志格式的配置装置可以实现为软件、或者软件和硬件的组合，具体实现时，该日志格式的配置装置可以实现为一研发人员所对应的终端/服务器。该日志格式的配置方法可以包括：

步骤S1701：获取用户端所能够运行的场景信息以及与所述场景信息相对应的日志配置信息。

其中，预置日志格式用于限定所获得的用户端上实时数据所包括的数据类型，例如：预置日志格式至少包括：用于获取用户侧账户信息的日志格式、用于获取用户侧配置信息的日志格式、用于获取用户侧运行环境的日志格式、用于获取API调用行为的日志格式、用于获取用户操作行为的日志格式等等。由于不同的用户端、不同的场景信息所需要获取的实时数据类型不同，因此，为了能够为不同的用户端、不同的场景信息配置不同的预置日志格式，可以先获取用户端所能够运行的场景信息，用户端所能够运行的场景信息可以是指研发人员所能预见或者预先配置好的用户端能够运行的所有场景信息、用户端所能实际运行的所有场景信息，为了能够覆盖所有场景信息，并对所有应用场景进行预置日志格式的配置操作，可以将用户所能够运行的场景信息进行场景分类，以场景类别来进行预置日志格式的配置操作。此外，为了能够实现预置日志格式的配置操作，还需要获取到与场景信息相对应的日志配置信息，该日志配置信息可以包括用户在配置页面中所输入的执行操作。

步骤S1702：基于所述日志配置信息，生成与所述场景信息相对应的预置日志格式，所述预置日志格式用于获取所述用户端的至少部分日志数据。

在获取到日志配置信息和场景信息之后，可以基于日志配置信息建立与场景信息相对应的预置日志格式，该预置日志格式至少用于获取上报数据。

需要注意的是，当日志格式的配置装置连接用户端之后，用户端处于一个新的场景信息，而日志格式的配置装置并未对上述新的场景信息进行预置日志格式的配置操作时，为了能够针对用户端实现准确地日志采集操作，可以将上述的新的场景信息确定预先配置的兜底场景类型，例如“其他场景”，而后可以将上述“其他场景”所对应的预置日志格式确定为上述新的场景信息所对应的预置日志格式，从而可以实现对所有的用户端、所有的应用场景进行稳定地日志格式的配置操作。

举例来说，日志格式的配置装置所获得的场景信息可以包括：浏览器场景、社交软件场景、电商平台场景、特定软件场景以及其他场景，预先配置的预置日志格式可以包括：日志格式一、日志格式二、日志格式三，在获取到与上述各个场景信息相对应的日志配置信息之后，可以基于日志配置信息对上述各个场景信息所对应的预置日志格式进行配置操作，例如：可以将浏览器场景所对应的预置日志格式配置为日志格式二、社交软件场景所对应的预置日志格式配置为日志格式三、电商平台场景和特定软件场景所对应的预置日志格式配置为日志格式一，其他场景所对应的预置日志格式配置为日志格式二，从而完成了对用户端的各个场景信息进行预置日志格式的配置操作。

当日志格式的配置装置进行通信连接的用户端的应用场景为自动驾驶场景时，由于日志格式的配置装置中并不存在自动驾驶场景的单独配置操作，因此，可以将自动驾驶场景确定为“其他场景”，而后可以将其他场景所对应的预置日志格式(即日志格式二)确定为与自动驾驶场景相对应的预置日志格式。

在又一些实例中，本实施例中的方法还可以包括：

步骤1801：获取用户端发送的数据上报请求。

步骤1802：确定与所述数据上报请求相对应的预置日志格式。

步骤1803：将所述预置日志格式发送至用户端，以基于所述预置日志格式获得与所述用户端相对应的上报数据。

本实施例中上述步骤的具体实现方式和实现效果与上述实施例中步骤S1301-步骤S1302的具体实现方式和实现效果相类似，具体可参考上述陈述内容，在此不再赘述。

本实施例提供的日志格式的配置方法，通过获取用户端所能够运行的场景信息以及与场景信息相对应的日志配置信息，基于日志配置信息建立与场景信息相对应的预置日志格式，从而有效地实现了对用户端的各个场景信息进行预置日志格式的配置操作，即预置日志格式是基于用户端所能够运行的场景信息进行配置的，这样有效地实现了对不同场景中的日志进行灵活的采集操作，进一步提高对日志数据进行获取的准确可靠性。

图18为本发明实施例提供的一种故障定位装置的结构示意图；参考附图18所示，本实施例提供了一种故障定位装置，该故障定位装置用于执行上述图2所示的故障定位方法，具体的，该故障定位装置可以包括：

第一接收模块11，用于接收用户端所发送的数据上报请求；

第一确定模块12，用于确定与数据上报请求相对应的数据定位标识；

第一获取模块13，用于获取用户端所产生的与数据定位标识相对应的用户数据，用户数据包括：用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志；

第一处理模块14，用于基于用户数据进行故障定位操作。

在一些实例中，在第一处理模块14基于用户数据进行故障定位操作时，该第一处理模块14用于执行：判断对用户数据进行日志排查操作能否定位故障信息；若能够定位故障信息，则获得与用户数据相对应的故障信息；若不能定位故障信息，则基于用户数据进行场景还原，以进行故障定位操作。

在一些实例中，在第一处理模块14基于用户数据进行场景还原时，该第一处理模块14用于执行：建立与用户侧运行环境相同的模拟运行环境；在模拟运行环境中，基于用户侧账号信息和用户侧配置信息，生成与用户数据相对应的界面信息；在界面信息中，基于API调用日志和用户操作日志进行场景还原。

在一些实例中，在第一获取模块13获取用户端所产生的与数据定位标识相对应的用户数据时，该第一获取模块13用于执行：获取用户端所产生的用户侧实时数据；基于数据定位标识，确定与数据上报请求相对应的数据标识时间段；在用户侧实时数据中，获取与数据标识时间段相对应的用户数据。

在一些实例中，在第一获取模块13获取用户端所产生的用户侧实时数据时，该第一获取模块13用于执行：获取与用户端相对应的预置日志格式；基于预置日志格式对用户端所生成的数据进行实时采集，获得用户侧实时数据。

在一些实例中，在第一获取模块13获取与用户端相对应的预置日志格式时，该第一获取模块13用于执行：获取与用户端相对应的场景信息；基于场景信息，确定与用户端相对应的预置日志格式。

图18所示装置可以执行图1-图7所示实施例的方法，本实施例未详细描述的部分，可参考对图1-图7所示实施例的相关说明。该技术方案的执行过程和技术效果参见图1-图7所示实施例中的描述，在此不再赘述。

在一个可能的设计中，图18所示故障定位装置的结构可实现为一电子设备，该电子设备可以是研发人员所对应的终端、服务器等各种设备。如图19所示，该电子设备可以包括：第一处理器21和第一存储器22。其中，第一存储器22用于存储相对应电子设备执行上述图1-图7所示实施例中提供的故障定位方法的程序，第一处理器21被配置为用于执行第一存储器22中存储的程序。

程序包括一条或多条计算机指令，其中，一条或多条计算机指令被第一处理器21执行时能够实现如下步骤：接收用户端所发送的数据上报请求；确定与数据上报请求相对应的数据定位标识；获取用户端所产生的与数据定位标识相对应的用户数据，用户数据包括：用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志；基于用户数据进行故障定位操作。

进一步的，第一处理器21还用于执行前述图1-图7所示实施例中的全部或部分步骤。

其中，电子设备的结构中还可以包括第一通信接口23，用于电子设备与其他设备或通信网络通信。

另外，本发明实施例提供了一种计算机存储介质，用于储存电子设备所用的计算机软件指令，其包含用于执行上述图1-图7所示方法实施例中故障定位方法所涉及的程序。

此外，本发明实施例提供了一种计算机程序产品，包括：存储有计算机指令的计算机可读存储介质，当计算机指令被一个或多个处理器执行时，致使一个或多个处理器执行上述图1-图7所示方法实施例中故障定位方法中的步骤。

图20为本发明实施例提供的另一种故障定位装置的结构示意图；参考附图20所示，本实施例提供了另一种故障定位装置，该故障定位装置用于执行上述图8所示的故障定位方法，具体的，该故障定位装置可以包括：

第二获取模块31，用于获取数据上报请求，数据上报请求用于进行故障定位操作；

第二确定模块32，用于确定与数据上报请求相对应的预置日志格式；

第二生成模块33，用于基于预置日志格式，生成上报数据，上报数据包括用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志；

第二处理模块34，用于对上报数据进行上报，以基于上报数据进行故障定位操作。

在一些实例中，在确定与数据上报请求相对应的预置日志格式之后，本实施例中的第二生成模块33和第二处理模块34用于执行以下步骤：

第二生成模块33，用于生成与预置日志格式相对应的日志采集提示；

第二处理模块34，用于在获取到与日志采集提示相对应的确认执行信息时，允许基于预置日志格式生成上报数据；在获取到日志采集提示相对应的取消执行信息时，禁止基于预置日志格式生成上报数据。

在一些实例中，本实施例中的第二生成模块33和第二处理模块34用于执行以下步骤：

第二生成模块33，用于在生成上报数据的过程中，获取与用户操作行为相对应的截图信息和/或录像信息；

第二处理模块34，用于将截图信息和/或录像信息添加至上报数据中。

图20所示装置可以执行图8-图10、图14-图16所示实施例的方法，本实施例未详细描述的部分，可参考对图8-图10、图14-图16所示实施例的相关说明。该技术方案的执行过程和技术效果参见图8-图10、图14-图16所示实施例中的描述，在此不再赘述。

在一个可能的设计中，图20所示故障定位装置的结构可实现为一电子设备，该电子设备可以是用户端、个人电脑、智能终端等各种设备。如图21所示，该电子设备可以包括：第二处理器41和第二存储器42。其中，第二存储器42用于存储相对应电子设备执行上述图8-图10、图14-图16所示实施例中提供的故障定位方法的程序，第二处理器41被配置为用于执行第二存储器42中存储的程序。

程序包括一条或多条计算机指令，其中，一条或多条计算机指令被第二处理器41执行时能够实现如下步骤：获取数据上报请求，数据上报请求用于进行故障定位操作；确定与数据上报请求相对应的预置日志格式；基于预置日志格式，生成上报数据，上报数据包括用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志；对上报数据进行上报，以基于上报数据进行故障定位操作。

进一步的，第二处理器41还用于执行前述图11所示实施例中的全部或部分步骤。

其中，电子设备的结构中还可以包括第二通信接口43，用于电子设备与其他设备或通信网络通信。

另外，本发明实施例提供了一种计算机存储介质，用于储存电子设备所用的计算机软件指令，其包含用于执行上述图8-图10、图14-图16所示方法实施例中故障定位方法所涉及的程序。

此外，本发明实施例提供了一种计算机程序产品，包括：存储有计算机指令的计算机可读存储介质，当计算机指令被一个或多个处理器执行时，致使一个或多个处理器执行上述图8-图10、图14-图16所示方法实施例中故障定位方法中的步骤。

图22为本发明实施例提供的又一种故障定位装置的结构示意图；参考附图22所示，本实施例提供了又一种故障定位装置，该故障定位装置用于执行上述图11所示的故障定位方法，具体的，故障定位装置可以包括：

第三获取模块51，用于获取用于进行故障定位操作的上报数据，上报数据包括用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志；

第三判断模块52，用于判断对上报数据进行日志排查操作能否定位故障信息；

第三处理模块53，用于若不能定位故障信息，则基于上报数据进行场景还原，以进行故障定位操作。

在一些实例中，本实施例中的第三处理模块53用于执行：若能够定位故障信息，则获得与上报数据相对应的故障信息。

在一些实例中，在第三处理模块53基于上报数据进行场景还原时，该第三处理模块53用于执行：建立与用户侧运行环境相同的模拟运行环境；在模拟运行环境中，基于用户侧账号信息和用户侧配置信息，生成与上报数据相对应的界面信息；在界面信息中，基于API调用日志和用户操作日志进行场景还原。

在一些实例中，本实施例中的第三获取模块51和第三处理模块53用于执行以下步骤：

第三获取模块51，用于获取用户端所能够运行的场景信息以及与场景信息相对应的日志配置信息；

第三处理模块53，用于基于日志配置信息建立与场景信息相对应的预置日志格式，预置日志格式至少用于获取上报数据。

在一些实例中，在获取用于进行故障定位操作的上报数据之前，本实施例中的第三处理模块53用于执行：响应于用户端所发送的数据上报请求，确定与数据上报请求相对应的预置日志格式；将预置日志格式发送至用户端，以基于预置日志格式获得与用户端相对应的上报数据。

图22所示装置可以执行图11-图16所示实施例的方法，本实施例未详细描述的部分，可参考对图11-图16所示实施例的相关说明。该技术方案的执行过程和技术效果参见图11-图16所示实施例中的描述，在此不再赘述。

在一个可能的设计中，图22所示故障定位装置的结构可实现为一电子设备，该电子设备可以是研发人员所对应的终端设备、服务器等各种设备。如图23所示，该电子设备可以包括：第三处理器61和第三存储器62。其中，第三存储器62用于存储相对应电子设备执行上述图11-图16所示实施例中提供的故障定位方法的程序，第三处理器61被配置为用于执行第三存储器62中存储的程序。

程序包括一条或多条计算机指令，其中，一条或多条计算机指令被第三处理器61执行时能够实现如下步骤：获取用于进行故障定位操作的上报数据，上报数据包括用户侧账户信息、用户侧配置信息、用户侧运行环境、应用程序接口API调用日志、用户操作日志；判断对上报数据进行日志排查操作能否定位故障信息；若不能定位故障信息，则基于上报数据进行场景还原，以进行故障定位操作。

进一步的，第三处理器61还用于执行前述图11-图16所示实施例中的全部或部分步骤。

其中，电子设备的结构中还可以包括第三通信接口63，用于电子设备与其他设备或通信网络通信。

另外，本发明实施例提供了一种计算机存储介质，用于储存电子设备所用的计算机软件指令，其包含用于执行上述图11-图16所示方法实施例中故障定位方法所涉及的程序。

此外，本发明实施例提供了一种计算机程序产品，包括：存储有计算机指令的计算机可读存储介质，当计算机指令被一个或多个处理器执行时，致使一个或多个处理器执行上述图11-图16所示方法实施例中故障定位方法中的步骤。

图24为本发明实施例提供的一种日志格式的配置装置的结构示意图；参考附图24所示，本实施例提供了一种日志格式的配置装置，该日志格式的配置装置用于执行上述图17所示的日志格式的配置方法，具体的，该日志格式的配置装置可以包括：

第四获取模块71，用于获取用户端所能够运行的场景信息以及与所述场景信息相对应的日志配置信息；

第四处理模块72，用于基于所述日志配置信息，生成与所述场景信息相对应的预置日志格式，所述预置日志格式用于获取所述用户端的至少部分日志数据。

在一些实例中，本实施例中的第四获取模块71和第四处理模块72还用于执行以下步骤：

第四获取模块71，用于获取用户端发送的数据上报请求。

第四处理模块72，用于确定与所述数据上报请求相对应的预置日志格式；将所述预置日志格式发送至用户端，以基于所述预置日志格式获得与所述用户端相对应的上报数据。

图24所示装置可以执行图17所示实施例的方法，本实施例未详细描述的部分，可参考对图17所示实施例的相关说明。该技术方案的执行过程和技术效果参见图17所示实施例中的描述，在此不再赘述。

在一个可能的设计中，图24所示日志格式的配置装置的结构可实现为一电子设备，该电子设备可以是研发人员所对应的终端设备、服务器等各种设备。如图25所示，该电子设备可以包括：第四处理器81和第四存储器82。其中，第四存储器82用于存储相对应电子设备执行上述图17所示实施例中提供的日志格式的配置方法的程序，第四处理器81被配置为用于执行第四存储器82中存储的程序。

程序包括一条或多条计算机指令，其中，一条或多条计算机指令被第四处理器81执行时能够实现如下步骤：获取用户端所能够运行的场景信息以及与所述场景信息相对应的日志配置信息；基于所述日志配置信息，生成与所述场景信息相对应的预置日志格式，所述预置日志格式用于获取所述用户端的至少部分日志数据。

进一步的，第四处理器81还用于执行前述图17所示实施例中的全部或部分步骤。

其中，电子设备的结构中还可以包括第四通信接口83，用于电子设备与其他设备或通信网络通信。

另外，本发明实施例提供了一种计算机存储介质，用于储存电子设备所用的计算机软件指令，其包含用于执行上述图17所示方法实施例中日志格式的配置方法所涉及的程序。

此外，本发明实施例提供了一种计算机程序产品，包括：存储有计算机指令的计算机可读存储介质，当计算机指令被一个或多个处理器执行时，致使一个或多个处理器执行上述图17所示方法实施例中日志格式的配置方法中的步骤。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件和软件结合的方式来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程设备的处理器以产生一个机器，使得通过计算机或其他可编程设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。