一种分布式系统的日志收集方法及系统与流程

1.本发明涉及日志处理技术领域，尤其涉及一种分布式系统的日志收集方法。


背景技术：

2.现有在大规模分布式系统中，利用日志中蕴藏的信息来改进用户体验，从海量数据中挖掘有价值的信息，针对用户建立模型提供个性化服务是非常有价值的。但是日志系统建设有各种各样的方式，存在不同层面的问题，比如性能、存储以及运维等。
3.现有的efk日志收集方案是分布式系统直接把日志写入到文件中，然后通过filebeat等日志收集工具收集，进行加工后写入到分布式搜索系统elasticsearch中存储，再通过kibana进行日志的搜索与分析。从前述流程中可以发现，系统中产生的日志文件繁多，较大的日志打开写入是很慢的过程，较小日志文件数量较多，管理困难，尤其在分布式环境下，如果节点数较多，每个节点都需要部署filebeat进行日志的收集与处理，维护这么多的节点的filebeat服务也是一个巨大的成本。


技术实现要素：

4.为了克服上述技术缺陷，本发明的目的在于提供一种分布式系统的日志收集方法及系统，解决现有分布式系统的日志收集需要将日志写入文件，并在每一节点部署采集工具，收集效率较低而成本较高的问题。
5.本发明公开了一种分布式系统的日志收集方法，应用于处理服务器端，包括：
6.采集分布式系统各服务端的事件，集成日志框架，基于预设基础库对所述日志框架进行扩展后分类，以生成日志信息；
7.将所述日志信息异步写入日志消息队列，对所述日志信息进行存储；
8.在所述日志消息队列下执行多线程消费任务；
9.当消费任务异常，根据预设提醒规则判断是否发出提醒；若是，则写入消息提醒队列，以用于发送至开发端进行提醒；
10.当消费任务正常，同步将所述日志信息批量存储于elasticsearch中，采用kibana对所述日志信息进行搜索与分析。
11.优选地，基于预设基础库对所述日志框架进行扩展后分类，以生成日志信息，包括：
12.在所述预设基础库对所述日志框架进行扩展；
13.在异步任务下对扩展后的日志框架进行分类；
14.若所述扩展后的日志框架为error级别，则执行异常重写任务；
15.否则，生成日志信息。
16.优选地，所述异常重写任务包括执行重写日志框架，或对所述扩展后的日志框架进行截取，获得日志信息。
17.优选地，基于预设基础库对所述日志框架进行扩展的内容包括：日志发生的模块、
日志发生的位置、日志所属的系统分组、日志所属的应用服务、日志部署的机器信息、日志的链路追踪traceid、日志发生的时间。
18.优选地，在写入消息提醒队列后，包括：
19.在消息提醒队列中再次执行消费，根据预设过滤规则发送消息提醒至开发端。
20.本发明还提供一种分布式系统的日志收集系统，包括：
21.应用服务模块，用于采集分布式系统各服务端的事件，集成日志框架；
22.日志基础库处理模块，用于基于预设基础库对所述日志框架进行扩展后分类，以生成日志信息；
23.消息队列模块，包括日志消息队列和消息提醒队列；将所述日志信息异步写入日志消息队列，对所述日志信息进行存储；写入消息提醒队列，用于发送至开发端进行提醒；
24.日志处理模块，用于在所述日志消息队列下执行多线程消费任务；当消费任务异常，根据预设提醒规则判断是否发出提醒；当消费任务正常，同步将所述日志信息批量存储于elasticsearch中；
25.日志应用模块，用于采用kibana对所述日志信息进行搜索与分析。
26.优选地，所述日志基础库处理模块中，对所述日志框架进行扩展的内容包括：日志发生的模块、日志发生的位置、日志所属的系统分组、日志所属的应用服务、日志部署的机器信息、日志的链路追踪traceid、日志发生的时间。
27.优选地，所述日志处理模块在所述日志信息消费任务异常写入消息提醒队列后，包括：
28.在消息提醒队列中再次执行消费，根据预设过滤规则发送消息提醒至开发端。
29.优选地，所述日志基础库处理模块基于预设基础库对所述日志框架进行扩展后分类，以生成日志信息，包括：在所述预设基础库对所述日志框架进行扩展；在异步任务下对扩展后的日志框架进行分类；若所述扩展后的日志框架为error级别，则执行异常重写任务；否则，生成日志信息。
30.优选地，所述日志基础库处理模块执行所述异常重写任务包括：执行重写日志框架，或对所述扩展后的日志框架进行截取，获得日志信息。
31.采用了上述技术方案后，与现有技术相比，具有以下有益效果：
32.本发明采集事件并集成日志框架，而后根据预设基础库扩展生成日志信息，写入日志消息队列，在日志消息队列下的多线程消费任务，在当消费任务异常，写入消息提醒队列，并在符合预提醒规则后发出提醒，当消费任务正常，则同步至elasticsearch，以用于搜索与分析，由此协同完成日志的高效收集、高效存储以及更灵活的日志处理以及日志的应用问题，无需在多个服务器节点部署采集工具，收集效率高且成本较低。
附图说明
33.图1为本发明所述一种分布式系统的日志收集方法实施例一的流程图；
34.图2为本发明所述一种分布式系统的日志收集方法实施例一中用于体现日志收集过程的整体流程；
35.图3本发明所述所述一种分布式系统的日志收集系统实施例二的程序模块示意图。
36.附图标记：6-分布式系统的日志收集系统；61-应用服务模块；62-日志基础库处理模块；63-消息队列模块；64-日志处理模块；65-日志应用模块。
具体实施方式
37.以下结合附图与具体实施例进一步阐述本发明的优点。
38.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
39.在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
40.应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在
……
时”或“当
……
时”或“响应于确定”。
41.在本发明的描述中，需要理解的是，术语“纵向”、“横向”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。
42.在本发明的描述中，除非另有规定和限定，需要说明的是，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是机械连接或电连接，也可以是两个元件内部的连通，可以是直接相连，也可以通过中间媒介间接相连，对于本领域的普通技术人员而言，可以根据具体情况理解上述术语的具体含义。
43.在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，“模块”与“部件”可以混合地使用。
44.实施例一：本实施例提供一种分布式系统的日志收集方法，以用于分布式系统场景下的日志采集，应用于处理服务器端，参阅图1和图2，包括以下步骤：
45.s100：采集分布式系统各服务端的事件，集成日志框架，基于预设基础库对所述日志框架进行扩展后分类，以生成日志信息；
46.在上述步骤中，服务端的事件可以基于服务端的控件触发产生，由于是分布式系统，包含至少两个服务端，每一服务端均在事件触发时采集数据，并直接由各个事件集合成日志框架，而无需在各个服务端生成文件，日志框架集成发生在应用服务模块中，应用服务模块集成日志时，日志的处理完全由自定义的预设基础库来处理完成。
47.上述预设基础库的主要作用就是通过扩展日志框架的基本功能，为日志信息添加
更多游戏里排查和分析的日志信息，服务产生日志时，日志的处理完全由自定义的预设基础库来处理完成。具体的，所述基于预设基础库对所述日志框架进行扩展后分类，以生成日志信息，包括以下步骤：
48.s110：在所述预设基础库对所述日志框架进行扩展；
49.需要进一步说明的是，上述基于预设基础库对所述日志框架进行扩展的内容包括但不限于：日志发生的模块、日志发生的位置、日志所属的系统分组、日志所属的应用服务、日志部署的机器信息、日志的链路追踪traceid、日志发生的时间。可以通过扩展日志框架的基本功能，为日志信息添加更多可排查和分析的日志信息。
50.s120：在异步任务下对扩展后的日志框架进行分类；
51.s130：若所述扩展后的日志框架为error级别，则执行异常重写任务；否则，生成日志信息。
52.具体的，上述步骤中，需要强调的是，该分类进程采用异步任务处理，异步处理是按照不同步的程序处理问题，产生多线程或者多进程，异步处理可以提高设备使用率，从而在宏观上提升程序运行效率。更为具体的，上述步骤中的分类主要是用于确定扩展后的日志框架是否异常，需要说明的是，此处着重筛选格式异常，例如出现超长日志等，消费异常在下属步骤s300中排查。若如前述，出现超长日志，超长日志会占用更多空间，视为异常，则确定该扩展后的日志框架为error级别，需要重写或者重新处理，若非异常，则进入到生成日志信息的流程。分类确定所有异常信息，有利于问题排查。
53.更具体的，所述异常重写任务包括执行重写日志框架，或对所述扩展后的日志框架进行截取，获得日志信息。作为举例而非限定的，以前述超长日志为例，超长的异常信息只会带来更多的空间占用，因此异常日志信息一般需要重写，把重要的部分写入日志系统即可。或者，开发人员因为认识不足或者其他原因，也可能写入超长日志，再此，也对超长日志进行适当截取，减少非必要的日志内容即可。
54.为阐述清楚仅用于作为示例的，所述日志框架的扩展具体内容可参考下表所示：
55.[0056][0057]
s200：将所述日志信息异步写入日志消息队列，对所述日志信息进行存储；
[0058]
基于上述步骤s100，日志的基本信息完善(即日志的扩展)以后，进行存储。本实施方式中的存储并未采用现有常见的直接写入日志文件的方式，主要原因在于，日志文件的拆分存在较多问题，太大的文件导致写入很慢，太小的文件带来管理困难。因此，本实施方式中使用异步写入消息队列方式来完成上述步骤中的日志存储问题。
[0059]
具体的，消息队列的特点是可以支持很高的并发量，足以支持较大规模的日志写入，且在写入的过程也是异步化的，并发效率会更高。而现有日志文件写入的方式需要每个节点都需要部署filebeat进行日志的收集与处理，维护这么多的节点的filebeat服务也是一个巨大的成本。使用的消息队列包括但不限于activemq，rabbitmq，zeromq，kafka，metamq，rocketmq。本实施方式中具体可采用kafka。
[0060]
s300：在所述日志消息队列下执行多线程消费任务；
[0061]
具体的，在上述步骤中将日志信息写入消息队列后，进入日志的处理环节。其主要工作是把消息队列中的消息消费出来，然后把消费任务正常的日志信息使用批量的方式写入到elasticsearch(es，一个基于lucene的搜索服务器)中进行存储，需要说明的是，es的存储能力扩展可以通过hbase(hbase是一个分布式的、面向列的开源数据库)来实现更大规模的日志存储，更具体的，上述消费任务包括但不限于读取、缓存、操作或定时控制逻辑等等。
[0062]
s400：当消费任务异常，根据预设提醒规则判断是否发出提醒；若是，则写入消息提醒队列，以用于发送至开发端进行提醒；
[0063]
在上述步骤中，通过自定义的代码规则，判断日志信息的处理方式是否存在异常，把异常信息再次写回到消息提醒队列，在本实施方式中，设置消息提醒队列是由于直接发送提醒可能过于频繁，且影响正常消费日志的效率，因此设置消息队列，并在下述满足预设过滤规则后才进行提醒，以更快的发现系统存在的问题。
[0064]
因此，基于前述，更进一步的，在写入消息提醒队列后，包括：
[0065]
在消息提醒队列中再次执行消费，根据预设过滤规则发送消息提醒至开发端。
[0066]
具体的，在上述步骤中，通过其他的任务再消费，即，相当于复核是否存在异常消息，根据预设过滤规则后发送到开发者群或者邮件中进行提醒，以更快的发现系统存在的问题。具体的预设过滤规则可以根据实际使用场景设置，作为举例的，如操作执行某一控制逻辑失败或触发某个响应信号等。
[0067]
s500：当消费任务正常，同步将所述日志信息批量存储于elasticsearch中，采用kibana对所述日志信息进行搜索与分析。
[0068]
在本实施方式中，收集日志信息后的最终目的在于其应用，设置日志应用中心，主要的功能是日志的搜索与日志的分析。通过开源分析软件kibana实现，kibana是用来为elasticsearch设计开发的，可以提供数据查询，数据可视化等功能，方便开发者或者数据运营者快速找到系统的问题或者挖掘日志数据的价值，由于实施方式中，在上述步骤中，消费任务正常的日志信息会存储于es中，因此采用kibana实现日志的搜索与分析，这与现有常见的efk日志方案操作基本一致，因此不作赘述。
[0069]
在本实施方式中，利用应用服务采集事件、集成日志框架、生成日志信息写入消息队列、日志处理(执行多线程消费任务)、日志应用(搜索与分析)，协同完成日志的高效收集、高效存储以及更灵活的日志处理以及日志的应用问题，从大规模分布式系统日志收集与处理出发，提高分布式系统收集效率、降低存储成本、减少非必要的系统警告、减少运维成本，提升经济效益，特别地，采集时间集成日志框架并利用消息队列异步写入，区别于现有生成日志文件的方式，解决现有分布式系统的日志收集需要将日志写入文件，并在每一节点部署采集工具，收集效率较低而成本较高的问题。
[0070]
实施例二：本实施例提供一种分布式系统的日志收集系统6，参阅图3，包括以下：
[0071]
应用服务模块61，用于采集分布式系统各服务端的事件，集成日志框架；
[0072]
具体的，每一服务端均在事件触发时采集数据，并直接由各个事件集合成日志框架，而无需在各个服务端生成文件。
[0073]
日志基础库处理模块62，用于基于预设基础库对所述日志框架进行扩展后分类，以生成日志信息；
[0074]
具体的，预设基础库的主要作用就是通过扩展日志框架的基本功能，为日志信息添加更多游戏里排查和分析的日志信息。所述日志基础库处理模块中，对所述日志框架进行扩展的内容包括：日志发生的模块、日志发生的位置、日志所属的系统分组、日志所属的应用服务、日志部署的机器信息、日志的链路追踪traceid、日志发生的时间。
[0075]
更进一步的，所述日志基础库处理模块基于预设基础库对所述日志框架进行扩展后分类，以生成日志信息，包括：在所述预设基础库对所述日志框架进行扩展；在异步任务下对扩展后的日志框架进行分类；若所述扩展后的日志框架为error级别，则执行异常重写任务；否则，生成日志信息。即，在对日志框架进行扩展后首先判断扩展后生成的日志信息是否异常，是否出现超长日志等问题，如果存在，则立刻执行重写。作为优选地，所述日志基础库处理模块执行所述异常重写任务包括：执行重写日志框架，或对所述扩展后的日志框架进行截取，获得日志信息。
[0076]
消息队列模块63，包括日志消息队列和消息提醒队列；将所述日志信息异步写入日志消息队列，对所述日志信息进行存储；写入消息提醒队列，用于发送至开发端进行提
醒；
[0077]
具体的，实施方式中使用异步写入消息队列(包括日志消息队列和消息提醒队列)方式来完成日志存储或消息提醒。
[0078]
日志处理模块64，用于在所述日志消息队列下执行多线程消费任务；当消费任务异常，根据预设提醒规则判断是否发出提醒；当消费任务正常，同步将所述日志信息批量存储于elasticsearch中；
[0079]
具体的，通过自定义的代码规则，判断日志信息的处理方式是否存在异常，把异常信息再次写回到消息提醒队列，解决直接发送提醒可能过于频繁，且影响正常消费日志的效率的问题，而非异常的日志信息则存储于es中，用于下述日志应用模块的搜索或分析。进一步的，所述日志处理模块在所述日志信息消费任务异常写入消息提醒队列后，包括：在消息提醒队列中再次执行消费，根据预设过滤规则发送消息提醒至开发端。相当于复核是否存在异常消息，根据预设过滤规则后发送到开发者群或者邮件中进行提醒，以更快的发现系统存在的问题。
[0080]
日志应用模块65，用于采用kibana对所述日志信息进行搜索与分析。
[0081]
在本实施方式中，利用应用服务模块61采集事件并集成日志框架，而后由日志基础库处理模块62根据预设基础库扩展生成日志信息，再次过程中首先排查日志信息是否异常，若异常则启动重写任务，若非异常，则在消息队列模块63下写入日志消息队列，日志处理模块64执行日志消息队列下的多线程消费任务，在当消费任务异常，写入消息队列模块63下消息提醒队列，并在符合预提醒规则后发出提醒，当消费任务正常，则同步至elasticsearch，可由日志应用模块64进行搜索与分析，由此各个模块协同完成日志的高效收集、高效存储以及更灵活的日志处理以及日志的应用问题，无需在多个服务器节点部署采集工具，收集效率高且成本较低。
[0082]
应当注意的是，本发明的实施例有较佳的实施性，且并非对本发明作任何形式的限制，任何熟悉该领域的技术人员可能利用上述揭示的技术内容变更或修饰为等同的有效实施例，但凡未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何修改或等同变化及修饰，均仍属于本发明技术方案的范围内。