CN108156006B - 一种埋点数据上报方法、装置及电子设备 - Google Patents

Abstract

本申请公开了一种埋点数据上报方法、装置及电子设备，两种埋点数据处理方法、装置及电子设备，以及两种埋点数据处理***。其中，所述埋点数据上报方法包括：将页面中被触发的埋点存储到待发送的埋点队列；在预设条件成立时，通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样，形成所述页面的埋点数据包；向服务器发送针对该页面的埋点数据处理请求，所述埋点数据处理请求包括所述埋点数据包。采用本申请提供的方法，对埋点队列中的多个埋点进行动态采样，批量上报埋点数据，避免向服务器发送过多的请求；因此，可以兼顾上报足够的埋点数据及保证客户端性能两方面。

Description

一种埋点数据上报方法、装置及电子设备

技术领域

本申请涉及页面监控技术领域，具体涉及一种埋点数据上报方法。本申请同时涉及一种埋点数据上报装置及电子设备，两种埋点数据处理方法、装置及电子设备，以及两种埋点数据处理***。

背景技术

互联网中的很多Web应用并不是独立存在的，也无法独立工作，而是相互交织在一起形成一个整体，这意味着只要其中任何一个Web应用出现问题，就可能导致其它Web应用无法工作。因此，对于Web应用的运行状态进行监控是至关重要的环节。根据运行环境，一个Web应用可分为两部分：客户端和服务端；其中，服务端在服务器上运行，运行环境单一且容易监控，而客户端则完全不同，由于移动时代的到来，用户逐渐从个人电脑迁移到手机等移动设备，用户的终端类型及网络状态等因素都会对Web应用的运行产生影响，因此，必须将客户端的运行情况上报，经过汇总、分析处理后才能得出应用整体的运行情况，这其中每一环都充满了困难与挑战。

为了能够采集到客户端的运行情况数据，需要在页面的关键位置处进行埋点处理，通过埋点可获取页面运行状况，以实现对客户端的监控。目前普遍的埋点数据上报及报警方案是，直接在客户端通过固定比率抽样上报，然后根据上报数据总量是否达到一个固定数值来判断是否触发告警。这种处理方式，将不可避免的产生如下问题：

1)不能合理利用客户端能力，在需要发送的数据量大时，会发送过多请求，从而减慢页面加载，降低用户体验，如果发送数据量少又会导致样本量不足，从而影响报警信息的准确度。

2)由于固定采样比，会导致部分数据量少的埋点的发送机会被数据量大的埋点抢占，导致服务端无法收到足够的埋点数据。

3)稳定性算法(埋点告警算法)的计算模型简单，主要是根据固定阀值来计算，无法结合历史流量和变化趋势进行评估，容易出现由于业务形态的不同而导致误报的情况。

因此，如何研究和开发出一种新的埋点数据上报方式，其能够兼顾上报足够的埋点数据及保证客户端性能两方面成为本领域技术人员迫切需要解决的问题。

发明内容

本申请提供一种埋点数据上报方法，以解决现有技术无法兼顾上报足够的埋点数据及保证客户端性能两方面的问题。本申请另外提供一种埋点数据上报装置及电子设备，两种埋点数据处理方法、装置及电子设备，以及两种埋点数据处理***。

本申请提供一种埋点数据上报方法，包括：

将页面中被触发的埋点存储到待发送的埋点队列；

在预设条件成立时，通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样，形成所述页面的埋点数据包；

向服务器发送针对所述页面的埋点数据处理请求，所述埋点数据处理请求包括所述埋点数据包。

可选的，所述埋点的类型包括普通类型或错误类型；

所述预设的动态采样算法包括：

从所述埋点队列中随机抽取普通类型的埋点；以及，从所述埋点队列中随机抽取错误类型的埋点；

以传输协议允许的请求数据包最大长度为限制，对抽取出的普通类型的埋点对应的序列化字符串进行最大限度拼接，获得普通类型的采样埋点数据包；以及，对抽取出的错误类型的埋点对应的序列化字符串进行最大限度拼接，获得错误类型的采样埋点数据包；

根据所述普通类型的采样埋点数据包和埋点采样比，生成第一数据包，所述埋点采样比是指普通类型的埋点总数量与成功拼接的埋点数量的比值；以及，根据所述错误类型的采样埋点数据包，生成第二数据包；

所述向服务器发送针对所述数据包的埋点数据处理请求，包括：

向所述服务器发送针对所述页面的第一埋点数据处理请求，所述第一埋点数据处理请求包括所述第一数据包；以及，向所述服务器发送针对所述页面的第二埋点数据处理请求，所述第二埋点数据处理请求包括所述第二数据包。

可选的，从所述埋点队列中随机抽取普通类型的埋点之前，以及从所述埋点队列中随机抽取错误类型的埋点之前，还包括：

对所述埋点队列中同名的埋点进行合并，并记录合并数量；

从所述埋点队列中随机抽取普通类型的埋点，采用如下方式：

从同名埋点合并后的埋点队列中随机抽取普通类型的埋点；

从所述埋点队列中随机抽取错误类型的埋点，采用如下方式：

从同名埋点合并后的埋点队列中随机抽取错误类型的埋点；

所述方法还包括：

将成功拼接的普通类型的埋点对应的所述合并数量写入生成第一数据包；以及将成功拼接的错误类型的埋点对应的所述合并数量写入生成第二数据包。

可选的，还包括：

将发送成功的错误类型的埋点从所述埋点队列中清除；以及，将普通类型的埋点从所述埋点队列中清除。

可选的，所述预设条件采用如下方式：

在页面加载过程中，当页面包括的资源文件下载完成后，根据第一预设时间间隔通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样；

在页面展示过程中，根据第二预设时间间隔通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样。

可选的，所述埋点数据包包括：埋点的信息、以及埋点所属页面的信息。

可选的，所述埋点的信息至少包括埋点名称，并包括以下信息的至少一者：埋点类型，父埋点，根埋点，合并数量，采集时间。

可选的，所述页面的信息至少包括页面标识，并包括以下信息的至少一者：页面所属仓库名称，页面所属仓库版本。

本申请还提供一种埋点数据上报装置，包括：

埋点采集单元，用于将页面中被触发的埋点存储到待发送的埋点队列；

埋点采样单元，用于在预设条件成立时，通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样，获得采样埋点对应的埋点数据包；

请求发送单元，用于向服务器发送针对所述页面的埋点数据处理请求，所述埋点数据处理请求包括所述埋点数据包。

本申请还提供一种电子设备，包括：

处理器；以及

存储器，用于存储实现埋点数据上报方法的程序，该设备通电并通过所述处理器运行该埋点数据上报方法的程序后，执行下述步骤：将页面中被触发的埋点存储到待发送的埋点队列；在预设条件成立时，通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样，获得采样埋点对应的埋点数据包；向服务器发送针对所述页面的埋点数据处理请求，所述埋点数据处理请求包括所述埋点数据包。

本申请还提供一种埋点数据处理方法，包括：

接收至少一个客户端发送的针对特定页面的多个埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；

根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的报警概率算法相关的预设指标的本次数据；

根据所述预设指标的本次数据和历史数据，通过所述报警概率算法确定所述预设监控埋点的报警概率；

根据所述报警概率和预设的报警概率阈值，确定需要报警的预设监控埋点。

可选的，所述报警概率算法相关的预设指标包括以下指标的任意一个：累计次数，父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比；

所述报警概率算法包括：

根据所述预设指标的本次数据和历史数据，获取所述预设指标的平均值和方差；

根据所述预设指标的本次数据、所述平均值和方差，通过高斯模型获取所述预设指标的报警概率，作为所述预设监控埋点的报警概率。

可选的，所述报警概率算法相关的预设指标包括以下指标的至少两个：累计次数，父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比；

所述报警概率算法包括：

根据所述预设指标的本次数据和历史数据，获取各个预设指标的平均值和方差；

根据所述预设指标的本次数据、所述平均值和方差，通过高斯模型获取各个预设指标的报警概率；

根据所述各个预设指标各自对应的预设报警概率权重和所述各个预设指标的报警概率，获取所述预设监控埋点的报警概率。

可选的，所述预设监控埋点包括多个预设监控埋点，不同的预设监控埋点对应不同的报警概率算法，不同的预设监控埋点对应不同的报警概率阈值。

