CN109359094A - 一种分布式***日志全链路追踪方法及装置 - Google Patents

Abstract

本发明涉及一种分布式***日志全链路追踪方法及装置。所述方法包括：S1，创建配置文件配置***，按以下流程执行：配置集群服务器；配置集群依赖关系；配置数据逻辑关系；S2，通过应用程序读取并解析配置文件获取关键信息；S3，根据关键信息获取***数据的生命历程。所述装置包括***配置单元，信息获取单元和集群遍历单元。把数据日志全链路追踪抽象成三个配置文件，通过相应应用程序读取并解析这些配置文件即可获取每个集群对应的服务器信息、***的上下游顺序和***数据间逻辑关系这些关键信息，可以实现在无代码埋点，一键式获取一条***数据的生命历程，并定位线上或者测试过程中遇到的问题。

Description

一种分布式***日志全链路追踪方法及装置

技术领域

本发明涉及日志追踪***领域，尤其涉及一种分布式***日志全链路追踪方法及装置。

背景技术

现在的互联网公司有着大量的分布式服务器，每一个请求路由过来后，会经过多个业务***并留下足迹，并产生许多DB的访问，但是这些分散的数据位于不同的服务器，由不同的开发组管理，对于问题排查，或是流程优化都帮助有限。一旦线上出现问题，就会出现所有涉及到的开发组加入到问题排查的队列，浪费宝贵的开发资源。如果有一套***能准确定位到问题发生的时间，地点，将大大提高问题的解决效率，缩短线上问题的影响时间。追踪每个请求的完整调用链路，收集调用链路上每个服务的业务数据，定位数据发生异常的原因，也成为各个公司迫切需求。

当前众多公司使用ELK搭建日志管理平台，ELK包括ElasticSearch(数据存储、快速查询)、logstash(日志搜集)、kibana(展示ElasticSearch数据的图形界面)。kibana是一个图形界面，可以在上面条件检索存储在ElasticSearch(ES)里的数据，相当于提供了ES的可视化操作管理器。

目前有基于Elasticsearch搭建的日志追踪***，其中需要用到日志传输工具，目前可用的传输工具有：Logstash、Filebeat、Fluentd、rsyslog、syslog-ng以及Logagent。基于logstash+Elasticsearch+kibana组合的日志分析***。针对logstash，需要配置的包括：1、数据源2、定义数据格式3、输出配置(输出到elasticsearch)。以上配置将保存到logstash.conf，然后运行logstash，可以看到logstash可以自动查询IP的归属地，并将请求里面的device字段进行分析。针对Elasticsearch和kibana，所需要的配置有：1、Elasticsearch使用默认配置，配置名称为config/elasticsearch.yml。其中Elasticsearch默认监听在9200端口，可对其进行查询和管理。2、Kibana也不需要特殊配置，默认监听在5601端口。

Logstash的主要优点在于其灵活的配置，拥有多种可定制插件，比如：输入、过滤器、输出、从而可以获取丰富的数据并将其发送至目标进行存储。但同时logstash的劣势也非常明显，主要体现在一不能将跨***数据相关联，二是不能定制一键查询，三是性能及资源消耗问题，在大数据量的时候速度会比较慢。所以在选用logstash的时候，需要考虑到服务器的性能。如果服务器性能比较差的时候，此时就需要一个轻量级的日志传输工具替代logstash。

经过上述的分析知，日志管理***能够实现对不同服务日志的查询和记录，但不能快速和方便的获取加工和流转在各个***的数据。

在代码中埋点，为流入下个***的数据创建一个唯一的id的方案也能实现全链路的日志查询，但是该方案需要投入更多的人力物力，修改原有的代码，既影响***的性能又有可能给***引入新的问题。

发明内容

为了解决上述问题，本发明的目的在于提供一种分布式***日志全链路追踪方法及装置。把数据日志全链路追踪抽象成三个配置文件，即集群服务器配置，集群依赖关系配置和数据逻辑关系配置，通过相应应用程序读取并解析这些配置文件即可获取每个集群对应的服务器信息、***的上下游顺序和***数据间逻辑关系这些关键信息，根据以上的关键信息，可以实现在无代码埋点，最大程度减少开发、测试人员的介入，一键式获取一条***数据的生命历程，并定位线上或者测试过程中遇到的问题。

为了实现上述的目的，本申请实施例是这样实现的：

本申请实施例提供的一种分布式***日志全链路追踪方法，包括：

S1，创建配置文件配置***，按以下流程执行：

配置集群服务器；

配置集群依赖关系；

配置数据逻辑关系；

S2，通过应用程序读取并解析配置文件获取关键信息；

S3，根据关键信息获取***数据的生命历程。

作为优选技术方案，所述配置集群服务器，包括：

定义每组集群服务器的唯一标识；

在每组集群服务器下增减服务器。

作为优选技术方案，所述配置集群依赖关系，包括：

定义上游集群服务器和下游集群服务器；

建立上游集群服务器和下游集群服务器之间的对应关系。

作为优选技术方案，一个上游集群服务器可以对应一个或多个下游集群服务器。

作为优选技术方案，所述配置数据逻辑关系，包括：

定义数据线标志；

配置每条数据线下有数据变化的服务器从上游集群服务器和/或下游集群服务器获取数据的规则；

其中，所述规则包括数据的转移规则和数据的加工规则。

作为优选技术方案，所述S2中的关键信息包括：每个集群对应的服务器信息、每组集群服务器的上下游顺序和***数据间的逻辑关系。

作为优选技术方案，所述S3包括：

S31，给出一个***数据；

S32，以所述关键信息作为查询条件遍历集群服务器配置文件中对应的集群服务器；

S33，输出所述***数据所在的数据线。

作为优选技术方案，所述S32按以下流程执行：

以S2中得到的关键数据以及S31中给出的***数据作为函数参数编写函数方法，遍历所有服务器，查询到与S1中的***数据相关的事务；

根据集群依赖关系配置文件查询到上下游集群服务器，分两条支路遍历***中的其余集群服务器，一条支路向上游逐个查找，另一条分支向下游逐个查找；在查找上游或下游集群服务器时，需要读取数据逻辑关系配置文件获取当前与上游或下游集群服务器之间的数据转换关系。

作为优选技术方案，S2中，遍历到警告信息或错误信息后，跳出遍历。

本申请实施例提供的一种分布式***日志全链路追踪装置，包括：

***配置单元，用于创建配置文件配置***，所述配置文件包括集群服务器配置、集群依赖关系配置和数据逻辑关系配置；

信息获取单元，用于通过应用程序读取并解析配置文件获取关键信息；

集群遍历单元，用于输入***数据，根据关键信息获取该***数据的生命历程。

本发明的优点在于：

1.本方案是一套完整的对关键数据日志全链路进行查询的方案，可以给出数据经过各集群服务器留下的信息，警告和错误等。

2.本方案应用简单，不需在原有***代码进行埋点，不需要开发人员投入大量的人力物力。

3.本方案操作简单，可以一键式定位线上或者测试过程中遇到的问题，定位问题节省的时间也是与集群的数量成正比。如果有五个***，将节省4/5的日志查询时间。

附图说明

图1为本发明中方法的流程图。

图2为本发明方法中S3的流程图。

图3为本发明实施例的***架构图。

图4为本发明执行S3的示意图。

图5为本发明装置的功能模块框图。

具体实施方式

下面结合附图对本专利的优选实施方案作进一步详细的说明。

如图1所示为一种分布式***日志全链路追踪方法的一种实现方式，该方法包括：

S1，创建配置文件配置***，按以下流程执行：

配置集群服务器；

配置集群依赖关系；

配置数据逻辑关系。

其中，配置集群服务器包括，定义每组集群服务器的唯一标识；在每组集群服务器下增减服务器。

例如，使用xml生成集群服务器配置文件，集群服务器配置文件的扩展名是.clusters，集群服务器配置文件xml节点如下：父节点为clusters，子节点cluseter里包含id和servers。id是该集群服务器的唯一标识，不可重复，一个集群服务器只有一个id。增减服务器在servers节点下操作即可。例如，使用SystemA和SystemB作为id来标志两组集群服务器，SystemA下关联有IP为192.168.1.1和192.168.1.2的两台服务器，上述SystemA和SystemB在子节点cluseter下定义，增加IP为192.168.1.1和192.168.1.2的两台服务器的操作在servers下定义。

其中，配置集群服务器包括，定义上游集群服务器和下游集群服务器；建立上游集群服务器和下游集群服务器之间的对应关系。一个上游集群服务器可以对应一个或多个下游集群服务器。

