一种日志数据发送方法及装置与流程

本申请涉及网页技术领域，具体而言，涉及一种日志数据发送方法及装置。

背景技术：

在合法帮助企业收集其用户非敏感数据的服务中，通常要将用户在浏览企业网站的操作行为的日志统一发送到第三方的服务器，第三方在收集日志之后，对日志中的数据进行清洗和计算分析。其中，数据传输的形式以单向为主，不需要第三方对中间的处理过程进行反馈，只返回结果。

现有技术中，在网页领域进行数据传输的相关方式主要由xmlhttprequest(一种应用程序接口函数集调用请求)对象提供对http(hypertexttransferprotocol，超文本传输协议)的完全访问。而xmlhttprequest对象存在一些问题：部分浏览器与xmlhttprequest对象不能直接兼容；由于浏览器的同源策略，xmlhttprequest对象不能进行跨域传输；在页面关闭时，xmlhttprequest对象正在进行的数据传输会被取消。

技术实现要素：

有鉴于此，本申请的目的在于提供一种日志数据发送方法及装置，用于解决现有技术中浏览器上传日志数据的稳定性差的问题。

第一方面，本申请实施例提供了一种日志数据发送方法，该方法包括：

接收到针对目标网页的操作指令，生成所述操作指令对应的操作日志；

将所述操作日志转换成日志键值对，并将所述日志键值对存储在所述目标网页中工具图片的资源地址下；

将所述资源地址下的日志键值对发送至所述资源地址对应的日志服务器。

根据第一方面，本申请实施例提供了第一方面的第一种可能的实施方案，其中，将所述操作日志转换成日志键值对，并将所述日志键值对存储在所述目标网页中工具图片的资源地址下之前，还包括：

在所述目标网页的属性中实例化一个工具图片；

获取日志服务器的服务器地址，并将该服务器地址配置为所述工具图片的资源地址。

根据第一方面，本申请实施例提供了第一方面的第二种可能的实施方案，其中，将所述日志键值对发送至所述资源地址对应的日志服务器之后，还包括：

对所述工具图片的加载状态进行监听；

若监听到所述工具图片的加载状态为加载成功，确认所述日志键值对发送成功。

根据第一方面的第二种可能的实施方案，本申请实施例提供了第一方面的第三种可能的实施方案，其中，确认所述日志键值对发送成功之后，还包括：

将所述工具图片设置为失效状态；

实例化一个新的工具图片，并将目标网页的属性中的日志发送请求次数设置为0。

根据第一方面的第二种可能的实施方案，本申请实施例提供了第一方面的第四种可能的实施方案，其中，还包括：

若监听到所述工具图片的加载状态为加载失败，确认所述日志键值对发送失败；

查询目标网页的属性中的日志发送请求次数是否小于预设次数；

若所述日志发送请求次数小于预设次数，重新将所述日志键值对发送至所述资源地址对应的日志服务器。

根据第一方面的第四种可能的实施方案，本申请实施例提供了第一方面的第五种可能的实施方案，其中，还包括：

若所述日志发送请求次数等于预设次数，将所述工具图片设置为失效状态；

实例化一个新的工具图片，并将目标网页的属性中的日志发送请求次数设置为0。

第二方面，本申请实施例提供了一种日志数据发送装置，该装置包括：

生成模块，用于接收到针对目标网页的操作指令，生成所述操作指令对应的操作日志；

处理模块，用于将所述操作日志转换成日志键值对，并将所述日志键值对存储在所述目标网页中工具图片的资源地址下；

发送模块，用于将所述资源地址下的日志键值对发送至所述资源地址对应的日志服务器。

根据第二方面，本申请实施例提供了第二方面的第一种可能的实施方案，其中，所述发送模块包括：

监听单元，用于对所述工具图片的加载状态进行监听；若监听到所述工具图片的加载状态为加载成功，确认所述日志键值对发送成功。

第三方面，本申请实施例提供了一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述第一方面及其可能的实施方案中任一项所述的方法的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述第一方面及其可能的实施方案中任一项所述的方法的步骤。

