CN112181931A - 一种大数据系统链路追踪方法及电子设备 - Google Patents

Abstract

本申请提供一种大数据系统链路追踪方法及电子设备，大数据系统链路包括请求响应链路和数据流链路，方法包括：系统埋点，在大数据系统中埋点，当用户在大数据系统上进行操作，产生的用户请求或数据流经过埋点时，生成日志文件；日志采集，监听日志文件，当日志文件发生变化时，将日志文件的变化增量传输到日志存储模块；日志存储，日志存储模块对日志文件添加索引；链路查询，搜索输入的关键词，获得关键词对应的索引，得到查询结果；链路分析，分析查询结果，并判断链路异常中断的位置。根据本申请实施例大数据系统链路追踪方法及电子设备，当大数据系统出现用户调用失败或数据丢失时，能够高效、快速定位大数据系统故障的位置，缩减了排查故障的时间。

Description

一种大数据系统链路追踪方法及电子设备

技术领域

本申请涉及大数据领域，具体涉及一种大数据系统链路追踪方法及电子设备。

背景技术

随着互联网日益增长的业务量，城市级密集数据是非常常见的。为了适应庞大的业务量，必须依赖于复杂分布式系统。在复杂分布式系统中，当一个请求经过了多个服务后出现了调用失败的问题，最终收到的报错信息难以定位到具体出问题，排查是非常耗时且低效的，同时一个海量数据系统的数据也会经过多层处理形成一个漫长的数据流链路，当出现数据损耗以及丢失时我们也需要及时地定位到造成数据丢失的处理过程及模块，复杂系统中的故障定位既耗时又耗费人力。

在城市级密集型分布式海量数据应用中，对于请求的响应链路而言，当一个请求经过了多个服务后，如果发生故障，无法高效直接地定位到发生故障的地方，而且人工直接定位往往过程繁琐，会浪费大量的人力和时间；对于数据流链路而言，数据会经历数据采集、特征抽取、实时处理、离线处理、基础检索、高级应用等模块的处理，形成一个长数据流链路，可能会由于某些模块本身的不稳定性造成数据损耗、丢失、抖动，一方面人工无法实时感知数据丢失，另一方面当数据发生丢失时人工定位问题也需要逐一排查。

发明内容

有鉴于此，本申请提供一种大数据系统链路追踪方法，能够将大数据系统里的用户分布式请求和数据流处理还原成调用链路，当大数据系统出现用户调用失败或数据丢失时，通过本申请实施例的一种大数据系统链路追踪方法可以高效、快速定位链路故障的位置，大大缩减了排查故障的时间，节约了大数据流链路的维护时间。

为解决上述技术问题，本申请采用以下技术方案：

第一方面，本申请提供一种大数据系统链路追踪方法，大数据系统链路包括请求响应链路和数据流链路，方法包括：

系统埋点，在大数据系统中埋点，当用户在大数据系统上进行操作，产生的用户请求或数据流处理经过埋点时，将所述用户请求信息或数据流信息写入日志文件；

日志采集，监听日志文件，当日志文件发生变化时，将日志文件的变化增量传输到日志存储模块；

日志存储，日志存储模块对日志文件添加索引，其中，索引覆盖日志文件的所有字段；

链路查询，搜索输入的关键词，获得关键词对应的索引，得到链路查询结果；

链路分析，分析链路查询结果，并判断链路异常中断的位置。

作为本申请的第一方面的一个实施例，系统埋点是后端埋点。

作为本申请的第一方面的一个实施例，用户请求或数据流经过系统埋点生成日志文件具体包括：

针对请求响应链路，获取请求响应链路中的用户请求，并分配唯一标识的请求ID；将用户请求及对应的请求ID输出到日志文件中存储；请求ID依次递增；

针对数据流链路，给每一条数据分配唯一标识的数据ID，获取数据处理步骤；将数据处理步骤及对应的数据ID输出到日志文件中存储；数据ID依次递增。

作为本申请的第一方面的一个实施例，日志存储，进一步包括：

将日志文件的每一个字段编入索引；

当索引的数据量大于阈值时，将该索引上的数据水平拆分成分片，分片用于存储一个或多个个单个字段数据的索引。

作为本申请的第一方面的一个实施例，分片分布在多台服务器上，且分片对应设有副本分片，分片与对应的副本分片分布在不同的服务器上。

作为本申请的第一方面的一个实施例，链路查询将关键字广播到索引的每一个分片中进行查询。

作为本申请的第一方面的一个实施例，与请求响应链路和数据流链路分别对应的链路查询结果，具体包括：