可选的，还包括：

为所述需要报警的预设监控埋点生成对应的报警消息；

获取所述需要报警的预设监控埋点对应的报警人和报警方式；

根据所述报警方式向所述报警人提供所述报警消息。

可选的，所述报警方式包括：手机短消息，邮件，即时通讯。

可选的，在接收到所述埋点数据处理请求之后，还包括：

解析所述埋点数据包，获得所述埋点数据包对应的埋点数据。

可选的，所述埋点数据包包括普通类型的多个埋点数据和埋点采样比；

所述解析所述埋点数据包，并获得所述埋点数据包对应的埋点数据，包括：

根据所述埋点采样比，确定所述埋点数据包中各个埋点的出现次数；

根据所述各个埋点及所述出现次数，形成所述埋点数据包对应的多个埋点数据。

可选的，所述埋点数据包包括各个埋点的合并数量；

所述根据所述埋点采样比，并确定所述埋点数据包中各个埋点的出现次数，采用如下方式：

将所述埋点采样比和所述埋点的合并数量的乘积作为所述埋点的出现次数。

可选的，所述埋点数据包包括错误类型的多个埋点数据和各个埋点的合并数量；

所述解析所述埋点数据包，并获得所述埋点数据包对应的埋点数据，采用如下方式：

根据所述多个埋点及各个埋点的合并数量，形成所述埋点数据包对应的多个埋点数据。

可选的，所述埋点的信息至少包括埋点名称，并包括以下信息的至少一者：埋点类型，所属父埋点，合并数量，采集时间。

可选的，所述埋点数据包包括所述特定页面的信息。

可选的，所述特定页面的信息至少包括页面标识，并包括以下信息的至少一者：页面所属仓库名称，页面所属仓库版本。

可选的，还包括：

存储解析获得的多个埋点数据。

可选的，还包括：

对应各个埋点数据存储所述特定页面的信息。

可选的，还包括：

对应各个埋点数据存储所述客户端的信息。

可选的，所述客户端的信息包括以下信息的至少一者：设备类型，浏览器，操作***，用户标识，IP地址。

本申请还提供一种埋点数据处理装置，包括：

请求接收单元，用于接收至少一个客户端发送的针对特定页面的多个埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；

数据统计单元，用于根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的报警概率算法相关的预设指标的本次数据；

报警概率计算单元，用于根据所述预设指标的本次数据和历史数据，通过所述报警概率算法确定所述预设监控埋点的报警概率；

报警埋点确定单元，用于根据所述报警概率和预设的报警概率阈值，确定需要报警的预设监控埋点。

本申请还提供一种电子设备，包括：

处理器；以及

存储器，用于存储实现埋点数据处理方法的程序，该设备通电并通过所述处理器运行该埋点数据处理方法的程序后，执行下述步骤：接收至少一个客户端发送的针对特定页面的多个埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的报警概率算法相关的预设指标的本次数据；根据所述预设指标的本次数据和历史数据，通过所述报警概率算法确定所述预设监控埋点的报警概率；根据所述报警概率和预设的报警概率阈值，确定需要报警的预设监控埋点。

本申请还提供一种埋点数据处理***，包括：根据上述的埋点数据上报装置，根据上述的埋点数据处理装置。

本申请还提供又一种埋点数据处理方法，包括：

接收至少一个客户端发送的针对特定页面的埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；

根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的预设指标的本次数据；

根据所述预设指标的本次数据和所述预设指标对应的预设阈值，确定需要报警的预设监控埋点。

可选的，所述预设指标包括以下指标的任意一个：父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比。

本申请还提供又一种埋点数据处理装置，包括：

请求接收单元，用于接收至少一个客户端发送的针对特定页面的埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；

数据统计单元，用于根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的预设指标的本次数据；

报警埋点确定单元，用于根据所述预设指标的本次数据和所述预设指标对应的预设阈值，确定需要报警的预设监控埋点。

本申请还提供又一种电子设备，包括：

处理器；以及

存储器，用于存储实现埋点数据处理方法的程序，该设备通电并通过所述处理器运行该埋点数据处理方法的程序后，执行下述步骤：接收至少一个客户端发送的针对特定页面的埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的预设指标的本次数据；根据所述预设指标的本次数据和所述预设指标对应的预设阈值，确定需要报警的预设监控埋点。

本申请还提供又一种埋点数据处理***，包括：根据上述的埋点数据上报装置，根据上述的又一种埋点数据处理装置。

与现有技术相比，本申请具有以下优点：

本申请提供的埋点数据上报方法，通过将页面中被触发的埋点存储到待发送的埋点队列，并在预设条件成立时，通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样，形成所述页面的埋点数据包，再向服务器发送针对该页面的埋点数据处理请求，所述埋点数据处理请求包括所述埋点数据包；这种处理方式，对埋点队列中的多个埋点进行动态采样，批量上报埋点数据，避免向服务器发送过多的请求；因此，可以兼顾上报足够的埋点数据及保证客户端性能两方面。

本申请提供的埋点数据处理方法，通过接收至少一个客户端发送的针对特定页面的埋点数据处理请求，所述埋点数据处理请求包括埋点数据包，并根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的报警概率算法相关的预设指标的本次数据，然后根据所述预设指标的本次数据和历史数据，通过所述报警概率算法确定所述预设监控埋点的报警概率，最后，根据所述报警概率和预设的报警概率阈值，确定需要报警的预设监控埋点；这种处理方式，使得结合历史流量和变化趋势进行评估，避免由于业务形态的不同导致误报的情况发生；因此，可以有效提高报警的准确率。

附图说明

图1是本申请提供的一种埋点数据上报方法的实施例的流程图；

图2是本申请提供的一种埋点数据上报方法的实施例的具体流程图；

图3是本申请提供的一种埋点数据上报装置的实施例的示意图；

图4是本申请提供的一种电子设备的实施例的示意图；

图5是本申请提供的一种埋点数据处理方法的实施例的流程图；

图6是本申请提供的一种埋点数据处理方法的实施例的具体流程图；

图7是本申请提供的一种埋点数据处理装置的实施例的示意图；

图8是本申请提供的一种电子设备的实施例的示意图；

图9是本申请提供的一种埋点数据处理***的实施例的示意图；

图10是本申请提供的一种埋点数据处理***的实施例的具体示意图；

图11是本申请提供的又一种埋点数据处理方法的实施例的流程图；

图12是本申请提供的又一种埋点数据处理装置的实施例的示意图；

图13是本申请提供的一种电子设备的实施例的示意图；

图14是本申请提供的一种埋点数据处理***的实施例的示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请中，提供了一种埋点数据上报方法、装置及电子设备，两种埋点数据处理方法、装置及电子设备，以及两种埋点数据处理***。在下面的实施例中逐一进行详细说明。

本申请提供的埋点数据上报方法，其核心的基本思想为：将页面中被触发的埋点存储到待发送的埋点队列，并在预设条件成立时，通过预设的动态采样算法对埋点队列中的埋点进行动态采样，形成埋点数据包，再向服务器发送针对该页面的埋点数据处理请求，该埋点数据处理请求包括该埋点数据包。由于对埋点队列中的多个埋点进行动态采样，批量上报埋点数据，避免向服务器发送过多的请求，因而，可以兼顾上报足够的埋点数据及保证客户端性能两方面。

请参考图1，其为本申请的埋点数据上报方法实施例的流程图。所述方法包括如下步骤：

步骤S101：将页面中被触发的埋点存储到待发送的埋点队列。

所述页面包括但不限于HTML页面、HTML5页面或移动APP的原生页面，例如，天猫首页的HTML页面，天猫首页的HTML5页面等。所述HTML页面可通过安装在个人电脑中的浏览器进行展示，所述HTML5页面可通过安装在智能手机中的浏览器进行展示，所述原生页面可通过安装在智能手机中的移动APP进行展示。

所述页面包括多个埋点，对页面进行埋点可应用的技术包括但不限于代码埋点或可视化埋点技术，也可以应用动态埋点技术。在页面或在移动APP初始化时，将初始化用于发送埋点数据的埋点工具库(SDK)。

页面开发人员会在页面上引入SDK，SDK会提供埋点方法供页面代码直接调用，页面代码调用埋点工具库的方法并传入待发送的埋点名称、父埋点名称等信息后，埋点工具库便会将该待发送的埋点数据加入一个发送队列(待发送的埋点队列)中，每隔一段时间，就会通过动态采样算法从埋点队列中抽样生成最终发送的埋点数据包。

在现有技术下，在某个事件发生时，如果该事件对应的埋点为根据固定采样比确定的要采样的点，就调用SDK里面相应的数据发送接口发送数据；而本申请提供的方法，在某个事件发生时，将首先将该埋点发送到待发送的埋点队列中，只有在预设条件成立时，才会向服务器发送埋点数据。

步骤S103：在预设条件成立时，通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样，形成所述页面的埋点数据包。

本申请提供的埋点数据上报方法，在预设条件成立时，可通过预设的动态采样算法对待发送的埋点队列中的埋点进行动态采样，形成所述页面的本次向服务器上报的埋点数据包。

所述预设条件包括但不限于以下方式的至少一者：

1)在页面加载过程中，当页面包括的资源文件(如，图片资源等)下载完成后，根据第一预设时间间隔通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样；

2)在页面展示过程中，根据第二预设时间间隔通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样。

所述第一预设时间间隔通常大于所述第二预设时间间隔，其原因在于，相对页面展示过程而言，页面加载过程中将消耗更多的客户端资源，例如，下载资源文件等。这种情况下，为了避免频繁动态采样影响客户端性能，因此，通常将第一预设时间间隔设置的大一些，例如，将第一预设时间间隔设置5秒，将第二预设时间间隔设置2秒。

具体实施时，所述预设的动态采样算法可包括如下步骤：

1)从所述埋点队列中随机抽取普通类型的埋点；以及，从所述埋点队列中随机抽取错误类型的埋点；2)以传输协议允许的请求数据包最大长度为限制，对抽取出的普通类型的埋点对应的序列化字符串进行最大限度拼接，获得普通类型的采样埋点数据包；以及，对抽取出的错误类型的埋点对应的序列化字符串进行最大限度拼接，获得错误类型的采样埋点数据包；3)根据所述普通类型的采样埋点数据包和埋点采样比，生成第一数据包，所述埋点采样比是指普通类型的埋点总数量与成功拼接的普通类型的埋点数量的比值；以及，根据所述错误类型的采样埋点数据包，生成第二数据包。下面具体介绍各步骤。

1)从所述埋点队列中随机抽取普通类型的埋点；以及，从所述埋点队列中随机抽取错误类型的埋点。

所述埋点的类型，可以分为普通类型和错误类型。错误类型的埋点数据通常会对页面的稳定性分析及页面调整产生较大的影响，因此，优选将错误类型的埋点数据全部上报至服务器端，以保证页面稳定性分析结果的准确性，并为页面调整提供更多的有用信息。

本申请提供的埋点数据上报方法，对普通类型和错误类型的埋点分别进行动态埋点采样处理。由于待发送的埋点队列中集中了一段时间范围内采集到的埋点数据，为保证上报的埋点数据为时间轴上均匀分布的埋点数据，因此，有必要首先从所述埋点队列中随机抽取出普通类型的埋点，以及，从所述埋点队列中随机抽取出错误类型的埋点。

2)以传输协议允许的请求数据包最大长度为限制，对抽取出的普通类型的埋点对应的序列化字符串进行最大限度拼接，获得普通类型的采样埋点数据包；以及，对抽取出的错误类型的埋点对应的序列化字符串进行最大限度拼接，获得错误类型的采样埋点数据包。

在本实施例中，埋点数据包是通过网络传输协议(如：HTTP协议或HTTPS协议等)发送到服务器端的，因此，一个埋点数据处理请求的长度受到传输协议允许的请求数据包最大长度限制，即一次请求包括的采样埋点数受传输协议允许的请求数据包最大长度限制。

所述埋点是一个对象，因此，需要首先对埋点进行序列化处理，然后将序列化后的埋点字符串进行最大限度拼接。在本实施例中，分别形成普通类型的采样埋点数据包和错误类型的采样埋点数据包。

3)根据所述普通类型的采样埋点数据包和埋点采样比，生成第一数据包，所述埋点采样比是指普通类型的埋点总数量与成功拼接的普通类型的埋点数量的比值；以及，根据所述错误类型的采样埋点数据包，生成第二数据包。

在本实施例中，通过动态采样算法从所述埋点队列中采样普通类型的埋点数据，将普通类型的埋点数据包上报到服务器后，就会将所述埋点队列中的普通类型的埋点数据清除，因此，在上报普通类型的埋点数据时，需要上报实际的埋点采样比，以便于服务器准确的获知埋点数据的实际情况。由于不同埋点包括的信息量不同，因此，按最大限度拼接成的不同埋点数据包通常包括不同的埋点数量。可见，实际的埋点采样比是一个动态采样比。在本实施例中，根据所述普通类型的采样埋点数据包和埋点采样比，生成第一数据包，即普通类型的采样埋点对应的数据包。

在本实施例中，对于错误类型的埋点数据，要将其全部上报至服务器端，对于本次没有上报的服务器的埋点，将继续留在所述埋点队列中，下一次上报埋点数据时会对其再次进行采样，直至将所有错误类型的埋点数据全部上报至服务器端。

在实际应用中，所述埋点队列中可能包括不同时间产生的同一埋点的数据。作为一种优选的方案，从所述埋点队列中随机抽取普通类型的埋点之前，以及从所述埋点队列中随机抽取错误类型的埋点之前，还可包括如下步骤：对所述埋点队列中同名的埋点进行合并，并记录合并数量；相应的，从所述埋点队列中随机抽取普通类型的埋点的步骤，可采用如下方式实现：从同名埋点合并后的埋点队列中随机抽取普通类型的埋点；从所述埋点队列中随机抽取错误类型的埋点的步骤，可采用如下方式实现：从同名埋点合并后的埋点队列中随机抽取错误类型的埋点。采用这种处理方式，能够避免数据量少的埋点的发送机会被数据量大的埋点抢占，保证服务端可以收到足够的埋点数据，从而提高报警准确度。

具体实施时，对埋点队列中的同名埋点进行合并处理后，还可包括如下步骤：将成功拼接的普通类型的埋点对应的所述合并数量写入生成第一数据包；以及将成功拼接的错误类型的埋点对应的所述合并数量写入生成第二数据包。采用这种处理方式，能够保证服务端可以获知真实的埋点数据情况，从而提高报警准确度。

综上所述，通过在采样埋点前合并相同名称的埋点，可以压缩所述埋点队列中的埋点数量，使得出现多次的埋点与只出现一次的埋点具有相同的被采样概率，避免漏报出现次数少的埋点。为使服务器端能够准确的分析埋点数据，需要将埋点的合并数量一并上报至服务器端。

例如，在页面中引入SDK后，若执行window.ctkTrack(‘name’，‘parent’)，便会将一个埋点名称为name、父埋点名称为parent的埋点加入到待发送的埋点队列中；假如待发送的埋点队列中有name1、name1(重复发送了两次)、name2、name3、name4、name5五个埋点，动态采样算法会筛选出最终发送的埋点数据，如，最终随机发送name1|10；name3|5，其中10表示name1在埋点队列中出现了10次，5表示name3在埋点队列中出现了5次。

此外，在实际应用中，服务器端会对属于不同项目的多个页面进行埋点数据处理。由于不同项目的不同页面可能具有相同的埋点标识，为使服务器能够区分这些同名的埋点，优选的方案是不仅将采样埋点的数据添加至所述埋点数据包，还需将埋点所属页面的信息添加至所述埋点数据包。

所述埋点的信息至少包括埋点名称，并包括以下信息的至少一者：埋点类型(如，普通类型或错误类型)，所属父埋点，所属根埋点，同名埋点的合并数量，埋点采集时间等。例如，父埋点是要加载资源文件时对应的埋点，其子埋点可以为加载成功时对应的埋点和加载失败时对应的埋点，其根埋点可以是进入页面时设置的埋点，根埋点的出现次数实际就是页面的浏览量(PV，Page View)。

所述页面的信息至少包括页面标识，并包括以下信息的至少一者：页面所属仓库名称，页面所属仓库版本。具体实施时，页面代码发布前可执行代码构建，构建过程中会把页面的相关信息(仓库名称、仓库版本等)注入到页面代码中，页面代码运行时调用埋点工具库的方法便会发送这些数据。

