CN109542733B - 一种高可靠的实时日志收集及可视化检索方法 - Google Patents

Abstract

高可靠的实时日志收集及可视化检索方法，1)设置实时日志收集架构，设有实时日志收集，日志数据加密传输，日志数据完整性检查，缺失告警，检查结果可视化系统架构；在目标日志服务器上部署Flume客户端及自定义Flume插件、Kafka集群、HDFS分布式文件系统；通过配置Flume配置文件，进行多线程的目标日志读取，并将读取的数据传输至Kafka集群；Kafka集群通过创建的分区与Kafka集群的Topic归类进行日志数据的缓存；2)日志数据完整性检查流程与算法步骤：通过自定义Flume插件在传输日志数据时，对已收集的日志文件发送检查消息，使Storm集群在对落地日志数据时，对HDFS存储的日志数据进行完整性检查；3)切片日志文件删除与缺失数据重传流程与算法步骤。

Description

一种高可靠的实时日志收集及可视化检索方法

技术领域

本发明涉及实时日志收集与检索领域，具体而言涉及一种高可靠的实时日志收集与可视化检索方法。

背景技术

一般大型系统是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，服务产生的日志(应用日志、访问日志、安全日志等)因此也就散落在各服务器上。直接在日志服务器上通过grep、awk、wc命令可以实现日志信息的检索和统计。但在规模较大的场景中(数十、上百台服务，一台服务器多种日志类型，一种类型又有多个日志文件)，此方法效率低下，同时还需面临日志文件以循环覆盖方式输出，日志数据量太大如何归档、文本搜索太慢、如何多维度查询分析统计等问题。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，存储，然后再进行分析。

一个完整的集中式日志系统，需要包含以下几个主要特点：收集，能够完整地采集多种来源的日志数据；传输，能够安全、稳定、可靠地将日志数据实时传输到中央系统；存储，持久化存储日志数据；分析检索，支持自定义UI查询、分析，并快速得到结果。

目前通过现有技术Flume、Kafka、Storm、HDFS可以实现实时日志的集中式收集。Flume是一个分布式、可靠和高可用的海量日志采集、聚合和传输的日志收集系统，已支持多种数据发送方(包括Kafka)，并且支持自定义编写插件实现日志的处理及发送。Kafka是一种高吞吐量的分布式发布订阅消息系统，通过消息的生产者与消费者实现消息数据的扭转。Storm是一个分布式的、容错的实时计算系统，通过“流处理”实时地处理消息。而HDFS是Hadoop的分布式文件系统，能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。

ELK(Elasticsearch、Logstash、Kibana)可以实现以Web展现形式对集中的实时日志可视化查询、检索、分析。其中Elasticsearch是一个实时的分布式搜索分析引擎，它被用作全文检索、结构化搜索、分析。Logstash是一款强大的数据处理工具，它可以实现数据传输，格式处理，格式化输出。而Kibana是一个基于Web的图形界面，用于可视化地检索、分析、统计存储在Elasticsearch中的数据。

但设计一套综合现有技术，能够建立实时日志收集及检索平台，实现实时日志完整地收集，安全、稳定、可靠地传输，持久化存储，并能实时地可视化查询仍是一个值得解决的问题。

发明内容

本发明目的是，在以上现有技术背景下，设计一套实时日志收集及检索平台，实现实时日志完整地收集，安全、稳定、可靠地传输，持久化存储，并能实时地可视化查询、检索、分析。

为达成上述目的，本发明所采用的技术方案如下：高可靠的实时日志收集及可视化检索方法，步骤如下：

步骤1设置实时日志收集架构

设置通用的实时日志收集架构，确保日志收集完整：设有实时日志收集，日志数据加密传输，日志数据完整性检查，缺失告警，检查结果可视化系统架构；在目标日志服务器上部署Flume客户端及自定义Flume插件、Kafka集群、Storm集群、HDFS分布式文件系统；通过配置Flume配置文件，进行多线程的目标日志读取，并将读取的数据传输至Kafka集群；Kafka集群通过创建的分区与Kafka集群的Topic归类进行日志数据的缓存，并通过配置的自动清理机制清除过期的日志数据，避免Kafka消息堆积引起磁盘存储问题；Storm集群通过提交日志数据处理Topology任务，进行Kafka消息流式消费，并写入HDFS分布式文件系统，在过程中进行日志数据完整性检查，并将检查结果写入数据库中；最后通过开源调度工具Pentaho，编写定时调度作业，进行检查结果的处理，按制定的告警策略对日志文件完整性检查失败的结果进行邮件、短信的通知，并通过报表工具QlikView，开发报表实现准实时的检查结果展示

