CN117724937A - 日志资源管理方法及相关装置 - Google Patents
日志资源管理方法及相关装置 Download PDFInfo
- Publication number
- CN117724937A CN117724937A CN202410172798.1A CN202410172798A CN117724937A CN 117724937 A CN117724937 A CN 117724937A CN 202410172798 A CN202410172798 A CN 202410172798A CN 117724937 A CN117724937 A CN 117724937A
- Authority
- CN
- China
- Prior art keywords
- electronic device
- value
- log
- weight
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000007726 management method Methods 0.000 title abstract description 32
- 238000000034 method Methods 0.000 claims abstract description 83
- 230000002596 correlated effect Effects 0.000 claims description 30
- 230000008569 process Effects 0.000 claims description 28
- 230000006870 function Effects 0.000 claims description 27
- 238000004590 computer program Methods 0.000 claims description 16
- 230000000903 blocking effect Effects 0.000 claims description 9
- 229910010888 LiIn Inorganic materials 0.000 claims 1
- 238000004458 analytical method Methods 0.000 abstract description 13
- 230000000875 corresponding effect Effects 0.000 description 66
- 230000035945 sensitivity Effects 0.000 description 60
- 238000012545 processing Methods 0.000 description 34
- 238000004364 calculation method Methods 0.000 description 31
- 238000010586 diagram Methods 0.000 description 15
- 238000004891 communication Methods 0.000 description 12
- 238000005516 engineering process Methods 0.000 description 6
- 238000013461 design Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 238000010606 normalization Methods 0.000 description 4
- 238000013468 resource allocation Methods 0.000 description 3
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 238000013528 artificial neural network Methods 0.000 description 2
- 230000003190 augmentative effect Effects 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000009877 rendering Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 230000001133 acceleration Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 210000000988 bone and bone Anatomy 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 239000011521 glass Substances 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 239000004984 smart glass Substances 0.000 description 1
- 238000001356 surgical procedure Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000003786 synthesis reaction Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本申请实施例提供的日志资源管理方法及相关装置,涉及终端技术领域。方法包括:可以考虑用户提供问题单的数量、采集的日志的数量以及采集的性能故障打点的数量,并将其作为分配上传日志资源的因素。这样,对于频繁发生性能卡顿问题的电子设备,可以上传更多的日志信息,方便开发人员进行问题定位和分析。对于较少发生性能卡顿问题的电子设备,可以上传较少的日志信息,从而合理的分配上传日志的资源。
Description
技术领域
本申请涉及终端技术领域,尤其涉及日志资源管理方法及相关装置。
背景技术
电子设备在运行过程中可以打印日志,日志中可以包括函数间的调用信息、进程或线程的调度信息、系统运行的性能信息等。电子设备还可以将日志上传给云端服务器,开发人员可以基于云端服务器中的日志进行问题定位和分析。
然而,开发人员在进行问题定位时,可能存在获得的日志信息不足的情况,使得定位问题较为困难。
发明内容
本申请实施例提供的日志资源管理方法及相关装置,可以考虑用户提供问题单的数量、采集的日志的数量以及采集的性能故障打点的数量,并将其作为分配上传日志资源的因素。这样,对于频繁发生性能卡顿问题的电子设备,可以上传更多的日志信息,方便开发人员进行问题定位和分析。对于较少发生性能卡顿问题的电子设备,可以上传较少的日志信息,从而合理的分配上传日志的资源。
第一方面,本申请实施例提供的日志资源管理方法,方法应用于第一电子设备,方法包括:
接收来自N个电子设备的日志数据,N个电子设备包括第二电子设备和第三电子设备,N为大于1的整数;确定第一值,以及第二值,其中,第一值用于指示第二电子设备向第一电子设备上传日志数量的最大值,第一值与第二电子设备向第一电子设备上传日志数据的频率正相关,第二值用于指示第三电子设备向第一电子设备上传日志数量的最大值,第二值与第三电子设备向第一电子设备上传日志数据的频率正相关,第一值与第二值不同;向第二电子设备发送第一值;向第三电子设备发送第二值。这样,对于问题单数量较多、性能日志数量较多和/或性能故障打点数量较多的电子设备,可以分配较多的上传日志的资源;对于问题单数量较少、性能日志数量较少和/或性能故障打点数量较少的电子设备,可以分配较少的上传日志的资源。也可以理解为,对于频繁发生性能卡顿问题的电子设备,可以上传更多的日志信息,方便开发人员进行问题定位和分析。对于较少发生性能卡顿问题的电子设备,可以上传较少的日志信息,从而合理的分配上传日志的资源。
一种可能的实现中,接收来自N个电子设备的日志数据之后,还包括:确定第一权重,第一权重与第二电子设备向第一电子设备上传日志数据的频率在N个电子设备向第一电子设备上传日志数据的频率中的排名正相关;确定第一值,包括:基于第一权重确定第一值,第一权重和第一值正相关。当第一权重较大时,电子设备可以分配到较多的日志配额,有利于问题的定位与分析;当第一权重较小时,电子设备可以分配到较少的日志配额。这样,云端服务器可以采集到较多有用的性能日志,从而方便开发人员基于性能日志定位和解决问题。
一种可能的实现中,第一权重与第一值满足下述公式:
。
其中,wi为第一权重,Li为第一值,L adjust 为第一电子设备为第i个电子设备预设的上传日志的数量,i为大于或等于1的整数,i小于或等于N。第一电子设备可以对各个电子设备的可调整日志配额进行求和,得到总的可调整日志配额。该总的可调整日志配额可以理解为公共资源池,这样,每个电子设备可以基于日志权重的大小从该公共资源池中获取更多或更少的日志配额。
一种可能的实现中,第一权重与第一值满足下述公式:
。
其中,wi为第一权重,Li为第一值,L adjust 为第一电子设备为第i个电子设备设置的可调整日志的数量,L basic 为第一电子设备为第i个电子设备设置的上传日志数量的最小值,i为大于或等于1的整数,i小于或等于N。第一电子设备可以为每个电子设备分配基础日志配额和可调整日志配额。基础日志配额使得各个电子设备均可以得到一定的日志配额。对于上传日志频率较少的电子设备,当该电子设备出现故障时,开发人员依然可以通过日志信息对该电子设备进行问题定位和分析。这样,在云端服务器为电子设备分配日志资源总量不变,且不增加云端服务器压力的前提下,可以基于日志权重的不同对日志上传的资源进行合理的调整和分配,从而提升日志采集的效率。
一种可能的实现中,向第二电子设备发送第一值,包括:在第L周期内,向第二电子设备发送第一值,L为大于或等于1的整数;向第二电子设备发送第一值之后,还包括:在第L+1周期内,接收来自第二电子设备的日志数据;确定第三值,第三值用于指示第二电子设备向第一电子设备上传日志数量的最大值,第三值与第二电子设备向第一电子设备上传日志数据的频率正相关;向第二电子设备发送第三值。同一电子设备,在不同的周期内,所得到的日志配额可以相同或不同。这样,可以根据第二电子设备在不同周期内上传日志数量的不同,灵活调整第二电子设备的日志配额,从而合理的利用第一电子设备的内存资源。
一种可能的实现中,确定第三值之前,还包括:确定第三权重,第三权重与下述的一项或多项成正相关:第二电子设备向第一电子设备上传日志数据的频率在N个电子设备向第一电子设备上传日志数据的频率中的排名、第一权重;确定第三值,包括:基于第三权重确定第三值,第三权重和第三值正相关。由于用户在使用电子设备的过程中,用户的习惯可能不会有较大的改变,因此,在计算第三权重时,可以结合考虑上一周期的第一权重,这样可以将上一周期的日志权重作为经验值进行参考,从而得到更加准确合理的日志权重。
一种可能的实现中,第三权重满足下述公式:
。
其中,wi为第三权重,为基于第二电子设备向第一电子设备上传日志数据的频率在N个电子设备向第一电子设备上传日志数据的频率中的排名得到的权重,/>为第一权重,D为第一权重在第L+1周期中所占的权重。在计算第三权重时,可以结合考虑上一周期的第一权重,这样可以考虑用户之前的习惯,得到更加准确合理的日志权重。
一种可能的实现中,日志数据包括下述的一项或多项:问题单信息、性能日志信息或故障打点信息;其中,问题单信息用于记录电子设备中出现的问题,问题单信息包括下述的一种或多种信息:问题描述、与问题相关的图片、问题出现频率或问题类型;性能日志信息用于记录电子设备的运行状态,性能日志信息包括下述的一种或多种信息:函数间的调用信息、进程或线程的调度信息、内核的负载信息、内核的使用率或线程在内核上的运行状态;故障打点信息用于记录电子设备中发生的卡顿,故障打点信息包括下述的一种或多种信息:卡顿类型、卡顿时间或卡顿等级。这样,第一电子设备可以基于各个电子设备上传的日志数据,统计问题单的数量、性能日志的数量以及故障打点的数量,从而计算各个电子设备的日志配额,使得日志资源的分配更为合理。
一种可能的实现中,第一电子设备包括第一服务、第二服务和第三服务,接收来自N个电子设备的日志数据之后,还包括:第一服务基于第二电子设备的日志数据统计第四值、第五值、第六值,第四值包括问题单的数量,第五值包括日志的数量,第六值包括故障打点的数量;确定第一值之前,还包括:第二服务确定第二电子设备在N个电子设备中的排名,排名与下述的一项或多项成正相关:第四值、第五值或第六值;第二服务确定第一权重;确定第一值,包括:第二服务基于第一权重确定第一值,第一权重和第一值正相关;向第二电子设备发送第一值,包括:第三服务向第二电子设备发送第一值。对于性能敏感度较高的电子设备,日志配额计算服务可以设置较大的日志权重,从而可以分配较多的上传日志的资源。对于性能敏感度较低的电子设备,日志配额计算服务可以设置较小的日志权重,从而可以分配较少的上传日志的资源。这样,云端服务器可以采集到较多有用的性能日志,从而方便开发人员基于性能日志定位和解决问题。
一种可能的实现中,第一服务保存有上一周期的权重值,第二服务确定第一权重之前,还包括:第二服务从第一服务中获取上一周期的权重值;第二服务确定第一权重,包括:第二服务基于排名和上一周期的权重值确定第一权重。第一服务可以记录各个电子设备的日志配额的权重,在第二服务计算下一周期的日志配额时,可以从第一服务获取前一次记录的日志配额的权重,作为计算下一周期的日志配额的参考数据。这样,可以将上一周期的日志权重作为经验值进行参考,从而得到更加准确合理的日志权重。
一种可能的实现中,第二电子设备包括第四服务和第五服务,第四服务,用于接收来自第一电子设备的第一值,并向第五服务传递第一值;第五服务,用于基于第一值确定是否允许第二电子设备向第一电子设备上传日志,若第二电子设备向第一电子设备上传日志的数量小于第一值,则允许第二电子设备向第一电子设备上传日志;或者,若第二电子设备向第一电子设备上传日志的数量等于第一值,则不允许第二电子设备向第一电子设备上传日志。对于上传日志较多的电子设备,可以得到较多的上传日志的资源,方便开发人员进行问题定位和分析。对于上传日志较少的电子设备,可以得到较少的上传日志的资源,这样,可以合理的分配上传日志的资源,方便开发人员对问题的定位与分析。
第二方面,本申请实施例提供一种日志资源管理的装置,该装置可以是电子设备,也可以是电子设备内的芯片或者芯片系统。该装置可以包括处理单元。处理单元用于实现第一方面或第一方面的任意一种可能的实现方式中电子设备执行的与处理相关的任意方法。当该装置是电子设备时,该处理单元可以是处理器。该装置还可以包括存储单元,该存储单元可以是存储器。该存储单元用于存储指令,该处理单元执行该存储单元所存储的指令,以使该电子设备实现第一方面或第一方面的任意一种可能的实现方式中描述的方法。当该装置是电子设备内的芯片或者芯片系统时,该处理单元可以是处理器。该处理单元执行存储单元所存储的指令,以使该电子设备实现第一方面或第一方面的任意一种可能的实现方式中描述的方法。该存储单元可以是该芯片内的存储单元(例如,寄存器、缓存等),也可以是该电子设备内的位于该芯片外部的存储单元(例如,只读存储器、随机存取存储器等)。
示例性的,处理单元,用于接收来自N个电子设备的日志数据;还用于确定第一值,以及第二值;具体还用于向第二电子设备发送第一值;还用于向第三电子设备发送第二值。
一种可能的实现方式中,处理单元,用于确定第一权重;还用于基于第一权重确定第一值。
一种可能的实现方式中,第一权重与第一值满足下述公式:
。
其中,wi为第一权重,Li为第一值,L adjust 为第一电子设备为第i个电子设备预设的上传日志的数量,i为大于或等于1的整数,i小于或等于N。
一种可能的实现方式中,第一权重与第一值满足下述公式:
。
其中,wi为第一权重,Li为第一值,L adjust 为第一电子设备为第i个电子设备设置的可调整日志的数量,L basic 为第一电子设备为第i个电子设备设置的上传日志数量的最小值,i为大于或等于1的整数,i小于或等于N。
一种可能的实现方式中,处理单元,用于在第L周期内,向第二电子设备发送第一值,还用于在第L+1周期内,接收来自第二电子设备的日志数据;具体还用于确定第三值,还用于向第二电子设备发送第三值。
一种可能的实现方式中,处理单元,用于确定第三权重;还用于基于第三权重确定第三值。
一种可能的实现方式中,第三权重满足下述公式:
。
其中,wi为第三权重,为基于第二电子设备向第一电子设备上传日志数据的频率在N个电子设备向第一电子设备上传日志数据的频率中的排名得到的权重,/>为第一权重,D为第一权重在第L+1周期中所占的权重。
一种可能的实现方式中,日志数据包括下述的一项或多项:问题单信息、性能日志信息或故障打点信息。
一种可能的实现方式中,处理单元,用于基于第二电子设备的日志数据统计第四值、第五值、第六值,还用于确定第二电子设备在N个电子设备中的排名,还用于确定第一权重;具体还用于基于第一权重确定第一值,还用于向第二电子设备发送第一值。
一种可能的实现方式中,处理单元,用于从第一服务中获取上一周期的权重值;还用于基于排名和上一周期的权重值确定第一权重。
一种可能的实现方式中,第二电子设备包括第四服务和第五服务,第四服务,用于接收来自第一电子设备的第一值,并向第五服务传递第一值;第五服务,用于基于第一值确定是否允许第二电子设备向第一电子设备上传日志,若第二电子设备向第一电子设备上传日志的数量小于第一值,则允许第二电子设备向第一电子设备上传日志;或者,若第二电子设备向第一电子设备上传日志的数量等于第一值,则不允许第二电子设备向第一电子设备上传日志。
第三方面,本申请实施例提供一种电子设备,包括一个或多个处理器和存储器,存储器与一个或多个处理器耦合,存储器用于存储计算机程序代码,计算机程序代码包括计算机指令,一个或多个处理器调用计算机指令以使得电子设备执行第一方面或第一方面的任意一种可能的实现方式中描述的方法。
第四方面,本申请实施例提供一种系统,该系统包括:第一电子设备和第二电子设备,第一电子设备用于执行第一方面或第一方面的任意一种可能的实现方式中描述的方法。
第二电子设备用于向第一电子设备上传日志数据,第二电子设备还用于接收来自第一电子设备的第一值,第二电子设备还用于基于第一值确定是否允许第二电子设备向第一电子设备上传日志。
第五方面,本申请提供一种芯片或者芯片系统,该芯片或者芯片系统应用于电子设备,该芯片或者芯片系统包括一个或多个处理器和通信接口,通信接口和至少一个处理器通过线路互联,一个或多个处理器用于调用计算机指令以使得电子设备执行第一方面或第一方面的任意一种可能的实现方式中描述的方法。其中,芯片中的通信接口可以为输入/输出接口、管脚或电路等。
在一种可能的实现中,本申请中上述描述的芯片或者芯片系统还包括至少一个存储器,该至少一个存储器中存储有指令。该存储器可以为芯片内部的存储单元,例如,寄存器、缓存等,也可以是该芯片的存储单元(例如,只读存储器、随机存取存储器等)。
第六方面,本申请实施例提供一种计算机可读存储介质,计算机可读存储介质包括计算机指令,当计算机指令在电子设备上运行时,使得电子设备执行第一方面或第一方面的任意一种可能的实现方式中描述的方法。
第七方面,本申请实施例提供一种计算机程序产品,该计算机程序产品包括计算机程序代码,当计算机程序代码在电子设备上运行时,使得电子设备执行第一方面或第一方面的任意一种可能的实现方式中描述的方法。
应当理解的是,本申请的第二方面至第七方面与本申请的第一方面的技术方案相对应,各方面及对应的可行实施方式所取得的有益效果相似,不再赘述。
附图说明
图1为本申请实施例提供的一种电子设备的结构示意图;
图2为本申请实施例提供的一种电子设备的软件结构示意图;
图3为本申请实施例提供的一种日志资源管理方法的流程图;
图4为本申请实施例提供的一种生成日志配额的示意图;
图5为本申请实施例提供的一种日志资源管理方法的示意图;
图6为本申请实施例提供的一种芯片的结构示意图。
具体实施方式
为了便于清楚描述本申请实施例的技术方案,以下,对本申请实施例中所涉及的部分术语和技术进行简单介绍:
1、术语
在本申请的实施例中,采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如,第一芯片和第二芯片仅仅是为了区分不同的芯片,并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定,并且“第一”、“第二”等字样也并不限定一定不同。
需要说明的是,本申请实施例中,“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言,使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
本申请实施例中,“至少一个”是指一个或者多个,“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B的情况,其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b,或c中的至少一项(个),可以表示:a,b,c,a-b,a--c,b-c,或a-b-c,其中a,b,c可以是单个,也可以是多个。
电子设备在运行过程中可以打印日志,日志中可以包括函数间的调用信息、进程或线程的调度信息、系统运行的性能信息等。其中,性能信息可以包括CPU的负载信息、CPU的使用率、线程在内核上的运行状态等信息。电子设备还可以将日志上传给服务器,开发人员可以基于服务器中的日志进行问题定位和分析。一些场景中,服务器也可以称为云端服务器,为了便于描述,后续均以云端服务器为例进行说明。
一些实现中,云端服务器可以为电子设备分配固定的上传日志的资源。示例性的,每个电子设备在一个周期内可以向云端服务器上传预设数量的日志。其中,该周期可以由云端服务器或电子设备预先设置,例如该周期可以包括一天或一周等,具体的周期,本申请实施例不作限定。可以理解的是,当电子设备上传的日志数量超过预设数量时,则无法继续上传日志。
然而,由于用户使用电子设备的习惯存在较大的差异,使得不同的电子设备发生性能卡顿问题的频率不同。例如,有些用户可能不会经常清理电子设备的后台应用,或者可能经常玩游戏、看视频等,这时电子设备可能较大概率处于高负载的情况,从而较为频繁的发生性能卡顿问题。而有些用户可能经常清理电子设备的后台应用,或者使用一些使电子设备负载较小的功能等,则电子设备会较少的发生性能卡顿问题。
对于频繁发生性能卡顿问题的电子设备,其上传日志的数量容易超过预设数量,使得无法继续上传新生成的日志,导致开发人员进行问题定位时,获得的日志信息不足,不容易准确定位到问题原因。
对于较少发生性能卡顿问题的电子设备,其上传日志的数量不容易超过预设数量,导致云端服务器为这类电子设备分配了较多的上传日志的资源。
有鉴于此,本申请实施例提供的日志资源管理方法,可以考虑用户提供问题单的数量、采集的日志的数量以及采集的性能故障打点的数量,并将其作为分配上传日志资源的因素。示例性的,对于用户提供问题单数量较多、采集的日志数量较多和/或采集的性能故障打点数量较多的电子设备,可以分配较多的上传日志的资源;对于用户提供问题单数量较少、采集的日志数量较少和/或采集的性能故障打点数量较少的电子设备,可以分配较少的上传日志的资源。这样,对于频繁发生性能卡顿问题的电子设备,可以上传更多的日志信息,方便开发人员进行问题定位和分析。对于较少发生性能卡顿问题的电子设备,可以上传较少的日志信息,从而合理的分配上传日志的资源。
可以理解的是,本申请实施例的电子设备可以包括云端服务器或任意形式的终端设备,例如,终端设备可以包括:手机(mobile phone)、平板电脑、掌上电脑、笔记本电脑、移动互联网设备(mobile internet device,MID)、可穿戴设备,虚拟现实(virtual reality,VR)设备、增强现实(augmented reality,AR)设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端、蜂窝电话、无绳电话、会话启动协议(session initiation protocol,SIP)电话、无线本地环路(wireless local loop,WLL)站、个人数字助理(personal digitalassistant,PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备,5G网络中的终端设备或者未来演进的公用陆地移动通信网络(publicland mobile network,PLMN)中的终端设备等,本申请实施例对此并不限定。
作为示例而非限定,在本申请实施例中,该电子设备还可以是可穿戴设备。可穿戴设备也可以称为穿戴式智能设备,是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称,如眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上,或是整合到用户的衣服或配件的一种便携式设备。可穿戴设备不仅仅是一种硬件设备,更是通过软件支持以及数据交互、云端交互来实现强大的功能。广义穿戴式智能设备包括功能全、尺寸大、可不依赖智能手机实现完整或者部分的功能,例如:智能手表或智能眼镜等,以及只专注于某一类应用功能,需要和其它设备如智能手机配合使用,如各类进行体征监测的智能手环、智能首饰等。
此外,在本申请实施例中,电子设备还可以是物联网(internet of things,IoT)系统中的电子设备,IoT是未来信息技术发展的重要组成部分,其主要技术特点是将物品通过通信技术与网络连接,从而实现人机互连,物物互连的智能化网络。
本申请实施例中的电子设备也可以称为:用户设备(user equipment,UE)、移动台(mobile station,MS)、移动终端(mobile terminal,MT)、接入终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置等。
在本申请实施例中,电子设备或各个网络设备包括硬件层、运行在硬件层之上的操作系统层,以及运行在操作系统层上的应用层。该硬件层包括中央处理器(centralprocessing unit,CPU)、内存管理单元(memory management unit,MMU)和内存(也称为主存)等硬件。该操作系统可以是任意一种或多种通过进程(process)实现业务处理的计算机操作系统,例如,Linux操作系统、Unix操作系统、Android操作系统、iOS操作系统或windows操作系统等。该应用层包含浏览器、通讯录、文字处理软件、即时通信软件等应用。
本申请实施例中,电子设备可以包括第一电子设备和第二电子设备。
其中,第一电子设备可以包括算力较强和/或存储能力较强的电子设备,例如第一电子设备可以包括云端服务器等。为了便于描述,后续以第一电子设备为云端服务器为例进行说明。
第二电子设备可以包括用户频繁操作的电子设备,例如第二电子设备可以包括手机、平板、手表等。本申请实施例对具体的第一电子设备和第二电子设备不作限定。下面以第二电子设备为例,说明电子设备的硬件结构示意图和软件架构示意图。
示例性的,图1示出了第二电子设备的硬件结构示意图。
电子设备可以包括处理器110,外部存储器接口120,内部存储器121,通用串行总线(universal serial bus,USB)接口130,充电管理模块140,电源管理模块141,电池142,天线1,天线2,移动通信模块150,无线通信模块160,音频模块170,扬声器170A,受话器170B,麦克风170C,耳机接口170D,传感器模块180,按键190,马达191,指示器192,摄像头193,显示屏194,以及用户标识模块(subscriber identification module,SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A,陀螺仪传感器180B,气压传感器180C,磁传感器180D,加速度传感器180E,距离传感器180F,接近光传感器180G,指纹传感器180H,温度传感器180J,触摸传感器180K,环境光传感器180L,骨传导传感器180M等。
可以理解的是,本申请实施例示意的结构并不构成对电子设备的具体限定。在本申请另一些实施例中,电子设备可以包括比图示更多或更少的部件,或者组合某些部件,或者拆分某些部件,或者不同的部件布置。图示的部件可以包括硬件,软件或软件和硬件的组合实现。
处理器110可以包括一个或多个处理单元,例如:处理器110可以包括应用处理器(application processor,AP),调制解调处理器,图形处理器(graphics processingunit,GPU),图像信号处理器(image signal processor,ISP),控制器,视频编解码器,数字信号处理器(digital signalprocessor,DSP),基带处理器,和/或神经网络处理器(neural-network processing unit,NPU)等。其中,不同的处理单元可以是独立的器件,也可以集成在一个或多个处理器中。控制器可以根据指令操作码和时序信号,产生操作控制信号,完成取指令和执行指令的控制。
处理器110中还可以设置存储器,用于存储指令和数据。在一些实施例中,处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据,可从上述存储器中直接调用。避免了重复存取,减少了处理器110的等待时间,因而提高了系统的效率。例如本申请实施例中,处理器110可以用于处理日志的采集和日志的上传等流程。
可以理解的是,本申请实施例示意的各模块间的接口连接关系,只是示意性说明,并不构成对电子设备的结构限定。在本申请另一些实施例中,电子设备也可以采用上述实施例中不同的接口连接方式,或多种接口连接方式的组合。
内部存储器121可以用于存储计算机可执行程序代码,可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。其中,存储程序区可存储操作系统,至少一个功能所需的应用程序等。存储数据区可存储电子设备使用过程中所创建的数据等。此外,内部存储器121可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件,闪存器件,通用闪存存储器(universal flash storage,UFS)等。处理器110通过运行存储在内部存储器121的指令,和/或存储在设置于处理器中的存储器的指令,执行电子设备的各种功能应用以及数据处理。例如本申请实施例中,内部存储器121可以用于存储日志,还可以用于存储日志采集和日志上传的相关代码等。
图2示出了本申请实施例的第二电子设备的软件架构示意图。分层架构将软件分成若干个层,每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中,将Android系统分为五层,从上至下分别为应用程序层,应用程序框架层,安卓运行时(Android runtime)和系统库,硬件抽象层(hardware adaptation layer,HAL),以及内核层。
应用程序层也可以称为应用层,应用层可以包括一系列应用程序包。如图2所示,应用程序包可以包括云化参数更新服务、桌面、相机等应用程序。应用程序可以包括系统应用和三方应用。
其中,本申请实施例中,云化参数更新服务可以用于和云端服务器的云端推送服务进行交互,从云端服务器获取数据包。云化参数更新服务还可以对数据包进行解压,从而得到日志配额等相关信息。
应用程序框架层也可以称为Framework层,Framework层可以为应用层的应用程序提供应用编程接口(application programming interface,API)和编程框架。Framework层可以包括一些预先定义的函数。
如图2所示,Framework层可以包括活动管理器、窗口管理器和视图管理器等。
活动管理器可以负责应用程序的生命周期管理、任务栈管理、进程管理和权限管理等。
窗口管理器可以负责窗口程序的管理。窗口管理器可以获取显示屏大小,判断是否有状态栏、锁定屏幕、触摸屏幕、拖拽屏幕、截取屏幕等。
视图管理器可以负责应用程序的界面绘制和事件处理。
Android runtime包括核心库和虚拟机。Android runtime负责安卓系统的控制和管理。
核心库包含两部分:一部分是java语言需要调用的功能函数,另一部分是安卓的核心库。
应用层和Framework层运行在虚拟机中。虚拟机将应用层和Framework层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理,堆栈管理,线程管理,安全和异常的管理,以及垃圾回收等功能。例如本申请实施例中,虚拟机可以用于执行日志的采集以及日志的上传管控等功能。
系统库也可以称为Native层,Native层可以包括多个功能模块。例如:Native层可以包括日志采集服务、日志库、流量管控服务、网络库和图形库等。
日志采集服务可以用于采集电子设备运行过程中生成的日志等。
日志库可以用于保存日志采集服务采集的日志。
流量管控服务可以用于在电子设备向云端服务器上传日志时,确定当前是否超出日志配额。若超出日志配额,则无法继续上传日志;若未超出日志配额,则可以继续上传日志。由于电子设备上传日志时,需要消耗一定的流量数据,因此,一些场景中,对上传日志数量的管控也可以理解为流量管控。
网络库可以用于处理网络请求和响应。网络库可以提供与网络处理相关的API,并支持同步和异步网络请求、文件上传和下载等功能,例如网络库可以包括okhttp网络框架等。
图形库用于实现三维图形绘图、图像渲染、合成和图层处理等。
硬件抽象层是介于内核层和Android runtime之间的抽象出来的一层结构。硬件抽象层可以是对硬件驱动的一个封装,为上层应用的调用提供统一接口。
内核层是硬件和软件之间的层。内核层可以包括设备驱动、文件系统驱动、绑定驱动等。
需要说明的是,本申请实施例仅以安卓系统举例来说明,在其他操作系统中(例如Windows系统,IOS系统等),只要各个功能模块实现的功能和本申请的实施例类似,也能实现本申请的方案。
可以理解的是,第一电子设备可以与云端服务器进行交互。
本申请实施例中,云端服务器可以包括日志上报统计服务、日志配额计算服务和云端推送服务等。
日志上报统计服务可以用于统计问题单的数量,统计日志的数量,以及统计性能故障打点的数量。其中,由于问题单和日志在一定程度上均可以反映电子设备的性能,因此本申请实施例中,问题单也可以称为性能问题单,日志也可以称为性能日志。此外,一些场景中,性能故障打点的数量也可以理解为触发性能故障的次数。为了便于统一描述,后续以性能问题单、性能故障打点的数量为例进行说明。
日志上报统计服务还可以用于对统计数据进行处理,例如日志上报统计服务可以将一个周期内的统计数据进行归一化处理,得到单日的统计数据等。
日志配额计算服务可以基于采集的数据进行日志资源的分配,得到各个电子设备的日志配额。例如日志配额计算服务可以计算与日志相关的敏感度数据,根据敏感度数据计算性能问题单、性能日志以及性能故障打点各自对应的权重,并基于权重计算不同电子设备的日志配额等。
云端推送服务可以用于将日志配额的相关数据推送给电子设备。
图3示出了本申请实施例提供的日志资源管理方法的流程图。
如图所示,云端服务器可以包括日志上报统计服务、日志配额计算服务和云端推送服务。具体日志上报统计服务、日志配额计算服务和云端推送服务所实现的功能可以参照上述图2对应实施例中的相关描述,不再赘述。
电子设备可以包括云化参数更新服务和流量管控服务。具体云化参数更新服务和流量管控服务所实现的功能可以参照上述图2对应实施例中的相关描述,不再赘述。
S301、日志上报统计服务统计3种数据的统计值。
日志上报统计服务可以统计出一个周期内,各个用户提供性能问题单的数量、性能日志的数量、以及性能故障打点的数量。
在用户使用电子设备的过程中,若电子设备发生卡顿等问题,或者用户使用电子设备的体验较差,用户可以通过电子设备主动向云端服务器提供性能问题单。其中,该性能问题单可以用于记录电子设备在运行过程中出现的问题,该性能问题单中可以包括下述的一种或多种信息:问题描述、与问题相关的图片、问题出现频率、问题类型或问题出现的时间等。具体性能问题单中所包括的内容,本申请实施例不作限定。
可能的实现中,电子设备接收到用于提交性能问题单的操作后,响应于该操作,电子设备可以调用上传问题单的相关接口,向云端服务器上传性能问题单。进而云端服务器可以采集到各个用户提供性能问题单的数量。
当电子设备出现卡顿时,电子设备的系统后台可以向云端服务器上报性能故障打点事件,还可以向云端服务器上报性能日志。这样,云端服务器可以采集到各个电子设备上报的性能故障打点的数量和性能日志的数量。
其中,性能故障打点事件可以用于记录电子设备中发生的卡顿等问题,性能故障打点事件可以包括下述的一种或多种信息:卡顿类型、卡顿时间、卡顿等级或发生卡顿的模块等。具体性能故障打点事件所包括的内容,本申请实施例不作限定。
性能日志可以用于记录电子设备的运行状态,性能日志可以包括下述的一种或多种信息:函数间的调用信息、进程或线程的调度信息、内核的负载信息、内核使用率、线程在内核上的运行状态、内存使用率、磁盘使用率或系统温度等。具体性能日志中所包括的内容,本申请实施例不作限定。
示例性的,电子设备的系统后台可以运行有性能检测服务,该性能检测服务可以检测到电子设备中发生卡顿问题的卡顿时间、卡顿类型和卡顿等级等。其中,该卡顿类型可以包括滑动卡顿、动效卡顿、丢帧卡顿、冷启动卡顿或热启动卡顿等。电子设备还可以根据卡顿的严重程度为卡顿划分不同的等级。具体卡顿类型和卡顿等级的划分,本申请实施例不作限定。
可以理解的是,电子设备向云端服务器上报的性能日志的数量和性能故障打点的数量不一定是相同的。当电子设备中发生的卡顿达到最低或较低的卡顿等级时,可以认为发生了性能故障,则电子设备可以向云端服务器上报性能故障打点事件。当电子设备发生较为明显卡顿,达到一定的卡顿等级或满足一定的卡顿类型时,电子设备可以向云端服务器上报性能日志。
也可以理解为,并不是每一次触发性能故障打点事件时,电子设备都会采集性能日志,并向云端服务器上报性能日志。而是在卡顿达到一定的卡顿等级或满足一定的卡顿类型时,才会上报性能日志。本申请实施例中,采集的性能故障的次数可以理解为宏观上对电子设备的性能卡顿状态的统计,而采集性能日志则需要电子设备发生的卡顿达到一定的卡顿等级或满足一定的卡顿类型。因此,采集性能日志的数量可以小于或等于性能故障打点的数量。
可能的实现中,上述一个周期的时长可以由云端服务器根据经验预先设置。示例性的,一个周期可以采用固定的预设时长,例如一个周期可以为3天、5天或7天等;或者,一个周期还可以包括电子设备的系统版本的更新周期,其中,不同的系统版本可以对应有不同的更新周期,因此一个周期时长也可以是不固定的。具体一个周期的时长,本申请实施例不作限定。
日志上报统计服务还可以对一个周期内的统计数据做归一化处理,得到归一化的统计数据。例如日志上报统计服务可以将一个周期内的统计数据换算为单日的统计结果。
示例性的,假设一个周期为7天,日志上报统计服务在统计到一个周期内的性能问题单的数量、性能日志的数量、以及性能故障打点的数量等数据后,可以将各个数据分别除以7,从而得到单日的统计数据。这样,通过对各个数据进行归一化处理,可以较为准确的评估电子设备在一段时间内的性能卡顿状态,使得日志资源的分配更为合理。
S302、日志配额计算服务计算性能敏感度排序。
日志配额计算服务可以基于日志上报统计服务得到的归一化统计数据,计算出各个电子设备的性能敏感度。
其中,电子设备的性能敏感度可以分别与性能问题单的数量、性能日志的数量以及性能故障打点的数量成正相关。例如,当性能日志的数量和性能故障打点的数量一定时,性能问题单的数量越多,该电子设备的性能敏感度越高;当性能问题单的数量和性能故障打点的数量一定时,性能日志的数量越多,该电子设备的性能敏感度越高;当性能问题单的数量和性能日志的数量一定时,性能故障打点的数量越多,该电子设备的性能敏感度越高。
也可以理解为,电子设备的性能敏感度可以与性能问题单的数量、性能日志的数量以及性能故障打点的数量的加权总和成正相关。
可能的实现中,图4示出了计算日志配额的示意图,如图所示,性能问题单的数量、性能日志的数量和性能故障打点的数量可以分别对应有各自的权重。例如,性能问题单的数量可以对应为权重A,性能日志的数量可以对应为权重B,性能故障打点的数量可以对应为权重C。
其中,权重A、权重B和权重C可以由云端服务器根据经验预先设置。权重A、权重B和权重C三者的取值可以相同或不同,具体权重A、权重B和权重C的取值,本申请实施例不作限定。
可以理解的是,为了更好的提升用户体验,开发人员可能更多的关注卡顿较为明显的问题,而当电子设备发生较为明显的卡顿或卡顿达到一定的等级时,会上报性能日志。因此,云端服务器可以为性能日志的数量设置相对更大的权重,这样可以优先考虑和解决卡顿较为明显的问题,从而提升用户体验。例如,权重A可以为0.3,权重B可以为0.4,权重C可以为0.3。后续权重A、权重B和权重C的取值还可以进行修改,做进一步优化。
在确定了权重A、权重B和权重C的取值后,日志配额计算服务可以基于权重计算各个电子设备的性能敏感度。
示例性的,第i个电子设备的性能敏感度可以满足下述公式:
。
其中,Param1可以为归一化处理后的性能问题单的数量,Param2可以为归一化处理后的性能日志的数量,Param3可以为归一化处理后的性能故障打点的数量。
日志配额计算服务还可以对各个电子设备的性能敏感度进行排序。对于性能敏感度较高的电子设备,日志配额计算服务可以设置较大的日志权重,从而可以分配较多的上传日志的资源。对于性能敏感度较低的电子设备,日志配额计算服务可以设置较小的日志权重,从而可以分配较少的上传日志的资源。这样,云端服务器可以采集到较多有用的性能日志,从而方便开发人员基于性能日志定位和解决问题。
可能的实现中,在对N个电子设备进行性能敏感度排序之后,日志配额计算服务可以将N个电子设备划分为M个组。其中,N和M均可以为大于或等于1的正整数。在对电子设备进行分组之后,日志配额计算服务还可以基于分组确定出各个电子设备所对应的性能敏感度权重。
例如,假设N为100,M为5,以性能敏感度按照升序排序为例,在对100个电子设备进行性能敏感度排序之后,日志配额计算服务可以将100个电子设备划分为5个组,每个组有20个电子设备。其中,第一组中可以包括性能敏感度排名从第1名到第20名的电子设备,第二组中可以包括性能敏感度排名从第21名到第40名的电子设备,第三组中可以包括性能敏感度排名从第41名到第60名的电子设备,第四组中可以包括性能敏感度排名从第61名到第80名的电子设备,第五组中可以包括性能敏感度排名从第81名到第100名的电子设备。
其中,第一组对应的性能敏感度权重大于第二组对应的性能敏感度权重,第二组对应的性能敏感度权重大于第三组对应的性能敏感度权重,第三组对应的性能敏感度权重大于第四组对应的性能敏感度权重,第四组对应的性能敏感度权重大于第五组对应的性能敏感度权重。这样可以使得电子设备的性能敏感度与权重成正相关,对于性能敏感度较高的电子设备,可以分配到更多的日志上传的资源,有利于问题的定位与分析。
可以理解的是,若性能敏感度按照降序排序,则第一组对应的性能敏感度权重小于第二组对应的性能敏感度权重,第二组对应的性能敏感度权重小于第三组对应的性能敏感度权重,第三组对应的性能敏感度权重小于第四组对应的性能敏感度权重,第四组对应的性能敏感度权重小于第五组对应的性能敏感度权重,使得电子设备的性能敏感度与权重成正相关。这样,也可以满足对于性能敏感度较高的电子设备,可以分配到更多的日志上传的资源。
S303、日志配额计算服务获取上一周期日志配额权重。
在确定出各个电子设备所对应的性能敏感度权重后,日志配额计算服务可以计算各个电子设备的日志权重。
一种可能的实现中,第i个电子设备的日志权重wi可以等于该电子设备所对应的性能敏感度权重。
另一种可能的实现中,如图4所示,日志配额计算服务还可以获取第i个电子设备上一周期的日志权重,并基于性能敏感度权重和上一周期的日志权重,计算第i个电子设备当前一个周期的日志权重。
可以理解的是,由于用户在使用电子设备的过程中,用户的习惯可能不会有较大的改变,因此,在计算当前一个周期内电子设备的日志权重时,可以结合考虑上一周期该电子设备的日志权重,这样可以将上一周期的日志权重作为经验值进行参考,从而得到更加准确合理的日志权重。
示例性的,第i个电子设备当前一个周期的日志权重wi可以满足下述公式:
。
其中,为上一周期第i个电子设备的日志权重,D为上一周期第i个电子设备的日志权重在当前一个周期内第i个电子设备的日志权重中所占的权重。权重D可以由云端服务器根据经验预先设置,例如,权重D可以包括0.5,后续权重D的取值还可以进行修改,做进一步优化,具体权重D的取值,本申请实施例不作限定。
可选的,日志配额计算服务也可以为第i个电子设备所对应的性能敏感度权重设置对应的权重,该权重的具体取值,可以由云端服务器根据经验设置,本申请实施例不作限定。
S304、日志配额计算服务计算电子设备的日志配额。
一种可能的实现中,日志配额计算服务可以为每个电子设备分配相同或不同的可调整日志配额L adjust 。具体每个电子设备得到的可调整日志配额,本申请实施例不作限定。
示例性的,第i个电子设备分配得到的日志配额Li可以满足下述公式:
。
由上述公式可知,日志配额计算服务可以对每个电子设备的可调整日志配额进行求和,得到总的可调整日志配额。该总的可调整日志配额可以理解为公共资源池,每个电子设备可以基于日志权重的大小从该公共资源池中获取更多或更少的日志配额。
另一种可能的实现中,如图4所示,日志配额计算服务可以为每个电子设备分配日志配额L,该日志配额L可以包括基础日志配额L basic 和可调整日志配额L adjust 。
其中,每个电子设备可以对应有一定的基础日志配额L basic 。示例性的,假设日志配额计算服务为每个电子设备每天分配12份日志配额,其中,基础日志配额可以为4份,可调整日志配额可以为8份。这样,为每个电子设备分配一定的基础日志配额,使得性能敏感度较低的电子设备也可以得到一定的日志配额。若性能敏感度较低的电子设备出现故障,开发人员依然可以通过日志信息对该电子设备进行问题定位和分析。
可以理解的是,日志配额计算服务可以为每个电子设备分配相同或不同的日志配额、分配相同或不同的基础日志配额,以及分配相同或不同的可调整日志配额,具体每个电子设备得到的日志配额、基础日志配额和可调整日志配额,本申请实施例不作限定。
可能的实现中,第i个电子设备分配得到的日志配额Li可以满足下述公式:
。
由上述公式可知,日志配额计算服务可以对每个电子设备的可调整日志配额进行求和,得到总的可调整日志配额。该总的可调整日志配额可以理解为公共资源池,每个电子设备可以基于性能敏感度的高低从该公共资源池中获取更多或更少的日志配额。
例如,对于性能敏感度较高的电子设备,可以得到较多的日志配额,对于性能敏感度较低的电子设备,可以得到较少的日志配额。这样,在云端服务器为电子设备分配日志资源总量不变,且不增加云端服务器压力的前提下,可以基于日志权重的不同对日志上传的资源进行合理的调整和分配,从而提升日志采集的效率。
可选的,日志配额计算服务还可以对上述公式做任意可能的变形,例如可以为基础日志配额L basic 和可调整日志配额L adjust 设置各自对应的权重,其中,该基础日志配额L basic 的权重和可调整日志配额L adjust 的权重的具体取值,可以由云端服务器根据经验设置,本申请实施例不作限定。
S305、日志配额计算服务执行配置推送服务。
在计算得到各个电子设备的日志配额后,日志配额计算服务可以执行配置推送服务,指示云端推送服务给电子设备推送日志配额等相关信息。
S306、日志上报统计服务记录本次日志配额权重。
日志上报统计服务还可以在云端服务器中记录各个电子设备的日志配额的权重,例如日志上报统计服务可以在数据库中保存各个电子设备的日志配额的权重。这样,在日志配额计算服务计算下一周期的日志配额时,可以从云端服务器中获取前一次记录的日志配额,作为计算下一周期的日志配额的参考数据。
可以理解的是,步骤S305与步骤S306的执行可以不区分先后顺序。也就是说,云端服务器可以先执行步骤S305,再执行步骤S306;或者,云端服务器可以先执行步骤S306,再执行步骤S305;或者,云端服务器可以同时执行步骤S303和步骤S306,本申请实施例不作限定。
S307、云端推送服务推送给电子设备。
云端推送服务获取到日志配额计算服务的指示消息后,云端推送服务可以将日志配额等相关信息推送给各个电子设备。
可能的实现中,日志配额计算服务可以根据电子设备划分的组,将属于同一组的电子设备对应的日志配额配置到一个配置文件中。云端推送服务可以根据电子设备所属分组的不同推送不同的配置文件。
可选的,日志配额计算服务也可以不在配置文件中配置日志配额,而是云端推送服务向各个电子设备传递日志配额标识,该日志配额标识可以用于表示电子设备对应的日志配额。
云端推送服务可以采用任意可能的方式向各个电子设备推送日志配额,具体向电子设备传递日志配额的实现方式,本申请实施例不作限定。
S308、配置文件生效。
云化参数更新服务可以从云端服务器获取与日志配额相关的数据包,并对数据包进行解压,从而得到日志配额等的相关信息。
流量管控服务可以基于配置文件中的日志配额控制电子设备向云端服务器上传日志的数量,使配置文件生效。这样,对于性能敏感度较高的电子设备,可以得到较多的上传日志的资源,方便开发人员进行问题定位和分析。对于性能敏感度较低的电子设备,可以得到较少的上传日志的资源,从而合理的分配上传日志的资源。
下面通过具体的实施例对本申请实施例的方法进行详细说明。下面的实施例可以相互结合或独立实施,对于相同或相似的概念或过程可能在某些实施例中不再赘述。
图5示出了本申请实施例的日志资源管理方法。方法应用于第一电子设备,方法包括:
S501、接收来自N个电子设备的日志数据,N个电子设备包括第二电子设备和第三电子设备,N为大于1的整数。
本申请实施例中,第一电子设备可以包括算力较强和/或存储能力较强的电子设备,例如第一电子设备可以包括云端服务器等。本申请实施例对具体的第一电子设备不作限定。
第二电子设备和第三电子设备可以包括用户频繁操作的电子设备,例如第二电子设备可以包括手机、平板或手表等电子设备。本申请实施例对具体的第二电子设备和第三电子设备不作限定。
日志数据中可以包括用于开发人员定位问题的信息,例如日志数据可以包括上述图3对应实施例中的性能问题单、性能日志以及性能故障打点等信息。具体日志数据可以包括更多或更少的内容,本申请实施例不作限定。
接收来自N个电子设备的日志数据可以包括电子设备向上报第一电子设备日志数据,也可以包括第一电子设备通过调用接口等方式从电子设备中获取日志数据,具体接收日志数据的方式,本申请实施例不作限定。
S502、确定第一值,以及第二值,第一值用于指示第二电子设备向第一电子设备上传日志数量的最大值,第一值与第二电子设备向第一电子设备上传日志数据的频率正相关,第二值用于指示第三电子设备向第一电子设备上传日志数量的最大值,第二值与第三电子设备向第一电子设备上传日志数据的频率正相关,第一值与第二值不同。
本申请实施例中,第一值可以理解为第二电子设备的日志配额或上传日志的资源,第二值可以理解为第三电子设备的日志配额或上传日志的资源。日志配额可以包括上传日志的数量,也可以包括上传日志的流量等。具有日志配额的计算方式可以参照上述图3对应实施例中步骤S304中的相关描述,不再赘述。
上传日志数据的频率可以理解为上传日志数据的数量。上传的日志数据的数量越多,说明上传日志数据的频率越高。而第二电子设备上传日志数据的频率越高,第一值越大,也可以理解为第二电子设备上传日志数据的数量越多。第三电子设备上传日志数据的频率越高,第二值越大,也可以理解为第三电子设备上传日志数据的数量越多。
S503、向第二电子设备发送第一值。
本申请实施例中,第一电子设备在计算出第一值后,可以向第二电子设备发送第一值。具体向第二电子设备发送第一值的过程可以参照上述图3对应实施例中步骤S307中的相关描述,不再赘述。
S504、向第三电子设备发送第二值。
本申请实施例中,第一电子设备在计算出第二值后,可以向第三电子设备发送第二值。类似地,具体向第二电子设备发送第一值的过程可以参照上述图3对应实施例中步骤S307中的相关描述,不再赘述。
本申请实施例提供的日志资源管理方法,可以考虑问题单的数量、性能日志的数量以及性能故障打点的数量,并将其作为分配上传日志资源的因素。示例性的,对于问题单数量较多、性能日志数量较多和/或性能故障打点数量较多的电子设备,可以分配较多的上传日志的资源;对于问题单数量较少、性能日志数量较少和/或性能故障打点数量较少的电子设备,可以分配较少的上传日志的资源。这样,对于频繁发生性能卡顿问题的电子设备,可以上传更多的日志信息,方便开发人员进行问题定位和分析。对于较少发生性能卡顿问题的电子设备,可以上传较少的日志信息,从而合理的分配上传日志的资源。
可选的,在图5对应的实施例的基础上,接收来自N个电子设备的日志数据之后,还可以包括:确定第一权重,第一权重与第二电子设备向第一电子设备上传日志数据的频率在N个电子设备向第一电子设备上传日志数据的频率中的排名正相关;确定第一值,可以包括:基于第一权重确定第一值,第一权重和第一值正相关。
本申请实施例中,第一权重可以用于衡量电子设备获得日志配额的情况。第一权重可以包括上述图3对应实施例中的日志权重wi,具体日志权重wi的计算方法可以参照图3对应实施例中的步骤S303中的相关描述,不再赘述。
基于第一权重确定第一值可以参照图3对应实施例中的步骤S304中的相关描述,不再赘述。
当第一权重较大时,电子设备可以分配到较多的日志配额,有利于问题的定位与分析;当第一权重较小时,电子设备可以分配到较少的日志配额。这样,云端服务器可以采集到较多有用的性能日志,从而方便开发人员基于性能日志定位和解决问题。
可选的,在图5对应的实施例的基础上,第一权重与第一值满足下述公式:
。
其中,wi为第一权重,Li为第一值,L adjust 为第一电子设备为第i个电子设备预设的上传日志的数量,i为大于或等于1的整数,i小于或等于N。
本申请实施例中,第一值的计算方式可以参照图3对应实施例中的步骤S304中的相关描述,不再赘述。
第一电子设备可以对各个电子设备的可调整日志配额进行求和,得到总的可调整日志配额。该总的可调整日志配额可以理解为公共资源池,这样,每个电子设备可以基于日志权重的大小从该公共资源池中获取更多或更少的日志配额。
可选的,在图5对应的实施例的基础上,第一权重与第一值满足下述公式:
。
其中,wi为第一权重,Li为第一值,L adjust 为第一电子设备为第i个电子设备设置的可调整日志的数量,L basic 为第一电子设备为第i个电子设备设置的上传日志数量的最小值,i为大于或等于1的整数,i小于或等于N。
本申请实施例中,第一值的计算方式可以参照图3对应实施例中的步骤S304中的相关描述,不再赘述。
第一电子设备可以为每个电子设备分配基础日志配额和可调整日志配额。基础日志配额使得各个电子设备均可以得到一定的日志配额。对于上传日志频率较少的电子设备,当该电子设备出现故障时,开发人员依然可以通过日志信息对该电子设备进行问题定位和分析。这样,在云端服务器为电子设备分配日志资源总量不变,且不增加云端服务器压力的前提下,可以基于日志权重的不同对日志上传的资源进行合理的调整和分配,从而提升日志采集的效率。
可选的,在图5对应的实施例的基础上,向第二电子设备发送第一值,可以包括:在第L周期内,向第二电子设备发送第一值,L为大于或等于1的整数;向第二电子设备发送第一值之后,还可以包括:在第L+1周期内,接收来自第二电子设备的日志数据;确定第三值,第三值用于指示第二电子设备向第一电子设备上传日志数量的最大值,第三值与第二电子设备向第一电子设备上传日志数据的频率正相关;向第二电子设备发送第三值。
本申请实施例中,第三值可以理解为在第L+1周期内,第二电子设备的日志配额或上传日志的资源。第一电子设备在计算出第三值后,可以向第二电子设备发送第三值。具体向第二电子设备发送第三值的过程可以参照上述图3对应实施例中步骤S307中的相关描述,不再赘述。
可以理解的是,第一值和第三值可以相同,也可以不同。也可以理解为,同一电子设备,在不同的周期内,所得到的日志配额可以相同或不同,本申请实施例不作限定。这样,可以根据第二电子设备在不同周期内上传日志数量的不同,灵活调整第二电子设备的日志配额,从而合理的利用第一电子设备的内存资源。
可选的,在图5对应的实施例的基础上,确定第三值之前,还可以包括:确定第三权重,第三权重与下述的一项或多项成正相关:第二电子设备向第一电子设备上传日志数据的频率在N个电子设备向第一电子设备上传日志数据的频率中的排名、第一权重;确定第三值,可以包括:基于第三权重确定第三值,第三权重和第三值正相关。
本申请实施例中,第三权重可以用于衡量电子设备获得日志配额的情况。第三权重可以包括上述图3对应实施例中的日志权重wi,具体日志权重wi的计算方法可以参照图3对应实施例中的步骤S303中的相关描述,不再赘述。
由于用户在使用电子设备的过程中,用户的习惯可能不会有较大的改变,因此,在计算第三权重时,可以结合考虑上一周期的第一权重,这样可以将上一周期的日志权重作为经验值进行参考,从而得到更加准确合理的日志权重。
可选的,在图5对应的实施例的基础上,第三权重满足下述公式:
。
其中,wi为第三权重,为基于第二电子设备向第一电子设备上传日志数据的频率在N个电子设备向第一电子设备上传日志数据的频率中的排名得到的权重,/>为第一权重,D为第一权重在第L+1周期中所占的权重。
本申请实施例中,第三权重的计算方法可以参照上述图3对应实施例中的步骤S303中的相关描述,不再赘述。
在计算第三权重时,可以结合考虑上一周期的第一权重,这样可以考虑用户之前的习惯,得到更加准确合理的日志权重。
可选的,在图5对应的实施例的基础上,日志数据可以包括下述的一项或多项:问题单信息、性能日志信息或故障打点信息;其中,问题单信息用于记录电子设备中出现的问题,问题单信息可以包括下述的一种或多种信息:问题描述、与问题相关的图片、问题出现频率或问题类型;性能日志信息用于记录电子设备的运行状态,性能日志信息可以包括下述的一种或多种信息:函数间的调用信息、进程或线程的调度信息、内核的负载信息、内核的使用率或线程在内核上的运行状态;故障打点信息用于记录电子设备中发生的卡顿,故障打点信息可以包括下述的一种或多种信息:卡顿类型、卡段时间或卡顿等级。
本申请实施例中,日志数据的具体描述可以参照上述图3对应实施例中的步骤S301中的相关描述,不再赘述。
这样,第一电子设备可以基于各个电子设备上传的日志数据,统计问题单的数量、性能日志的数量以及故障打点的数量,从而计算各个电子设备的日志配额,使得日志资源的分配更为合理。
可选的,在图5对应的实施例的基础上,第一电子设备包括第一服务、第二服务和第三服务,接收来自N个电子设备的日志数据之后,还可以包括:第一服务基于第二电子设备的日志数据统计第四值、第五值、第六值,第四值包括问题单的数量,第五值包括日志的数量,第六值包括故障打点的数量;确定第一值之前,还可以包括:第二服务确定第二电子设备在N个电子设备中的排名,排名与下述的一项或多项成正相关:第四值、第五值或第六值;第二服务确定第一权重;确定第一值,可以包括:第二服务基于第一权重确定第一值,第一权重和第一值正相关;向第二电子设备发送第一值,可以包括:第三服务向第二电子设备发送第一值。
本申请实施例中,第一服务可以理解为用于统计问题单的数量、统计性能日志的数量以及统计故障打点的数量的服务,第一服务还可以理解为对统计数据进行归一化等处理的服务。例如,第一服务可以包括上述图3对应实施例中的日志上报统计服务。
第二服务可以理解为基于第一服务采集的数据进行日志资源的分配,得到各个电子设备的日志配额的服务。例如,第二服务可以包括上述图3对应实施例中的日志配额计算服务。
第三服务可以理解为用于将日志配额的相关数据推送给各个电子设备的服务。例如第三服务可以包括上述图3对应实施例中的云端推送服务。
第一服务基于第二电子设备的日志数据统计第四值、第五值、第六值可以参照上述图3对应实施例的步骤S301中的相关描述,不再赘述。
第二电子设备在N个电子设备中的排名可以包括通过性能敏感度排序得到的排名,具体第二服务确定第二电子设备在N个电子设备中的排名可以参照上述图3对应实施例的步骤S302中的相关描述,不再赘述。
第二服务基于第一权重确定第一值可以参照上述图3对应实施例的步骤S304中的相关描述,不再赘述。
第三服务向第二电子设备发送第一值可以参照上述图3对应实施例的步骤S307中的相关描述,不再赘述。
本申请实施例中,对于性能敏感度较高的电子设备,日志配额计算服务可以设置较大的日志权重,从而可以分配较多的上传日志的资源。对于性能敏感度较低的电子设备,日志配额计算服务可以设置较小的日志权重,从而可以分配较少的上传日志的资源。这样,云端服务器可以采集到较多有用的性能日志,从而方便开发人员基于性能日志定位和解决问题。
可选的,在图5对应的实施例的基础上,第一服务保存有上一周期的权重值,第二服务确定第一权重之前,还可以包括:第二服务从第一服务中获取上一周期的权重值;第二服务确定第一权重,可以包括:第二服务基于排名和上一周期的权重值确定第一权重。
本申请实施例中,第二服务从第一服务中获取上一周期的权重值可以参照上述图3对应实施例的步骤S303中的相关描述,不再赘述。
第一服务可以记录各个电子设备的日志配额的权重,在第二服务计算下一周期的日志配额时,可以从第一服务获取前一次记录的日志配额的权重,作为计算下一周期的日志配额的参考数据。这样,可以将上一周期的日志权重作为经验值进行参考,从而得到更加准确合理的日志权重。
可选的,在图5对应的实施例的基础上,第二电子设备包括第四服务和第五服务,第四服务,用于接收来自第一电子设备的第一值,并向第五服务传递第一值;第五服务,用于基于第一值确定是否允许第二电子设备向第一电子设备上传日志,若第二电子设备向第一电子设备上传日志的数量小于第一值,则允许第二电子设备向第一电子设备上传日志;或者,若第二电子设备向第一电子设备上传日志的数量等于第一值,则不允许第二电子设备向第一电子设备上传日志。
本申请实施例中,第四服务可以理解为用于用于接收来自第一电子设备的第一值,并向第五服务传递第一值的服务。第四服务还可以用于和云端服务器进行交互,并获取数据包的服务,第四服务可以用于对数据包进行解压,从而得到日志配额等相关信息的服务。例如第四服务可以包括上述图3对应实施例中的云化参数更新服务。
第五服务可以理解为用于基于第一值确定是否允许第二电子设备向第一电子设备上传日志的服务。例如第五服务可以包括上述图3对应实施例中的流量管控服务。
具体第四服务和第五服务的执行过程可以参照上述图3对应实施例的步骤S308中的相关描述,不再赘述。
对于上传日志较多的电子设备,可以得到较多的上传日志的资源,方便开发人员进行问题定位和分析。对于上传日志较少的电子设备,可以得到较少的上传日志的资源,这样,可以合理的分配上传日志的资源,方便开发人员对问题的定位与分析。
需要说明的是,本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等),均为经用户授权或者经过各方充分授权的信息和数据,并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准,并提供有相应的操作入口,供用户选择授权或者拒绝。
可以理解的是,本申请实施例中,可以在电子设备的测试阶段进行日志的采集。对于已经发布的电子设备,可以不采集用户的日志,这样可以更好的保护用户的信息。当然,对于已经发布的电子设备,若用户同意电子设备采集日志,让开发人员进行问题定位和分析,也可以采集日志,本申请实施例不作限定。
上述主要从方法的角度对本申请实施例提供的方案进行了介绍。为了实现上述功能,其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到,结合本文中所公开的实施例描述的各示例的方法步骤,本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
本申请实施例可以根据上述方法示例对实现该方法的装置进行功能模块的划分,例如可以对应各个功能划分各个功能模块,也可以将两个或两个以上的功能集成在一个处理模块中。集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。需要说明的是,本申请实施例中对模块的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
如图6示为本申请实施例提供的一种芯片的结构示意图。芯片600包括一个或两个以上(包括两个)处理器601、通信线路602、通信接口603和存储器604。
在一些实施方式中,存储器604存储了如下的元素:可执行模块或者数据结构,或者他们的子集,或者他们的扩展集。
上述本申请实施例描述的方法可以应用于处理器601中,或者由处理器601实现。处理器601可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器601中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器601可以是通用处理器(例如,微处理器或常规处理器)、数字信号处理器(digitalsignal processing,DSP)、专用集成电路(application specific integrated circuit,ASIC)、现成可编程门阵列(field-programmablegate array,FPGA)或者其他可编程逻辑器件、分立门、晶体管逻辑器件或分立硬件组件,处理器601可以实现或者执行本申请实施例中的公开的各处理相关的方法、步骤及逻辑框图。
结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。其中,软件模块可以位于随机存储器、只读存储器、可编程只读存储器或带电可擦写可编程存储器(electricallyerasable programmable read only memory,EEPROM)等本领域成熟的存储介质中。该存储介质位于存储器604,处理器601读取存储器604中的信息,结合其硬件完成上述方法的步骤。
处理器601、存储器604以及通信接口603之间可以通过通信线路602进行通信。
在上述实施例中,存储器存储的供处理器执行的指令可以采用计算机程序产品的形式实现。其中,计算机程序产品可以是事先写入在存储器中,也可以是以软件形式下载并安装在存储器中。
本申请实施例还提供一种计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时,全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一计算机可读存储介质传输,例如,计算机指令可以从一个网站的站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line,DSL)或无线(例如红外、无线、微波等)方式向另一个网站的站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包括一个或多个可用介质集成的服务器、数据中心等数据存储设备。例如,可用介质可以包括磁性介质(例如,软盘、硬盘或磁带)、光介质(例如,数字通用光盘(digital versatile disc,DVD))、或者半导体介质(例如,固态硬盘(solid state disk,SSD))等。
本申请实施例还提供一种计算机可读存储介质。上述实施例中描述的方法可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。计算机可读介质可以包括计算机存储介质和通信介质,还可以包括任何可以将计算机程序从一个地方传送到另一个地方的介质。存储介质可以是可由计算机访问的任何目标介质。
作为一种可能的设计,计算机可读介质可以包括紧凑型光盘只读储存器(compactdisc read-only memory,CD-ROM)、RAM、ROM、EEPROM或其它光盘存储器;计算机可读介质可以包括磁盘存储器或其它磁盘存储设备。而且,任何连接线也可以被适当地称为计算机可读介质。例如,如果使用同轴电缆,光纤电缆,双绞线,DSL或无线技术(如红外,无线电和微波)从网站,服务器或其它远程源传输软件,则同轴电缆,光纤电缆,双绞线,DSL或诸如红外,无线电和微波之类的无线技术包括在介质的定义中。如本文所使用的磁盘和光盘包括光盘(CD),激光盘,光盘,数字通用光盘(digital versatile disc,DVD),软盘和蓝光盘,其中磁盘通常以磁性方式再现数据,而光盘利用激光光学地再现数据。
本申请实施例是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理单元以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理单元执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
Claims (16)
1.一种日志资源管理方法,其特征在于,所述方法应用于第一电子设备,所述方法包括:
接收来自N个电子设备的日志数据,所述N个电子设备包括第二电子设备和第三电子设备,N为大于1的整数;
确定第一值,以及第二值,其中,所述第一值用于指示所述第二电子设备向所述第一电子设备上传日志数量的最大值,所述第一值与所述第二电子设备向所述第一电子设备上传日志数据的频率正相关,所述第二值用于指示所述第三电子设备向所述第一电子设备上传日志数量的最大值,所述第二值与所述第三电子设备向所述第一电子设备上传日志数据的频率正相关,所述第一值与所述第二值不同;
向所述第二电子设备发送所述第一值;
向所述第三电子设备发送所述第二值。
2.根据权利要求1所述的方法,其特征在于,所述接收来自N个电子设备的日志数据之后,还包括:
确定第一权重,所述第一权重与所述第二电子设备向所述第一电子设备上传日志数据的频率在所述N个电子设备向所述第一电子设备上传日志数据的频率中的排名正相关;
所述确定第一值,包括:
基于所述第一权重确定所述第一值,所述第一权重和所述第一值正相关。
3.根据权利要求2所述的方法,其特征在于,所述第一权重与所述第一值满足下述公式:
;
其中,wi为所述第一权重,Li为所述第一值,L adjust 为所述第一电子设备为第i个电子设备预设的上传日志的数量,i为大于或等于1的整数,i小于或等于N。
4.根据权利要求2所述的方法,其特征在于,所述第一权重与所述第一值满足下述公式:
;
其中,wi为所述第一权重,Li为所述第一值,L adjust 为所述第一电子设备为第i个电子设备设置的可调整日志的数量,L basic 为所述第一电子设备为第i个电子设备设置的上传日志数量的最小值,i为大于或等于1的整数,i小于或等于N。
5.根据权利要求2-4任一项所述的方法,其特征在于,向所述第二电子设备发送所述第一值,包括:
在第L周期内,向所述第二电子设备发送所述第一值,L为大于或等于1的整数;
向所述第二电子设备发送所述第一值之后,还包括:
在第L+1周期内,接收来自所述第二电子设备的日志数据;
确定第三值,所述第三值用于指示所述第二电子设备向所述第一电子设备上传日志数量的最大值,所述第三值与所述第二电子设备向所述第一电子设备上传日志数据的频率正相关;
向所述第二电子设备发送所述第三值。
6.根据权利要求5所述的方法,其特征在于,所述确定第三值之前,还包括:
确定第三权重,所述第三权重与下述的一项或多项成正相关:所述第二电子设备向所述第一电子设备上传日志数据的频率在所述N个电子设备向所述第一电子设备上传日志数据的频率中的排名、所述第一权重;
所述确定第三值,包括:
基于所述第三权重确定所述第三值,所述第三权重和所述第三值正相关。
7.根据权利要求6所述的方法,其特征在于,所述第三权重满足下述公式:
;
其中,wi为所述第三权重,为基于所述第二电子设备向所述第一电子设备上传日志数据的频率在所述N个电子设备向所述第一电子设备上传日志数据的频率中的排名得到的权重,/>为所述第一权重,D为所述第一权重在所述第L+1周期中所占的权重。
8.根据权利要求1-4任一项所述的方法,其特征在于,所述日志数据包括下述的一项或多项:问题单信息、性能日志信息或故障打点信息;
其中,所述问题单信息用于记录电子设备中出现的问题,所述问题单信息包括下述的一种或多种信息:问题描述、与问题相关的图片、问题出现频率或问题类型;
所述性能日志信息用于记录电子设备的运行状态,所述性能日志信息包括下述的一种或多种信息:函数间的调用信息、进程或线程的调度信息、内核的负载信息、内核的使用率或线程在内核上的运行状态;
所述故障打点信息用于记录电子设备中发生的卡顿,所述故障打点信息包括下述的一种或多种信息:卡顿类型、卡顿时间或卡顿等级。
9.根据权利要求2-4任一项所述的方法,其特征在于,所述第一电子设备包括第一服务、第二服务和第三服务,所述接收来自N个电子设备的日志数据之后,还包括:
所述第一服务基于所述第二电子设备的日志数据统计第四值、第五值、第六值,所述第四值包括问题单的数量,所述第五值包括日志的数量,所述第六值包括故障打点的数量;
所述确定第一值之前,还包括:
所述第二服务确定所述第二电子设备在所述N个电子设备中的排名,所述排名与下述的一项或多项成正相关:所述第四值、所述第五值或所述第六值;
所述第二服务确定所述第一权重;
所述确定第一值,包括:
所述第二服务基于所述第一权重确定所述第一值,所述第一权重和所述第一值正相关;
向所述第二电子设备发送所述第一值,包括:
所述第三服务向所述第二电子设备发送所述第一值。
10.根据权利要求9所述的方法,其特征在于,所述第一服务保存有上一周期的权重值,所述第二服务确定所述第一权重之前,还包括:
所述第二服务从所述第一服务中获取所述上一周期的权重值;
所述第二服务确定所述第一权重,包括:
所述第二服务基于所述排名和所述上一周期的权重值确定所述第一权重。
11.根据权利要求1-4任一项所述的方法,其特征在于,所述第二电子设备包括第四服务和第五服务,
所述第四服务,用于接收来自所述第一电子设备的所述第一值,并向所述第五服务传递所述第一值;
所述第五服务,用于基于所述第一值确定是否允许所述第二电子设备向所述第一电子设备上传日志,若所述第二电子设备向所述第一电子设备上传日志的数量小于所述第一值,则允许所述第二电子设备向所述第一电子设备上传日志;或者,若所述第二电子设备向所述第一电子设备上传日志的数量等于所述第一值,则不允许所述第二电子设备向所述第一电子设备上传日志。
12.一种电子设备,其特征在于,所述电子设备包括:一个或多个处理器和存储器;
所述存储器与所述一个或多个处理器耦合,所述存储器用于存储计算机程序代码,所述计算机程序代码包括计算机指令,所述一个或多个处理器调用所述计算机指令以使得所述电子设备执行如权利要求1-11任一项所述的方法。
13.一种系统,其特征在于,所述系统包括:第一电子设备和第二电子设备,所述第一电子设备用于执行如权利要求1-11任一项所述的方法;
所述第二电子设备用于向所述第一电子设备上传日志数据,所述第二电子设备还用于接收来自所述第一电子设备的第一值,所述第二电子设备还用于基于所述第一值确定是否允许所述第二电子设备向所述第一电子设备上传日志。
14.一种芯片系统,其特征在于,所述芯片系统应用于电子设备,所述芯片系统包括一个或多个处理器,所述一个或多个处理器用于调用计算机指令以使得所述电子设备执行如权利要求1-11中任一项所述的方法。
15.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质包括计算机指令,当所述计算机指令在电子设备上运行时,使得所述电子设备执行如权利要求1-11中任一项所述的方法。
16.一种计算机程序产品,其特征在于,所述计算机程序产品包括计算机程序代码,当所述计算机程序代码在电子设备上运行时,使得所述电子设备执行如权利要求1-11中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202410172798.1A CN117724937A (zh) | 2024-02-07 | 2024-02-07 | 日志资源管理方法及相关装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202410172798.1A CN117724937A (zh) | 2024-02-07 | 2024-02-07 | 日志资源管理方法及相关装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN117724937A true CN117724937A (zh) | 2024-03-19 |
Family
ID=90202039
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202410172798.1A Pending CN117724937A (zh) | 2024-02-07 | 2024-02-07 | 日志资源管理方法及相关装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN117724937A (zh) |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110457195A (zh) * | 2019-08-05 | 2019-11-15 | 深圳乐信软件技术有限公司 | 客户端本地日志的获取方法、装置、服务器及存储介质 |
CN114077529A (zh) * | 2022-01-19 | 2022-02-22 | 荣耀终端有限公司 | 日志上传方法、装置、电子设备及计算机可读存储介质 |
CN116541238A (zh) * | 2023-04-28 | 2023-08-04 | 苏州浪潮智能科技有限公司 | 日志文件采集方法、装置、电子设备及可读存储介质 |
CN116909862A (zh) * | 2023-07-14 | 2023-10-20 | Oppo广东移动通信有限公司 | 异常日志的收集方法及装置、电子设备、存储介质 |
-
2024
- 2024-02-07 CN CN202410172798.1A patent/CN117724937A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110457195A (zh) * | 2019-08-05 | 2019-11-15 | 深圳乐信软件技术有限公司 | 客户端本地日志的获取方法、装置、服务器及存储介质 |
CN114077529A (zh) * | 2022-01-19 | 2022-02-22 | 荣耀终端有限公司 | 日志上传方法、装置、电子设备及计算机可读存储介质 |
CN116541238A (zh) * | 2023-04-28 | 2023-08-04 | 苏州浪潮智能科技有限公司 | 日志文件采集方法、装置、电子设备及可读存储介质 |
CN116909862A (zh) * | 2023-07-14 | 2023-10-20 | Oppo广东移动通信有限公司 | 异常日志的收集方法及装置、电子设备、存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110401715B (zh) | 资源收集任务管理方法、装置、存储介质及系统 | |
US9372898B2 (en) | Enabling event prediction as an on-device service for mobile interaction | |
CN109960582A (zh) | 在tee侧实现多核并行的方法、装置及系统 | |
US20180039779A1 (en) | Predictive Behavioral Analysis for Malware Detection | |
JP2018514848A (ja) | クラウド対クライアント挙動の差異を通じてマルウェアを特定するための方法およびシステム | |
US20180210808A1 (en) | System and methods for application activity capture, error identification, and error correction | |
CN104541293A (zh) | 用于客户端-云行为分析器的架构 | |
CN107209825A (zh) | 经由存储器监测的数据流跟踪 | |
CN102193853A (zh) | 虚拟机监控器及其调度方法 | |
CN102855216A (zh) | 改进多处理器计算机系统的性能 | |
CN107786738B (zh) | 网络控制方法及设备 | |
CN115543577B (zh) | 基于协变量的Kubernetes资源调度优化方法、存储介质及设备 | |
CN109144658A (zh) | 有限资源的负载均衡方法、装置及电子设备 | |
CN115016866A (zh) | 应用启动时的数据处理方法、电子设备及存储介质 | |
WO2022100141A1 (zh) | 插件管理方法、系统及装置 | |
CN107689892B (zh) | 共存攻击防御方法 | |
CN109117279A (zh) | 电子装置及其限制进程间通信的方法、存储介质 | |
CN110598419A (zh) | 一种区块链客户端漏洞挖掘方法、装置、设备及存储介质 | |
Folino et al. | Automatic offloading of mobile applications into the cloud by means of genetic programming | |
CN117724937A (zh) | 日志资源管理方法及相关装置 | |
CN106482742A (zh) | 计步数据的获取方法及装置 | |
CN114281807A (zh) | 数据质量稽核方法、装置、设备及存储介质 | |
CN109635015B (zh) | 属性数据使用对象的确定方法、装置和服务器 | |
CN111984202A (zh) | 一种数据处理方法、装置、电子设备和存储介质 | |
CN114546671A (zh) | 一种数据处理方法、装置及电子设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |