一种采样方法、设备及可读存储介质
技术领域
本发明涉及业务支撑领域,尤其涉及一种采样方法、设备及可读存储介质。
背景技术
服务链路追踪(Spring Cloud Sleuth)是一款开源的分布式实时数据追踪系统(Distributed Tracking System),基于Google Dapper的论文设计而来,其主要功能是聚集来自各个异构系统的实时监控数据。在分布式链路跟踪中,跟踪数据可能会非常大,所以采样数据极其重要。Spring Cloud Sleuth中有一个采样器(Sampler)策略,可以通过实现类来控制采样算法。采样器不会阻碍span相关识别码(identification,id)的产生,但是会对采样数据量和采样数据标签造成影响。
随着平台的发布,分布式服务数量越来越多,结构也越来越复杂,每一个请求路由过来后,会经过多个服务并留下足迹,但是分散数据对于问题排查,或是流程优化都帮助有限。针对跨服务场景,需要对服务的请求数据进行采样上报并分析数据,而目前业内已经有成熟的开源Sleuth数据追踪系统,是按固定的采样率进行数据上报,默认的采样比例为0.1(即10%)。采用固定采样率时,可能会出现两个时间段的请求的数据量差距非常大(例如从一千增到一千万),那采用固定采样率上报的数量差距也很大,使得请求量波动时采样的数据过多或者过少,对效率和可靠性产生极大作用,从而影响业务的程序性能。
发明内容
有鉴于此,本发明实施例期望提供一种采样方法、设备及可读存储介质,能够实时的根据请求数据量和相关参数动态生成合理的采样率,以解决现有技术方案中SpringCloud Sleuth数据追踪系统按固定的采样率进行数据上报在请求量波动时采样数据过多或过少的问题。
本发明的技术方案是这样实现的:
第一方面,本发明实施例提供一种采样方法,所述方法包括:
确定上一次采样时长内按照第一采样比例进行采样得到的采样总量;
根据预设的期望请求数、采样总量和第一采样比例确定第二采样比例;
根据所述期望请求数、预设的队列缓存请求数和达到所述队列缓存请求数个请求所需时间确定第三采样比例;
根据所述第二采样比例、第三采样比例确定修正后的第一采样比例;
在本次采样时长内按照所述修正后的第一采样比例进行采样。
第二方面,本发明实施例提供一种采样设备,所述设备至少包括:存储器、通信总线和处理器,其中:
所述存储器,用于存储采样程序;
所述通信总线,用于实现处理器和存储器之间的连接通信;
所述处理器,用于执行存储器中存储的采样程序,以实现以下步骤:
确定上一次采样时长内按照第一采样比例进行采样得到的采样总量;
根据预设的期望请求数、采样总量和第一采样比例确定第二采样比例;
根据所述期望请求数、预设的队列缓存请求数和达到所述队列缓存请求数个请求所需时间确定第三采样比例;
根据所述第二采样比例、第三采样比例确定修正后的第一采样比例;
在本次采样时长内按照所述修正后的第一采样比例进行采样。
第三方面,本发明实施例提供一种可读存储介质,所述可读存储介质上存储有采样程序,所述采样程序被处理器执行时实现本发明实施例提供的采样方法的步骤。
本发明实施例提供一种采样方法、设备及可读存储介质,其中,首先确定上一次采样时长内按照第一采样比例进行采样得到的采样总量;然后根据预设的期望请求数、采样总量和第一采样比例确定第二采样比例;并根据所述期望请求数、预设的队列缓存请求数和达到所述队列缓存请求数个请求所需时间确定第三采样比例;再根据所述第二采样比例、第三采样比例确定修正后的第一采样比例;在本次采样时长内按照所述修正后的第一采样比例进行采样。如此,能够实时的根据请求数据量和相关参数动态生成合理的采样率,以解决现有技术方案中Spring Cloud Sleuth数据追踪系统按固定的采样率进行数据上报在请求量波动时采样数据过多或过少的问题。
附图说明
图1为本发明实施例采样方法的实现流程示意图;
图2为本发明实施例采样方法的实现流程示意图;
图3为本发明实施例分布式采样数据上报方法的实现流程示意图;
图4为本发明实施例确定修正动态采样率的实现过程示意图;
图5为本发明实施例采样设备的组成结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对发明的具体技术方案做进一步详细描述。以下实施例用于说明本发明,但不用来限制本发明的范围。
实施例一
本发明实施例提供一种采样方法,图1为本发明实施例采样方法的实现流程示意图,如图1所示,所述方法包括以下步骤:
步骤S101,确定上一次采样时长内按照第一采样比例进行采样得到的采样总量。
这里,所述步骤S101可以是由采样设备实现的,在本实施例中,所述采样设备还可以是上报程序客户端。
在本实施例中,采样时长是预先设置好的,例如采样时长可以是1分钟,30秒,2分钟等等。所述第一采样比例是上一次采样时采用的采样比例,第一采样比例也是根据上上次采样的一些相关参数确定出来的。
需要说明的是,本实施例及其他实施例中所说的采样比例,例如第一采样比例、第二采样比例、第三采样比例等等都是0到1之间的数值,例如第一采样比例可以是0.1,它表征的意思是在采样时长内如果接收到N个请求,那么需要从这N个请求中,采集出0.1*N个请求。例如采样时长是1分钟,第一采样比例是0.1,在1分钟内接收到100个服务请求,那么此时在这1分钟采集到的采集总量为100*0.1=10个服务请求。
步骤S102,根据预设的期望请求数、采样总量和第一采样比例确定第二采样比例。
这里,所述步骤S102可以是由采样设备实现的。所述期望请求数是指在采样时长内的期望采集上报的请求数,该期望请求数可以是本实施例采样方法的开发人员根据采样设备的软件参数和硬件参数以及待采集的数据的实际情况而配置的。
所述步骤S102在实现的过程中,首先根据在采样总量和第一采样比例确定出在上一次采样时长内接收到的所有请求的总量,所有请求的总量可以通过采样总量与第一采样比例的比值确定。第二采样比例是将期望请求数和所有请求的总量求比值确定的,第二采样比例也就是能达到期望请求数个请求的期望采样比例。
步骤S103,根据所述期望请求数、预设的队列缓存请求数和达到所述队列缓存请求数个请求所需时间确定第三采样比例。
这里,所述步骤S103可以是由采样设备实现的。队列缓存请求数是根据期望请求数和一个缓存比例确定的,这里,缓存比例可以是开发人员在采样设备上配置的一个可以表征缓存比例的配置参数,例如可以是spring.sleuth.sampler.percentage参数,同样,spring.sleuth.sampler.percentage也是一个0到1之间的数值,在配置该参数时,需要综合考虑采样设备的软件参数和硬件参数,因为这个数值越大,就表明队列缓存请求数越大,那么也就需要更多的存储空间,运行内存等等。
需要说明的是,如果开发人员没有对spring.sleuth.sampler.percentage进行配置,那么spring.sleuth.sampler.percentage的默认值为0.1,将期望请求数和缓存比例相乘得到队列缓存请求数。
这里,达到所述队列缓存请求数个请求所述的时间,也就是达到队列的状态为满时所需的时间,在采样设备首次运行该采样方法时,达到所述队列缓存请求数个请求所需时间为从缓存第一条服务请求的时间点算起,到缓存第N个服务请求的时间点为止,将这中间所用的时间确定为达到所述队列缓存请求数个请求所需时间,其中,N=所述队列缓存请求数。
步骤S104,根据所述第二采样比例、第三采样比例确定修正后的第一采样比例。
这里,所述步骤S104可以是由采样设备实现的。
在本实施例中,是将所述第二采样比例、第三采样比例和1中最小的数值确定为修正后的第一采样比例。
步骤S105,在本次采样时长内按照所述修正后的第一采样比例进行采样。
这里,所述步骤S105可以是由采样设备实现的。
在其他实施例中,在所述步骤S105之后,所述方法还包括:
步骤31,将已存储的第一采样比例更新为修正后的第一采样比例;
步骤32,将所述修正后的第一采样比例和按照所述修正后的第一采样比例进行采样得到的数据发送给服务器。
在本发明实施例提供的采样方法中,首先确定上一次采样时长内按照第一采样比例进行采样得到的采样总量;然后根据预设的期望请求数、采样总量和第一采样比例确定第二采样比例;并根据所述期望请求数、预设的队列缓存请求数和达到所述队列缓存请求数个请求所需时间确定第三采样比例;再根据所述第二采样比例、第三采样比例确定修正后的第一采样比例;在本次采样时长内按照所述修正后的第一采样比例进行采样。如此,能够实时的根据请求数据量和相关参数动态生成合理的采样率,以解决现有技术方案中Spring Cloud Sleuth数据追踪系统按固定的采样率进行数据上报在请求量波动时采样数据过多或过少的问题。
实施例二
基于前述的实施,本发明实施例再提供一种采样方法,图2为本发明实施例采样方法的实现流程示意图,如图2所示,所述方法包括以下步骤:
步骤S201,采样设备启动采样程序。
这里,所述采样设备可以是Spring Cloud应用的客户端,该客户端可以接收用户的微服务请求,并对接收到的微服务请求中进行采样,确定上报给服务器的微服务请求。Spring Cloud是一系列框架的有序集合,也是基于Spring Boot之上的用来快速构建微服务系统的工具集,拥有功能完善的轻量级微服务组件。Spring Boot是由Pivotal团队提供的全新框架,其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置,从而使开发人员不再需要定义样板化的配置。通过这种方式,Spring Boot致力于在蓬勃发展的快速应用开发领域(rapid application development)成为领导者。
步骤S202,所述采样设备获取预设采样时长内的期望请求数和缓存比例。
这里,所述预设采样时长内的期望请求数是指在预设采样时长内期望上报给服务器的请求数,该期望请求数可以是开发人员根据需要在客户端配置的。所述缓存比例为缓存到队列的请求数占所述期望请求数的比例,这个值即为客户端中spring.sleuth.sampler.percentage参数的参数值,开发人员可以根据采样设备的软硬件参数来配置该参数,如果不做配置,则spring.sleuth.sampler.percentage的默认值为0.1。
步骤S203,所述采样设备根据所述期望请求数和缓存比例确定队列缓存请求数。
这里,队列缓存请求数也可以看作是队列的容量,或者队列可缓存的请求的个数。在实现过程中,队列缓存请求数可以通过公式(1-1)确定:
C=E*P(1-1);
其中,在公式(1-1)中,C为队列缓存请求数,E为期望请求数,P为spring.sleuth.sampler.percentage参数的参数值。
步骤S204,所述采样设备判断是否存储有第一采样比例。
这里,如果存储有所述第一采样比例,则表明不是首次采样,此时进入步骤S208确定预设采样时长内按照第一采样比例进行采样得到的采样总量;如果没有存储有所述第一采样比例,则表明此次是首次采样,此时进入步骤S205。
步骤S205,所述采样设备根据所述期望请求数、所述队列缓存请求数和达到所述队列缓存请求数个请求所需时间确定第四采样比例。
这里,在首次采样时,为了确定达到所述队列缓存请求数个请求所需时间,需要先缓存第一条请求到达的时间点数据,然后缓存后续请求,最后缓存第N条请求到达的时间点数据,其中,N等于所述队列缓存请求数,将第N条请求到达的时间点与第一条请求到达的时间点做差,得到达到所述队列缓存请求数个请求所需时间。
在实际实现过程中,可以通过公式(1-2)确定第四采样比例:
其中,在公式(1-2)中,R为第四采样比例,Ts为采样时长,Tf为达到所述队列缓存请求数个请求所需时间,min()为求最小值函数。
需要说明的是,Ts和Tf的单位是相同的,可以都是秒,还可以都是分钟。
步骤S206,所述采样设备将第四采样比例和1中的最小值确定为第一采样比例。
步骤S207,所述采样设备在本次采样时长内按照所述第一采样比例进行采样。
这里,在其他实施例中,在所述步骤S207之后,所述方法还包括:
步骤41,存储所述第一采样比例;
步骤42,将所述第一采样比例和按照所述第一采样比例进行采样采集到的数据发送给服务器。
步骤S208,所述采样设备确定上一次采样时长内按照第一采样比例进行采样得到的采样总量。
步骤S209,所述采样设备根据预设的期望请求数、采样总量和第一采样比例确定第二采样比例。
这里,所述步骤S209可以通过以下步骤实现:
步骤S2091,根据所述采样总量和所述第一采样比例确定预设采样时长内接收到的请求总数;
这里,将所述采样总量除以所述第一采样比例得到的值即为预设采样时长内接收到的请求总数。
步骤S2092,根据所述请求总数和所述期望请求数确定第二采样比例。
这里,将所述请求总数除以所述期望请求数得到的数值即为第二采样比例。
步骤S210,所述采样设备根据所述期望请求数、预设的队列缓存请求数和达到所述队列缓存请求数个请求所需时间确定第三采样比例。
这里,所述步骤S210可以通过以下步骤实现:
步骤S2101,根据所述队列缓存请求数和达到所述队列缓存请求数个请求所需时间确定单位时间内的缓存请求数;
这里需要说明的是,在该步骤中的达到所述队列缓存请求数个请求所需时间和步骤S205中达到所述队列缓存请求数个请求所需时间的计算方法可能是不同的,因此在步骤S205中计算的是首次采样达到所述队列缓存请求数个请求所需时间,在首次采样时,队列是空的,因此这一时间是从缓存第一条请求开始算起的,而在本步骤中,不是首次采样,在上一次采样结束后队列中可能就缓存有一定数量的请求,此时从本次采样开始算起,到缓存了所述队列缓存请求数个请求为止,这一时间间隔为本步骤中达到所述队列缓存请求数个请求所需时间。
将所述队列缓存请求数除以达到所述队列缓存请求数个请求所需时间得到的数值即为单位时间内的缓存请求数。
步骤S2102,根据所述期望请求数和所述预设采样时长确定单位时间内的期望请求数;
这里,将所述期望请求数除以所述预设采样时长得到的数值即为单位时间内的期望请求数。
步骤S2103,根据所述单位时间内的缓存请求数和所述单位时间内的期望请求数确定第三采样比例。
这里,将所述单位时间内的期望请求数除以所述单位时间内的缓存请求数得到的数值即为第三采样比例。
步骤S211,所述采样设备根据所述第二采样比例、第三采样比例确定修正后的第一采样比例。
这里,所述步骤S211在实现的过程中,可以是将所述第二采样比例、第三采样比例和1中最小的数值确定为修正后的第一采样比例。
步骤S212,所述采样设备在本次采样时长内按照所述修正后的第一采样比例进行采样。
这里,在其他实施例中,在所述步骤S212之后,所述方法还包括:
步骤51,存储所述修正后第一采样比例;
步骤52,将所述修正后的第一采样比例和按照所述修正后的第一采样比例进行采样采集到的数据发送给服务器。
在本发明实施例提供的采样方法中,采样设备启动采样程序后,首先获取预设采样时长内的期望请求数和缓存比例并根据所述期望请求数和缓存比例确定队列缓存请求数;然后判断是否存储有第一采样比例,如果没有存储有第一采样比例,根据所述期望请求数、所述队列缓存请求数和达到所述队列缓存请求数个请求所需时间确定第四采样比例;将第四采样比例和1中的最小值确定为第一采样比例;在本次采样时长内按照所述第一采样比例进行采样;如果存储有所述第一采样比例,确定上一次采样时长内按照第一采样比例进行采样得到的采样总量;根据预设的期望请求数、采样总量和第一采样比例确定第二采样比例;根据所述期望请求数、预设的队列缓存请求数和达到所述队列缓存请求数个请求所需时间确定第三采样比例;根据所述第二采样比例、第三采样比例确定修正后的第一采样比例;在本次采样时长内按照所述修正后的第一采样比例进行采样,如此,不仅在首次采样时能够确定出动态的采样比例,并且在后续的采样过程中还可以对动态的采样比例进行修正,以得到合理的采样率从而提高分布式链路跟踪数据精准度,并进一步完善分析服务性能。
实施例三
本实施例提供一种基于Spring Cloud Sleuth的分布式采样数据上报方法,主要包括:改造Sleuth数据上报部分功能代码,去除原固定比例上报处理、上报程序客户端根据请求时间数据按照队列缓存、请求量与参数动态的生成采样率,并根据动态生成的采样率采集一个周期(1分钟)的数据,同时将实时的采样率写入到上报span数据中,以更好的分析服务、采样完成后根据新的缓存数据修正动态采样率,最后循环完成。
图3为本发明实施例分布式采样数据上报方法的实现流程示意图,如图3所示,所述方法包括以下步骤:
步骤S301,根据需要配置客户端每分钟期望的上报数据量expectSize,根据需要配置spring.sleuth.sampler.percentage参数(如果不配置默认0.1);
这里,spring.sleuth.sampler.percentage参数的值介于0.0到1.0之间,1.0则表示全部采集,也可以通过实现bean的方式来设置采样为全部采样(AlwaysSampler)或者不采样(NeverSampler),设置合理的采样率可以提高分布式链路跟踪数据精准度,更加完善分析服务性能。
步骤S302,通过expectSize*spring.sleuth.sampler.percentage计算得出队列缓存数量cacheQueueSize;
步骤S303,首次运行时先缓存cacheQueueSize条请求到达的时间点数据;
步骤S304,计算此时达到cacheQueueSize条请求所需的时间cacheQueueFullTime(秒);
步骤S305,计算出此时的动态采样率。
这里,可以根据公式(2-1)计算动态采样率:
其中,在公式(2-1)中,expectSize为每分钟期望的上报数据量,cacheQueueSize为队列缓存数量,cacheQueueFullTime为达到cacheQueueSize条请求所需的时间。
对公式(2-1)进行整理得到公式(2-2):
图4为本发明实施例确定修正动态采样率的实现过程示意图,如图4所示,根据固定时间内(1分钟)的采样总量、达到cacheQueueSize条请求所需时间和期望的上报数据量可以对动态采样率进行修正。也就是说,按动态采样率采样1分钟,记录下1分钟之内的采样总量totalSize,同时仍需通过队列先进先出的方式记录时间点缓存数据,同时在上报的span数据中记录此时的生效的动态采样率,用于分析服务的总请求量,1分钟采样完成后根据新的缓存数据修正动态采样率。
在实现过程中,可以根据公式(2-3)来确定修正后的动态采样率:
其中,在公式(2-3)中,ratem为修正动态采样率,totalSize为1分钟内采集到的采样总量,old_rate为在这1分钟内进行采样时的采样率,cacheQueueFullTime为在这1分钟内再次达到达到cacheQueueSize条请求所需的时间。
在本实施例中提供的基于Spring Cloud Sleuth分布式采样数据生成动态采样率的计算方法中,是根据期望上报的请求量与相关参数动态生成采样率,再根据生成的采样率采集一个周期的数据,同时将动态生成的采样率写入到上报span数据中,以更好的分析服务,并且在一次采样周期采样完成后根据新的缓存数据修正动态采样率。
虽然当第一次启动程序之后,请求量很小且没有达到开始默认设置的采样率时,会造成此时的采样率不精准,现有的方案和技术与本发明都存在此问题,但与现有技术相比,利用本实施例提供的基于Spring Cloud Sleuth分布式采样数据生成动态采样率的计算方法,在高并发的情况下,请求量非常大或者请求量波动过大,能够克服固定的采样率造成采样数据不合理,而影响服务性能或分析效果的技术问题,采用动态的采用率可以很好的实现对数据的采集,优化系统的性能。
在本实施例中采用消息队列(Message Queue,MQ)或关键值(key-value)存储系统(redis)等其他的采用套接字(socket)方式通信,利用消息中间件或数据库缓存的实现方式,可以实时根据流量,动态调整采样率,以到达更准确的分析和服务性能的维护的技术目的,从而使系统得到有效的提升。
利用本实施提供的计算动态采样率的方法能够使得微服务架构中的程序,每个请求的步骤更加清晰可见,一旦出了问题,更快的精准定位,更好的提高工作效率和系统可靠性,从而对系统的服务性能和效果分析提供明显的改善。
实施例四
本发明实施例提供一种采样设备,图5为本发明实施例采样设备的组成结构示意图,如图5所示,所述设备500至少包括:存储器501、通信总线502和处理器503,其中:
所述存储器501,用于存储采样程序;
所述通信总线502,用于实现处理器和存储器之间的连接通信;
所述处理器503,用于执行存储器中存储的采样程序,以实现以下步骤:
确定上一次采样时长内按照第一采样比例进行采样得到的采样总量;
根据预设的期望请求数、采样总量和第一采样比例确定第二采样比例;
根据所述期望请求数、预设的队列缓存请求数和达到所述队列缓存请求数个请求所需时间确定第三采样比例;
根据所述第二采样比例、第三采样比例确定修正后的第一采样比例;
在本次采样时长内按照所述修正后的第一采样比例进行采样。
需要说明的是,以上采样设备实施例的描述,与上述方法实施例的描述是类似的,具有同方法实施例相似的有益效果,因此不做赘述。对于本发明采样设备实施例中未披露的技术细节,请参照本发明方法实施例的描述而理解。
相应地,本发明实施例提供一种计算机可读存储介质,所述计算机可读存储介质上存储有采样程序,所述采样程序被处理器执行时实现本发明其他实施例提供的采样方法的步骤。
应理解,说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此,在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外,这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解,在本发明的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
在本申请所提供的几个实施例中,应该理解到,所揭露的设备和方法,可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,如:多个单元或组件可以结合,或可以集成到另一个系统,或一些特征可以忽略,或不执行。另外,所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口,设备或单元的间接耦合或通信连接,可以是电性的、机械的或其它形式的。
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的,作为单元显示的部件可以是、或也可以不是物理单元;既可以位于一个地方,也可以分布到多个网络单元上;可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
另外,在本发明各实施例中的各功能单元可以全部集成在一个处理单元中,也可以是各单元分别单独作为一个单元,也可以两个或两个以上单元集成在一个单元中;上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:移动存储设备、只读存储器(Read Only Memory,ROM)、磁碟或者光盘等各种可以存储程序代码的介质。
或者,本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括:移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以所述权利要求的保护范围为准。