步骤S105：向服务器发送针对所述页面的埋点数据处理请求，所述埋点数据处理请求包括所述埋点数据包。

本申请实施例提供的埋点数据上报方法，对普通类型的埋点和错误类型的埋点分别进行处理，因此，所述向服务器发送针对所述页面的埋点数据处理请求，可包括如下具体步骤：向所述服务器发送针对所述页面的第一埋点数据处理请求，所述第一埋点数据处理请求包括所述第一数据包；以及，向所述服务器发送针对所述页面的第二埋点数据处理请求，所述第二埋点数据处理请求包括所述第二数据包。

需要注意的是，在普通类型的埋点上报成功后，需要将普通类型的埋点全部从所述埋点队列中清除；在错误类型的埋点上报成功后，仅将发送成功的错误类型的埋点从所述埋点队列中清除。

请参考图2，其为本申请的埋点数据上报方法实施例的具体流程图。在本实施例中，客户端加载页面或是页面展示过程中，页面代码会调用埋点工具库提供的埋点发送方法，将待发送的埋点数据加入到待发送的埋点队列中，每隔一段时间(可根据用户当前页面的运行状态确定)，会执行一次动态采样算法，动态采样的运行过程大致如下：

1)由于错误数据在页面稳定性层面较为重要，因此首先需要确认待发送的埋点的类型，对于普通类型的埋点和错误类型的埋点采用不同的处理逻辑，也会采用不同的队列。

2)无论普通类型的埋点还是错误类型的埋点，都会先将待发送的埋点队列中同名的埋点进行合并处理，并记录合并的个数，如有5条名字为init的埋点，那么合并完成后队列中只会有一条名字为init的埋点，但埋点数据包中会记录它的合并个数是5。

3)对于队列中的埋点，会进行乱序排序，作为后续随机抽样的准备工作

4)将乱序后的埋点队列逐个拿出，将其序列化成字符串后，再根据HTTP请求的最大长度限制进行拼接，到达最大长度之后停止拼接。

5)对于合并后的普通类型的埋点队列，要记录队列中的埋点总个数和最终成功拼接的埋点个数的比率，每个埋点的合并个数乘以这个比率的值为最终的埋点个数。如，一共有100个普通类型的埋点，最终成功拼接了25个，那么队列中的总个数和最终成功拼接的埋点个数比率为4，而若埋点中合并个数为5，那么最终合并个数即为20，意思是这个埋点一条数据代表了20条数据。完成后，便会将这些数据发送至服务器端，发送完成后清空埋点队列。

6)对于合并后的错误类型的埋点队列，拼接完成后直接发送至服务器端，对于成功发送的埋点要从队列中清除，而未能成功发送的埋点会参与下一次动态采样算法的计算，等待下一次发送。

在上述的实施例中，提供了一种埋点数据上报方法，与之相对应的，本申请还提供一种埋点数据上报装置。该装置是与上述方法的实施例相对应。

请参看图3，其为本申请的埋点数据上报装置实施例的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的一种埋点数据上报装置，包括：

埋点采集单元301，用于将页面中被触发的埋点存储到待发送的埋点队列；

埋点采样单元303，用于在预设条件成立时，通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样，获得采样埋点对应的埋点数据包；

请求发送单元305，用于向服务器发送针对所述页面的埋点数据处理请求，所述埋点数据处理请求包括所述埋点数据包。

可选的，所述埋点的类型包括普通类型或错误类型；

所述埋点采样单元303包括：

随机抽取子单元，用于从所述埋点队列中随机抽取普通类型的埋点；以及，从所述埋点队列中随机抽取错误类型的埋点；

埋点数据拼接子单元，用于以传输协议允许的请求数据包最大长度为限制，对抽取出的普通类型的埋点对应的序列化字符串进行最大限度拼接，获得普通类型的采样埋点数据包；以及，对抽取出的错误类型的埋点对应的序列化字符串进行最大限度拼接，获得错误类型的采样埋点数据包；

数据包生成子单元，用于根据所述普通类型的采样埋点数据包和埋点采样比，生成第一数据包，所述埋点采样比是指普通类型的埋点总数量与成功拼接的埋点数量的比值；以及，根据所述错误类型的采样埋点数据包，生成第二数据包；

所述请求发送单元305包括：

第一请求发送子单元，用于向所述服务器发送针对所述页面的第一埋点数据处理请求，所述第一埋点数据处理请求包括所述第一数据包；

第二请求发送子单元，用于向所述服务器发送针对所述页面的第二埋点数据处理请求，所述第二埋点数据处理请求包括所述第二数据包。

可选的，所述埋点采样单元303还包括：

同名埋点合并子单元，用于对所述埋点队列中同名的埋点进行合并，并记录合并数量；

所述随机抽取子单元，具体用于从同名埋点合并后的埋点队列中随机抽取普通类型的埋点；以及，从同名埋点合并后的埋点队列中随机抽取错误类型的埋点；

所述埋点采样单元303还包括：

合并数量写入单元，用于将成功拼接的普通类型的埋点对应的所述合并数量写入生成第一数据包；以及将成功拼接的错误类型的埋点对应的所述合并数量写入生成第二数据包。

可选的，所述装置还包括：

埋点队列清理单元，用于将发送成功的错误类型的埋点从所述埋点队列中清除；以及，将普通类型的埋点从所述埋点队列中清除。

可选的，所述预设条件采用如下方式：

在页面加载过程中，当页面包括的资源文件下载完成后，根据第一预设时间间隔通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样；

在页面展示过程中，根据第二预设时间间隔通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样。

可选的，所述埋点数据包包括：埋点的信息、以及埋点所属页面的信息。

可选的，所述埋点的信息至少包括埋点名称，并包括以下信息的至少一者：埋点类型，父埋点，根埋点，合并数量，采集时间。

可选的，所述页面的信息至少包括页面标识，并包括以下信息的至少一者：页面所属仓库名称，页面所属仓库版本。

请参考图4，其为本申请的电子设备实施例的示意图。由于设备实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的设备实施例仅仅是示意性的。

本实施例的一种电子设备，该电子设备包括：处理器401；以及存储器403，用于存储实现埋点数据上报方法的程序，该设备通电并通过所述处理器运行该埋点数据上报方法的程序后，执行下述步骤：将页面中被触发的埋点存储到待发送的埋点队列；在预设条件成立时，通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样，获得采样埋点对应的埋点数据包；向服务器发送针对所述页面的埋点数据处理请求，所述埋点数据处理请求包括所述埋点数据包。

与上述的埋点数据上报方法相对应，本申请还提供一种埋点数据处理方法。请参考图5，其为本申请提供的一种埋点数据处理方法实施例的流程图，本实施例与第一实施例内容相同的部分不再赘述，请参见实施例一中的相应部分。本申请提供的一种埋点数据处理方法包括：

步骤S501：接收至少一个客户端发送的针对特定页面的多个埋点数据处理请求，所述埋点数据处理请求包括埋点数据包。

所述特定页面包括但不限于HTML页面、HTML5页面或移动APP的原生页面，所述HTML页面可通过安装在个人电脑中的浏览器进行展示，所述HTML5页面可通过安装在智能手机中的浏览器进行展示，所述原生页面可通过安装在智能手机中的移动APP进行展示。

大量用户访问所述特定页面(如，手机天猫的首页等)，便会将埋点数据通过网络发送到服务器端。在本实施例中，服务器端首先将这些网络请求(包含发送的埋点相关数据以及终端类型、用户id、用户IP、数据时间等)存储到服务器本地，并通过发送消息的方式触发实时计算服务。实时计算服务接受到消息后，便会将这些网络请求的原始数据拆解和分析，生成方便后续报警处理和网站展示使用的数据，例如，解析后的埋点数据包括：页面标识、埋点名称、父埋点名称、根埋点名称、仓库名称、仓库版本、合并个数、发送时间、浏览器、操作***等，并存储到列式数据库中方便查询。

本申请实施例提供的埋点数据处理方法，在接收到客户端发送的埋点数据处理请求之后，需要解析埋点数据包，获得其中包括的埋点数据。所述特定页面的埋点数据包可以是通过现有技术下固定采样比上报的埋点数据包，也可以是通过上述实施例一所述的埋点数据上报方法动态采样形成的埋点数据包。当埋点数据包为通过固定采样比上报的数据包时，埋点数据包中通常仅包括一个埋点数据；当埋点数据包为通过动态采样算法上报的数据包时，埋点数据包中通常包括多个埋点数据。