例如，使用xml生成集群依赖关系配置文件，集群依赖关系配置文件的扩展名是.relations，集群依赖关系配置文件xml节点如下：父节点为relations，子节点relation里包含upstream和downstream。使用upstream节点定义上游集群服务器，使用downstream节点定义下游集群服务器，upstream和downstream的值必须是集群服务器配置文件已经存在的id。例如，在一个relation节点下定义SystemA和SystemB的上下游关系，其中，SystemA在upstream节点下定义，SystemB在downstream节点下定义，则可知SystemA是SystemB的上游。在另一个relation节点下定义SystemB和SystemC的上下游关系，其中，SystemB在upstream节点下定义，SystemB在downstream节点下定义，则可知SystemB是SystemC的上游。按上述方式可以定义任何两个集群服务器间的上下游关系。另外，一个上游集群服务器也可以对应多个下游集群服务器，例如，在一个relation节点下定义SystemA、SystemB和SystemC的上下游关系，其中，SystemA在upstream节点下定义，SystemB和SystemC在downstream节点下定义，则可知SystemA是SystemB和SystemC的上游。其中，SystemA、SystemB和SystemC均是集群服务器配置文件中定义的id。

其中，配置数据逻辑关系包括定义数据线标志；配置每条数据线下有数据变化的服务器从上游集群服务器和/或下游集群服务器获取数据的规则；如图3所示，所述规则包括数据的转移规则和数据的加工规则。

例如，使用xml生成数据逻辑关系配置文件，数据逻辑关系配置文件的扩展名是.logics。默认所有数据是没有转换关系的，即一条数据在所有集群服务器中的形态和值都是一样。当在某个集群服务器中被加工或转移后我们需要配置.logics文件。数据逻辑关系配置文件xml节点如下：该文件父节点为logics，子节点logic里包含businessId和transfer。一个businessId代表一条数据线，多条数据线要配置多个logic。在Transfer节点下需要列出该***数据的变化方式，有数据变化的集群需要给出从上游和下游获取数据的方式，其中，从上游获取数据的方式在fromUpStream节点下定义，从上游获取数据的方式在fromDownStream节点下定义，这样不论给出哪个集群中的数据我们都可以得到该集群上游或者下游的数据。有些数据在传递过程中是不会发生变化的，或者是该数据位于一条数据线上的发起集群和结束集群，因此在一个Transfer节点下，fromUpStream和fromDownStream可以只出现一个。Transfer节点是数据上下游逻辑的具体实施，它定义了由当前节点的数据如何查询到父***(fromUpStream)和子***(fromDownStream)的数据。譬如说，父***的数据在数据库中储存，可以根据当前***的数据查询出来的，我们可以使用语句SELECT Id_A FROM SystemA WHERE Id_B＝Value_B。查询出来的Id_A就是我们***A对应的数据，也是Value_B的上游数据。同理，我们也可以查询到下游对应Id_C。当然此处应该是支持多种数据形式的，如果只是简单的数学计算，那么我们列出公式即可。假如上游id除以2得到下游id，我们可以直接写成<fromUpStream>SystemA/2</fromUpStream>。这些配置会让程序去解析采用何种数据形式。

S2，通过应用程序读取并解析配置文件获取关键信息。

有了上述创建的配置文件，就可以新建java或其他类型的应用程序，读取并解析这些配置文件。我们将得到如下信息：每组集群对应的服务器信息、每组集群服务器的上下游顺序和***数据间的逻辑关系。

S3，根据关键信息获取***数据的生命历程。

所述数据的生命历程指的是数据在整个生命周期内的流动：从创建和初始存储，到它过时被删除。

如图2和图4所示，S3包括：

S31，给出一个***数据，例如SystemC中的数据C。例如，通过webUI选择***名称，业务关键字名称(譬如buisinessId)，值(譬如：P123456)。

S32，以所述关键信息作为查询条件遍历集群服务器配置文件中对应的集群服务器。所述S32按以下流程执行：

以S2中得到的关键数据以及S31中给出的***数据作为函数参数编写函数方法，遍历所有服务器，查询到与S1中的***数据相关的事务、警告信息或错误信息后，跳出遍历；一旦检测到警告信息或错误信息，打印出当前***名称，机器名称和具体的警告或错误日志。

根据集群依赖关系配置文件查询到上下游集群服务器，分两条支路遍历***中的其余集群服务器，一条支路向上游逐个查找，另一条分支向下游逐个查找；在查找上游或下游集群服务器时，需要读取数据逻辑关系配置文件获取当前与上游或下游集群服务器之间的数据转换关系。

