ELK部署及实操

ELK是三个开源工具的缩写——Elasticsearch、Logstash、Kibana。

Elasticsearch：
开源分布式搜索引擎，提供搜索、分析、存储数据三大功能。特点包括分布式、零配置、自动发现、索引自动分片、索引副本机制、restful风格接口、多数据源、自动搜索负载等。

Logstash：
开源的日志搜集、分析、过滤工具，支持大量的数据获取方式。一般工作方式为C/S架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作后再发送到Elasticsearch上。

Kibana：
为Logstash和Elasticsearch提供友好的日志分析界面，帮助汇总、分析和搜索重要的数据日志。

Filebeat，新增的工具，轻量级的日志收集处理工具(Agent)，filebeat占用资源少，适用于在服务器上搜集日志后传输到logstash。

补充：Beats轻量级数据采集器，目前包含四种工具：

• Packetbeat——搜集网络流量数据

• Topbeat——搜集系统、进程、文件系统级别的CPU和内存使用情况

• Filebeat——搜索文件数据

• Winlogbeat——搜索windows事件日志数据

一般情况下进行日志分析时，可以直接在日志文件中使用grep、awk就可以获得想要的信息。但是，在规模较大的场景中此方法效率很低，面临的问题包括：日志量太大如何归档、文本检索太慢、如何多维度查询，需要集中化的日志管理所有服务器上的日志收集汇总。常见解决思路是建立集中式的日志收集系统，将所有节点上的日志统一收集、管理、访问。ELK提供了一整套解决方案，并且都开源，各组件相互配合使用，高效的满足了很多场景的应用，是目前主流的日志分析系统。

完整的集中式日志收集系统应包含以下主要特点：

• 收集——能够采集多种来源的日志数据

• 传输——能够稳定的把日志数据传输到核心系统

• 存储——如何存储日志数据

• 分析——支持UI分析

• 警告——提供监控机制及异常告警

最简单的ELK架构方式，此架构由logstash分布于各个节点上搜集相关日志、数据，并经过分析、过滤后发送到远端服务器上的Elasticsearch进行存储。Elasticsearch将数据以分片的形式压缩存储，并提供多种API供用户查询。也可更直观的通过配置Kibana对日志进行查询，并根据数据生成报表。

优点：搭建简单、易于上手

缺点：logstash资源消耗大，运行时占用较高的CPU和内存，且没有消息队列缓存，存在数据丢失隐患。

此种架构引入了消息队列机制，各个节点上的logstashAgent先将日志数据传递给kafka(或redis)，并将kafka队列中的消息或数据间接传递给logstash，logstash过滤、分析后将数据传递给elasticsearch进行存储。最后由kabana将日志和数据呈现在界面。因为引入了kafka(或redis)，所以即使远端logstash server因故障停止运行，数据将会先被存储下来，避免数据丢失。

此种架构将收集端logstash替换为beats，更灵活、消耗资源更少、扩展性更强。同时可配置logstash和elasticsearch集群用于支持大集群系统的运维日志数据监控和查询。

主要两个组件Prospectors和Harvesters，协同工作将文件的变动发送到指定的输出中。

每个文件会启动一个Harvester，Harvester会逐行读取文件内容，并将文件内容发送到指定的输出中。Harvester负责打开和关闭文件，即在Harvester运行时，文件描述符处于打开状态。如果文件在收集时被重命名或删除，Filebeat会继续读取此文件，所以在Harvester关闭之前磁盘不会被释放。默认情况下，filebeat会保持文件的打开状态，直到达到close_inactive。若close_inactive选项开启，filebeat会在指定时间内将不再更新的文件句柄关闭，时间从Harvester读取最后一行的时间开始计时。若文件句柄被关闭后，文件内容发生了变化，则会启动一个新的Harvester。关闭文件句柄的时间不取决于文件的修改时间，而是由scan_frequency参数决定，默认10s，若配置不当，则可能发生日志不实时的情况。Harvester使用内部时间戳来记录文件最后被收集的时间。如scan_frequency设置60s，则在Harvester读取文件最后一行后，开始倒计时60s，若文件60s内无变化，则关闭文件句柄。

Prospector会搜寻到/apps/logs/下所有的info.log文件，并为每个文件启动一个Harvester。Prospector会检查每个文件的Harvester是否已经启动、是否需要启动、或者文件是否可以忽略。若文件的Harvester已关闭，在有文件大小发生变化时Prospector才会执行检查，且Prospector只能检测本地文件。

将文件状态记录在registry文件中(默认在filebeat的data目录下)，状态中会记录Harvester收集文件的偏移量。filebeat会记录发送前的最后一行，并在可以连接的时候继续发送。filebeat运行时，Prospector的状态记录在内存中。重启filebeat时，利用registry记录的状态进行重建，用来还原到重启之前的状态。Prospector会为找到的每个文件记录一个状态，而对于每个文件，filebeat会存储唯一标识符以检测文件是否已经被收集。

