分布式实时日志分析解决方案 ELK 部署架构.docx

《分布式实时日志分析解决方案 ELK 部署架构.docx》由会员分享，可在线阅读，更多相关《分布式实时日志分析解决方案 ELK 部署架构.docx（10页珍藏版）》请在第壹文秘上搜索。

1、一、概述E1.K已经成为目前最流行的集中式日志解决方案，它主要是由Beats.1.ogstash.Elasticsearch.Kibana等组件组成，来共同完成实时日志的收集,存储，展示等一站式的解决方案。本文将会介绍E1.K常见的架构以及相关问题解决.I-Filebeat:Filebeat是一款轻量级，占用服务资源非常少的数据收集引擎，它是E1.K家族的新成员，可以代替1.ogstash作为在应用服务器端的日志收集引擎,支持将收集到的数据输出到Kafka,Redis等队列.2 .1.ogstash:数据收集引孥,相较于Filebeat比较蚤量级，但它集成了大量的插件，支持丰富的数据源收集，对

2、收集的数据可以过遮，分析，格式化日志格式.3 .Elasticsearch:分布式数据搜索引擎,基于Apache1.ucene实现，可集群,提供数据的集中式存储，分析，以及强大的数据搜索和聚合功能.4 .Kibana：数据的可视化平台，通过该Web平台可以实时的杳看Elasticsearch中的相关数据，并梃供r丰富的图表统计功能，二.E1.K常见部署架构2.1 1.ogstash作为日志收集器这种架构是比较原始的部署架构，在各应用服务器端分别部署一个1.ogstash组件，作为日志收集器，然后将1.ogstash收集到的数据过速、分析、格式化处理后发送至Elasticsearch存储,最后使

3、用Kibana进行可视化展示，这种架构不足的是：1.ogstash比较耗服务器资源，所以会增加应用服务器端的负载压力。2.2 Filebeat作为日志收集器该架构与第一种架构唯一不同的是：应用端日志收集器换成了Filebeat,Filebeat轻量，占用服务器资源少，所以使用Filebeat作为应用服务器端的日志收集器，一般Filebeat会配合1.ogstash一起使用，这种部署方式也是目前最常用的架2.3 引入缓存队列的部署架构该架构在第二种架构的基础上引入了Kafka消息队列（还可以是其他消息队列将Filebeat收集到的数据发送至Kafka,然后在通过1.ogstasth读取Kafka

4、中的数据，这种架构主要是解决大数据量下的日志收集方案，使用缓存队列主要是解决数据安全与均衡1.ogstash与ElaStiCSearCh负载压力.2.4以上三种架构的总结第一种部署架构由于资源占用问题现已很少使用目前使用最多的是笫二种部署架构.至于第三种部署架构个人觉得没有必要引入消息队列，除非有其他儒求，因为在数据技较大的情况下，Filebeat使用压力敏感协以向1.ogstash或Elasticsearch发送数据.如果1.ogstash正在繁忙地处理数据，它会告知Filebeat诚微读取速度.拥塞解决后，FiIebeal将恢更初始速度并继续发送数据。三、问题及解决方案问题：如何实现日志的

5、多行合并功能？系统应用中的日志一般都是以特定格式进行打印的，属于同一条日志的数据可能分多行进行打印，那么在使用E1.K收集日志的时候就需要将属于同一条日志的多行数据进行合并.解决方案：使用Filebeat或1.ogstash中的multiline多行合并插件来实现在使用multiline多行合并插件的时候需要注意，不同的E1.K部署架构可能multiline的使用方式也不同，如果是本文的第一种部署架构，那么multiline需要在1.ogstash中配置使用，如果是第二种那善架构,那么multiline需要在Filebeat中配置使用,无需再在1.ogstash中配普multiline.1、m

6、ultiline在Filebeat中的配诲方式:)aths:negate:trhosts:localhost:5044pattern:正则表达式negate:默认为false,表示匹配pattern的行合并到上一行；true表示不匹配pattern的行合井到上一行match:after表示合并到上一行的末尾,before表示合并到上一行的行attern:legate:true!fter该配爸表示将不匹配pattern模式的行合并到上一行的末尾2、multiline在1.ogstash中的配置方式beatsernegatetrueWhat.previous(1)1.ogstash中配置的What

7、属性值为previous,相当于Filebeat中的after,1.ogstash中配笆的what属性值为next,相当于Filebeat中的before.(2)pattern=%1.OG1.EVE1.)s*中的1.OG1.EVE1.是1.ogstash预制的正则匹配模式，预制的还有好多常用的正则匹配模式，详细请看：treemasterpatterns问题：如何将Kibana中显示日志的时间字段替换为日志信息中的时间？默认情况下,我们在Kibana中查看的时间字段与日志信息中的时间不一致，因为默认的时间字段值是日志收集时的当前时间，所以需要将该字段的时间替换为日志信息中的时间.解决方案：使用g

8、rok分词插件与date时间格式化插件来实现在1.ogstash的配置文件的过滤器中配百grok分词插件与date时间格式化插件，如：如，要匹配的日志格式为：”(DEBUG(2017081110:07:31,359DefaultBeanDefinitionDocumentReadeclOG1.oadingBeandefinitions,解析出该日志的时间字段的方式有：1.通过引入写好的表达式文件，如表达式文件为ClJStomCjPallerns,内容为：CUSTOMERTIME%YEAR%(MONTHNUM)%MONTHDAY)s-11(TIMI1注：内容格式为：自定义表达式名称正则表达式然后

9、logstash中就可以这样引用：Patterns_dir=“custiierpattermsmypatter11s/01IIJ五工区Kfl4彳）.tCUSTOMER11ME:J2.以配置项的方式，规则为：（?自定义表达式名称正则匹配规则,如:问SS：如何在Kibana中通过选择不同的系统日志模块来查看数据一般在Kibana中显示的日志数据混合了来自不同系统模块的数据，那么如何来选择或者过谑只查看指定的系统模块的日志数据？解决方案：新增标识不同系统模块的字段或根据不同系统模块建ES索引1.新增标识不同系统模块的字段，然后在Kibana中可以根据该字段来过速查询不同模块的数据这里以第二种部署架构

10、讲解，在Filebeat中的配置内容为:/新增logfrg字FIogfrom:accountjaths:multiline:通过新增：IogJrom字段来标识不同的系统模块日志2、根据不同的系统模块配署对应的ES索引，然后在Kibana中创建对应的索引模式匹配，即可在页面通过索引模式下拉框选择不同的系统模块数据.这里以第二种部署架构讲解，分为两步：在Filebeat中的配置内容为：afteUtnenJtype:Whosts:11oc31host:5044通过document.type来标识不同系统模块修改1.ogstash中OUtPUt的配首内容为：hostsIocslhost:92在output中增加index属性，type表示按不同的documenttype值建ES索引四、总结本文主要介绍了E1.K实时日志分析的三种部署架构，以及不同架构所能解决的问题，这三种架构中第二种部署方式是时下最流行也是最常用的部署方式，最后介绍了E1.K作在日志分析中的一些问题与解决方案，说在最后，E1.K不仅仅可以用来作为分布式日志数据集中式查询和管理，还可以用来作为项目应用以及服务器资源监控等场景,更多内容谙看官网.本内容由社区会员上传分享,仅供读者交流学习，版权归原作者所有,若所引用的图片.故据.文字等来源标注