通过对请求ID过滤，并得到与该请求ID对应的完整的请求响应链路的日志文件；

通过对数据ID过滤，并得到与该数据ID对应的数据处理步骤对应的日志文件。

作为本申请的第一方面的一个实施例，日志模块设有分布式搜索引擎，分布式搜索引擎是ElasticSearch、SenseiDB、Conclusion、或Solr中任一个。

作为本申请的第一方面的一个实施例，日志文件采用Json数据格式。

作为本申请的第一方面的一个实施例，方法还包括：

可视化显示链路分析结果，和/或发出语音警报。

第二方面，本申请实施例提供了一种电子设备，包括处理器和存储器，

存储器中存储有指令，

处理器，用于读取存储器中存储的指令，以执行上述一种大数据系统链路追踪方法的方法。

本申请的上述技术方案至少具有如下有益效果之一：

根据本申请实施例的大数据系统链路追踪方法及电子设备，能够将大数据系统里的用户分布式请求和数据流处理还原成调用链路，当大数据系统出现用户调用失败或数据丢失时，通过本申请实施例的一种大数据系统链路追踪方法可以高效、快速定位链路故障的位置，大大缩减了排查故障的时间，节约了大数据流链路的维护时间。

附图说明

图1a为本申请实施例的大数据系统用户请求链路的示意图；

图1b为本申请实施例的大数据系统数据流链路的示意图；

图2为本申请实施例的大数据系统链路追踪方法的流程图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面结合具体的场景对本申请实施例进行说明。

图1a是根据本申请一个实施例的大数据系统的用户请求链路示意图。该链路可以应用于大数据系统中，如图1a所示，用户与大数据系统进行交互。例如，购物相关的大数据系统，用户通过前端登录购物系统，其中，前端载体可以是PC端或移动端，前端可以是网站或应用程序。用户在前端搜索内容，浏览页面，观看视频，购买商品，收藏，评论等等操作生成前端请求，每一个前端请求都发送到后端服务器进行处理。本申请实施例在大数据系统的后端服务器的各个服务接口埋点，来获取用户每一个请求的全部处理步骤和顺序。如，用户浏览网页页面，可以在Web端使用js采集页面信息，然后向日志服务器特定URL发起一次http请求，将js采集到的页面信息作为参数传递给服务器，服务器响应请求，记录页面信息生成日志文件。在本申请实施例中，为了减少埋点对业务代码的侵入并保障埋点的全覆盖，在服务器后端埋点通过模版将脚本嵌入到每一个页面。埋点覆盖所有服务器端的服务，且服务参与的顺序也会记录，将这些内容保存到日志文件，从而达到用户的每个请求的步骤清晰溯源，用户请求链路出了问题，能够快速定位链路故障位置。

图1b是根据本申请一个实施例大数据系统的数据流链路图。如图1b所示，当用户与大数据系统进行交互时，会产生一系列的数据计算处理，数据会经历数据采集、特征抽取、实时处理、离线处理、基础检索、高级应用等模块的处理，形成一个长数据流链路，将数据经过每个模块的详细信息保存到日志文件，从而达到数据的每个处理的步骤清晰溯源，当数据流链路出了问题，能够快速定位链路故障位置。

下面结合附图对本申请的大数据系统链路追踪方法进行描述，图2示出了大数据系统链路追踪方法的流程图，大数据系统链路包括请求响应链路和数据流链路，如图2所示，该方法包括：

步骤S210，系统埋点，在大数据系统中埋点，当用户在大数据系统上进行操作，产生的用户请求或数据流处理经过埋点时，生成日志文件，并将用户请求信息增量写入该日志文件中。也就是说，埋点是在用户和大数据系统之间进行交互时，记录下来的数据，并保存至日志文件，为后续做日志监听使用。根据需要用户请求的分类，对应在大数据系统的一些调用接口的地方进行埋点，由此，可以得到用户请求相关的数据并保存至日志文件。

在本申请的一些实施例中，用户请求和数据流处理经过系统埋点生成日志文件具体包括：

针对请求响应链路，获取请求响应链路中的用户请求，并分配唯一标识的请求ID；将用户请求及对应的请求ID输出到日志文件中存储。

针对数据流链路，给每一条数据分配唯一标识的数据ID，获取数据处理步骤；将数据处理步骤及对应的数据ID输出到日志文件中存储。

在本申请的一些实施例中，链路调用中的请求ID和数据ID可以分配多个字节，例如，请求ID使用一个4个字节，共64位字符串标识，也就是说，请求ID或数据ID，拥有较大的存储空间，可以包含更多的信息，例如该请求记录的时间戳，链路来源等信息。

