基于Docker 快速搭建EFK日志中心

需要集中的日志系统的原因

目前现状，每个服务生产上有三台，定位生产问题，需要连上一台机器，然后使用 cd / tail / less / grep / sed / awk 等 linux命令去日志里查找故障原因。如果在这台机器没搜索到线索，就去另外两台机器上查日志。
但在分布式系统中，众多服务分散部署在数十台甚至上百台不同的服务器上，想要快速方便的实现查找、分析和归档等功能，使用Linux命令等传统的方式查询到想要的日志就费事费力，更不要说对日志进行分析与归纳了。
为解决大量日志归档，文件搜索慢，如何多维度查询就得需要集中化日志管理，将所有服务器上的日志收集汇总，常见的解决思路就是建立集中式日志收集系统。

EFK

• Elasticsearch：负责存储日志。Elasticsearch 是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful 风格接口，多数据源，自动搜索负载等。
• FileBeat：负责收集日志。
  • Filebeat 隶属于 Beats。目前 Beats 包含六种工具：Packetbeat（搜集网络流量数据）Metricbeat（搜集系统、进程和文件系统级别的 CPU 和内存使用情况等数据）Filebeat（搜集文件数据）Winlogbeat（搜集 Windows 事件日志数据）Auditbeat（ 轻量型审计日志采集器）Heartbeat（轻量级服务器健康采集器）
• Kibana：负责展示日志。Kibana可以为 Logstash 、Beats和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助汇总、分析和搜索重要数据日志。

注意：EFK 系统下的各个组件都非常吃内存，后期根据业务需要，EFK 的架构可进行扩展，当 FileBeat 收集的日志越来越多时，为防止数据丢失，可引入 Redis，而 ElasticSearch 也可扩展为集群，并使用 Head 插件进行管理， 所以要保证服务器有充足的运行内存和磁盘空间。

EFK 与 ELK 区别

EFK 和 ELK 只有一个区别， 收集日志的组件由 Logstash 替换成了 FileBeat，因为 Filebeat 相对于 Logstash 来说有2个好处：

1. 侵入低，无需修改 elasticsearch 和 kibana 的配置；
2. 性能高，IO 占用率比 logstash 小太多；

快速部署

离线安装Docker

# 1.下载Docker安装包(二进制) docker-19.03.1.tgz  https://download.docker.com/linux/static/stable/x86_64/ 
 yum install -y wget
 wget https://download.docker.com/linux/static/stable/x86_64/docker-19.03.1.tgz
 
 # 2.解压docker-19.03.1.tgz
 tar -zxvf docker-19.03.1.tgz
 
 # 3.复制docker目录下所有文件到/usr/bin目录下（/usr/bin是环境变量目录，在任意目录下都执行docker命令）
 cp docker/* /usr/bin
 
 # 4.添加docker到系统服务
 vi /etc/systemd/system/docker.service
 # 添加内容如下
 [Unit]
 Description=Docker Application Container Engine
 Documentation=https://docs.docker.com
 After=network-online.target firewalld.service
 Wants=network-online.target
 [Service]
 Type=notify
 # the default is not to use systemd for cgroups because the delegate issues still
 # exists and systemd currently does not support the cgroup feature set required
 # for containers run by docker
 ExecStart=/usr/bin/dockerd
 ExecReload=/bin/kill -s HUP 
 # Having non-zero Limit*s causes performance problems due to accounting overhead
 # in the kernel. We recommend using cgroups to do container-local accounting.
 LimitNOFILE=infinity
 LimitNPROC=infinity
 LimitCORE=infinity
 <
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30