CN112506894A

CN112506894A - 基于链路追踪的服务链日志处理方法、装置和计算机设备

Info

Publication number: CN112506894A
Application number: CN202011401505.0A
Authority: CN
Inventors: 王辉
Original assignee: Ping An Medical and Healthcare Management Co Ltd
Current assignee: Shenzhen Ping An Medical Health Technology Service Co Ltd
Priority date: 2020-12-02
Filing date: 2020-12-02
Publication date: 2021-03-16

Abstract

本申请揭示了一种基于链路追踪的服务链日志处理方法、装置和计算机设备，其中方法包括：分别对服务链中不同应用进群进行日志数据采集，得到对应的日志数据；对所述日志数据进行格式标准化，得到标准格式的日志数据；通过Kafka中间件将所述标准格式的日志数据全量存储到Hbase数据库中；对数据进行分析处理，得到检索索引数据和统计分析数据；将所述检索索引类数据存入ES集群；将所述统计分析数据存入关系数据库MySQL。本申请通过对日志数据进行采集和数据格式标准化，然后对日志数据进行分析处理，将不同数据类型的日志数据储存在不同的数据库中，能够使运维人员快速识别关键节点数据，根据日志数据中的参数实现服务监控，提高运维效率。

Description

基于链路追踪的服务链日志处理方法、装置和计算机设备

技术领域

本申请涉及到通信技术领域，特别是涉及到一种基于链路追踪的服务链日志处理方法、装置和计算机设备。

背景技术

近年来，微服务架构因其服务间松耦合、可由不同团队不同语言开发以及快速独立部署等特点备受青睐，越来越多企业选择微服务架构进行系统开发或将传统集中式大型系统进行微服务化改造。微服务架构满足了企业对软件系统敏捷开发、高效运转、可伸缩性强等需求，但微服务架构带来的问题也不容忽视。

传统的监控系统、日志分析系统都是孤立的，针对当前分布式系统场景，没办法做到全链路层面的日志追踪。同时由于传统的监控系统，无法清晰监控一个业务流程经过的每一个环节、每个服务的执行时长、执行状态、过程参数、上下游服务等信息，导致运维人员处理分布式系统故障时比较困难，需要花费大量时间来理清各服务间调用关系，而且容易出错，使得整体的运维工作效率较低。

发明内容

本申请的主要目的为提供一种基于链路追踪的服务链日志处理方法、装置和计算机设备，旨在解决如何实现在分布式微服务系统中实现日志处理、提高运维效率的技术问题。

为了实现上述发明目的，本申请提出一种基于链路追踪的服务链日志处理方法，包括：

分别对服务链中不同应用进群进行日志数据采集，得到对应的日志数据；

对所述日志数据进行格式标准化，得到标准格式的日志数据；

通过Kafka中间件将所述标准格式的日志数据全量存储到Hbase数据库中；

对Kafka中间件中的日志数据进行流处理，得到检索索引数据和统计分析数据；

将所述检索索引类数据存入ES集群；

将所述统计分析数据存入关系数据库MySQL。

进一步地，所述分别对服务链中不同应用进群进行日志数据采集，得到对应的日志数据步骤，包括：

通过业务代码调用应用集群的日志输出接口进行日志采集。

通过代理Agent实现在不同应用集群的日志埋点，对服务调用过程切面进行拦截，捕获日志数据，完成数据采集。

进一步地，所述对所述日志数据进行格式标准化，得到标准格式的日志数据的步骤包括：

根据调用链路径关系确定TraceID、SpanID、ParentID，得到日志基本属性；

根据调用业务类型确定日志扩展属性；

将所述日志基本属性和所述日志扩展属性按照预设的格式保存为所述标准格式的日志数据。

进一步地，所述将所述统计分析数据存入关系数据库MySQL的步骤之后还包括：

接收来自WEB端的日志查询操作指令；

根据所述日志查询操作指令判断所查询的日志数据类型；

根据所述日志数据类型在对应的数据库中进行日志数据查询，得到查询结果；

将所述查询结果发送到WEB端进行展示。

进一步地，所述将所述查询结果发送到WEB端进行展示的步骤包括：

根据业务需求，按照服务调用顺序排序进行日志展示，同一个服务调用内产生的日志进一步按时间排序；

对于同一业务请求类型，将同一请求类型的不同调用链进行对比；

将较长的调用链按其内部服务间的连接关系进行分段，使用预设的聚类算法对该服务调用网络图进行子图划分，使处于同一子图内的服务间连接紧密，不同子图间的服务连接稀疏。

进一步地，所述通过Kafka中间件将所述标准格式的日志数据全量存储到Hbase数据库中的步骤之后还包括：

对所述标准格式的日志数据进行错误和异常分析；

若发现日志错误或日志异常，则向预设的预警信息接收地址发送预警信息。

本申请实施例还提供一种基于链路追踪的服务链日志处理装置，包括：

采集模块，用于分别对服务链中不同应用进群进行日志数据采集，得到对应的日志数据；

标准化模块，用于对所述日志数据进行格式标准化，得到标准格式的日志数据；

Kafka模块，用于通过Kafka中间件将所述标准格式的日志数据全量存储到Hbase数据库中；

分析处理模块，用于对Kafka中间件中的日志数据进行流处理，得到检索索引数据和统计分析数据；

第一执行模块，用于将所述检索索引类数据存入ES集群；

第二执行模块，用于将所述统计分析数据存入关系数据库MySQL。

本申请还提供一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述任一项所述方法的步骤。

本申请还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一项所述的方法的步骤。

本申请的基于链路追踪的服务链日志处理方法、装置和计算机设备，通过对日志数据进行采集和数据格式标准化，然后对日志数据进行分析处理，将不同数据类型的日志数据储存在不同的数据库中，能够使运维人员快速识别关键节点数据，根据日志数据中的参数实现服务监控，提高运维效率。

附图说明

图1为本申请一实施例的基于链路追踪的服务链日志处理方法的流程示意图；

图2为本申请一实施例的基于链路追踪的服务链日志处理装置的结构示意框图；

图3为本申请一实施例的计算机设备的结构示意框图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

参照图1，本申请实施例中提供一种基于链路追踪的服务链日志处理方法，包括步骤：

S1、分别对服务链中不同应用进群进行日志数据采集，得到对应的日志数据；

S2、对所述日志数据进行格式标准化，得到标准格式的日志数据；

S3、通过Kafka中间件将所述标准格式的日志数据全量存储到Hbase数据库中；

S4、对Kafka中间件中的日志数据进行流处理，得到检索索引数据和统计分析数据；

S5、将所述检索索引类数据存入ES集群；

S6、将所述统计分析数据存入关系数据库MySQL。

如上述步骤S1所述，在本实施例中，可以从不同的应用集群(如web集群，接口服务系统群和业务系统集群等)中采集数据，完成分布式系统的日志采集工作。其中应用集群通过服务中间件产生日志并将日志写入日志文件，日志收集器读取该应用集群的日志。应用集群生成日志的操作可以基于disruptor实现并提供标准api(应用程序接口)，通过设置拦截器或者代码嵌入的方式调用api，将日志写入缓冲队列，并异步保存到本地日志文件中。日志收集器将读取的日志写入日志收集器的缓冲队列，如ringbuffer(环形缓冲区)。

如上述步骤S2所述，在本实施例中，提出了将日志数据进行格式标准化的过程，通过统一日志数据格式，可以使运维人员能够快速识别关键节点数据。日志数据标准化的过程可以通过统一配置的方式实现，根据配置信息直接生成标准格式的日志数据，也可以通过再次处理的方式实现，将原日志数据进行格式转换，得到标准格式的日志数据。

如上述步骤S3所述，可以使用基于Kafka的消息中间件进行日志数据收集，提供日志消息队列的缓冲功能，实现日志数据的海量传输。通过Kafka消息中间件将全量的日志数据存储到Hbase数据库中，可以起到数据备份的作用。

如上述步骤S4-S6所述，然后对Kafka中间件中的日志数据进行流处理，例如可以通过storm分布式流处理框架实现，通过读取消息，然后对日志数据进行集中分析，将检索索引类数据存入ES(Elasticsearch)集群，将分析数据存入关系数据库MySQL。这样可以方便后续的数据查询与展示。

Storm是一种开源的大数据处理系统集群，基于storm实现的分布式流式处理框架，可以从消息中间件集群读取日志，接收日志消息队列中的日志，并根据预设的规则实时分析处理日志，主要处理操作如下：

