基于开源技术栈搭建高可用日志平台

elastic stack开源技术栈介绍

elastic stack栈涉及到以下几个组件

• beats：用于轻量级日志采集，支持文件采集，系统数据采集，特定中间件数据采集等
• logstash：用于日志结构化，标签化，支持DSL方式将数据进行结构化
• elasticsearch：用于提供日志相关的索引，使得日志能够有效的检索
• kibana：用于提供日志检索，特定metric展示的面板，方便使用的UI
• x-pack：用于监控与预警相关的组件，可以集成到es中，kibana有特定的面板用于展示UI
• curator：用于管理ES集群的索引相关的数据，对索引进行分析

使用elastic stack进行日志平台架构如下图所示：

elastic stack技术栈

从以上日志数据的流向可以看到掌阅的应用日志数据有三种流向，下面分别说明：

• beats->es->kibana 该场景适用于数据量比较写，而且数据不需要太多转换的场景
• beats->logstash->es->kibana 该场景适用于数据量不大，但是数据需要进一步分析和转换后才能入ES集群的场景
• beats->queue->logstash->es->kibana 该场景适用于大规模日志数据，并且日志数据需要批量分析过滤结构化的场景

beats采集数据

beats是elasticstack的一员，属于一种轻量级的日志采集组件，使用go语言开发，没有依赖，可以简化部署和运维操作，使用yaml格式的配置文件来采集日志或者系统信息，目前beats支持的事件采集包括：网络数据，日志文件，mysql，system，mongodb，kafka，nginx，redis，zookeeper，haproxy等

beats提供了一个易于开发和扩展的框架用于扩展相关的监控指标的采集来满足各种不同的指标采集需求，logstash提供了对beats数据采集的接入接口，因此只需要使用beats工具进行数据采集，然后将数据推到logstash集群即可；另外beats的数据还支持直接写入es，这种场景适合不需要针对性的对数据做结构化的场景。

目前beats支持以下几种：

• filebeat：用于采集文件数据
• metrcbeat：用于采集各种系统数据
• packetbeat：用于采集网络数据
• winlogbeat：用于采集Windows系统数据
• heartbeat：用于采集心跳数据

beats使用指南

beats是基于libbeat框架进行开发的专门用于采集数据的一个组件。

开源的beats组件列表：https://www./guide/en/beats/libbeat/5.2/community-beats.html

Beats 平台是 Elastic.co 从 packetbeat 发展出来的数据收集器系统，统一基于go进行开发和扩展。beat 收集器可以直接写入 Elasticsearch，也可以传输给 Logstash。其中抽象出来的 libbeat，提供了统一的数据发送方法，输入配置解析，日志记录框架等功能。也就是说，所有的 beat 工具，在配置上，除了 input 以外，在output、filter、shipper、logging、run-options 上的配置规则都是完全一致的，下图是Filebeats的架构设计

filebeat架构设计

上图的filebeat是最常见的一个日志采集工具，主要用来采集文件日志，filebeat的工作原理如下：

• 日志采集器（harvesters）：用来从日志文件读取内容
• 日志勘察器（propectors）：用来管理所有的harvesters和发现日志源进行读取，目前支持stdin和日志文件读取日志，日志勘察器会发现所有定义在配置文件路径中的日志文件，并针对每个日志文件启动一个日志采集器进行采集，每个勘察器都会运行在自己的goroutine中。
• spooler：每个日志采集器采集完成后将日志数据发送给spooler，spooler用来汇集和聚合数据并根据配置文件的输出进行发送出去。
• registry：启动filebeat后会在数据目录产生一个registry文件用来记录采集日志事件的状态以确保所有的日志均至少发送一次，不丢失。另外registry还有以下几个功能：首先，确保filebeat重启后日志数据不重复读取，因为registry会记录每个文件读取的位置，当服务重启时从记录的位置开始执行；其次，如果后端的Elasticsearch或者logstash不可用，filebeats会记录到最后一次发送的行到registry中，当后端可用时重新开始发送。

注意：因为registry文件记录了每个文件的状态并且持久化到了磁盘，如果有大量的文件的话，registry文件可能会变的很大，为了减少registry文件的大小，建议开启clean_removed和clean_inactive两个配置项。

安装和使用filebeat

因为filebeat为go语言开发，语言特性决定了filebeat的安装和使用将会特别方便，首先去官方下载对应版本的压缩包，然后解压到指定路径即可。

当我们安装完filebeat之后，我们可以在filebeat的安装目录下看到两个文件

• filebeat.template.json （输出的文件格式，在filebeat的template中指定，当服务启动时，会被加载）
• filebeat.yml（所有的配置都在该文件下进行）

使用yaml配置beats

1，配置文件名称filebeat.yml，格式yaml格式。

2，filebeat日志勘探器prospector配置项说明

