「SpringCloud」（三十八）搭建ELK日志采集与分析系统

 一套好的日志分析系统可以详细记录系统的运行情况，方便我们定位分析系统性能瓶颈、查找定位系统问题。上一篇说明了日志的多种业务场景以及日志记录的实现方式，那么日志记录下来，相关人员就需要对日志数据进行处理与分析，基于E(ElasticSearch)L(Logstash)K(Kibana)组合的日志分析系统可以说是目前各家公司普遍的首选方案。

  作为微服务集群，必须要考虑当微服务访问量暴增时的高并发场景，此时系统的日志数据同样是爆发式增长，我们需要通过消息队列做流量削峰处理，Logstash官方提供Redis、Kafka、RabbitMQ等输入插件。Redis虽然可以用作消息队列，但其各项功能显示不如单一实现的消息队列，所以通常情况下并不使用它的消息队列功能；Kafka的性能要优于RabbitMQ，通常在日志采集，数据采集时使用较多，所以这里我们采用Kafka实现消息队列功能。

  ELK日志分析系统中，数据传输、数据保存、数据展示、流量削峰功能都有了，还少一个组件，就是日志数据的采集，虽然log4j2可以将日志数据发送到Kafka，甚至可以将日志直接输入到Logstash，但是基于系统设计解耦的考虑，业务系统运行不会影响到日志分析系统，同时日志分析系统也不会影响到业务系统，所以，业务只需将日志记录下来，然后由日志分析系统去采集分析即可，Filebeat是ELK日志系统中常用的日志采集器，它是 Elastic Stack 的一部分，因此能够与 Logstash、Elasticsearch 和 Kibana 无缝协作。

软件下载：

  因经常遇到在内网搭建环境的问题，所以这里习惯使用下载软件包的方式进行安装，虽没有使用Yum、Docker等安装方便，但是可以对软件目录、配置信息等有更深的了解，在后续采用Yum、Docker等方式安装时，也能清楚安装了哪些东西，安装配置的文件是怎样的，即使出现问题，也可以快速的定位解决。

Elastic Stack全家桶下载主页： >

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来保障服务的高可用性，以此提升整个架构的稳定性。

日志文件的话开头都有记录时间的,具体是什么格式记录的,需要你自己去看下在利用date命令获取当前日期时间,对比一下,提取自己需要的内容。具体怎么写脚本你可以把你的日志内容等相关信息上传上来。

访问日志的话没有指定路径，在安装目录的logs目录下，指定的话就看到指定什么路径了 另外NGINX+PHP的话，错误日志不好找，要开启PHP的日志，可以使用系统日志（/var/log/message)，也可以自己指定路径

nginx的log_format可以自主选择参数用于指示服务器的活动状态，默认的是：

假设将nginx服务器作为web服务器，位于负载均衡设备，nginx反向代理之后，不能获取到客户端的真实ip地址了。

原因是进过反向代理后，由于在客户端和web服务器之间增加了中间层，因此web服务器无法直接拿到客户端的ip。通过$remote_addr变量拿到的将是反向代理服务器的ip地址，但是，反向代理服务器在转发请求的>

我们这里用到的是 filebeat+elk(elasticsearch+logstash+kibana) 来进行系统日志的收集。filebeat安装在各个服务器中，Logstash+ElasticSearch+Kibana安装在一台专门用于基础服务的服务器上。

Filebeat是一个轻量级的托运人，用于转发和集中日志数据 Filebeat作为代理安装在服务器上，监视您指定的日志文件或位置，收集日志事件，并将它们转发到 ElasticSearch 或 Logstash 进行索引

官方中文文档： >

以上就是关于「SpringCloud」（三十八）搭建ELK日志采集与分析系统全部的内容，包括:「SpringCloud」（三十八）搭建ELK日志采集与分析系统、logstash在Elasticsearch中创建的默认索引模板问题、efk 日志集群架构了解等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！