{"source":"/usr/local/tomcat/apache-tomcat-7.0.29/logs/localhost_access_log.2019-03-26.txt","offset":11694,"timestamp":"2021-07-12T16:21:52.006333381+08:00","ttl":-1,"type":"log","meta":null,"FileStateOS":{"inode":262747,"device":64768}}]

filebeat之所以能保证事件至少被传递一次而没有数据丢失，是因为filebeat将每个事件的传递状态保存在文件中。在未得到接收方确认时，filebeat会一直尝试发送，直到得到回应。若filebeat在传输过程中被关闭，则不会在关闭前确认所有事件是否被传递。任何在filebeat关闭前未确认的事件，都会在filebeat重启之后重新发送。可确认至少发送一次，但用可能会重复。可通过shutdown_timeout参数设置关闭前等待事件回应的时间。

logstash是接收、处理、转发日志的工具。支持系统日志、webserver日志、错误日志、应用日志，基本包括所有的日志类型。

logstash事件处理的三个阶段：inputs → filters → outputs。

• file → 从文件系统中的文件读取，类似于tail -f命令

• syslog → 在514端口上监听系统日志消息，并根据RFC3164标准进行解析

• redis → 在redis server上读取

• beats → 在filebeat中读取

• grok → 解析任意文本数据，grok是logstash最重要的插件，主要作用是将文本格式的字符串转换为具体的结构化的数据，配置正则表达式使用。

• mutate → 对字段进行转换，例如对字段进行删除、替换、重命名、修改等。

• drop → 丢弃一部分events不进行处理

• clone → 复制事件，该过程中也可以添加或移除字段

• geoip → 添加地理信息(为前台kibana图形化展示使用)

一个事件可以在处理过程中经过多重输出，但是一旦所有的outputs都执行结束，该事件就完成生命周期。常用的outputs为以下

• elasticsearch → 可高效的保存数据，并且能够简单的进行查询

• file → 将事件数据保存到文件中

• graphite → 将事件数据发送到图形化组件中，很流行的开源存储图形化展示的组件

codecs可以轻松的分割已经序列化的数据。常见的codecs如下

• json → 使用json格式对数据进行编码/解码。

• multiline → 多个事件中数据汇总为一个单一的行。比如：java异常信息和堆栈信息

Elasticsearch配置

Master节点编辑elasticsearch.yml配置文件：

Slave1节点编辑elasticsearch.yml配置文件：

Slave2节点编辑elasticsearch.yml配置文件：

Logstash配置：

可以在任一节点部署logstash，默认不修改配置文件也可以运行。

Kibana配置：

可以在任一节点部署Kibana，修改kibana.yml配置文件

启动ELK：

后台启动ES： ./elasticsearch -d

后台启动kibana： nohup ./kibana &

后台启动logstash：nohup ./logstash &

logstash -e input { stdin{} } output { stdout{} } --  -e参数允许在命令行中直接输入配置

logstash -f file_std.conf  --  -f参数指定配置文件

1. logstash简单测试

进入到logstash安装目录，执行以下命令：

./logstash -e input { stdin{} } output { stdout{} }

-e参数允许在命令行中直接输入配置，而不同通过-f参数指定配置文件。

如果出现Pipeline main started则logstash已经启动成功，在命令行输入一些文字后，logstash会加上日期和主机名（IP）输出到终端。这就是Logstash最基本的工作模式，接受标准输入，然后将信息加工后放入到标准输出。

2. logstash接收filebeat输出

在filebeat安装目录中filebeat.yml文件修改如下：

在logstash安装目录中新建配置文件filebeat.conf，使logstash接收filebeat的输入，并输出到终端。

测试配置文件的准确性，返回OK则配置文件没有问题

启动命令./logstash -f ../test/filebeat.conf，输出以下内容则成功

启动命令./filebeat -e -c filebeat.yml -d "public"

查看logstash终端输出

新建配置文件logfile.conf,配置内容如下

验证配置文件logfile.conf准确性

启动命令./logstash -f ../test/logfile.conf

新建配置文件logfileIntoES.conf

启动命令./logstash -f ../test/logfileIntoES.conf，elasticsearch上查看结果如下

需在Chrome双核浏览器上安装Elasticsearch-head插件

安装成功后可点击插件图标使用Elasticsearch-head，输入ES地址和端口即可查看集群中的节点信息、索引信息等。

通过Kibana提供的Dev Tools工具可以查看集群的健康状态，在Dev Tools的Console中运行“GET /_cat/health?v”查看集群状态，返回green和100%则集群状态良好

在Elasticsearch中也可查看集群节点的状态，浏览器访问节点IP:9200即可

在Elasticsearch-head同样可以查看集群的健康状态

• 绿色——健康状态，所有主分片和副本分片都可用

• 黄色——所有主分片可用，部分副本分片不可用

• 红色——部分主分片可用

END

更多精彩干货分享

点击下方名片关注

IT那活儿