在本实施例中，所述埋点数据包是通过上述实施例一所述的埋点数据上报方法动态采样形成的埋点数据包。当接收到的埋点数据包是普通类型的埋点数据包时，埋点数据包中包括普通类型的多个埋点数据和埋点采样比；这种情况下，解析所述埋点数据包可包括如下步骤：1)根据所述埋点采样比，确定所述埋点数据包中各个埋点的出现次数；2)根据所述各个埋点及所述出现次数，形成所述埋点数据包对应的多个埋点数据。

如果客户端在采样之前对同名埋点进行了合并处理，埋点数据包还包括各个埋点的合并数量的信息；这种情况下，将所述埋点采样比和所述埋点的合并数量的乘积作为所述埋点的出现次数。

当接收到的埋点数据包是错误类型的埋点数据包时，埋点数据包包括错误类型的多个埋点数据，同时也可以包括各个埋点的合并数量；这种情况下，解析所述埋点数据包，可采用如下方式实现：根据多个埋点及各个埋点的合并数量，形成所述埋点数据包对应的多个埋点数据。

所述埋点的信息至少包括埋点名称，并包括以下信息的至少一者：埋点类型，所属父埋点，所属根埋点，合并数量，采集时间等。

所述埋点数据包可以包括所述特定页面的信息。所述特定页面的信息至少包括页面标识，并包括以下信息的至少一者：页面所属仓库名称，页面所属仓库版本。

为了方便后续报警处理和网站展示数据，本申请提供的埋点数据处理方法，还可包括存储解析获得的多个埋点数据的步骤。具体实施时，可对应各个埋点数据存储所述特定页面的信息，对应各个埋点数据存储所述客户端的信息。所述客户端的信息包括以下信息的至少一者：设备类型，浏览器，操作***，用户标识，IP地址。

步骤S503：根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的报警概率算法相关的预设指标的本次数据。

与现有技术通过埋点出现次数达到预设的次数阈值即触发告警的方式不同，本申请提供的埋点数据处理方法，首先通过预设的报警概率算法，根据预设监控埋点相关的历史数据确定该埋点的本次报警概率，然后再将确定的本次报警概率与预设的报警概率阈值进行比较，确定需要报警的预设监控埋点。

为了能够计算获得预设监控埋点的报警概率，首先需要获得预设监控埋点对应的报警概率算法相关的预设指标的本次数据。

本申请提供的埋点数据处理方法，根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的报警概率算法相关的预设指标的本次数据。

所述预设的时间间隔，根据业务需求进行设置，例如，可设置为5分钟的时间间隔，即每5分钟确定一次需要报警的埋点。

所述特定页面包括多个埋点，其中可能只有一部分是需要监测报警的埋点，本申请将需要监控报警的埋点称为预设监控埋点，例如，天猫首页中为下载某个资源文件的埋点设置下载成功的子埋点和下载失败的子埋点，如果希望监控资源成功下载情况，就可以将所述下载成功的子埋点设置为预设监控埋点。

所述报警概率算法可以仅与一个预设指标相关，也可以与多个预设指标相关。具体实施时，用户可通过配置页面设置需要监控哪些埋点(即指定预设监控埋点)，还可以通过配置页面设置为各个预设监控埋点指定可应用的报警概率算法。

步骤S505：根据所述预设指标的本次数据和历史数据，通过所述报警概率算法确定所述预设监控埋点的报警概率。

所述报警概率算法可以仅与一个预设指标相关，例如，所述报警概率算法相关的预设指标包括但不限于以下指标的任意一个：累计次数，父子埋点(父埋点与子埋点)的累计次数比率，根子埋点(根埋点与子埋点)的累计次数比率，累计次数的日环比，累计次数的周环比等。

在报警概率算法仅与一个预设指标相关的情况下，所述报警概率算法可包括如下具体步骤：1)根据所述预设指标的本次数据和历史数据，获取所述预设指标的平均值和方差；2)根据所述预设指标的本次数据、所述平均值和方差，通过高斯模型获取所述预设指标的报警概率，作为所述预设监控埋点的报警概率。例如，某个业务可以选用累计次数进行报警，这样如果本次累计次数与历史均值相差较大时便会触发告警。

具体实施时，可首先对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，生成一份汇总数据，包括：页面标识、埋点名称、仓库名称、时间段、该时间段内累计数量；然后，再计算获得预设监控埋点相关的各个预设指标的数据(即：预设指标的本次数据)；接下来，可根据预设指标的本次数据和历史数据，获取预设指标的平均值和方差；最后，根据所述预设指标的本次数据、所述平均值和方差，通过高斯模型获取所述预设指标的报警概率，作为预设监控埋点的报警概率。

所述报警概率算法也可以与多个预设指标相关，例如，所述报警概率算法相关的预设指标包括以下指标的至少两个：累计次数，父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比。这种情况下，需要为各个预设指标分别设置报警概率权重，各个预设指标分别对应的报警概率权重的总和为1。

在报警概率算法与多个预设指标相关的情况下，所述报警概率算法可包括如下具体步骤：1)根据所述预设指标的本次数据和历史数据，获取各个预设指标的平均值和方差；2)根据所述预设指标的本次数据、所述平均值和方差，通过高斯模型获取各个预设指标的报警概率；3)根据所述各个预设指标各自对应的预设报警概率权重和所述各个预设指标的报警概率，获取所述预设监控埋点的报警概率。

例如，某个业务即流量周期性变化，可以选用日环比和周环比进行告警，两者权重可以7:3分配，这样如果数据与昨日不同更容易触发告警，而与上周同时段不同也会触发告警，但优先级较低；假如在2016/12/2日10:05-10:10这个时间段，上报埋点A的累计次数为100；在2016/12/1日10:05-10:10时间段，上报埋点A的累计次数为70；在2016/11/2日10:05-10:10时间段，上报埋点A的累计次数为80，则埋点A的日环比为100/70，埋点A的周环比为100/80；根据埋点A在10:05-10:10时间段的日环比历史数据和本次数据(100/70)，可计算获得埋点A在10:05-10:10时间段的日环比均值，假设日环比均值为100/70，日环比方差为10％，则由于埋点A的本次日环比数据与历史均值相同，则告警机率为0；另外，根据埋点A在10:05-10:10时间段的周环比历史数据和本次数据(100/80)，可计算获得埋点A在10:05-10:10时间段的周环比均值，假设周环比均值为100/50，周环比方差为10％，则由于埋点A的本次周环比数据与历史均值相差较远，则告警机率较大(如，80％)。

请参看图6，其为本申请的埋点数据处理方法实施例的具体流程图。在本实施例中，记录每一次获得的预设指标的平均值和方差，当处理本次数据时，可直接根据预设指标的本次数据和上一次计算获得的平均值和方差，计算本次预设指标的平均值和方差；这种处理方式，可以有效减少计算量；因此，可以有效降低计算资源的消耗。在本实施例中，采用增量计算框架计算预设指标的平均值和方差。

步骤S507：根据所述报警概率和预设的报警概率阈值，确定需要报警的预设监控埋点。

在确定了预设监控埋点的报警概率后，就可以根据该报警概率和预设的报警概率阈值，确定该预设监控埋点是否需要报警。在本实施例中，当报警概率超过预设的报警概率阈值时，将该预设监控埋点确定为需要报警的埋点。

所述预设的报警概率阈值，可以根据经验和具体业务需求进行设置。具体实施时，可以为不同的预设监控埋点设置不同的报警概率阈值。

此外，本申请提供的埋点数据处理方法，还可包括如下步骤：1)为所述需要报警的预设监控埋点生成对应的报警消息；2)获取所述需要报警的预设监控埋点对应的报警人和报警方式；3)根据所述报警方式向所述报警人提供所述报警消息。采用这种处理方式，可以将不同埋点的报警消息推送给负责该埋点的用户。

在本实施例中，在服务器端本地数据库中存储有各个预设监控埋点分别对应的报警人信息及报警方式信息。在为需要报警的预设监控埋点生成对应的报警消息后，就可以通过查询数据库的方式获取各个预设监控埋点分别对应的报警人及报警方式，然后，将各个报警信息推送给负责该埋点的用户。