设有日志数据压缩、加密算法模块，在Flume发送数据时，进行数据加密、压缩，并在Storm中再进行数据解压、解密还原；这样一方面保证了数据的安全性，同时可以降低数据传输所需的网络带宽，而Kafka集群在本地缓存数据时，就地加密存储，多方面确保了日志数据的安全性；

步骤2，日志数据完整性检查流程与算法步骤：通过自定义Flume插件在传输日志数据时，对已收集的日志文件发送检查消息，使Storm集群在对落地日志数据时，对HDFS存储的日志数据进行完整性检查，将检查结果入库，并且流式的向后传递检查结果消息；

步骤3，切片日志文件删除与缺失数据重传流程与算法步骤：

1)自定义Flume插件订阅Kafka数据检查Topic，解析检查结果；检查成功，则进行本地的切片日志文件清理工作，以减轻磁盘压力；

2)若检查失败，则根据缺失的日志文件名以及日志文件行号信息，重新读取缺失的日志文件，以相同的日志文件数据流向管道写入Kafka集群，并在最后添加日志文件完整性检查消息，等待步骤2中的第四步；直至日志文件检查完整或者检查次数超过设定阈值；

在步骤1至3下，日志文件数据的完整性有了保证；

步骤4，设置实时日志可视化检索架构：

设有实时日志订阅模块，实时日志解析、过滤，实时日志可视化检索系统架构；实时日志订阅模块指搭建Elasticsearch集群与Kibana，使Kibana能利用Elasticsearch的REST接口来检索存储在Elasticsearch数据；通过配置Logstash配置文件，订阅Kafka中的某一个或多个日志数据缓存的Topic，将日志数据解析、过滤后，以指定索引写入Elasticsearch；最后在Kibana Web页面通过指定的索引，自定义日志数据的实时检索、查询与分析。

步骤2中，

1)Flume在收集日志时，首先会对目标日志进行实时切片(切片策略包括按时间分钟、小时、天)得到切片的日志文件，切片的日志文件以时间格式存储为本地文件，并本地保存目标切片日志文件的偏移量，防止程序异常关闭(人为或者自身出错引起)导致再次启动时日志数据的重复或者丢失；

2)对于切片的日志文件，通过自定义Flume插件实时读取，将日志文件数据逐行写入Kafka集群，并在每一行消息头部添加日志数据附带属性；其间实时保存读取的日志文件信息(文件名，文件偏移量，当前文件行数等信息)，保证再次启动时日志文件能够准确无误地继续读取；

3)自定义Flume插件定时执行任务，对需要检查的切片日志，以日志文件数据相同的数据管道向后发送日志文件数据检查消息(包括日志文件数据的文件名，日志文件数据最大行数等)；

4)Storm Topology在处理日志文件数据的同时，会收到文件检查消息，对落地至HDFS的日志数据进行完整性检查，并将检查结果写入数据库，流式地将检查结果写入Kafka数据检查Topic中；

5)定时作业根据日志数据的切片日志文件的策略，对HDFS落地的日志数据以及数据库中的记录信息检查结果进行告警裁定，将需告警的信息以邮件、短信形式通知运维人员。

步骤4中，

1)Logstash在订阅日志数据时，根据日志数据在Kafka中的分区数，确定多线程数量，以达到日志数据的实时消费；

2)Logstash在解析、过滤日志数据时，首先处理解析日志消息的头部信息，提取其中的数据附带属性，并作为关键字段添加至日志消息尾部；其次，根据指定规则过滤不需要的日志数据或者垃圾数据。

有益效果：本发明的核心是日志数据完整性收集的流程与算法步骤以及如何快速检索日志数据，收集，能够完整地采集多种来源的日志数据；传输，能够安全、稳定、可靠地将日志数据实时传输到中央系统；存储，持久化存储日志数据；分析检索，支持自定义UI查询、分析，并快速得到结果。总之，本发明利于实时日志的集中式收集、管理与应用。利于实时日志完整、可靠、安全、稳定传输。本发明利于实时日志快速地可视化的检索、查询以及分析。

附图说明

图1系统整体架构。

图2日志收集插件组件图。

图3日志数据检查流程图。

图4日志缺失数据重传流程图。

具体实施方式

以下结合附图，对本发明作进一步详细说明。设计实时日志收集架构与实时日志可视化检索框架，如图1所示。

设计实时日志收集架构。设计通用的实时日志收集架构，确保日志收集完整：

