CN113239000A - 一种业务日志的管理系统以及处理方法、装置和服务器 - Google Patents

一种业务日志的管理系统以及处理方法、装置和服务器 Download PDF

Info

Publication number
CN113239000A
CN113239000A CN202110523044.2A CN202110523044A CN113239000A CN 113239000 A CN113239000 A CN 113239000A CN 202110523044 A CN202110523044 A CN 202110523044A CN 113239000 A CN113239000 A CN 113239000A
Authority
CN
China
Prior art keywords
service
log
request
logs
database
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
Application number
CN202110523044.2A
Other languages
English (en)
Inventor
何弟
刘楚兰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bigo Technology Pte Ltd
Original Assignee
Bigo Technology Pte Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Bigo Technology Pte Ltd filed Critical Bigo Technology Pte Ltd
Priority to CN202110523044.2A priority Critical patent/CN113239000A/zh
Publication of CN113239000A publication Critical patent/CN113239000A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/172Caching, prefetching or hoarding of files
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/1805Append-only file systems, e.g. using logs or journals to store data
    • G06F16/1815Journaling file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/182Distributed file systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明实施例公开了一种业务日志的管理系统以及处理方法、装置和服务器。其中,该系统包括:消息消费机、列式数据库和行式数据库,消息消费机缓存在不同业务请求的请求链全过程中异步上报的业务日志,业务日志中携带有所处业务请求通过日志埋点后生成的请求链标识;消息消费机定期按照业务日志中的请求链标识,生成相应的日志统计报表,并将业务日志存储至列式数据库中,将日志统计报表存储至行式数据库中。本发明实施例提供的技术方案,实现业务请求的请求链全过程中业务日志的统一分析管理,在高并发的业务日志上报下,仍然能够按照指定节奏来存储业务日志,从而提高业务日志处理的高效性和平稳性,极大降低了数据库的负载压力。

Description