步骤S220，日志采集，监听日志文件，当日志文件发生变化时，将日志文件的变化增量传输到日志存储模块。在实际应用中，可以通过日志采集器进行日志采集，通常选用的日志采集器有Logstash、Fluentd、Logtail、Agent几种，在本申请实施例中，用Agent举例说明。在采集日志的服务器上安装Agent后，在Agent管理页面配置日志采集项，用于指定Agent采集服务器上的哪些日志文件，其中，Agent可采集文件、目录、Syslog、脚本、性能数据、数据库数据等共8种数据源。还可以进一步地配置日志存储路径、日志换行格式等，最终，Agent采集的数据会生成规律的结构化的字段，即日志文件，日志文件通常要包含请求编号ID、请求的开始时间，通讯协议类型、调用方ip和端口号，请求的服务名、调用耗时，调用结果，异常信息等，同时预留可扩展字段，为下一步请求扩展日志文件做准备。采集得到的日志文件便于本申请实施例大数据系统链路追踪方法的后续数据处理。

步骤S230，日志存储，日志存储模块对日志文件添加索引，其中，索引覆盖日志文件的所有字段。在本申请实施例中，采用分布式日志存储模块来存储和管理日志文件。在分布式日志存储模块中对日志文件添加索引，将日志的每一个字段都编入索引，使其可以被搜索。

在本申请的一些实施例中，日志存储，进一步包括将日志文件的每一个字段编入索引，当索引的数据量大于阈值时，将该索引上的数据水平拆分成分片，分片用于存储一个或多个个单个字段数据的索引。在实际应用中，大数据系统的业务达到百万级用户规模以后，通过进行合理的数据拆分，可以有效解决日志存储的性能、可伸缩等问题。

在本申请的一些实施例中，采用水平切分的方式将将一个索引上的数据拆分出来分配到不同的分片中。其中，水平切分是按照预设的规则，将一个索引的数据分散到多个物理独立的数据库服务器中，这些多个分片组成一个逻辑完整的日志文件存储实例。

在本申请的一些实施例中，分片分布在多台服务器上，且分片对应设有副本分片，分片与对应的副本分片分布在不同的服务器上。其中，分片和副本分片都可以通过索引被搜索到，提高了链路查询效率。

步骤S240，链路查询，搜索关键词，获得关键词对应的索引，得到链路查询结果。由此，搜索关键词，分别与索引匹配，当匹配一致，即能够得到该索引对应的日志文件。其中，关键词一般选择请求ID或者数据ID，通常日志文件还包括时间戳，在本申请的一些实施例中，也可以通过时间戳将对应的日志文件排序。

在本申请的一些实施例中，链路查询将关键字广播到索引的每一个分片中进行查询。也就是说，由于日志存储采取的分片策略，分布式搜索引擎会将对日志文件的查询广播到索引中的每一个分片中，这样，每台机器上的分片直接可以分布式的并行对一部分数据进行搜索，起到一个分布式搜索的效果，由此，大幅度提升海量数据的搜索性能和吞吐量。

在本申请的一些实施例中，与请求响应链路和数据流链路分别对应的链路查询结果，具体包括：通过对请求ID过滤，并得到与该请求ID对应的完整的请求响应链路的日志文件。通过对数据ID过滤，并得到与该数据ID对应的数据处理步骤对应的日志文件。最终链路查询得到的结果，会将同一条调用链路的日志文件汇总在一起。由此，后续步骤链路分析可以全面分析请求响应链路和数据流链路的调用情况。

步骤S250，链路分析，分析链路查询结果，并判断链路异常中断的位置。由此，能够将大数据系统里的用户分布式请求和数据流处理还原成调用链路，当大数据系统出现用户调用失败或数据丢失时，通过本申请实施例的一种大数据系统链路追踪方法可以高效、快速定位链路故障的位置，大大缩减了排查故障的时间，节约了大数据流链路的维护时间。

在本申请的一些实施例中，系统埋点是后端埋点。其中，后端埋点能实时采集数据，不存在延时上报，数据很准确。并且，后端埋点支持与用户身份信息和用户请求信息整合，另外，当上线新的埋点或者更新埋点时，埋点发布后马上生效，可以即时采集用户请求和数据流的数据。

在本申请的一些实施例中，日志模块设有分布式搜索引擎，分布式搜索引擎是ElasticSearch、SenseiDB、Conclusion、或Solr中任一个。其中，在本申请实施例中，选择Elasticsearch分布式搜索引擎，可以扩展到上百台服务器，处理PB级数据。