设有实时日志收集，日志数据加密传输，日志数据完整性检查，缺失告警，检查结果可视化系统架构。在目标日志服务器上部署Flume客户端及Flume自定义插件，通过配置Flume配置文件，进行多线程的目标日志读取，并将读取的数据传输至Kafka集群。

设有日志数据压缩、加密算法，在Flume发送数据时，进行数据加密、压缩算法的设计，并在Storm中再进行数据解压、解密还原。这样一方面保证了数据的安全性，同时可以降低数据传输所需的网络带宽，而Kafka集群在本地缓存数据时，就以加密存储，多方面确保了日志数据的安全性。

其中，Flume部署在目标日志服务上，通过Agent1将原始日志文件读取后，根据切片策略落地至本地文件夹，生成带有时间格式的切片文件，再经过Agent2读取切片文件数据，进行压缩、加密后写入Kafka集群。Kafka集群部署在网络中心节点，将写入的日志数据根据Topic进行本地缓存，等待订阅者消费数据。Storm集群部署在大数据集群(Hadoop)中，通过提交日志数据处理Topology。

通过自定义Flume插件在传输日志数据时，对已收集的日志文件发送检查消息，促使Storm在落地日志数据时，对HDFS存储的日志数据进行完整性检查，将检查结果入库，并流式的向后传递检查结果消息。

Flume在收集日志时，首先会对目标日志进行实时切片(切片策略包括按时间分钟、小时、天)，切片成以时间格式存储的本地文件，并本地保存目标文件的偏移量，防止程序异常关闭(人为或者自身出错引起)导致再次启动时日志数据的重复或者丢失。

对于切片的日志文件，通过自定义Flume插件实时读取，将日志数据逐行写入Kafka集群，并在每一行消息头部添加日志数据附带属性。其间实时保存读取的日志文件信息(文件名，文件偏移量，当前文件行数等信息)，保证再次启动时日志文件能够准确无误地继续读取。

自定义Flume插件定时执行任务，对需要检查的切片日志，以日志数据相同的数据管道向后发送日志数据检查消息(日志数据文件名，日志最大行数等)。

Storm Topology在处理日志数据的同时，会收到文件检查消息，对落地至HDFS的日志数据进行完整性检查，并将检查结果写入数据库，流式地将检查结果写入Kafka数据检查Topic中。

定时作业根据日志数据切片的策略，对HDFS落地的日志数据以及检查结果库中的记录信息进行告警裁定，将需告警的信息以邮件、短信形式通知运维人员。

在本实施例中，本发明设计的日志数据收集Flume自定义插件组件结构如图2所示。

整个结构分为日志数据切片与切片数据读取两块，日志数据切片用于将原始日志以时间策略切片保存至本地，切片数据读取用于将切片的日志数据逐行封装后写入Kafka集群。各组件根据Flume官方提供的API进行自定义开发以及封装，达到精简易用的程度。

日志数据切片，根据系统时间与切片策略进行日志数据的原始拷贝，并落地成指定规则文件名的日志切片数据。本实例以按小时切片策略为例，切片后的文件名命名规则如下：yyyy-MM-dd-HH_fileMaker.log，其中fileMaker用于标识切片文件的原始文件名。日志切片组件工作流程如下：

1、MultiExec Source多线程执行各原始日志文件Tail指令，将每一行日志数据内容、系统当前时间、日志文件名封装成各个event，写入File Channel；

2、File Sink从File Channel中取出event，并根据封装的event头信息将日志数据写入指定规则的切片文件中。

切片数据读取流程如下：

1、Taildir Source实时监测多个目录下的文件，当文件增大或者新增文件时，实时增量式读取文件，并将新增的数据以一行一个event进行封装写入File Channel，同时本地记录各切片文件的偏移量。

2、Kafka Sink从File Channel中取出event，将event以指定的序列化键值方式(key-value)写入Kafka。根据策略定时构造需进行文件检查的消息，同时本地记录尚未检查的文件信息。

其中1中封装后的每一行日志数据event头信息如下：

日志数据所属切片文件全路径，数据标签(fileMaker)，当前数据所属行号

比如：/focus/sample/logs/2018-03-26-9_TEST.log,1.47_test_file,119

其中2中文件检查消息的数据结构如下：

其中各属性含义如下：

·fileAllPath：待检查的日志切片文件全路径。

·maxLines：日志切片文件最大的行数。

·headdfKey：日志切片文件自带的唯一标识。

·upTime：日志切片文件最后更新时间，用于判定文件是否已切割完成。

·isBuilt：日志切片文件是否已构造过检查消息标识，若是则会定时移除。

·topic：日志切片文件写入Kafka的Topic名称。

从Kafka消费日志数据，根据消息的头信息，判定是日志数据还是数据检查消息，从而进行数据落地HDFS或者日志数据完整性检查流程，将检查结果写入单独部署的数据库中。Kafka集群通过创建的分区与Topic进行日志数据的缓存，并通过配置的自动清理机制清除过期的数据，避免Kafka消息堆积引起磁盘存储问题。Storm集群通过提交日志数据处理Topology，进行Kafka消息流式消费，写入HDFS分布式文件系统，在过程中进行日志数据完整性检查，并将检查结果写入QV数据库中。最后通过调度工具Pentaho，编写定时调度作业，进行检查结果的分析与处理，按制定的告警策略对日志文件完整性检查失败的结果进行邮件、短信的通知，并通过报表工具QlikView，开发报表准实时的展现检查结果。设有QV服务器并单独部署，连通数据检查结果数据库，通过编写SQL语句，将检查结果分类，分时以报表形式联动展现。告警服务属于公共平台，只需配置定时告警策略与告警消息接收者即可，达到告警阈值，系统自动发送告警消息。

ELK部署于数据应用网，Logstash与Kafka集群能够连通，Elasticsearch集群与Kibana只需能够与Logstash连通即可。通过Logstash，订阅Kafka中的某一个或多个日志Topic，将日志数据解析、过滤后，以指定索引写入Elasticsearch。最后在Kibana Web页面通过指定的索引，自定义日志数据的实时检索、查询与分析。

在本实施例中，本发明设计的日志数据检查流程图如图3所示。

日志数据检查时，解析检查消息，根据需检查的文件名，获取HDFS以此文件名结尾的所有文件；循环文件并截取每一行尾部在落地时添加的行号数据，根据最大行号数，进行匹配并标识。若存在缺失的行数，则构造需重传的日志数据信息；若检查通过则构造检查成功信息。检查信息装载后，通过Kafka bolt流入检查结果Kafka Topic中，等待订阅者消费。

自定义Flume插件订阅Kafka数据检查Topic，解析检查结果。检查成功，则进行本地的切片文件清理工作，以减轻磁盘压力；

若检查失败，则根据缺失的文件名以及文件行号信息，重新读取缺失的日志数据，以相同的数据流向管道写入Kafka集群，并在最后添加文件完整性检查消息，等待StormTopology对落地至HDFS的日志数据进行完整性检查，并将检查结果写入数据库，流式地将检查结果写入Kafka数据检查Topic中；直至文件检查完整或者检查次数超过设定阈值。

设有实时日志订阅，实时日志解析、过滤，实时日志可视化检索系统架构。搭建Elasticsearch集群与Kibana，使Kibana可以利用Elasticsearch的REST接口来检索存储在Elasticsearch数据。通过配置Logstash配置文件，订阅Kafka中的某一个或多个日志Topic，将日志数据解析、过滤后，以指定索引写入Elasticsearch。最后在Kibana Web页面通过指定的索引，自定义日志数据的实时检索、查询与分析。

Logstash在订阅日志数据时，根据日志数据在Kafka中的分区数，确定多线程数量，以达到日志数据的实时消费；

Logstash在解析、过滤日志数据时，首先处理解析日志消息的头部信息，提取其中的数据附带属性，并作为关键字段添加至日志消息尾部；其次，根据指定规则过滤不需要的日志数据或者垃圾数据。

在本实施例中，本发明设计的缺失数据重传流程图，如图4所示。

日志缺失数据重传，从Kafka中获取检查结果消息，根据消息头部信息判断是否是本机需要关注的数据检查结果，若不是，直接跳过。若为检查成功消息，则进行切片文件的清理工作，否则从本地切片数据中再次读取缺失的日志数据，通过Kafka Sink写入与缺失数据相同的Kafka Topic中，由Storm追加至HDFS对应的文件中。

在本实施例中，针对存储在Kafka集群中的日志数据，需根据每一行日志数据的头部信息，进行过滤以及处理，配置Logstash参数，关键设置如下：

其中“key_deserializer_class”与“value_deserializer_class”需要以写入的K-V序列化方法对应，“decorate_events”设置为“true”才能将Kafka消息的头部信息带出，以便在filter组件中过滤及处理。输出时需指定索引“index”，以便于在Kibana中实时检索。

以上具体实施方式所述仅为本发明的实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均以包含在本发明的保护范围之内。

Claims (3)

1.高可靠的实时日志收集及可视化检索方法，其特征是，步骤如下：

步骤1，设置实时日志收集架构：

