0.基础架构：
说明：filebeat日志直接传送给es，直接从界面查看日志
1.架构图
使用filebeat收集日志直接写入kafka，然后再由logstash从kafka读取写到elasticsearch
其中各组件说明如下：
Filebeat：轻量级数据收集引擎。早期的ELK架构中使用Logstash收集、解析日志，但是Logstash对内存、cpu、io等资源消耗比较高。如果用它来对服务器进行日志收集，将加重服务器的负载。相比 Logstash，Beats所占系统的CPU和内存几乎可以忽略不计，所以filebeat作为一个轻量级的日志收集处理工具(Agent)，它可以用来替代Logstash，由于其占用资源少，所以更适合于在各个服务器上搜集日志后传输给Logstash，这也是官方推荐的一种做法。【收集日志】
Logstash：数据收集处理引擎。支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储以供后续使用。【对日志进行过滤、分析】
Elasticsearch：分布式搜索引擎。是基于Lucene的开源分布式搜索服务器，具有高可伸缩、高可靠、易管理等特点。可以用于全文检索、结构化检索和分析，并能将这三者结合起来。【搜集、分析、存储数据】
Kibana：可视化平台。它能够搜索、展示存储在 Elasticsearch 中索引数据。使用它可以很方便的用图表、表格、地图展示和分析数据。【图形化展示日志】
如果还是遇到性能瓶颈
使用filebeat收集日志，先转发到beat端的logstash1，然后logstash1转发到kafka，然后再由logstash2从kafka读取写到elasticsearch。
2.架构升级：
架构解释：
（1）首先用户通过nginx代理访问ELK日志统计平台，这里的Nginx可以设置界面密码。
（2）Nginx将请求转发到kibana
（3）kibana到Elasticsearch中去获取数据，这里的Elasticsearch是两台做的集群，日志数据会随机保存在任意一台Elasticsearch服务器。
（4）Logstash1从Kafka中取出数据并发送到Elasticsearch中。
（5）Kafka服务器做日志数据的持久化保存，避免web服务器日志量过大的时候造成的数据收集与保存不一致而导致日志丢失，其中Kafka可以做集群，然后再由Logstash服务器从Kafka持续的取出数据。
（6）logstash2从Filebeat取出的日志信息，并放入Kafka中进行保存。
（7）Filebeat在客户端进行日志的收集。
注1：【Kafka的加入原因与作用】
整个架构加入Kafka，是为了让整个系统更好的分层，Kafka作为一个消息流处理与持久化存储软件，能够帮助我们在主节点上屏蔽掉多个从节点之间不同日志文件的差异，负责管理日志端（从节点）的人可以专注于向 Kafka里生产数据，而负责数据分析聚合端的人则可以专注于从 Kafka内消费数据。所以部署时要把Kafka加进去。
而且使用Kafka进行日志传输的原因还在于其有数据缓存的能力，并且它的数据可重复消费，Kafka本身具有高可用性，能够很好的防止数据丢失，它的吞吐量相对来说比较好并且使用广泛。可以有效防止日志丢失和防止logsthash挂掉。综合来说：它均衡了网络传输，从而降低了网络闭塞，尤其是丢失数据的可能性，
注2：【双层的Logstash作用】
这里为什么要在Kafka前面增加二台logstash呢？是因为在大量的日志数据写入时，容易导致数据的丢失和混乱，为了解决这一问题，增加二台logstash可以通过类型进行汇总分类，降低数据传输的臃肿。
如果只有一层的Logstash，它将处理来自不同客户端Filebeat收集的日志信息汇总，并且进行处理分析，在一定程度上会造成在大规模日志数据下信息的处理混乱，并严重加深负载，所以有二层的结构进行负载均衡处理，并且职责分工，一层汇聚简单分流，一层分析过滤处理信息，并且内层都有二台Logstash来保障服务的高可用性，以此提升整个架构的稳定性。