所述报警方式包括但不限于：手机短消息，邮件，即时通讯消息等。

在上述的实施例中，提供了一种埋点数据处理方法，与之相对应的，本申请还提供一种埋点数据处理装置。该装置是与上述方法的实施例相对应。

请参看图7，其为本申请的埋点数据处理装置实施例的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的一种埋点数据处理装置，包括：

请求接收单元701，用于接收至少一个客户端发送的针对特定页面的多个埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；

数据统计单元703，用于根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的报警概率算法相关的预设指标的本次数据；

报警概率计算单元705，用于根据所述预设指标的本次数据和历史数据，通过所述报警概率算法确定所述预设监控埋点的报警概率；

报警埋点确定单元707，用于根据所述报警概率和预设的报警概率阈值，确定需要报警的预设监控埋点。

可选的，所述报警概率算法相关的预设指标包括以下指标的任意一个：累计次数，父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比；

所述报警概率计算单元705包括：

均值及方差获取子单元，用于根据所述预设指标的本次数据和历史数据，获取所述预设指标的平均值和方差；

报警概率获取子单元，用于根据所述预设指标的本次数据、所述平均值和方差，通过高斯模型获取所述预设指标的报警概率，作为所述预设监控埋点的报警概率。

可选的，所述报警概率算法相关的预设指标包括以下指标的至少两个：累计次数，父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比；

所述报警概率计算单元705包括：

均值及方差获取子单元，用于根据所述预设指标的本次数据和历史数据，获取各个预设指标的平均值和方差；

第一报警概率获取子单元，用于根据所述预设指标的本次数据、所述平均值和方差，通过高斯模型获取各个预设指标的报警概率；

第二报警概率获取子单元，用于根据所述各个预设指标各自对应的预设报警概率权重和所述各个预设指标的报警概率，获取所述预设监控埋点的报警概率。

可选的，所述预设监控埋点包括多个预设监控埋点，不同的预设监控埋点对应不同的报警概率算法，不同的预设监控埋点对应不同的报警概率阈值。

可选的，所述装置还包括：

报警消息生成单元，用于为所述需要报警的预设监控埋点生成对应的报警消息；

报警人和报警方式获取单元，用于获取所述需要报警的预设监控埋点对应的报警人和报警方式；

报警消息提供单元，用于根据所述报警方式向所述报警人提供所述报警消息。

可选的，所述报警方式包括：手机短消息，邮件，即时通讯。

可选的，所述装置还包括：

埋点数据包解析单元，用于解析所述埋点数据包，获得所述埋点数据包对应的埋点数据。

可选的，所述埋点数据包包括普通类型的多个埋点数据和埋点采样比；

所述埋点数据包解析单元包括：

出现次数确定子单元，用于根据所述埋点采样比，确定所述埋点数据包中各个埋点的出现次数；

埋点数据形成子单元，用于根据所述各个埋点及所述出现次数，形成所述埋点数据包对应的多个埋点数据。

可选的，所述埋点数据包包括各个埋点的合并数量；

所述出现次数确定子单元，具体用于将所述埋点采样比和所述埋点的合并数量的乘积作为所述埋点的出现次数。

可选的，所述埋点数据包包括错误类型的多个埋点数据和各个埋点的合并数量；

所述埋点数据包解析单元，具体用于根据所述多个埋点及各个埋点的合并数量，形成所述埋点数据包对应的多个埋点数据。

可选的，所述埋点的信息至少包括埋点名称，并包括以下信息的至少一者：埋点类型，所属父埋点，合并数量，采集时间。

可选的，所述埋点数据包包括所述特定页面的信息。

可选的，所述特定页面的信息至少包括页面标识，并包括以下信息的至少一者：页面所属仓库名称，页面所属仓库版本。

可选的，所述装置还包括：

埋点数据存储单元，用于存储解析获得的多个埋点数据。

可选的，所述装置还包括：

页面信息存储单元，用于对应各个埋点数据存储所述特定页面的信息。

可选的，所述装置还包括：

客户端信息存储单元，用于对应各个埋点数据存储所述客户端的信息。

可选的，所述客户端的信息包括以下信息的至少一者：设备类型，浏览器，操作***，用户标识，IP地址。

请参考图8，其为本申请的电子设备实施例的示意图。由于设备实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的设备实施例仅仅是示意性的。

本实施例的一种电子设备，该电子设备包括：处理器801；以及存储器803，用于存储实现埋点数据处理方法的程序，该设备通电并通过所述处理器运行该埋点数据处理方法的程序后，执行下述步骤：接收至少一个客户端发送的针对特定页面的多个埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的报警概率算法相关的预设指标的本次数据；根据所述预设指标的本次数据和历史数据，通过所述报警概率算法确定所述预设监控埋点的报警概率；根据所述报警概率和预设的报警概率阈值，确定需要报警的预设监控埋点。

本申请实施例还提供了一种埋点数据处理***，如图9所示，该***包括上述实施例所述的埋点数据处理装置901和埋点数据上报装置902。所述埋点数据处理装置通常部署于服务器，但并不局限于服务器，也可以是能够实现所述埋点数据处理方法的任何设备；所述埋点数据上报装置通常部署于移动通讯设备、个人电脑、PAD、iPad等终端设备。

例如，埋点数据上报装置部署在智能手机上，能够将页面中被触发的埋点存储到待发送的埋点队列，在预设条件成立时，通过预设的动态采样算法对埋点队列中的埋点进行动态采样，形成该页面的埋点数据包，向服务器发送针对该页面的埋点数据处理请求，该埋点数据处理请求包括埋点数据包；所述埋点数据处理装置部署在服务器上，通过接收至少一个客户端发送的针对该页面的多个埋点数据处理请求，所述埋点数据处理请求包括埋点数据包，并根据预设的时间间隔，对该时间间隔范围内接收到的该页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的报警概率算法相关的预设指标的本次数据，然后根据所述预设指标的本次数据和历史数据，通过所述报警概率算法确定所述预设监控埋点的报警概率，最后，根据所述报警概率和预设的报警概率阈值，确定需要报警的预设监控埋点。

请参考图10，其为本申请的埋点数据处理***实施例的具体示意图。在本实施例中，客户端上报埋点数据及服务器端进行埋点报警处理的整个工作流程涉及如下步骤：

1)页面开发人员在页面上引入埋点工具库，埋点工具库(SDK)会提供埋点方法供页面代码直接调用，页面代码调用埋点工具库的埋点方法，并传入待发送的埋点名称、父埋点名称等信息，埋点工具库便会将待发送的埋点数据加入到待发送的埋点队列中，每隔一段时间，就会采用动态采样算法从埋点队列中抽样生成最终发送的埋点数据。

2)在发布页面代码之前会执行代码构建的操作，构建过程中会把页面代码的相关信息(如，仓库名称、仓库版本等)注入到页面代码中，页面代码在运行过程中调用埋点工具库的方法时，便会发送这些数据。

3)大量用户访问页面，便会运行这些埋过点的代码，这时便会将数据通过网络发送到数据收集应用，数据收集应用将这些网络请求存储(包含发送的埋点相关数据以及终端类型、用户id、用户IP、数据时间等)到服务器本地，并通过发送消息的方式触发Galaxy实时计算。Galaxy是增量计算模型，而不是流计算，增量计算是有状态的计算。使用批量计算，每一次的输出结果只与本次全量扫进来的数据有关，而且计算是幂等的；使用增量计算，每批计算结果是由本批数据和历史批次结果计算出来的，因而，可以有效减少计算资源的消耗。

4)Galaxy实时计算接受到消息后，便会将这些网络请求的原始数据拆解和分析，生成方便后续进行报警监控和网站展示所用的数据(如页面标识、节点名称、父节点名称、仓库名称、仓库版本、合并个数、发送时间、浏览器、操作***等)，并存储到列式数据库中方便查询。同时，也会根据预设的时间间隔生成一份汇总数据(页面标识、节点名称、仓库名称、时间段、该时间段内总数)，交由稳定性(即：报警监控)应用(CodeTrack-worker)。

5)稳定性应用(CodeTrack-worker)获取到Galaxy实时计算的汇总数据后，会将这些数据结合稳定性算法(如，根据报警概率和预设的报警概率阈值的算法)来决定是否需要发送告警。

