发明内容
有鉴于此,本发明提供了一种基于微服务架构的日志管理方法及系统,能够使日志处理的全流程均可根据实际使用情况,进行动态弹缩,有效地利用了物理资源,并能够应对大规模的日志,提高了查询和统计效率。
为了实现上述目的,本发明提供如下技术方案:
一种基于微服务架构的日志管理方法,包括:
将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中;
在分布式场景下,采集各个应用服务器上各个应用的日志信息;
将所述各个应用的日志信息统一缓存在Key为logstash的名字中;
拉取所述日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换;
从所述日志信息中抓取关键字,基于所述关键字将对应的所述日志信息存入所述ElasticSearch搜索服务器。
优选地,所述方法还包括:
展示所述ElasticSearch搜索服务器中的信息。
优选地,所述在分布式场景下,采集各个应用服务器上各个应用的日志信息包括:
通过logstash shipper将各应用的日志信息采集到redis集群中;
所述logstash shipper为各个应用定义用以生成索引的唯一type。
优选地,所述将所述各个应用的日志信息统一缓存在Key为logstash的名字中包括:
通过日志转储组件redis,将数据统一缓存在key为logstash的名字中;
采用list数据类型作为日志采集的一个缓存区队列。
优选地,所述展示所述ElasticSearch搜索服务器中的信息包括:
在所述ElasticSearch搜索服务器的索引中查找、交换数据,生成相应的图表;
展示所述图表。
一种基于微服务架构的日志管理系统,包括:
信息传递模块,用于将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中;
日志采集模块,用于在分布式场景下,采集各个应用服务器上各个应用的日志信息;
日志缓存模块,用于将所述各个应用的日志信息统一缓存在Key为 logstash的名字中;
日志处理模块,用于拉取所述日志信息,进行从原始数据到ElasticSearch 搜索服务器所要求的数据格式的转换;
日志存储模块,用于从所述日志信息中抓取关键字,基于所述关键字将对应的所述日志信息存入所述ElasticSearch搜索服务器。
优选地,所述系统还包括:
日志展示模块,用于展示所述ElasticSearch搜索服务器中的信息。
优选地,所述日志采集模块具体用于:
通过logstash shipper将各应用的日志信息采集到redis集群中;
所述logstash shipper为各个应用定义用以生成索引的唯一type。
优选地,所述日志缓存模块,具体用于:
通过日志转储组件redis,将数据统一缓存在key为logstash的名字中;
采用list数据类型作为日志采集的一个缓存区队列。
优选地,所述日志展示模块,具体用于:
在所述ElasticSearch搜索服务器的索引中查找、交换数据,生成相应的图表;
展示所述图表。
从上述技术方案可以看出,本发明提供了一种基于微服务架构的日志管理方法,将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中,在分布式场景下,采集各个应用服务器上各个应用的日志信息,将各个应用的日志信息统一缓存在Key为logstash 的名字中,拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换;从日志信息中抓取关键字,基于关键字将对应的日志信息存入ElasticSearch搜索服务器。本发明通过RequestID能查询出整个请求的调用链日志详情,对于排查异常、快速定位非常方便快捷。同时,在日志收集、缓存、处理、存储等各个阶段均采用分布式、微服务化的部署方式,使日志处理的全流程均可根据实际使用情况,进行动态弹缩,有效地利用了物理资源,并能够应对大规模的日志,提高了查询和统计效率。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
如图1所示,为本发明公开的一种基于微服务架构的日志管理方法实施例1的流程图,所述方法包括:
S101、将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中;
当需要对日志进行管理时,首先为各个应用统一配置请求拦截器,当拦截到http请求时,拦截器首先生成request ID,同时收集应用的调用信息以及一些用户信息,将所述request ID以及收集的应用的调用信息和用户信息加密输出到日志中。其中,Request ID的生成是为各个应用日志间形成调用链,每次请求都会生成唯一的Request ID,在日志量非常庞大的情况下,带有Request ID的日志在排查故障,查询用户每次请求所产生的日志非常方便、快捷。
S102、在分布式场景下,采集各个应用服务器上各个应用的日志信息;
然后,在分布式场景下,各个应用服务器上都增加了一个日志采集模块,通过日志采集模块收集服务器上的各个应用的日志信息。
S103、将各个应用的日志信息统一缓存在Key为logstash的名字中;
在采集到各个应用的日志信息后,将采集到的各个应用的日志信息统一缓存在Key为logstash的名字中。
S104、拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换;
然后,拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换,例如,日期格式转换为预定义的格式,某些字段的去除、字段的合并转换、message信息json解析等,还有通过GeoIP获取ip所在地,根据系统定制过滤条件,正则解析等。
S105、从日志信息中抓取关键字,基于关键字将对应的日志信息存入ElasticSearch搜索服务器。
从日志信息中抓取关键字,判断出应该写入到ElasticSearch的哪个index 中,并将信息存入对应的index,完成将日志信息存入ElasticSearch搜索服务器。日志存储在ElasticSearch中,同样ElasticSearch也是使用集群方式来进行部署,通过cluster.name来定义集群名称。ElasticSearch集群节点分为两种类型:master node、data node。Masternode:集群的管理节点,主要功能是维护元数据,管理集群各个节点的状态。Data node:负责数据的存储、查询和导入。
综上所述,在上述实施例中,在日志管理时,首先将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中,然后在分布式场景下,采集各个应用服务器上各个应用的日志信息,将各个应用的日志信息统一缓存在Key为logstash的名字中,拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换;从日志信息中抓取关键字,基于关键字将对应的日志信息存入ElasticSearch搜索服务器。本发明通过RequestID能查询出整个请求的调用链日志详情,对于排查异常、快速定位非常方便快捷。同时,在日志收集、缓存、处理、存储等各个阶段均采用分布式、微服务化的部署方式,使日志处理的全流程均可根据实际使用情况,进行动态弹缩,有效地利用了物理资源,并能够应对大规模的日志,提高了查询和统计效率。
如图2所示,为本发明公开的一种基于微服务架构的日志管理方法实施例2的流程图,所述方法包括:
S201、将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中;
当需要对日志进行管理时,首先为各个应用统一配置请求拦截器,当拦截到http请求时,拦截器首先生成request ID,同时收集应用的调用信息以及一些用户信息,将所述request ID以及收集的应用的调用信息和用户信息加密输出到日志中。其中,Request ID的生成是为各个应用日志间形成调用链,每次请求都会生成唯一的Request ID,在日志量非常庞大的情况下,带有Request ID的日志在排查故障,查询用户每次请求所产生的日志非常方便、快捷。
S202、在分布式场景下,采集各个应用服务器上各个应用的日志信息;
然后,在分布式场景下,各个应用服务器上都增加了一个日志采集模块,通过日志采集模块收集服务器上的各个应用的日志信息。
S203、将各个应用的日志信息统一缓存在Key为logstash的名字中;
在采集到各个应用的日志信息后,将采集到的各个应用的日志信息统一缓存在Key为logstash的名字中。
S204、拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换;
然后,拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换,例如,日期格式转换为预定义的格式,某些字段的去除、字段的合并转换、message信息json解析等,还有通过GeoIP获取ip所在地,根据系统定制过滤条件,正则解析等。
S205、从日志信息中抓取关键字,基于关键字将对应的日志信息存入ElasticSearch搜索服务器;
从日志信息中抓取关键字,判断出应该写入到ElasticSearch的哪个index 中,并将信息存入对应的index,完成将日志信息存入ElasticSearch搜索服务器。日志存储在ElasticSearch中,同样ElasticSearch也是使用集群方式来进行部署,通过cluster.name来定义集群名称。ElasticSearch集群节点分为两种类型:master node、data node。Masternode:集群的管理节点,主要功能是维护元数据,管理集群各个节点的状态。Data node:负责数据的存储、查询和导入。
S206、展示ElasticSearch搜索服务器中的信息。
将日志信息存储至ElasticSearch搜索服务器后,还可以根据使用需求,在ElasticSearch搜索服务器的索引中查找、交换数据,生成需要的表图并进行显示。
综上所述,在上述实施例中,在日志管理时,首先将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中,然后在分布式场景下,采集各个应用服务器上各个应用的日志信息,将各个应用的日志信息统一缓存在Key为logstash的名字中,拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换;从日志信息中抓取关键字,基于关键字将对应的日志信息存入ElasticSearch搜索服务器。本发明通过RequestID能查询出整个请求的调用链日志详情,对于排查异常、快速定位非常方便快捷。同时,在日志收集、缓存、处理、存储等各个阶段均采用分布式、微服务化的部署方式,使日志处理的全流程均可根据实际使用情况,进行动态弹缩,有效地利用了物理资源,并能够应对大规模的日志,提高了查询和统计效率,并且能够进一步对ElasticSearch搜索服务器中的信息进行展示。
如图3所示,为本发明公开的一种基于微服务架构的日志管理方法实施例3的流程图,所述方法包括:
S301、将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中;
当需要对日志进行管理时,首先为各个应用统一配置请求拦截器,当拦截到http请求时,拦截器首先生成request ID,同时收集应用的调用信息以及一些用户信息,将所述request ID以及收集的应用的调用信息和用户信息加密输出到日志中。其中,Request ID的生成是为各个应用日志间形成调用链,每次请求都会生成唯一的Request ID,在日志量非常庞大的情况下,带有Request ID的日志在排查故障,查询用户每次请求所产生的日志非常方便、快捷。
S302、通过logstash shipper将各应用的日志信息采集到redis集群中,logstash shipper为各个应用定义用以生成索引的唯一type;
然后,在分布式场景下,各个应用服务器上都增加了一个日志采集模块,通过日志采集模块收集服务器上的各个应用的日志信息。logstash shipper根据配置将各应用日志采集到redis集群中,logstash shipper会为各个应用定义唯一type用来以后生成索引用。
S303、通过日志转储组件redis,将数据统一缓存在key为logstash的名字中,采用list数据类型作为日志采集的一个缓存区队列;
在采集到各个应用的日志信息后,将采集到的各个应用的日志信息统一缓存在Key为logstash的名字中。redis作为日志转储组件可以有效提高系统可用性,使用集群或者主备结构代替单实例,可以有效提高组件的可用性。在redis中,数据统一缓存在key为logstash的名字中,采用list数据类型作为日志采集的一个缓存区队列,list类型是按照插入顺序排序的字符串链表,和数据结构中的普通链表一样,可以在其头部(left)和尾部(right)添加新的元素。
S304、拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换;
然后,logstash indexer负责从redis拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换,例如,日期格式转换为预定义的格式,某些字段的去除、字段的合并转换、message信息json解析等,还有通过GeoIP获取ip所在地,根据系统定制过滤条件,正则解析等。
S305、从日志信息中抓取关键字,基于关键字将对应的日志信息存入ElasticSearch搜索服务器;
从日志信息中抓取关键字,判断出应该写入到ElasticSearch的哪个index 中,并将信息存入对应的index,完成将日志信息存入ElasticSearch搜索服务器。日志存储在ElasticSearch中,同样ElasticSearch也是使用集群方式来进行部署,通过cluster.name来定义集群名称。ElasticSearch集群节点分为两种类型:master node、data node。Masternode:集群的管理节点,主要功能是维护元数据,管理集群各个节点的状态。Data node:负责数据的存储、查询和导入。
S306、在ElasticSearch搜索服务器的索引中查找、交换数据,生成相应的图表,展示图表。
本日志系统的界面使用了kibana开源框架,为Elasticsearch提供分析和可视化的Web平台。它可以在Elasticsearch的索引中查找,交互数据,并生成各种维度的表图。主要展示信息包括:日志数量变化趋势图、日志TOPN 的实例图、失败时间日志分析图、日志查询结果。
综上所述,在上述实施例中,在日志管理时,首先将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中,然后在分布式场景下,采集各个应用服务器上各个应用的日志信息,将各个应用的日志信息统一缓存在Key为logstash的名字中,拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换;从日志信息中抓取关键字,基于关键字将对应的日志信息存入ElasticSearch搜索服务器。本发明通过RequestID能查询出整个请求的调用链日志详情,对于排查异常、快速定位非常方便快捷。同时,在日志收集、缓存、处理、存储等各个阶段均采用分布式、微服务化的部署方式,使日志处理的全流程均可根据实际使用情况,进行动态弹缩,有效地利用了物理资源,并能够应对大规模的日志,提高了查询和统计效率,并且能够进一步对ElasticSearch搜索服务器中的信息进行展示。
如图4所示,为本发明公开的一种基于微服务架构的日志管理系统实施例1的结构示意图,所述系统包括:
信息传递模块401,用于将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中;
当需要对日志进行管理时,首先为各个应用统一配置请求拦截器,当拦截到http请求时,拦截器首先生成request ID,同时收集应用的调用信息以及一些用户信息,将所述request ID以及收集的应用的调用信息和用户信息加密输出到日志中。其中,Request ID的生成是为各个应用日志间形成调用链,每次请求都会生成唯一的Request ID,在日志量非常庞大的情况下,带有Request ID的日志在排查故障,查询用户每次请求所产生的日志非常方便、快捷。
日志采集模块402,用于在分布式场景下,采集各个应用服务器上各个应用的日志信息;
然后,在分布式场景下,各个应用服务器上都增加了一个日志采集模块,通过日志采集模块收集服务器上的各个应用的日志信息。
日志缓存模块403,用于将各个应用的日志信息统一缓存在Key为 logstash的名字中;
在采集到各个应用的日志信息后,将采集到的各个应用的日志信息统一缓存在Key为logstash的名字中。
日志处理模块404,用于拉取日志信息,进行从原始数据到ElasticSearch 搜索服务器所要求的数据格式的转换;
然后,拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换,例如,日期格式转换为预定义的格式,某些字段的去除、字段的合并转换、message信息json解析等,还有通过GeoIP获取ip所在地,根据系统定制过滤条件,正则解析等。
日志存储模块405,用于从日志信息中抓取关键字,基于关键字将对应的日志信息存入ElasticSearch搜索服务器。
从日志信息中抓取关键字,判断出应该写入到ElasticSearch的哪个index 中,并将信息存入对应的index,完成将日志信息存入ElasticSearch搜索服务器。日志存储在ElasticSearch中,同样ElasticSearch也是使用集群方式来进行部署,通过cluster.name来定义集群名称。ElasticSearch集群节点分为两种类型:master node、data node。Masternode:集群的管理节点,主要功能是维护元数据,管理集群各个节点的状态。Data node:负责数据的存储、查询和导入。
综上所述,在上述实施例中,在日志管理时,首先将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中,然后在分布式场景下,采集各个应用服务器上各个应用的日志信息,将各个应用的日志信息统一缓存在Key为logstash的名字中,拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换;从日志信息中抓取关键字,基于关键字将对应的日志信息存入ElasticSearch搜索服务器。本发明通过RequestID能查询出整个请求的调用链日志详情,对于排查异常、快速定位非常方便快捷。同时,在日志收集、缓存、处理、存储等各个阶段均采用分布式、微服务化的部署方式,使日志处理的全流程均可根据实际使用情况,进行动态弹缩,有效地利用了物理资源,并能够应对大规模的日志,提高了查询和统计效率。
如图5所示,为本发明公开的一种基于微服务架构的日志管理系统实施例2的结构示意图,所述系统包括:
信息传递模块501,用于将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中;
当需要对日志进行管理时,首先为各个应用统一配置请求拦截器,当拦截到http请求时,拦截器首先生成request ID,同时收集应用的调用信息以及一些用户信息,将所述request ID以及收集的应用的调用信息和用户信息加密输出到日志中。其中,Request ID的生成是为各个应用日志间形成调用链,每次请求都会生成唯一的Request ID,在日志量非常庞大的情况下,带有Request ID的日志在排查故障,查询用户每次请求所产生的日志非常方便、快捷。
日志采集模块502,用于在分布式场景下,采集各个应用服务器上各个应用的日志信息;
然后,在分布式场景下,各个应用服务器上都增加了一个日志采集模块,通过日志采集模块收集服务器上的各个应用的日志信息。
日志缓存模块503,用于将各个应用的日志信息统一缓存在Key为 logstash的名字中;
在采集到各个应用的日志信息后,将采集到的各个应用的日志信息统一缓存在Key为logstash的名字中。
日志处理模块504,用于拉取日志信息,进行从原始数据到ElasticSearch 搜索服务器所要求的数据格式的转换;
然后,拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换,例如,日期格式转换为预定义的格式,某些字段的去除、字段的合并转换、message信息json解析等,还有通过GeoIP获取ip所在地,根据系统定制过滤条件,正则解析等。
日志存储模块505,用于从日志信息中抓取关键字,基于关键字将对应的日志信息存入ElasticSearch搜索服务器;
从日志信息中抓取关键字,判断出应该写入到ElasticSearch的哪个index 中,并将信息存入对应的index,完成将日志信息存入ElasticSearch搜索服务器。日志存储在ElasticSearch中,同样ElasticSearch也是使用集群方式来进行部署,通过cluster.name来定义集群名称。ElasticSearch集群节点分为两种类型:master node、data node。Masternode:集群的管理节点,主要功能是维护元数据,管理集群各个节点的状态。Data node:负责数据的存储、查询和导入。
日志展示模块506,用于展示ElasticSearch搜索服务器中的信息。
将日志信息存储至ElasticSearch搜索服务器后,还可以根据使用需求,在ElasticSearch搜索服务器的索引中查找、交换数据,生成需要的表图并进行显示。
综上所述,在上述实施例中,在日志管理时,首先将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中,然后在分布式场景下,采集各个应用服务器上各个应用的日志信息,将各个应用的日志信息统一缓存在Key为logstash的名字中,拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换;从日志信息中抓取关键字,基于关键字将对应的日志信息存入ElasticSearch搜索服务器。本发明通过RequestID能查询出整个请求的调用链日志详情,对于排查异常、快速定位非常方便快捷。同时,在日志收集、缓存、处理、存储等各个阶段均采用分布式、微服务化的部署方式,使日志处理的全流程均可根据实际使用情况,进行动态弹缩,有效地利用了物理资源,并能够应对大规模的日志,提高了查询和统计效率,并且能够进一步对ElasticSearch搜索服务器中的信息进行展示。
如图6所示,为本发明公开的一种基于微服务架构的日志管理系统实施例3的结构示意图,所述系统包括:
信息传递模块601,用于将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中;
当需要对日志进行管理时,首先为各个应用统一配置请求拦截器,当拦截到http请求时,拦截器首先生成request ID,同时收集应用的调用信息以及一些用户信息,将所述request ID以及收集的应用的调用信息和用户信息加密输出到日志中。其中,Request ID的生成是为各个应用日志间形成调用链,每次请求都会生成唯一的Request ID,在日志量非常庞大的情况下,带有Request ID的日志在排查故障,查询用户每次请求所产生的日志非常方便、快捷。
日志采集模块602,用于通过logstash shipper将各应用的日志信息采集到redis集群中,logstash shipper为各个应用定义用以生成索引的唯一type;
然后,在分布式场景下,各个应用服务器上都增加了一个日志采集模块,通过日志采集模块收集服务器上的各个应用的日志信息。logstash shipper根据配置将各应用日志采集到redis集群中,logstash shipper会为各个应用定义唯一type用来以后生成索引用。
日志缓存模块603,用于通过日志转储组件redis,将数据统一缓存在key 为logstash的名字中,采用list数据类型作为日志采集的一个缓存区队列;
在采集到各个应用的日志信息后,将采集到的各个应用的日志信息统一缓存在Key为logstash的名字中。redis作为日志转储组件可以有效提高系统可用性,使用集群或者主备结构代替单实例,可以有效提高组件的可用性。在redis中,数据统一缓存在key为logstash的名字中,采用list数据类型作为日志采集的一个缓存区队列,list类型是按照插入顺序排序的字符串链表,和数据结构中的普通链表一样,可以在其头部(left)和尾部(right)添加新的元素。
日志处理模块604,用于拉取日志信息,进行从原始数据到ElasticSearch 搜索服务器所要求的数据格式的转换;
然后,logstash indexer负责从redis拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换,例如,日期格式转换为预定义的格式,某些字段的去除、字段的合并转换、message信息json解析等,还有通过GeoIP获取ip所在地,根据系统定制过滤条件,正则解析等。
日志存储模块605,用于从日志信息中抓取关键字,基于关键字将对应的日志信息存入ElasticSearch搜索服务器;
从日志信息中抓取关键字,判断出应该写入到ElasticSearch的哪个index 中,并将信息存入对应的index,完成将日志信息存入ElasticSearch搜索服务器。日志存储在ElasticSearch中,同样ElasticSearch也是使用集群方式来进行部署,通过cluster.name来定义集群名称。ElasticSearch集群节点分为两种类型:master node、data node。Masternode:集群的管理节点,主要功能是维护元数据,管理集群各个节点的状态。Data node:负责数据的存储、查询和导入。
日志展示模块606,用于在ElasticSearch搜索服务器的索引中查找、交换数据,生成相应的图表,展示图表。
本日志系统的界面使用了kibana开源框架,为Elasticsearch提供分析和可视化的Web平台。它可以在Elasticsearch的索引中查找,交互数据,并生成各种维度的表图。主要展示信息包括:日志数量变化趋势图、日志TOPN 的实例图、失败时间日志分析图、日志查询结果。
综上所述,在上述实施例中,在日志管理时,首先将配置在各个应用中的拦截器生成的request ID,以及收集的应用的调用信息和用户信息输出至日志中,然后在分布式场景下,采集各个应用服务器上各个应用的日志信息,将各个应用的日志信息统一缓存在Key为logstash的名字中,拉取日志信息,进行从原始数据到ElasticSearch搜索服务器所要求的数据格式的转换;从日志信息中抓取关键字,基于关键字将对应的日志信息存入ElasticSearch搜索服务器。本发明通过RequestID能查询出整个请求的调用链日志详情,对于排查异常、快速定位非常方便快捷。同时,在日志收集、缓存、处理、存储等各个阶段均采用分布式、微服务化的部署方式,使日志处理的全流程均可根据实际使用情况,进行动态弹缩,有效地利用了物理资源,并能够应对大规模的日志,提高了查询和统计效率,并且能够进一步对ElasticSearch搜索服务器中的信息进行展示。
为了更加特定地强调实施的独立性,本说明书涉及许多模块或单元。举例而言,模块或单元可由硬件电路实现,该硬件电路包括特制VLSI电路或门阵列,比如逻辑芯片、晶体管,或其它组件。模块或单元也可在可编程的硬设备中实现,比如场效可编程门阵列、可编程阵列逻辑、可编程逻辑设备等等。
模块或单元也可在藉由各种形式的处理器所执行的软件中实现。比如说,一可执行码模块可包括一个或多个实体的或逻辑的计算机指令区块,该区块可能形成为,比如说,对象、程序或函数。然而,鉴别模块或单元的可执行部分不需要物理上放置在一起,但可由存于不同位置的不同指令所组成,当逻辑上组合在一起时,形成模块或单元且达到该模块或单元所要求的目的。
实际上,可执行码模块或单元可以是一单一指令或多个指令,甚至可以分布在位于不同的程序的数个不同的码区段,并且横跨数个存储设备。同样地,操作数据可被辨识及显示于此模块或单元中,并且可以以任何合适的形式实施且在任何合适的数据结构形式内组织。操作数据可以集合成单一数据集,或可分布在具有不同的存储设备的不同的位置,且至少部分地只以电子信号方式存在于一系统或网络。
本说明书所提及的“实施例”或类似用语表示与实施例有关的特性、结构或特征,包括在本发明的至少一实施例中。因此,本说明书所出现的用语“在一实施例中”、“在实施例中”以及类似用语可能但不必然都指向相同实施例。
再者,本发明所述特性、结构或特征可以以任何方式结合在一个或多个实施例中。以下说明将提供许多特定的细节,比如编程序、软件模块、用户选择、网络交易、数据库查询、数据库结构、硬件模块、硬件电路、硬件芯片等例子,以提供对本发明实施例的了解。然而相关领域的普通技术人员将看出本发明,即使没有利用其中一个或多个特定细节,或利用其它方法、组件、材料等亦可实施。另一方面,为避免混淆本发明,公知的结构、材料或操作并没有详细描述。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。
专业人员还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。