本申请实施例提出的一种日志数据发送方法，通过生成用户对浏览器的操作指令对应的操作日志，以日志键值对的形式将日志存储在目标网页中预先实例化的工具图片的资源地址下，以将日志键值对发送至资源地址对应的日志服务器。本申请实施例所提出的日志数据发送方法保障了日志发送的准确性、完整性，避免了页面关闭导致的日志发送取消，从而提高了日志数据的传输稳定性。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种日志数据发送方法的流程示意图；

图2为本申请实施例提供的一种日志数据发送方法的流程示意图；

图3为本申请实施例提供的一种日志数据发送装置的结构示意图；

图4为本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例提供了一种日志数据发送方法，如图1所示，包括以下步骤：

步骤s101、接收到针对目标网页的操作指令，生成上述操作指令对应的操作日志；

步骤s102、将上述操作日志转换成日志键值对，并将上述日志键值对存储在上述目标网页中工具图片的资源地址下；

步骤s103、将上述资源地址下的日志键值对发送至上述资源地址对应的日志服务器。

具体地，在用户访问指定的网站时，对该网站的网页窗口中的任意点击都会生成一个操作指令，浏览器作为监测端在接收到该操作指令后会生成一个操作日志，监测端将该操作日志转化为日志键值对(key、value等的形式)，并将该键值对存储在预先在网页中设置好的工具图片的资源项src(source)下的资源地址url(uniformresourcelocator,统一资源定位符)中。

之所以存储在工具图片中，是因为当进行网页跳转，也就是当前的网页卸载的时候，图片文件不会立刻卸载，并且通过图片文件发送数据也不受浏览器同源策略的限制，兼容性较好。

网页在加载该工具图片的时候会向服务器发起请求发送该工具图片的资源项src下的资源地址url中存储的数据，也就是将日志键值对发送给服务器。

通过使用工具图片(image对象)而不是使用xmlhttprequest对象来进行用户行为日志数据的发送，可以避免用户终端兼容性问题导致的日志不完整，可以避免xmlhttprequest对象所受到的浏览器同源策略的限制，还可以避免因页面关闭事件带来的日志发送取消问题，进一步地简化监测源码的简洁性。从而保障日志发送的准确性、完整性，并且针对工具图片的状态监听和加载异常时的应对机制做了具体优化，进一步提升日志发送的稳定性。

在一可选的实施例中，步骤s102、将上述操作日志转换成日志键值对，并将上述日志键值对存储在上述目标网页中工具图片的资源地址下之前，还包括：

步骤104、在上述目标网页的属性中实例化一个工具图片；

步骤105、获取日志服务器的服务器地址，并将该服务器地址配置为上述工具图片的资源地址。

具体地，工具图片是在网页中实例化的一个0像素的图片，作为网页的一个属性存在。在用户通过浏览器打开指定网站(添加了包含在网页中实例化该工具图片的监测服务代码的网站)时，在页面中加载该工具图片，由于该工具图片是0像素的，所以用户在网页中时看不到该工具图片的。

该工具图片的资源地址url是需要通过所要使用的日志服务器来进行配置的，也就是将该工具图片的资源地址url设置为日志服务器的url，以便将日志发送到指定的日志服务器。

在一可选的实施例中，步骤s103、将上述日志键值对发送至上述资源地址对应的日志服务器之后，如图2所示，还包括：

步骤s106、对上述工具图片的加载状态进行监听；

步骤s107、若监听到上述工具图片的加载状态为加载成功，确认上述日志键值对发送成功。

具体地，通过使用工具图片发送日志键值对是通过该工具图片在网页中的加载来进行的，因此日志键值对的发送状态与该工具图片的加载状态是相关联的。

监测端通过监测工具图片的加载状态就能间接确认日志键值对的发送情况。当监听到工具图片的onload事件(页面加载事件)，表示该工具图片加载成功，证明该键值对发送成功。

在一可选的实施例中，步骤s107、确认上述日志键值对发送成功之后，如图2所示，还包括：

步骤s108、将上述工具图片设置为失效状态；

步骤s109、实例化一个新的工具图片，并将目标网页的属性中的日志发送请求次数设置为0。

