CN112711518B - 一种日志上传方法和装置 - Google Patents

Abstract

本申请实施例提供一种日志上传方法和装置，涉及通信技术领域。其中，日志上传方法包括：获取目标应用程序的运行数据以及用户标识；根据运行数据和用户标识，生成运行日志；根据预设的日志上传条件，从运行日志中确定待上传日志；上传待上传日志。本申请实施例在生成运行日志后，通过预设的日志上传条件，从运行日志中确定待上传日志，并主动上传待上传日志，保证了日志上传的实时性，提高了日志上传的效率，以避免用户反馈问题后，开发人员去获取用户端日志时，用户已经离线，从而导致的无法及时获取用户端日志的问题。

Description

一种日志上传方法和装置

技术领域

本申请涉及通信技术领域，具体涉及一种日志上传方法和装置。

背景技术

随着计算机技术的发展，市面上的应用程序逐渐增多，用户在使用应用程序的时候，经常出现异常、错误或崩溃的情况，为了降低这种情况的发生，开发人员需要对用户端的日志进行收集。其中，日志可以记录很多关键信息，包括应用程序运行时产生的错误信息、调试信息，和其它一些有用的状态信息、运行数据信息等。

但是，应用程序绝大部分是不会连接着开发环境和测试环境的，同时由于测试和开发的设备有限以及外网环境的复杂性，开发人员不能够很方便地获取到用户端上的日志信息。例如，有一些应用程序获取用户端的日志时需要在办公环境下，同时需要用户在线才能获取用户端的日志，而现实中很多时候用户端反馈问题后，需要产品对接人通知到开发人员，开发人员再去获取用户端的日志，等开发人员去获取用户端的日志的时候用户可能已经处于离线状态，开发人员无法获取离线状态下的用户端的日志信息，因此，不能及时的将日志信息反馈至开发人员。

发明内容

本申请实施例提供一种日志上传方法和装置，保证了上传日志的实时性。

本申请实施例提供了一种日志上传方法，包括：

获取目标应用程序的运行数据以及用户标识；

根据所述运行数据和所述用户标识，生成运行日志；

根据预设的日志上传条件，从所述运行日志中确定待上传日志；

上传所述待上传日志。

本申请实施例还提供了一种日志上传装置，包括：

获取单元，用于获取目标应用程序的运行数据以及用户标识；

生成单元，用于根据所述运行数据和所述用户标识，生成运行日志；

确定单元，用于根据预设的日志上传条件，从所述运行日志中确定待上传日志；

上传单元，用于上传所述待上传日志。

进一步地，所述生成单元，包括：

第一检测单元，用于检测日志跟随标识；

目标数据确定单元，用于在检测到所述日志跟随标识时，确定所述日志跟随标识对应的目标运行数据；

第一生成单元，用于根据所述目标运行数据，以及所述用户标识生成运行日志。

进一步地，所述第一检测单元，具体用于：检测是否生成日志跟随标识；在检测到生成所述日志跟随标识时，确定检测到所述日志跟随标识。

进一步地，所述第一检测单元，具体用于：检测是否接收到交互请求；在检测到所述交互请求时，确定检测到所述日志跟随标识。

进一步地，所述确定单元，包括：

标识检测单元，用于检测所述运行日志中是否包括所述日志跟随标识；

第一确定单元，用于若所述运行日志中包括所述日志跟随标识，确定为待上传日志。

进一步地，所述确定单元，包括：

类型获取单元，用于获取所述运行日志的日志类型，所述日志类型包括异常类型；

第二确定单元，用于将包括所述异常类型的运行日志确定为待上传日志，所述异常类型包括网络请求失败异常。

进一步地，所述确定单元，包括：

文件夹获取单元，用于获取启动异常文件夹中的运行日志；

第三确定单元，用于将所获取的运行日志确定为待上传日志。

进一步地，所述确定单元，包括：

级别获取单元，用于获取所述运行日志的日志级别，以及目标日志级别；

第四确定单元，用于将所述日志级别为目标日志级别的运行日志确定为待上传日志。

进一步地，所述级别获取单元包括目标级别获取单元，所述目标级别获取单元，具体用于接收服务器发送的日志获取指令；根据所述日志获取指令确定所述目标日志级别。

进一步地，所述确定单元，包括：

第二内容获取单元，用于获取运行日志的数据内容，以及目标数据内容；

第五确定单元，用于将所述数据内容中包括目标数据内容的运行日志确定为待上传日志。

进一步地，所述上传单元，具体用于将所述待上传日志上传至区块链。

本申请实施例还提供了一种计算机设备，所述计算机设备包括存储器，以及与所述存储器相连的处理器；所述存储器用于存储计算机程序；所述处理器用于运行所述存储器中存储的计算机程序，以执行上述任一种日志上传方法。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时，实现上述任一种日志上传方法。

本申请实施例通过获取目标应用程序的运行数据以及用户标识；根据所述运行数据和所述用户标识，生成运行日志；根据预设的日志上传条件，从所述运行日志中确定待上传日志；上传所述待上传日志。本申请实施例在生成运行日志后，通过预设的日志上传条件，从运行日志中确定待上传日志，并主动上传待上传日志，保证了日志上传的实时性，提高了日志上传的效率以避免用户反馈问题后，开发人员去获取用户端日志时，用户已经离线，从而导致的无法及时获取用户端日志的问题。

附图说明

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

图1a是本申请实施例提供的日志上传系统的系统示意图；

图1b是本申请实施例提供的生成日志获取指令的场景示意图；

图1c是本申请实施例提供的日志上传方法的流程示意图；

图1d是本申请实施例提供的日志上传方法的子流程示意图；

图1e是本申请实施例提供的日志跟随标识相关的场景示意图；

图1f是本申请实施例提供的触发日志上传指令的场景示意图；

图1g是本申请实施例提供的目标日志级别相关的场景示意图；

图2a是本申请实施例提供的日志上传装置的示意性框图；

图2b是本申请实施例提供的生成单元的示意性框图；

图3是本申请实施例提供的计算机设备的结构示意图。

具体实施方式

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

可以理解地，在本申请的描述中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个所述特征。另外也应当理解，尽管术语第一、第二等可以在此用来描述各种元素，但这些元素不应该受限于这些术语。这些术语仅用来将这些元素彼此区分开。例如，在不脱离本发明范围的前提下，第一终端可以被称为第二终端，并且类似地，第二终端可以被称为第一终端。第一终端和第二终端均为终端，但它们并非同一终端。