• 输入类型配置：input_type，控制从文件输入还是stdin输入
• 日志路径配置：paths，可以配置多个路径，支持正则匹配
• 文档类型：document_type，可以设置特殊的文档类型进行采集
• 过滤：excluede_lines和include_lines，可以控制是否包含或者不采集某些日志
• 标签：tags，给日志打上tag后方便kibana过滤搜索
• 字段：fields，可以用key/value的方式定义一些特殊的字段给日志文件，方便过滤和筛选
• 采集开始时间：ignore_older，是否从当前时间开始采集，可以设置类似2h,5minutes等，默认为0
• close_*相关配置：针对文件重命名，移除，文件是否有持续写入等条件对监听文件句柄的一些特殊操作
• clean_*相关配置：对监听文件的一些清理操作
• 扫描文件周期：scan_frequency 扫描日志文件的周期，默认10s，可以调大到60s
• 扫描文件的位置：tail_files，如果设置则从文件尾部开始tail，否则从文件头开始
• backoff：Filebeat检测到某个文件到了EOF之后，每次等待多久再去检测文件是否有更新，默认为1s。
• max_backoff：Filebeat检测到某个文件到了EOF之后，等待检测文件更新的最大时间，默认是10秒。
• backoff_factor：定义到达max_backoff的速度，默认因子是2，到达max_backoff后，变成每次等待max_backoff那么长的时间才backoff一次，直到文件有更新才会重置为backoff。比如：如果设置成1，意味着去使能了退避算法，每隔backoff那么长的时间退避一次。

• spool_size:spooler的大小，spooler中的事件数量超过这个阈值的时候会清空发送出去（不论是否到达超时时间）。
• idle_timeout:spooler的超时时间，如果到了超时时间，spooler也会清空发送出去（不论是否到达容量的阈值）。
• registry_file:记录filebeat处理日志文件的位置的文件
• config_dir:如果要在本配置文件中引入其他位置的配置文件，可以写在这里（需要写完整路径），但是只处理prospector的部分。
• publish_async：是否采用异步发送模式（实验功能）。
• 配置举例

3，输出相关的配置：output

• 输出到elasticsearch：output.elasticsearch，以下配置会自动装载es的索引模板

输出到elasticsearch

安装filebeats的时候会在相应得目录下有一份filebeat.template.json的文件，该文件用于高速Elasticsearch集群如何处理filebeat采集的日志，可以用以下命令手动装载该模板：

curl -XPUT 'http://localhost:9200/_template/filebeat?pretty' -d@/etc/filebeat/filebeat.template.json

如果要删除该模板，执行：

curl -XDELETE 'http://localhost:9200/filebeat-*'

• 输出到logstash：output.logstash

输出到logstash

• 输出到kafka：output.kafka

输出到kafka

• 输出到redis：output.redis

输出到Redis

• 输出到文件：output.file

输出到文件

• 输出到终端：output.console

输出到终端

4，完成配置后需要检查配置的可用性

编写完成filebeats相关的配置后执行如下命令检查配置是否正确

./filebeat -configtest -e

5，启动beats

使用本地文件为输入源，console为输出进行debug测试启动

• 配置文件

测试配置

• 启动命令

/data/server/filebeat/filebeat -c /data/server/filebeat/filebeat.test.yml -e

线上启动可以用nohup或者supervisord进行管理。

nohup /data/server/filebeat/filebeat -e -c /data/server/filebeat/filebeat.yml >/dev/null 2>&1 &

6，使用beats组件需要测试和了解的几项指标

• filebeats采集数据的速率每秒支持1w行级别日志采集，如何优化配置还可以更高。
• 采集数据对系统资源的占用，小数据量几乎不耗（需要大数据量进一步验证）如果配置scan_相关的参数间隔时间短会导致消耗CPU。
• mem：小数据量几乎不耗（需要大数据量进一步验证）相对于flume来说可以忽略。
• 采集数据时新增文件，删除文件，变更文件采集方式，对于日志文件变更，重命名，删除，新增等常见场景filebeat都有处理，filebeat会定期扫描配置的日志路径去发现新增的日志，当日志被移除会通过close_removed相关的配置逻辑进行执行操作，默认移除日志后自动关闭句柄。当日志发生重命名操作也会触发close_removed操作进行旧日志移除和关闭，然后重新扫描到新名字日志加入监听。
• 采集数据时如果接收数据的集群异常是否能够正确处理，如果接收数据服务不可用或者阻塞filebeat会监听到并停止数据发送，然后以30s的间隔进行探测，当探测到后端可用后重新开始数据发送。
• filebeat异常退出或者重启是否影响日志采集，如果filebeat退出或者重启对日志采集不会有影响，filebeat内部会记录每个日志采集到什么位置的文件registry到磁盘，每次重启的时候会从该文件读取一下上次采集到什么位置，然后基于上次记录的位置开始采集。
• filebeat配置多个ouput服务时是如何选择服务的，当配置多个接收端时，采取随机选择策略。

