场景

在项目初期的时候，大家都是赶着上线，一般来说对日志没有过多的考虑，当然日志量也不大，所以用log4j等框架打印日志到文件就够了，随着应用的越来越多，日志散落在各个服务器的logs文件夹下，因此有点不大方便。

当我们需要查看日志的时候，很多时候都是直接在服务器中使用tail等命令查看日志。当我们需要日志分析的时候你大概会这么做：直接在日志文件中 grep、awk 就可以获得自己想要的信息。

那你们想过这种方式的问题吗？

1.日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询

2.应用太多，面临数十上百台应用时你该怎么办

3.随意登录服务器查询log对系统的稳定性及安全性肯定有影响

4.如果开发人员对Linux不太熟练那面对庞大的日志简直要命。

ELK因此就应运而生，那么为什么要用ELK呢？ELK又能给我们解决哪些问题呢？

1.日志统一收集，管理，访问。查找问题方便安全:收集放到搜索引擎中。也就就是ELK中的E表示elasticsearch：分布式搜索引擎存储库。是一个Nosql。其核心是倒排索引库。可存TB级的数据。

2.使用简单，可以大大提高定位问题的效率：一个页面搞定所有查询。K：kibana。

3.可以对收集起来的log进行分析。L：Logstash，就是用收集日志。会部署到应用服务器上面。还可以提供过滤功能。

4.能够提供错误报告，监控机制。

ELK架构设计

ELK是三个开源软件的缩写，分别表示：Elasticsearch , Logstash, Kibana , 它们都是开源软件

1. LogStash

它可以流放到各自的服务器上收集Log日志，通过内置的ElasticSearch插件解析后输出到ES中

2.ElasticSearch

这是一个基于Lucene的分布式全文搜索框架，可以对logs进行分布式存储，有点像hdfs。此为ELK的核心组件，日志的分析以及存储全部由es完成，因此在后面的课程中我们还会对此进行重点讲解。

3. Kibana：论坛。大屏展示

它可以多维度的展示es中的数据。可提供图表展示，造出一些非常炫酷的页面。这也解决了用mysql存储带来了难以可视化的问题。他提供了丰富的UI组件，简化了使用难度，数据在es中的展示是比较让人蛋疼的，后面再讲es的时候让大家看看。

目前ELK主要有两种框架：

1.普通框架：这一套框架不会影响生产环境应用。唯一影响的就是logstash会耗一点系统资源。

2.个性化扩展框架（针对日志数据需要二次处理以及多方使用的场景）：kafka(不建议用，除非针对TB数据) + Filebeat（数据量过大的时候或者应用服务器性能不足的时候部署在应用和Logstash之间）

我们的交流基地，“JAVA互联网技术交流：789650498”欢迎小伙伴们一起来交流：