6)若稳定性算法认为数据流量异常，就会将告警消息推送到一个消息队列中，同时数据展示应用会监听这些消息，获取到消息后找到配置的告警人列表以及配置的告警方式(钉钉、旺旺、短信、邮件等)，发送告警。

7)告警人收到告警后，会进入数据展示应用(CodeTrack-web)，数据展示应用会从列式数据库中获取存储的数据，以图表曲线的方式展示给告警人，告警人查看今日数据波动曲线、昨日数据波动曲线，确定问题出现的时间。然后通过查看注入版本、终端类型、错误信息等数据来定位具体出现稳定的场景和影响范围。

8)页面开发人员根据这些信息修正问题后，将页面代码重新发布上线。

与上述的埋点数据上报方法相对应，本申请还提供又一种埋点数据处理方法。请参考图11，其为本申请提供的又一种埋点数据处理方法实施例的流程图，本实施例与第一实施例内容相同的部分不再赘述，请参见实施例一中的相应部分。本申请提供的又一种埋点数据处理方法包括：

步骤S1101：接收至少一个客户端发送的针对特定页面的多个埋点数据处理请求，所述埋点数据处理请求包括埋点数据包。

步骤S1103：根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的预设指标的本次数据。

所述预设指标包括以下指标的任意一个：父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比。

步骤S1105：根据所述预设指标的本次数据和所述预设指标对应的预设阈值，确定需要报警的预设监控埋点。

例如，某个业务可以选用父子埋点的累计次数比率进行报警，如果本次累计次数比率超过预设的阈值时便会触发告警，如，父埋点是要加载资源文件时对应的埋点，其子埋点为加载成功时对应的埋点，客户端将上报该父埋点的数据和该子埋点的数据，本申请提供的又一种埋点数据处理方法，可计算该父埋点与该子埋点的累计次数比率，并为父子埋点的累计次数比率设置一个阈值(如，90％)，则如果本次比率为80％就会触发告警。

在上述的实施例中，提供了又一种埋点数据处理方法，与之相对应的，本申请还提供又一种埋点数据处理装置。该装置是与上述方法的实施例相对应。

请参看图12，其为本申请的又一种埋点数据处理装置实施例的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的又一种埋点数据处理装置，包括：

请求接收单元1201，用于接收至少一个客户端发送的针对特定页面的埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；

数据统计单元1203，用于根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的预设指标的本次数据；

报警埋点确定单元1205，用于根据所述预设指标的本次数据和所述预设指标对应的预设阈值，确定需要报警的预设监控埋点。

可选的，所述预设指标包括以下指标的任意一个：父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比。

请参考图13，其为本申请的电子设备实施例的示意图。由于设备实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的设备实施例仅仅是示意性的。

本实施例的一种电子设备，该电子设备包括：处理器1301；以及存储器1303，用于存储实现埋点数据处理方法的程序，该设备通电并通过所述处理器运行该埋点数据处理方法的程序后，执行下述步骤：接收至少一个客户端发送的针对特定页面的埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的预设指标的本次数据；根据所述预设指标的本次数据和所述预设指标对应的预设阈值，确定需要报警的预设监控埋点。

本申请实施例还提供了又一种埋点数据处理***，如图14所示，该***包括上述实施例所述的又一种埋点数据处理装置1401和埋点数据上报装置1402。所述又一种埋点数据处理装置通常部署于服务器，但并不局限于服务器，也可以是能够实现所述又一种埋点数据处理方法的任何设备；所述埋点数据上报装置通常部署于移动通讯设备、个人电脑、PAD、iPad等终端设备。

例如，埋点数据上报装置部署在智能手机上，能够将页面中被触发的埋点存储到待发送的埋点队列，在预设条件成立时，通过预设的动态采样算法对埋点队列中的埋点进行动态采样，形成该页面的埋点数据包，向服务器发送针对该页面的埋点数据处理请求，该埋点数据处理请求包括埋点数据包；所述又一种埋点数据处理装置部署在服务器上，通过接收至少一个客户端发送的针对特定页面的埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；根据预设的时间间隔，对该时间间隔范围内接收到的所述特定页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的预设指标的本次数据；根据所述预设指标的本次数据和所述预设指标对应的预设阈值，确定需要报警的预设监控埋点。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

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

2、本领域技术人员应明白，本申请的实施例可提供为方法、***或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

Claims (33)

1.一种埋点数据上报方法，其特征在于，包括：

将页面中被触发的埋点存储到待发送的埋点队列；

在预设条件成立时，通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样，形成所述页面的埋点数据包；

所述预设条件采用如下方式：

在页面加载过程中，当页面包括的资源文件下载完成后，根据第一预设时间间隔通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样；

在页面展示过程中，根据第二预设时间间隔通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样；向服务器发送针对所述页面的埋点数据处理请求，所述埋点数据处理请求包括所述埋点数据包。

2.根据权利要求1所述的埋点数据上报方法，其特征在于，所述埋点的类型包括普通类型或错误类型；

所述预设的动态采样算法包括：

从所述埋点队列中随机抽取普通类型的埋点；以及，从所述埋点队列中随机抽取错误类型的埋点；

以传输协议允许的请求数据包最大长度为限制，对抽取出的普通类型的埋点对应的序列化字符串进行最大限度拼接，获得普通类型的采样埋点数据包；以及，对抽取出的错误类型的埋点对应的序列化字符串进行最大限度拼接，获得错误类型的采样埋点数据包；

根据所述普通类型的采样埋点数据包和埋点采样比，生成第一数据包，所述埋点采样比是指普通类型的埋点总数量与成功拼接的埋点数量的比值；以及，根据所述错误类型的采样埋点数据包，生成第二数据包；

所述向服务器发送针对所述数据包的埋点数据处理请求，包括：

向所述服务器发送针对所述页面的第一埋点数据处理请求，所述第一埋点数据处理请求包括所述第一数据包；以及，向所述服务器发送针对所述页面的第二埋点数据处理请求，所述第二埋点数据处理请求包括所述第二数据包。

3.根据权利要求2所述的埋点数据上报方法，其特征在于，从所述埋点队列中随机抽取普通类型的埋点之前，以及从所述埋点队列中随机抽取错误类型的埋点之前，还包括：

对所述埋点队列中同名的埋点进行合并，并记录合并数量；

从所述埋点队列中随机抽取普通类型的埋点，采用如下方式：

从同名埋点合并后的埋点队列中随机抽取普通类型的埋点；

从所述埋点队列中随机抽取错误类型的埋点，采用如下方式：

从同名埋点合并后的埋点队列中随机抽取错误类型的埋点；

所述方法还包括：

将成功拼接的普通类型的埋点对应的所述合并数量写入生成第一数据包；以及将成功拼接的错误类型的埋点对应的所述合并数量写入生成第二数据包。

4.根据权利要求2所述的埋点数据上报方法，其特征在于，还包括：

在普通类型的埋点上报成功后，需要将普通类型的埋点全部从所述埋点队列中清除；在错误类型的埋点上报成功后，仅将发送成功的错误类型的埋点从所述埋点队列中清除。

5.根据权利要求1所述的埋点数据上报方法，其特征在于，所述埋点数据包包括：埋点的信息、以及埋点所属页面的信息。

6.根据权利要求5所述的埋点数据上报方法，其特征在于，所述埋点的信息至少包括埋点名称，并包括以下信息的至少一者：埋点类型，父埋点，根埋点，合并数量，采集时间。

7.根据权利要求5所述的埋点数据上报方法，其特征在于，所述页面的信息至少包括页面标识，并包括以下信息的至少一者：页面所属仓库名称，页面所属仓库版本。

8.一种埋点数据上报装置，其特征在于，包括：

埋点采集单元，用于将页面中被触发的埋点存储到待发送的埋点队列；

埋点采样单元，用于在预设条件成立时，通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样，获得采样埋点对应的埋点数据包；

所述预设条件采用如下方式：

在页面加载过程中，当页面包括的资源文件下载完成后，根据第一预设时间间隔通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样；

在页面展示过程中，根据第二预设时间间隔通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样；

请求发送单元，用于向服务器发送针对所述页面的埋点数据处理请求，所述埋点数据处理请求包括所述埋点数据包。