一种业务日志的管理系统以及处理方法、装置和服务器
技术领域
本发明实施例涉及数据处理技术领域,尤其涉及一种业务日志的管理系统以及处理方法、装置和服务器。
背景技术
目前,在互联网领域内针对不同业务类型已经开发有大量应用程序,每一应用程序在执行相应业务请求时,会在该业务请求的调用链全过程中,不断上报相应的业务日志,以对该业务请求进行异常监控。此时,服务端通常会采用关系型数据库mySQL来存储各个业务日志,然后通过查询mySQL数据库来分析各个业务日志。但是,在服务端对于高并发的业务日志上报,会造成mySQL数据库的存储瓶颈,从而影响到业务日志的查询速率,导致难以准确定位出业务请求的异常起因。
针对上述问题,通常会增加服务端的机器部署,以采用高并发的服务集群来接收各个应用程序上报的业务日志,同时优化mySQL数据库中的查询字段索引,但如果服务集群内的机器部署过多,会增加业务日志管理的系统复杂性,而且会造成mySQL数据库的高负载,使得在高并发的业务日志上报下,直接影响到业务日志管理的高效性。
发明内容
本发明实施例提供了一种业务日志的管理系统以及处理方法、装置和服务器,实现业务请求的请求链全过程中业务日志的统一分析管理,提高业务日志处理的高效性和平稳性。
第一方面,本发明实施例提供了一种业务日志的管理系统,该系统包括:消息消费机、列式数据库和行式数据库,所述消息消费机缓存在不同业务请求的请求链全过程中异步上报的业务日志,所述业务日志中携带有所处业务请求通过日志埋点后生成的请求链标识;其中,
所述消息消费机定期按照所述业务日志中的请求链标识,生成相应的日志统计报表,并将所述业务日志存储至所述列式数据库中,将所述日志统计报表存储至所述行式数据库中。
第二方面,本发明实施例提供了一种业务日志的处理方法,应用于上述第一方面提供的业务日志的管理系统中,该方法包括:
接收不同业务请求的请求链全过程中异步上报的业务日志,所述业务日志中携带有所处业务请求通过日志埋点后生成的请求链标识;
通过消息消费机定期按照所述业务日志中的请求链标识,生成相应的日志统计报表,并将所述业务日志存储至所述列式数据库中,将所述日志统计报表存储至所述行式数据库中。
第三方面,本发明实施例提供了一种业务日志的处理装置,配置于上述第一方面提供的业务日志的管理系统中,该装置包括:
日志接收模块,用于接收不同业务请求的请求链全过程中异步上报的业务日志,所述业务日志中携带有所处业务请求通过日志埋点后生成的请求链标识;
日志分析模块,用于通过消息消费机定期按照所述业务日志中的请求链标识,生成相应的日志统计报表,并将所述业务日志存储至所述列式数据库中,将所述日志统计报表存储至所述行式数据库中。
第四方面,本发明实施例提供了一种服务器,该服务器包括:
一个或多个处理器;
存储装置,用于存储一个或多个程序;
当所述一个或多个程序被所述一个或多个处理器执行,使得所述一个或多个处理器实现本发明任意实施例所述的业务日志的处理方法。
第五方面,本发明实施例提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现本发明任意实施例所述的业务日志的处理方法。
本发明实施例提供的一种业务日志的管理系统以及处理方法、装置和服务器,通过消息消费机接收业务应用在不同业务请求的请求链全过程中异步上报的业务日志,并在业务应用发起业务请求时,通过日志埋点生成该业务请求的请求链标识,使得请求链全过程中的每一业务日志中均携带所处业务请求的请求链标识,以便后续通过各业务日志中的请求链标识,来分析各业务请求的请求链性能,实现业务请求的请求链全过程中业务日志的统一分析管理;同时,通过消息消费机定期按照业务日志中的请求链标识,生成相应的日志统计报表,并将业务日志存储至列式数据库中,将日志统计报表存储至行式数据库中,实现业务日志的平稳存储,在高并发的业务日志上报下,仍然能够按照指定节奏来存储业务日志,从而提高业务日志处理的高效性和平稳性,通过分数据库的方式存储不同类型的日志数据,极大降低了数据库的负载压力。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本发明的其它特征、目的和优点将会变得更明显:
图1为本发明实施例一提供的一种业务日志的管理系统的原理架构图;
图2为本发明实施例二提供的一种业务日志的管理系统的结构示意图;
图3为本发明实施例三提供的一种业务日志的处理方法的流程图;
图4为本发明实施例四提供的一种业务日志的处理方法的流程图;
图5为本发明实施例五提供的一种业务日志的处理装置的结构示意图;
图6为本发明实施例六提供的一种服务器的结构示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释本发明,而非对本发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与本发明相关的部分而非全部结构。此外,在不冲突的情况下,本发明中的实施例及实施例中的特征可以相互组合。
实施例一
图1为本发明实施例一提供的一种业务日志的管理系统的原理架构图。本实施例可适用于在任一种业务应用下发起某一业务请求后,对该业务请求的请求链全过程中生成的各个业务日志进行管理的情况中。具体的,参照图1,该业务日志的管理系统10可以包括:消息消费机110、列式数据库120和行式数据库130。
其中,消息消费机110缓存在不同业务请求的请求链全过程中异步上报的业务日志,业务日志中携带有所处业务请求通过日志埋点后生成的请求链标识。
具体的,消息消费机110定期按照业务日志中的请求链标识,生成相应的日志统计报表,并将业务日志存储至列式数据库120中,将日志统计报表存储至行式数据库130中。
可选的,本实施例中的业务应用可以为任一互联网业务类型下所开发出的能够安装于客户端上的应用程序,用户通过在该业务应用上执行不同的业务操作时,会对应发起不同的业务请求,然后经过该业务应用的后台服务端来响应该业务请求。此时,每一业务请求在被后台服务的响应过程中,会经过均衡负载器、网络网关和业务服务等各个业务中间节点,直至到达后台服务,以成功响应该业务请求,从而生成对应的请求链,该请求链由业务请求在响应过程中经过的各个业务节点构成。而且,在每一业务请求的请求链全过程中,每一业务节点会按照该业务请求的执行情况生成对应的业务日志。因此,为了准确分析每一业务请求的请求链全过程中的业务执行性能,需要将在每一业务请求的请求链全过程中生成的各个业务日志存储到本实施例中提供的业务日志的管理系统10中,以便后续对每一业务请求下的业务日志情况进行分析。
需要说明的是,为了将业务请求从前端业务应用发起到后端服务对该业务请求响应返回的整个请求链路串连起来,本实施例中业务应用在前端发起业务请求后,便会采用日志埋点的方式生成该业务请求的请求链标识,然后控制该请求链标识伴随在该业务请求的请求链全过程中,从而将每一业务请求的整个前后端请求链路打通一体化,使得该业务请求的请求链全过程内的每一业务节点生成对应的业务日志时,该业务日志中也会携带该业务请求的请求链标识。也就是说,对于业务日志的管理系统10中缓存的每一业务日志来说,该业务日志中会携带有该业务日志所处业务请求通过日志埋点后生成的请求链标识,后续按照各个业务日志中携带的请求链标识,即可得到每一业务请求下完整的日志流以及业务执行环境的上下文信息,从而对每一业务请求下生成的各个业务日志进行分析,判断该业务请求的链路性能。
此时,如图1所示,在每一业务请求的请求链全过程中,该业务请求所经过的每一业务节点均可以利用本地部署的代理进程来监听该业务节点生成的业务日志,然后采用相应的数据传输协议将各个业务日志异步上报给本实施例中的业务日志的管理系统10。
进而,本实施例中的业务日志的管理系统10会依赖消息消费机110来接收在每一业务请求的请求链全过程中每一业务节点异步上报的各个业务日志,并缓存到本地。
在本实施例中,业务日志异步上报时可以采用一种无连接的传输层协议,以使业务应用上针对每一业务请求的实际业务操作与日志上报服务之间解耦,因此在每一业务请求的请求链全过程中异步上报各个业务日志时,仍然可以正常执行后续的业务操作,也就是业务日志的管理系统10所在服务端的系统升级和维护,在业务应用所在客户端发起的每一业务请求的请求链全过程中是透明的,从而保证业务请求的业务独立性,避免由于上报服务响应不及时而影响到业务请求正常响应的问题,在高并发的业务日志上报下,仍能够保持稳定的日志上报效率,而不影响业务请求的执行性能。
需要说明的是,由于每一业务请求的请求链全过程中,可能会重复生成相同的业务日志或者生成一些无用的业务日志,因此为了保证业务日志的管理系统10中所缓存的业务日志的有效性,本实施例可以针对异步上报的业务日志设定一个专门的预设日志过滤规则,该预设日志过滤规则可以指定一些无效日志的特征。然后,在通过消息消费机110接收到在每一业务请求的请求链全过程中异步上报的各个业务日志后,首先利用该预设日志过滤规则从异步上报的全部业务日志中过滤出相应的无效日志,例如重复日志或者无用日志等,然后将通过该预设日志过滤规则的预处理后剩余的业务日志缓存到该消息消费机110内,从而排除由该预设日志过滤规则所过滤的业务日志的后续存储,保证业务日志存储后的真实性和可用性。
进一步的,考虑到在业务日志上报过程中,业务日志的管理系统10所在服务端不可避免会存在重启或者宕机的情况,而且后续还需要对所存储的业务日志按照请求链标识进行额外的日志分析,来判断各个业务请求的请求链性能。因此,本实施例中的消息消费机110在缓存有每一业务请求的请求链全过程中异步上报的业务日志后,还会将所缓存的各个业务日志存储至列式数据库120中。此时,列式数据库120作为以列相关存储架构进行数据存储的数据库,能够适用于批量的日志处理和即时查询,具备高聚合的计算能力,从而提高业务日志的管理高效性。
而且,为了实时分析业务日志的性能,本实施例还会通过消息消费机110定期按照该消息消费机110内当前缓存的各个业务日志中携带的请求链标识,对同一业务请求的请求链全过程中异步上报的各个业务日志进行统计分析,从而生成各个业务请求下对应的日志统计报表,该日志统计报表中可以记录每一业务请求下在相应时段内的日志分析结果。而且,日志统计报表可以从多个维度进行日志分析,例如业务日志所处的业务应用、在请求链全过程中的所处节点、日志类型和分钟级分布情况等,使得后续可以从各个维度查看相应的日志统计结果,从而分析不同维度下的系统性能。
示例性的,通过消息消费机110可以将一个小时作为单位分片,每间隔一个小时就会提取出当前时段内缓存的各个业务日志,然后按照各个业务日志中携带的请求链标识,对同一业务请求的请求链全过程中异步上报的业务日志进行统计分析,从而生成对应的日志统计报表。此时,基于业务日志的只读特性,定期生成的各个日志统计报表中,最新的日志统计报表是基于实时业务日志的内存建模和分析得到的,而历史的日志统计报表可以通过聚合完成。
此时,由于日志统计报表属于普通的存储数据,无需执行批量的聚合处理等,而且为了降低数据库的负载压力,本实施例可以通过消息消费机110将定期生成的日志统计报表存储至行式数据库130中,与列式数据库120中原始的业务日志分区存储,通过分数据库的方式存储不同类型的日志数据,极大降低数据库的负载压力。
需要说明的是,为了保证业务日志的高并发处理,本实施例的业务日志的管理系统10中的消息消费机110、列式数据库120和行式数据库130均可以采用集群方式部署。
此外,本实施例还可以在每一业务请求的请求链全过程中的各个业务节点中,额外添加执行时延等指示节点性能的信息,使得请求链全过程中的业务日志能够携带所处业务节点的性能信息,以便后续通过各个业务日志即可分析出各个业务节点的性能瓶颈,进而对其进行针对性的优化。
而且,按照各个业务日志中携带的请求链标识,可以分析出每一业务请求的请求链路径以及所经过的业务服务,从而汇总分析出各个业务请求的服务情况。
本实施例提供的技术方案,通过消息消费机接收业务应用在不同业务请求的请求链全过程中异步上报的业务日志,并在业务应用发起业务请求时,通过日志埋点生成该业务请求的请求链标识,使得请求链全过程中的每一业务日志中均携带所处业务请求的请求链标识,以便后续通过各业务日志中的请求链标识,来分析各业务请求的请求链性能,实现业务请求的请求链全过程中业务日志的统一分析管理;同时,通过消息消费机定期按照业务日志中的请求链标识,生成相应的日志统计报表,并将业务日志存储至列式数据库中,将日志统计报表存储至行式数据库中,实现业务日志的平稳存储,在高并发的业务日志上报下,仍然能够按照指定节奏来存储业务日志,从而提高业务日志处理的高效性和平稳性,通过分数据库的方式存储不同类型的日志数据,极大降低了数据库的负载压力。
实施例二
图2为本发明实施例二提供的一种业务日志的管理系统的结构示意图。本实施例是在上述实施例提供的技术方案的基础上进行优化。参照图2,该业务日志的管理系统20可以包括:消息消费机210、列式数据库220和行式数据库230。
其中,消息消费机210缓存在不同业务请求的请求链全过程中异步上报的业务日志,业务日志中携带有所处业务请求通过日志埋点后生成的请求链标识。
具体的,消息消费机210定期按照业务日志中的请求链标识,生成相应的日志统计报表,并将业务日志存储至列式数据库220中,将日志统计报表存储至行式数据库230中。
需要说明的是,本实施例提供的业务日志的管理系统20中的消息消费机210、列式数据库220和行式数据库230与上述实施例中的消息消费机、列式数据库和行式数据库具备相同的功能。
在本实施例中,为了保证消息消费机210对于所缓存的业务日志的准确处理,该消息消费机210中可以包括异步缓存队列211、日志接收进程212、日志分发进程213和日志分析进程组214。
此时,本实施例的业务日志的管理系统20可以通过日志接收进程212实时接收在每一业务请求的请求链全过程中异步上报的各个业务日志,然后将各个业务日志均衡缓存到各个异步缓存队列211中。进而,为了对各个业务日志进行统计分析,可以通过日志分发进程213定期从异步缓存队列211中拉取相应的业务日志,然后分发给日志分析进程组214内的各个日志分析进程,由各个日志分析进程按照所分发的业务日志中的请求链标识,对同一业务请求下的各个业务日志进行相应的统计分析,从而生成相应的日志统计报表。
其中,日志接收进程212可以基于Netty的NIO实现。
需要说明的是,为了保证业务日志的处理高效性,本实施例中日志接收进程212和日志分析进程组214内的每一日志分析进程均可以采用线程池的方式,根据相应业务日志的数量,动态调整日志接收进程212和日志分析进程组214内的每一日志分析进程内所运行的线程数量。也就是说,日志接收进程212可以按照业务请求的请求链全过程中异步上报的业务日志数量,动态设置日志接收进程212内运行的线程数量,同时日志分析进程组214可以按照日志分发进程213定期从异步缓存队列211内拉取业务日志后的实际分发数量,动态设置日志分析进程组214内的进程运行数量以及每一运行的日志分析进程内的线程数量,从而避免在高并发的业务日志处理下,造成日志处理拥塞的问题,提高业务日志处理的高效性和平稳性。
而且,为了保证日志分发进程213对于业务日志在日志分析进程组214内各日志分析进程上的均衡分发,本实施例还会在消息消费机210内设置对应的负载均衡器215,通过该负载均衡器215分析日志分发进程213当前需要分发的业务日志数量,以及日志分析进程组214内各日志分析进程上已分发待处理的业务日志数量,来为日志分析进程组214内的各个日志分析进程均衡分发相应数量的业务日志,确保业务日志的均衡处理。
此外,本实施例提供的业务日志的管理系统20支持用户对所发起的各个业务请求的业务执行质量进行查询,在业务日志的管理系统20的用户前端设置有对应的系统界面,用户可以在系统界面中通过填写业务请求的资源访问地址(Uniform Resource Locator,URL)、时间、机房和区域等检索条件来选择本次想要查询的业务请求下所生成的各个业务日志的目标查询维度以及对应的目标查询报表,此时该目标查询维度可以为业务日志在列式数据库220中存储时的任一个维度,也可以为多个维度,对此不作限定;本实施例中业务日志的查询维度可以是指业务日志所处业务请求在请求链全过程中执行时的运行性能面向的不同指标维度,例如按照各个业务日志中的请求链标识分析各个业务请求的请求链分布图和在请求链全过程中任一业务节点的日志性能等。
此时,本实施例中的业务日志的管理系统20可以通过查询服务进程240来接收用户在系统界面内当前选择好本次想要查询的目标查询维度和目标查询报表后生成的业务查询指令,该业务查询指令可以指示查看各个业务日志在目标查询维度下的性能,例如某一业务节点对于业务日志的处理性能等,还可以查看对应的日志统计报表。此时,通过查询服务进程240解析当前接收的业务查询请求,即可确定出本次指定的目标查询维度和目标查询报表,然后将目标查询维度推送给列式数据库220,将目标查询报表推送给行式数据库230。
进而,列式数据库220在接收到目标查询维度后,利用列式数据库220具备的高聚合计算能力,可以在该目标查询维度下对所存储的业务日志进行对应的聚合分析,得到目标查询维度下的业务查询结果,并推送给查询服务进程240。而且,行式数据库230也可以在接收到目标查询报表后,按照目标查询报表查找出对应的日志统计报表,并推送给查询服务进程240。然后,查询服务进程240将目标查询维度下的业务查询结果和目标查询报表指定的日志统计报表展示在系统界面内,由前端采用开源的图表工具echarts来对每一目标查询维度下的业务查询结果进行绘图展示,使得用户能够直观地查看目标查询维度下的业务执行性能。
进一步的,由于业务请求的请求链全过程中会存在相应的故障情况,因此为了准确定位出业务请求的请求链全过程中的故障点,本实施例还会通过异常监控进程250对列式数据库220中存储的各个业务日志进行异常监控,并按照异常业务日志中的请求链标识,在异常业务日志所处业务请求的请求链全过程中进行异常定位。
也就是说,异常监控进程250在检测到异常业务日志后,通过分析该异常业务日志中携带的请求链标识,即可查看出该异常业务日志所处业务请求的整个执行环境中的上下文信息,然后按照该异常业务日志中的生成节点,即可从该异常业务日志所处业务请求的请求链全过程中进行异常定位,从而准确查找出每一业务请求的请求链全过程中的故障位置点,保证业务请求的请求链全过程中故障定位的及时性,优化业务请求的执行性能。
本实施例提供的技术方案,通过消息消费机接收业务应用在不同业务请求的请求链全过程中异步上报的业务日志,并在业务应用发起业务请求时,通过日志埋点生成该业务请求的请求链标识,使得请求链全过程中的每一业务日志中均携带所处业务请求的请求链标识,以便后续通过各业务日志中的请求链标识,来分析各业务请求的请求链性能,实现业务请求的请求链全过程中业务日志的统一分析管理;同时,通过消息消费机定期按照业务日志中的请求链标识,生成相应的日志统计报表,并将业务日志存储至列式数据库中,将日志统计报表存储至行式数据库中,实现业务日志的平稳存储,在高并发的业务日志上报下,仍然能够按照指定节奏来存储业务日志,从而提高业务日志处理的高效性和平稳性,通过分数据库的方式存储不同类型的日志数据,极大降低了数据库的负载压力。
实施例三
图3为本发明实施例三提供的一种业务日志的处理方法的流程图,本实施例可适用于在任一种业务应用下发起某一业务请求后,对该业务请求的请求链全过程中生成的各个业务日志进行管理的情况中,可应用于上述实施例提供的业务日志的管理系统中。本实施例提供的一种业务日志的处理方法可以由本发明实施例提供的业务日志的处理装置来执行,该装置可以通过软件和/或硬件的方式来实现,并集成在执行本方法的服务器中,该服务器可以是本发明任意实施例提供的业务日志的管理系统对应的后台服务端。
具体的,参考图3,该方法可以包括如下步骤:
S310,接收不同业务请求的请求链全过程中异步上报的业务日志,该业务日志中携带有所处业务请求通过日志埋点后生成的请求链标识。
具体的,为了将业务请求从前端业务应用发起到后端服务对该业务请求响应返回的整个请求链路串连起来,本实施例中业务应用在前端发起业务请求后,便会采用日志埋点的方式生成该业务请求的请求链标识,然后控制该请求链标识伴随在该业务请求的请求链全过程中,从而将每一业务请求的整个前后端请求链路打通一体化,使得该业务请求的请求链全过程内的每一业务节点生成对应的业务日志时,该业务日志中也会携带该业务请求的请求链标识。也就是说,对于业务请求发起后生成的每一业务日志来说,该业务日志中会携带有该业务日志所处业务请求通过日志埋点后生成的请求链标识,后续按照各个业务日志中携带的请求链标识,即可得到每一业务请求下完整的日志流以及业务执行环境的上下文信息,从而对每一业务请求下生成的各个业务日志进行分析,判断该业务请求的链路性能。
此时,在每一业务请求的请求链全过程中,该业务请求所经过的每一业务节点均可以利用本地部署的代理进程来监听该业务节点生成的业务日志,然后采用相应的数据传输协议对各个业务日志进行异步上报。进而,依赖消息消费机来接收在每一业务请求的请求链全过程中每一业务节点异步上报的各个业务日志,并缓存到本地。
需要说明的是,由于每一业务请求的请求链全过程中,可能会重复生成相同的业务日志或者生成一些无用的业务日志,因此为了保证业务日志缓存的有效性,本实施例可以针对异步上报的业务日志设定一个专门的预设日志过滤规则,该预设日志过滤规则可以指定一些无效日志的特征。此时,接收不同业务请求的请求链全过程中异步上报的业务日志,可以具体包括:利用预设日志过滤规则对不同业务请求的请求链全过程中异步上报的业务日志进行预处理,并将预处理后的业务日志缓存至消息消费机中。
也就是说,通过消息消费机接收到在每一业务请求的请求链全过程中异步上报的各个业务日志后,首先利用该预设日志过滤规则从异步上报的全部业务日志中过滤出相应的无效日志,例如重复日志或者无用日志等,然后将通过该预设日志过滤规则的预处理后剩余的业务日志缓存到该消息消费机内,从而排除由该预设日志过滤规则所过滤的业务日志的后续存储,保证业务日志存储后的真实性和可用性。
S320,通过消息消费机定期按照所业务日志中的请求链标识,生成相应的日志统计报表,并将业务日志存储至列式数据库中,将日志统计报表存储至行式数据库中。
可选的,考虑到在业务日志上报过程中,业务日志的管理系统所在服务端不可避免会存在重启或者宕机的情况,而且后续还需要对所存储的业务日志按照请求链标识进行额外的日志分析,来判断各个业务请求的请求链性能。因此,本实施例在通过消息消费机缓存有每一业务请求的请求链全过程中异步上报的业务日志后,还会将所缓存的各个业务日志存储至列式数据库中。此时,列式数据库作为以列相关存储架构进行数据存储的数据库,能够适用于批量的日志处理和即时查询,具备高聚合的计算能力,从而提高业务日志的管理高效性。
而且,为了实时分析业务日志的性能,本实施例还会通过消息消费机定期按照该消息消费机内当前缓存的各个业务日志中携带的请求链标识,对同一业务请求的请求链全过程中异步上报的各个业务日志进行统计分析,从而生成各个业务请求下对应的日志统计报表,该日志统计报表中可以记录每一业务请求下在相应时段内的日志分析结果。而且,日志统计报表可以从多个维度进行日志分析,例如业务日志所处的业务应用、在请求链全过程中的所处节点、日志类型和分钟级分布情况等,使得后续可以从各个维度查看相应的日志统计结果,从而分析不同维度下的系统性能。
此时,由于日志统计报表属于普通的存储数据,无需执行批量的聚合处理等,而且为了降低数据库的负载压力,本实施例可以通过消息消费机将定期生成的日志统计报表存储至行式数据库中,与列式数据库中原始的业务日志分区存储,通过分数据库的方式存储不同类型的日志数据,极大降低数据库的负载压力。
示例性的,为了保证消息消费机对于所缓存的业务日志的准确处理,本实施例中通过消息消费机定期按照业务日志中的请求链标识,生成相应的日志统计报表,具体可以包括:通过消息消费机内的日志分发进程定期将业务日志均衡分发给消息消费机内的日志分析进程组内的各日志分析进程;通过每一日志分析进程按照所分发的业务日志中的请求链标识,生成相应的日志统计报表。
具体的,本实施例可以通过日志接收进程实时接收在每一业务请求的请求链全过程中异步上报的各个业务日志,然后将各个业务日志均衡缓存到各个异步缓存队列中。进而,为了对各个业务日志进行统计分析,可以通过日志分发进程定期从异步缓存队列中拉取相应的业务日志,然后分发给日志分析进程组内的各个日志分析进程,由各个日志分析进程按照所分发的业务日志中的请求链标识,对同一业务请求下的各个业务日志进行相应的统计分析,从而生成相应的日志统计报表。
需要说明的是,为了保证业务日志的处理高效性,本实施例中日志接收进程和日志分析进程组内的每一日志分析进程均可以采用线程池的方式,根据相应业务日志的数量,动态调整日志接收进程和日志分析进程组内的每一日志分析进程内所运行的线程数量。也就是说,本实施例可以按照根据业务日志的分发数量,动态设置日志分析进程组内的进程运行数量以及每一运行的日志分析进程内的线程数量,从而避免在高并发的业务日志处理下,造成日志处理拥塞的问题,提高业务日志处理的高效性和平稳性。
本实施例提供的技术方案,通过消息消费机接收业务应用在不同业务请求的请求链全过程中异步上报的业务日志,并在业务应用发起业务请求时,通过日志埋点生成该业务请求的请求链标识,使得请求链全过程中的每一业务日志中均携带所处业务请求的请求链标识,以便后续通过各业务日志中的请求链标识,来分析各业务请求的请求链性能,实现业务请求的请求链全过程中业务日志的统一分析管理;同时,通过消息消费机定期按照业务日志中的请求链标识,生成相应的日志统计报表,并将业务日志存储至列式数据库中,将日志统计报表存储至行式数据库中,实现业务日志的平稳存储,在高并发的业务日志上报下,仍然能够按照指定节奏来存储业务日志,从而提高业务日志处理的高效性和平稳性,通过分数据库的方式存储不同类型的日志数据,极大降低了数据库的负载压力。
实施例四
图4为本发明实施例四提供的一种业务日志的处理方法的流程图。本实施例是在上述实施例的基础上进行优化。具体的,如图4所示,本实施例主要对于各个业务请求的业务执行性能的具体查询过程以及业务日志的异常监控过程进行详细的解释说明。
可选的,如图4所示,本实施例中可以包括如下步骤:
S410,接收不同业务请求的请求链全过程中异步上报的业务日志,该业务日志中携带有所处业务请求通过日志埋点后生成的请求链标识。
S420,通过消息消费机定期按照业务日志中的请求链标识,生成相应的日志统计报表,并将业务日志存储至列式数据库中,将日志统计报表存储至行式数据库中。
S430,通过查询服务进程接收当前的业务查询请求,并基于业务查询请求确定目标查询维度和目标查询报表。
可选的,本实施例支持用户对业务应用所发起的各个业务请求的业务执行质量进行查询,在用户前端设置有对应的系统界面,用户可以在系统界面中通过填写业务请求的URL、时间、机房和区域等检索条件来选择本次想要查询的业务请求下所生成的各个业务日志的目标查询维度以及对应的目标查询报表,从而生成对应的业务查询请求。
此时,通过查询服务进程可以接收用户在系统界面内当前选择好本次想要查询的目标查询维度和目标查询报表后生成的业务查询指令,并解析当前接收的业务查询请求,即可确定出本次指定的目标查询维度和目标查询报表,然后将目标查询维度推送给列式数据库,将目标查询报表推送给行式数据库,以便后续执行相应的业务性能分析。
S440,通过列式数据库按照目标查询维度对业务日志进行对应的聚合分析,得到目标查询维度下的业务查询结果。
可选的,通过列式数据库接收到目标查询维度后,可以利用列式数据库具备的高聚合计算能力,在该目标查询维度下对所存储的业务日志进行对应的聚合分析,得到目标查询维度下的业务查询结果,然后推送给查询服务进程,由查询服务进程将目标查询维度下的业务查询结果展示在系统界面内,由前端采用开源的图表工具echarts来对每一目标查询维度下的业务查询结果进行绘图展示,使得用户能够直观地查看目标查询维度下的业务执行性能。
S450,通过行式数据库按照目标查询报表查找出对应的日志统计报表。
可选的,通过行式数据库接收到目标查询报表后,按照目标查询报表查找出对应的日志统计报表,并推送给查询服务进程,由查询服务进程将目标查询报表指定的日志统计报表展示在系统界面内,使得用户能够直观地查看所查询的日志统计报表。
S460,对列式数据库中的业务日志进行异常监控,并按照异常业务日志中的请求链标识,在异常业务日志所处业务请求的请求链全过程中进行异常定位。
在本实施例中,通过异常监控进程可以对列式数据库中的业务日志进行异常监控,并在检测到异常业务日志后,通过分析该异常业务日志中携带的请求链标识,即可查看出该异常业务日志所处业务请求的整个执行环境中的上下文信息,然后按照该异常业务日志中的生成节点,即可从该异常业务日志所处业务请求的请求链全过程中进行异常定位,从而准确查找出每一业务请求的请求链全过程中的故障位置点,保证业务请求的请求链全过程中故障定位的及时性,优化业务请求的执行性能。
本实施例提供的技术方案,通过消息消费机接收业务应用在不同业务请求的请求链全过程中异步上报的业务日志,并在业务应用发起业务请求时,通过日志埋点生成该业务请求的请求链标识,使得请求链全过程中的每一业务日志中均携带所处业务请求的请求链标识,以便后续通过各业务日志中的请求链标识,来分析各业务请求的请求链性能,实现业务请求的请求链全过程中业务日志的统一分析管理;同时,通过消息消费机定期按照业务日志中的请求链标识,生成相应的日志统计报表,并将业务日志存储至列式数据库中,将日志统计报表存储至行式数据库中,实现业务日志的平稳存储,在高并发的业务日志上报下,仍然能够按照指定节奏来存储业务日志,从而提高业务日志处理的高效性和平稳性,通过分数据库的方式存储不同类型的日志数据,极大降低了数据库的负载压力。
实施例五
图5为本发明实施例五提供的一种业务日志的处理装置的结构示意图,可以配置于本发明任意实施例提供的业务日志的管理系统中。具体的,如图5所示,该装置可以包括:
日志接收模块510,用于接收不同业务请求的请求链全过程中异步上报的业务日志,业务日志中携带有所处业务请求通过日志埋点后生成的请求链标识;
日志分析模块520,用于通过消息消费机定期按照所述业务日志中的请求链标识,生成相应的日志统计报表,并将所述业务日志存储至所述列式数据库中,将所述日志统计报表存储至所述行式数据库中。
本实施例提供的技术方案,通过消息消费机接收业务应用在不同业务请求的请求链全过程中异步上报的业务日志,并在业务应用发起业务请求时,通过日志埋点生成该业务请求的请求链标识,使得请求链全过程中的每一业务日志中均携带所处业务请求的请求链标识,以便后续通过各业务日志中的请求链标识,来分析各业务请求的请求链性能,实现业务请求的请求链全过程中业务日志的统一分析管理;同时,通过消息消费机定期按照业务日志中的请求链标识,生成相应的日志统计报表,并将业务日志存储至列式数据库中,将日志统计报表存储至行式数据库中,实现业务日志的平稳存储,在高并发的业务日志上报下,仍然能够按照指定节奏来存储业务日志,从而提高业务日志处理的高效性和平稳性,通过分数据库的方式存储不同类型的日志数据,极大降低了数据库的负载压力。
本实施例提供的业务日志的处理装置可适用于上述任意实施例提供的业务日志的处理方法,具备相应的功能和有益效果。
实施例六
图6为本发明实施例六提供的一种服务器的结构示意图,如图6所示,该服务器包括处理器60、存储装置61和通信装置62;服务器中处理器60的数量可以是一个或多个,图6中以一个处理器60为例;服务器中的处理器60、存储装置61和通信装置62可以通过总线或其他方式连接,图6中以通过总线连接为例。
本实施例提供的一种服务器可用于执行上述任意实施例提供的业务日志的处理方法,具备相应的功能和有益效果。
实施例七
本发明实施例七还提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时可实现上述任意实施例中的业务日志的处理方法。
该方法具体可以包括如下步骤:
当然,本发明实施例所提供的一种包含计算机可执行指令的存储介质,其计算机可执行指令不限于如上所述的方法操作,还可以执行本发明任意实施例所提供的业务日志的处理方法中的相关操作。
通过以上关于实施方式的描述,所属领域的技术人员可以清楚地了解到,本发明可借助软件及必需的通用硬件来实现,当然也可以通过硬件实现,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
值得注意的是,上述业务日志的处理装置的实施例中,所包括的各个单元和模块只是按照功能逻辑进行划分的,但并不局限于上述的划分,只要能够实现相应的功能即可;另外,各功能单元的具体名称也只是为了便于相互区分,并不用于限制本发明的保护范围。
以上所述仅为本发明的优选实施例,并不用于限制本发明,对于本领域技术人员而言,本发明可以有各种改动和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (17)

1.一种业务日志的管理系统,其特征在于,包括:消息消费机、列式数据库和行式数据库,所述消息消费机缓存在不同业务请求的请求链全过程中异步上报的业务日志,所述业务日志中携带有所处业务请求通过日志埋点后生成的请求链标识;其中,
所述消息消费机定期按照所述业务日志中的请求链标识,生成相应的日志统计报表,并将所述业务日志存储至所述列式数据库中,将所述日志统计报表存储至所述行式数据库中。
2.根据权利要求1所述的管理系统,其特征在于,所述消息消费机包括异步缓存队列、日志接收进程、日志分发进程和日志分析进程组;其中,
所述日志接收进程接收在不同业务请求的请求链全过程中异步上报的业务日志,并将所述业务日志缓存至所述异步缓存队列中;
所述日志分发进程定期从所述异步缓存队列中拉取所述业务日志,并分发给所述日志分析进程组内的各日志分析进程;
所述日志分析进程内的各日志分析进程按照所分发的业务日志中的请求链标识,生成相应的日志统计报表。
3.根据权利要求2所述的管理系统,其特征在于,所述日志接收进程和所述日志分析进程组内的每一日志分析进程均采用线程池,所述日志接收进程按照异步上报的业务日志数量,动态设置所述日志接收进程内运行的线程数量,所述日志分析进程组按照所述业务日志的分发数量,动态设置所述日志分析进程组内的进程运行数量以及每一运行的日志分析进程内的线程数量。
4.根据权利要求2所述的管理系统,其特征在于,所述消息消费机还包括:负载均衡器,所述负载均衡器用于均衡所述日志分析进程组内各日志分析进程上分发的业务日志。
5.根据权利要求1所述的管理系统,其特征在于,还包括:查询服务进程;
所述查询服务进程根据当前接收的业务查询请求,确定目标查询维度和目标查询报表,并将所述目标查询维度推送给所述列式数据库,将所述目标查询报表推送给所述行式数据库;
所述列式数据库按照所述目标查询维度对所存储的业务日志进行对应的聚合分析,得到所述目标查询维度下的业务查询结果,并推送给所述查询服务进程;
所述行式数据库按照所述目标查询报表查找出对应的日志统计报表,并推送给所述查询服务进程。
6.根据权利要求1所述的管理系统,其特征在于,还包括:异常监控进程;
所述异常监控进程对所述列式数据库中的业务日志进行异常监控,并按照异常业务日志中的请求链标识,在所述异常业务日志所处业务请求的请求链全过程中进行异常定位。
7.根据权利要求1-6任一项所述的管理系统,其特征在于,所述消息消费机上缓存的业务日志为利用预设日志过滤规则进行预处理后的业务日志。
8.根据权利要求1-6任一项所述的管理系统,其特征在于,所述消息消费机、所述列式数据库和所述行式数据库采用集群方式部署。
9.一种业务日志的处理方法,其特征在于,应用于权利要求1-8任一项所述的业务日志的管理系统中,包括:
接收不同业务请求的请求链全过程中异步上报的业务日志,所述业务日志中携带有所处业务请求通过日志埋点后生成的请求链标识;
通过消息消费机定期按照所述业务日志中的请求链标识,生成相应的日志统计报表,并将所述业务日志存储至所述列式数据库中,将所述日志统计报表存储至所述行式数据库中。
10.根据权利要求9所述的方法,其特征在于,所述接收不同业务请求的请求链全过程中异步上报的业务日志,包括:
利用预设日志过滤规则对不同业务请求的请求链全过程中异步上报的业务日志进行预处理,并将预处理后的业务日志缓存至所述消息消费机中。
11.根据权利要求9所述的方法,其特征在于,所述通过消息消费机定期按照所述业务日志中的请求链标识,生成相应的日志统计报表,包括:
通过所述消息消费机内的日志分发进程定期将所述业务日志均衡分发给所述消息消费机内的日志分析进程组内的各日志分析进程;
通过每一所述日志分析进程按照所分发的业务日志中的请求链标识,生成相应的日志统计报表。
12.根据权利要求11所述的方法,其特征在于,所述方法还包括:
按照根据所述业务日志的分发数量,动态设置所述日志分析进程组内的进程运行数量以及每一运行的日志分析进程内的线程数量。
13.根据权利要求9所述的方法,其特征在于,所述方法还包括:
通过查询服务进程接收当前的业务查询请求,并基于所述业务查询请求确定目标查询维度和目标查询报表;
通过所述列式数据库按照所述目标查询维度对所述业务日志进行对应的聚合分析,得到所述目标查询维度下的业务查询结果;
通过所述行式数据库按照所述目标查询报表查找出对应的日志统计报表。
14.根据权利要求9所述的方法,其特征在于,所述方法还包括:
对所述列式数据库中的业务日志进行异常监控,并按照异常业务日志中的请求链标识,在所述异常业务日志所处业务请求的请求链全过程中进行异常定位。
15.一种业务日志的处理装置,其特征在于,配置于权利要求1-8任一项所述的业务日志的管理系统中,包括:
日志接收模块,用于接收不同业务请求的请求链全过程中异步上报的业务日志,所述业务日志中携带有所处业务请求通过日志埋点后生成的请求链标识;
日志分析模块,用于通过消息消费机定期按照所述业务日志中的请求链标识,生成相应的日志统计报表,并将所述业务日志存储至所述列式数据库中,将所述日志统计报表存储至所述行式数据库中。
16.一种服务器,其特征在于,所述服务器包括:
一个或多个处理器;
存储装置,用于存储一个或多个程序;
当所述一个或多个程序被所述一个或多个处理器执行,使得所述一个或多个处理器实现如权利要求9-14中任一所述的业务日志的处理方法。
17.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现如权利要求9-14中任一所述的业务日志的处理方法。
CN202110523044.2A 2021-05-13 2021-05-13 一种业务日志的管理系统以及处理方法、装置和服务器 Pending CN113239000A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110523044.2A CN113239000A (zh) 2021-05-13 2021-05-13 一种业务日志的管理系统以及处理方法、装置和服务器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110523044.2A CN113239000A (zh) 2021-05-13 2021-05-13 一种业务日志的管理系统以及处理方法、装置和服务器

Publications (1)

Publication Number Publication Date
CN113239000A true CN113239000A (zh) 2021-08-10

Family

ID=77134065

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110523044.2A Pending CN113239000A (zh) 2021-05-13 2021-05-13 一种业务日志的管理系统以及处理方法、装置和服务器

Country Status (1)

Country Link
CN (1) CN113239000A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113806360A (zh) * 2021-08-12 2021-12-17 浙江吉利控股集团有限公司 一种派单链路故障确定方法、装置、设备及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107330034A (zh) * 2017-06-26 2017-11-07 百度在线网络技术(北京)有限公司 一种日志分析方法和装置、计算机设备、存储介质
CN107391746A (zh) * 2017-08-10 2017-11-24 深圳前海微众银行股份有限公司 日志分析方法、设备和计算机可读存储介质
CN109639809A (zh) * 2018-12-20 2019-04-16 上海拍拍贷金融信息服务有限公司 一种业务数据请求链路监控的方法及装置
CN109726074A (zh) * 2018-08-31 2019-05-07 网联清算有限公司 日志处理方法、装置、计算机设备和存储介质
CN111752799A (zh) * 2020-06-24 2020-10-09 中国建设银行股份有限公司 一种业务链路跟踪方法、装置、设备及储存介质
CN112491611A (zh) * 2020-11-25 2021-03-12 网银在线(北京)科技有限公司 故障定位系统、方法、装置、电子设备和计算机可读介质
CN112506915A (zh) * 2020-10-27 2021-03-16 百果园技术(新加坡)有限公司 一种应用数据的管理系统以及处理方法、装置和服务器

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107330034A (zh) * 2017-06-26 2017-11-07 百度在线网络技术(北京)有限公司 一种日志分析方法和装置、计算机设备、存储介质
CN107391746A (zh) * 2017-08-10 2017-11-24 深圳前海微众银行股份有限公司 日志分析方法、设备和计算机可读存储介质
CN109726074A (zh) * 2018-08-31 2019-05-07 网联清算有限公司 日志处理方法、装置、计算机设备和存储介质
CN109639809A (zh) * 2018-12-20 2019-04-16 上海拍拍贷金融信息服务有限公司 一种业务数据请求链路监控的方法及装置
CN111752799A (zh) * 2020-06-24 2020-10-09 中国建设银行股份有限公司 一种业务链路跟踪方法、装置、设备及储存介质
CN112506915A (zh) * 2020-10-27 2021-03-16 百果园技术(新加坡)有限公司 一种应用数据的管理系统以及处理方法、装置和服务器
CN112491611A (zh) * 2020-11-25 2021-03-12 网银在线(北京)科技有限公司 故障定位系统、方法、装置、电子设备和计算机可读介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113806360A (zh) * 2021-08-12 2021-12-17 浙江吉利控股集团有限公司 一种派单链路故障确定方法、装置、设备及存储介质

Similar Documents

Publication Publication Date Title
US11775501B2 (en) Trace and span sampling and analysis for instrumented software
CN108009236B (zh) 一种大数据查询方法、系统、计算机及存储介质
US8176196B2 (en) Stream data processing method and apparatus
US20210058320A1 (en) Time-Series Data Monitoring With Sharded Server
WO2020233212A1 (zh) 一种日志记录的处理方法、服务器及存储介质
US8635617B2 (en) Tracking requests that flow between subsystems using transaction identifiers for generating log data
CN112506915B (zh) 一种应用数据的管理系统以及处理方法、装置和服务器
CN111984499A (zh) 一种大数据集群的故障检测方法和装置
CN112653586A (zh) 基于全链路监控的时空大数据平台应用性能管理方法
WO2014120487A1 (en) Data stream splitting for low-latency data access
CN106940677A (zh) 一种应用日志数据告警方法及装置
Zygouras et al. Insights on a scalable and dynamic traffic management system.
US11436116B1 (en) Recovering pre-indexed data from a shared storage system following a failed indexer
US9922133B2 (en) Live topological query
CN111740860A (zh) 日志数据传输链路监控方法及装置
CN107783985A (zh) 一种分布式数据库查询方法、装置及管理系统
US20210303532A1 (en) Streamlined transaction and dimension data collection
CN112559567A (zh) 适用于olap查询引擎的查询方法及装置
US9367418B2 (en) Application monitoring
CN114979186B (zh) 基于Flink组件的流量链接分析方法及系统
CN113239000A (zh) 一种业务日志的管理系统以及处理方法、装置和服务器
CN109299089A (zh) 一种画像标签数据的计算及存储方法和计算及存储系统
CN110011845B (zh) 日志采集方法及系统
CN112579552A (zh) 日志存储及调用方法、装置及系统
CN113568804A (zh) 一种面向Web应用的性能瓶颈精准定位系统

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