(1)、验证：主要是对一些不符合规范的数据进行过滤，以达到系统能够处理的标准，包括对日志格式、请求链是否可分析、上下文信息是否完整等信息进行验证。Storm读取消息队列中的日志进行验证分析，对单条调用链进行分析并将结果存储到数据库中，同时将全量日志存储到离线数据分析集群中。

(2)、分析：主要是对调用链进行统计，统计单条调用链的调用接口数、请求响应时间、cpu、内存和jvm(Java虚拟机)性能参数等数据，分析调用来源，调用依赖，并将分析结果写入ES数据库或Mysql数据库。

(3)、预警：对于日志中的错误信息或分析出有问题的调用链，可以根据预设的规则，通知相关的开发和运维人员。如根据统一配置中心的配置文件信息发现日志错误，则向配置文件中预先设定的预警信息接收地址(如邮箱地址等)发送预警信息和日志错误信息。

在一个实施例中，所述分别对服务链中不同应用进群进行日志数据采集，得到对应的日志数据步骤，包括：

S11、通过业务代码调用应用集群的日志输出接口进行日志采集。

如上所述，本在实施例中，采用了代码嵌入的方式进行日志采集，调用API完成日志数据的采集过程。这样的日志采集方式操作简单，收集方便，而且可以减少业务依赖，能够针对复杂场景，侵入性强。

S12、通过代理Agent实现在不同应用集群的日志埋点，对服务调用过程切面进行拦截，捕获日志数据，完成数据采集。

如上所述，在本实施例中，通过设置拦截器来实现日志采集。这种方式是非侵入式的采集，无需侵入业务代码，使用Java Instrumention特性，实现非侵入式日志埋点，以AOP(Aspect Oriented Programming，面向切面编程)方式完成日志收集。通过自实现代理程序(agent)在类加载过程中对字节码进行转换，从而完成日志埋点逻辑的注入，实现日志数据的采集功能。非侵入日志埋点的核心还是AOP技术，通过对服务调用过程切面进行拦截，捕获相关信息，完成数据采集。具体地，代理(agent)是在main方法前的一个拦截器(interceptor)，也就是在main方法执行之前，执行agent的代码。agent的代码与main方法在同一个JVM(Java虚拟机)中运行，并被同一个system classloader装载，被同一的安全策略(security policy)和上下文(context)所管理。简单地说，Agent的作用是类加载前，先调用agent的代码，然后再正常启动其他已经存在的类，实现对业务数据无侵入的日志输出和耗时计算。

在一个实施例中，所述对所述日志数据进行格式标准化，得到标准格式的日志数据的步骤包括：

S21、根据调用链路径关系确定TraceID、SpanID、ParentID，得到日志基本属性；

S22、根据调用业务类型确定日志扩展属性；

S23、将所述日志基本属性和所述日志扩展属性按照预设的格式保存为所述标准格式的日志数据。

如上所述，本实施例中，通过内部定制的统一的日志框架，实现了标准的应用日志格式，其数据格式分为两个部分，包括基本属性和扩展属性，其中基本属性是服务调用链的必备信息，是实现日志跟踪系统的基础；扩展属性与业务结合密切，是日志跟踪系统的价值所在。

调用链路数据格式基本属性有三个：TraceID、SpanID、ParentID，它们是构建调用链的基础。TraceID是跟踪流水号，是每个调用链的主线，一个TraceID代表一次请求，在调用链入口服务请求时生成，全局唯一。TraceID作为全链共有属性，需要在服务调用过程中全程透传。通过TraceID可以关联到所有参与本次请求的服务，但仅依靠TraceID无法形成一个链，还需要SpanID。如果把调用链比喻成树的话，Span相当于树叉，一个连接节点。它有两个属性：SpanID和ParentID。SpanID是节点本身的标识ID，ParentID用于记录该节点的父节点的SpanID。如果一个节点没有ParentID，则该节点就是根节点，是调用链的入口。SpanID在每次请求时生成，在调用过程中与TraceID向下透传，每个服务都将该次请求携带的SpanID作为ParentID来记录，同时将自己生产的Span ID和TraceID也一起记录。通过TraceID即可查出所有调用记录，然后通过ParentID和SpanID可以组织起整个调用父子关系链路。