在对本发明实施例进行详细地解释说明之前，先对本发明实施例涉及到的一些名词进行解释说明。

交互数据，包括多个终端之间进行交互时的数据，如一个终端向另一个终端发送的数据等。

日志跟随标识，用于跟随一条交互数据的发送情况和接收情况，由于交互数据的发送情况和接收情况等都会生成一条日志，因此称为日志跟随标识。日志跟随标识可通过预定长度的字符串来表示，还可以通过其他的数据来表示。一个日志跟随标识用于标识一条交互数据，以跟随一条交互数据的发送情况和接收情况等。如此，日志跟随标识用于存在交互数据的场景中，例如，在涉及视频直播的目标应用程序中，老师通过视频向学生直播课程，在老师发送一条交互数据给学生时，会携带一个日志跟随标识，用于标识老师发送的该条交互数据。当老师发送另一条交互数据给学生时，会携带另一个日志跟随标识，该另一个日志跟随用于标识老师发送的另一条交互数据。

区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。其中，一批次网络交易的信息，也可以理解为一批次的输入信息，在本申请实施例中指的是需保存在区块链上的运行日志。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。

区块链底层平台可以包括用户管理、基础服务、智能合约以及运营检测等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置(风控审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求(如本申请实施例中的将待上传日志上传并保存至区块链的保存请求)的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营检测模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、检测网络情况、检测节点设备健康状态等。平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。

本申请实施例提供一种日志上传方法、装置、计算机设备和存储介质。

本申请实施例提供了一种日志上传系统，包括本申请实施例任一提供的日志上传装置。如图1a所示，为本申请实施例提供的日志上传系统的示意图。该日志上传系统包括第一终端、第二终端和服务器。该第一终端包括至少一个，该第二终端包括至少一个。该第一终端可以理解为普通用户所在的客户端，在该第一终端中安装有目标应用程序，该第二终端可以理解为开发人员所在的客户端。该服务器可以是单个服务器，还可以是服务器集群，该服务器包括存储功能和业务功能，该存储功能和业务功能可在单个服务器中实现，也可以通过服务器集群实现。如图1a中，服务器包括业务服务器和云服务器。进一步地，完成存储功能的服务器除了包括云服务器，还可以包括区块链等。该第一终端和该第二终端通过网络和服务器连接，网络中包括路由器、网关等网络实体。

在该第一终端中，获取目标应用程序的运行数据和用户标识；根据目标应用程序的运行数据和用户标识生成运行日志；根据预设的日志上传条件，从所生成的运行日志中确定待上传日志；并上传该待上传日志至服务器。

在该第二终端中，获取运行日志中的用户标识，获取时间标识；根据用户标识和时间标识生成日志获取指令，并发送日志获取指令至服务器；接收服务器基于该日志获取指令返回的运行日志数据；对返回的运行日志数据进行分析。

如图1b所示，获取用户标识(图中用户标识用uin表示)，在第二终端所在的界面上输入所获取的用户标识，并输入需获取日志的起始时间和时间范围(时长)，根据该起始时间和时间范围确定时间标识。根据用户标识和时间标识生成日志获取指令。

服务器端接收到第一终端发送的运行日志后，将所发送的运行日志进行保存。服务器端接收到第二终端发送的日志获取指令后，在保存的运行日志中进行查询，以得到运行日志数据，并发送至第二终端。或者服务器端接收到第二终端发送的日志获取指令后，将该日志获取指令发送至第一终端，并接收第一终端基于该日志获取指令返回的运行日志数据，并将该运行日志数据发送至第二终端。

由于第一终端可以主动实时的发送运行日志至服务器，保证了日志上传的实时性，提高了日志上传的效率，第二终端可实时地获取第一终端的运行日志数据，保证了第二终端获取日志的实时性，提高了获取日志的效率，以进一步提高对日志分析处理的效率。

可以理解地，本申请实施例中的日志上传方法也可应用在业务服务器端。为了方便理解，下文中的日志上传方法的实施例中以应用于在第一终端为例进行说明。

图1c是本申请实施例提供的日志上传方法流程示意图，该方法应用于第一终端中，该日志上传方法的具体流程可以如下：

101，获取目标应用程序的运行数据以及用户标识。

目标应用程序在运行过程中会产生很多运行数据，主要包括两大类：异常运行数据和正常运行数据等。异常运行数据包括启动异常、登陆失败等，正常运行数据包括目标应用程序在运行过程中产生的各类数据，如使用目标应用程序的一个用户终端向另一个用户终端发送的交互数据、目标应用程序中涉及的参数数据等。目标应用程序在运行过程中产生的运行数据，还可以按照其他的方式进行分类。用户标识用来标识一个用户，用户标识可以是用户登录目标应用程序的昵称、邮箱、微信号、通信号码、身份证、二维码等，也可以是在检测到用户使用目标应用程序时，目标应用程序的服务器为该用户分配的字符串等，具体不做限制。

102，根据运行数据和用户标识，生成运行日志。

根据具体运行数据的不同，生成运行日志的方式也存在差异。

如图1d所示，是本申请实施例提供的步骤102的子流程示意图。具体地，步骤102，即根据运行数据和用户标识，生成运行日志的步骤，包括：

1021，检测日志跟随标识。

即在目标应用程序运行过程中，检测日志跟随标识。日志跟随标识也属于目标应用程序运行过程中的运行数据。

具体地，检测日志跟随标识的步骤，包括：检测是否生成日志跟随标识；在检测到生成日志跟随标识时，确定检测到日志跟随标识。其中，生成日志跟随标识的步骤，包括：检测是否在目标应用程序上触发预设操作；若检测到在目标应用程序上触发预设操作，生成日志跟随标识。

预设操作包括发送操作。可以理解地，日志跟随标识用于跟随一条交互数据的发送情况和接收情况，因此在第一终端要发送交互数据，触发了发送操作时，生成日志跟随标识。该发送操作可以是在交互数据编辑后，通过点击/触摸目标应用程序界面上的“发送”控件、“确定”控件等触发的操作，还可以是其他方式触发的用于与其他终端(如服务器)进行交互的操作。例如在涉及视频直播的目标应用程序中，老师通过视频向学生直播课程，可能会涉及到老师要发送消息给学生，如老师编辑消息“你们还有什么问题吗？”后，点击“发送”控件，则生成日志跟随标识。将该消息作为交互数据，如此，该日志跟随标识用于标识老师发送“你们还有什么问题吗？”的交互数据。

其中，可通过获取当前时间数据和/或用户标识，并对当前时间数据和/或用户标识进行哈希计算或者进行加密计算，以得到日志跟随标识，如利用信息摘要算法MD5(Message-Digest Algorithm)进行加密计算；还可以通过获取他数据或者通过其他方式来生成日志跟随标识。

在编辑交互数据，并触发发送操作时，会生成日志跟随标识。第一终端在检测到触发发送操作后，会根据交互数据(如“你们还有什么问题吗？”)和该发送操作，以及所生成的日志跟随标识生成发送请求，因此，该发送请求会携带所生成的日志跟随标识。将该发送请求发送至服务器，服务器转发该发送请求到其他终端，如另一第一终端。因此，另一第一终端接收到该发送请求后，该发送请求中仍携带日志跟随标识。

具体地，检测日志跟随标识的步骤，包括：检测是否接收到交互请求；在检测到交互请求时，确定检测到日志跟随标识。其中，交互请求是指多个终端之间为了进行数据交互而生成的请求。交互请求是由其他第一终端(可能会经过服务器转发)发送的，也可以是由服务器发送的，例如，由其他第一终端发送的发送请求。由于发送请求中会携带日志跟随标识、交互数据。因此，第一终端检测是否接收到交互请求；若检测接收到交互请求，则确定检测到日志跟随标识。需要指出的是，该处的交互请求不止包括发送请求，还包括存在交互的其他终端发送的任何数据。

1022，在检测到日志跟随标识时，确定日志跟随标识对应的目标运行数据。

其中，目标运行数据包括发送数据和接收数据。如发送请求所对应的数据；从交互的其他终端接收的数据等。例如，在发送交互数据阶段，在编辑交互数据、并触发了发送操作时，生成日志跟随标识，即检测到日志跟随标识；根据交互数据、日志跟随标识和发送操作生成发送请求，该发送请求中携带日志跟随标识；将该发送请求所对应的数据确定为日志跟随标识对应的目标运行数据。在接收数据阶段，如接收发送请求，由于发送请求会携带日志跟随标识，因此，检测是否接收到发送请求，若检测接收到发送请求，即检测到日志跟随标识，将接收数据，如接收到的发送请求确定为日志跟随标识所对应的目标运行数据。

1023，根据目标运行数据，以及用户标识生成运行日志。

具体地，获取运行日志的数据结构；获取运行日志的数据结构中对应的字段；确定每个字段对应的数据内容；根据每个字段对应的数据内容生成运行日志。如运行日志的数据结构中对应的字段包括目标运行数据、日志跟随标识、用户标识、当前时间戳、运行日志级别等。确定每个字段对应的数据内容，如确定当前时间戳的数据内容包括：获取当前时间，将当前时间作为当前时间戳字段的数据内容；或者获取当前时间，将当前时间进行转换处理，将转换处理后的数据作为当前时间戳字段的数据内容。根据所确定的每个字段对应的数据内容生成运行日志。其中，将发送数据所对应的日志称为发送运行日志，将接收数据所对应的日志称为接收运行日志。

如图1e所示，服务器包括业务服务器和云服务器，第一终端A向业务服务器发送CS请求(客户端请求)，该CS请求中携带日志跟随标识traceid；业务服务器接收到该CS请求后，将该CS请求推送(转发)至第一终端B，该CS请求中仍携带traceid。第一终端C向业务服务器发送CGI请求(与CS请求不同的另一种请求)，该CGI请求中携带日志跟随标识traceid；业务服务器接收到该CGI请求后，应答该CGI请求，并将该应答CGI请求发送至第一终端C，该CGI请求中携带traceid。需要注意的是，CS请求中携带的日志跟随标识traceid，与CGI请求中携带的日志跟随标识traceid，是不相同的。

例如，第一终端A要发送“你们还有什么问题吗？”这条交互数据，检测到触发发送操作后，生成日志跟随标识traceid，则检测到日志跟随标识；根据交互数据、发送操作和traceid生成CS请求，如此，该CS请求携带traceid，将所生成的CS请求作为目标运行数据。将所生成的CS请求和用户标识生成一条运行日志。将所生成的CS请求发送到业务服务器，业务服务器推送到第一终端B。第一终端B接收CS请求，由于CS请求中携带traceid，则检测接收到CS请求时，确定检测到日志跟随标识，将所接收到的CS请求作为目标运行数据，根据接收到的CS请求和用户标识生成一条运行日志。

可以理解地，在第一终端A(假设为老师)发送“你们还有什么问题吗？”的交互数据给第一终端B时(假设有多个第一终端B，即有多个学生)，生成一条运行日志。接收到该条交互数据的第一终端B，在接收到该条交互数据时生成一条运行日志，未接收到该条交互数据的第一终端B，不会生成运行日志。如此，可根据第一终端A生成的运行日志和第一终端B生成的运行日志，查看交互数据是否已经成功发送到所有的第一终端B。

上述根据运行数据和用户标识，生成运行日志的方案，利用日志跟随标识来跟随交互数据的发送情况和接收情况，或者也可以理解为，利用日志跟随标识来跟随一条交互数据的链路信息(发送情况和接收情况)，会得到发送运行日志和接收运行日志，如此以得到交互数据的全链路日志。

在涉及网络请求失败异常的场景中，具体地，步骤102，即根据运行数据和用户标识，生成运行日志的步骤，包括：检测是否接收到目标应用程序出现网络请求失败异常所对应的错误码；若接收到目标应用程序出现网络请求失败异常所对应的错误码，根据网络请求、错误码以及用户标识生成网络请求失败异常的运行日志。其中，网络请求失败异常包括：登陆失败、进房失败(进入某个房间查看直播或者回放等)、回放播放失败等。需要指出的是，根据日志跟随标识生成运行日志时，该运行日志的数据结构与网络请求失败异常的所对应的运行日志的数据结构可以相同，也可以不同。若采用不同的数据结构，在该网络请求失败异常所对应的运行日志的数据结构中，包括网络请求、错误码、用户标识、日志级别、当前时间戳等，在一些情况下，还包括日志类型等字段。需要注意的是，若出现网络请求失败异常，则生成的运行日志的日志类型也设置为异常类型。

该根据网络请求失败异常生成运行日志的方案，根据网络请求失败异常的异常情况生成运行日志，以记录网络请求失败异常的异常情况，方面对网络请求失败异常的排查。

可以理解地，根据网络请求失败异常生成运行日志的方案中，用户已经进入目标应用程序或者已经登录至目标应用程序，则可以根据用户标识、错误码、网络请求等生成运行日志。

在一些场景中，用户还没有进入目标应用程序或者用户还没有登录至目标应用程序时，目标应用程序还没有启动运行日志读写模块，因此，目标应用程序不会生成运行日志。如出现启动异常时，即目标应用程序一启动就奔溃(crash)。在目前的技术中，获取不到该种场景下的运行日志。

在该种场景下，具体地，步骤102，即根据运行数据和用户标识，生成运行日志的步骤，包括：检测目标应用程序是否出现启动异常；若检测到目标应用程序出现启动异常，保存出现启动异常时的堆栈信息，并修改启动异常标志位；根据所保存的堆栈信息生成启动异常的运行日志，并将所生成的启动异常的运行日志保存在第一终端。如保存在第一终端的系统日志中，或者保存在预设目录的文件夹中。将系统日志所在的文件夹或者预设目录的文件夹都统称为启动异常文件夹。

其中，启动异常标志位，用户标识目标应用程序是否出现启动异常。启动异常标志位用两个数字或者两个字符串等来表示，如将启动异常标志位设置为0和1，或者，yes和no等。如将0和no表示启动正常，1和yes标识启动异常。若目标应用程序出现启动异常，将启动异常标志位从0或者no，修改为1或者yes，以标识目标应用程序启动出现异常。其中，堆栈信息会保存什么位置、什么原因导致的启动异常。由于堆栈信息下次启动时内容会发生变化，可能是另外一个堆栈信息了，因此，将发生启动异常时的堆栈信息进行保存，以确保可以得到启动异常的运行日志；另外将启动异常时的堆栈信息保存在本地，以为了可以获取该启动异常的运行日志。

在一些场景下，如个别用户出现的某些异常或者漏洞(简称为BUG)，开发人员没有设备或者环境重现这些BUG场景的情况下。具体地，步骤102，即根据运行数据和用户标识，生成运行日志的步骤，包括：获取所出现的异常或者漏洞信息；根据所出现的异常或者漏洞信息，以及用户标识，生成运行日志。

在一些场景中，有一些重要的参数数据，如直播首帧数据、直播音画不同步数据、卡顿数据、推送是否到达的数据、发送延迟和接收延迟等数据。将这些重要的参数数据收集以供开发人员进行进一步分析处理。具体地，步骤102，即根据运行数据和用户标识，生成运行日志的步骤，包括：检测参数数据；在检测到参数数据时，获取参数数据的数据内容；根据参数数据的数据内容和用户标识，生成运行日志。

可以理解地，除了系统日志外，运行日志的数据结构中都包括运行数据、用户标识、日志级别、当前时间戳等字段。根据场景的不同，运行数据字段也存在不同，如在某些场景中，运行数据字段包括网络请求、错误码等下级字段，在某些场景中，运行数据字段没有下级字段，只包括对应的内容，如预设参数数据的数据内容。需要说明的是，这些例举的字段并不构成对运行日志的数据结构的限定，只是为了方便理解本申请实施例中的方案，运行日志的数据结构还可以包括更多或者更少的字段。

103，根据预设的日志上传条件，从运行日志中确定待上传日志。

在本申请实施例中，预设的日志上传条件中包括多种不同的日志上传条件。根据预设的日志上传条件，从运行日志中选择出与预设的日志上传条件匹配的运行日志，并将所选择出的运行日志确定为待上传日志。

在一些场景中，具体地，步骤103，即根据预设的日志上传条件，从运行日志中确定待上传日志的步骤，包括：检测是否触发日志上传指令；若检测到触发日志上传指令，从运行日志中获取预设时间段的运行日志，确定为待上传日志。

其中，日志上传指令可通过用户触发。如检测到用户点击/触摸目标应用程序界面上对应的上传控件，则检测到触发日志上传指令。其中，预设时间段可以是触发日志上传指令当天内，也可以触发日志上传指令一天内，即24h内，还可以是触发日志上传指令1h内，还可以是其他的时间段。可以理解地，上传预设时间段内的运行日志，是因为考虑到一般用户遇到问题或者异常时，可能是由于前面的多个其他操作导致的；或者若仅上传问题或者异常对应的运行日志，则很难根据该运行日志定位出问题的原因所在。上传预设时间段内的运行日志，以提高后续开发人员定位问题的效率。

请参看图1f所示，在目标应用程序的界面上，存在“上传日志”的控件，若检测到用户点击/触摸该“上传日志”的控件，则检测到触发日志上传指令。

可以理解地，在该种情况下，用户可主动上传运行日志。如用户遇到问题时，可触发该日志上传指令，主动上传运行日志。如此，避免了用户遇到问题，反馈问题至开发人员时，开发人员再去获取运行日志时，用户已经离线，而无法及时获取运行日志的情况。另外，主动上传运行日志，也保证了日志上传的实时性。

在全链路日志的场景中，具体地，步骤103，即根据预设的日志上传条件，从运行日志中确定待上传日志的步骤，包括：检测运行日志中是否包括日志跟随标识；若包括日志跟随标识，确定为待上传日志。在一些实施例中也可以是：检测运行日志中的日志跟随标识是否不为空；若不为空，则确定为待上传日志。

可以理解地，在该种情况下，生成运行日志后，检测运行日志中是否包括日志跟随标识或者日志跟随标识是否不为空，若是，则将运行日志确定为待上传日志，并在步骤104中上传待上传日志。如此，可自动实时上传运行日志，保证了日志上传的实时性，提高了日志上传的效率，解决开发人员获取运行日志时，用户已经离线，不能及时的获取运行日志的问题；同时，利用日志跟随标识来跟随一条交互数据的链路信息(发送情况和接收情况)，会得到发送运行日志和接收运行日志，如此以得到交互数据的全链路日志，根据交互数据的全链路日志可排查多端交互时存在的异常，解决多端交互时存在异常的情况。

在设计网络请求失败异常的场景中，具体地，步骤103，即根据预设的日志上传条件，从运行日志中确定待上传日志的步骤，包括：获取运行日志的日志类型，该日志类型包括异常类型；将包括异常类型的运行日志确定为待上传日志，该异常类型包括网络请求失败异常。其中，待上传日志包括异常类型的运行日志，存在以下情况：待上传日志中仅包括异常类型的运行日志；待上传日志中包括异常类型的运行日志在内的多条运行日志，如包括异常类型的运行日志在内的预设时间段内的所有运行日志。上传多条运行日志以提高后续开发人员定位问题的效率。

可以理解地，在该种情况下，生成网络请求失败异常的运行日志后，将包括网络请求失败异常的运行日志确定为待上传日志，并在步骤104中上传待上传日志。如此，自动实时上传运行日志，保证了日志上传的实时性，提高了日志上传的效率。

在目标应用程序启动异常的场景中，具体地，步骤103，即根据预设的日志上传条件，从运行日志中确定待上传日志的步骤，包括：获取启动异常文件夹中的运行日志；将所获取的运行日志确定为待上传日志。其中，获取启动异常文件夹中的运行日志的步骤，包括：在检测到目标应用程序启动时，检测启动异常标志位是否标识为启动异常；若启动异常标志位标识启动异常，则获取启动异常文件夹中的运行日志。启动异常文件夹包括系统日志所在的文件夹或者预设目录的文件夹。其中，若启动异常文件夹为系统日志所在的文件夹，则从系统日志中获取目标应用程序的运行日志，将所获取的目标应用程序的运行日志确定为待上传日志。

若出现启动异常，在一实施例中，步骤103所实现的功能可通过日志捞取助手来实现。日志捞取助手可以是目标应用程序中一个模块，也可以是独立于目标应用程序的一个应用程序或者小程序等。

可以理解地，在目标应用程序启动异常，生成启动异常的运行日志后，下次再次启动时，将启动异常的运行日志确定为待上传日志，并在步骤104中上传待上传日志。如此，自动实时上传运行日志，保证了日志上传的实时性，提高了日志上传的效率；解决了目前无法获取目标应用程序启动异常的运行日志的问题。

在个别用户出现的某些异常或者漏洞的场景下，具体地，步骤103，即根据预设的日志上传条件，从运行日志中确定待上传日志的步骤，包括：获取运行日志的日志级别，以及目标日志级别；将日志级别为目标日志级别的运行日志确定为待上传日志。其中，获取目标日志级别的步骤，包括：接收服务器发送的日志获取指令；根据日志获取指令确定目标日志级别。

其中，运行日志包括多个不同的级别。如图1g所示，日志级别包括Debug级别、Info级别、Warn级别、Error级别、Key级别，可分别为1、2、3、4、5表示，或者用其他的字符串表示，分别对应的运行日志为DebugLog、InfoLog、WarnLog、ErrorLog、KeyLog。可以理解地，默认情况下，用户上传Error级别、Key级别的运行日志，但如果个别用户出现了某些异常或者漏洞，而开发人员没有设备或者环境重现这些异常或者漏洞的场景，则需要用户实时上传较为全面的运行日志信息，如所有级别的运行日志信息，以让开发人员进行定位分析。或者在某些情况下，开发人员需要获取某一类或者某几类的运行日志，则需要用户实时上传该某一类或者某几类的运行日志，以供开发人员进行定位分析。

如此，可通过开发人员所在的第二终端获取对应用户的运行日志，根据运行日志获取用户的用户标识，并设置第一终端需上传的运行日志的日志级别，根据所设置的需上传的运行日志的日志级别生成日志获取指令，并发送日志获取指令至服务器，服务器接收到日志获取指令后发送至第一终端，即出现某些异常或者漏洞的终端，以调整默认日志上传级别。或者直接通过服务器获取对应用户的运行日志，根据运行日志获取用户的用户标识，并设置第一终端需上传的运行日志的日志级别，根据所设置的日志级别生成日志获取指令，发送日志获取指令至第一终端，以调整默认日志上传级别。其中，需上传的运行日志的日志级别可以仅仅是其中一个级别，如Key级别，也可以包括其中的某几个日志级别，还可以包括所有日志级别等情况。第一终端接收服务器发送的日志获取指令；根据日志获取指令确定目标日志级别。由于该日志获取指令中包括所设置的需上传的运行日志的日志级别，则获取日志获取指令中的需上传的运行日志的日志级别，将该日志级别确定为目标日志级别。

进一步地，第二终端或者服务器除了可设置需上传的运行日志的日志级别之外，还可设置需上传的运行日志的日志级别的上传时间，根据所设置的需上传的运行日志的日志级别和上传时间生成日志获取指令。如此，日志获取指令中除了包括所设置的需上传的运行日志的日志级别，还包括所设置的上传时间。其中，需上传的运行日志的上传时间可以通过两个时间来设置，如2018.1.1，2018.3.1，还可以具体到分或者秒等。该两个时间可以是(历史时间，当前时间)、(历史时间，未来时间)、(当前时间，未来时间)等情况。需上传的运行日志的上传时间还可以通过一个时间和一个时长来设置，该时间可以是历史时间、当前时间、未来时间的任意一种，表示将从该时间开始，该时长内对应的运行日志确定为待上传日志。

对应地，根据预设的日志上传条件，从运行日志中确定待上传日志的步骤，包括：获取运行日志的日志级别，以及目标日志级别和目标上传时间；将目标上传时间内的日志级别为目标日志级别的运行日志确定为待上传日志。其中，获取目标日志级别和目标上传时间的步骤，包括：接收服务器发送的日志获取指令；根据日志获取指令确定目标日志级别和目标上传时间。其中，根据日志获取指令确定目标日志级别和目标上传时间的步骤，包括：获取日志获取指令中的需上传的运行日志的日志级别和上传时间；将所获取的需上传的运行日志的日志级别确定为目标日志级别，将该上传时间确定为目标上传时间。如此，以将目标日志级别的运行日志的上传时间确定为目标上传时间，即将待上传日志的上传时间确定为目标上传时间。可以理解地，不是所有时刻都将目标日志级别的运行日志确定为待上传日志，而是只将在目标上传时间内的目标日志级别的运行日志确定为待上传日志。

进一步地，若目标上传时间通过(当前时间，未来时间)来设置，即将从当前时间到该未来时间截止的目标日志级别的运行日志确定为待上传日志。或者目标上传时间通过当前时间和时长来设置，即将从当前时间开始，该时长内的目标日志级别的运行日志确定为待上传日志。在这些情况下，待上传日志随着时间的推移而产生，为了减少待上传日志上传的次数，以进一步减少与服务器的交互，在第一终端中设置一计时器。

如此，根据预设的日志上传条件，从运行日志中确定待上传日志的步骤，包括：启动计时器；获取运行日志的日志级别，以及目标日志级别和目标上传时间；检测当前时间是否在目标上传时间内；若当前时间在目标上传时间内，检测当前计时器的计时时间是否达到预设时间；若达到预设时间，将所保存的日志级别为目标日志级别的运行日志确定为待上传日志，并重置计时器。可以理解地，若当前时间不在目标上传时间内，则将日志级别为默认日志级别的运行日志确定为待上传日志。其中，日志级别为目标日志级别的运行日志可保存在缓存中。在该种情况下，通过第一终端的计时器在目标上传时间内来控制确定以及上传待上传日志的时间点，以及通过第一终端来确定当前时间是否在目标上传时间内。

如图1f所示，在图1f中，第一终端中设置一计时器。在目标上传时间内，若计时器的时间达到预设时间，则将保存在缓存中的、日志级别为目标日志级别的运行日志确定为待上传日志，并上传至服务器。

在上述设置有目标上传时间的方案中，在日志获取指令中包括有目标上传时间，在一些情况下，虽然设置有目标上传时间，但将该目标上传时间保存在服务器中。在日志获取指令中包括目标日志级别，而不包括目标上传时间。如此，服务器接收第一终端上传的待上传日志；判断当前时间是否在目标上传时间内；若在目标上传时间内，则向第一终端发送日志获取指令，该日志获取指令中包括目标日志级别；若不再目标上传时间内，则向第一终端发送日志获取指令，该日志获取指令中包括默认日志级别。如此，由服务器端来确定当前时间是否在目标上传时间内。

可以理解地，上述涉及目标日志级别的方案中，实现了实时修改用户的日志上传级别，如此，可实时上传用户对应的运行日志。如可实时上传用户全面的运行日志，解决了开发人员没有设备或者环境重现个别用户出现的某些异常或者漏洞的问题。另外，自动实时上传对应的运行日志，保证了日志上传的实时性，提高了日志上传的效率。

在涉及重要参数数据的场景中，将其中一些重要参数数据或者全部重要参数数据作为预设参数数据。具体地，步骤103，即根据预设的日志上传条件，从运行日志中确定待上传日志的步骤，包括：获取运行日志的数据内容，以及目标数据内容；将数据内容中包括目标数据内容的运行日志确定为待上传日志。其中，目标数据内容包括一个或者多个预设参数数据所对应的数据内容。将数据内容中包括目标数据内容的运行日志确定为待上传日志。或者也可以理解为，只要运行日志的数据内容中包括一个或者多个预设参数数据，就将该运行日志确定为待上传日志。其中，包括预设参数数据的数据内容的运行日志包括：仅包括预设参数数据的数据内容的运行日志；包括预设参数数据的数据内容在内的多条运行日志，如包括预设参数数据的数据内容的运行日志在内的预定时间段内的所有运行日志。上传多条运行日志以提高后续开发人员定位问题的效率。

可以理解地，在该种情况下，将数据内容中包括有目标数据内容的运行日志确定为待上传日志，并在步骤104中上传待上传日志。如此，自动实时上传运行日志，保证了日志上传的实时性，提高了日志上传的效率。

进一步地，服务器在接收到多个第一终端发送运行日志(数据内容中包括预设参数数据的数据内容)后，将预设参数数据的数据内容进行统计处理，以得到预设指标数据，其中，预设指标数据包括直播音画不同步率、卡顿率、推送到达率和延迟时间等。如求取多个第一终端中的发送延迟时间的平均值，将该平均值作为总延迟时间；判断计算出的总延迟时间是否大于预设延迟时间；若大于预设延迟时间，则发送告警提示至开发人员所在的第二终端，如此，以实现实现重要参数数据的实时检测报警。

104，上传待上传日志。

上传待上传日志，可通过HTTP协议(HyperText Transfer Protocol，超文本传输协议)上传。即第一终端和服务器建立HTTP连接，以通过HTTP协议上传待上传日志。由于建立的HTTP连接是单条连接，不影响第一终端与服务器之间的其他连接请求。如图1e、图1g所示。

具体地，步骤104，即上传待上传日志的步骤，包括：将待上传日志上传至区块链。将待上传日志上传至区块链，以通过区块链来保存所上传的运行日志。如根据待上传日志生成保存请求，该保存请求用于将待上传日志上传并保存至区块链，将该保存请求发送至区块链的节点设备上，节点设备验证保存请求的有效性，并对有效的保存请求完成共识后记录到存储上。

本申请实施例中所例举的场景，几乎覆盖日志上传的所有场景，解决了背景技术中的用户离线问题，以及无法重现第一终端的设备或者环境而导致的无法定位外网问题的困境，同时也解决了多端交互问题的定位，和启动异常无法上传对应的运行日志的问题等。本申请实施例中的日志上传方法适用于所有项目的运行日志上传。且本申请实施例中的日志上传方法可根据预设的日志上传条件实时上传用户对应的运行日志，自动实时上传对应的运行日志，保证了日志上传的实时性，提高了日志上传的效率。

根据上述实施例所描述的方法，本实施例将从日志上传装置的角度进一步进行描述，该日志上传装置具体可以作为独立的实体来实现，也可以集成在第一终端或者业务服务器中来实现。

如图2a所示，该日志上传装置包括用于执行上述图1c中的日志上传方法所对应的单元。该装置可以包括获取单元201、生成单元202、确定单元203、以及上传单元204。

获取单元201，用于获取目标应用程序的运行数据以及用户标识。

生成单元202，用于根据运行数据和用户标识，生成运行日志。

具体地，图2b所示，生成单元202，包括：第一检测单元2021、目标数据确定单元2022、第一生成单元2023。其中，第一检测单元2021，用于检测日志跟随标识。目标数据确定单元2022，用于在检测到日志跟随标识时，确定日志跟随标识对应的目标运行数据。第一生成单元2023，用于根据目标运行数据，以及用户标识生成运行日志。

具体地，生成单元202，还包括：失败检测单元、第二生成单元。其中，失败检测单元，用于检测是否接收到目标应用程序出现网络请求失败异常所对应的错误码。第二生成单元，用于若接收到目标应用程序出现网络请求失败异常所对应的错误码，根据网络请求、错误码以及用户标识生成网络请求失败异常的运行日志。

具体地，生成单元202，还包括：启动异常检测单元、保存修改单元、第三生成单元。其中，启动异常检测单元，用于检测目标应用程序是否出现启动异常。保存修改单元，用于若检测到目标应用程序出现启动异常，保存出现启动异常时的堆栈信息，并修改启动异常标志位。第三生成单元，用于根据所保存的堆栈信息生成启动异常的运行日志，并将所生成的启动异常的运行日志保存在第一终端。

具体地，生成单元202，还包括：信息获取单元、第四生成单元。其中，信息获取单元，用于获取所出现的异常或者漏洞信息。第四生成单元，用于根据所出现的异常或者漏洞信息，以及用户标识，生成运行日志。

具体地，生成单元202，还包括：第二检测单元、第一内容获取单元、第五生成单元。其中，第二检测单元，用于检测参数数据。第一内容获取单元，用于在检测到参数数据时，获取参数数据的数据内容。第五生成单元，用于根据参数数据的数据内容和用户标识，生成运行日志。

确定单元203，用于根据预设的日志上传条件，从运行日志中确定待上传日志。

具体地，确定单元203，包括：标识检测单元、第一确定单元。其中，标识检测单元，用于检测运行日志中是否包括日志跟随标识。第一确定单元，用于若运行日志中包括日志跟随标识，确定为待上传日志。

具体地，确定单元203，还包括：类型获取单元、第二确定单元。其中，类型获取单元，用于获取运行日志的日志类型，该日志类型包括异常类型。第二确定单元，用于将包括异常类型的运行日志确定为待上传日志，该异常类型包括网络请求失败异常。

具体地，确定单元203，还包括：文件夹获取单元、第三确定单元。其中，文件夹获取单元，用于获取启动异常文件夹中的运行日志。第三确定单元，用于将所获取的运行日志确定为待上传日志。

具体地，确定单元203，还包括：级别获取单元、第四确定单元。其中，级别获取单元，用于获取运行日志的日志级别，以及目标日志级别。第四确定单元，用于将日志级别为目标日志级别的运行日志确定为待上传日志。其中，级别获取单元，包括目标级别获取单元。目标级别获取单元，用于获取目标日志级别。目标级别获取单元，具体用于接收服务器发送的日志获取指令；根据日志获取指令确定所述目标日志级别。

具体地，确定单元203，还包括：第二内容获取单元、第五确定单元。其中，第二内容获取单元，用于获取运行日志的数据内容，以及目标数据内容。第五确定单元，用于将数据内容中包括目标数据内容的运行日志确定为待上传日志。

具体地，确定单元203，还包括：指令检测单元、第六上传单元。其中，指令检测单元，用于检测是否触发日志上传指令。第六上传单元，用于若检测到触发日志上传指令，从运行日志中获取预设时间段的运行日志，确定为待上传日志。

上传单元204，用于上传待上传日志。上传单元204，具体用于将待上传日志上传至区块链。

具体实施时，以上各个单元可以作为独立的实体来实现，也可以进行任意组合，作为同一或若干个实体来实现。以上装置和各单元的具体实现过程，以及所达到的有益效果，可以参考前述应用于区块链的节点中的方法实施例中的相应描述，为了描述的方便和简洁，在此不再赘述。

本申请实施例还提供一种计算机设备，如图3所示，其示出了本申请实施例所涉及的计算机设备的结构示意图，具体来讲：

该计算机设备可以包括一个或者一个以上处理核心的处理器301、一个或一个以上计算机可读存储介质的存储器302、射频(Radio Frequency，RF)电路303、电源304、输入单元305、以及显示单元306等部件。本领域技术人员可以理解，图中示出的计算机设备结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

处理器301是该计算机设备的控制中心，利用各种接口和线路连接整个计算机设备的各个部分，通过运行或执行存储在存储器302内的计算机程序，如软件程序和/或模块，以及调用存储在存储器302内的数据，执行计算机设备的各种功能和处理数据，从而对计算机设备进行整体检测。可选的，处理器301可包括一个或多个处理核心；优选的，处理器301可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器301中。

存储器302可用于存储软件程序以及模块，处理器301通过运行存储在存储器302的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器302可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据计算机设备的使用所创建的数据等。此外，存储器302可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器302还可以包括存储器控制器，以提供处理器301对存储器302的访问。

RF电路303可用于收发信息过程中，信号的接收和发送，特别地，将基站的下行信息接收后，交由一个或者一个以上处理器301处理；另外，将涉及上行的数据发送给基站。通常，RF电路303包括但不限于天线、至少一个放大器、调谐器、一个或多个振荡器、用户身份模块(SIM)卡、收发信机、耦合器、低噪声放大器(LNA，Low Noise Amplifier)、双工器等。此外，RF电路303还可以通过无线通信与网络和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(GSM，Global System of Mobilecommunication)、通用分组无线服务(GPRS，General Packet Radio Service)、码分多址(CDMA，Code Division Multiple Access)、宽带码分多址(WCDMA，Wideband CodeDivision Multiple Access)、长期演进(LTE，Long Term Evolution)、电子邮件、短消息服务(SMS，Short Messaging Service)等。

计算机设备还包括给各个部件供电的电源304(比如电池)，优选的，电源304可以通过电源管理系统与处理器301逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源304还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

该计算机设备还可包括输入单元305，该输入单元305可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。具体地，在一个具体的实施例中，输入单元305可包括触敏表面以及其他输入设备。触敏表面，也称为触摸显示屏或者触控板，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触敏表面上或在触敏表面附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触敏表面可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器301，并能接收处理器301发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触敏表面。除了触敏表面，输入单元305还可以包括其他输入设备。具体地，其他输入设备可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

该计算机设备还可包括显示单元306，该显示单元306可用于显示由用户输入的信息或提供给用户的信息以及计算机设备的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。显示单元306可包括显示面板，可选的，可以采用液晶显示器(LCD，Liquid Crystal Display)、有机发光二极管(OLED，Organic Light-Emitting Diode)等形式来配置显示面板。进一步的，触敏表面可覆盖显示面板，当触敏表面检测到在其上或附近的触摸操作后，传送给处理器301以确定触摸事件的类型，随后处理器301根据触摸事件的类型在显示面板上提供相应的视觉输出。虽然在图中，触敏表面与显示面板是作为两个独立的部件来实现输入和输入功能，但是在某些实施例中，可以将触敏表面与显示面板集成而实现输入和输出功能。

尽管未示出，计算机设备还可以包括摄像头、蓝牙模块等，在此不再赘述。具体在本实施例中，计算机设备中的处理器301会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器302中，并由处理器301来运行存储在存储器302中的应用程序，从而实现各种功能，如下：

获取目标应用程序的运行数据以及用户标识；

根据所述运行数据和所述用户标识，生成运行日志；

根据预设的日志上传条件，从所述运行日志中确定待上传日志；

上传所述待上传日志。

该计算机设备可以实现本申请实施例所提供的应用于第一终端和业务服务器中的日志上传方法任一实施例中的步骤，因此，可以实现本申请实施例所提供的应用于第一终端和业务服务器中的任一日志上传方法所能实现的有益效果，详见前面的实施例，在此不再赘述。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。为此，本发明实施例提供一种存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本发明实施例所提供的应用于第一终端和业务服务器中的日志上传方法任一实施例的步骤。

其中，该存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、磁盘或光盘等。

由于该存储介质中所存储的指令，可以执行本发明实施例所提供的任一日志上传方法实施例中的步骤，因此，可以实现本发明实施例所提供的任一日志上传方法所能实现的有益效果，详见前面的实施例，在此不再赘述。

以上对本申请实施例所提供的一种日志上传方法、装置、计算机设备以及存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种日志上传方法，其特征在于，包括：

获取目标应用程序的运行数据以及用户标识；

若所述目标应用程序正常启动，则根据所述运行数据、所述用户标识和当前时间，生成不同日志类型和不同日志级别的运行日志，所述运行日志的日志类型包括：异常类型和正常类型，正常类型的日志包括：交互数据的运行日志和/或参数数据的运行日志，异常类型的运行日志包括：网络请求失败异常的运行日志；所述日志级别包括目标日志级别，所述目标日志级别的运行日志包括用户异常或者漏洞的运行日志；

根据预设的日志上传条件，从所述运行日志中确定与所述日志上传条件匹配的待上传日志，所述日志上传条件包括检测到用户触发日志上传指令、检测到交互数据对应的日志跟随标识和/或接收到服务器发送的日志获取指令，所述所述日志上传指令携带目标日志级别和目标上传时间；

若所述目标应用程序启动异常，则根据出现启动异常时的堆栈信息生成应用启动异常日志；

基于预设日志捞取程序从所述运行日志中确定所述应用启动异常日志作为待上传日志，所述日志捞取程序独立于所述目标应用程序；

基于第一终端与服务器之间的单条链路，上传所述待上传日志；

根据所述运行数据和所述用户标识，生成交互数据的运行日志，包括：

检测日志跟随标识；

在检测到所述日志跟随标识时，确定所述日志跟随标识对应的目标运行数据；

根据所述目标运行数据，以及所述用户标识生成交互数据的运行日志。

2.如权利要求1所述的日志上传方法，其特征在于，所述根据所述运行数据和所述用户标识，生成运行日志的步骤，包括：

检测日志跟随标识；

在检测到所述日志跟随标识时，确定所述日志跟随标识对应的目标运行数据；

根据所述目标运行数据，以及所述用户标识生成运行日志。

3.如权利要求2所述的日志上传方法，其特征在于，所述根据预设的日志上传条件，从所述运行日志中确定待上传日志的步骤，包括：

检测所述运行日志中是否包括所述日志跟随标识；

若包括所述日志跟随标识，确定为待上传日志。

4.如权利要求2所述的日志上传方法，其特征在于，所述检测日志跟随标识的步骤，包括：

检测是否生成日志跟随标识；

在检测到生成所述日志跟随标识时，确定检测到所述日志跟随标识。

5.如权利要求2所述的日志上传方法，其特征在于，所述检测日志跟随标识的步骤，包括：

检测是否接收到交互请求；

在检测到所述交互请求时，确定检测到所述日志跟随标识。

6.如权利要求1所述的日志上传方法，其特征在于，所述根据预设的日志上传条件，从所述运行日志中确定待上传日志，包括：

获取所述运行日志的日志类型，所述日志类型包括异常类型；

将包括所述异常类型的运行日志确定为待上传日志，所述异常类型包括网络请求失败异常。

7.如权利要求1所述的日志上传方法，其特征在于，所述根据预设的日志上传条件，从所述运行日志中确定待上传日志，包括：

获取启动异常文件夹中的运行日志；

将所获取的运行日志确定为待上传日志。

8.如权利要求1所述的日志上传方法，其特征在于，所述根据预设的日志上传条件，从所述运行日志中确定待上传日志，包括：

获取所述运行日志的日志级别，以及目标日志级别；

将所述日志级别为目标日志级别的运行日志确定为待上传日志。

9.如权利要求1-8任一所述的日志上传方法，其特征在于，所述上传所述待上传日志，包括：

将所述待上传日志上传至区块链。

10.一种日志上传装置，其特征在于，包括：

获取单元，获取目标应用程序的运行数据以及用户标识；

第一生成单元，若所述目标应用程序正常启动，则根据所述运行数据、所述用户标识和当前时间，生成不同日志类型和不同日志级别的运行日志，所述运行日志的日志类型包括异常类型和正常类型，正常类型的运行日志包括：交互数据的运行日志、参数数据的运行日志，异常类型的运行日志包括：网络请求失败异常的运行日志；所述日志级别包括目标日志级别，所述目标日志级别的运行日志包括用户异常或者漏洞的运行日志；

第一确定单元，根据预设的日志上传条件，从所述运行日志中确定与所述日志上传条件匹配的待上传日志，所述日志上传条件包括检测到用户触发日志上传指令、检测到交互数据对应的日志跟随标识、接收到服务器发送的日志获取指令，所述日志获取指令携带目标日志级别和目标上传时间；

第二生成单元，若所述目标应用程序启动异常，则根据出现启动异常时的堆栈信息生成应用启动异常日志；

第二确定单元，基于预设日志捞取程序从所述运行日志中确定所述应用启动异常日志作为待上传日志，所述日志捞取程序独立于所述目标应用程序；

上传单元，基于第一终端与服务器之间的单条链路，上传所述待上传日志；

所述第一生成单元包括交互数据生成子单元，交互数据生成子单元，用于：

检测日志跟随标识；

在检测到所述日志跟随标识时，确定所述日志跟随标识对应的目标运行数据；

根据所述目标运行数据，以及所述用户标识生成交互数据的运行日志。