具体地，在工具图片完成了存储的用户的操作指令对应的日志键值对的发送之后，该工具图片被设置为失效状态(null)，然后监测端会在网页中实例化一个新的工具图片，以监测下一个操作请求以及对应的日志键值对的发送。在实例化新的工具图片的同时，将网页的属性中的通过工具图片进行日志键值对发送的日志发送请求次数置为0。

在一可选的实施例中，如图2所示，还包括：

步骤s110、若监听到上述工具图片的加载状态为加载失败，确认上述日志键值对发送失败；

步骤s111、查询目标网页的属性中的日志发送请求次数是否小于预设次数；

步骤s112、若上述日志发送请求次数小于预设次数，重新将上述日志键值对发送至上述资源地址对应的日志服务器。

具体地，当监测端监听到工具图片的onerror事件(加载失败事件)时，确认日志键值对发送失败，这时需要查询目标网页属性中的日志发送请求次数。由于在通常的情况下，如果发送多次仍失败就说明可能是网络环境或是日志服务器出现故障等情况导致的，这类状态下如果持续尝试发送会加大监测端的负荷，并且也会影响下一个操作请求的日志发送，所以需要设定一个重新尝试发送日志键值对的次数上限，也就是预设次数，优选地，这里预设次数设定为3。如果通过上述工具图片发送日志键值对的次数小于预设次数，就重新尝试发送日志键值对到资源地址对应的日志服务器，并将日志发送请求次数的数据加1。

在一可选实施例中，如图2所示，还包括：

步骤s113、若上述日志发送请求次数等于预设次数，将上述工具图片设置为失效状态；

步骤s114、实例化一个新的工具图片，并将目标网页的属性中的日志发送请求次数设置为0。

具体地，当监测端发现通过工具图片发送日志键值对的次数达到了3次，监测端就确认是由于外在因素导致的日志键值对发送失败，并放弃当前的日志键值对的发送，将当前的工具图片设置为失效状态，然后监测端在网页中实例化一个新的工具图片，以开始监测下一个操作请求以及对应的日志键值对的发送。同时，将网页的属性中的通过工具图片进行日志键值对发送的日志发送请求次数置为0。

本申请是实施例提供了一种日志数据发送装置，如图3所示，该装置包括：

生成模块30，用于接收到针对目标网页的操作指令，生成上述操作指令对应的操作日志；

处理模块31，用于将上述操作日志转换成日志键值对，并将上述日志键值对存储在上述目标网页中工具图片的资源地址下；

发送模块32，用于将上述资源地址下的日志键值对发送至上述资源地址对应的日志服务器。

在一可选的实施例中，上述发送模块32包括：

监听单元321，用于对上述工具图片的加载状态进行监听；若监听到上述工具图片的加载状态为加载成功，确认上述日志键值对发送成功。

对应于图1中的一种日志数据发送方法，本申请实施例还提供了一种计算机设备400，如图4所示，该设备包括存储器401、处理器402及存储在该存储器401上并可在该处理器402上运行的计算机程序，其中，上述处理器402执行上述计算机程序时实现上述一种日志数据发送方法。

具体地，上述存储器401和处理器402能够为通用的存储器和处理器，这里不做具体限定，当处理器402运行存储器401存储的计算机程序时，能够执行上述一种日志数据发送方法，解决了现有技术中浏览器上传日志数据的稳定性差的问题。

对应于图1中的一种日志数据发送方法，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述一种日志数据发送方法的步骤。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述一种日志数据发送方法，解决了现有技术中浏览器上传日志数据的稳定性差的问题，本申请实施例提出的一种日志数据发送方法，通过生成用户对浏览器的操作指令对应的操作日志，以日志键值对的形式将日志存储在目标网页中预先实例化的工具图片的资源地址下，以将日志键值对发送至资源地址对应的日志服务器。本申请实施例所提出的日志数据发送方法保障了日志发送的准确性、完整性，避免了页面关闭导致的日志发送取消，从而提高了日志数据的传输稳定性。

在本申请所提供的实施例中，应该理解到，所揭露方法和装置，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释，此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围。都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。