要让调用链真正发挥它的应用价值，光有基本属性是不够的，还需要扩展一些属性。如服务名称(servicename)可用用来显示节点名称，主机IP(HostIP)可以让运维人员知道服务的当前位置应用实例名(Appname)可以让运维人员知道服务所处的业务中心或环节；开始时间、结束时间、耗时、返回状态等可以让运维人员了解服务执行的效率和成败；入参、出参、调用上下文信息能让运维人员了解调用过程中的数据等，有了这些信息，调用链才能发挥出更大的价值。

更具体地，扩展属性包括：

Sampleratio：采样率；

Servicename：接口名称；

Hostip：当前主机ip；

Appname：应用实例名；

Starttime：开始时间；

Endtime：结束时间；

Elapsedtime：耗时；

Returncode：返回状态；

Responsesize：响应大小；

Inparam：入参；

Outparam：出参；

Context：调用上下文信息；

Probetype：日志类型；

BizID：业务ID；

Errmsg：异常信息等。

根据所述日志基本属性和所述日志扩展属性，可以按照预设的规则得到所述标准格式的日志数据。这里预设的规则可以是认为预先设定的，比如在日志数据的指定位置插入所述日志基本属性，将日志数据文件的名称以特定格式命名等。通过日志数据标准化，可以使运维人员能够快速识别关键节点数据，提高运维效率。

在一个实施例中，所述将所述统计分析数据存入关系数据库MySQL的步骤之后还包括：

S31、接收来自WEB端的日志查询操作指令；

S32、根据所述日志查询操作指令判断所查询的日志数据类型；

S33、根据所述日志数据类型在对应的数据库中进行日志数据查询，得到查询结果；

S34、将所述查询结果发送到WEB端进行展示。

如上所述，将日志数据分别存入不同的数据库中之后，在接收到用户在WEB端发送的日志查询操作指令时，可以对所查询的日志数据类型进行判断，并根据所述日志数据类型在对应的数据库中进行查询，将查询结果返回给用户，在WEB端进行展示。为提高安全性，可以对用户的身份进行权限认证，在通过认证后才执行查询操作以及展示操作。

在一个实施例中，所述在WEB端为日志数据提供查询接口和信息展示的步骤包括：

S341、根据业务需求，按照服务调用顺序排序进行日志展示，同一个服务调用内产生的日志进一步按时间排序；

S342、对于同一业务请求类型，将同一请求类型的不同调用链进行对比；

S343、将较长的调用链按其内部服务间的连接关系进行分段，使用预设的聚类算法对该服务调用网络图进行子图划分，使处于同一子图内的服务间连接紧密，不同子图间的服务连接稀疏。

如上所述，针对单条调用链较短的情况，如某些小型业务系统，平均业务请求调用链涉及的服务在3个以内，运维人员通常只需查看该条失败的调用链涉及各服务的详细日志即可找出故障的根源。调用链中各服务的详细日志信息包括服务自身的运行状态，如服务被调用时间戳、服务被调用时长、服务响应结果等，以及该服务所在实例的状态信息。日志展示时按照服务调用顺序排序，同一个服务调用内产生的日志可进一步按时间排序，以便运维人员直观地查看此次业务请求处理的完整过程，快速定位根源位置。

针对业务请求调用链较长或被频繁使用的业务系统，对于同一请求类型，如系统登录、订单查询、退款等业务类型，可将同一请求类型的不同调用链进行对比来辅助故障根源定位。因为同一请求类型下的所有调用链具有相同的业务逻辑，调用链所涉及的服务以及调用顺序也基本相同，故具有可比性。运维人员可选择失败的调用链与同类型的其他正常调用链进行对比，如果失败的调用链明显短于正常的调用链，且其所经过的服务包含于其他正常调用链所经过的服务，则该调用链最后调用的服务很有可能就是出现故障的根源。

针对大型业务系统，单条业务请求的服务调用可能涉及成百上千个微服务，这种情况明显不适合对单条调用链进行完整的查看分析。而且当服务调用结构复杂时，异常服务往往会形成异常传播现象，导致调用该服务的附近一片服务异常。这种情况就需要将较长的调用链按其内部服务间的连接关系进行分段(或分块)，使运维人员可以按段为单位进行分析。在微服务系统中，不同调用链的服务调用形成了服务调用网络，该网络是有向的，但在此忽略其方向性，看成无向网络，因为此处只关注其服务之间连接的紧密程度。由于处于同一子图内的服务之间调用频繁，出错的概率一般远大于两子图间的服务调用，故可使用某个聚类算法对该服务调用网络图进行子图划分，使处于同一子图内的服务间连接紧密，不同子图间的服务连接稀疏。

在一个具体的实施例中，所述预设的聚类算法为Fast-Unfolding子图划分算法，具体包括如下步骤：

S3431、将图中的每个顶点作为一个独立的子图，初始子图的数目与顶点个数相同；

S3432、对每个顶点vi，将顶点vi分配到其邻居顶点所在的子图中，并计算分配前与分配后的模块度变化ΔQ，以及记录ΔQ最大的邻居顶点，若最大ΔQ>0，则把顶点vi分配到ΔQ最大的那个邻居顶点所在的子图，否则放弃此次划分，重复此步骤，直到所有顶点的子图不再变化；

S3433、对图进行压缩，将所有在同一个子图的顶点压缩成一个新的顶点，子图内顶点之间边的权重转化为新顶点的环的权重，子图间的边权重转化为新顶点间的边权重；

S3434、重复以上步骤直到整个图的模块度不再发生变化。

如上所述，将调用链的服务调用形成的网络用图G＝(V,E)来表示，其中V＝{vi,i＝1,2,...n}表示图中顶点的集合；E＝{(u,v)|u,v∈V}则是图中边的集合，如果网络中两个顶点之间有联系，则图中对应的节点u，v之间有一条连边。考虑到子图划分的速度与精度，可采用具有线性时间复杂度的Fast-Unfolding子图划分算法，算法的步骤如上所述。

在一个具体的实施例中，所述通过Kafka中间件将所述标准格式的日志数据全量存储到Hbase数据库中的步骤之后还包括：

S35、对所述标准格式的日志数据进行错误和异常分析；

S36、若发现日志错误或日志异常，则向预设的预警信息接收地址发送预警信息。

如上所述，对于日志中的错误信息或分析出有问题的调用链，可以根据预设的规则，通知相关的开发和运维人员。如根据统一配置中心的配置文件信息发现日志错误，则向配置文件中预先设定的预警信息接收地址(如邮箱地址等)发送预警信息和日志错误信息。这样可以使运维人员没有主动查询日志数据时仍能得到日志错误或日志异常信息，提高系统的稳定性。

参照图2，本申请实施例中还提供一种基于链路追踪的服务链日志处理装置，包括：

采集模块1，用于分别对服务链中不同应用进群进行日志数据采集，得到对应的日志数据；

标准化模块2，用于对所述日志数据进行格式标准化，得到标准格式的日志数据；

Kafka模块3，用于通过Kafka中间件将所述标准格式的日志数据全量存储到Hbase数据库中；

分析处理模块4，用于对数据进行分析处理，得到检索索引数据和统计分析数据；

第一执行模块5，用于将所述检索索引类数据存入ES集群；

第二执行模块6，用于将所述统计分析数据存入关系数据库MySQL。

在一个实施例中，所述采集模块1包括：

第一采集单元，用于通过业务代码调用应用集群的日志输出接口进行日志采集。

在一个实施例中，所述采集模块1包括：

第二采集单元，用于通过代理Agent实现日志埋点，对服务调用过程切面进行拦截，捕获日志数据，完成数据采集。

在一个实施例中，所述格式标准化模块2包括：

基本属性确定单元，用于根据调用链路径关系确定TraceID、SpanID、ParentID，得到日志基本属性；

扩展属性确定单元，用于根据调用业务类型确定日志扩展属性；

执行单元，用于将所述日志基本属性和所述日志扩展属性按照预设的格式保存为所述标准格式的日志数据。

在一个实施例中，所述基于链路追踪的服务链日志处理装置还包括：

指令接收模块，用于接收来自WEB端的日志查询操作指令；

判断模块，用于根据所述日志查询操作指令判断所查询的日志数据类型；

查询模块，用于根据所述日志数据类型在对应的数据库中进行日志数据查询，得到查询结果；

展示模块，用于将所述查询结果发送到WEB端进行展示。

在一个实施例中，所述展示模块包括：

排序单元，用于根据业务需求，按照服务调用顺序排序进行日志展示，同一个服务调用内产生的日志进一步按时间排序；

