ELK企业级日志分析系统

一、ELK 概述

1.ELK 简介

ELK平台是一套完整的日志集中处理解决方案，将 ElasticSearch、Logstash 和 Kiabana 三个开源工具配合使用， 完成更强大的用户对日志的查询、排序、统计需求。
●ElasticSearch：是基于Lucene（一个全文检索引擎的架构）开发的分布式存储检索引擎，用来存储各类日志。
Elasticsearch 是用 Java 开发的，可通过 RESTful Web 接口，让用户可以通过浏览器与 Elasticsearch 通信。
Elasticsearch是一个实时的、分布式的可扩展的搜索引擎，允许进行全文、结构化搜索，它通常用于索引和搜索大容量的日志数据，也可用于搜索许多不同类型的文档。

●Kiabana：Kibana 通常与 Elasticsearch 一起部署，Kibana 是 Elasticsearch 的一个功能强大的数据可视化 Dashboard，Kibana 提供图形化的 web 界面来浏览 Elasticsearch 日志数据，可以用来汇总、分析和搜索重要数据。

●Logstash：作为数据收集引擎。它支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储到用户指定的位置，一般会发送给 Elasticsearch。
Logstash 由 Ruby 语言编写，运行在 Java 虚拟机（JVM）上，是一款强大的数据处理工具， 可以实现数据传输、格式处理、格式化输出。Logstash 具有强大的插件功能，常用于日志处理。

可以添加的其它组件：
●Filebeat：轻量级的开源日志文件数据搜集器。通常在需要采集数据的客户端安装 Filebeat，并指定目录与日志格式，Filebeat 就能快速收集数据，并发送给 logstash 进行解析，或是直接发给 Elasticsearch 存储，性能上相比运行于 JVM 上的 logstash 优势明显，是对它的替代。常应用于 EFLK 架构当中。

filebeat 结合 logstash 带来好处：
1）通过 Logstash 具有基于磁盘的自适应缓冲系统，该系统将吸收传入的吞吐量，从而减轻 Elasticsearch 持续写入数据的压力
2）从其他数据源（例如数据库，S3对象存储或消息传递队列）中提取
3）将数据发送到多个目的地，例如S3，HDFS（Hadoop分布式文件系统）或写入文件
4）使用条件数据流逻辑组成更复杂的处理管道

使用Filebeat代替Logstash去收集数据，可以直接去部署，不用在部署jdk了，不用运行在jvm上了，可以直接运行，可以收集轻量级的应用，占用空间小，可以直接收集日志数据，如不想处理，可直接发送给ElasticSearch存储。通常来讲，要让Logstash先做格式化的转换处理，再发送给ElasticSearch存储，最后由Kiabana进行图形化界面浏览。

●缓存/消息队列（redis、kafka、RabbitMQ等）：可以对高并发日志数据进行流量削峰和缓冲，这样的缓冲可以一定程度的保护数据不丢失，还可以对整个架构进行应用解耦。

●Fluentd：是一个流行的开源数据收集器。由于 logstash 太重量级的缺点，Logstash 性能低、资源消耗比较多等问题，随后就有 Fluentd 的出现。相比较 logstash，Fluentd 更易用、资源消耗更少、性能更高，在数据处理上更高效可靠，受到企业欢迎，成为 logstash 的一种替代方案，常应用于 EFK 架构当中。在 Kubernetes 集群中也常使用 EFK 作为日志数据收集的方案。
在 Kubernetes 集群中一般是通过 DaemonSet 来运行 Fluentd，以便它在每个 Kubernetes 工作节点上都可以运行一个 Pod。 它通过获取容器日志文件、过滤和转换日志数据，然后将数据传递到 Elasticsearch 集群，在该集群中对其进行索引和存储。

2.为什么要使用 ELK

日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠正错误。
往往单台机器的日志我们使用grep、awk等工具就能基本实现简单分析，但是当日志被分散的储存不同的设备上。如果你管理数十上百台服务器，你还在使用依次登录每台机器的传统方法查阅日志。这样是不是感觉很繁琐和效率低下。当务之急我们使用集中化的日志管理，例如：开源的syslog，将所有服务器上的日志收集汇总。集中化管理日志后，日志的统计和检索又成为一件比较麻烦的事情，一般我们使用 grep、awk和wc等Linux命令能实现检索和统计，但是对于要求更高的查询、排序和统计等要求和庞大的机器数量依然使用这样的方法难免有点力不从心。
一般大型系统是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套集中式日志系统，可以提高定位问题的效率。

3.完整日志系统基本特征

收集：能够采集多种来源的日志数据
传输：能够稳定的把日志数据解析过滤并传输到存储系统
存储：存储日志数据
分析：支持 UI 分析
警告：能够提供错误报告，监控机制