S33，输出所述***数据所在的数据线。

以java应用程序为例对S3的具体执行方式进行说明：

设计一个带三个参数的方法，譬如queryDataFlow(String systemId，StringbusinessId，String value)。

根据systemId得到.clusers文件中对应服务器，编写函数方法遍历进入所有服务器，查询到与该数据相关联的info，警告和错误后，跳出遍历。businessId在查询上下游***关系会作为条件。

根据.relations查询到上下游***，分两条支路去遍历剩下的集群。一条分支向上游逐个查找，另一条分支向下游逐个查找。

在查找上游(或下游)集群时要读取.logics配置文件，获取当前和上游(或下游)集群之间的数据转换关系，如果该关系能从数据库中体现，可以利用数据库查询转换后的数据，然后到上游(或下游)集群中查询转换后数据相关联的info，警告和错误；如果该关系由特定的算法计算得到，则只需要在我们的程序代码中添加该算法对应的方法，然后调用该方法来获取转换后的数据。

如图5所示的一种分布式***日志全链路追踪，所示装置包括：

***配置单元51，用于创建配置文件配置***，所述配置文件包括集群服务器配置、集群依赖关系配置和数据逻辑关系配置；

信息获取单元52，用于通过应用程序读取并解析配置文件获取关键信息；

集群遍历单元53，用于输入***数据，根据关键信息获取该***数据的生命历程。

Claims (10)

1.一种分布式***日志全链路追踪方法，其特征在于，包括：

S1，创建配置文件配置***，按以下流程执行：

配置集群服务器；

配置集群依赖关系；

配置数据逻辑关系；

S2，通过应用程序读取并解析配置文件获取关键信息；

S3，根据关键信息获取***数据的生命历程。

2.根据权利要求1所述的一种分布式***日志全链路追踪方法，其特征在于，所述配置集群服务器，包括：

定义每组集群服务器的唯一标识；

在每组集群服务器下增减服务器。

3.根据权利要求1所述的一种分布式***日志全链路追踪方法，其特征在于，所述配置集群依赖关系，包括：

定义上游集群服务器和下游集群服务器；

建立上游集群服务器和下游集群服务器之间的对应关系。

4.根据权利要求3所述的一种分布式***日志全链路追踪方法，其特征在于，一个上游集群服务器可以对应一个或多个下游集群服务器。

5.根据权利要求1所述的一种分布式***日志全链路追踪方法，其特征在于，所述配置数据逻辑关系，包括：

定义数据线标志；

配置每条数据线下有数据变化的服务器从上游集群服务器和/或下游集群服务器获取数据的规则；

其中，所述规则包括数据的转移规则和数据的加工规则。

6.根据权利要求1所述的一种分布式***日志全链路追踪方法，其特征在于，所述S2中的关键信息包括：每组集群对应的服务器信息、每组集群服务器的上下游顺序和***数据间的逻辑关系。

7.根据权利要求1所述的一种分布式***日志全链路追踪方法，其特征在于，所述S3包括：S31，给出一个***数据；

S32，以所述关键信息作为查询条件遍历集群服务器配置文件中对应的集群服务器；

S33，输出所述***数据所在的数据线。

8.根据权利要求7所述的一种分布式***日志全链路追踪方法，其特征在于，所述S32按以下流程执行：

以S2中得到的关键数据以及S31中给出的***数据作为函数参数编写函数方法，遍历所有服务器，查询到与S1中的***数据相关的事务；

根据集群依赖关系配置文件查询到上下游集群服务器，分两条支路遍历***中的其余集群服务器，一条支路向上游逐个查找，另一条分支向下游逐个查找；在查找上游或下游集群服务器时，需要读取数据逻辑关系配置文件获取当前与上游或下游集群服务器之间的数据转换关系。

9.根据权利要求7所述的一种分布式***日志全链路追踪方法，其特征在于，S3中，遍历到警告信息或错误信息后，跳出遍历。

10.一种分布式***日志全链路追踪装置，其特征在于，包括：

***配置单元，用于创建配置文件配置***，所述配置文件包括集群服务器配置、集群依赖关系配置和数据逻辑关系配置；

信息获取单元，用于通过应用程序读取并解析配置文件获取关键信息；

集群遍历单元，用于输入***数据，根据关键信息获取该***数据的生命历程。