安装和使用logstash

1，logstash安装

安装Java环境，要求Jdk版本大于1.8。

Java版本查看

安装logstash

wget https://artifacts./downloads/logstash/logstash-5.2.1.tar.gz

解压到指定路径

tar -xzvf logstash-5.2.1.tar.gz -C /data/server

测试logstash是否安装成功

logstash -e 'input { stdin { } } output { stdout {} }'

2，logstash配置文件讲解

logstash的配置文件是一种DSL的配置方式，主要包括三部分：

• input：配置日志输入源
• filter：配置对日志的过滤清洗规则
• output：将日志输出到指定服务

配置文件举例：

3，启动logstash进行测试

常规启动方式：

/data/server/logstash/bin/logstash -f /data/server/logstash/pipeline/demo.conf

推荐使用supervisord进行管理启动，启动脚本supervisord.conf配置举例：

[program:elkpro_1]environment=LS_HEAP_SIZE=5000mdirectory=/data/server/logstash/command=/data/server/logstash/bin/logstash -f /data/server/logstash/pipelien/pro1.conf --pluginpath /data/server/logstash/plugins/ -w 10 -l /data/logs/logstash/pro1.log[program:elkpro_2]environment=LS_HEAP_SIZE=5000mdirectory=/data/server/logstashcommand=/data/server/logstash/bin/logstash -f /data/server/logstash/pro2.conf --pluginpath /data/server/logstash/plugins/ -w 10 -l /data/logs/logstash/pro2.log

4，logstash的工作原理

在logstash中有输入，过滤，输出即：input，filter，output三种配置，这三种功能在logstash中是通过不同的线程进行处理，通过top命令然后H可以查看logstash的各个线程的工作情况

logstash处理的数据在线程之间以event形式传递，在过滤的过程中可以给event添加或者删除修改event的tag，每个filter插件都会提供add_tag,remove_tag,add_field和remove_field四个方法。

logstash默认基于内存的队列在管道间进行事件传递，如果logstash异常终止缓存在内存的事件将会被丢失，为了避免logstash异常终止导致的事件丢失，可以考虑使用持久化队列来处理事件。跟持久化队列相关的配置项有以下几个：

• queue.type：设置为persisted使之有持久化能力，默认是memory
• path.queue：持久化队列存放的位置
• queue.page_capacity：持久化队列最大队列页，默认250mb，该项理论不会对性能产生影响。
• queue.max_events：允许的最大事件数，默认为0，不限制
• queue.max_bytes：队列的容量，默认1G

当使用了持久化队列的配置后，有一种场景也可能发生就是队列分配的资源使用完了，这时候logstash为了避免后端ES过载采取的措施是不再接受新事件输入。这个时候如果往logstash写入数据的是beats组件时，beats会停止往logstash写入数据，直到logstash队列被消费后才继续写入。

5，logstash事件生命周期

logstash的事件会经历inputs=>filters=>outputs这样的管道完成一个事件的生命周期，我们针对事件的完整生命周期来分别讲解每个阶段的工作内容。

5.1 inputs

可以作为输入源的类型有以下几种

• file：文件
• syslog：通用的syslog日志，简单的syslog架构如下图所示

• redis：从redis中接收日志
• beats：通过filebeat接收日志

5.2 filters

filters阶段是对event的加工处理，每个事件在该阶段都是运行在一个独立的线程中，并将读取到event写入到Java的一个同步队列SynchronousQueue，该队列会将数据发送给当前空闲的worker去处理，如果所有的worker都是busy状态就会阻塞。worker线程数可以通过配置文件进行设置，优化logstash的执行性能可以参考Tuning and Profiling logstash Performance

默认情况下logstash在各个管道（pipeline）间通过内存队列做缓冲进行事件传递

常用的filters有以下几种

• grok：解析并结构化文本，将非结构化数据转换为结构化数据常用的filter，有120多个匹配模式可以使用
• mutate：对event进行调整，增删修改某个event的field
• drop：可以丢弃掉某个event，比如debug级别
• clone：生成一个event的拷贝
• geoip：添加IP地理位置相关的数据到event

5.3 outputs

event最后的处理阶段，该阶段将event事件输出到指定的服务中，当前支持的输出服务有以下几个

• elasticsearch：发送数据到elasticsearch
• file：发送数据到文件
• graphite：发送事件到graphite
• statsd：发送事件到statsd

5.4 Codec

可以用于input或者output中。codecs可以简化某些event的序列化操作，比较流行的codec有以下几个

• json：增加对json数据序列化、反序列化支持
• multiline：对多行数据支持比如stacktrace消息

6，logstash插件架构