在本申请的一些实施例中，日志文件采用Json数据格式。Json数据格式支持多种编程语言，且数据结构简单便于解析。若接收的数据不是json格式的数据，可以通过解析，将关键信息解析到json字段里面。在本申请的一些实施例中，方法还包括可视化显示链路分析结果，例如，可以在页面中直接显示异常，或者发送异常提醒邮件。还可以语音的方式发出警报，或者是可视化和语音结合的方式发出警报，例如，在页面中直接显示异常，同时发出语音警报。对此，本申请并不作为限定。也此外，也可以将链路查询的返回内容对接上可视化系统，针对不同的场景需求进行可视化分析。对于请求响应的链路，将对应的日志内容展示出来并根据需要进行字段的过滤，以供快速排查请求响应的链路的故障。对于数据流链路，将异常的数据信息及时报警，达到一个实时监控整条数据流链路的状态。由此，能够直观迅速地帮助用户排查链路的故障，节约维护大数据系统的时间。

本申请还提供一种电子设备，包括处理器和存储器，

存储器中存储有指令，处理器用于读取存储器中存储的指令，以执行上述大数据系统链路追踪方法中任一项步骤。

由此，本申请实施例的大数据系统链路追踪方法及电子设备，能够将大数据系统里的用户分布式请求和数据流处理还原成调用链路，当大数据系统出现用户调用失败或数据丢失时，通过本申请实施例的一种大数据系统链路追踪方法可以高效、快速定位链路故障的位置，并且可以可视化显示故障位置，简洁清晰，大大缩减了排查故障的时间，节约了大数据流链路的维护时间。

需要说明的是，在本专利的示例和说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请所述原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种大数据系统链路追踪方法，其特征在于，所述大数据系统链路包括请求响应链路和数据流链路，所述方法包括：

系统埋点，在所述大数据系统中埋点，当用户在所述大数据系统上进行操作，产生的用户请求或数据流经过所述埋点时，将所述用户请求信息或数据流信息写入日志文件；

日志采集，监听所述日志文件，当所述日志文件发生变化时，将所述日志文件的变化增量传输到日志存储模块；

日志存储，所述日志存储模块对所述日志文件添加索引，其中，所述索引覆盖所述日志文件的所有字段；

链路查询，搜索输入的关键词，获得所述关键词对应的所述索引，得到链路查询结果；

链路分析，分析所述链路查询结果，并判断所述链路异常中断的位置。

2.根据权利要求1所述的方法，其特征在于，所述系统埋点是后端埋点。

3.根据权利要求2所述的方法，其特征在于，所述用户请求和所述数据流经过所述系统埋点生成所述日志文件具体包括：

针对所述请求响应链路，获取所述请求响应链路中的用户请求，并分配唯一标识的请求ID；将所述用户请求及对应的所述请求ID输出到日志文件中存储；

针对所述数据流链路，给每一条数据分配唯一标识的数据ID，获取数据处理步骤；将数据处理步骤及对应的所述数据ID输出到日志文件中存储。

4.根据权利要求1所述的方法，其特征在于，所述日志存储，进一步包括：

将所述日志文件的每一个字段编入索引；

当所述索引的数据量大于阈值时，将该索引上的数据水平拆分成分片，所述分片用于存储一个或多个单个字段数据的索引。

5.根据权利要求4所述的方法，其特征在于，所述分片分布在多台服务器上，且所述分片对应设有副本分片，所述分片与对应的所述副本分片分布在不同的服务器上。

6.根据权利要求1或5所述的方法，其特征在于，所述链路查询将所述关键字广播到所述索引的每一个分片中进行查询。

7.根据权利要求1所述的方法，其特征在于，与所述请求响应链路和所述数据流链路分别对应的所述链路查询结果，具体包括：

通过对所述请求ID过滤，并得到与该请求ID对应的完整的请求响应链路的所述日志文件；

通过对所述数据ID过滤，并得到与该数据ID对应的所述数据处理步骤对应的所述日志文件。

8.根据权利要求1所述的方法，其特征在于，所述日志模块设有分布式搜索引擎，所述分布式搜索引擎是ElasticSearch、SenseiDB、Conclusion、或Solr中任一个。

9.根据权利要求1所述的方法，其特征在于，方法还包括：

可视化显示所述链路分析结果，和/或发出语音警报。

10.一种电子设备，其特征在于，包括处理器和存储器，

所述存储器中存储有指令，

所述处理器，用于读取所述存储器中存储的所述指令，以执行权利要求1-9任一项所述的方法。

Images