9.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储实现埋点数据上报方法的程序，该设备通电并通过所述处理器运行该埋点数据上报方法的程序后，执行下述步骤：将页面中被触发的埋点存储到待发送的埋点队列；在预设条件成立时，通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样，获得采样埋点对应的埋点数据包；所述预设条件采用如下方式：

在页面加载过程中，当页面包括的资源文件下载完成后，根据第一预设时间间隔通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样；

在页面展示过程中，根据第二预设时间间隔通过预设的动态采样算法对所述埋点队列中的埋点进行动态采样；

向服务器发送针对所述页面的埋点数据处理请求，所述埋点数据处理请求包括所述埋点数据包。

10.一种埋点数据处理方法，其特征在于，包括：

接收至少一个客户端发送的针对页面的多个埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；

根据预设的时间间隔，对该时间间隔范围内接收到的所述页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的报警概率算法相关的预设指标的本次数据；

所述报警概率算法相关的预设指标包括以下指标的至少一个：累计次数，父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比；

根据所述预设指标的本次数据和历史数据，通过所述报警概率算法确定所述预设监控埋点的报警概率；

根据所述报警概率和预设的报警概率阈值，确定需要报警的预设监控埋点。

11.根据权利要求10所述的埋点数据处理方法，其特征在于，所述报警概率算法相关的预设指标包括的指标为一个时：

所述报警概率算法包括：

根据所述预设指标的本次数据和历史数据，获取所述预设指标的平均值和方差；

根据所述预设指标的本次数据、所述平均值和方差，通过高斯模型获取所述预设指标的报警概率，作为所述预设监控埋点的报警概率。

12.根据权利要求10所述的埋点数据处理方法，其特征在于，所述报警概率算法相关的预设指标包括的指标为至少两个时：所述报警概率算法包括：

根据所述预设指标的本次数据和历史数据，获取各个预设指标的平均值和方差；

根据所述预设指标的本次数据、所述平均值和方差，通过高斯模型获取各个预设指标的报警概率；

根据所述各个预设指标各自对应的预设报警概率权重和所述各个预设指标的报警概率，获取所述预设监控埋点的报警概率。

13.根据权利要求10所述的埋点数据处理方法，其特征在于，所述预设监控埋点包括多个预设监控埋点，不同的预设监控埋点对应不同的报警概率算法，不同的预设监控埋点对应不同的报警概率阈值。

14.根据权利要求10所述的埋点数据处理方法，其特征在于，还包括：

为所述需要报警的预设监控埋点生成对应的报警消息；

获取所述需要报警的预设监控埋点对应的报警人和报警方式；

根据所述报警方式向所述报警人提供所述报警消息。

15.根据权利要求14所述的埋点数据处理方法，其特征在于，所述报警方式包括：手机短消息，邮件，即时通讯。

16.根据权利要求10所述的埋点数据处理方法，其特征在于，在接收到所述埋点数据处理请求之后，还包括：

解析所述埋点数据包，获得所述埋点数据包对应的埋点数据。

17.根据权利要求16所述的埋点数据处理方法，其特征在于，所述埋点数据包包括普通类型的多个埋点数据和埋点采样比；

所述解析所述埋点数据包，并获得所述埋点数据包对应的埋点数据，包括：

根据所述埋点采样比，确定所述埋点数据包中各个埋点的出现次数；

根据所述各个埋点及所述出现次数，形成所述埋点数据包对应的多个埋点数据。

18.根据权利要求17所述的埋点数据处理方法，其特征在于，所述埋点数据包包括各个埋点的合并数量；

所述根据所述埋点采样比，并确定所述埋点数据包中各个埋点的出现次数，采用如下方式：

将所述埋点采样比和所述埋点的合并数量的乘积作为所述埋点的出现次数。

19.根据权利要求16所述的埋点数据处理方法，其特征在于，所述埋点数据包包括错误类型的多个埋点数据和各个埋点的合并数量；

所述解析所述埋点数据包，并获得所述埋点数据包对应的埋点数据，采用如下方式：

根据所述多个埋点及各个埋点的合并数量，形成所述埋点数据包对应的多个埋点数据。

20.根据权利要求10所述的埋点数据处理方法，其特征在于，所述埋点的信息至少包括埋点名称，并包括以下信息的至少一者：埋点类型，所属父埋点，合并数量，采集时间。

21.根据权利要求10所述的埋点数据处理方法，其特征在于，所述埋点数据包包括所述页面的信息。

22.根据权利要求21所述的埋点数据处理方法，其特征在于，所述页面的信息至少包括页面标识，并包括以下信息的至少一者：页面所属仓库名称，页面所属仓库版本。

23.根据权利要求16所述的埋点数据处理方法，其特征在于，还包括：

存储解析获得的多个埋点数据。

24.根据权利要求23所述的埋点数据处理方法，其特征在于，还包括：

对应各个埋点数据存储所述页面的信息。

25.根据权利要求23所述的埋点数据处理方法，其特征在于，还包括：

对应各个埋点数据存储所述客户端的信息。

26.根据权利要求25所述的埋点数据处理方法，其特征在于，所述客户端的信息包括以下信息的至少一者：设备类型，浏览器，操作***，用户标识，IP地址。

27.一种埋点数据处理装置，其特征在于，包括：

请求接收单元，用于接收至少一个客户端发送的针对页面的多个埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；

数据统计单元，用于根据预设的时间间隔，对该时间间隔范围内接收到的所述页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的报警概率算法相关的预设指标的本次数据；

所述报警概率算法相关的预设指标包括以下指标的至少一个：累计次数，父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比；

报警概率计算单元，用于根据所述预设指标的本次数据和历史数据，通过所述报警概率算法确定所述预设监控埋点的报警概率；

报警埋点确定单元，用于根据所述报警概率和预设的报警概率阈值，确定需要报警的预设监控埋点。

28.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储实现埋点数据处理方法的程序，该设备通电并通过所述处理器运行该埋点数据处理方法的程序后，执行下述步骤：接收至少一个客户端发送的针对页面的多个埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；根据预设的时间间隔，对该时间间隔范围内接收到的所述页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的报警概率算法相关的预设指标的本次数据；所述报警概率算法相关的预设指标包括以下指标的至少一个：累计次数，父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比；

根据所述预设指标的本次数据和历史数据，通过所述报警概率算法确定所述预设监控埋点的报警概率；根据所述报警概率和预设的报警概率阈值，确定需要报警的预设监控埋点。

29.一种埋点数据处理***，其特征在于，包括：根据权利要求9所述的埋点数据上报装置，根据权利要求28所述的埋点数据处理装置。

30.一种埋点数据处理方法，其特征在于，包括：

接收至少一个客户端发送的针对页面的埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；

根据预设的时间间隔，对该时间间隔范围内接收到的所述页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的预设指标的本次数据；

所述预设指标包括以下指标的任意一个：父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比；

根据所述预设指标的本次数据和所述预设指标对应的预设阈值，确定需要报警的预设监控埋点。

31.一种埋点数据处理装置，其特征在于，包括：

请求接收单元，用于接收至少一个客户端发送的针对页面的埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；

数据统计单元，用于根据预设的时间间隔，对该时间间隔范围内接收到的所述页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的预设指标的本次数据；

所述预设指标包括以下指标的任意一个：父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比；

报警埋点确定单元，用于根据所述预设指标的本次数据和所述预设指标对应的预设阈值，确定需要报警的预设监控埋点。

32.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储实现埋点数据处理方法的程序，该设备通电并通过所述处理器运行该埋点数据处理方法的程序后，执行下述步骤：接收至少一个客户端发送的针对页面的埋点数据处理请求，所述埋点数据处理请求包括埋点数据包；根据预设的时间间隔，对该时间间隔范围内接收到的所述页面的多个埋点数据包中的埋点数据进行统计，获得预设监控埋点对应的预设指标的本次数据；所述预设指标包括以下指标的任意一个：父子埋点的累计次数比率，根子埋点的累计次数比率，累计次数的日环比，累计次数的周环比；

根据所述预设指标的本次数据和所述预设指标对应的预设阈值，确定需要报警的预设监控埋点。

33.一种埋点数据处理***，其特征在于，包括：根据权利要求8 所述的埋点数据上报装置，根据权利要求31所述的埋点数据处理装置。

Images