基于以上架构可以扩展和丰富logstash日志插件。不再赘述，如果当前插件不能满足业务需求的时候可以考虑进行开发和扩展。以下是官方的插件列表举例：

7，使用filebeat做为文件输入源进行简单配置举例

8，logstash性能调优

logstash默认会选择最佳的性能方案，当默认配置不能满足需求的时候可以对影响性能的几个参数进行调整，涉及到性能相关的参数有以下几个：

• pipeline.workers
• pipeline.batch.size
• pipeline.batch.delay

9，logstash测试指标

• logstash每秒可以处理的数据量
• logstash服务重启是否丢失事件
• logstash集群化如何和filebeat进行集成

使用队列做数据缓冲

由于数据写入太快logstash或者ES集群性能有问题会导致数据写入失败，因此常规的架构上一般在输入数据层都会使用一个队列系统做缓冲区进行缓冲，常见的做为日志平台的数据缓冲的队列系统有以下几种：

• kafka
• redis
• rabitmq

几种队列做一个简单的对比：

1. 是否需要保证日志数据不丢失持久化（kafka）
2. 是否需要高性能（redis，kafka）
3. 是否需要支持分布式扩展（kafka，rabbitmq）
4. 运维友好性（redis）
5. 开发友好性（redis）
6. 完整的队列特性（kafka，rabbitmq）

引入队列中间件的好处：

• 增加缓冲区，是的ES写入可控，logstash的接收可控
• 增加高可用，日志数据写入到队列集群中时logstash的升级和回滚操作不会导致数据丢失

从以上对比分析可以无论选择什么队列做中间件，只要自己能够hold住整体架构即可，每个中间件自身都各有千秋。接下来我们以kafka为队列中间件做分析和举例：

1，kafka架构及原理讲解

kafka通过zookeeper集群保证服务的高可用，kafka自身又包括生产者和消费者，生产者和消费者的连接的桥梁是broker。

生产者和消费者关系

生产者将数据转发到自己感兴趣的topic中，每个topic在kafka上又支持划分多个分区，通过分区的方式来解决负载均衡问题。多个消费者可以订阅自己感兴趣的topic，

生产者和消费者的关系

从上图可以看出生产者是推送数据给kafka，消费者是从kafka拉取数据。

2，kafka集群搭建

从以上原理图大家大概能知道kafka集群的搭建首先需要搭建zookeeper集群，搭建完zookeeper集群后需要根据日志平台进行评估kafka集群的规模，设计kakfa服务器的磁盘分区以及配置项，由于篇幅有限，本文不再单独讲解kafka如何搭建。有兴趣的读者可以参考：http:///2017/09/04/kafka-best-pratice/

存储集群ElasticSearch讲解

elasticsearch是基于luncene的一个分布式搜索服务，支持在线扩容，海量数据存储，高性能倒排列表，模糊搜索等高级特性，为了方便大家理解我拿ES和普通的关系数据库进行对比如下：

使用es2unix工具可以在命令行上操作es

可以用paramedic插件监控ES集群的状态，使用head插件可以查看ES索引的状态，具体如何安装插件和扩展请大家参考插件官方网站即可，不再赘述。

1，单机搭建ES集群讲解

下载elasticsearch指定版本，注意ES官方目前已经升级到6.0以上版本，建议基于最新稳定版本搭建。

ES安装比较简单，从官方下载指定的压缩包，然后解压到指定路径即可。

2，单机模式ES服务启动

用于测试ES服务的接口和API等相关特性，搭建一个节点的单机版本进行测试

启动ES集群前需要先设置ES启动时依赖的一些系统参数：

• 查看ulimit -Hn 如果值小于65535则需要进行调整，编辑/etc/security/limits.conf将 soft和hard相关的配置参数调整到一个大于65535的值
• 配置jvm.options将其堆的大小调整到一个合适的值，默认为2g，如果是测试环境可以调为512m
• 查看系统中max_map_count，先查看sysctl -a|grep vm.max_map_count 如果小于65535则将其调大，可以设置为262144，用sysctl -w vm.max_map_count=262144写入即可，若要永久生效编辑/etc/sysctl.conf将vm.max_map_count=262144即可。

启动命令：

/path/to/elasticsearch/bin/elasticsearch

3，集群模式搭建

由于不同规模，不同配置的硬件对集群搭建要求不一样，建议大家基于自身服务器条件进行定制化搭建，不再赘述。

4，curator管理elasticsearch的索引

curator是python开发的一个工具，专门用来管理es集群相关的索引，通过该工具的api可以对es集群的索引进行单独管理，包括查看，修改，删除，副本，restore，snapshot等。

总结

以上就是一个简单的日志平台涉及到的关键组件的讲解和对应组件的原理分析。下面一个章节我们会将docker和这些组件的适配进行讲解。敬请大家期待。