4.ELK 的工作原理

（1）在所有需要收集日志的服务器上部署Logstash；或者先将日志进行集中化管理在 日志服务器上，在日志服务器上部署 Logstash。
（2）Logstash 收集日志，将日志格式化并输出到 Elasticsearch 群集中。
（3）Elasticsearch 对格式化后的数据进行索引和存储。
（4）Kibana 从 ES 群集中查询数据生成图表，并进行前端数据的展示。
总结：logstash作为日志搜集器，从数据源采集数据，并对数据进行过滤，格式化处理，然后交由Elasticsearch存储，kibana对日志进行可视化处理。

二、ELK Elasticsearch 集群部署

1.部署

node1节点（2C/4G）：node1/192.168.169.10 Elasticsearch（es01）
node2节点（2C/4G）：node2/192.168.169.20 Elasticsearch（es02）
Apache节点：apache/192.168.169.30 Logstash Kibana Apache (web01)

所有主机都需关防火墙安全机制

systemctl stop firewalld
setenforce 0

环境准备
设置dns域名解析
#所有主机需部署

vim /etc/hosts
...
192.168.169.30 web01
192.168.169.10 es01
192.168.169.20 es02
...

设置Java环境

java -version										#如果没有安装，yum -y install java
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-b12)
OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)

2.部署 Elasticsearch 软件

（1）安装elasticsearch—rpm包

#上传elasticsearch-6.7.2.rpm到/opt目录下
cd /opt
rpm -ivh elasticsearch-6.7.2.rpm
（2）修改elasticsearch主配置文件
cp /etc/elasticsearch/elasticsearch.yml /etc/elasticsearch/elasticsearch.yml.bak
vim /etc/elasticsearch/elasticsearch.yml
--17--取消注释，指定集群名字
cluster.name: my-elk-cluster
--23--取消注释，指定节点名字：Node1节点为node1，Node2节点为node2
node.name: node1
node.master: true		#是否master节点，false为否
node.data: true			#是否数据节点，false为否
--33--取消注释，指定数据存放路径
path.data: /var/lib/elasticsearch
--37--取消注释，指定日志存放路径
path.logs: /var/log/elasticsearch
--43--取消注释，避免es使用swap交换分区
bootstrap.memory_lock: true
--55--取消注释，设置监听地址，0.0.0.0代表所有地址
network.host: 0.0.0.0
--59--取消注释，ES 服务的默认监听端口为9200
http.port: 9200					#指定es集群提供外部访问的接口
transport.tcp.port: 9300		#指定es集群内部通信接口
--68--取消注释，集群发现通过单播实现，指定要发现的节点
discovery.zen.ping.unicast.hosts: ["192.168.169.10:9300", "192.168.169.20:9300"]
grep -v "^#" /etc/elasticsearch/elasticsearch.yml

**能调优参数**
#优化最大内存大小和最大文件描述符的数量
vim /etc/security/limits.conf
......
*  soft    nofile          65536
*  hard    nofile          65536
*  soft    nproc           32000
*  hard    nproc           32000
*  soft    memlock         unlimited
*  hard    memlock         unlimited

vim /etc/systemd/system.conf
DefaultLimitNOFILE=65536
DefaultLimitNPROC=32000
DefaultLimitMEMLOCK=infinity

需重启生效
优化elasticsearch用户拥有的内存权限
由于ES构建基于lucene, 而lucene设计强大之处在于lucene能够很好的利用操作系统内存来缓存索引数据，以提供快速的查询性能。lucene的索引文件segements是存储在单文件中的，并且不可变，对于OS来说，能够很友好地将索引文件保持在cache中，以便快速访问；因此，我们很有必要将一半的物理内存留给lucene ; 另一半的物理内存留给ES（JVM heap )。所以， 在ES内存设置方面，可以遵循以下原则：
1.当机器内存小于64G时，遵循通用的原则，50%给ES，50%留给操作系统，供lucene使用
2.当机器内存大于64G时，遵循原则：建议分配给ES分配 4~32G 的内存即可，其它内存留给操作系统，供lucene使用

vim /etc/sysctl.conf
#一个进程可以拥有的最大内存映射区域数，参考数据（分配 2g/262144，4g/4194304，8g/8388608）
vm.max_map_count=262144
sysctl -p
sysctl -a | grep vm.max_map_count

（4）启动elasticsearch是否成功开启

systemctl start elasticsearch.service
systemctl enable elasticsearch.service
netstat -antp | grep 9200

5）查看节点信息
浏览器访问 http://192.168.169.10:9200 、 http://192.168.169.20:9200 查看节点 Node1、Node2 的信息

总结