设置通用的实时日志收集架构，确保日志收集完整：设有实时日志收集，日志数据加密传输，日志数据完整性检查，缺失告警，检查结果可视化系统架构；在目标日志服务器上部署Flume客户端及自定义Flume插件、Kafka集群、Storm集群、HDFS分布式文件系统；通过配置Flume配置文件，进行多线程的目标日志读取，并将读取的数据传输至Kafka集群；Kafka集群通过创建的分区与Kafka集群的Topic归类进行日志数据的缓存，并通过配置的自动清理机制清除过期的日志数据，避免Kafka消息堆积引起磁盘存储问题；Storm集群通过提交日志数据处理Topology任务，进行Kafka消息流式消费，并写入HDFS分布式文件系统，在过程中进行日志数据完整性检查，并将检查结果写入数据库中；最后通过开源调度工具Pentaho，编写定时调度作业，进行检查结果的处理，按制定的告警策略对日志文件完整性检查失败的结果进行邮件、短信的通知，并通过报表工具QlikView，开发报表实现准实时的检查结果展示；

设有日志数据压缩、加密算法模块，在Flume发送数据时，进行数据加密、压缩，并在Storm中再进行数据解压、解密还原；这样一方面保证了数据的安全性，同时可以降低数据传输所需的网络带宽，而Kafka集群在本地缓存数据时，就地加密存储，多方面确保了日志数据的安全性；

步骤2，日志数据完整性检查流程与算法步骤：通过自定义Flume插件在传输日志数据时，对已收集的日志文件发送检查消息，使Storm集群落地至HDFS的日志数据进行完整性检查，将检查结果入库，并且流式的向后传递检查结果消息；

步骤3，切片日志文件删除与缺失数据重传流程与算法步骤：

1)自定义Flume插件订阅Kafka数据检查Topic，解析检查结果；检查成功，则进行本地的切片日志文件清理工作，以减轻磁盘压力；

2)若检查失败，则根据缺失的日志文件名以及日志文件行号信息，重新读取缺失的日志文件，以相同的日志文件数据流向管道写入Kafka集群，并在最后添加日志文件完整性检查消息，等待步骤2；直至日志文件检查完整或者检查次数超过设定阈值；

在步骤1至3下，日志文件数据的完整性有了保证；

步骤4，设置实时日志可视化检索架构：

设有实时日志订阅模块，实时日志解析、过滤，实时日志可视化检索系统架构；实时日志订阅模块指搭建Elasticsearch集群与Kibana，使Kibana能利用Elasticsearch的REST接口来检索存储在Elasticsearch数据；通过配置Logstash配置文件，订阅Kafka中的某一个或多个日志数据缓存的Topic，将日志数据解析、过滤后，以指定索引写入Elasticsearch；最后在Kibana Web页面通过指定的索引，自定义日志数据的实时检索、查询与分析。

2.根据权利要求1所述的高可靠的实时日志收集及可视化检索方法，其特征是，步骤2中 ，

1)Flume在收集日志时，首先会对目标日志进行实时切片，切片策略包括按时间分钟、小时、天得到切片的日志文件，切片的日志文件以时间格式存储为本地文件，并本地保存目标切片日志文件的偏移量，防止程序异常关闭，异常关闭指人为或者自身出错引起导致再次启动时日志数据的重复或者丢失；

2)对于切片的日志文件，通过自定义Flume插件实时读取，将日志文件数据逐行写入Kafka集群，并在每一行消息头部添加日志数据附带属性；其间实时保存读取的日志文件信息，包括文件名、文件偏移量、当前文件行数信息，保证再次启动时日志文件能够准确无误地继续读取；

3)自定义Flume插件定时执行任务，对需要检查的切片日志，以日志文件数据相同的数据管道向后发送日志文件数据检查消息，包括日志文件数据的文件名，日志文件数据最大行数；

4)Storm Topology在处理日志文件数据的同时，会收到文件检查消息，对落地至HDFS的日志数据进行完整性检查，并将检查结果写入数据库，流式地将检查结果写入Kafka数据检查Topic中；

5)定时作业根据日志数据的切片日志文件的策略，对HDFS落地的日志数据以及数据库中的记录信息检查结果进行告警裁定，将需告警的信息以邮件、短信形式通知运维人员。

3.根据权利要求1所述的高可靠的实时日志收集及可视化检索方法，其特征是，步骤4中，

1)Logstash在订阅日志数据时，根据日志数据在Kafka中的分区数，确定多线程数量，以达到日志数据的实时消费；

2)Logstash在解析、过滤日志数据时，首先处理解析日志消息的头部信息，提取其中的数据附带属性，并作为关键字段添加至日志消息尾部；其次，根据指定规则过滤不需要的日志数据或者垃圾数据。

Images