发明内容
本发明的目的在于针对现有技术中日志收集管理***对原有的业务***变更很大,有的日志收集管理***时效性差,数据产生慢的问题,提供一种日志收集管理***,能够满足对业务***要求低,通用性好的要求。
为解决上述技术问题,本发明采用了如下技术方案:
一种日志收集管理***,包括应用层子***、数据传输层子***、数据处理层子***和数据存储层子***,其中,
应用层子***包括一个以上业务***,用于收集单机的日志,将收集的日志传输给数据传输层子***;
数据传输层子***由分布式发布订阅消息***组成,用于接收应用层子***发送的日志;
数据处理层子***由分布式计算***组成,从数据传输层子***订阅日志,并进行分析;
数据存储层子***将原始日志存放至分布式文件***,将数据处理层子***的分析结果存放至分布式数据库***和关系型数据库单元。
其中,所述应用层子***采用数据交换格式组织收集的日志,统一不同业务***获得的日志格式。
另外,所述应用层子***在所述一个以上业务***设置埋点,获得包括跟踪识别号、远程过程调用识别号、调用开始时间、调用类型、协议类型、调用方网络地址和端口、服务名信息、调用耗时、调用结果、异常信息的日志内容。
所述数据传输层子***采用离线与实时存储结合的方式,获取应用层子***发布的日志。
另外,所述应用层子***将所有日志均衡发到数据传输层子***的所有子节点上,以实现负载均衡,当数据传输层子***的单个子节点失效时,其他子节点补充发布订阅消息功能。
特别地,当发生业务***异常时,所述应用层子***收集报警日志,所述报警日志包括异常业务***标示号、报警标示、通知方式字段、通知对象和报警通知内容。
所述数据处理层子***包括报警监测单元,当所述应用层子***收集到报警日志后,如果所述数据处理层子***的报警监测单元监测到报警日志重复发送,则按照预定间隔发送报警日志,发送成功后则存储所述报警日志并不再发送报警日志,直至报警日志超出预设有效时间。
一种日志收集管理方法,所述方法包括步骤:
A、收集单机的日志并发布收集的日志;
B、利用分布式发布订阅消息***接收日志;
C、利用分布式计算***订阅日志,并进行分析;
D、将原始日志存放至分布式文件***,将数据处理层子***的分析结果存放至分布式数据库***和关系型数据库单元。
特别地,步骤A中收集单机的日志的步骤包括:在业务***设置埋点,获得包括跟踪识别号、远程过程调用识别号、调用开始时间、调用类型、协议类型、调用方网络地址和端口、服务名信息、调用耗时、调用结果、异常信息的日志内容。
发布收集的日志及利用分布式发布订阅消息***接收日志的步骤包括:应用层子***将所有日志均衡发到数据传输层子***的所有子节点上,以实现负载均衡,当数据传输层子***的单个子节点失效时,其他子节点补充发布订阅消息功能。
本发明的日志收集管理***和方法采用数据交换格式组织收集的日志,统一不同业务***获得的日志格式,因此对业务***的要求低,通用性较好,不同业务***之间的日志文件能够兼容。
本发明的日志收集管理***和方法对报警日志采用防雪崩方式,因此提供了***的稳定性,防止了业务***的崩溃。
具体实施方式
下面结合附图,对本发明作详细说明。
以下公开详细的示范实施例。然而,此处公开的具体结构和功能细节仅仅是出于描述示范实施例的目的。
然而,应该理解,本发明不局限于公开的具体示范实施例,而是覆盖落入本公开范围内的所有修改、等同物和替换物。在对全部附图的描述中,相同的附图标记表示相同的元件。
参阅附图,本说明书所附图式所绘示的结构、比例、大小等,均仅用以配合说明书所揭示的内容,以供熟悉此技术的人士了解与阅读,并非用以限定本发明可实施的限定条件,故不具技术上的实质意义,任何结构的修饰、比例关系的改变或大小的调整,在不影响本发明所能产生的功效及所能达成的目的下,均应仍落在本发明所揭示的技术内容得能涵盖的范围内。同时,本说明书中所引用的位置限定用语,亦仅为便于叙述的明了,而非用以限定本发明可实施的范围,其相对关系的改变或调整,在无实质变更技术内容下,当亦视为本发明可实施的范畴。
同时应该理解,如在此所用的术语“和/或”包括一个或多个相关的列出项的任意和所有组合。另外应该理解,当部件或单元被称为“连接”或“耦接”到另一部件或单元时,它可以直接连接或耦接到其他部件或单元,或者也可以存在中间部件或单元。此外,用来描述部件或单元之间关系的其他词语应该按照相同的方式理解(例如,“之间”对“直接之间”、“相邻”对“直接相邻”等)。
在介绍本发明具体实施方式之前,首先简要说明一些相关技术。
埋点即***在当前节点的上下文信息,可以分为客户端埋点、服务端埋点,以及客户端和服务端双向型埋点。
Kafka是一种高吞吐量的分布式发布订阅消息***,它可以处理消费者规模的网站中的所有动作流数据。这种动作(网页浏览,搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。对于像Hadoop的一样的日志数据和离线分析***,但又要求实时处理的限制,这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理,也是为了通过集群机来提供实时的消费。
Hadoop是一个由Apache基金会所开发的分布式***基础架构。Hadoop由许多元素构成。其最底部是Hadoop Distributed File System(HDFS),它存储Hadoop集群中所有存储节点上的文件。
Strom是分布式的、容错的实时计算***。Storm与其他大数据解决方案的不同之处在于它的处理方式。Hadoop在本质上是一个批处理***。数据被引入Hadoop文件***(HDFS)并分发到各个节点进行处理。当处理完成时,结果数据返回到HDFS供始发者使用。Storm支持创建拓扑结构来转换没有终点的数据流,不同于Hadoop作业,这些转换从不停止,它们会持续处理到达的数据。
Storm集群由一个主节点和多个工作节点组成。主节点运行了一个名为“Nimbus”的守护进程,用于分配代码、布置任务及故障检测。每个工作节点都运行了一个名为“Supervisor”的守护进程,用于监听工作,开始并终止工作进程。Nimbus和Supervisor都能快速失败,而且是无状态的,这样一来它们就变得十分健壮,两者的协调工作是由ApacheZooKeeper来完成的。
HBase是一个分布式的、面向列的开源数据库,该技术来源于Fay Chang所撰写的Google论文“Bigtable:一个结构化数据的分布式存储***”。就像Bigtable利用了Google文件***(File System)所提供的分布式数据存储一样,HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。
Log4j是Apache的一个开源项目,通过使用Log4j,我们可以控制日志信息输送的目的地是控制台、文件、GUI组件,甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等;我们也可以控制每一条日志的输出格式;通过定义每一条日志信息的级别,我们能够更加细致地控制日志的生成过程。最方便的是,这些可以通过一个配置文件来灵活地进行配置,而不需要修改应用的代码。
Log4j主要有三个组件,分别是Logger、Appender和Layout。其中Logger负责供客户端代码调用,执行debug(Object msg)、info(Object msg)、warn(Object msg)、error(Object msg)等方法。而Appender负责日志的输出,Log4j已经实现了多种不同目标的输出方式,可以向文件输出日志、向控制台输出日志、向Socket输出日志等。Layout则负责日志信息的格式化。
JSON(JavaScript Object Notation)是一种轻量级的数据交换格式。它基于ECMAScript的一个子集。JSON采用完全独立于语言的文本格式,但是也使用了类似于C语言家族的习惯(包括C、C++、C#、Java、JavaScript、Perl、Python等)。这些特性使JSON成为理想的数据交换语言。
如图1所示,本发明具体实施方式中提供了一种日志收集管理***及方法,所述***包括应用层子***、数据传输层子***、数据处理层子***和数据存储层子***,其中,应用层子***包括一个以上业务***,用于收集单机的日志,将收集的日志传输给数据传输层子***;数据传输层子***由分布式发布订阅消息***组成,用于接收应用层子***发送的日志;数据处理层子***由分布式计算***组成,从数据传输层子***订阅日志,并进行分析;数据存储层子***将原始日志存放至分布式文件***,将数据处理层子***的分析结果存放至分布式数据库***和关系型数据库单元。
特别地,应用层子***的每个业务***使用Log4j配置Appender,负责进行对单机的日志收集工作。
具体而言,所述应用层子***在所述一个以上业务***设置埋点,获得包括跟踪识别号TraceId、远程过程调用识别号RPCId、调用开始时间、调用类型、协议类型、调用方网络地址和端口、服务名信息、调用耗时、调用结果、异常信息的日志内容。另外,日志还可以预留可扩展字段,为下一步扩展做准备。
为了对日志进行统一处理。一个统一、规范的日志格式就是非常重要的,而现有技术中常常使用的Pattern Layout,主要用于人眼查看,而对于***的分析和处理很不方便,特别是字段的切分非常的不方便,如下所示:
可以看出,这种日志的组织方式不利于统一管理,也不利于计算机进行自动分析。为此,所述应用层子***采用数据交换格式组织收集的日志,统一不同业务***获得的日志格式。例如在一个具体实施方式中,采用JSON格式来统一组织需要的日志格式。
因此,本发明的日志收集管理***和方法采用数据交换格式组织收集的日志,统一不同业务***获得的日志格式,因此对业务***的要求低,通用性较好,不同业务***之间的日志文件能够兼容。
另外,所述数据传输层子***采用离线与实时存储结合的方式,获取应用层子***发布的日志。例如在一个具体实施方式中,直接采用基于Log4j的MQ组件将日志推送给分布式发布订阅消息***。
对于数据传输层子***而言,所述分布式发布订阅消息***可以是Kafka,利用Kafka接受应用层子***发布的日志,并将日志发送给订阅日志的数据处理层子***。
而所述数据处理层子***的分布式计算***可以是Storm集群,Storm集群由一个主节点和多个工作节点组成。主节点运行了一个名为“Nimbus”的守护进程,用于分配代码、布置任务及故障检测。
在一个具体实施方式中,所述应用层子***将所有日志均衡发到数据传输层子***的所有子节点上,以实现负载均衡,当数据传输层子***的单个子节点失效时,其他子节点补充发布订阅消息功能,这种技术方案也被称为failover策略,其目的是为了防止Kafka的单点故障问题,将所有的日志均衡地发到所有的Kafka节点上,达到负载均衡的目标,同时并处理单个Kafka失效的问题。
另外,当发生业务***异常时,所述应用层子***收集报警日志,所述报警日志包括异常业务***标示号、报警标示、通知方式字段、通知对象和报警通知内容。
例如报警日志的各字段为:
sysid:***标示号
alarm:[true\false]是否报警的标示,默认false
msgtype:[sms\email]通知方式字段,
sysidto:发送需要通知的通知对象,
content:报警通知内容
如果某些条件下一些***连续alarm日志,这时要来者不拒发消息就可能导致消息***崩溃,甚至一系列其它业务***雪崩。为了克服这一问题,在本发明具体实施方式中,所述数据处理层子***包括报警监测单元,当所述应用层子***收集到报警日志后,如果所述数据处理层子***的报警监测单元监测到报警日志重复发送,则按照预定间隔发送报警日志,发送成功后存储所述报警日志并不再发送报警日志,直至存储的报警日志超出预设有效时间。
通过伪代码的方式表示为:
可见,本发明的日志收集管理***和方法对报警日志采用防雪崩方式,因此提供了***的稳定性,防止了业务***的崩溃。
与本发明的日志收集管理***相对应,本发明具体实施方式中还包含了一种日志收集管理方法,如图2所示,所述方法包括步骤:
A、收集单机的日志,发布收集的日志;
B、利用分布式发布订阅消息***接收日志;
C、利用分布式计算***订阅日志,并进行分析;
D、将原始日志存放至分布式文件***,将数据处理层子***的分析结果存放至分布式数据库***和关系型数据库单元。
特别地,在步骤A中收集单机的日志的步骤包括:在业务***设置埋点,获得包括跟踪识别号、远程过程调用识别号、调用开始时间、调用类型、协议类型、调用方网络地址和端口、服务名信息、调用耗时、调用结果、异常信息的日志内容。
另外,发布收集的日志及利用分布式发布订阅消息***接收日志的步骤包括:应用层子***将所有日志均衡发到数据传输层子***的所有子节点上,以实现负载均衡,当数据传输层子***的单个子节点失效时,其他子节点补充发布订阅消息功能。
需要说明的是,上述实施方式仅为本发明较佳的实施方案,不能将其理解为对本发明保护范围的限制,在未脱离本发明构思前提下,对本发明所做的任何微小变化与修饰均属于本发明的保护范围。