获取日志数据的方法和系统
获取日志数据的方法和系统
技术领域
[0001] 本发明涉及数据通信技术领域，特别是涉及一种获取日志数据的方法和系统。
背景技术
[0002] 随着电子商务技术的发展，网络的后端服务器承载的压力也越来越大，同时需要处理的“数据”也呈几何级增长，实时准确的收集、传输、计算海量日志随之成为电子商务中的迫切要求。现有技术中主要使用twitter收集日志时涉及的flume-ng技术。Flume是一个分布式、可靠的高性能工具，用于从不同数据源收集、聚合、传输大量日志数据到一个中央数据源。Flume有三个重要的概念，source, channel, sink,这三个逻辑概念组成一个Flume的代理。Source定义了数据的来源(比如文件),Sink定义了数据的出口，而Channel是Source和Sink中间的通道。其中Source, Channel, Sink都是水平扩展的,可以根据性能进行调整。
[0003] 但是，flume是一个java进程,在启动时就载入了 Iib中的各种与平台无关的文件格式jar (Java Archive, Java归档文件),如果有程序需要读取其中的信息,需要写一个flume的插件(用java)，并且要重启flume才可以，操作复杂，灵活性差；过于注重消息的可靠性，吞吐量低，不便于用户从flume快速获取日志数据。
发明内容
[0004] 基于此，有必要针对上述Flume收集日志数据灵活性差和吞吐量低的问题，提供一种获取日志数据的方法和系统。
[0005] 一种获取日志数据的方法，包括以下步骤:
[0006] 第一 Flume从应用服务器获取日志数据；
[0007] 所述第一 Flume将获取的日志数据传送到Kafka，所述Kafka将收到的日志数据转换为Kafka消息队列。
[0008] 一种获取日志数据的系统，包括应用服务器、第一 Flume和Kafka，其中:
[0009] 所述第一 Flume用于从所述应用服务器获取日志数据和将获取的日志数据传送到所述Kafka ；
[0010] 所述Kafka用于将收到的日志数据转换为Kafka消息队列。
[0011 ] 上述获取日志数据的方法和系统，通过第一 Flume将应用服务器中的日志数据传送到Kafka，并通过Kafka将日志数据转换为Kafka消息队列，用户从Kafka获取日志数据时，只需要连接到Kafka即可，不需要进行繁琐重启和插入操作，可提高获取日志数据的灵活性。
附图说明
[0012] 图1是本发明获取日志数据的方法第一实施方式的流程示意图；
[0013] 图2是本发明获取日志数据的方法第二实施方式的流程示意图；[0014] 图3是本发明获取日志数据的方法第三实施方式的流程示意图；
[0015] 图4是本发明获取日志数据的系统第一实施方式的结构示意图；
[0016] 图5是本发明获取日志数据的系统第二实施方式的结构示意图；
[0017] 图6是本发明获取日志数据的系统第三实施方式的结构示意图。
具体实施方式
[0018] 请参阅图1，图1是本发明获取日志数据的方法第一实施方式的流程示意图。
[0019] 本实施方式的所述获取日志数据的方法包括以下步骤:
[0020] 步骤101，第一 Flume从应用服务器获取日志数据。
[0021] 步骤102,所述第一 Flume将获取的日志数据传送到Kafka,所述Kafka将收到的日志数据转换为Kafka消息队列。
[0022] 本实施方式所述获取日志数据的方法，通过第一 Flume将应用服务器中的日志数据传送到Kafka,并通过Kafka将日志数据转换为Kafka消息队列,用户从Kafka获取日志数据时，只需要连接到Kafka即可，不需要进行繁琐重启和插入操作，可提高获取日志数据的灵活性。
[0023] 其中，对于步骤101,所述Flume优选地可通过自身的三个逻辑部分source、channel和sink从应用服务器抓取日志数据。所述应用服务器的个数和类型可预先根据用户需要和用户类型进行设定。
[0024] 对于步骤102，所述Kafka是一种高吞吐量的分布式发布订阅消息系统，首先，所述Kafka的操作系统的文件缓存足够完善和强大，只要不随机写，顺序读写的性能非常高效。所述Kafka的数据只会顺序插入，数据的删除策略是累积到一定程度或者超过一定时间再删除。所述Kafka另一个独特的特性是将用户信息保存在客户端而不是MQ服务器，这样服务器就不用记录消息的投递过程，每个客户端都自己知道自己下一次应该从什么地方什么位置读取消息，消息的投递过程也是采用客户端主动模型，这样大大减轻了服务器的负担。所述Kafka还强调减少数据的序列化和拷贝开销，它会将一些消息组织成消息队列做批量存储和发送。
[0025] 优选地，所述Kafka具有如下特性:
[0026] 1、通过0(1)的磁盘数据结构提供消息的持久化，这种结构对于即时数据以TB的消息存储也能够保持长时间的稳定性能。
[0027] 2、高吞吐量:即使是非常普通的硬件kafka也可以支持每秒数十万的消息。
[0028] 3、支持通过kafka服务器和消费机集群来分区消息。
[0029] 4、支持Hadoop并行数据加载。
[0030] 在一个实施例中，所述第一 Flume将获取的日志数据传送到Kafka的步骤包括以下步骤:
[0031] 步骤1021,所述第一 Flume通过第一 Github系统建立与所述Kafka间的数据传输通道，并以所述Kafka为数据接收终端进行参数配置。
[0032] 步骤1022，所述第一 Flume对获取的每条日志数据进行预处理后通过建立的数据传输通道发送至所述Kafka。
[0033] 步骤1023，所述Kafka接收的日志数据达到预设数据量时，对预设数据量的日志数据进行数据打包，存储到所述Kafka的存储区域并转换为所述Kafka消息队列。
[0034] 其中，在本实施例中，所述Github可托管各种Git库，并提供一个web界面,但与其它像SourceForge或Google Code这样的服务不同,Github的独特之处在于从另外一个项目进行分支的简易性。所述Git是一个分布式的版本控制系统,最初由Linus Torvalds编写，用作Linux内核代码的管理。
[0035] 优选地，所述第一 Flume和所述Kafka通过一个flume插件flume-kakfa (数据传输通道)进行日志数据传输，所述f lume-kafka是托管于所述第一 Github系统。所述flume-kafka支持从所述Kafka抓取日志数据，也支持将日志数据推向所述Kafka。
[0036] 进一步地，在传输日志数据前，所述第一 Flume首先将所述Kafka定义为数据源的代码片段，并通过process软件程序、congfigure软件程序和stop然间程序对每一条日志
数据进行预设的预处理、配置和停止操作，具体的操作代码如下:
[0037]
public class KafkaSource extends AbstractSource implements Configurable, PollableSource { public Status process() throws EventDeIiveryException {} public void configure(Context context) {} public synchronized void stop() {}
}
[0038] 优选地，以所述Kafka为数据源，并将第一 Flume连接所述Kafka的代 码如下:
[0039]
public static ConsumerConnector getConsumer(Context context) throws IOException5 KeeperException,InterruptedException {
Properties props = new Properties(); props.put("zk.comi€ctn, getZkCoimect(context)); props.put(”groupid”，getGroup(context)); props.put(,fautocommitenabie,T, ”false,，)； props.put(nautooffset.reselM, "largest")； props.put(nsocketbuffersizeM," 102400000");
CotisumerConfig consumerConfig = new ConsumerConflg(props);
CoiisumerComiector consumer = Consumer.createJavaConsumerConnector(consiimerConfig);
[0040]
return consumer;
}
[0041] 在上述代码中,props, put是针对到所述Kafka的连接的属性,下面分别对上述代码中每一个属性进行说明:
[0042] roup id:连接的名称
[0043] autocommit, enable:自动告知所述Kafka目前消费到哪条日志消息
[0044] autooffset, reset:自动获取最新的日志消息
[0045] socket, buffersize:端口通信的缓冲器大小。
[0046] 最后根据这些属性的定义，所述第一 Flume与所述Kafka建立连接。接下来具体说明一下，所述第一 Flume连接到所述Kafka后,所述Kafka是如何接收数据的。我们定义了一批数据中消息的数量。所谓一批数据，指的是所述Kafka将一定数量的数据打包，一次性发送到数据目的地，而不是从所述第一 Flume接收一次数据，往所述Kafka的存储区域发一次。批量发送可节约网络传输的开销。
[0047] 同样的，下面是连接所述Kafka并所述Kafka以为数据目的的代码:
[0048]
[0049] 和以所述Kafka为数据源时建立连接和发送日志数据存在不同之处:对于日志数据的批量处理，以所述Kafka为数据目的时，由所述Kafka自己控制，而不是所述第一Flume。根据上述代码中batch, size,所述Kafka获取到一定数目的日志消息，以一批一批的方式发送。
[0050] 在另一个实施例中，在所述通过Kafka将收到的日志数据转换为Kafka消息队列的步骤之后，还包括以下步骤:
[0051] 通过所述Kafka提供的jmx监控接口获取Kafka的运行数据。
[0052] 所述Kafka相比所述第一 Flume，具有更多的监控数据可以获取，更加方便的监控到整个系统的健康情况。[0053] 请参阅图2，图2是本发明获取日志数据的方法第二实施方式的流程示意图。
[0054] 本实施方式的所述获取日志数据的方法与第一实施方式的区别在于:在所述Kafka将收到的日志数据转换为Kafka消息队列的步骤之后，还包括以下步骤:
[0055] 步骤201, Storm实时计算集群通过Storm系统建立与所述Kafka间的数据传输通道。
[0056] 步骤202,所述Storm实时计算集群通过建立的数据通道从所述Kafka消息队列中获取需要的日志数据。
[0057] 其中，对于步骤201，所述Storm为分布式实时计算提供了一组通用原语，可被用于“流处理”之中，实时处理消息并更新数据库。所述Storm是管理队列及工作者集群的一种方式。所述Storm也可被用于“连续计算”(continuous computation),对数据流做连续查询，在计算时就将结果以流的形式输出给用户，还可被用于“分布式RPC”，以并行的方式运行昂贵的运算
[0058] 对于步骤202, Storm实时计算集群可使用所述Storm中storm-contrib的java方法来连接所述Kafka而获取日志消息。除所述Storm实时计算集群外的其他系统也可从作为消息中间件的所述Kafka中获取日志消息(即每一行日志)。
[0059] 目前，所述Kafka对于很多语言具有亲和力，如:java, python, ruby等流行的语言，都有支持所述Kafka的库。
[0060] 本实施方式的所述获取日志数据的方法，作为用户通过自身与所述Kafka间特有的连接方式即可从所述Kafka快速获取日志数据，无需反复重启所述Kafka。
[0061] 请参阅图3，图3是本发明获取日志数据的方法第三实施方式的流程示意图。
[0062] 本实施方式的所述获取日志数据的方法与第一实施方式的区别在于:所述Kafka将收到的日志数据转换为Kafka消息队列的步骤之后，还包括以下步骤:
[0063] 第二 Flume从所述Kafka消息队列中获取用户需要的日志数据。
[0064] 对于除所述Storm实时计算集群外的其他系统,如:HAFS集群、全文检索集群等，若本身与所述Kafka没有固有的连接方式,可通过第二 Flume与所述Kafka建立连接,并从作为消息中间件的所述Kafka中获取日志消息。
[0065] 在一个实施例中所述第二 Flume从所述Kafka消息队列中获取用户需要的日志数据的步骤包括以下步骤:
[0066] 步骤301,所述第二 Flume通过第二 Github系统建立与所述Kafka间的数据传输通道，并以所述Kafka为数据发送终端进行参数配置。
[0067] 步骤302,所述第二 Flume通过建立的数据传输通道向所述Kafka发送日志请求。
[0068] 步骤303,所述Kafka根据所述日志请求,从所述Kafka消息队列获取对应的日志数据，并通过所述数据传输通道将所述对应的日志数据分批发送至所述第二 Flume。
[0069] 本实施例中所述第二 Flume与所述Kafka建立连接的方式可与第一实施方式中以所述Kafka为数据目的通过所述flume-kafka建立连接的方式中连接代码相同。
[0070] 本实施方式所述获取日志数据的方法，通过所述第二 Flume与所述Kafka建立连接，并为其他系统从作为消息中间件的所述Kafka中快速获取日志消息。
[0071] 请参阅图4，图4是本发获取日志数据的系统第一实施方式的结构示意图。
[0072] 本实施方式的所述获取日志数据的系统包括应用服务器100、第一 Flume200和Kafka300，其中:
[0073] 第一 Flume200，用于从应用服务器100获取日志数据和将获取的日志数据传送到Kafka300。
[0074] Kafka300，用于将收到的日志数据转换为Kafka消息队列。
[0075] 本实施方式所述获取日志数据的系统，通过第一 Flume将应用服务器中的日志数据传送到Kafka,并通过Kafka将日志数据转换为Kafka消息队列,用户从Kafka获取日志数据时，只需要连接到Kafka即可，不需要进行繁琐重启和插入操作，可提高获取日志数据的灵活性。
[0076] 其中，对于应用服务器100，其个数和类型可预先根据用户需要和用户类型进行设定。
[0077] 对于第一 Flume200,所述Flume优选地可通过自身的三个逻辑部分source、channel和sink从应用服务器抓取日志数据。
[0078] 对于Kafka300，Kafka300中是一种高吞吐量的分布式发布订阅消息系统，首先，其操作系统的文件缓存足够完善和强大，只要不随机写，顺序读写的性能非常高效。Kafka300的数据只会顺序插入，数据的删除策略是累积到一定程度或者超过一定时间再删除。Kafka300另一个独特的特性是将用户信息保存在客户端而不是MQ服务器，这样服务器就不用记录消息的投递过程，每个客户端都自己知道自己下一次应该从什么地方什么位置读取消息，消息的投递过程也是采用客户端主动模型，这样大大减轻了服务器的负担。Kafka300还强调减少数据的序列化和拷贝开销，它会将一些消息组织成消息队列做批量存储和发送。
[0079] 优选地，Kafka300具有如下特性:
[0080] 1、通过0(1)的磁盘数据结构提供消息的持久化，这种结构对于即时数据以TB的消息存储也能够保持长时间的稳定性能。
[0081] 2、高吞吐量:即使是非常普通的硬件kafka也可以支持每秒数十万的消息。
[0082] 3、支持通过kafka服务器和消费机集群来分区消息。
[0083] 4、支持Hadoop并行数据加载。
[0084] 在一个实施例中，本实施方式所述获取日志数据的系统还包括第一 Github系统，其中:
[0085] 第一 Flume200还用于通过第一 Github系统建立与Kafka300间的数据传输通道，并以Kafka300为数据接收终端进行参数配置，并对获取的每条日志数据进行预处理后通过建立的数据传输通道发送至Kafka300。
[0086] Kafka300还用于在接收的日志数据达到预设数据量时，对预设数据量的日志数据进行数据打包，存储到Kafka300的存储区域并转换为所述Kafka消息队列。
[0087] 其中，在本实施例中，所述Github可托管各种Git库，并提供一个web界面，但与其它像SourceForge或Google Code这样的服务不同,Github的独特之处在于从另外一个项目进行分支的简易性。所述Git是一个分布式的版本控制系统,最初由Linus Torvalds编写，用作Linux内核代码的管理。
[0088]优选地，第一 Flume200 和 Kafka300 通过一个 flume 插件 flume-kakfa (数据传输通道)进行日志数据传输，所述flume-kafka是托管于所述第一 Github系统。所述flume-kafka支持从Kafka300抓取日志数据，也支持将日志数据推向Kafka300。
[0089] 进一步地，在传输日志数据前，第一 Flume200首先将Kafka300定义为数据源的代码片段，并通过process软件程序、congfigure软件程序和stop然间程序对每一条日志数
据进行预设的预处理、配置和停止操作，具体的操作代码如下:
[0090]
[0091] 优选地，以Kafka300为数据源，并将第一 Flume200连接Kafka300的代码如下:
[0092]
[0094] 在上述代码中，props, put是针对到Kafka300的连接的属性,下面分别对上述代码中每一个属性进行说明:
[0095] roup id:连接的名称
[0096] autocommit, enable:自动告知Kafka300目前消费到哪条日志消息
[0097] autooffset, reset:自动获取最新的日志消息
[0098] socket, buffersize:端口通信的缓冲器大小。
[0099] 最后根据这些属性的定义，第一 Flume200与Kafka300建立连接。接下来具体说明一下，第一 Flume200连接到Kafka300后，Kafka300是如何接收数据的。我们定义了一批数据中消息的数量。所谓一批数据，指的是Kafka300将一定数量的数据打包，一次性发送到数据目的地，而不是从第一 Flume200接收一次数据，往Kafka300的存储区域发一次。批量发送可节约网络传输的开销。
[0100] 同样的，下面是连接Kafka300并Kafka300以为数据目的的代码:
[0101]
[0103] 和以Kafka300为数据源时建立连接和发送日志数据存在不同之处:对于日志数据的批量处理，以Kafka300为数据目的时，由所Kafka300自己控制，而不是第一 Flume200。根据上述代码中batch, size, Kafka300获取到一定数目的日志消息，以一批一批的方式发送。
[0104] 在另一个实施例中，本实施方式所述获取日志数据的系统还可以包括一个监控单元，所述监控单元用于在所述通过Kafka将收到的日志数据转换为Kafka消息队列后，通过Kafka300提供的jmx监控接口获取Kafka300的运行数据。
[0105] Kafka300相比第一 Flume200，具有更多的监控数据可以获取，更加方便的监控到整个系统的健康情况。
[0106] 请参阅图5，图5是本发明获取日志数据的系统第二实施方式的结构示意图。
[0107] 本实施方式的所述获取日志数据的系统与第一实施方式的区别在于:还包括Storm实时计算集群400和Storm系统500, Storm实时计算集群400用于通过Storm系统500建立与Kafka300间的数据传输通道，通过建立的数据通道从所述Kafka消息队列中获取需要的日志数据。
[0108] 其中，对于Storm系统500,所述Storm为分布式实时计算提供了一组通用原语，可被用于“流处理”之中，实时处理消息并更新数据库。所述Storm是管理队列及工作者集群的一种方式。所述Storm也可被用于“连续计算”(continuous computation),对数据流做连续查询，在计算时就将结果以流的形式输出给用户，还可被用于“分布式RPC”，以并行的方式运行昂贵的运算
[0109] 对于Storm实时计算集群400,其可使用所述Storm中storm-contrib的java方法来连接Kafka300而获取日志消息。除Storm实时计算集群400外的其他系统也可从作为消息中间件的Kafka300中获取日志消息(即每一行日志)。
[0110] 目前，Kafka300对于很多语言具有亲和力，如:java, python, ruby等流行的语言，都有支持Kafka300的库。
[0111] 本实施方式的所述获取日志数据的系统，作为用户通过自身与所述Kafka间特有的连接方式即可从所述Kafka快速获取日志数据，无需反复重启所述Kafka。
[0112] 请参阅图6，图6是本发明获取日志数据的系统第三实施方式的结构示意图。
[0113] 本实施方式的所述获取日志数据的系统与第一实施方式的区别在于:还包括第二Flume600,用于从所述Kafka消息队列中获取用户需要的日志数据。
[0114] 对于除Storm实时计算集群400外的其他系统，如:HAFS集群、全文检索集群等，若本身与Kafka300没有固有的连接方式，可通过第二 Flume600与Kafka300建立连接，并从作为消息中间件的Kaf ka300中获取日志消息。
[0115] 在一个实施例中，本实施方式的所述获取日志数据的系统还包括第二 Github系，其中:
[0116] 第二 Flume600还用于通过第二 Github系统建立与Kafka300间的数据传输通道，以Kafka300为数据发送终端进行参数配置，并向Kafka300发送日志请求.[0117] Kafka300还用于根据所述日志请求，从所述Kafka消息队列获取对应的日志数据，并通过所述数据传输通道将所述对应的日志数据分批发送至所述第二 Flume600。
[0118] 本实施例中第二 Flume600与Kafka300建立连接的方式可与第一实施方式中第一实施方式中以所述Kafka300为数据目的通过所述flume-kafka建立连接的方式中连接代码相同。
[0119] 本实施方式所述获取日志数据的系统，通过所述第二 Flume与所述Kafka建立连接，并为其他系统从作为消息中间件的所述Kafka中快速获取日志消息。
[0120] 以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。