对比单元，用于对于同一业务请求类型，将同一请求类型的不同调用链进行对比；

分段单元，用于将较长的调用链按其内部服务间的连接关系进行分段，使用预设的聚类算法对该服务调用网络图进行子图划分，使处于同一子图内的服务间连接紧密，不同子图间的服务连接稀疏。

错误异常分析模块，用于对所述标准格式的日志数据进行错误和异常分析；

预警模块，用于若发现日志错误或日志异常，则向预设的预警信息接收地址发送预警信息。

如上所述，可以理解地，本申请中提出的所述种基于链路追踪的服务链日志处理装置的各组成部分可以实现如上所述种基于链路追踪的服务链日志处理方法任一项的功能，具体结构不再赘述。

参照图3，本申请实施例中还提供一种计算机设备，该计算机设备可以是服务器，其内部结构可以如图3所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设计的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于储存日志数据等数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于链路追踪的服务链日志处理方法。

上述处理器执行上述的基于链路追踪的服务链日志处理方法，包括：

将所述检索索引类数据存入ES集群；

将所述统计分析数据存入关系数据库MySQL。

通过业务代码调用不同的应用集群的日志输出接口进行日志采集。

根据调用业务类型确定日志扩展属性；

接收来自WEB端的日志查询操作指令；

根据所述日志查询操作指令判断所查询的日志数据类型；

将所述查询结果发送到WEB端进行展示。

在一个实施例中，所述将所述查询结果发送到WEB端进行展示的步骤包括：

在一个实施例中，所述通过Kafka中间件将所述标准格式的日志数据全量存储到Hbase数据库中的步骤之后还包括：

对所述标准格式的日志数据进行错误和异常分析；

本申请一实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现一种基于链路追踪的服务链日志处理方法。

将所述检索索引类数据存入ES集群；

将所述统计分析数据存入关系数据库MySQL。

根据调用业务类型确定日志扩展属性；

接收来自WEB端的日志查询操作指令；

根据所述日志查询操作指令判断所查询的日志数据类型；

将所述查询结果发送到WEB端进行展示。

对所述标准格式的日志数据进行错误和异常分析；

上述执行的基于链路追踪的服务链日志处理方法，通过对日志数据进行采集和数据格式标准化，然后对日志数据进行分析处理，将不同数据类型的日志数据储存在不同的数据库中，能够使运维人员快速识别关键节点数据，根据日志数据中的参数实现服务监控，提高运维效率。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的和实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可以包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双速据率SDRAM(SSRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、装置、物品或者方法不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、装置、物品或者方法所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、装置、物品或者方法中还存在另外的相同要素。

以上所述仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims

1.一种基于链路追踪的服务链日志处理方法，其特征在于，包括：

将所述检索索引类数据存入ES集群；

将所述统计分析数据存入关系数据库MySQL。

2.根据权利要求1所述的基于链路追踪的服务链日志处理方法，其特征在于，所述分别对服务链中不同应用进群进行日志数据采集，得到对应的日志数据步骤，包括：

3.根据权利要求1所述的基于链路追踪的服务链日志处理方法，其特征在于，所述分别对服务链中不同应用进群进行日志数据采集，得到对应的日志数据步骤，包括：

4.根据权利要求1所述的基于链路追踪的服务链日志处理方法，其特征在于，所述对所述日志数据进行格式标准化，得到标准格式的日志数据的步骤包括：

根据调用业务类型确定日志扩展属性；

5.根据权利要求1所述的基于链路追踪的服务链日志处理方法，其特征在于，所述将所述统计分析数据存入关系数据库MySQL的步骤之后还包括：

接收来自WEB端的日志查询操作指令；

根据所述日志查询操作指令判断所查询的日志数据类型；

将所述查询结果发送到WEB端进行展示。

6.根据权利要求5所述的基于链路追踪的服务链日志处理方法，其特征在于，所述将所述查询结果发送到WEB端进行展示的步骤包括：

7.根据权利要求1所述的基于链路追踪的服务链日志处理方法，其特征在于，所述通过Kafka中间件将所述标准格式的日志数据全量存储到Hbase数据库中的步骤之后还包括：

对所述标准格式的日志数据进行错误和异常分析；

8.一种基于链路追踪的服务链日志处理装置，其特征在于，包括：

第一执行模块，用于将所述检索索引类数据存入ES集群；

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。