ELK 集群搭建总结
因公司开发人员查询线上日志困难需求，故计划搭建 ELK 系统解决这一问题。了解到之前搭建过单机单节点的 ELK，但由于负载内存过高，停止弃用了。所以这次准备了三台性能不错的服务器，开始搭建 ELK 集群。
过程曲折且艰辛，记录下来以备不时之需。
由于这种方案，每个 logstash 都需要占用较大内存，这对线上各日志收集的应用服务器，压力太大难以承受。
filebeat是一个轻量级的日志采集器，部署简单占用内存小。这一方案总体上比较好了，只是 logstash 这一节点的压力比较大，查询到filebeat可以负载均衡输出到多个logstash，所以后边考虑了在准备的三台 elk 服务器上都安装一个 logstash ，这样就实现了下边这一方案。
上边的方案其实已经能够满足一般公司的日志需求，但超大的日志数量可能会存在数据错乱缺失，节点脑裂等多个问题。要尽量解决这些问题，要做的工作还很多，这里收集部分网上的建议，记录如下：
在个服务器上通过 yum install -y ***.rpm 直接快速安装
安装后程序位置都在 /usr/share/ 下
配置文件都在 /etc/ 下
建议用 ansible 管理
启动：elasticsearch --- logstash --- filebeat --- kibana
停止：kibana --- filebeat --- logstash --- elasticsearch
「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全家桶下载主页： https://www.elastic.co/cn/downloads/
我们选择如下版本：
Kafka下载：
??安装前先准备好三台CentOS7服务器用于集群安装，这是IP地址为：172.16.20.220、172.16.20.221、172.16.20.222，然后将上面下载的软件包上传至三台服务器的/usr/local目录。因服务器资源有限，这里所有的软件都安装在这三台集群服务器上，在实际生产环境中，请根据业务需求设计规划进行安装。
??在集群搭建时，如果能够编写shell安装脚本就会很方便，如果不能编写，就需要在每台服务器上执行安装命令，多数ssh客户端提供了多会话同时输入的功能，这里一些通用安装命令可以选择启用该功能。
新建/usr/local/java目录
将下载的jdk软件包jdk-8u64-linux-x64.tar.gz上传到/usr/local/java目录，然后解压
配置环境变量/etc/profile
在底部添加以下内容
使环境变量生效
备注：后续可通过此命令停止elasticsearch运行
??新建kafka的日志目录和zookeeper数据目录，因为这两项默认放在tmp目录，而tmp目录中内容会随重启而丢失,所以我们自定义以下目录:
修改如下：
在data文件夹中新建myid文件，myid文件的内容为1（一句话创建：echo 1 > myid）
kafka启动时先启动zookeeper，再启动kafka；关闭时相反，先关闭kafka，再关闭zookeeper。
1、zookeeper启动命令
后台运行启动命令：
或者
查看集群状态：
2、kafka启动命令
后台运行启动命令：
或者
3、创建topic，最新版本已经不需要使用zookeeper参数创建。
参数解释:
复制两份
--replication-factor 2
创建1个分区
--partitions 1
topic 名称
--topic test
4、查看已经存在的topic（三台设备都执行时可以看到）
5、启动生产者：
6、启动消费者：
添加参数 --from-beginning 从开始位置消费，不是从最新消息
7、测试：在生产者输入test，可以在消费者的两台服务器上看到同样的字符test，说明Kafka服务器集群已搭建成功。
Logstash没有提供集群安装方式，相互之间并没有交互，但是我们可以配置同属一个Kafka消费者组，来实现统一消息只消费一次的功能。
??Filebeat用于安装在业务软件运行服务器，收集业务产生的日志，并推送到我们配置的Kafka、Redis、RabbitMQ等消息中间件，或者直接保存到Elasticsearch，下面来讲解如何安装配置：
1、进入到/usr/local目录，执行解压命令
2、编辑配置filebeat.yml
??配置文件中默认是输出到elasticsearch，这里我们改为kafka，同文件目录下的filebeat.reference.yml文件是所有配置的实例，可以直接将kafka的配置复制到filebeat.yml
后台启动命令
停止命令
2、测试logstash是消费Kafka的日志主题，并将日志内容存入Elasticsearch
自动新增的两个index，规则是logstash中配置的
数据浏览页可以看到Elasticsearch中存储的日志数据内容，说明我们的配置已经生效。
Gitee: GitEgg: GitEgg 是一款开源免费的企业级微服务应用开发框架，旨在整合目前主流稳定的开源技术框架，集成常用的最佳项目解决方案，实现可直接使用的微服务快速开发框架。
GitHub: https://github.com/wmz1930/GitEgg
一次系统扩容引起的elasticsearch故障及恢复
在公司搭建了elk集群，集群配置如下：
由于m21p22服务器配置比较老旧，而且上面还有其他人部署的其他应用。硬盘写入性能比较差，因此考虑吧elasticsearch部署在另外两台配置高的服务器，而将kibana、redis等与硬盘关系不大的软件部署在m21p22服务器。考虑到部署的复杂性以及服务器的实际情况，选择了redis接收beats的日志数据，再通过logstash实现负载均衡。这是之前elk集群的配置情况。
随着业务的深入，上述集群已经越来越难以满足业务的需要，日志量大会在redis中出现堆积，另外服务器查询量大之后，节点的cpu和load会触发告警。因此，与运维部门商议，又申请了2台服务器，作为elasticsearch的扩展节点，以降低原有服务器的负载。
如下是增加服务器之后的配置信息：
在新增加服务器到位之后，第一件事情就是决定将elasticsearch扩容。每台服务器部署2个节点，将原有集群扩大一倍，由4个节点扩大到8个节点。
原有节点：
扩展节点：
按上述配置对新增节点进行扩展，只需要配置好参数：
discovery.zen.ping.unicast.hosts: ["192.168.21.23", "192.168.21.24","192.168.21.88","192.168.21.89"]
新增节点就可以加入集群进行水平扩容。当上述操作都完成之后，新节点已加入集群，开始同步数据。
考虑到系统并未设置索引分片，全部索引一律采用的是系统默认的5个分片，而每个索引的数据可能大小不一，结果检查，决定将数据量较大的索引，分片数增加一倍。
操作如下：
注意，在采取put操作时，先采用get操作，得到_template信息，之后对需要修改的部分进行增加或者修改操作，之后再进行put。这样保证其他不需要修改的数据不会被修改。
在做完上述这一切之后，已是晚上8点，因此打卡下班。
早上还没到单位，就被同事信息轰炸，elk集群已经不能用了！！
我赶到单位之后，连上服务器一看，新加入的节点全部处于假死状态。已经有大部分数据同步到新节点，而且服务器已无法连接。通知运维人员将elasticsearch进程干掉。
如下是恢复的过程中某个节点假死查到的状态：
对上述节点进行重启，集群状态恢复中。。
redis内存在迅速增加，已经达到10个G
查看logstash日志：
出现如下提示：
原来是宕机节点太多，导致部分节点的主分片未分配。这样日志在写入过程中会超时。这就导致logstash的写入速度下降。从而导致redis中数据增加。
至于节点假死的原因，查看了elasticsearch的日志：
发现一个关键的问题：/opt/elasticsearch/node6/data/nodes/0/indices/NP2tORUfSq6jl0lb5CzOVw/2/translog/translog.ckp: Too many open files in system
也就是说同时打开的文件数达到了系统的限制，这也就是无法登陆系统的原因。
不难理解上述问题的出现：一个服务器中配置了两个节点，这两个节点都运行在elastic用户下，该用户所在系统的limit.conf中对该用户同时打开的文件数有限制。而在集群同步数据的过程中，系统在大量的写文件，同时实时数据又在大量写入。这样就导致文件达到最大的阈值。因此导致elasticsearch假死。
查询elasticsearch节点状态：
当天需要写入数据的索引，也存在部分分片未分配状态：
通过kibana也可发现该问题：
考虑到redis缓存一直增加，当务之急是让数据可以写入。保证redis的数据被消费。否则会出现redis服务器内存溢出。
先不考虑elasticsearch是否能自动恢复，以及自动恢复所花费的时间。
查询API后，要用到命令：reroute
通过kibana分配一个主分片
命令格式参考
需要注意的是，对于主分片执行reroute，一定需要所分配的节点上存在该索引的文件，否则会提示找不到索引：
在分配主分片的时候，一定要确认所分配的节点是否存在该索引的文件。
上述问题 虽然恢复，数据可以写入，但是还有几个地方需要优化：
1.redis作为负载均衡存在问题，在服务器节点充足之后，应该用kafka来替代redis，将数据放置在磁盘。避免redis内存溢出。
2.elasticsearch扩容时，如果有多个节点，尽量避免同时操作。如果一次性增加的节点比较多，就需要考虑文件是否达到最大limit配置的阈值。
ELK 构建 MySQL 慢日志收集平台
本文讲解如何通过一套开源日志存储和检索系统 ELK 构建 MySQL 慢日志收集及分析平台。
ELK、EFK 简介
想必你对 ELK、EFK 都不陌生，它们有一个共同的组件：Elasticsearch（简称ES），它是一个实时的全文搜索和分析引擎，可以提供日志数据的收集、分析、存储 3 大功能。另外一个组件 Kibana 是这套检索系统中的 Web 图形化界面系统，可视化展示在 Elasticsearch 的日志数据和结果。
ELF/EFK 工具集中还有 l 和 F 这两个名称的缩写，这两个缩写代表的工具根据不同的架构和使用方式而定。
L 通常是 Logstash 组件，它是一个用来搜集、分析、过滤日志的工具 。
F 代表 Beats 工具（它是一个轻量级的日志采集器），Beats 家族有 6 个成员，Filebeat 工具，它是一个用于在客户端收集日志的轻量级管理工具。
F 也可以代表工具 fluentd，它是这套架构里面常用的日志收集、处理转发的工具。
那么它们（Logstash VS Beats VS fluentd）有什么样的区别呢？Beats 里面是一个工具集，其中包含了 Filebeat 这样一个针对性的日志收集工具。Logstash 除了做日志的收集以外，还可以提供分析和过滤功能，所以它的功能会更加的强大。
Beats 和 fluentd 有一个共同的特点，就是轻量级，没有 Logstash 功能全面。但如果比较注重日志收集性能，Beats 里面的 Filebeat 和 fluentd 这两个工具会更有优势。
Kafka 是 ELK 和 EFK 里面一个附加的关键组件（缩写 K），它主要是在支持高并发的日志收集系统里面提供分布式的消息队列服务。
ELK 的优势
在此之前，先介绍 ELK 日志分析会有一些什么样的优势？主要有 3 点：
1、它是一套开源、完整的日志检索分析系统，包含收集、存储、分析、检索工具。我们不需要去开发一些额外的组件去完成这套功能，因为它默认的开源方式就提供了一整套组件，只要组合起来，就可以完成从日志收集、检索、存储、到整个展示的完整解决方案了。
2、支持可视化的数据浏览。运维人员只要在控制台里选择想关注的某一段时间内的数据，就可以查看相应的报表，非常快捷和方便。
3、它能广泛的支持一些架构平台，比如我们现在讲到的 K8s 或者是云原生的微服务架构。
Kafka 作为日志消息队列，客户端通过 Filebeat 收集数据（日志）后将其先存入 Kafka，然后由 Logstash 提取并消费，这套架构的好处是：当我们有海量日志同步情况下，直接存入服务端 ES 很难直接应承接海量流量，所以 Kafka 会进行临时性的存取和缓冲，再由 Logstash 进行提取、过滤，通过 Logstash 以后，再把满足条件的日志数据存入 ES。
ES 不再是以单实例的方部署，而是采用集群架构，考虑 Kafka 的集群模式， Logstash 也使用集群模式。
我们会看到这套架构稍微庞大，大中型的企业往往存储海量数据（上百 T 或 P 级）运维日志、或者是系统日志、业务日志。
完成ELK服务搭建后，首先我需要开启的是 MySQL 的慢查询配置，那么通过 set global slow_query_log=‘ON‘，这样就可以开启慢查询日志，还需要设置好慢查询日志标准是大于 1 秒的，那么同样是 set global long_query_time 大于或等于 1，它的意思是大于 1 秒的查询语句，才会认为是慢查询，并且做日志的记录。
那么另外还要设置慢查询日志的位置，通过 set global slow_query_log = 日志文件路径，这里设置到 filebeat 配置监听的路径下，就完成了慢查询日志的路径设置。
配置完成以后，需要在 MySQL 终端上，模拟执行一条执行时间较长的语句，比如执行 select sleep(5)，这样就会模拟执行一条查询语句，并且会让它休眠 5 秒。接下来我们看到服务端窗口的 MySQL 这条 sleep 语句已经执行完毕了，同时我们可以再打开 filebeat 的推送窗口，发现这里产生了一条推送日志，表示成功地把这条日志推送给了 ES。
那么接下来我们就可以通过浏览器打开 Kibana 的管理后台，从界面里来看一看检索日志的记录和一些可视化展示的图表，我们可以点击界面上的 Discover 按钮，同时选择好对应的时间周期，然后可以增加一个 filter 过滤器，过滤器里面敲入对应的关键字来进行索引。
这里我敲入的是 slow.query 这个关键字，就会匹配出对应的可以检索的项目，点击想要查询的对应项目，展示出想检索的某一个时间周期内对应的一些日志记录，以及它的图表是什么样子的，同时在下方会有对应的 MySQL 的日志信息打印出来，通过 Kibana 这样的可视化界面就能够看到的相关信息了。
Spring Boot教程第22篇:整合elk,搭建实时日志平台
这篇文章主要介绍springboot整合elk.
elk 简介
elk下载安装
elk下载地址：
建议在 linux上运行，elk在windows上支持得不好，另外需要jdk1.8 的支持，需要提前安装好jdk.
下载完之后： 安装，以logstash为栗子：
配置、启动 Elasticsearch
打开Elasticsearch的配置文件：
修改配置:
network.host=localhost
network.port=9200
它默认就是这个配置，没有特殊要求，在本地不需要修改。
启动Elasticsearch
启动成功，访问localhost:9200,网页显示：
配置、启动 logstash
在 logstash的主目录下：
修改 log4j_to_es.conf 如下：
input {
log4j {
mode => "server"
host => "localhost"
port => 4560
}
}
filter {
#Only matched data are send to output.
}
output {
elasticsearch {
action => "index" #The operation on ES
hosts => "localhost:9200" #ElasticSearch host, can be array.
index => "applog" #The index to write data to.
}
}
修改完配置后启动：
./bin/logstash -f config/log4j_to_es.conf
终端显示如下：
访问localhost:9600
证明logstash启动成功。
配置、启动kibana
到kibana的安装目录：
默认配置即可。
访问localhost:5601，网页显示：
证明启动成功。
创建springboot工程
起步依赖如下：
log4j的配置，／src/resources/log4j.properties如下：
log4j.rootLogger=INFO,console
# for package com.demo.elk, log would be sent to socket appender.
log4j.logger.com.forezp=DEBUG, socket
# appender socket
log4j.appender.socket=org.apache.log4j.net.SocketAppender
log4j.appender.socket.Port=4560
log4j.appender.socket.RemoteHost=localhost
log4j.appender.socket.layout=org.apache.log4j.PatternLayout
log4j.appender.socket.layout.ConversionPattern=%d [%-5p] [%l] %m%n
log4j.appender.socket.ReconnectionDelay=10000
# appender console
log4j.appender.console=org.apache.log4j.ConsoleAppender
log4j.appender.console.target=System.out
log4j.appender.console.layout=org.apache.log4j.PatternLayout
log4j.appender.console.layout.ConversionPattern=%d [%-5p] [%l] %m%n
打印log测试：
在kibana 实时监控日志
打开localhost:5601:
Management=>index pattrns=>add new:
点击discovery: